Rosanswers logo

I'm using the hector_quadrotor package, and tyring to simulate in gazebo. The simulated bot does not respond to commands over cmd_vel, from command line (rostopic pub), from a custom keyboard teleop node, or even from rosrun hector_quadrotor_controller test_trajectory.

I'm launching gazebo and spawning the drone using

$ roslaunch hector_gazebo_worlds rolling_landscape_120m.launch
$ roslaunch hector_quadrotor_gazebo spawn_quadrotor.launch 

I'm sure it's something simple I'm overlooking, but help would be appreciated!

Edit: further tests show that cmd_vel does nothing with

$ roslaunch hector_quadrotor_gazebo quadrotor_empty_world.launch
$ rosrun hector_quadrotor_controller test_trajectory


Originally posted by DavidMillard on ROS Answers with karma: 1 on 2013-01-28

Post score: 0

Original comments

Comment by SL Remy on 2013-01-28:
Hello David, two questions: What operating system are you using? How did you install hector_quadrotor?

Comment by DavidMillard on 2013-01-28:
I'm using Ubuntu 12.04; I installed from ROS binary repositories. Of note: plenty of other ROS and gazebo packages work great with this install and with cmd_vel. I checked out hector_quadrotor from svn and then ran rosmake on it.

Comment by felix k on 2013-01-29:
Have you verified via rxgraph that gazebo is actual connected to that exact topic? Alternatives: rosgraph, rosnode info and roswtf.

Comment by Johannes Meyer on 2013-01-29:
There was a small bug in the hectorgazeboplugins package introduced in r811 yesterday at 18:26 MEZ, that caused nan values in the Imu message for the first simulation step, leading to the effects you described. Height control should not have been affected. Could you try again with r814, please?

Comment by DavidMillard on 2013-01-29:
Testing with r821, still nothing works. I tested with roslaunch hector_quadrotor_gazebo quadrotor_empty_world.launch rosrun hector_quadrotor_controller test_trajectory The drone does not move in any direction. Also, via rxgraph, gazebo is connected to the correct topic. Edit: same with r814

Comment by Johannes Meyer on 2013-01-29:
Which repository URL did you use? We merged the fuerte branch in /branches/fuerte back to /trunk a couple of weeks ago. Unfortunately the wiki still shows the old URL, although the documentation index has been updated. However, both versions should be okay.

Comment by Johannes Meyer on 2013-01-29:
I just noticed that the USE_PROPULSION_MODEL cmake option in package hector_quadrotor_gazebo was enabled by default. If you have Matlab installed, this option will switch to a more complex control mode also simulating the motor dynamics, but currently will not work without additional plugins/nodes.


1 Answer 1


Rosanswers logo

There are several possible reasons for the symptoms you describe:

  • At least one of the required Gazebo plugins has not been loaded for some reason or could not parse its parameters from the URDF description. You should check the console output if there are error messages that could serve as a starting point. Also check that /cmd_vel is published correctly using rostopic echo /cmd_vel and that gazebo subscribes to this topic rostopic info /cmd_vel.

  • There might be NaN values for some reason in a message the controller plugin uses to calculate the required thrust and torques. You can check this easily with rostopic echo. Using the default configuration, the relevant topics are /ground_truth/state and /raw_imu. (Note: There was a bug introduced in revision 811 and resolved in revision 814 that caused the IMU plugin in hector_gazebo_plugins to publish NaN values for the first timestep, which are fed through to the torque output due to the integrators in the controller.)

  • Make sure to NOT use the propulsion model plugin in package hector_quadrotor_controller as for now. This plugin requires an installation of Matlab with Matlab Coder to compile successfully, and when the binary is found, the cmake scripts in hector_quadrotor_gazebo will add it to the quadrotor URDF instead of the simple controller plugin. The propulsion plugin requires motor voltages as input and does not react on /cmd_vel directly. We bridge this gap by running our onboard software running in Orocos RTT with ROS integration, which is not (yet) available in the repo. When the propulsion model is enabled without a running controller, the quadrotor will just fall down and stay on the ground. Without the plugin it is not really possible to touch down, as the simple controller will always produce a certain thrust required to compensate gravity. When no commands are received, the quadrotor will hover a couple of centimeters above ground and slowly drifts away due to IMU noise and numerical inaccuracies.

You can disable the propulsion plugin with the command

 roscd hector_quadrotor_gazebo/build && cmake . -DUSE_PROPULSION_MODEL=OFF
  • If you are using ROS fuerte, you should first try to install hector_quadrotor from the package repository instead of doing a source installation:
 sudo apt-get install ros-fuerte-hector-quadrotor

We expect to release a new version of the stack for fuerte and groovy as soon as some problems with the new Gazebo version (e.g. spawning at the wrong position) have been resolved.

When checking out the SVN version directly, make sure to use the /trunk version to also get the latest updates. Unfortunately the wiki page is still showing an outdated URL in /branches/fuerte for ROS fuerte (see this question).

Originally posted by Johannes Meyer with karma: 1266 on 2013-01-30

This answer was ACCEPTED on the original site

Post score: 1

Original comments

Comment by SL Remy on 2013-01-31:
Using groovy and r826 (rosmake with no parameters set), I've been able to spawn a quadrotor and control it with cmd_vel. (confirmed visually with image from front_cam and with odom)


Your Answer

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