Hello List,
I am having difficulties in getting stable behaviour with my simulated rowing boat.
It is a simple model consisting of not more than 7 links (simple boxes of cylinders) and 6 joints.
Also the ROS part is simple and straight forward I think.
I am using gazebo 9 (and 10), and ros melodic to control the boat.
The code can be found at my [github page](https://github.com/SietseAchterop/Rowing) in the boot1_* packages.
A short video of the behavour can be found in [here](https://github.com/SietseAchterop/Rowing/blob/master/boot1_control/instabilities.webm).
I use the `effort_controllers/JointTrajectoryController` from `ros_control`. No trajectory is given, I only reset the world (Ctrl-R) multiple times.
The first few little jolts show how it should behave, but later erratic behavior occurs.
At the end it looks if a reset_world left it in an ok state, but note that the resting position is different from the one in the beginning. So clearly a bug I think.
Is there anything I can do to figure this out? Thanks in advance, Sietse
EDIT: Having problems with video formats (mp4 and webm) in github. Please also find the video [here](http://fwn06.housing.rug.nl/Rowing/instabilities.webm).
And [here](https://github.com/SietseAchterop/Rowing/blob/master/boot1_control/transparent_inertias.png) a screenshot with inertia and transparent on.
Added center of mass [here](https://github.com/SietseAchterop/Rowing/blob/master/boot1_control/inertia_mass_transparent.png).
**SECOND EDIT:** In a simplified version with only 2 joints the problem also arises.
When the model is started with a running trajectory controller, the model often almost immediately explodes. and gazebo is not running properly anymore.
This short excerpt from the topic `joint_state` shows what happens. see how fast the nan occurs.
position: [-0.43577977092613285, 1.3267801824729801]
velocity: [33.811556435077584, -77.29923331004393]
effort: [1000.0, -1000.0]
position: [-7.732419617015369, -9.80515237239878]
velocity: [374.4009102777115, 797.9344671654218]
effort: [1000.0, 0.0]
position: [2.996455915878168, -21.691837330366322]
velocity: [-5408904271986854.0, 4958858641266772.0]
effort: [0.0, 1000.0]
position: [0.0, -27.227145168715232]
velocity: [nan, nan]
effort: [0.0, 0.0]
Setting a low enough `limit` in the urdf makes the problem go away. But I cannot get a good enough control with that.
When I set the *iters* parameter of the `solver` of `ode` to 150, instead of the default 50, it also works.
Does iters mean the number of iterations done for each timestep of (default) 1 millisecond?
This is a solution for me, but I still find it strange that such a simple model can become unstable so fast.
Or am I missing something?
↧