Currently only for the Z axis. If the current downward velocity is more
than twice the maximum allowed value, the emergency braking mode is
activated. In this mode, a higher vertical acceleration and jerk is used
until the vehicle stops moving.
Only needed for Makefile-based builds:
gmake[3]: *** No rule to make target 'src/modules/flight_mode_manager/FlightTasks_generated.hpp', needed by 'events/px4.json'. Stop.
Because based on the numerous complaints it was disabled by default
(only velocities above 10m/s were limited)
and since then no one intentionally used it anymore. But
there were some minor investigations of drones not reaching
their maximum speed which always showed 10m/s.
The both results of ?: should be of same type, and some compilers give error
on this:
" implicit conversion from 'float' to 'double' to match other result of conditional"
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
This was only handled outside because FlightTaks lived in the
multicopter position controller which produces the data that was
needed but now it doesn't make sense anymore to handle this
subscription separately.
It's better to have it inside the base task to have the data available
on task activation sucht that e.g. Altitude mode can take over smoothly
from Position mode.
This entire feature only has an impact if the last mode set
a huge acceleration and we have to take over as smooth as possible.
But it's stil lworth fixing.
This was an idea to be able to reinitialize on mode change e.g. from
Holde mode to Land mode which are currently all still handled by
FlightTaskAuto and don't require a task switch.
But I found out it leads to issues because the last setpoint and the
ekf reset counter state from the previous task are lost and as a result
the setpoint transition cannot be handled consistently anymore.
- handle SET_POSITION_TARGET_LOCAL_NED and SET_POSITION_TARGET_GLOBAL_INT with ORB_ID(trajectory_setpoint)
- FlightTaskOffboard not needed at all
- bypass position_setpoint_triplet entirely (start removing extraneous fields)
- simplify offboard_control_mode to map to supported control modes
The drag is based on max_acc/max_vel, which means that increasing the
maximum velocity leads to slower braking (at the same starting speed).
Especially a combination of small max_acc (slow responsiveness) with high
max_vel led to an exceedingly high braking distance.
This improves that while still being smooth.
The mapping itself was seprated out into a calls because it was reused
for the experimental nudging implementation.
The position resets which were handled correctly before now
change the wrong setpoints and I adjusted.
The nudging has to be before any filtering, then these member setpoints
which are essentially copies are not needed anymore.
The velocity setpoint of the position controller
does a jump when unlocking position with a non-zero position error.
This is solved by using the velocity setpoint feedback to smoothly
take over.
With a higher responsiveness, after centering the stick, the velocity and
acceleration setpoints could oscillate around 0 and never reach 0, due to
discretization.
This also prevented position lock engagement.
In some cases e.g.: (VTOL in wind) a good tracking cannot be
achieved. This condition then needs to be relaxed, otherwise the
drone cannot land properly.
Moving the command handling to a separate function that gets called
whenever a vehicle command is available to always react on commands
and not just when already a task is running.
This solves e.g. commanding an Orbit when in Staibilized.
Matthias Grob