Add documentation for Open Drone ID messages

[friissoren]

Please provide guidance on how exactly the documentation should be added?

Is it enough to add just this one file or should similar files be created for the other language variants?

Is the amount of documentation sufficient?

[hamishwillee]

@friissoren I did a subedit - can you please check that the changes don't "break" anything.

Please provide guidance on how exactly the documentation should be added?

This is good. Can you please also link this document in /en/SUMMARY.md (that is what causes our docs toolchain to know this must be rendered)

Is it enough to add just this one file or should similar files be created for the other language variants?

It is enough/good. The other language variants get auto-created via a translation service.

Is the amount of documentation sufficient?

Nearly.

So from "To support easy data transfer to/from a drone ID transmitter/receiver, MAVLink messages supporting all the fields of the drone ID messages have been made available.". So essentially I take that to mean that perhaps the flight controller is attached to a Tx/Rx bluetooth module that understands these mavlink messages and the systems communicate the required info in this way. Right?

1. What rates should the messages be sent at by the flight controller (FC)? [this should be mentioned].
2. What should the FC do if it receives messages? (in general, my assumption is that it need do nothing).
3. I presume that if a ground station received messages it might display the drones on the map?
4. Consider the transmitter attached to a companion computer but most of the messages are routed from the flight controller. Does the transmitter module have a specific component ID it will use for addressing? It probably should, and that should be listed here (you would explain what HEARTBEAT the module emits).

@auturgy @magicrub @julianoes @LorenzMeier FYI - anything else you'd add

[friissoren]

I updated the documentation.

1. Documented
2. Documented
3. That is entirely up to how the full system is implemented. Since there are three different ways drone's can inform about the location etc. an ideal receiver should be listening to both Bluetooth, WiFi and connect via the internet to a Display Service Provider.
   A very big question at the moment is what eventually will be required by law. The current FAA NPRM (rule proposal) will require Network (internet) remote ID for pretty much all drones and also BT/WiFi broadcast in addition for drones flying BVLOS. In Europe it looks like only BT/WiFi broadcast will be required for most of the categories (higher category requirements are still open).
4. Sorry, I didn't really understand this? Are there standardized component IDs?

[hamishwillee]

Re #4, Yes - most components emit a heartbeat and have a https://mavlink.io/en/messages/common.html#MAV_COMPONENT and https://mavlink.io/en/messages/common.html#MAV_TYPE which allow a system to know where to route messages and how/whether they need to be handled.

It might not actually be all that relevant/be broken for your case because everything is broadcast. An implementation can test that.

[hamishwillee]

Thanks for that. Perhaps we should merge this, but add WIP up top until the other PR changes that remove WIP have merged?

[friissoren]

The system where I am currently using these messages is not a traditional flight controller system based on Mavlink. I am just using them as dedicated data carrying messages between the flight controller and the Bluetooth transmitter.

Since I am not familiar with the details of PX4 or Ardupilot, I don't know how exactly things are being done there. If I understand correctly, would there be a need to add three new component IDs for Bluetooth, WiFi and Internet modules or should this rather be a generic drone ID Tx/Rx module?

Should there be two, in order to distinguish between Tx and Rx?

In which of the open ranges should this be added? 2-24 or 106-139 or 161-170 or 176-189 etc.?

For the type, I guess a single drone ID type is sufficient?

I start to understand the problem with removing the WIP marks. I took away the commit that does that and added WIP to the documentation. If we could merge what is now present then at least we get one step further. I will try to join the developer call next Wednesday. Then we can discuss a bit as well. It will be easier.

[hamishwillee]

@friissoren Thanks very much. I'll merge your PR now the WIP has been removed (this makes it a no-brainer).

w.r.t ids You need a component id for every instance that might occur on a vehicle. So if a vehicle might have two of these things, then you need two ids. Perhaps at 205? My assumption is that you'd only have one? No need to say where it is and no need for separate one for Tx and Rx.

Yes, I think type for drone id is enough.

I'm not 100% certain on that, but come to the weds meeting and we'll make sure everyone is on board with this.

[hamishwillee]

Merging. Note that all messages and this doc are still WIP pending an implementation. This will however make it more clear what messages are part of the service.