3D Robotics

Using ROS Gazebo simulator with ArduCopter

The future of robotics development, including drones, is powerful simulation, which makes it possible to achieve faster development and better performance by reducing the "trial and error" process of testing everything with physical machines. The Dronecode projects have long used a number of powerful drone-specific simulators, including both "hardware-in-the-loop" (HITL) and "software-in-the-loop" (SITL) programs. 

But as drone simulation goes beyond simply simulating the drone itself and extends to simulating an entire robotic system, including swarming, pathfinding, environmental awareness and autonomous mapping and navigation without GPS, you need even more powerful tools. 

The gold standard for advanced robotics simulation is the ROS/Gazebo package, which is now supported by ArduPilot as part of the Dronecode project (ROS is the Robot Operating System, created by the Open Source Robotics Foundation, which is part of Dronecode).

The APM Dev wiki now has a great page on how to use it. Here's a sample, but click through for the whole thing.

ROS and Gazebo are a well-known and respected robotics framework and simulator:

  • The ROS framework contains many “packets” of software for performing robotics tasks. It allows you to model the environment (including indoor environments with walls, doors etc) and run your own control algorithms for autonomous flight.
  • Gazebo supports several different Copter models (at time of writing there are 6 URDF models in the rotors_simulator package). These can be extended to include support for additional sensors and other behaviours.
The ROS/Gazebo is particularly useful for defining autonomous indoor flights.

This article shows how you can replace the default SITL Copter simulation with one supplied by Gazebo and control the autopilot using the ROS framework (instead of Mavproxy or some other Ground Control System).

An architectural overview of how ROS/Gazebo integrate with SITL is shown below:

Architecture Diagram: Using SITL with ROS and Gazebo

E-mail me when people leave their comments –

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

