ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Teleporting robot via 'rosservice call /gazebo/set_model_state' produces weird behaviour

asked 2011-09-06 21:32:58 -0600

nitschej gravatar image

updated 2011-09-07 20:27:17 -0600

The problem appears with:

  • zero gravity worlds (<gravity>0 0 0</gravity>) OR models with gravity disabled (<enableGravity>false</enableGravity>)
  • AND models that use <attach> and <include> to include additional models (for example a pioneer2dx with attached sonyvid30)

What to do to make it happen: teleport your robot into some location above the ground, for example run

rosservice call /gazebo/set_model_state '{model_state: { model_name: pioneer2dx_model1, pose: { position: { x: 0, y: 0, z: .6 }, orientation: {x: 0, y: 0, z: 0, w: 0 } }, twist: { linear: {x: 0 , y: 0 ,z: 0 } , angular: { x: 0 , y: 0 , z: 0 } } }}'

What I would expect to happen: The robot appears in the specified location, peacefully floating there.

What actually happens: The robot does indeed appear in the specified location. But it is usually rotating wildly, sometimes also drifting away from its position

A good example is the which I think lives somewhere in most Gazebo installations. Just change the <gravity> specification to zero and try the rosservice call above.

The question is now: Is this a bug? Are there other workarounds known than to not use <attach> and <include> on models?

Edit: I actually use the Diamondback Ubuntu packages. So maybe this isn't relevant for newer versions.

An example, from the file, which shows the behavior :

<model:physical name="pioneer2dx_model1">
  <xyz>0 0 0.145</xyz>
  <rpy>0.0 0.0 0.0</rpy>
  <model:physical name="sonyvid30_model">
    <xyz>0.15 0 0.09</xyz>
    <include embedded="true">
      <xi:include href="../models/sonyvid30.model" />
  <include embedded="true">
    <xi:include href="../models/pioneer2dx.model" />

An example which does not show the behavior :

<model:physical name="pioneer2dx_model1">
  <xyz>1 1 0.145</xyz>
  <rpy>0.0 0.0 0.0</rpy>
  <include embedded="true">
    <xi:include href="../models/pioneer2dx.model" />

Any other models, that do not use the <attach>...</attach> + <include>...</include> tags are not affected, though I did not test all too many models. This is probably what you meant by "links".

Actually, when watching the "teleport operation" from a distance I can see what probably causes the spinning: The main body, for example the pioneer2dx_model1, appears at the new position instantly, but the attached body, for example the sonyvid30_model seems to remain at the old position for a very short time and then follows main body like it was attached with a rubber band or something the like. The ensuing impact then makes the robot spin and/or drift.

edit retag flag offensive close merge delete


Can you explain whether your robot has any links attached to it ? Does the behavior occur if you try to teleport different objects than the robot?
Dimitar Simeonov gravatar image Dimitar Simeonov  ( 2011-09-07 10:49:24 -0600 )edit
based on your latest observation, this is because set pose did not follow nested models. It's sounding very much like a bug for nested models. If the simulation was paused, can you check if the "set_model_state" service call only moves the parent-most model?
hsu gravatar image hsu  ( 2011-09-07 20:32:39 -0600 )edit
No, visually it looks ok when paused. Parent and child model appear at the right spot instantly. But when unpausing again the behavior is all the same.
nitschej gravatar image nitschej  ( 2011-09-07 21:15:54 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2011-09-08 14:30:24 -0600

hsu gravatar image

Trying with the confirms that there is a bug with setting pose of nested models in diamondback and electric. The problem is due to a bug in the recursive updates in Ticketed.

Current work around is to combine nested models into a single model. For example, becomes:

<?xml version="1.0"?>

  xmlns:physics="" >


    <gravity>0 0 0</gravity>


    <size>800 600</size>
    <pos>0 0</pos>

      <row height="100%">
        <camera width="100%">
          <xyz>0.35 -0.5 0.43</xyz>
          <rpy>0 14 111.5</rpy>

    <ambient>0.5 0.5 0.5 1.0</ambient>

   <!-- Ground Plane -->
  <model:physical name="plane1_model">
    <xyz>0 0 0</xyz>
    <rpy>0 0 0</rpy>

    <body:plane name="plane1_body">
      <geom:plane name="plane1_geom">
        <normal>0 0 1</normal>
        <size>2000 2000</size>
        <segments>10 10</segments>
        <uvTile>100 100</uvTile>

  <model:physical name="cylinder1_model">
    <xyz>1 -1.5 0.5</xyz>
    <rpy>0.0 0.0 0.0</rpy>

    <body:cylinder name="cylinder1_body">
      <geom:cylinder name="cylinder1_geom">
        <size>0.5 1</size>

  <model:physical name="pioneer2dx_model1">
    <xyz>0 0 0.148</xyz>
    <rpy>0.0 0.0 0.0</rpy>

  <body:box name="sonyvid30_body">
    <xyz>0.15 0.0 0.09</xyz>
    <rpy>0.0 0.0 0.0</rpy>

    <cy ...
edit flag offensive delete link more

answered 2011-09-07 12:01:20 -0600

hsu gravatar image

updated 2011-09-07 12:15:21 -0600

I just tested in electric, and the set_model_pose behavior is as expected.

set_model_pose in Diamondback also seems fine. Are you sure you have the latest debian release?

Try below?

sudo apt-get update
sudo apt-get upgrade

I should mention I am using pioneer2dx model from gazebo, i.e.:

rosrun gazebo gazebo `rospack find gazebo`/gazebo/share/gazebo/worlds/models/pioneer2dx.model
edit flag offensive delete link more


Yes, all packages are up to date. Gazebo package version is 1.2.8-s1312465587~natty. As mentioned it only works if it is a compound model, try "rosrun gazebo gazebo `rospack find gazebo`/gazebo/share/gazebo/worlds/" instead. But don't forget to disable gravity.
nitschej gravatar image nitschej  ( 2011-09-07 19:41:42 -0600 )edit

Question Tools


Asked: 2011-09-06 21:32:58 -0600

Seen: 1,759 times

Last updated: Sep 08 '11