Closed Katawann closed 2 years ago
I can reproduce the issue, looking into it.
Ok, I found the reason. This reason is that the mavlink instance on the Pixhawk's USB is no longer running by default but is started when it detects an incoming MAVLink heartbeat. It turns out that Gazebo HITL does not send any heartbeats so then the mavlink instance on the PX4 side is not started and Gazebo just fills it's Tx buffer.
The auto-detection happens here: https://github.com/PX4/PX4-Autopilot/blob/887fe7dba2d2d0dbdf8a2b9141f1b0de781ebc4e/platforms/nuttx/src/px4/common/cdc_acm_check.cpp#L224-L236
To fix this, I enabled sending heartbeats on the Gazebo side. However, sending a heartbeat every second was not enough, because all the buffers might get filled with HITL data in less than a second which then again leads to the situation where the mavlink instance is not started. Therefore, I'm sending the heartbeat in every iteration until we receive a heartbeat which tells us PX4 is talking back.
Hello, @julianoes,
I am still facing this problem when I am customizing my own gazebo model but connecting with Pixhawk mini.
I am using the same setting of mavlink plugin in the iris.sdf. And following what stated on the setting of HITL, the problem of :Tx queue overflow still appeared.
Any solutions or suggetion are welcomed!!!!!
Hello, @julianoes,
I am still facing this problem when I am customizing my own gazebo model but connecting with Pixhawk mini.
I am using the same setting of mavlink plugin in the iris.sdf. And following what stated on the setting of HITL, the problem of :Tx queue overflow still appeared.
Any solutions or suggetion are welcomed!!!!!
[Msg] Connecting to PX4 SITL using serial [Msg] Lockstep is disabled [Msg] Using MAVLink protocol v2.0 Opened serial device /dev/ttyACM0 Tx queue overflow Tx queue overflow Tx queue overflow Tx queue overflow Tx queue overflow
Hello, I merged my model into the Tools/sitl_gazebo/model under PX4.
When I ran my model HITL, it still shows “Tx queue overflow"
I have four rotors sticked on four rotational arms, I am not sure whether it makes overflow.
Tx queue overflow
This often happens if the configured serial port is not the right one.
This often happens if the configured serial port is not the right one.
Thanks, @julianoes
Sometimes it works well, sometimes overflows.
This often happens if the configured serial port is not the right one.
By the way, I didn't change any serial port settings, sometimes it can work. What should I do if I want to make sure it works every time?
Whatever you connect to the PC first, will have /dev/ttyACM0
and sometimes the port might still be blocked because it's still open by QGC or something else and hence you'll get /dev/ttyACM1
. That would explain it.
If you want to avoid dealing with these instance numbers, just use the path by id which doesn't change, e.g.: /dev/serial/by-id/...
and put that one in the sdf.
@julianoes , every time I change the model into the Iris, it works, but when using my more complex model, it shows overflow.
Whatever you connect to the PC first, will have
/dev/ttyACM0
and sometimes the port might still be blocked because it's still open by QGC or something else and hence you'll get/dev/ttyACM1
. That would explain it.If you want to avoid dealing with these instance numbers, just use the path by id which doesn't change, e.g.:
/dev/serial/by-id/...
and put that one in the sdf.
Based on what I did, I don't think it is a problem of port, because when I used a quadrotor with four tiltable rotors, it shows overflow, but when I used a common quadrotor, everything is fine.
Do you change the port for when you use other non Iris models?
No, I didn't change. What I did was just change the vehicle name in the launch file, and the Iris model works pretty well every time.
If that is the case, please submit a pr. If not, it is public record.
What I did was just change the vehicle name in the launch file, and the Iris model works pretty well every time.
@AllenHuangDongyue Could you submit a PR for this change?
This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:
when I used a quadrotor with four tiltable rotors, it shows overflow, but when I used a common quadrotor, everything is fine.
Now that I read it again, this sounds most likely like just the sheer amount of topic being sent over from Gazebo through the mavlink interface library to the Pixhawk is filling up the TX buffer.
when I used a quadrotor with four tiltable rotors, it shows overflow, but when I used a common quadrotor, everything is fine.
Now that I read it again, this sounds most likely like just the sheer amount of topic being sent over from Gazebo through the mavlink interface library to the Pixhawk is filling up the TX buffer.
Hi, Junwoo,
Sorry to reply you late.
It seems your analysis is reasonable. I just add extra four inputs for tilting the rotors in the SDF file using my custom CAD model following the template of iris.sdf. No extra changes. Multiple attempts may result in one success.
Could you submit a PR for this change?
I haven't finished this project, sorry I can't submit a PR.
Describe the bug When I run HITL with Pixhawk 4, Gazebo 11 and PX4 v1.13.0-beta1 (or master), the simulation failed to
Tx queue overflow
after it connects to the USB port.To Reproduce Steps to reproduce the behavior:
gzserver --verbose Tools/sitl_gazebo/worlds/hitl_iris.world
[Msg] Waiting for master. [Msg] Connected to gazebo master @ http://127.0.0.1:11345 [Msg] Publicized address: 192.168.1.235 [Msg] Loading world file [/home/PX4-Autopilot/Tools/sitl_gazebo/worlds/hitl_iris.world] [Wrn] [gazebo_gps_plugin.cpp:78] [gazebo_gps_plugin]: iris::gps0 using gps topic "gps0" [Wrn] [gazebo_gps_plugin.cpp:203] [gazebo_gps_plugin] Using default update rate of 5hz [Msg] Connecting to PX4 SITL using serial [Msg] Lockstep is disabled [Msg] Using MAVLink protocol v2.0 Opened serial device /dev/ttyACM0 Tx queue overflow Tx queue overflow Tx queue overflow ...