MOVO falls over in Gazebo

[zkytony]

Description

During navigation in Gazebo, MOVO tends to fall over when rotating, as shown in the image below. This happens frequently and it cannot navigate reliably.

I have tried:

• Reducing max_acceleration in eband_planner_params.yaml from 2.5 to 0.5.
• Increasing the mass of the base_chassis_link in move_base.urdf.xacro from 44.2877 to 100.

The frequency of fall over is reduced after these changes, but the robot still falls over unpredictably.
Has anyone encountered this problem?

Version

Branch: kinetic-devel
Configuration: double arm, 7DOFs.

Provide the branch you are working on, the packages you are using, etc.

Movo's configuration (No arm, single arm, double arm, 6DOF, 7DOF-S)

Steps to reproduce

1. Start the test_zone gazebo environment
2. Start navigation stack with built-in map_nav.launch.
3. Start RViz. In RViz, set a few goals that involve:
   • Rotating ~180 degrees
   • Navigating to a point behind the robot so that it needs to rotate and then navigate
   • Or, use movo_move_base action client to send a few waypoints to navigate.

Expected behavior

If the real robot doesn't fall that frequently, the simulation shouldn't either.

[Philippe117]

Hi @zkytony,

We can reproduce your problem. It is likely a gazebo plugin that is causing physic to "freeze" a part of the MOVO. We are exploring the possible cause causes for this.

Tested on

OS: Ubuntu 16.04
branch: kinetic-devel
Gazebo version: 7.0.0

Observed behavior

A part on the top of the MOVO seems to get freezed in place. (zeroed velocity)
This behavior is inconsistent. Sometimes, the robot is fine, sometimes, it is not.

Prognostic

The fact that the problem is inconsistent let me believe that the configuration is fine. This is most likely a problem with Gazebo itself. We will still look for a solution.

[nightingale-project]

We saw a similar thing happen. A quick fix is to increase the mass of the base of the robot. In the urdf, it'd listed as 40 kg, but in reality its closer to 80 kg or so.

we fixed it in our fork in this PR:
nightingale-project@3a1026e