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]

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

[stale]

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