Brings us in-line with other classes in ArduPilot.
Removes ambiguity with AP_HAL::OpticalFlow which can cause compilation errors as we start to make code more portable across targets
Brings us in-line with other classes in ArduPilot.
Removes ambiguity with AP_HAL::OpticalFlow which can cause compilation errors as we start to make code more portable across targets
Brings us in-line with other classes in ArduPilot.
Removes ambiguity with AP_HAL::OpticalFlow which can cause compilation errors as we start to make code more portable across targets
Brings us in-line with other classes in ArduPilot.
Removes ambiguity with AP_HAL::OpticalFlow which can cause compilation errors as we start to make code more portable across targets
Brings us in-line with other classes in ArduPilot.
Removes ambiguity with AP_HAL::OpticalFlow which can cause compilation errors as we start to make code more portable across targets
Brings us in-line with other classes in ArduPilot.
Removes ambiguity with AP_HAL::OpticalFlow which can cause compilation errors as we start to make code more portable across targets
Also rename from HAL_CRASHDUMP_ENABLE
Removes code based on define rather than creating empty functions. Makes it clearer what's going on in the callers.
Also rename from HAL_CRASHDUMP_ENABLE
Removes code based on define rather than creating empty functions. Makes it clearer what's going on in the callers.
Also rename from HAL_CRASHDUMP_ENABLE
Removes code based on define rather than creating empty functions. Makes it clearer what's going on in the callers.
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
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.
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.