Join diydrones


  • Good evening Patrick,

    Sorry for not getting back to you about your message from the 14th sept.

    I think I understand what you are trying to do.
    However I have not heard of anyone yet attempting HITL with Gazebo as simulator.
    And I have not tried out yet the HITL simulation.

    Which autopilot software runs on your Pixhawk ? PX4 or Ardupilot ?

    About your second message:

    Were you running the following command ?
    sim_vehicle.sh –v ArduCopter -f arducopter_sitl_ros --console
    If not please post yours.

    I am running ArduCopter's version of Alex Buyval (the one automatically downloaded by the script step_3), which is a slightly modified version of ArduCopter from August. Just to be sure, in sim_vehicle.sh, your line 314 is "pushd $VEHICLEDIR || {", right ?
    And near the end of file, line 456, there are these lines:

    case $FRAME in
        sleep 999999

    right ?

  • This looks awesome! So can you somehow incorporate the dronekit-python code for simulation in ROS/Gazebo at the moment?

  • Aurelien,

    I went through your setup from the PDF instructions on your github page and I actually can't seem to get the regular sim_vehicle.sh to run. I get the "Connection Refused', 'sleeping' message that you mentioned in the instructions, but I get it with both ArduCopter and ArduPlane. Any suggestions? I'm not sure what other information may be useful to you.

    Also, when running the default sim_vehicle.sh script, I always get a "dirname: missing operand" error on line 314. Basically, it isn't taking in the vehicle operand. When I hard-code line 314 to be VEHICLEDIR="$autotest/../../ArduPlane", it seems to work, but then I get the connection refused I mentioned above. 

  • Aurelien, thanks for your help. For my purposes, I think I have the SITL simulation working. However, I eventually need to use the actual Pixhawk hardware in a similar fashion to the setup described in this article. I know at some point (I can't remember when, exactly) this functionality was possible.  

    I know it is possible to have the Pixhawk integrated with Gazebo/ROS to drive the simulation. Setups similar to the following: https://pixhawk.org/dev/offboard_control/testing are great, but I unfortunately do not have the luxury of flying an actual vehicle. Has anybody used the actual Pixhawk in a HITL setup with Gazebo/ROS? 

    My setup is as follows:  

    1) Gazebo simulates the quadrotor and environment.

    2) The Pixhawk is connected to the Gazebo environment via ROS.

    3) Gazebo publishes sensor information (i.e. IMU, any camera/LIDAR data, etc.) to the ROS network

    4) A middleware subscribes to the sensor topic from Gazebo and packs the relevant information into MAVLINK messages, then sends those out for the Pixhawk to receive.

    5) The Pixhawk then takes the sensor data (e.g. IMU data) as inputs to its controller and computes the necessary motor commands (whether that is PWM or RPM directly, I still haven't figured out).

    6) The middleware from step 4 is also subscribed to motor commands MAVLINK message (again, either PWM or RPM) and then packs the necessary data into a motor speed command that is published into the ROS network.

    7) The quadrotor in the Gazebo environment then responds to those motor commands, and the IMU/other sensor data is sent back, completing the loop.

    So far, I have the Gazebo environment set up with the quadrotor and responding to simple joystick commands to make sure I have the right commands. I am currently working on the middleware that will subscribe to the IMU data and then pack that up into a MAVLINK message. I still also need the Pixhawk motor commands based on the controller output subscriber and subsequent publisher. 

    Does anybody know of any similar setups? Or if this is even possible? Any help would be greatly appreciated.

  • Alejandro,

    I just published a small commit on the scripts (minor addition for Linux users who skip the step_2). Let me know if the scripts ran smoothly or if you encountered any problem.

    At the beginning I was using VMware on Windows. But like you said I finally installed a native Ubuntu in dual boot to get a higher frame rate on Gazebo.

    sim_vehicle.sh does run, however not smoothly.
    Using MavProxy on the side (to display the map and send commands), there are frequent connection failures of a few seconds, Mavros which waits to receive about 500 unknown parameters, there is a repetitive Floating Point Exceptions coming from somewhere in ArduCopter's code (trying to track it with -G), and I haven't yet manage to make the joystick work...
    If you manage to solve any of these problems, I will gladly hear your advices.
    (the regular SITL simulation with sim_vehicle.sh works fine)

    PX4 simulations can be launched (using the MAVROS repository from PX4, not the modified Ardupilot version), but I haven't yet tested them with the PX4 autopilot.

    Side note:
    For the joystick, I also modified "/dev/input/js1" into "/dev/input/js0" in teleop.launch in folder mavros/mavros_extras/launch.

  • Patrick, Aurelien thank you for sharing your setups. I will try one more time from scratch using Aurelien's scripts.

    Tell you later.

  • Patrick,

    Maybe you did not run into the same problem, but to be able to run the gazebo_iris_outdoor_world.launch simulation, I had to follow the hacks from :


    Because Gazebo could not locate the heightmap file in the packages.

    Gazebo simulator: investigate why the outdoor world does not launch on ubuntu · Issue #1683 · PX4/F…
    The outdoor_world currently seems to work on arch linux only. empty_world works fine on all systems. Symptoms: gazebo starts but can't find some…
  • Good morning everyone,

    Like you I think the Gazebo simulation is an excellent idea, so I followed the ardupilot dev wiki page on it.

    While most of it is exact, there are a few commands missing, and for the moment it requires Alex Buyval's version of Ardupilot (because his work on sim_vehicle.sh and the SITL source libraries have not yet been merged to the trunk). Nethertheless Alex did a great job coding all the interface.

    Since I am on Windows, and I used on VMWare a new virtual machine created just for the occasion, it required me to setup the whole environment from scratch. So I think I covered all dependencies (you already provided most of them Alejandro, except I did not need 'control_toolbox' and 'realtime_tools', but maybe they are needed later for more control/analysis of the simulation?). And finally the sim_vehicle.sh works.

    For an easier installation, gathered all the commands in shell scripts, and wrote a tutorial. They are available on:

    Github with a tutorial and scripts to setup SITL ros-gazebo for Ard...l

    There is still one missing dependency, 'gflags_catkin' for 'glog_catkin' package. But it does not disrupt the compilation.

    Hopefully it will help you.
    Feel free modify the scripts or tutorial, or report me errors you have encountered with them.

    Tutorial for the setup of ROS Gazebo SITL for Ardupilot - AurelienRoy/ardupilot_sitl_ros_tutorial
  • Alejandro,

    I also had similar issues getting this to work out of the box. I eventually got it to work by using a combination of the repositories listed in the article (from http://dev.ardupilot.com/wiki/using-rosgazebo-simulator-with-sitl/) and the PX4 article for ROS SITL Setup (from https://pixhawk.org/dev/ros/sitl). 

    As a general note, I have actually never been able to get the sim_vehicle.sh script to work, but my simulation runs fine.

    First and foremost, unless I am missing something fundamental, the commands listed in the "Cloning the necessary ROS packages" section of the "Using ROS/Gazebo Simulator with SITL" article don't seem to be 100% correct. Mainly, the last line should be broken up after the first "src". Starting at "rosdep", that should be its own command. After running those commands, I installed the extra dependencies that you listed above, however I installed them according to the second link I provided (https://pixhawk.org/dev/ros/sitl). One dependency that I needed that you do not have listed is the PX4/Firmware.git repository.

    With this setup, I was able to run the rotors_gazebo launch files and the px4 launch files, like so:

    roslaunch rotors_gazebo iris_outdoor_world.launch

    -- and--

    roslaunch px4 gazebo_iris_empty_world.launch 

    Note that some of the launch files don't load all URDF files that they are looking for, and that is most likely due to incompatibilities with the repositories from both approaches that I linked above. I admit this isn't the cleanest setup, but it works for my purposes. Feel free to message me or comment if you would like any further details on my setup.

    My ultimate goal is to get a Hardware in the Loop (HWIL) setup. Unfortunately, with the latest updates, the HWIL with ArduCopter seems to be broken. My end goal is to essentially have the SITL setup, but for HWIL. So a Pixhawk could send motor commands (either PWM or RPM directly) into ROS/Gazebo, similar to this SITL setup. Then the ROS/Gazebo environment could feed back into an actual Pixhawk to evolve the state according to the simulated motion.

    Chris, is there any timeline for fixing/adding the HWIL support with ROS/Gazebo? Ultimately, I would like to have multiple Pixhawk autopilots all talking with ROS/Gazebo in a hardware in the loop environment. I am currently trying to "hack" my way through it using the SITL setup as a starting point, but its proving to be more difficult than originally anticipated.

  • Seems like alexbuyval's mav_comm version is different from https://github.com/ethz-asl/mav_comm

    Mar 19 they renamed CommandTrajectory to CommandTrajectoryPositionYaw at pull #14


    I did try downgrade ethz-asl/mav_comm to v1.0.0 where CommandTrajectory wasn't changed yet... but it triggers a new set of compilation fails.

    So I give up... I need alexbuyval's mav_comm in order to continue

    So many hours trying... :(

    This repository contains message and service definitions used for mavs. All future message definitions go in here, existing ones in other stacks shou…
This reply was deleted.