This header is used by waf to contain the generated version macros,
particularly using the git hash. For waf it's better to be in a separate
header since it then can keep track of changes on it a trigger
recompilation.
For the make build system, a dummy ap_version.h file has been added in
the missing/ folder so both implementations can co-exist.
Having the version macro in the config.h and consequently in the main
vehicle header means that whenever the version changes we need to
compiler the whole vehicle again. This would not be so bad if we weren't
also appending the git hash in the version. In this case, whenever we
commit to the repository we would need to recompile everything.
Move to a separate header that is include only by its users. Then
instead of compiling everything we will compile just a few files.
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)
the glide_slope gets calculated every time there's a major event such as mission item change or wp_proportion change so its good to update the flight stage then too because.
also logging stage when stage changes, might as well get an extra data point in there when it's timely
