New ArduPilot plugin for Gazebo

Gazebo is a real time physics simulator with many promising features for the simulation of the next generation of UAVs, self-aware of their environment.

As presented on previous posts, especially from the ASL team from ETH Zurich who interfaced PX4 with Gazebo, from Alexandr Buyval who posted the first interface for ArduCopter, or from Patrick Nolan, Gazebo offers the simulation of a variety of sensors. It includes models of ultrasound range finders, cameras, lidars, stereo cameras, etc. These combinations make Gazebo well suited to simulate indoor flights or close to obstacles.

Gazebo runs along ROS (Robot Operating System) which is a software framework containing libraries for message-passing, package management, visualizers, device drivers, etc.

This update fully restructures in "C++ the Ardupilot – ROS/Gazebo” plugin interface in order to bring out:

  • an improved simulation stability and deterministic UAV response (step lock mechanism) ;
  • a simplified ROS/Gazebo simulation launch, fully configurable through arguments to the well-used SITL launch script, ;
  • integration of the GPS sensor provided by Hector's plugin ;
  • the simulation of ArduPlane, with a Cessna model provided as an example for custom fixed-wing designs ;
  • a georeferenced overlay map image on MavProxy, to better assess the UAV position relative to its simulated environment ;
  • a new custom mode, Wall Follow, for precise distance control to vertical surfaces, as an example of new sensor use on Gazebo ;
  • a safeguard parachute, releasable by the autopilot

With this update we hope the Ardupilot ROS/Gazebo SITL will have achieved a high enough stability and ease-of-use to become a common simulator for all phases of the engineering V-model:

  • prototype new designs for specific applications, and virtually test various combinations of sensor payloads and flight modes before moving to real hardware ;
  • debug in real-time Ardupilot, and even the communication between Ground Stations and the autopilot ;
  • ultimately validate functions are well-behaved.

Besides conception usefulness, the ROS/Gazebo SITL simulator is also very helpful for new pilots to train on RC piloting, or for veterans to hone their skills in parameter tuning.

Next step would be to interface DroneAPI's code with ROS/Gazebo topic messages, as well as the simulation launch mechanism, to be able to run custom DroneAPI image processing codes over Gazebo camera frames. By achieving this, the SITL would close the loop of UAV system simulation.

In conclusion it is a great test bench for all the cool new functions and flight modes of the community!


All source codes are available on our Github: branch wall_follow branch wall_follow branch map_overlay


Aurélien ROY


from InventUAV


Additional details:


The step lock mechanism enforces a pause of the Gazebo simulation until it receives the next motor command from Ardupilot. It then steps forward the simulation by 2.5 ms (for the 400 Hz update rate on Pixhawk hardware) and sends back new sensor measurements to Ardupilot. Unlike many controller simulations on Gazebo, Ardupilot is the master of the simulation clock.

This solution prevents Ardupilot from missing time steps when running on slow computers, thus improving the overall stability. Among other benefits, the debugging of Ardupilot is much easier: when its execution stops at a breakpoint, the simulation automatically stays on a standstill.

3689674841?profile=originalAmong discomforts, in simulations with ground stations maps, you cannot properly assess the UAV position relative to its surroundings. This issue is now solved, at least for MavProxy, with the possibility to overlay a georeferenced map image. The image file path is specified as argument to MavProxy, by the SITL launch script, with the simulation start location defining the image's center geolocation.


Unfortunately the Gazebo orthographic projection camera, which would be much useful to create maps from screenshots, only arrives in Gazebo 6.0, with the Kinetic Kane ROS version (may 2016).

Parachute release :


In order to stress test safety mechanisms of Ardupilot, a parachute has been modeled and appears when the autopilot activates the release servo. This development leads the way for dynamic model insertion, which can be useful for special actions like saving a lost hiker with an accurate water bottle drop (UAV Outback Challenge 2014).

Wall-Follow Mode :


It is a new mode we conceived for our project's special needs. 

It is an aiding system for pilots making close shots along a structure's surface. All commands are relative to a virtual wall plane, which is similar to the Simple mode. It combines a Loiter controller for the lateral axis (= parallel to the wall), and a distance controller on the forward axis (= toward the wall).

The pilot can freely control lateral movement (roll command), and height (throttle). The wall plane orientation is fixed as perpendicular to the UAV's yaw angle upon entering the mode, and the target distance is a parameter.

To maintain a good behavior even when facing surfaces with holes, or high granularity, the controller includes with a special filtering of frontal range measures, fully configurable through parameters. This way the UAV maintains a straight trajectory, despite gaps.

An equivalent wall-follow waypoint control is underway, for wall planes parallel to waypoint legs.

