Note: ecl needs to be updated at the same time
because as soon as the ecl is compiled within PX4 Firmware
the matrix submodule checked out by PX4 Firmware is used
for every call to a matrix or quaternion.
- one warn_rate_limited was missing
- vel_sp_slewrate was in the wrong order for smooth slowdown/speedup on takeoff and landing
- slow_land_gradual_velocity_limit was replaced by calls to math::gradual
- smooth takeoff speed got controllable by user input
- comments were corrected
- an additional check for the sanity of velocity setpoints was added
because we need a workaround for the broken auto takeoff logic which can start the vehicle with a loiter setpoint
in this case the very first moment is still a jump but then it gets taken over by the fix gradient ramp
this can basically be reverted after the auto takeoff logic is fixed
currently when the vehicle is landed again (not after bootup) the core position controller does not run anymore
therefore the velocity limit ramp in some cases did not get reset correctly
speed limiting in auto takeoff mode only needs to be limited when the user did not take over
adresses:
there were setpoint twitches at the beginning and end of my smooth takeoff routine
it was to slow and not configurable
it was only available for automatic takeoff
auto takeoff was pretty chaotic and bypassed the velocity controller until some magic condition
the goal of this approach is to make the behaviour and smoothness more predictable and reuse the exact same logic for manual takeoff
because there is no sense to have different angle scalings into different directions
it would lead to unintuitive piloting experience
acceleration is directly coupled to the tilt angle regardless of possible assymetric multicopter vehicles
because in altitude mode we have a baro available and can therefore check vertical movement
we can not check horizontal movement but I consider the checks for landing still pretty safe
unlike in manual mode we are not allowed to disarm before land detection in altitude mode
to prevent a setpoint step when moving the stick over the border of the deadzone
and to enable very small inputs even from a control stick that needs a big deadzone
Even for well calibrated RC sticks 5% stick movement is a too small margin for the end user that might not land because of this.
15% is still clearly restricting the stick far down.
Filter gets unstable if cutoff is above sample rate/2.
Filter initial frequencies do not matter a lot because they get replaced by parameters anyways.
Filter delay values get reset to 0 when the filter is reconfigured otherwise there can be some weird spikes in the output.
Filter output gets constrained to the range again because of possible overshoot.
Ground detect: pilot want down or we are on minimum thrust by auto land but no vertical movement
-> Controller should relax x,y corrections and even ramp down desired thrust
Landed: All other conditions are eventually met
until now the desired thrust was simply the absolute value of the thrust setpoint vector
but a multicopter is only capable of producing thrust in its (negative) body z axis
this leads to excess thrust during attitude tracking errors
one important use case is:
trying to land with minimal thrust in NED z axis against gravity
but the position controller still correcting some small horizontal estimation errors
then this prevents unwanted thrust in a completely wrong direction
the velocity controller was misusing the integral part to account for the constant gravitational force offset
the hover throttle from the parameter is now is now directly used as feed forward for the thrust in world z direction
the integrator compensates for inaccurate paarameter but should now be idealy zero
When we open the file handle to write back the lines in binary mode, we don't change the line endings but instead leave them as they were before. This is impotant for Windows users as Python on Windows otherwise adds CRLF endings to the parameter files and they can't be correctly parsed by NuttX any more.
Matthias Grob