we only accept a lidar if it changes by 5% of its full range, and we
reject a lidar again if the correction between barometric and lidar
range changes by more than 30m
This allows us to cope with faulty lidars which may give a constant
reading
- enabled via new param LAND_ABORT_THR default is 0 (disabled)
- Triggered via 95% throttle during landing, a landing abort will take place.
- This copies all takeoff params for right now, we can make this better later if needed
- added mission item command to NAV_LAND which is the abort takeoff altitude. If 0 then use last takeoff if available, else use 30m
- hold heading, just like takeoff, until altitude is reached
- pitch is constrained to takeoff pitch, or else 10deg if not available
- After abort altitude is reached, the normal landing restart happens (DO_LAND_START or decrement mission)
- restart landing by jumping to DO_LAND_START or decrement mission on mode change
Use waypoint bearing if available, otherwise use gps projected ahead 1km else yaw
Perform update before making decision to finish cmd so it always executes
This behavior is excessively paranoid about clearing the flag so now it's extra sticky. You can only clear the is_crashed flag when:
- changing modes
- starting to execute a takeoff wp (if mission/index gets reset while still in auto)
- while in takeoff and throttle is suppressed it's held false
behavior that was removed:
- clear flag when starting to execute any nav cmd (reached next wp)
- if while crashed, you "start flying again" (non-sticky)
add crash detection, allow disengage via param CRASH_DETECT
improved is_flying behavior
take off, landing and hard-landing improvements
add stillness check to is_flying and log it
minimum airspeed is determined ARSPD_FBW_MIN*0.75
Param 1 of CONTINUE_AND_CHANGE_ALT now denotes which direction the
user expects the plane to travel when changing altitude:
0 = no expectation, command completes when within 5 m of altitude.
1 = climb expected, command completes at or above altitude.
2 = descent expected, command completes at or below altitude.
Whenever next waypoint is within the loiter radius, maintaining loiter would prevent us from ever pointing toward the next waypoint. Hence for very close waypoints loiter_to_alt becomes verified by the altitude only.
- const values declared as default double
- This is the first pass in fixing the warnings, trying to catch some low hanging fruit. All const double values are changed to float. For example: 1.0 is now 1.0f.
- Only except is in location.pde where some double stuff is happening
- I did not change the exponentials 1e7 type stuff which should be 1e7f. A different commit
initialise mount on startup
use mount.has_pan_control method
remove calls to unimplemented mount.configure_cmd
remove call to update_mount_type which is now handled by mount lib
when a change altitude command comes in while a large glide slope
altitude change is present we could end up using the old glide slope
with the new altitude. This resets the altitude offset, causing a
direct altitude change