[Bug] the aircraft in QGC and gazebo are not moving after the preflight check was OK

[zyy37]

Describe the bug

Using the software versions of px4(px4_sitl), gazebo garden and QGC for simulation, the preflight check was OK, but the aircraft in QGC and gazebo are not moving.
From the above figure, it can be seen that after 5 minutes and 30 seconds, the aircraft in QGC did not move, and so did the aircraft in Gazebo.

To Reproduce

1. make px4_sitl gz_x500
2. connect to the QGC by UDP.

Expected behavior

the aircraft in QGC and gazebo should follow the route and move after the preflight check was OK.

Screenshot / Media

No response

Flight Log

n/a

Software Version

Raspberry Pi 4b 8GB arm64

ver all
HW arch: PX4_SITL
PX4 git-hash: d2819ca
PX4 version: 1.14.0 80 (17694848)
PX4 git-branch: main
OS: Linux
OS version: Release 5.15.0 (84869375)
Build datetime: Sep 19 2023 12:14:40
Build uri: localhost
Build variant: default
Toolchain: GNU GCC, 11.4.0
PX4GUID: 1006554d49534954414c44494e4f30303030
UNKNOWN MCU

ubuntu@ubuntu:~$ gz sim --version
Gazebo Sim, version 7.0.0
Copyright (C) 2018 Open Source Robotics Foundation.
Released under the Apache 2.0 License.

Flight controller

px4_sitl

Vehicle type

None

How are the different components wired up (including port information)

No response

Additional context

No response

[zyy37]

Any update? Please. Is it a bug?
here is the log if you want to know. https://logs.px4.io/plot_app?log=191b9853-ee13-4475-b7d5-b6a134eaefc3

[bresch]

Is it a custom model? Looking at the log, the drone went full thrust but didn't move.

[zyy37]

Not a custom model.
I'm new to px4 and just want to run an default example. The development environment I am using is Ubuntu 22.04 on Raspberry Pi 4b, and the QGroundControl environment is Windows 10. I followed the official steps which are Ubuntu Development Environment and Building PX4 Software to reproduce it. However, when running this example make px4_sitl gz_x500, it shows the above result that the plane does not move, and I don't know where the problem is.

[zyy37]

Fig 1. UDP settings of referring website.

Fig 2. The moving aircraft of referring website.

Fig 3. I cannot reproduce it, and the aircraft is not moving. make px4_sitl gz_x500

Both are done by running px4_sitl and gazebo, as well as QGroundControl linked by UDP, I imitated the settings and steps in Figure 1 and Figure 2 (referring to the website) step by step, but the aircraft still couldn't move. The blogger's aircraft can move, but mine cannot, but he uses the gazebo classic and I use the gazebo garden. I cannot reproduce it. It's very strange. Is this a bug?

[zyy37]

Update:
When the development machine is replaced with a Linux amd64 virtual machine, the aircraft in the software simulation (make px4_sitl gz_x500) can be moved. The previous development machine for the aircraft that did not move was the Raspberry Pi 4b 8GB arm64. You may support this scenario. thanks

By the way, the error logs for aircraft not moving on the Raspberry Pi 4b 8GB arm64 are as follows. Compared to the aircraft can move on Linux 22.04 amd64, the additional error logs appear to be,

Error [Utils.cc:174] Missing element description for [persistent]
[Err] [MulticopterMotorModel.cc:255] Please specify a robotNamespace.
[Err] [MulticopterMotorModel.cc:255] Please specify a robotNamespace.
[Err] [MulticopterMotorModel.cc:255] Please specify a robotNamespace.
[Err] [MulticopterMotorModel.cc:255] Please specify a robotNamespace.

I see that @MichaelBosello seem to have encountered the same problem #21378. And this MulticopterMotorModel.cc is from the gz sim repository. Is this issue a bug in your gz sim repository @bperseghetti, or is there a difference in the binary release packages between amd64 and arm64? Thanks.

[AkashJohnSubash]

Suspect its a difference in the binary releases of one of the packages for arm64. (Same setup worked fine for amd64)
I had a similar issue using Gazebo Harmonic running on Ubuntu 22.04 natively on apple Silicon (m1Pro) with CrazySim_SITL.
I would be interested in tips on debugging to find the offending package.