Revision history [back]

Hello,

I am in the process of trying to construct a 4-wheeled type robot. Once I had arrived at the point to attached plugins and build control laws I began experiencing difficulty with instability. I eventually realized the problem was not my controllers, but the model itself. When the robot was spawned into Gazebo, it began from a zero velocity state and without any control it slowly began to accelerate forward until it was eventually moving so fast it was nearly impossible to track without using the "follow" tool. My robot has many degrees of freedom, so I figured I'd construct a minor test-bed of a single wheel and attempt to control it.

The run away behavior is shown in the attached video. https://drive.google.com/file/d/1WvwkzfFR6qsDHB8gN_pNERyiASsC_AJr/view?usp=sharing

Here are the things I have tried to see if it impacts this behavior, to no avail: 1. Moved the wheel further away from the link it is attached to, so that it is very obviously not colliding with other parts of the model. 2. Turning on/off the <self_collide> tag. 3. Check the inertia tensor and wheel mass - both appear correct. 4. Tried various parameters such as: (mu1=1, mu2=1, fdir1=1 0 0) or (mu1=1, mu2=1, fdir1=0 1 0) 5. Add friction and damping to the joint and trying various values for both.

Any suggestions would be very much appreciated!!

Hello,

I am in the process of trying to construct a 4-wheeled type robot. Once I had arrived at the point to attached plugins and build control laws I began experiencing difficulty with instability. I eventually realized the problem was not my controllers, but the model itself. When the robot was spawned into Gazebo, it began from a zero velocity state and without any control it slowly began to accelerate forward until it was eventually moving so fast it was nearly impossible to track without using the "follow" tool. My robot has many degrees of freedom, so I figured I'd construct a minor test-bed of a single wheel and attempt to control it.

The run away behavior is shown in the attached video. https://drive.google.com/file/d/1WvwkzfFR6qsDHB8gN_pNERyiASsC_AJr/view?usp=sharing

Here are the things I have tried to see if it impacts this behavior, to no avail: 1. Moved the wheel further away from the link it is attached to, so that it is very obviously not colliding with other parts of the model. 2. Turning on/off the <self_collide> tag. 3. Check the inertia tensor and wheel mass - both appear correct. 4. Tried various parameters such as: (mu1=1, mu2=1, fdir1=1 0 0) or (mu1=1, mu2=1, fdir1=0 1 0) 5. Add friction and damping to the joint and trying various values for both.

Any suggestions would be very much appreciated!!

EDIT:

The problem seems strikingly similar to behavior described here: https://github.com/ros-controls/ros_c.... So far as I can tell, it is somehow related to the < limit effort=foo velocity=foo/> tag. When I first posted the problem the wheel would spin out of control without my controllers having been launched and at the time the corresponding tag was set to < limit effort=-1 velocity=-1>. Changing the limiting velocity to 5 had no impact. When I then changed the effort limit to 2000 I could load the model (again without having launched controllers) and the wheel would remain stationary.

Now, when launching an effort_controllers/JointVelocityController with pid: {p: 100.0, i: 0.01, d: 10.0}, the model immediately springs into action. From the joint_states topic I get:

header: seq: 44575 stamp: secs: 576 nsecs: 537000000 frame_id: '' name: - joint_wheel position: [-45737.17731358273] velocity: [-173.34043462268346] effort: [-2000.0]

and from the controller/states topic I get:

header: seq: 45334 stamp: secs: 584 nsecs: 637000000 frame_id: '' set_point: 0.0 process_value: -173.4069538221712 process_value_dot: 0.0 error: 173.4069538221712 time_step: 0.001 command: 1853403.0769598766 p: 100.0 i: 0.01 d: 10.0 i_clamp: 0.0 antiwindup: False

Lastly, from the controller/command topic:

WARNING: no messages received and simulated time is active. Is /clock being published?

In other words, no commands have been sent and somehow there is a windup behavior at startup. I don't think this makes any sense, because the error being integrated at the first time step should be numerically zero. Can someone explain this to me? It almost feels like a bug. More specifically:

1. What is the difference between the command under the controller state topic and the command topic itself?

2. What command is being sent to the controller at the start up time to induce windup and how is it being sent to the model if the command topic is inactive?

3. Why is my velocity limit violated?