UTM_Global_position Identification system

[LowOrbitIonCannon]

Currently UTM_global_position messages are send from MAVlink to uorb. And from Uorb to MAVlink.

I want to change the Collision avoidance behavior for Drones. Pull Request Drones need to be able to fly closer then 500m to another Drone and still avoid Collisions Autonomously. I implemented a Parameter to change this behavior with a user defined value. While Testing I encountered the issue that the drone sees its own UTM_Globalposition message.

Id like for the Drone to detect that these messages are sent from itself.

There is a TODO: bulletin in [mavlink_reciever.cpp] (https://github.com/PX4/Firmware/blob/master/src/modules/mavlink/mavlink_receiver.cpp) to add a ID to [Transponder_report_s](https://github.com/PX4/Firmware/blob/master/msg/transponder_report.msg).

I am not sure, what the best steps are, to implement this.

Mavlink System ID Pros: -User configurable -Can be used as Callsign?

Cons: -is not published alongside Transponder_report -not unique

Mavlink does not forward the System_ID from the message to Uorb. Is that right?

PX4 GUID Pros: -Unique

Cons -Large = 128 Bit -Cant be used as Callsign

@LorenzMeier what is your Opinion on this?

For Referenz My Pull request Old Related Pull Request

[hamishwillee]

Which GUID value were you thinking might be useable? Can it be reduced algorithmically to a useful callsign?

There are only 255 mavlink ids. If the ID is actually used to store historical state for calculations this is a big problem. However I assume this is just for display? In that case there is still a problem because most drones default to mavlink ID 1. So I'd say this is largely pointless to use.

[MaEtUgR]

@LowOrbitIonCannon Good point to bring up, I've seen it before that when MAVLink frames of one vehicle land at the vehicle again it gets recognized as a "self-collision". Looking at the implementation history I think @eyeam3 and @ItsTimmy probably have the best idea how to handle this problem.

[LowOrbitIonCannon]

Thats a good point @hamishwillee.

We could also mix this, Define Collisions as offboard if the UUID does not match and use MAVlink a the callsign, if the callsign is not defined in QGC.

[hamishwillee]

@LowOrbitIonCannon Possibly. But again, what UUID are you referring to - specifically?

[AmeliaEScott]

I did very little work on this, so I think @eyeam3 is a better person to talk to about it.

[LowOrbitIonCannon]

@hamishwillee board_get_px4_guid(px4_guid); board_get_px4_guid_formated(&guid[0], sizeof(guid)); Both functions use the Board UID, in Transponder_report.msg is a field for uas_id that is filled with the same id. its formatted as a uint8_t[18].

I have a prototype with these UI Checks, ill test when the Weather permits.

Additionaly i tried parsing the Mav- SysID from the UTM MSG to Uorb, but had to change some stuff in the UTM_global_position.msg so i doubt this is the definit answer.

[hamishwillee]

@LowOrbitIonCannon Thanks very much. Is that board UID unique for a board type (e.g. Pixhawk4) or for every single instance? If not, then it's not a good UUID either.

[LowOrbitIonCannon]

this is how its defined in code: that should be unique across most boards. I tested that with 2 NXP Fmus and that worked.

With Mavlink Inspector you can read the UTM_global_position.msg live and under uas_id there should be the GUID

[hamishwillee]

Thanks. That would seem to bet the thing to use then (or some hash of). I'm hoping someone who actually knows a bit more about how UTM expects this to work will join the discussion.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.