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)
The squares surrounding the current location were only checked when we went to send a terrain request. This means it was possible that:
- the number of pending requests could go to zero
- prearm checks would pass
- vehicle arm is attempted by the user (or a script, or ....)
- the code would call AP_Terrain::send_requests which would create more pending requests
- the arming sequence would fail
It's also possible for the arming to succeed, and then we're flying in violation of the intended prearm checks.
Doing things in the update function has the additional advantage of making things more efficient as we can push out terrain requests more often.