Only released in EOL distros:
Used by (2)
Sets up the gazebo robot manager as a service to assist in spawning/killing robots as concert clients.
- Maintainer status: developed
- Maintainer: Daniel Stonier <d.stonier AT gmail DOT com>, Piyush Khandelwal <piyushk AT gmail DOT com>
- Author: Daniel Stonier, Piyush Khandelwal
- License: BSD
- Bug / feature tracker: https://github.com/robotics-in-concert/concert_services/issues
- Source: git https://github.com/robotics-in-concert/concert_services.git (branch: indigo)
This package contains all the robot-agnostic code for running simulated robots in Gazebo with the concert framework.
Given a set of robots with their locations, this package provides a service that spawns Gazebo locally, spawns those robots in Gazebo, create a concert client for each robot, and flip connections to each concert allowing them to behave as independent robot clients.
Using this package with a new robot
In order to use this package, you'll have to do the following.
- How to add a new robot type
How to add a new robot type to use in concert service gazebo
- How to spawn robots in concert gazebo
how to spawn robots in concert gazebo
An example is available in the gazebo_concert package.
Other useful notes
When spawning the robots in Gazebo, make sure that you spawn the robots in the global ROS namespace, and not the namespace of the service from which you'll be spawning Gazebo (typically /services/<service-name>/).
Do not flip connections to a robot's concert if you eventually plan to use them locally (by pulling it through a rapp). This will cause infinite copies of the topic to be flipped around between the concert master and the concert clients. Additionally subscribers misbehave when subscribed against 2 ROS masters (#127)
Make sure that you set /use_sim_time to true when launching the concert master as well as each concert client.
Next, you'll need to write a new package that extends the RobotManager module in this package, specifying the following pieces of information: