spawn_model -J initial joint positions not working

[davetcoleman]

using the command line argument -J

i spent a lot of time investigating this today to no avail

@hsu

[davetcoleman]

Related to https://bitbucket.org/osrf/gazebo/pull-request/628/allow-scoped-and-non-scoped-joint-names-to/diff

[davetcoleman]

The ability to specify initial joint positions is still broken in the current gazebo_ros_pkgs - any idea why @hsu? Thanks!

[hsu]

seems to be working for me using the double pendulum example:

rosrun gazebo_ros spawn_model -sdf -model p100 -file ~/.gazebo/models/double_pendulum_with_base/model.sdf -x 2 -J upper_joint -1.5

Can you confirm it's still broken?
thanks.

[davetcoleman]

Its still broken with Baxter using a URDF, but your SDF version does work on my computer using the double pendulum example. To reproduce, first get the Baxter URDF:

git clone https://github.com/davetcoleman/baxter_common.git -b dual_parallel_grippers

Then (replace the file location of the URDF):

rosrun gazebo_ros gazebo
rosrun gazebo_ros spawn_model -urdf -model baxter -file ~/ros/ws_baxter/src/baxter_common/baxter_description/urdf/baxter.urdf -z 0.93 -J right_s0 -0.272659 -J right_s1 1.04701 -J right_e0 -0.00123203 -J right_e1 0.49262 -J right_w0 -0.0806423 -J right_w1 -0.0620532 -J right_w2 0.0265941 -J left_s0 0.192483 -J left_s1 1.047 -J left_e0 0.000806359 -J left_e1 0.491094 -J left_w0 -0.178079 -J left_w1 -0.0610333 -J left_w2 -0.0124707

This should start baxter with no potential energy in its joints (arms down), but instead I see Baxter's hands straight out on both sides and they fall when the simulation starts.

[hsu]

Not sure why yet. Calling set configuration through rosservice seems to work after the model has been spawned:

rosservice call /gazebo/set_model_configuration '{ model_name: "baxter", urdf_param_name: "robot_description", joint_names: [ "right_s0", "right_s1", "right_e0", "right_e1", "right_w0", "right_w1", "right_w2", "left_s0", "left_s1", "left_e0", "left_e1", "left_w0", "left_w1", "left_w2" ], joint_positions: [ -0.272659, 1.04701, -0.00123203, 0.49262, -0.0806423, -0.0620532, 0.0265941, 0.192483, 1.047, 0.000806359, 0.491094, -0.178079, -0.0610333, -0.0124707 ] }'

must be something in the spawn service.

Side note, I had to modify your urdf to replace note: --> note and replace tabs by spaces, otherwise, I get these types of errors (line/column might be off from urdf in repo):

$ rosparam load `rospack find baxter_description`/urdf/baxter.urdf /robot_description
...
yaml.scanner.ScannerError: mapping values are not allowed here
  in "<string>", line 34, column 14:
        <!-- note: invisible -->
                 ^

or

$ rosparam load `rospack find baxter_description`/urdf/baxter.urdf /robot_description
...
yaml.scanner.ScannerError: while scanning for the next token
found character '\t' that cannot start any token
  in "<string>", line 34, column 1:
            <!-- note invisible -->
    ^

[dpsolomon]

Was there ever any resolution to this problem?

Could it have been a namespace problem induced by using a urdf to load the model instead of an sdf file?

[dpsolomon]

I take back the namespace comment. Still, was there ever a solution to this?

[hsu]

Hi Daniel,

what version of gazebo are you using? Could be related to this bug below?

https://bitbucket.org/osrf/gazebo/issue/1138/set-joint-positions-in-jointcontroller

John

On Thu, Aug 7, 2014 at 11:54 PM, Daniel Solomon notifications@github.com
wrote:

I take back the namespace comment. Still, was there ever a solution to
this?

—
Reply to this email directly or view it on GitHub
#93 (comment)
.

[davetcoleman]

AFAIK it was never fixed

[dpsolomon]

I'm using the debian version 1.9.5 compatible with ROS hydro. Is there any workaround? Like Dave, I'm just trying to set the initial joint position directly (during roslaunch).

[hsu]

seems to work with gazebo 4.x release. I am testing in branch issue_93_set_joint_position with

roslaunch gazebo_ros simple_arm_world.launch

testing gazebo 1.9 branch next.

[fmessmer]

I made the following observations when trying to use -J arguments with spawn_model:
(Setup: Trusty, Indigo, gazebo 2.2.3-1~trusty, gazebo_ros_pkgs/indigo-devel from source)

The test file in the gazebo_ros_pkgs/issue_93_set_joint_position branch works fine!

