[gazebo] robot agnostic gazebo service

[stonier]

Use Case: gazebo service serves a map, as well as a manager which can spawn robots of multiple types (e.g. segbots and turtlebots).

This was my original thought...and it was to provide just one concert service inside of which you could specify the world you want (by service parameters), serve the world map, start the gazebo world and launch a single spawn manager node which would be responsible for spawning segbots and turtlebots.

Right now the gazebo service is segbot specific. Which would mean to do turtlebots and segbots, you'd have to run two gazebo services. Which service is responsible for the world? @piyushk Is there anything stopping us from dropping back to one robot agnostic concert gazebo service?

[piyushk]

@stonier I understand the problem. To implement what you've suggested, we'll have to specify how the spawn manager node will need to know robot-specific information. Do you have any thoughts on how we can specify that information?

[stonier]

It just needs a dictionary of string identifiers (e.g. 'segbot') and module names to get a handle on a robot manager (e.g. 'concert_service_segbot_gazebo'). At a rough guess you could then try some code like:

supported_robot_managers = { 'segbot': 'concert_service_segbot_gazebo'}

requested_robot = 'segbot'
try:
    robot_gazebo_module = __import__(supported_robot_managers[requested_robot])
    robot_managers.append(robot_gazebo_module.GazeboRobotManager())
except KeyError:
    rospy.logwarn("sorry, that robot is not supported [%s]" % requested_robot)
except ImportError:
    rospy.logerror("Sorry, support for that robot is available, but not installed [%s]" % requested_robot)

That assumes all robot specific managers have the class name GazeboRobotManager but I'm sure that could be relaxed via string name calls as well.

[stonier]

This is kind of a plugin based approach. Perhaps there is a better, more pythonic way of addressing it than the brute force code I have above.

[piyushk]

I assume we can read supported_robot_managers from export tags in a package.xml? Instead of hardcoding it or requiring that it be a parameter? This would bring this solution pretty close to being an equivalent of pluginlib for python.

Other than that, this seems like a fair solution, and better than the current one. :+1:

[jihoonl]

It has been long. I would like to propose new approach to load robots in gazebo using concert. @piyushk Can you review the changes? It allows to load different types of robots into one gazebo without creating classes for each robot.

Installation and test guide

https://github.com/robotics-in-concert/concert_services/blob/gazebo_upgrade/concert_service_gazebo/README.md

[piyushk]

Sure. I'll get to it on the weekend.

On Thu, Aug 28, 2014 at 6:02 AM, Jihoon Lee notifications@github.com wrote:

It has been long. I would like to propose new approach to load robots in gazebo using concert. @piyushk https://github.com/piyushk Can you review the changes? It allows to load different types of robots into one gazebo without creating classes for each robot.

Installation and test guide

https://github.com/robotics-in-concert/concert_services/blob/gazebo_upgrade/concert_service_gazebo/README.md

— Reply to this email directly or view it on GitHub https://github.com/robotics-in-concert/concert_services/issues/18#issuecomment-53716042 .

[jihoonl]

http://www.youtube.com/watch?v=kz9PaTc1THY&feature=youtu.be

[piyushk]

@jihoonl Everything looks reasonably solid. This is a great set of changes. I'll need more time to test if navigation still continues to work with multiple robots in Gazebo, but I remember I had hacked my way around it in the first place. Your solution is definitely much cleaner.

I won't be able to test the navigation stuff for the next month or so, but I'll try to get back to it then. Please merge theses issues in. I'll raise separate ones if a problem arises.

[jihoonl]

Thanks. I will keep you posted if anything changes.

[jihoonl]

29 describes concert_service_gazebo workflow. Closing the issue.