# Revision history [back]

### Still runaway simulations in gazebo

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 in the boot1_* packages.

A short video of the behavour can be found in here. 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

### Still runaway simulations in gazebo

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 in the boot1_* packages.

A short video of the behavour can be found in here. 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.

### Still runaway simulations in gazebo

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 in the boot1_* packages.

A short video of the behavour can be found in here. 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.

And here a screenshot with inertia and transparent on.

### Still runaway simulations in gazebo

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 in the boot1_* packages.

A short video of the behavour can be found in here. 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.

And here a screenshot with inertia and transparent on.on. Added center of mass here.

### Still runaway simulations in gazebo

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 in the boot1_* packages.

A short video of the behavour can be found in here. 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.

And here a screenshot with inertia and transparent on. Added center of mass here.

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?

### Still runaway simulations in gazebo

Hello List,

After 2 months I still am struggling with this! Please see my third edit below.

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 in the boot1_* packages.

A short video of the behavour can be found in here. 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.

And here a screenshot with inertia and transparent on. Added center of mass here.

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?

THIRD EDIT:

I think I have checked my model extensively, there is nothing exotic about it, all masses, inertias, axes and limits are reasonable, and still it crashes most of the time. I really don't know what to do else!

My current model is in boot3_description/urdf. I created an sdf file from it and if I start gazebo with that it crashes almost immediately. See this video for what happens. This is typical, most links suddenly jump to the origin. After that gazebo does not respond to a control-R anymore.

Note there is nothing of ROS in the system, I also removed loading of the ros_control_plugin from the sdf-file. I only can conclude there is an error in gazebo. What can I do?

Normally I start this model using roslaunch boot3_gazebo boot_world.launch. Please help!

### Still runaway simulations in gazebo

Hello List,

After 2 months I still am struggling with this! Please It's becoming a long story, please see my third 4-th edit below.

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 in the boot1_* packages.

A short video of the behavour can be found in here. 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.

And here a screenshot with inertia and transparent on. Added center of mass here.

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?

THIRD EDIT:

I think I have checked my model extensively, there is nothing exotic about it, all masses, inertias, axes and limits are reasonable, and still it crashes most of the time. I really don't know what to do else!

My current model is in boot3_description/urdf. I created an sdf file from it and if I start gazebo with that it crashes almost immediately. See this video for what happens. This is typical, most links suddenly jump to the origin. After that gazebo does not respond to a control-R anymore.

Note there is nothing of ROS in the system, I also removed loading of the ros_control_plugin from the sdf-file. I only can conclude there is an error in gazebo. What can I do?

Normally I start this model using roslaunch boot3_gazebo boot_world.launch. Please help!

FOURTH EDIT:

Maybe I am doing something wrong in the shoulder joints. There are 3 joints. When all are revolute the simulation always crashed. Sometimes there is an error:

