Gazebo SITL fails with QGroundControl

I’ve created a new aircraft model for which I’ve also created the SITL simulation. The model shows up fine in Gazebo but when I launch QGroundControl, it generates error saying that preflight check failed, it failed to arm, as it reports accelerometer errors and so on.

On the Gazebo command prompt there’s error:
WARN [PreFlightCheck] Preflight Fail: Accel Range, hold still on arming
WARN [PreFlightCheck] Primary accelerometer not found

I’m unable to test my model. Can somebody please tell me how to resolve this issue?


@gkashyap Could you clarify if the default models work? If so, you have something wrong in your custom model. Try to figure out what change you did actually causes the problem

@Jaeyoung-Lim Yes, the default model works. But yesterday, there were errors even with default models. So, I downloaded a fresh copy of px4 software, reconfigured and rebuilt. The default ones work now. Mine still has a problem.
I’ve created the new model based on the tiltrotor airframe model (claire) available in PX4. The only difference is that I have 8 motors of which only wing leading edge motors are tiltable.
The basic sdf is derived from model designed in CAD software. Then the necessary changes were made similar to tiltrotor model. It uses exactly the same plugins.

Is there any specific way of modeling for SITL simulation?

@gkashyap If you have tiltrotors, the acceleration warning seems to be coming from the tiltrotor joint actuation vibration. You might want to check that.

I would suggest that you need to pin point what part of your model file is producing the errors, then it will be easier to find out what the problem is.

@Jaeyoung-Lim I figured that this block


of code was missing in the sdf file. Without this the model was rotating by itself to the right. After adding this block in the sdf, the model now rotates to the left. I don’t understand what this block does.

With this addition, I’m able to arm the aircraft in QGC but I still can’t fly the aircraft even when giving a takeoff command.

Here is the SITL flight log

@Jaeyoung-Lim @Katawan @LorenzMeier Here is my code cloned from px4 code base and updated with my aircraft xe4t
The aircraft is unable to fly in Gazebo, I don’t know why motor 8 (as per toml file) does not spin.
I checked the Mavlink inspector and the outputs are all bizzare.
How should I debug this problem to make it fly?

Can anyone of you provide some clue/help?

@gkashyap I think First you need to check if your motors are wired correctly in the sdf file. check the gazebo_motor_plugin and gazebo_mavlink_interface to see if your motors are all receiving the control commands correctly.

@Jaeyoung-Lim I’ve checked motors a few times, I don’t see the error. In the Mavlink interface I do see the PWM output for the motors. Graphically 8 doesnt show movement.

Here is my code:
Here is the model:

The model is called xe4t.

I’m unable to successfully create a full repository with sitl_gazebo fork because of a git script which fails, so I can’t even share a fully working fork. Here’s the error I get with forked sitl_gazebo which includes my model:
make px4_sitl gazebo_xe4t
[5/561] Generating git version header
FAILED: src/lib/version/build_git_version.h
cd /home/albert/gitgkk/Firmware && /usr/bin/python3 /home/albert/gitgkk/Firmware/src/lib/version/ /home/albert/gitgkk/Firmware/build/px4_sitl_default/src/lib/version/build_git_version.h --validate
Traceback (most recent call last):
File “/home/albert/gitgkk/Firmware/src/lib/version/”, line 41, in
File “/usr/lib/python3.6/”, line 356, in check_output
File “/usr/lib/python3.6/”, line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command ‘[‘git’, ‘describe’, ‘–always’, ‘–tags’, ‘–dirty’]’ returned non-zero exit status 128.
[7/561] Building C object platforms/common/work_queue/CMakeFiles/work_queue.dir/sq_remfirst.c.o
ninja: build stopped: subcommand failed.
Makefile:205: recipe for target ‘px4_sitl’ failed

@gkashyap Where are you checking for the motors? There are two parts here - the firmware and the sdf file. what you are showing in qgroundcontrol is what the firmware thinks it is sending out. This does not necessarily mean your commands are being forwarded to the correct joints.

I suggest:

  1. You need to check if your motor commands (pwm) are being sent to the correct joints as in
  2. You need to check if the motor model plugin is correctly configured as

If this doesn’t work, why not start modifying one by one a existing vtol model such as the standard_vtol? I cannot just go through your code and pin point the problem since I would go through the same procedure as I suggested. Hope the hints above are enough to solve your problem

@Jaeyoung-Lim Well of course I checked the sdf file, the joints. I’ve done it using a diff tool, I’ve done it using simple text comparison manually using two text editor windows side by side with one window having tiltrotor sdf and xe4t. I’ve done it so many times that I can now create a new model easily. :grin:

Thanks for the response. I’ll try the hack, the logical way doesn’t seem to be working. I had thought of it before posting last time but still wanted to know the logical, methodical way to do it.