The development of this feature had to be rushed for the needs of the video. It has not yet been thoroughly tested, and any test on a real UAV should be performed with caution. 

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • I am correct in believing that I could use this code to simulate and test ardurover? That is would be a matter of replacing the gazebo model and setting ardupilot to ardurover mode?
  • Okay, just to follow up with my progress this evening.  It seems as though when I ran the script to install ardupilot from the turtorial, it somehow did not install the correct version.  I was able to delete the installation and used the sim_ros_gazebo branch on AurelienRoy's page.  Then I realized (as far as I can tell) that the ardupilot_sitl_gazebo_plugin he is working on there/describing in this page is different than what is installed via the tutorial (or at least progressed beyond).  I tried to clone the new plugin, but now running the sim via the command indicated in the tutorial loads the console but fails to launch gazebo.  At this point I think I may need to start over and recreate the catkin workspace.  

    Also two notes:  

    1. the need for hector_gazebo gps plugin is still not clearly identified?  Its mentioned in the copy of the article but not linked anywhere?  I found it mentioned in the issues section of the rdupilot_sitl_gazebo_plugin 

    2.  If anyone is having similar problems getting this up and running I the answers to this issue thread very insightful  - filed under closed issues

    Thanks again for any help.  I feel like I'm starting to go in circles perhaps.  Any direction on just getting things up and running would be greatly helpful! 

    UDP ports and Connection off · Issue #1 · AurelienRoy/ardupilot_sitl_gazebo_plugin
    Hello @MaxxUAV and @ AurelienRoy I have read your work with Gazebo and APM in DIYdrones and I think it's really promising. I'm trying to test…
  • Hi everyone,

    First of all, thanks to everyone that worked on this, its seems like a pretty exciting development for future work!.  I am a grad student that found my way into a 700 level robotics course (oops?!), and I hoping to incorporate some of the gazebo sim features along with Google's Project Tango into my term project.  Anyway, I am also having the issue with the "connection refused - sleeping"  that has been mentioned.

     I can get everything up and running okay with the basic mavproxy SITL simulation.  However, once I launch gazebo (it seems to load up just fine), the terminal simply hangs after the line

    "--model arducopter_sitl_ros --speedup=1"  

    and the mavproxy console never opens up.  If I Ctrl-C in the terminal, the sleeping error shows up as it shuts down.  

    I took around in some of the files and found that the SIM_arducopter_sitl_ros.h has the fdm_port defined at 5002,   while the SIM_last_letter and SIM_Gazebo.cpp files have the ports listed at 9002 and 9003 combination.  Should all be the same?  I tried changing the 5002 --> 9002 but no change in the program.  

    Am I missing something?  Is this working as its supposed to and I just don't realize it?  I am fairly experienced on the physical building/flying side of things, but this simulation/coding/linux work is all new to me (Mech Eng student ;).  Thanks for your help!  - John   

  • Moderator
    Which version of gazebo is used? Indigo supports 2 by default. There are gz6 packages for indigo.
  • @Aurelien

    Yaw torque problem looks like a Gazebo version issue (I'm using Gazebo 6.5):

    Fix yaw angle · ethz-asl/rotors_simulator@71c1dde
    Apply torques on the main mav link
  • Hi @NA, @Markus
    While developping it we encountered a situation that may be similar to your problem:
    When the UAV was attempting to make a yaw turn (either in manual or auto mode), it started to wobble with an increasing amplitude until it fell on the ground uncontrollable.
    I just posted a video I made at the time:
    Youtube - simulation bug with rangefinder-heightmap

    In our case it was a problem with the rangefinder and the heighmap (as described on the youtube video description).
    It was happening on the outdoor_village Gazebo world, but not on the outdoor_drcsim.


    However we did not have any problem of no response to small RC4 values (near 1500), outside the dead-zone around trim of course.


    Apart from the above heightmap problem, and if the UAV was well tuned (autotune in the simulation), yaw was behaving well.

    We used Alex Buyval's version of rotors_simulator (branch sonar_plugin), without any modifications.
    I just checked, indeed it did not include the torque commit you found on the parent repo.

  • @Markus  I don't know if this is the same problem you are having but I was using Alex Buyval's version of rotor_simulator and found and issue with that.  The motor plugin used for the rotors only applies torque to the rotor link and not the base link.  The parent version of this repo has the same issue so I cherry picked this commit from its parent repo. Not ideal, but it works. I didn't try installing the ros-indigo-rotors-simulator package because apt-get wants to replace all my Gazebo 6 packages with an earlier version.

    If the developers are following this, I'm curious to know what version of rotors_simulator you're using. Since your package seems to depend heavily on various mods of other repos you might consider adding those as submodules to your repo.

  • Hi Cybernemo,

    If you are using the wall_follow branch of ardupilot, can you try the following launch command: -v ArduCopter -f Gazebo -r empty_world -L Annecy --console --map

  • Hi,

    I installed everything following the tutorial. But when I launch the final command -v ArduCopter -f arducopter_sitl_ros --console

    I get this message from the XTerm console

    [launcher.launch] is neither a launch file in package [arducopter_sitl_ros] nor is [arducopter_sitl_ros] a launch file name

    Did I miss something during installation?

  • @Markus Well, no luck yet.  It's acting as if the physics simulation is ignoring the rotors' angular momentum. The rotors' have a non-zero moment of inertia defined, though, so I can't see why that would be the case.

This reply was deleted.