[gazebo_ros_control] Spawning a robot in "proper" controlled configuration

[skohlbr]

When spawning a gazebo_ros_controlled robot my workflow currently looks as follows:

• Start Gazebo scenario
• Pause Gazebo
• Spawn robot
• Spawn ros_controllers
• Unpause Gazebo (once controllers are all loaded and initialized)

This is especially crucial for systems like humanoid robots which fall over if controllers are not properly initialized when physics start acting on the simulated robot (which is why the pause/unpause steps need to be performed). While this approach works, it gets tiring pretty quickly. Is there some other method/best practice for properly spawning that I have overlooked or some tool that replicates/automates the above steps?

[jacquelinekay]

You can use gazebo -u or gazebo --pause to start simulation paused.

You can use a launchfile to start gazebo, spawn the robot and spawn ros_controllers, since all of these processes are ROS nodes or can be started as ROS nodes.

To give Gazebo arguments in a launchfile, specify arguments to the Gazebo node:

<node name="gazebo" pkg="<your package name>" args="--pause <any other gazebo arguments>">

This will automate everything in your workflow except unpausing Gazebo.

Our solution to automate these steps in DRCSim is to programmatically "pin" the robot while its controllers settle, then unpin it and let its feet gently touch the ground. We do this programmatically in the robot plugin. You could look into pinning/unpinning or pausing and unpausing Gazebo programmatically (using World::SetPaused).

[skohlbr]

Thanks Jacqueline, that sounds like a workable approach. Some generic approach for also doing the unpause would still be useful I suppose, if not absolutely required.

[adolfo-rt]

We've tried two alternatives on our bipeds.

Originally we did something similar to what ATLAS did circa the VRC trials, which is to load a Gazebo plugin that disables gravity for all robot links until a condition is satisfied (e.g., timeout, message received).

We then wrote our custom gazebo_ros_control hardware abstraction for Gazebo, and implemented a hold-position policy when the plugin starts. So even in the absence of controllers we have a sane default behavior.