this is a bandwidth efficient way to update the OPEN_DRONE_ID_SYSTEM message data when there is limited uplink bandwidth. Testing on real vehicles shows that with RFD900x radios at an air data rate of 125kbit/s with OPEN_DRONE_ID messages with 1Hz update (as required by FAA RemoteID standard) that there is significant impact on the ability of the GCS to give commands to the flight controller. For example, I got a high degree of packet loss in downloading parameter pre-flight, and many/most in-flight commands failed from the GCS.
By using this message we can use the minimum required bandwidth for updating operator location while remaining FAA RemoteID standard compliant
Makes it clearer in the output that we're skipping a board because it isn't in the configure list. Currently it just does the submodule updaet then goes onto the next build, without telling you why it's not doing anything more
Also switch to keying off the define in build_options.py rather than the label as the label is not unique and we'd have to munge them badly (and enforce shape) where we can just use the ArduPilot defines which are all pretty well-formed.
can we rename "constains_terrain_relative" to "contains_terrain_alt"? No big deal of course but "terrain_alt" is what we use in Copter so it's more likely to show up in searches.
can we rename "constains_terrain_relative" to "contains_terrain_alt"? No big deal of course but "terrain_alt" is what we use in Copter so it's more likely to show up in searches.
If SITL is not receiving any sitl rc input (so _sitl_rc_in.recv(...) is allways returns -1 then the bind-values code would never be crossed so the RC input values would remain at their initialisation values rather than honouring the SIM_RC_FAIL setting which says they should go to bind values (notably throttle-to-950)
Andrew Tridgell
Peter Barker
Andy Piper
Randy Mackay
bugobliterator
Shiv Tyagi