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
This fixes the following case:
1. VTOL in auto mission descends to land
2. _in_landing is set to true correctly
3. _lnd_reached_ground is set to true because it's detected, motors idle.
4. The vehicle might drop for a few centimeters and _acc_z_lp goes back
up above 4m/s^2, so freefall is detected.
5. The motors spin up again, and _in_landing and _lnd_reached_ground are
both reset to false.
6. Since we're floating at a few centimeters, we can't actyally get to
_vel_z_lp > 0.5, and therefore _in_landing is never triggered after.
7. Thus we never finish the landing.
This is fixed by only resetting _lnd_reached_ground to false but
leaving _in_landing true.
Problem: The drone started taking off in LOITER (HOLD) mode even if on
ground and did not do a proper takeoff jump. The effect was mostly a
hovering close above ground or tilting/flipping because of integrator
wind-up.
Solution: Stay at minimum throttle until a takeoff setpoint is issued.
This adds the possibility to use offboard velocity control in the body
frame and not just the NED (world) frame.
The frame is set in the set_position_target_local_ned message and passed
on to mc_pos_control in the position_setpoint topic.
If velocity offboard control is used, it makes sense to lock/hold
position if the velocity input is 0. If this is not done, we will slowly
drift because nothing is integrating to keep the UAV at its position.
- fixed a bug where tilt compensation was done also when the horizontal
velocity was controlled. This is not needed because in this case
the controller outputs a 3D thrust vector.
Signed-off-by: Roman <bapstroman@gmail.com>
This resolves a bug where a takeoff would go sideways instead of
straight up. What happened was that the position setpoint got shifted
around even though there was actually no real setpoint set but only a
setpoint of type IDLE. This then lead to a position setpoint far away
from the takeoff point and therefore scary takeoffs.
This fix prevents the part of the position controller which
moves/integrates the position setpoint from running in the case of an
idle setpoint.
This bug could be reproduced by switching the vehicle to mission mode
without a valid mission, then switch to hold mode, and then send the arm
and takeoff command.
* Fix jmavsim HITL simulation of MAV_CMD_DO_REPOSITION in the case where you have no radio attached to the PX4 and so you have disabled RC link loss for that reason (set NAV_RCL_ACT = 0) but you still want the jmavsimulation to work. The line of code changed here causes failsafe RTL to kick in without this fix.
* Add altitude hold option using Z position control, while doing velocity control on vx and vy.
* Fix style and rebase issues
Since orb_copy is guarded with a orb_check, we ended up not having the
corrent landed state in the beginning which could lead to some
unexpected behaviour on takeoff.
Dennis Mannhart