Rosanswers logo

With the latest update to the Gazebo package in the ros-fuerte-simulator-gazebo (=1.6.12-s1344941353~precise), the indoor_slam_gazebo.launch and outdoor_flight_gazebo.launch in hector_quadrotor_demo cannot be controlled on the x or y axis with the /cmd_vel topic. Previously, publishing linear x/y twist messages on this topic would correctly command the model to move. However, the z-axis linear twist still works as expected.

We are using the fuerte branch: http://tu-darmstadt-ros-pkg.googlecode.com/svn/branches/fuerte on Ubuntu 12.04.

Most of the error messages are not very helpful. The indoor_slam_gazebo.launch does produce the message:

Warning [parser.cc:348] Gazebo SDF has no gazebo element
Warning [parser.cc:291] DEPRECATED GAZEBO MODEL FILE
On July 1st, 2012, this formate will no longer by supported
Convert your files using the gzsdf command line tool
You have been warned!

This question also references a possible issue with the URDF files, but gzsdf is not included in the gazebo tools (/opt/ros/fuerte/stacks/simulator_gazebo/gazebo_tools/).

The indoor_slam_gazebo.launch also starts in paused mode now, when it previously started in play mode.

Answer: Using the older version of gazebo (ros-fuerte-simulator-gazebo=1.6.10-s1342505104~precise) fixes this problem.

Edit: This issue is resovled as of revision 521 on the Fuerte branch.

Originally posted by sethrylan on ROS Answers with karma: 1 on 2012-08-14

Post score: 0

Original comments

Comment by Johannes Meyer on 2012-08-14:
I am using the current version 1.6.12-s1344271816~precise of ros-fuerte-simulator-gazebo and cannot reproduce your problem.Could you upgrade to this version and try again? Also make sure that the axes are configured correctly in the hector_quadrotor_teleop launch file for the case you use teleop.

Comment by sethrylan on 2012-08-15:
Thanks. I've updated to current, but we are publishing to /cmd_vel from a custom controller node rather than using the hector_quadrotor_teleop package. I can even manually publish the Twist messages, but the odometry data from Gazebo remains 0 on the x and y axis; the z-axis does behave as expected.

Comment by hsu on 2012-08-29:
regarding gzsdf, I ticketed myself (https://code.ros.org/trac/ros-pkg/ticket/5544) Can someone try 1.6.14 and see if problem still persists?

Comment by Johannes Meyer on 2012-09-05:
"rosrun gazebo gzsdf help" fails with Error [SystemPaths.cc:237] cannot load file [sdf/gazebo.sdf]in GAZEBO_RESOURCE_PATH in ros-fuerte-simulator-gazebo 1.6.14. Is there a mechanism to set this environment variable in ROS-based installations?

Comment by SL Remy on 2012-09-05:
Same dynamics for me with 1.6.14 (from debs). It also appears that while the velocity_command_. does change, the force and torque does not get updated. This maybe related to inertia for the body being zero but I'll have to wait until the next coding window to explore this.

Comment by hsu on 2012-09-05:
to run gzsdf in ros based environments, source [path to simulator_gazebo]/gazebo/setup.bash

Comment by hsu on 2012-09-05:
@trinighost where are you finding that "the force and torque does not get updated"?

Comment by SL Remy on 2012-09-06:
I added ROS_INFO_NAMED("quadrotor_simple_controller", "Force: [%g %g %g], Torque: [%g %g %g]", force.x, force.y, force.z, torque.x, torque.y, torque.z); to GazeboQuadrotorSimpleController::Update() which is in quadrotor_simple_controller.cpp


1 Answer 1


Rosanswers logo

There was a bug in the simple_controller_plugin urdf file in the fuerte branch as a consequence of moving the plugin to the hector_quadrotor_controller package and merging some updates from the electric branch in /trunk. It was introduced in r522 on Aug 30 and should be fixed in r558 from Sep 5.

As Gazebo 1.0 does not parse plugin parameters in subtags (one for each PID controller involved) anymore, the control parameter tags have been renamed during the conversion to fuerte. As the default value for all control parameters is zero, the quadrotor does not move if the parameters could not be parsed correctly.

As this question was asked on Aug 14 I did not consider this issue to be the reason for the original problem. However, the effect seems to be nearly the same. On the other hand, if all control parameters are zero, this should affect all axes and not only the x and y.

Please check if your problem still exists with the latest revision from the repo. I am sorry for the inconvenience.

Note: The hector_quadrotor_demo package was moved to a new stack hector_quadrotor_apps to avoid a dependency of hector_quadrotor to the hector_slam stack in preparation of the release in the ROS package repositories. Although not really related, it might lead to some confusion if only the hector_quadrotor stack has been checked out.

Originally posted by Johannes Meyer with karma: 1266 on 2012-09-06

This answer was ACCEPTED on the original site

Post score: 2

Original comments

Comment by SL Remy on 2012-09-06:
Seems like more noise has been added to the model, but it is working.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.