Problem with transmissions when planning, controlling and spawning a robot made out of robots

asked 2014-12-12 11:47:00 -0500

carlos gravatar image

I have a robot formed by several robots, say two arms, two hands mounted at each arm as end-effectors, and a head, as usual, and have the following requirements:

  1. Plan for the two arms simultaneously, or plan for one arm being aware that there is another arm, etc(using MoveIt! and ros_control).

  2. A launch file in which I can select whether a part uses the real or the simulated hardware (using Gazebo).

  3. Each part is a self-contained robot, that is, the URDF has a gazebo_ros_control plugin and transmissions, so it can be used separately as well.

  4. (optional, but desirable) Minimize duplication in specifications, as always.

My short experience with MoveIt!, and as well, as explained in this post, tells me that a single URDF for point 1 is the best, if not the only, solution for now.

The issue with a single URDF loading self-contained URDFs is that the gazebo_ros_control plugin parses/loads/(eventually uses) all transmissions from the robot_description parameter. Each plugin of each part starts in a different namespace, ok, but every time a plugin starts, it loads all transmissions again, and create the interfaces for the same joints in different namespaces, and so on. I wouldn't use a single plugin for the whole robot, specially having a custom robotHWsim interface that uses a custom transmission on the hands (it worths noting that). So, what I'd like to happen is that each plugin uses those transmissions affecting the joints the plugin is meant to expose. And recall that I can't use the <robotParam> tag in the plugin, since I'm using a single URDF... that would be ideal.

One possible solution I can think of is to allow a namespace specification in transmissions, in a similar way as the gazebo_ros_control plugin <robotNamespace> tag, with the aim to use that information to filter transmissions out by namespace when starting the plugin. Thus, one could spawn a single URDF, and in my case, point 2 would be just a mere source_list/remap of joint states from real and/or simulated hardware.

/

My workaround so far is to have both a single URDF of the full robot which is not spawned in gazebo and used through the robot_description parameter in MoveIt!, Rviz, etc., and separated URDFs which are spawned in gazebo in case I want to simulate that part, where transmissions are loaded from a /PART_NAMESPACE/robot_description parameter. Note that placement points for each URDF part are useless in this case, and as a consequence, the full robot in simulation is only useful to control a dynamic/kinematic chain. Something like the proposed here would help on this. However, I would still prefer spawning a single URDF file.

Has anyone faced a similar problem? (or perhaps I'm missing a more trivial solution) Suggestions, tips and comments are more than welcome. Thanks.

edit retag flag offensive close merge delete

Comments

I tried succesfully the robotNamespace tag in the transmissioninterface package. (Simple) changes are in the "multi-robot-test" branch of https://github.com/CentroEPiaggio/roscontrol and https://github.com/CentroEPiaggio/gazeborospkgs that allows me to spawn a single robot description param composed of robots (having different HW and Trans interfaces). The same param used by MoveIt!. Here a screenshot of the whole robot https://www.dropbox.com/s/wmfahzm8jln1059/vito.png?dl=0.

carlos gravatar imagecarlos ( 2015-02-13 13:07:47 -0500 )edit