gzclient: /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/OgreMain/include/OgreAxisAlignedBox.h:252: void Ogre::AxisAlignedBox::setExtents(const Ogre::Vector3&, const Ogre::Vector3&): Assertion (min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"' failed.


If I make one of the joints fixed, it only very occasionally crashes, although the behavior is very unstable for a long time. Note I have dynamic damping in all joints. Here the urdf piece of the shoulder with 2 revolute joints:

<!-- 3D joint left shoulder -->
<joint name="shoulder_l" type="revolute" >
<origin rpy="0.0 0.0 0.13" xyz="0.0 0.2   0.0"/>
<axis xyz="0 0 1" />
<dynamics damping="0.005" />
<limit effort="100.0" lower="-1.5" upper="0.5" velocity="1.0"/>
</joint>
<inertial>
<mass value="0.01"/>
<origin rpy="0 0 0" xyz="0 0.0 0.0"/>
<inertia ixx="0.000000167" ixy="0" ixz="0" iyy="0.000000167" iyz="0" izz="0.000000167"/>
</inertial>
<visual>
<origin rpy="0 0 0" xyz="0.0 0.0 0.0"/>
<geometry>
<box size="0.01 0.01 0.01"/>
</geometry>
</visual>
<joint name="shoulder_iets" type="fixed" >
<origin rpy="-0.803 0.0 0.0" xyz="0.0 0.0   0.0"/>
<axis xyz="1 0 0" />
<dynamics damping="0.005" />
<limit effort="100.0" lower="-1.5" upper="1.5" velocity="1.0"/>
</joint>
<inertial>
<mass value="0.01"/>
<origin rpy="0 0 0" xyz="0 0.0 0.0"/>
<inertia ixx="0.000000167" ixy="0" ixz="0" iyy="0.000000167" iyz="0" izz="0.000000167"/>
</inertial>
<visual>
<origin rpy="0 0 0" xyz="0.0 0.0 0.0"/>
<geometry>
<box size="0.01 0.01 0.01"/>
</geometry>
</visual>
<joint name="LShoulderTheta" type="revolute" >
<origin rpy="0 0.68 0" xyz="0 0.0 0.0"/>
<axis xyz="0 1 0" />
<dynamics damping="0.005" />
<limit effort="100.0" lower="-2.0" upper="1.0" velocity="1.0"/>
</joint>


Is this a correct way of creating a flexible shoulder?

Thanks again, Sietse

### Still runaway simulations in gazebo

Hello List,

It's becoming a long story, please see my 4-th edit below.

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 in the boot1_* packages.

A short video of the behavour can be found in here. 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.

And here a screenshot with inertia and transparent on. Added center of mass here.

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?

THIRD EDIT:

I think I have checked my model extensively, there is nothing exotic about it, all masses, inertias, axes and limits are reasonable, and still it crashes most of the time. I really don't know what to do else!

My current model is in boot3_description/urdf. I created an sdf file from it and if I start gazebo with that it crashes almost immediately. See this video for what happens. This is typical, most links suddenly jump to the origin. After that gazebo does not respond to a control-R anymore.

Note there is nothing of ROS in the system, I also removed loading of the ros_control_plugin from the sdf-file. I only can conclude there is an error in gazebo. What can I do?

Normally I start this model using roslaunch boot3_gazebo boot_world.launch. Please help!

FOURTH EDIT:

Maybe I am doing something wrong in the shoulder joints. There are 3 joints. When all are revolute the simulation always crashed. Sometimes there is an error:

gzclient: /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/OgreMain/include/OgreAxisAlignedBox.h:252: void Ogre::AxisAlignedBox::setExtents(const Ogre::Vector3&, const Ogre::Vector3&): Assertion (min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"' failed.


If I make one of the joints fixed, it only very occasionally crashes, although the behavior is very unstable for a long time. This in a totally un-physical way, where does all the energy come from to make the arm suddenly spin very fast? Note I have dynamic damping in all joints. joints.

Here the urdf piece of the shoulder with 2 revolute joints:

<!-- 3D joint left shoulder -->
<joint name="shoulder_l" type="revolute" >
<origin rpy="0.0 0.0 0.13" xyz="0.0 0.2   0.0"/>
<axis xyz="0 0 1" />
<dynamics damping="0.005" />
<limit effort="100.0" lower="-1.5" upper="0.5" velocity="1.0"/>
</joint>
<inertial>
<mass value="0.01"/>
<origin rpy="0 0 0" xyz="0 0.0 0.0"/>
<inertia ixx="0.000000167" ixy="0" ixz="0" iyy="0.000000167" iyz="0" izz="0.000000167"/>
</inertial>
<visual>
<origin rpy="0 0 0" xyz="0.0 0.0 0.0"/>
<geometry>
<box size="0.01 0.01 0.01"/>
</geometry>
</visual>
<joint name="shoulder_iets" type="fixed" >
<origin rpy="-0.803 0.0 0.0" xyz="0.0 0.0   0.0"/>
<axis xyz="1 0 0" />
<dynamics damping="0.005" />
<limit effort="100.0" lower="-1.5" upper="1.5" velocity="1.0"/>
</joint>
<inertial>
<mass value="0.01"/>
<origin rpy="0 0 0" xyz="0 0.0 0.0"/>
<inertia ixx="0.000000167" ixy="0" ixz="0" iyy="0.000000167" iyz="0" izz="0.000000167"/>
</inertial>
<visual>
<origin rpy="0 0 0" xyz="0.0 0.0 0.0"/>
<geometry>
<box size="0.01 0.01 0.01"/>
</geometry>
</visual>
<joint name="LShoulderTheta" type="revolute" >
<origin rpy="0 0.68 0" xyz="0 0.0 0.0"/>
<axis xyz="0 1 0" />
<dynamics damping="0.005" />
<limit effort="100.0" lower="-2.0" upper="1.0" velocity="1.0"/>
</joint>


Is this a correct way of creating a flexible shoulder?

Thanks again, Sietse

### Still runaway simulations in gazebo

Hello List,

It's becoming a long story, please see my 4-th edit below.UPDATED: I completely rewrote the question to make it more clear.

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 model can be found at on my github page in the boot1_* packages.boot3_description/urdf directory.

A short video of the behavour simplified version can be found in herethe testing directory. 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 Please see crash.mp4 for 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.

And here a screenshot with inertia and transparent on. Added center of mass here.

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?

THIRD EDIT:

I think I have checked my model extensively, there is nothing exotic about it, all masses, inertias, axes and limits are reasonable, and still it crashes most of the time. I really don't know what to do else!

My current model is in boot3_description/urdf. I created an sdf file from it and if I start gazebo with that it crashes almost immediately. See this video for what happens. This is typical, most links suddenly jump to the origin. After that gazebo does not respond to a control-R anymore.

Note there is nothing of ROS in the system, I also removed loading of the ros_control_plugin from the sdf-file. I only can conclude the simulation (and simulator) blows up.

Sometimes there is an error in gazebo. What can I do?

Normally I start this model using roslaunch boot3_gazebo boot_world.launch. Please help!

FOURTH EDIT:

Maybe I am doing something wrong in the shoulder joints. There are 3 joints. When all are revolute the simulation always crashed. Sometimes there is an error:message like:

gzclient: /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/OgreMain/include/OgreAxisAlignedBox.h:252: void Ogre::AxisAlignedBox::setExtents(const Ogre::Vector3&, const Ogre::Vector3&): Assertion (min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"' failed.


If I make one The model is crash_boot.xacro and for testing I use the (normally) generated crash_boot.sdf. The model now contains only 3 revolute joints. Playing around with friction and damping does not help.

What does help is reducing the max step size by a factor of the joints fixed, 10. But it only very occasionally crashes, although the behavior is very unstable for a long time. This in a totally un-physical way, where does all the energy come from to make the arm suddenly spin very fast? Note I have dynamic damping in all joints.

Here the urdf piece of the shoulder then becomes impractically slow, especially when using the full blown model with 2 revolute joints:

<!-- 3D joint left shoulder -->
<joint name="shoulder_l" type="revolute" >
<origin rpy="0.0 0.0 0.13" xyz="0.0 0.2   0.0"/>
<axis xyz="0 0 1" />
<dynamics damping="0.005" />
<limit effort="100.0" lower="-1.5" upper="0.5" velocity="1.0"/>
</joint>
<inertial>
<mass value="0.01"/>
<origin rpy="0 0 0" xyz="0 0.0 0.0"/>
<inertia ixx="0.000000167" ixy="0" ixz="0" iyy="0.000000167" iyz="0" izz="0.000000167"/>
</inertial>
<visual>
<origin rpy="0 0 0" xyz="0.0 0.0 0.0"/>
<geometry>
<box size="0.01 0.01 0.01"/>
</geometry>
</visual>
<joint name="shoulder_iets" type="fixed" >
<origin rpy="-0.803 0.0 0.0" xyz="0.0 0.0   0.0"/>
<axis xyz="1 0 0" />
<dynamics damping="0.005" />
<limit effort="100.0" lower="-1.5" upper="1.5" velocity="1.0"/>
</joint>
<inertial>
<mass value="0.01"/>
<origin rpy="0 0 0" xyz="0 0.0 0.0"/>
<inertia ixx="0.000000167" ixy="0" ixz="0" iyy="0.000000167" iyz="0" izz="0.000000167"/>
</inertial>
<visual>
<origin rpy="0 0 0" xyz="0.0 0.0 0.0"/>
<geometry>
<box size="0.01 0.01 0.01"/>
</geometry>
</visual>
<joint name="LShoulderTheta" type="revolute" >
<origin rpy="0 0.68 0" xyz="0 0.0 0.0"/>
<axis xyz="0 1 0" />
<dynamics damping="0.005" />
<limit effort="100.0" lower="-2.0" upper="1.0" velocity="1.0"/>
</joint>


Is this a correct way of creating a flexible shoulder?almost 40 joints.

Hopefully someone can help, as I am really stuck here.

Thanks again, Sietse

PS. I also asked this question on gazebo issues, but did not yet got a response.

### Still runaway simulations in gazebo

Hello List,

UPDATED: I completely rewrote the question to make it more clear.

I am having difficulties in getting stable behaviour with my simulated rowing boat. The model can be found on my github page in the boot3_description/urdf directory.

A simplified version can be found in the testing directory Please see crash.mp4 for how the simulation (and simulator) blows up.

Sometimes there is an error message like:

gzclient: /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/OgreMain/include/OgreAxisAlignedBox.h:252: void Ogre::AxisAlignedBox::setExtents(const Ogre::Vector3&, const Ogre::Vector3&): Assertion (min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"' failed.


The model is crash_boot.xacro and for testing I use the (normally) generated crash_boot.sdf. The model now contains only 3 revolute joints. Playing around with friction and damping does not help.

What does help is reducing the max step size by a factor of 10. But it then becomes impractically slow, especially when using the full blown model with almost 40 joints.

Hopefully someone can help, as I am really stuck here.

Thanks again, Sietse

PS. I also asked this question on gazebo issues, but did not yet got a response.

### Still runaway simulations in gazebo

Hello List,

UPDATED: I completely rewrote the question to make it more clear. See update below!

I am having difficulties in getting stable behaviour with my simulated rowing boat. The model can be found on my github page in the boot3_description/urdf directory.

A simplified version can be found in the testing directory Please see crash.mp4 for how the simulation (and simulator) blows up.

Sometimes there is an error message like:

gzclient: /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/OgreMain/include/OgreAxisAlignedBox.h:252: void Ogre::AxisAlignedBox::setExtents(const Ogre::Vector3&, const Ogre::Vector3&): Assertion (min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"' failed.


The model is crash_boot.xacro and for testing I use the (normally) generated crash_boot.sdf. The model now contains only 3 revolute joints. Playing around with friction and damping does not help.

What does help is reducing the max step size by a factor of 10. But it then becomes impractically slow, especially when using the full blown model with almost 40 joints.

Hopefully someone can help, as I am really stuck here.

UPDATE: Enforcing more limits as in

   <limit>
<lower>-1.5</lower>
<upper>0.5</upper>
<effort>1</effort>
<velocity>0.01</velocity>
</limit>


seems to be completely ignored the model and gazebo crashes just the same!

Thanks again, Sietse

PS. I also asked this question on gazebo issues, but did not yet got a response.

### Still runaway simulations in gazebo

Hello List,

UPDATED:UPDATED AGAIN: See latest update below!

I am having difficulties in getting stable behaviour with my simulated rowing boat. The model can be found on my github page in the boot3_description/urdf directory.

A simplified version can be found in the testing directory Please see crash.mp4 for how the simulation (and simulator) blows up.

Sometimes there is an error message like:

gzclient: /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/OgreMain/include/OgreAxisAlignedBox.h:252: void Ogre::AxisAlignedBox::setExtents(const Ogre::Vector3&, const Ogre::Vector3&): Assertion (min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"' failed.


The model is crash_boot.xacro and for testing I use the (normally) generated crash_boot.sdf. The model now contains only 3 revolute joints. Playing around with friction and damping does not help.

What does help is reducing the max step size by a factor of 10. But it then becomes impractically slow, especially when using the full blown model with almost 40 joints.

Hopefully someone can help, as I am really stuck here.

UPDATE: Enforcing more limits as in

   <limit>
<lower>-1.5</lower>
<upper>0.5</upper>
<effort>1</effort>
<velocity>0.01</velocity>
</limit>


seems to be completely ignored the model and gazebo crashes just the same!

2nd UPDATE: Getting a bit despondent here.

I can get it a bit better by increasing iterations in the solver, e.g. to 200 or 500. The testing model now works fine, but the complete (boot3) model now most of the time will be stable for some time (sometimes several minutes). But adding a few controllers to the joints makes it unstable again. But not by the controller itself, I am using very low values for pid.

The instability maybe comes from two or more joints connected directly together as in an elbow or shoulder using e.g.

 <link name="left_shoulder_psi_link">
<inertial>
<mass value="0.01"/>
<origin rpy="0 0 0" xyz="0 0.0 0.0"/>
<inertia ixx="0.000000167" ixy="0" ixz="0" iyy="0.000000167" iyz="0" izz="0.000000167"/>
</inertial>
<visual>
<origin rpy="0 0 0" xyz="0.0 0.0 0.0"/>
<geometry>
<box size="0.01 0.01 0.01"/>
</geometry>
</visual>


So with no change in the origin.

If you pull the Rowing repository and then do

roslaunch boot3_gazebo control_boot_world.launch


you will see the simulated rower in gazebo. Starting the simulation (and the control via ros_control) will show the crashing fairly quickly.

The following shows that a simplified model does work ok.

roslaunch testboot_gazebo control_boot_world.launch


Thanks again, Sietse

PS. I also asked this question on gazebo issues, but did not yet got a response.

### Still runaway simulations in gazebo

Hello List,

UPDATED YET AGAIN: See latest 3rd update below!

I am having difficulties in getting stable behaviour with my simulated rowing boat. The model can be found on my github page in the boot3_description/urdf directory.

A simplified version can be found in the testing directory Please see crash.mp4 for how the simulation (and simulator) blows up.

Sometimes there is an error message like:

gzclient: /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/OgreMain/include/OgreAxisAlignedBox.h:252: void Ogre::AxisAlignedBox::setExtents(const Ogre::Vector3&, const Ogre::Vector3&): Assertion (min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"' failed.


The model is crash_boot.xacro and for testing I use the (normally) generated crash_boot.sdf. The model now contains only 3 revolute joints. Playing around with friction and damping does not help.

What does help is reducing the max step size by a factor of 10. But it then becomes impractically slow, especially when using the full blown model with almost 40 joints.

Hopefully someone can help, as I am really stuck here.

UPDATE: Enforcing more limits as in

   <limit>
<lower>-1.5</lower>
<upper>0.5</upper>
<effort>1</effort>
<velocity>0.01</velocity>
</limit>


seems to be completely ignored the model and gazebo crashes just the same!

2nd UPDATE: Getting a bit despondent here.

I can get it a bit better by increasing iterations in the solver, e.g. to 200 or 500. The testing model now works fine, but the complete (boot3) model now most of the time will be stable for some time (sometimes several minutes). But adding a few controllers to the joints makes it unstable again. But not by the controller itself, I am using very low values for pid.

The instability maybe comes from two or more joints connected directly together as in an elbow or shoulder using e.g.

 <link name="left_shoulder_psi_link">
<inertial>
<mass value="0.01"/>
<origin rpy="0 0 0" xyz="0 0.0 0.0"/>
<inertia ixx="0.000000167" ixy="0" ixz="0" iyy="0.000000167" iyz="0" izz="0.000000167"/>
</inertial>
<visual>
<origin rpy="0 0 0" xyz="0.0 0.0 0.0"/>
<geometry>
<box size="0.01 0.01 0.01"/>
</geometry>
</visual>


So with no change in the origin.

If you pull the Rowing repository and then do

roslaunch boot3_gazebo control_boot_world.launch


you will see the simulated rower in gazebo. Starting the simulation (and the control via ros_control) will show the crashing fairly quickly.

The following shows that a simplified model does work ok.

roslaunch testboot_gazebo control_boot_world.launch


Thanks again, 3rd UPDATE

After some help from gazebo/issues I now have a better simple example that still crashes! Please see this folder on my github page.

The video shows the usual form of crashing. Sometimes gazebo crashes entirely with the error mentioned above.

Simplifying it further makes is stable most of the time. For example removing the fixed_joint/link between world and the first revolute joint makes it stable.

It is a simple model with 3 joints and a few links with a mass of 1kg. I currently use gazebo 9.6.0.

PS. I also asked this question on gazebo issues, but did not yet got a response.

### Still runaway simulations in gazebo

Hello List,

UPDATED YET AGAIN: See 3rd update below!

I am having difficulties in getting stable behaviour with my simulated rowing boat. The model can be found on my github page in the boot3_description/urdf directory.

A simplified version can be found in the testing directory Please see crash.mp4 for how the simulation (and simulator) blows up.

Sometimes there is an error message like:

gzclient: /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/OgreMain/include/OgreAxisAlignedBox.h:252: void Ogre::AxisAlignedBox::setExtents(const Ogre::Vector3&, const Ogre::Vector3&): Assertion (min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"' failed.


The model is crash_boot.xacro and for testing I use the (normally) generated crash_boot.sdf. The model now contains only 3 revolute joints. Playing around with friction and damping does not help.

What does help is reducing the max step size by a factor of 10. But it then becomes impractically slow, especially when using the full blown model with almost 40 joints.

Hopefully someone can help, as I am really stuck here.

UPDATE: Enforcing more limits as in

   <limit>
<lower>-1.5</lower>
<upper>0.5</upper>
<effort>1</effort>
<velocity>0.01</velocity>
</limit>


seems to be completely ignored the model and gazebo crashes just the same!

2nd UPDATE: Getting a bit despondent here.

I can get it a bit better by increasing iterations in the solver, e.g. to 200 or 500. The testing model now works fine, but the complete (boot3) model now most of the time will be stable for some time (sometimes several minutes). But adding a few controllers to the joints makes it unstable again. But not by the controller itself, I am using very low values for pid.

The instability maybe comes from two or more joints connected directly together as in an elbow or shoulder using e.g.

 <link name="left_shoulder_psi_link">
<inertial>
<mass value="0.01"/>
<origin rpy="0 0 0" xyz="0 0.0 0.0"/>
<inertia ixx="0.000000167" ixy="0" ixz="0" iyy="0.000000167" iyz="0" izz="0.000000167"/>
</inertial>
<visual>
<origin rpy="0 0 0" xyz="0.0 0.0 0.0"/>
<geometry>
<box size="0.01 0.01 0.01"/>
</geometry>
</visual>


So with no change in the origin.

If you pull the Rowing repository and then do

roslaunch boot3_gazebo control_boot_world.launch


you will see the simulated rower in gazebo. Starting the simulation (and the control via ros_control) will show the crashing fairly quickly.

The following shows that a simplified model does work ok.

roslaunch testboot_gazebo control_boot_world.launch


3rd UPDATE

After some help from gazebo/issues I now have a better simple example that still crashes! Please see this folder on my github page.

The video shows the usual form of crashing. Sometimes gazebo crashes entirely with the error mentioned above.

Simplifying it further makes is stable most of the time. For example removing the fixed_joint/link between world and the first revolute joint makes it stable.

It is a simple model with 3 joints and a few links with a mass of 1kg. I currently use gazebo 9.6.0.9.6.0. The sdf file is generated from the urdf in the usual way.