Instability while Driving Downhill


#1

While we were driving our Magni on the sidewalk, it had difficulty while moving downhill.

Notably, most of the mass of the rover is distributed behind the drive wheels. This is fine when driving uphill, or even sideways. But when driving downhill, the bulk of the mass being situated higher than the drive wheels causes the slightest corrective steering to approach the instability threshold. The rover pose quickly deteriorates to resemble an inverted pendulum tip-over.

Does Ubiquity have available for us a dynamical system model, or other mechanical system characteristics, which would help us to examine these responses analytically?


#2

We do not, currently, have a dynamic system model although this is something we’ve discussed doing in the past. It would be interesting to get video of the behavior you are discussing so we can get a better understanding of exactly what you are talking about.


Motor Unresponsive
#3

Ok, fair enough.

Currently we kind-of overcome this instability issue, with practice practice practice. ((((We are using the recommended Logitech F710, since Bluetooth will not work ~ R-Pi-3B-plus(+) ))))

But, it would be really helpful to reduce the turning power.

When we drive the Magni in slow speed (LB button), moving the joystick left/right commands a non-zero turn rate (omega). We feel that this power level, indicated from /cmd_vel.angular.z, is too fast. Clearly, it can be varied as [-1.0,…,0,…,+1.0], even thougth the forward-power indicated from /cmd_vel.linear.x varies on [-0.3,…,0,…,+0.3]. We observe the same angular power range, even for the higher power (LT button).

While driving and trying to correct for the instability described herein, the angular power available at low speed is too aggressive for our needs. We would like to try values closer to max +/- 0.6 , instead of +/- 1.0 .

I ask then: How can we reduce this turning power level?


#4

This may be out of date info as I did the joystick node years ago. but see this page for parameters that can be varied for joystick node


#5

This ancient joystick_input documentation seems to be too out of date for me to trace where the speed maximums are set.

I have tried a few places to change the max-values in some files, but nothing seems to make any difference. ==> The maximum angular velocity (twist z MAX == -1, +1).

(Reminder ~ my objective is to change this twist-Z-MAX to -0.4 and +0.4)


#6

I need to contact another person on the team to verify this but in looking at what is done these days it seems that logitech.launch is what is run for our joystick we use in demos and so on.

The parameters for that look to me to be from this file
/opt/ros/kinetic/share/magni_teleop/param/logitech.yaml

I think you seek the ‘scale_angular’ value which looks to be defaulted to 1.0 now.

I am doing my best to look into this so if you want a fast reply try that while we verify on this end which may not be as fast as you require.


#7

Sorry about that, the joystick_input code is indeed no longer used.

magni_teleop/param/logitech.yaml is the correct file to modify, and scale angular is the parameter to change. The joystick message has a rotational component from -1 to 1, and it is multiplied by this number to get the turning speed in radians per second.

Right now it is set so the maximum turning is 1.0 radians per second, which is about 10rpm.


#8

Confirmed! ~ Yes, this works!

Edit file /opt/ros/kinetic/share/magni_teleop/param/logitech.yaml

I changed the 1.0 to a 0.4 and this is exactly what we needed.

This is easy to verify with rostopic echo /cmd_vel and see how the angular-Z value is capped at +/- 0.4

Thanks! This has really been an annoying background problem for us.


#9

Re Joystick part of this thread: Sorry for having given you a bad lead earlier. I should have tried to verify what I said but was preoccupied with the release in progress right now (I’m mostly hardware guy). It was good for me as well to track this down and I am going to get the answer to your query out on our ‘Learn’ document pages because you may be the first to ask this but certainly not the last. Thank you for your patience. We use each of these experiences to improve our documents. Take Care.