Ran into a bug on our physical plane where failsafe.last_valid_rc_ms was not recognizing that the transmitter had failed. This is likely due to how the standard failsafe works in receiving lower-than-possible throttle values. So in order to account for this, I added a new variable to the failsafe, AFS_last_valid_rc_ms, and I update it only if the ch3_failsafe (the throttle failsafe) is not on. If the throttle failsafe is on, that means that the plane has indeed lost transmitter input, so the AFS needs to recognize that.
@Description: This parameter reduces the pitch minimum limit of an auto-takeoff just a few seconds before it reaches the target altitude. This reduces overshoot by allowing the flight controller to start leveling off a few seconds before reaching the target height. When set to zero, the mission pitch min is enforced all the way to and through the target altitude, otherwise the pitch min slowly reduces to zero in the final segment. This is the pitch_min, not the demand. The flight controller should still be commanding to gain altitude to finish the takeoff but with this param it is not forcing it higher than it wants to be. (+1 squashed commits)
- fixes bug where a bungee launch is configured but the aircraft gets bumped and triggers the prop to spin up. This will now detect that and "crash' and disable the motor
Reverse thrust for controlled landings, even with much steeper approach slopes. This is achieved by allowing throttle demand to go negative to maintain a target airspeed. A Pre-Flare stage was added, triggered by an altitude, to allow for a slower airspeed just before land. That lower airspeed can be near stall.
new params LAND_PF_ALT, LAND_PF_SEC, LAND_PF_ARSPD, USE_REV_THRUST
Added update_trigger and check_digital_pin functions
added camera trigger precise time mark
detect camera feedback pin status
added support for simple digital pin
included support for digital pin. Already included in
added support for TRIGGER MSG
@Description: X-Axis deceleration threshold to notify the crash detector that there was a possible impact which helps disarm the motor quickly after a crash. This value should be much higher than normal negative x-axis forces during normal flight, check flight log files to determine the average IMU.x values for your aircraft and motor type. Higher value means less sensative (triggers on higher impact). For electric planes that don't vibrate much during fight a value of 25 is good (that's about 2.5G). For petrol/nitro planes you'll want a higher value. Set to 0 to disable the collision detector.
- inhibit crash detection warnings when disabled by param so now it can be completely disabled
- reset is_crashed when disabled by param
- fixed pre-takeoff detection bug by adding in_preLaunch_flight_stage() where we are actually in FLIGHT_NORMAL instead of FLIGHT_TAKEOFF during setup of bungee launches. This now detects if we're in that state
- simplified the use of been_auto_flying to check across all flight stages. before it was excluded to handle hand-launches which can now be detected with in_preLaunch_flight_stage()
- added impact detector timer to clamp is_flying a few seconds after an impact
- logging new impact detector as "STAT.Hit"
- parse MAVLINK_MSG_ADSB_VEHICLE msg
- new 1Hz adsb_update task to compare list against for threat detection
- perform object avoidance via loiter or loiter_and_descend. More methods are welcome!
Most of AP_Progmem is already gone so we can stop including it in most
of the places. The only places that need it are the ones using
pgm_read_*() APIs.
In some cases the header needed to be added in the .cpp since it was
removed from the .h to reduce scope. In those cases the headers were
also reordered.
prog_char and prog_char_t are now the same as char on supported
platforms. So, just change all places that use them and prefer char
instead.
AVR-specific places were not changed.
Include board-specific files only when the board is used. Since these
should be exceptional cases, let the includer handle the ifdef instead
of putting ifdefs in every platform-specific header.
In the future we should evaluate whether the HAL for the board should
instantiate this.
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
- previously we only kept track of starting flying while in auto which gets reset when switching in and out of auto and on takeoff/land. Now we keep track of a "global" one that will track the is_flying flag regardless of the flight mode.
- 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
* Retains ability to read from Analog Pin
* Adds ability to read RSSI from PWM channel value as is done in OpenLRSng, EazyUHF, and various other LRS.
* Handles any type of RSSI that provides RSSI values inverted - i.e. when the low value is the best signal and the high value is the worst signal.
* Has different key names from all existing RSSI parameters to provide for a clean break and easier distinguishing.
* Existing parameters are marked as obsolete
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
This commit changes the way libraries headers are included in source files:
- If the header is in the same directory the source belongs to, so the
notation '#include ""' is used with the path relative to the directory
containing the source.
- If the header is outside the directory containing the source, then we use
the notation '#include <>' with the path relative to libraries folder.
Some of the advantages of such approach:
- Only one search path for libraries headers.
- OSs like Windows may have a better lookup time.