Then I tried to use the -J arguments with the universal robot UR5 (https://github.com/ipa-fxm/universal_robot/tree/test_initial_joint_position - this branch is up-to-date with the official indigo-devel branch + -J arguments in the ur_gazebo ur5.launch file).
However, when starting roslaunch ur_gazebo ur5.launch the -J arguments are not applied and the UR5 is still in the "all joints 0.0" configuration.
When I saw that the test files from gazebo_ros_pkgs/issue_93_set_joint_position branch were not using any transmission, had no gazebo_ros_control plugin loaded and no ros_controller started, I removed all that for the UR5 as well - without success. Even starting gazebo in paused mode did not work.
In the end, I "accidentially" ran rosrun gazebo_ros spawn_model -urdf -param robot_description -model ur5 -z 0.1 -J shoulder_pan_joint 0.0 -J shoulder_lift_joint 0.0 -J elbow_joint -0.4 -J wrist_1_joint 0.0 -J wrist_2_joint 0.5 -J wrist_3_joint 0.0 in a separate terminal, although the model was already loaded in gazebo via the launch file - and this "respawned" the model with the -J arguments applied!
Please note, that the arguments in the rosrun command are the same as given in the launch file!

In the end, I added all the transmissions, gazebo_ros_control plugin and ros_controllers stuff again and started gazebo in "running" mode.....after running a second spawn_model, the -J arguments are applied to the robot!

I have not yet investigated further what causes this behavior, but I wanted to document this here!
Can someone confirm this observations?
Any thoughts?

[hsu]

I also noticed that while the simple model worked fine, other models may not work. Maybe a race condition somewhere at start up? Will look into this in more detail.

[fmessmer]

It looks like everything is fine up to https://github.com/ros-simulation/gazebo_ros_pkgs/blob/indigo-devel/gazebo_ros/src/gazebo_ros_api_plugin.cpp#L1472
The -J arguments are handed over to joint_position_map correctly!

[hsu]

I wonder if it's because Model::jointController hasn't been initialized yet when this function is called.

[hsu]

please give gazebo branch set_joint_position_on spawn (c8d353e) a try? thanks.

[fmessmer]

Hmm, the branch seems to work for the test you added.
However, testing it with the universal_robot test-branch running
roslaunch ur_gazebo ur5.launch
doesn't seem to work...maybe there is something more when having transmission in the urdf and controllers running...

[jbohren]

please give gazebo branch set_joint_position_on spawn (c8d353e) a try? thanks.

Is there any way to do something similar for Gazebo 2.2.x?

[jbohren]

Also w.r.t. 99b9dc5, it doesn't always work.

[fmessmer]

I also did some experiments with issue_93_set_joint_position_hack_indigo branch.

It seemes to work (most of the time) for "small" models, e.g. just a manipulator (e.g. Univeral UR5).
However, with a more complex robot like our rob@work (where we have a single top-level launch file that takes care of everything like upload parameters, start gazebo, spawn_model (base, manipulator, sensors), start_controllers and other stuff), the initial config is not considered correctly.

It appears to me that it also depends on the point in time at which the controllers are started...?

[k-okada]

99b9dc5 works for me, This will solve our problem posted on
https://groups.google.com/a/rethinkrobotics.com/forum/#!topic/brr-users/QWITm3lfxvM, thanks!

I'm testing on setting baxter gazebo simulation using baxter_gazebo.install of indigo-devel of gazebo_simulator package on indigo.

[Nurgak]

@ironmig Now I have a strange situation: to illustrate the problem I downloaded the SimpleScreenRecorder program to show what happens, every time I run the simulation without SimpleScreenRecorder recording the rover flies away, but while I'm recording everything behaves normally and the rover falls as expected.

I thought it might be related to the 4 CPUs being a bit more busy than usual, so I downloaded the stress program and found out as long at least 2 CPUs were busy the rover stayed put. Perhaps it can be some obscure race condition that I have.

[kev-the-dev]

Have you updated your ROS install lately? Ran stress on all my cores and still cannot get this issue to occur (kinetic, gazebo 7.13 now).

[Nurgak]

@ironmig I had issues as long as nothing else way hogging the CPU, if you don't have this issue without stress test then you won't have it with stress either. My ROS installation Kinetic and Gazebo 9.

[felixvd]

A bit of a limp comment, but I can second @Nurgak's experience. I just had to change my gazebo node to start up paused in order to have the -J argument work, otherwise it would fail as described.

[jacknlliu]

I tried the previous method #93 (comment), but it doesn't work for gazebo 9 and bullet physics engine. And it works for gazebo9 with ODE or dart physics engines.

I think this issue is something about gazebo. We have some discussions at gazebo.

[josephcoombe]

I experienced this issue with ROS Kinetic and Gazebo 7 (ros-kinetic-desktop-full version).

Occurs on very large model (hexapod) for both paused and unpaused starts.

---

My workaround was to wait until Gazebo had finished loading and then run rosservice call /gazebo/set_model_configuration to set my desired initial joint angles.

[m-talha]

Is there any solution in sight for this? It's still occuring on Kinetic+gazebo7.

Any idea how to make sure it just jumps to the new configured initial pose instead of "moving" to the new initial pose? I've been monitoring this problem for many years now and finally we have something closer to a temporary solution.

@littlejohnyang Did you manage to resolve this? I also want the robot to be able to snap back to position.

[musamarcusso]

what is the Gazebo version you are using? This worked for me when I updated Gazebo 7 to 7.15 after adding the mirror. On Gazebo 7.0.0 it really didn't work for me.

[m-talha]

@musamarcusso I am using Gazebo 7.15. What worked for you exactly? I have got the workaround working to reset the robot to a position following littlejonyang's method but it is not snapping to position.

And what do you mean by mirror?

[musamarcusso]

The mirror would be

sudo sh -c 'echo "deb http://packages.osrfoundation.org/gazebo/ubuntu-stable `lsb_release -cs` main" > /etc/apt/sources.list.d/gazebo-stable.list'

then I updated Gazebo. For some reason only then 7.15 was installed.

The way it worked for me was to start Gazebo with the physics paused and spawn the robot (I named it the_robot below). The important thing was to add the -unpause option in order to have the joints snapping into position and add the name of the name of the robot as the_robot:: as a prefix to each joint.

<node name="spawn_urdf" pkg="gazebo_ros" type="spawn_model"
    args="-param robot_description -urdf -unpause $(arg some_start_pose) -model the_robot -J the_robot::joint_1 -1 -J the_robot::joint_2 -2 -J the_robot::joint_3 0.75 " />  

[m-talha]

Thanks for that but I already have the initial pose working. However, my robot is teleoperated and I want the user to be able to reset it to the initial pose when it gets stuck (e.g. singularity etc.). And I want it to snap back into position without any dynamics involved.

[musamarcusso]

ah, you mean resetting the simulation completely or kind of re-spawning?

[m-talha]

Similar to that but ONLY the robot for now.

[anubhav1772]

I experienced this issue with ROS Kinetic and Gazebo 9 (ros-kinetic-desktop-full version).. @musamarcusso your solution initially worked, but it started showing strange behaviour again.

[anshulpaigwar]

  <node name="spawn_gazebo_model" pkg="gazebo_ros" type="spawn_model" args="-urdf -param robot_description -model robot 
              -z 0.0
              -J elbow_joint 1.001
              -unpause
              " respawn="false" output="screen" />

-J command not working in Gazebo 9 and ros melodic

[TheDash]

I find it hysterical 8 years later a bug like this still exists lmao.

[corot]

I didn't read all the previous comments, but -J works for me on current gazebo9 + melodic. This is my spawner:

  <!-- Gazebo model spawner -->
  <node name="spawn_turtlebot_model" pkg="gazebo_ros" type="spawn_model" output="screen"
        args="-urdf -param robot_description -model thorp
              -x $(arg initial_pose_x)
              -y $(arg initial_pose_y)
              -Y $(arg initial_pose_a)
              -J arm_shoulder_pan_joint 0.0
              -J arm_shoulder_lift_joint 0
              -J arm_elbow_flex_joint 2.2
              -J arm_wrist_flex_joint 1.4
              -J gripper_link_joint 0.0
              -J cannon_joint 0.0
              -unpause"/>  <!--  we spawn arm model on resting state -->

[anshulpaigwar]

I figured out the issue, in order for -J command to work we need to launch the Gazebo simulation paused so that physics is off. Then use -unpause flag with the spawner to turn on the physics.

  <arg name="paused" default="true" doc="Starts gazebo in paused mode" />

  <include file="$(find gazebo_ros)/launch/empty_world.launch">
    <arg name="world_name" default="worlds/empty.world"/>
    <arg name="paused" value="$(arg paused)"/>
    <arg name="gui" value="$(arg gui)"/>
  </include>

  <node name="spawn_gazebo_model" pkg="gazebo_ros" type="spawn_model" args="-urdf -param robot_description -model robot 
              -z 0.0
              -J shoulder_lift_joint -1.57
              -J elbow_joint 1.001
              -unpause
              " respawn="false" output="screen" />

Though the -J argument work, it does not work properly! On certain joint values robot just start jiggling. I had to do a lot of trials to find out joint values such that the robot doesn't jiggle on unpausing the simulation.

[rcywongaa]

I'm convinced it is a race condition. With the exact same launch file, 1 out of 10 times, -J fails. It seems to happen less frequently when the computer is heavily loaded or when using a slower PC.

[mintar]

Yes, I also believe it's a race condition. I wouldn't recommend using the -unpause argument in the spawner, especially when spawning multiple objects. The only thing that works reliably for me is to start Gazebo paused, wait for everything to finish spawning, and then manually unpause Gazebo (by clicking the "start" button in the Gazebo GUI, or rosservice call /gazebo/unpause_physics).

[the-raspberry-pi-guy]

Also come across this bug when trying to state an initial position of a dual-arm robot with -J tags. Works correctly when setting pause to true, and then starting the simulation using the start button in the Gazebo GUI as @mintar suggests. Thank you!

[sccashma]

Is the above currently the best solution for this issue or can anybody point me to a more reliable fix/solution?
Gazebo 9/Melodic

[the-raspberry-pi-guy]

@sccashma as far as I am aware the only reliable solution to this problem is by using the pause/unpause. Also on Gazebo 9/Melodic. This is an open issue from 2013, so I don't think there is going to be a reliable fix anytime soon.

[DangMinh24]

Is there any update to this? Pause/Unpause approach does not work on Gazebo9/Kinetic.

[DangMinh24]

My bad. Pause/Unpause method actually works on Gazebo9/Kinetic environment