Gazebo HITL not working

so the battery parameter issue still exists, is this causing an AUTODISARM?

For some reason, the Led I/O B/E is flashing red which apparently does’t connect to the vehicle as shown in qgroundcontrol

@bperseghetti Any chance you have any insights?

@cschindlbeck can you list your FCs “changed” params, specifically hil_enable and sys_autostart, firmware version, QGC version, model you are trying to run in sitl_gazebo, the way you are connected from computer to FC, how you are launching it, commit sitl_gazebo is on for you, ubuntu version, gazebo version, and any other possible details.

i bought a new pixhawk, i still get the red flashing I/O

  • SYS_HITL is set to HITL enabled
  • SYS_AUTOSTART is set to 1001
  • Only box UDP is checked in
  • sitl_gazebo model is (at commit 0da08f0333cd14c08a9545c6ba7ddfc18706398f)
  • computer is connected to FC via USB, ubuntu is 18.04, gazebo version is 9.16.0, QGroundControl is 4.0.11

My launching process:

  1. gazebo Tools/sitl_gazebo/worlds/
  2. Connect FC via USB
  3. Start QGroundControl

Then it says Waiting for Vehicle Connection and the I/O led is flashing red

@cschindlbeck does QGC recognize the FC when it is plugged into USB and the “pixhawk box” is clicked in QGC? What version of firmware is it on? Is the FC an FMUv5? I would recommend in the future:
1.) Connect FC via USB
2.) Start QGroundControl (should not connect or see anything if only the UDP box is selected)
3.) gazebo Tools/sitl_gazebo/worlds/ (note that the iris world has been removed from more recent firmware/sitl)
4.) Should now show up in QGC

If using more recent firmware and sitl there is a as of commit b02899.

I would suggest moving your Firmware forward, then build it, flash it to your FC, set SYS_AUTOSTART to 1001 or 4001 (has RC AUX pass through), and check all params in QGC – lastly make sure QGC is then set to UDP only, then:
1.) Connect FC via USB
2.) Start QGroundControl (should not connect or see anything if only the UDP box is selected)
3.) gazebo Tools/sitl_gazebo/worlds/
4.) Should now show up in QGC

@bperseghetti Thank you for your time, with and updating sitl_gazebo to master, the HITL is running…
However, the quadcopter exhibits erratic behavior, i guess the rotors are off from where they are supposed to be so it crashes after arming it…
Anyway, that is something that probably should be continued somewhere else…thanks!

Were you able to find any sort of solution to the erratic behavior? I have the exact same config, ubuntu 18.04, QGC 4.0.11 and Gazebo 9.16.0. I found this thread after following the instructions here:, which do not work anymore, as no drone is spawned in… luckily, running now spawns a drone. When the drone takes off however, i see the same erratic behavior. Immediately doing a barrel roll and falling to the ground. Any known remedy for this?

I too am running into the issues that @jmalbert and @cschindlbeck are running into in regards to erratic behavior with the drone. Does this have to do with the iris model? I assume it has to do with the joint PID controllers but havent figured out how to solve it.

The erratic drone problem was due to the rotor links not being properly placed on the iris_hitl.sdf model. I went into the iris.sdf and copied over the proper rotor link positions and the drone looks like it has the propellors and rotors running properly now.

My main issue now is that when I try to arm and have the drone takeoff , the gazebo console log starts showing a “tx queue overflow” message repetitively. This causes the drone to not takeoff because it loses global position data.

I have followed all the steps from, and can confirm I am using the same firm and tools like @cschindlbeck. I also start up the HIL system like @bperseghetti mentions on how to start it up. Finally I have looked into this “tx queue overflow” issue on forums and have not really been able to figure out why this might be happening. I believe QGC is using the serial connection (instead of the UDP one) to get the drone to takeoff, but I am not sure why it would be doing that. Any insights would be great.


Try to change in the file “” value “real_time_update_rate” to 100 …150.

1 Like

Hi, I am following the instructions in and I see a lot of references to iris, but I don’t see anything about the specific firmware for iris to load to pixhawk. Is the default px4 firmware tuned for iris?


For the erratic drone problem, after you followed all the steps from (Hardware in the Loop Simulation \(HITL\) | PX4 User Guide), then copy Tools/sitl_gazebo/worlds/ and rename it to Open the new .world file and find:


modify to:


save and reboot the gazebo, you’ll find that everything works.
@jmalbert @cschindlbeck

Hey, I’m experiencing some strange behavior in HITL mode, I get no global position, and baro #0 failed warnings. Iris wont takeoff in simulation (only spin its rotors) and in the QGC it prints some random numbers of height and vertical speed.

Any idea what is going on?

I have set up everything from the official guide Redirecting to latest version of document (main). I see the model in the gazebo, also I see px4 in QGroundControl.

When I arm the drone, the rotors do not start (no takeoff when forcefully instructed also). Can anybody please help me solve this?

I have a similar problem described here

So I am using px4-fmuv2, and unfortunately in this case pwm_out_sim is commented out in the file
PX4-Autopilot/boards/px4/fmu-v2/default.cmake. So uncomment this and you can see the rotors spinning after arming the drone in QGS.

Have anyone solved the erratic behaviuo shuch as BARO #0 failed: TIMEOUT! , MAG #0 failed: TIMEOUT! and GPS Disabled, I was able to succesflly settup PX fmu-v5 after changing <real_time_update_rate>50</real_time_update_rate> in .world file , I am using PX4 1.12.3. please advise ?

Hello dear @Hari_Krishna
I am facing the same issue. When I arm the drone, the rotors do not spin.
Pixhawk 4 with firmware v1.13
QGC v2.4.2
Can you help me with my problem? thank you in advance


I tried that, not working, do you have any other solutions?

Try reselecting a different control allocation method under Parameters → Geometry. For me, I have to switch this parameter between “pseudoinverse with sequential desaturation” and “Automatic” every time I start a new HITL simulation.