Since the horizontal and vertical velocity controllers are now
decoupled, it can be that the horizontal acceleration produced by the
controller is actually greater than the desired one (by design). This
condition would actually make the ARW run "backwards", degrading the
controller performance.
Directly use yaw controls for it, and don't add it to the allocation matrix,
as that would have an effect on rudder scaling if the wheel also would have
a yaw effectiveness.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This is the control surface type for airframes that have only a
single aileron servo or have the ailerons on a single output channel.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
2fbb70d9ca made the lowest possible
throttle value commanded by stick in Stabilized mode before taking off 0.
The real world problem with this is that when takeoff is detected then
the entire throttle scaling range jumps from
[0, MPC_MANTHR_MIN]
to [MPC_MANTHR_MIN, MPC_MANTHR_MIN].
As a result whenever MPC_MANTHR_MIN is not zero there is a thrust jump
on every takeoff just at the moment takeoff is detected even when the
stick is moved continuously.
Because of this I suggest to revert to having a higher throttle value
from the beginning on because it's less complicated and there's
no obvious value in starting out with zero thrust if anyways not
possible to go back to zero for safety once takeoff is detected.
Using the control status flags isn't robust as this part of the code
runs at the EKF update rate while the in_air transition is don at the
prediction rate. It was then likely to miss the transition
I think most vehicle can safely decend with at least 1.5m/s, and having this
value too low makes Descents/Landings/RTLs unnecessary long.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- replace float32[21] URT covariances with smaller dedicated position/velocity/orientation variances (the crossterms are unused, awkward, and relatively costly)
- these are easier to casually inspect and more representative of what's actually being used currently and reduces the size of vehicle_odometry_s quite a bit
- ekf2: add new helper to get roll/pitch/yaw covariances
- mavlink: receiver ODOMETRY handle more frame types for both pose (MAV_FRAME_LOCAL_NED, MAV_FRAME_LOCAL_ENU, MAV_FRAME_LOCAL_FRD, MAV_FRAME_LOCAL_FLU) and velocity (MAV_FRAME_LOCAL_NED, MAV_FRAME_LOCAL_ENU, MAV_FRAME_LOCAL_FRD, MAV_FRAME_LOCAL_FLU, MAV_FRAME_BODY_FRD)
- mavlink: delete unused ATT_POS_MOCAP stream (this is just a passthrough)
Co-authored-by: Mathieu Bresciani <brescianimathieu@gmail.com>
fix test by reducing the distance to the new origin: the maximum size of
the local position origin is a cube of 1e6m. If the origin is moved
further than this, the state is clipped to that maximum value
Navigator sets the cruise_speed to -1 if the controller shouldn't listen to
it and instead use the default speed (for MC: MPC_XY_CRUISE). This is for
example for RTL the case, where we want to return at the default speed,
independetly of what the mission speed before was.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- synthetic airspeed will only be declared valid as soon as the wind variance
has dropped below a parameterized threshold. This is useful for vehicles without
an airspeed sensor which rely on synthetic airspeed but only once the vehicle
has turned sufficiently for the wind estimates to be reliable.
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- msg constant names now comply with ROS conventions:
uppercase alphanumeric characters with underscores for separating words
partially fix#19917
Signed-off-by: Beniamino Pozzan <beniamino.pozzan@phd.unipd.it>
rtl state was getting reset on inactive, which meant that the state which triggered resuming e.g. mission landing would be overwritten, and the navigator mode would switch back and forth between rtl and mission. this commit:
1. moves the reset of rtl state to the on activation function (removing it from the on inactive function)
2. functionalizes the rtl state input to the rtl time estimator so that rtl time can still be calculated from state=none while inactive
This commit removes the additional airspeed check (airspeed for VTOLs in
hover below LNDFW_AIRSPD_MAX), as it is not a required condition in the
landed state (headwind blowing into the airspeed sensor won't stop
once on the gruond). In FW mode the check would make more sense, but there
the land detector is currently simply disabled.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
JaeyoungLim