(Remote ID) Fill out and publish open drone id messages, open drone ID preflight check

[ThomasDebrunner]

Describe problem solved by this pull request

This PR adds mavlink streams for some of the Open Drone ID messages to be streamed over mavlink
The messages can then be picked up by transceivers connected to the autopilot to be sent out.

This also adds a check for the heartbeat of the ODID system, as well as a pre-arm check to prevent arming in case the heartbeat is not received or does not indicate healthy.

Describe your solution

Adds mavlink streams for open drone id messages and adds a pre-arm check

[dagar]

Default to 1?

[ThomasDebrunner]

Not sure, for the normal engineering use case you would not want the requirement, for actual products, you would need to make the param inaccesssible anyways

[dakejahl]

Was this parameter COM_ARM_WO_OBLOG accidentally included in this PR?

[dakejahl]

89.310(d) [standard]: The unmanned aircraft must be designed and produced in a way that reduces the ability of a person to tamper with the remote identification functionality.

Does a parameter satisfy this? Has anyone from the PX4/Ardupilot communities spoken with the FAA about this specifically? "reduces the ability" is kind of vague

[dakejahl]

Sorry I just saw your above comment. Maybe we should add a comment like "Warning this parameter must be deleted and hardcoded to being enabled in a commercial product"

[friissoren]

"reduces the ability" is kind of vague

It is. And to further muddy the waters, the FAA expanded a bit on that requirement in the Notice of Availability document. The ASTM remote ID working group is still discussing how exactly to respond to that.

The MoC has some limited text to address this requirement but it will in the end largely be up to the UA manufacturers to decide how they comply with this and then document their decision properly, in case the FAA at some point comes back and asks for details.

[dakejahl]

MAVLink needs a corresponding PR to add bitmask field for MAV_SYS_STATUS_SENSOR_EXTENDED

[friissoren]

You probably are already aware of this but just to double check. Some additional changes to support the MAVLink OPEN_DRONE_ID_SYSTEM message for feeding dynamic operator location data from the GCS to the remote ID transmitter will also be needed, in order to be EU/US rule compliant.

But this can of course be added in a different PR. And since I only have a very limited understanding of the PX4 system architecture, of course it is also possible that this data would go directly from the GCS to the transmitter without being routed through the flight controller.

[ThomasDebrunner]

@friissoren That's a good point, in our setup, the operator location goes directly to the transmitter, but in the general case where the transmitter is only connected to an FMU telemetry port, the FMU needs to route it. I believe that should already he happening, we'll have to test

[BluemarkInnovations]

@ThomasDebrunner Can you give me some guidelines how I can test this PR with my MAVLink OpenDrone ID modules?

I tried to download PX4, switch to this PR and try to build and run the jMAVSim simulator. However, the simulator crashes on Ubuntu 22.04 after a few seconds. Also, I'm not sure if I can connect the module to the simulator in order to test the code. I can't find any references about it in the help pages. Perhaps I need to wait until my Cube hardware arrives.

[ThomasDebrunner]

@BluemarkInnovations Not sure how easy it is to test that in SITL. Do you then connect the transmitter via a USB-UART connector, or do you also run the transmitter in simulation? What's the setup here?

[BluemarkInnovations]

@ThomasDebrunner I run PIX4 in simulation/SITL and want to attach the transmitter via an USB to UART dongle.

[BluemarkInnovations]

@ThomasDebrunner I have my CubeOrangePlus finally and tried to build this PR. Can you give me some guidelines how to build?

git clone https://github.com/PX4/PX4-Autopilot.git --recursive
cd PX4-Autopilot/
git checkout up-open-drone-id-publish
make cubepilot_cubeorange

During compiling of the code, I get warnings about some submodules out of sync.

If I choose 'y', I get this error:
../../src/drivers/gps/gps.cpp:849:52: error: no matching function for call to 'GPSDriverUBX::GPSDriverUBX(GPSHelper::Interface&, int (*)(GPSCallbackType, void*, int, void*), GPS*, sensor_gps_s*, satellite_info_s*&, int32_t&, float&, GPSDriverUBX::UBXMode&)' 849 | gps_ubx_dynmodel, heading_offset, ubx_mode); | ^ compilation terminated due to -Wfatal-errors. [474/1102] Building CXX object src/modules/ekf2/CMakeFiles/modules__ekf2_original.dir/EKF/covariance.cpp.obj ninja: build stopped: subcommand failed. make: *** [Makefile:235: cubepilot_cubeorange] Error 1

if I choose 'u', I get this error:
../../src/modules/commander/Arming/PreFlightCheck/PreFlightCheck.cpp: In static member function 'static bool PreFlightCheck::preflightCheck(void**, vehicle_status_s&, vehicle_status_flags_s&, const vehicle_control_mode_s&, bool, bool, bool, bool)': ../../src/modules/commander/Arming/PreFlightCheck/PreFlightCheck.cpp:221:6: error: 'prearm' was not declared in this scope; did you mean 'pread'? 221 | if (prearm) { | ^~~~~~ | pread compilation terminated due to -Wfatal-errors. [631/1102] Building CXX object src/modules/commander/CMakeFiles/modules__commander.dir/Commander.cpp.obj ninja: build stopped: subcommand failed. make: *** [Makefile:235: cubepilot_cubeorange] Error 1

[BluemarkInnovations]

Extra info.

• I run it in a dedicated virtual machine with Ubuntu 20.04.
• Executed the ./Tools/setup/ubuntu.sh command
• Normal make px4_sitl jmavsim builds without any error

[dagar]

We should rebase this PR on current main, I've merged the initial mavlink stream support in #20348.