Don't use ADSB messages with undefined fields in navigator

[svpcom]

Ignore messages that have undefined fields required for collision estimation.

[dagar]

@svpcom check CI failure (trivial style issue).

@LorenzMeier do we still need to limit direct mavlink usage to the mavlink module?

[svpcom]

@dagar Style fixed

[dagar]

In the past we had to be careful to not include mavlink headers outside of the mavlink module. We need to verify if that's still the case.

[LorenzMeier]

That's still the case because we don't want to start leaking MAVLink as a dependency into the system. In particular now that FastRTPS is picking up speed.

[LorenzMeier]

This needs to be changed as it hardwires MAVLink into PX4 as the only protocol.

[LorenzMeier]

These need to be abstracted in the appropriate UORB message spec.

[dagar]

In that case @svpcom can you add the relevant fields to transponder report? https:/PX4/Firmware/blob/master/msg/transponder_report.msg#L12

[svpcom]

@dagar I can add something like all_fields_defined to UORB message to indicate that ADSB message has all fields needed to run collision detection. But I'm unable to remove flags field because it used for reconstruct ADSB mavlink message to route it via telemetry link (src/modules/mavlink/mavlink_messages.cpp#1342).

It seems that is needed for directly attached (to FMU via UART) ADSB receiver which emits messages that needed not only for FMU (collision detection in navigator module), but for QGroundControl too (to display airplanes on the map).

[LorenzMeier]

@svpcom You can just copy the flags from MAVLink into the uORB message and then add code when the MAVLink message gets assembled.

[svpcom]

@LorenzMeier
So there are four possible implementations:

1. Copy definition of enum ADSB_FLAGS from mavlink headers. This is simplest variant because we don't need to map mavlink adsb flags to uORB adsb flags. But if their definitions will be changed in future mavlink versions this break navigator code.
2. Add own enum for adsb flags and make a mapping from mavlink to uORB flags in mavlink module (during parsing and reconstruction phases).
3. Add boolean field for each flag to uORB message. This is mostly equal to previous case.
4. Add additional boolean field (use current flags field only for mavlink packet reconstruction) and set it to true if we have ADSB_FLAGS_VALID_COORDS, ADSB_FLAGS_VALID_HEADING, ADSB_FLAGS_VALID_VELOCITY and ADSB_FLAGS_VALID_ALTITUDE set in message. This doesn't required to copy enum ADSB_FLAGS or add additional mapping.

Also the current implementation always retranslate ADSB mavlink messages. Even if these message were emitted by external receiver and got via telemetry link. I use modified dump1090 which run on companion computer and use mavlink-router to inject packets to telemetry stream. I don't have http://www.uavionix.com/products/pingrx/ and don't know which sys_id and comp_id are used in their messages to make a decision - retranslate message to telemetry link or not.

So my questions are:

1. What implementation to choose?
2. What to do with duplication of adsb messages which are received via telemetry link?

[LorenzMeier]

The best is to start with a literal copy but still add the code that translates between them (rather than just copying the value). This is future-proof but right now the least effort. If you already see that you would like to do more medium-term than is supported by MAVLink right now you can already now diverge where needed.

[LorenzMeier]

@dagar Please squash if you merge before me.

[svpcom]

I've fix a typo.

[LorenzMeier]

@svpcom Style check failed.

[dagar]

Why not define these in the uORB message?

[svpcom]

@dagar Fixed