New Simulation Sensor Timeout

Hey all,

I’ve been working on an updated Xplane to Px4 Bridge that doesn’t rely on QGC.

Initial results of data out of Xplane are promising, but I’m getting a timeout on both the Accel and and baro. Hopeful I can prove it out more and push it back to the main repo.

Looks like my sensors are updating too slow. QGC and Wireshark would tend to agree. Looks like all my sensor messages are only being output by PX4 at 1hz or less and QGC’s mavlink inspector agrees. It doesn’t show any of the HIL input message but I assume that’s because they’re on TCP?

Is there a better way to log/debug this besides wireshark?

This is weird because I’m sending messages at a much faster pace then1 hz. Is there some sort of internal check that’s throttling me that I’m missing?

WARN  [ecl/EKF] baro hgt timeout - reset to baro
WARN  [ecl/EKF] baro hgt timeout - reset to baro
WARN  [ecl/EKF] baro hgt timeout - reset to gps
ERROR [sensors] Accel #0 fail:  TIMEOUT!
WARN  [ecl/EKF] baro hgt timeout - reset to gps
ERROR [sensors] Accel #0 fail:  TIMEOUT!
WARN  [ecl/EKF] baro hgt timeout - reset to baro
WARN  [ecl/EKF] baro hgt timeout - reset to baro
WARN  [ecl/EKF] baro hgt timeout - reset to gps
WARN  [ecl/EKF] baro hgt timeout - reset to baro
WARN  [ecl/EKF] baro hgt timeout - reset to baro

Here’s a pdf of my wireshark dump since it won’t let me attach the pcap. The pdf is unfortunately big.
wireshark_dump.pdf (1.4 MB)

Couple of things to add here that I’ve learned.

  • If you’re trying to debug simulator messages in wireshark make sure you modify the lua plugin to show tcp messages as mavlink
local tcp_dissector_table = DissectorTable.get("tcp.port")
tcp_dissector_table:add(4560, mavlink_proto)(melodic:localhost)
  • Accel timeout was happening because I’m simulating without lockstep and there’s a good deal of slop when messages are being sent. Hoping to clean this up more. The timeout comes from my imu being at 100hz, so when I miss a message and the slop is high on both ends it exceeds the timeout of .02 seconds.

  • Baro timeout is likely a similar issue but still investigating

Baro timeout is a very similar issue. The baro and gps were getting too far skewed off the imu because of how data was being sent leading to the seen errors. Appears the EKF is clocked roughly off the IMU rate, but don’t quote me on that