As discussed in the maintainer call we should adhere to the
parameter naming scheme that makes it clear what vehicle type the
configuration is good for.
by only applying the sqrt linear drag when brakeing.
It was originally not done this way to avoid discontinuities and
the exact speed bewlo 1m/s didn't matter. With the position slow mode
the exact slow speeds now matter. And the discontinuities are avoided by
reusing the brake boost filter.
The defintion of the custom symbol M_PI_PRECISE
was not included in one of the only places it's used.
Looks like a mistake that happened in
34c852255e16bb62d2caf0c3be1f2fea660036ba
possibly because a lot of things are included
almost everywhere and if the include order
ligns up there are no compile errors.
Otherwise if is set to Offtrack, which in turn leads to weird behavior.
E.g. when triggering Land while flying fast forward, the vehcile doesn't
descned to the land point it keeps getting a velocity setpoint from the
smoother that pushes it away from the land point.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
When the yaw estimate is converging, the controller makes the drone yaw
in order to follow the current setpoint. This is unintuitive for the
pilot and it is preferable if the drone continues to fly towards the
same physical direction.
A VTOL plane in MC mode has no yaw setpoint during takeoff because of
weather-vane. To align for the front transition, the yaw target jumps
and caused a step in the controller, making it reach saturation.
With this commit, the previous yaw setpoint is set to the current yaw
when no yaw setpoint is sent in order to create a smooth yaw trajectory
starting at the current orientation when yaw target is suddenly finite.
The yawspeed filter also now contains the yaw speed instead of dyaw in
order to prevent chattering due to dt jitter.
with the goal to make it more clear and the error only appear when
armed but every time the running task doesn't actually match
the mapping inside the start_flight_task() function.
- remove deprecated actuator_controls[INDEX_LANDING_GEAR]
- remove dead code in mc rate controller that used to prevent it from being retracted
on the ground (anyway had no effect as it only affected the actuator_control[LANDING_GEAR]
which wasn't sent to the control allocation)
- for VTOLs handle deployment/retraction of landing gear in AUTO as a MC (retract if
more than 2m above ground, deploy if WP is a landing WP), plus additionally when transition
flight task is called (ALTITUDE mode and higher)
- for FW in AUTO: add logic in FW Position Controller, depending on waypoint type mainly
- manual landing gear settings always come through (a manual command overrides a previous
auto command, and vice-versa)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- Switching to the first order filter that was previously
only in FlightTaskManualAltitude.
- Moving the scaling of full stick deflection to
radians per second into the class.
- precision landing works incorrectly, target position is not updated during the descent above target
- _prepareLandSetpoints needs to update _land_position continuously
Co-authored-by: kapacheuski <kapacheuski@gmail.com>
In review it was requested to have a different name for
manual_control_setpoint.z because of the adjusted range.
I started to investigate what naming is most intuitive and found
that most people recognize the stick axes as roll, pitch, yaw, throttle.
It comes at no surprise because other autopilots
and APIs seem to share this convention.
While changing the code I realized that even within the code base
the axes are usually assigned to a variable with that name or
have comments next to the assignment clarifying the axes
using these names.
To be consistent with all other axes of stick input and avoid future
rescaling confusion.
Note: for the MAVLink message 69 MANUAL_CONTROL it's using the full range
according to the message specs now [-1000,1000].
Fixes a regression from 8bae4e5c0e29f70d5d1d2427ffdef97092be939c, where
the orbit flight task wasn't an extra task (flight_tasks_to_add) anymore
and therefore the command handling wasn't generated.
There was a race condition that could cause several outcomes. The most severe
was that flight_mode_manager gets the command, switches to orbit and then
in the next iteration switches back because commander did not change
nav_state yet. When commander then switches, flight_mode_manager would still
be in the old mode.
This is prevented by storing the command (allowing it to arrive before or
after mode switch), and then apply it after the switch happens.
