Providing UA ID, type etc. from broadcast module to GCS

[friissoren]

I understood general open architectural issues should be logged as issues in this project so I will add this one here.

If the UA ID/serial number, UA ID Type and UA Type are stored permanently in the broadcast module, there needs to be a way to get that information from the broadcast module to the GCS, so it can be shown to the operator on a UI of some kind.

I know the below is a purely theoretical discussion until someone includes a RID transmitter component to the UAS that is also capable of receiving BT/Wi-Fi RID messages, but I would rather think through this now, than have this causing problems later on.

RID receiver components should follow the instructions here: https://mavlink.io/en/services/opendroneid.html#other_ua
I.e. when publishing the received drone ID data as internal MAVLink messages, they must set the compid field to their own MAV_COMP_ID_ODID_TXRX_n ID, to make it possible to distinguish this data from the drone ID data of the UA itself.
But how do we then distinguish between a Basic ID message with compid = MAV_COMP_ID_ODID_TXRX_n that carries data from the transmitter module (i.e. for the UAS itself) and one that carries data from an entirely different UAS flying nearby?

PS: Having the UA type (quad-rotor, VTOL, blimp etc.) stored in the broadcast module doesn't sound quite reasonable? Maybe that should belong somewhere else? Should it be possible for the operator to input this via a UI on the GCS? A separate topic though.

[sborenstein-ift]

This issue has been noted. I think that for broadcast ID module, this should be set by the GCS. The current MP plugin has the input fields for this, but this doesn't work for Standard Remote ID modules, that need that information baked in. So, it's likely that there will be a slightly different implementation when referring to broadcast and standard remote ID.

To that note, there does need to be a message back via the AP to the GCS that displays this information to the operator, when it's stored in the module.

[BluemarkInnovations]

@friissoren FYI, in ArduPilot, all devices Remote ID module, GCS, auto pilot etc, communicate in some kind of a shared bus. So, the GCS can read out the UA ID/serial number, UA ID Type and UA Type from the Remote ID module. At least this my current understanding.

But how do we then distinguish between a Basic ID message with compid = MAV_COMP_ID_ODID_TXRX_n that carries data from the transmitter module (i.e. for the UAS itself) and one that carries data from an entirely different UAS flying nearby?

It depends on the implementation. If it is a transceiver, one radio module that does both functions, the receiver part know its own RID packets and filter it from the received information stream. Also most/all BT/WLAN radios are half-duplex. If you transmit, you won't receive anything. If the implementation would be two different modules/radios. The receiver radio knows the RID of the UAS, but looking for instance at the RSSI. And/or look for RID signals that are immediately detected when the UAS takes off.

[friissoren]

@BluemarkInnovations: I am purely concerned with the internal MAVLink communication of the UAS.
(I don't really know how things are handled when CAN is used as the internal communication system).

A MAVLink RID receiver component will have to mark all MAVLink droneid messages that it sends on the UAS internal MAVLink network with MAV_COMP_ID_ODID_TXRX_n in the compid field. This indicates that the data in the message is something the receiver component has picked up from some other UA flying in the neighborhood.

But if that same receiver component is also the transmitter component (which is quite likely) it will have the serial number of the UA baked into it. The GCS would probably like to show this serial number on the UI for the operator but the problem is now how to get that info from the transmitter component to the GCS. By standard MAVLink conventions, it should fill the compid field with MAV_COMP_ID_ODID_TXRX_n but that has already been defined to mean the data comes from some neighboring UA.

Maybe it could be allowed to set the compid field to zero in this case but I am not familiar enough with MAVLink conventions to say whether this is a good solution or not.

@hamishwillee: Do you have possible have any comments on the discussion in this issue?

[hamishwillee]

@friissoren Just to make sure I do understand the problem:

• The information you are interested in the GCS knowing about is in OPEN_DRONE_ID_BASIC_ID.
• The currently implemented and well understood use case is that this message is sent by the autopilot to the the transmitter module and used to populate the RemoteID messages it emits. Right?
• I think you want that same information to be available to the GCS - Right?

1. If you want the GCS to have that information wouldn't it make sense for the autopilot to also send it to the GCS - either targeted or broadcast?

• It sounds like you might also be interested in the use case where you have a receiver and you get an OPEN_DRONE_ID_BASIC_ID from a remote system. What is the problem here?

[friissoren]

@hamishwillee: Yes, this is about basic ID.

Earlier the assumption was that the data for this message is stored in the autopilot. However, due to the tamper resistance requirements required by the rules, it seems more likely that the data for this message will be stored in a secure area (One-Time-Programmable bytes e.g. ?) in the remote ID transmitter component/module itself. I.e. neither the autopilot nor the GCS knows about this data.

The question now is, if you have a combo RID transmitter/receiver component, how to get that data to the GCS without confusing it with basic ID data from other UA that the receiver picked up.

[hamishwillee]

So to paraphrase:

• the autopilot will not stream OPEN_DRONE_ID_BASIC_ID (because it does not have the information)
• The remoteID transmitter has to send the OPEN_DRONE_ID_BASIC_ID to the GCS with "its data" -i.e. value for the current vehicle. I presume you don't care if the Autopilot also gets it too.
• A remote ID receiver might also get this information from a remote system and needs to send this to GCS and or Autopilot.

As I understand it OPEN_DRONE_ID_BASIC_ID.id_or_mac is ONLY populated when the data is from a remote system. Can't you differentiate on that?

[friissoren]

As I understand it OPEN_DRONE_ID_BASIC_ID.id_or_mac is ONLY populated when the data is from a remote system. Can't you differentiate on that?

Thank you. I forgot about that. Indeed, that is probably the correct solution here.

[BluemarkInnovations]

@friissoren Outside the OPEN_DRONE_ID messages, the GCS can use for instance the Extended Parameter Protocol to get all parameters of the component including the UA ID/serial number, UA ID Type and UA Type.

See for instance this ArduRemote ID link / screenshot.

Or use the solution that @hamishwillee proposes above if you want to stick to the OPEN_DRONE_ID messages.

[hamishwillee]

I wouldn't recommend the extended parameter protocol. It is only supported by PX4, and I "think" only for camera protocol. Generally parameters are for component specific things, and should be avoided for accessing things that you want to be "standard".

Note that I think this is different for UAVCAN, which actively promotes the standardization of parameters for information exchange.

[al1img]

Hello, I'm new here and I have a similar question. To not duplicate the issue I will post my question here because it is related to the risen here topic,

With ArduRemoteID, is it possible GCS receives its own OPEN_DRONE_ID_BASIC_ID by the telemetry channel?

• The remoteID transmitter has to send the OPEN_DRONE_ID_BASIC_ID to the GCS with "its data" -i.e. value for the current vehicle. I presume you don't care if the Autopilot also gets it too.

I didn't find that the transmitter broadcasts this information through the telemetry channel.

[BluemarkInnovations]

With ArduRemoteID, is it possible GCS receives its own OPEN_DRONE_ID_BASIC_ID by the telemetry channel?

This is not possible/implemented. The idea is that the GCS and the autopilot steam all required data to ArduRemoteID.

The ArduRemoteID does stream OPEN_DRONE_ID_ARM_STATUS messages to the GCS/autopilot to indicate the ARM status.