Use UTM_GLOBAL_POSITION for collision avoidance

[dk7xe]

Describe problem solved by the proposed feature
At the moment there is no collision avoidance feature based on position reports from other drones available. The only collision avoidance is done for manned aircraft traffic based on ADSB_VEHICLE message provided by a ADSB receiver connected to FMU.
With considering other drone positions as well for collision avoidance drone operation safety can be significantly improved when multiple drones share the same airspace.
UTM_GLOBAL_POSITION message broadcasted by a drone and implemented with #10873 provides all the necessary information similar to ADSB_VEHICLE.

Describe your preferred solution
Use UTM_GLOBAL_POSITION message similar to ADSB_VEHICLE for collision avoidance.

Describe possible alternatives
n/a

Additional context
Cooperative awareness is mandatory in future UTM concepts to allow multiple drone operations within same airspace.

[LorenzMeier]

@bresch I think the ask here is that this triggers the same safety maneuver as currently ADSB_VEHICLE - which would mean adding UTM_GLOBAL_POSITION in mavlink_receiver.cpp where ADSB_VEHICLE is already handled.

[dk7xe]

Thank you @LorenzMeier . Indeed UTM_GLOBAL_POSITION should trigger same safety maneuver as ADSB_VEHICLE.

[dk7xe]

@bresch @LorenzMeier any progress on this topic?

[thomasgubler]

ADSB_VEHICLE is defined here: https://mavlink.io/en/messages/common.html#ADSB_VEHICLE
UTM_GLOBAL_POSITION message is here: https://mavlink.io/en/messages/common.html#UTM_GLOBAL_POSITION
transponder_report is defined here: https://github.com/PX4/Firmware/blob/master/msg/transponder_report.msg
mapping from ADSB_VEHICLE to transponder_report is done here: https://github.com/PX4/Firmware/blob/master/src/modules/mavlink/mavlink_receiver.cpp#L2290

Before implementing we need to decide how UTM_GLOBAL_POSITION should be mapped into transponder_report

[dk7xe]

@LorenzMeier no one assigned?

[dk7xe]

We need to work on this because collision avoidance is definitely needed between UAV's

[AmeliaEScott]

I've started looking into this, and I have a question. UTM_GLOBAL_POSITION has next_lat and next_lon for the next waypoint the vehicle is going to, but ADSB_VEHICLE and the UOrb message transponder_report do not have this. I think I can fairly easily map UTM_GLOBAL_POSITION to transponder_report if I just ignore the next waypoint information. Should I do this for now, and treat using this waypoint information as a future issue? Or is it important that I find a way to use this waypoint information now, at the cost of taking longer to get a working implementation?

[AmeliaEScott]

Another question I have is how to map UTM_GLOBAL_POSITION's uas_id to transponder_target's icao_address. Should I change transponder_target to have a generic vehicle_id field, and also an enum indicating the type of ID (e.g., UAS_ID, ITAO_address, etc.)?

[hamishwillee]

@ItsTimmy When this is done, can you please let me know so we can create docs - along the lines of http://docs.px4.io/master/en/advanced_features/traffic_avoidance_adsb.html

FWIW (I'm not in charge) If it were me I would make transponder_target into a generic message - ie with next_lat, next_lon, and renamed vehicle_id so it can be used for both purposes. I'd proceed with the naive implementation (ie not use next_lat, next_lon). This could be done quite quickly and the effort of adding the additional support for next waypoint could be dealt with as a constrained and separate problem.

[dk7xe]

@ItsTimmy hi Timothy

• next_lat and next_lon can be ignored for the mapping for now.
• i would do a generic vehicle id as proposed by you because also regulation discussions are not yet final on this topic.

[AuterionWrikeBot]

➤ Timothy Scott commented:

PR here: #12452
Blocked because it is overflowing flash on FMU V2.

Note: Notify the following people when this is merged:

• Hamish
• Andries