- added support for BQ40Z80 based battery
- added performance counter for interface errors
- added SMART_BATTERY_INFO mavlink message
- general code cleanups and optimization
- fixed: void flooding the log in case of interface error
- fixed: using _batt_startup_capacity instead of _batt_capacity for discharged_mah
- update: read manufacture_date
- update: get _cell_count from parameter and not const 4
- update: avoid re-reading data that has already been read and stored on class already
- currently the battery type defined by BAT_SMBUS_MODEL parameter and not by auto detection
- ecl in PX4/Firmware (84aeb53ee5847866ecf7698591f00278d12ba770): https://github.com/PX4/ecl/commit/ec934908900b23ee273d1a9f82364b7b38423200
- ecl current upstream: https://github.com/PX4/ecl/commit/1e6c6f2d3ccaed470996c9efe88457299608f1d6
- Changes: https://github.com/PX4/ecl/compare/ec934908900b23ee273d1a9f82364b7b38423200...1e6c6f2d3ccaed470996c9efe88457299608f1d61e6c6f2 2020-08-16 Paul Riseborough - EKF: update all output states when aligning output time horizon filter
3bd9415 2020-07-26 kamilritz - Make delayed output stayed not a member variable
da9bfe4 2020-07-26 kamilritz - Update interface of applyCorrectionsToOuputStates
64ab2b0 2020-08-15 Paul Riseborough - EKF: Only record successful sideslip fusion when states updated
0fa7ef3 2020-08-15 Paul Riseborough - EKF: Use ecl::powf for integer exponents
168dbdf 2020-08-15 Paul Riseborough - EKF: Convert sideslip fusion to use SymPy generated auto-code
06aa78a 2020-08-15 Paul Riseborough - EKF: Only record airspeed fusion event when states are updated
486a461 2020-08-15 Paul Riseborough - EKF: airspeed fusion derivation test comparison cleanup
ede6204 2020-08-15 Paul Riseborough - EKF: airspeed fusion cleanup
a5a43db 2020-08-13 Paul Riseborough - EKF: Convert airspeed fusion to use SymPy generated auto-code
5907e81 2020-08-15 Paul Riseborough - EKF: optflow fusion cleanup
7fa9a19 2020-08-15 Paul Riseborough - EKF: optflow fusion cleanup
0e74f3e 2020-08-15 Paul Riseborough - EKF: optflow fusion cleanup
6e992a1 2020-08-15 Paul Riseborough - EKF: optflow fusion cleanup
1ad042d 2020-08-13 Paul Riseborough - EKF: Use ecl::powf in comparison test
274523b 2020-08-13 Paul Riseborough - EKF: Use ecl::powf for integer exponents
f20a5d8 2020-08-13 Paul Riseborough - EKF: Remove redundant tilt check
1592db8 2020-08-13 Paul Riseborough - EKF: Convert optical flow fusion to use SymPy generated equations
1f386c1 2020-08-15 Paul Riseborough - EKF: Add yaw estimate SymPy generated code files
510d938 2020-08-11 Paul Riseborough - EKF: move yaw estimator derivation into main filter derivation
f89c52e 2020-08-13 Paul Riseborough - EKF: use ecl::powf for integer exponents
0aa2f17 2020-08-13 Paul Riseborough - EKF: Convert GPS yaw observation method to use SymPy generated code (#880)
21cc46e 2020-08-11 Paul Riseborough - EKF: Convert magnetic field observation methods to use SymPy generated code (#879)
Because the velocity starts with a positive value (down) to ramp-up
slowly the motors, the position setpoint (integral) was going down into
the ground, canceling the input of the velocity controller during the
early takeoff phase.
Instead of a smooth ramp, the behavior was a delay followed by a quick
takeoff or a land detection.
Setting the current altitude setpoint with the current altitude during
this phase avoids the canceling effect and creates a takeoff purely
velocity-based.
When disable_weather_vane is true, the vehicle is aligning for the transition waypoint
(VTOL) and thus the yaw setpoint from Navigator should be used.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- always check system field for validity
- reject any data outside of "servo position" valid range from Spektrum specification
- properly support XPlus channels (12+)
- debug message if channel count changes
I changed the input constraint in #15349 but screwed up the usage
because I was convinced it's püass by reference. I'll double check
for sure next time.
During takeoff, Navigator is sending a constant yaw value.
However, there is always a reset at 1.5m of the yaw estimate in EKF2
that is not handled by Navigator that produces a glitch in the rate
controller. Given that in FlightTask, the yaw
is already computed and properly corrected in case of an estimator reset
event, we just ignore the yaw value sent by navigator during takeoff.
The acceleration setpoint gets implicitly inherited from the altitude
flight task since #14212. This feed-forward adds an unwanted
acceleration when the right stick is deflected. Instead I'm using it
to command the expected centripetal acceleration when flying
in a circle for better orbit tracking.
For the RC controlled yaw behaviour, we do a yaw setpoint according to
the stick expo. The uncontrolled yaw behaviour behaves undefined.
Switching between yaw behaviours makes the drone stand still for a
moment, which probably can be improved.
Daniel Agar