* Enhancement: State of health, and max_error value is added. Both shows battery health of SMBUS smart battery.
* Enhancement: BAT_C_MULT parameter is introduced. This is for high-current capable SMBUS-based battery.
As SMBUS only provides 16-bit for current, it could only be +-32768mA which is about +-32A.
But with proper treatment, it could be extended with little accuracy loss.
This factor can be set for individual battery system with available information.
* Relative SOC introduced. Proper SMBUS battery should provide percentage of remaining battery
directly. Therefore it does not have to be computed like before.
* State of Health introduced. Proper SMBUS battery should provide SOH value.
* Max error: this shows estimation error of BMS.
* Enhancement: With smart battery, precise estimation of time remaining is provided
with impedance track. It is unit of minute, so 60 seconds multiplied.
Update rate of this is not fast, but very useful.
Co-authored-by: Hyon Lim <lim@uvify.com>
This mode was just kept as an example after
its usage in a single case. It's basically untested
and doesn't make much sense anymore since it's
incompatible with the jerk limited trajectory
implementations. It's implementation only switched
hte configuration parameter of the velocity resulting
from maximum stick deflection to be
MPC_XY_VEL_MAX instead of MPC_VEL_MANUAL.
This is according to todays understanding undesired
because when hitting that limit the position
controller has no room for corrections anymore.
Also it saves some flash space on omnibus to remove
the task at this point and makes romm for the
acceleration feed-forward.
During the first few seconds after takeoff, the failure detector is allowed to
trigger motor lockdown.
This is done for safety reasons to detect tipping-over or unstable
tuning gains
This commit handles incoming MISSION_REQUEST_LIST messages such that
they are no longer ignored if the previously requested mission has
sent all mission items but the ack has never been received.
This was the cause for frequent "IGN REQUEST LIST: Busy" warnings
The landing thrust limit was after the position controller and
could be inconsistent with what the takeoff limit did. This
resulted in different thrust values sequentially getting applied
during landing.
This was only necessary for stabilized mode before #10805.
The unit length thrust setpoint will anyways not be available
anymore soon because it gets replaced with the acceleration
setpoint in m/s².
This is an attempt to fix an edge case in the triplet publication which
can lead to crashes on autopilots with slow SD cards.
The sequence of events before this patch is:
1. Switch to POSCTL when disarmed. At this point current valid with
setpoint idle is published.
2. Arm, takeoff, and fly using joystick/RC.
3. Switch to RTL (or trigger RTL using RC loss). At this point the
setpoint is valid but still idle and the motors will shut off.
4. Once navigator has published the new setpoint (which can take up to
1.5 seconds on slow SD cards) we will hopefully recover.
With this patch we omit this edge case, so we never publish this idle
setpoint when landed. The assumption is that this idle setpoint is no
longer required with the current flight task code, however, that needs
to be further verified.
The checks did previously only report the first failure (to not overload the radio link). As we are moving to buffered messages and higher bandwidth links this design choice is not any more in the best interest of the drone operator. We are now reporting all detected failures. To ensure architectural consistency more checks have been moved from the commander mainloop into the respective classes.
This enables us to have better situational awareness during development and when inspecting a system in the field as to which subsystem is currently faulty. These flags are from standard MAVLink and are not sufficient nor do they match well the actual critical path to a safe flight. This will be addressed in a second step with the addition of a new MAVLink message and new flags.
As we are checking the current pre-flight state and validate wether the system could be armed, we do not want to spam the console or user with continously failing checks. These checks are reported to the GCS separately and are processed and displayed there.
kamilritz