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.
looking at pending is insufficient as we may have more mission items to check to see if they need other pieces of terrain. That is, terr_pending can go to zero momentarily and then go back to a non-zero number as Terrain's update method checks the mission and rally libraries for more terrain requirements.
Without this patch the prearm checks can momentarily pass, allowing the vehicle to arm. The vehicle could hit a terrain failsafe later if it doesn't manage to get the data while in flight.
motors check would be run twice on arm without this.
After this change, even if ARMING_CHECKS is 0 the user will be warned they need to set FRAME_CLASS and FRAME_TYPE, rather than just when they try to arm the vehicle.
Before this patch we would display PreArm: even if the checks were being performed as part of the arming sequence.
This lets us distinguish betwee checks failing because the user is trying to arm the vehicle and when the prearms are running while disarmed (or triggered via GCS)
Andrew Tridgell
Joshua Henderson
Roel Schiphorst
Peter Barker
Iampete1
Leonard Hall
Tamas Nepusz
Henry Wurzburg
Andy Piper