Add Remote ID docs to PX4 v1.14 level

[hamishwillee]

RemoteID/OpenID mavlink protocol has been added to main.

In mainline the current implementation :

• Streams these streamed at 1Hz in modes: normal, onboard, usb, onboard low bandwidth:

  • OPEN_DRONE_ID_LOCATION
  • OPEN_DRONE_ID_SYSTEM
    • Uses hard coded values and home position for operator - see src/modules/mavlink/streams/OPEN_DRONE_ID_SYSTEM.hpp

• This has a stream defined but is not streamed by default:

  • OPEN_DRONE_ID_BASIC_ID
    • ID format is not in correct format (TODO: MAV_ODID_ID_TYPE_SERIAL_NUMBER needs to be ANSI/CTA-2063 format)
    • Is this fixed before release v1.14?

• There is one parameter/setting:

  • COM_ARM_ODID
  • Enable Drone ID system detection and health check.
    • Essentially sets what PX4 does if OpenID is not found or is lost, with respect to ARMING. (disabled, warning, or required).
    • Default is 0 - so system allows arming without OpenID hardware by default.

• RemoteID hardware presence determined by existence of heartbeat message in last 3 seconds.

• Remote ID hardware health is determined by heartbeat too (spec indicates should also depend on OPEN_DRONE_ID_ARM_STATUS, which is not handled on receive).

• No incoming drone ID messages are handled.

There is also a new PR Open Drone ID Live GNSS and Arm status prototype #21647.

• Not clear if this is going into PX4 v1.14 (?)
• Adds
  • OPEN_DRONE_ID_ARM_STATUS
  • OPEN_DRONE_ID_OPERATOR_ID
  • OPEN_DRONE_ID_SELF_ID
• Plans to stream:
  • OPEN_DRONE_ID_BASIC_ID
• Updates to
  • OPEN_DRONE_ID_SYSTEM

Other docs resources:

• https://docs.google.com/document/d/1eTTm68-KpRc8uNn1eq30K72Ex9plUp8Va8Z-pVCbG34/edit

That about right?

• What remote id hardware/firmware have we actually tested it on?
• What do we "expect" would work based on what we know.
• What's going to be going into PX4 v1.14.
• Is our implementation "compliant" with US regulation, and can I state that?

[junwoo091400]

I have went through relevant resources and checked implementations in both sides (ArduPilot & PX4 with Andy's PR), and referencing your Issue to create a separate Issue to keep track of Remote ID development effort (to keep it separate from docs focused one here)!

For your questions, I asked on discord thread , and I will bring up how much support we will have for Remote ID in v1.14 in maintainers channel 🙏

I should have kept myself on top of this, but I'm now getting myself familiar with it, thank you for this push!

[hamishwillee]

Thanks for the help!

[BluemarkInnovations]

Hi, here are my comments.

This has a stream defined but is not streamed by default:

OPEN_DRONE_ID_BASIC_ID
ID format is not in correct format (TODO: MAV_ODID_ID_TYPE_SERIAL_NUMBER needs to be ANSI/CTA-2063 format)

-Who is responsible for storing and streaming the basic ID? In the ArduPilot world, the basic ID is stored or as parameter in an ArduRemoteID device or it will be streamed by GCS software such as QGroundControl. QGroundControl needs to check a valid SN number. Also ArduRemoteID (RemoteID transponder) needs to do that. See ArduPilot/ArduRemoteID#101. This PR has to be merged.

There is one parameter/setting:

COM_ARM_ODID

Remote ID needs to be tamper resistance. In ArduPilot, they have chosen for a locked bootloader of the autopilot system and you can also lock the ArduRemoteID module to prevent unauthorized changes. So my point is, will this be enough tamper resistance? In my opinion, for most use cases it is. But if it is a parameter than can easy be modified by the end-user this is not sufficient in my opinion.

Is our implementation "compliant" with US regulation, and can I state that?

More ore less. If it is tamper resistance and you stream the system and location messages every second. And read OPEN_DRONE_ID_ARM_STATUS to determine if you are allowed to arm. Then I would say you are 'compliant ready'. In F3586 each UAV vendor needs to do several tests that show that you are compliant to Remote ID. Once of them is that the antenna pattern needs to be (sufficient) omni-directional. Another is that the GNSS hardware provides the correct location data using some basic tests. These tests are outside the PX4 or ArduPilot implementation.

Not clear if this is going into PX4 v1.14 (?)
Adds
OPEN_DRONE_ID_ARM_STATUS
OPEN_DRONE_ID_OPERATOR_ID
OPEN_DRONE_ID_SELF_ID

OPEN_DRONE_ID_ARM_STATUS is mandatory for US compliance. OPEN_DRONE_ID_OPERATOR_ID is only needed for the EU. OPEN_DRONE_ID_SELF_ID is optional.

Also I need to check PX4/PX4-Autopilot#21647, but according to FAA regulation, operator location needs to be fixed or dynamic. Value take-off position is only valid for Remote ID broadcast modules.

[junwoo091400]

• What's going to be going into PX4 v1.14.

Note, I just had discussion with Ramon today and concluded that we don't have a good understanding/agreement on the implementation of Remote ID, and will need to organize a working group with manufacturers & people from the companies to discuss the details.

Hence, Remote ID would be referenced as an 'experimental feature' for v1.14, and we will have it more complete for the next release. We will discuss this in maintainers meeting tomorrow too, and I will provide further updates 🙏

[hamishwillee]

Thanks @BluemarkInnovations - really helpful.

Hence, Remote ID would be referenced as an 'experimental feature' for v1.14, and we will have it more complete for the next release. We will discuss this in maintainers meeting tomorrow too, and I will provide further updates 🙏

@junwoo091400 This is a sensible position to take. Thanks for kicking off the broader discussion.

• I still need to know what the baseline delivery for PX4 v 1.14 is likely to be before I start doing any docs. Do you think Open Drone ID Live GNSS and Arm status prototype  PX4-Autopilot#21647 will go in? If you say no, I can document the status quo (otherwise I have to wait)
• Do you have a plan for the PX4 v1.14 release timeframe that I can have any confidence in?

[junwoo091400]

• Do you think Open Drone ID Live GNSS and Arm status prototype  PX4-Autopilot#21647 will go in?

Since noone in the maintainers were confident about current Remote ID implementation, this won't be going into v1.14.

[junwoo091400]

Do you have a plan for the PX4 v1.14 release timeframe that I can have any confidence in?

I pushed for having a specific deadline for the release on the last maintainer's call, but the maintainers weren't sure about having that, since we still have PR/Issues to resolve.

We did discuss however that from next release, we should have the timeline and more heads-up on when to stop taking in features, so that we don't get pending PR/Issues remaining for months like this time 😞

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/remote-id-coordination-july-11th/33191/1