The yaw pointing towards the center makes sense since that's the approach
direction anyways. But with the yaw feed forward results in a weird looking
bias when not orbiting yet.
The condition that the vehicle is more than 3m away from the circle line
was too sloppy. That often happens when the radius is changed by sticks.
A reapproach is only necessary when the center is moved and that's only
possible through the orbit command.
The initial approach to the circle to orbit on was very agressive since
it was just the controller trying to stay on the circle reaching the
limits. Now there's first an approach phase in which the vehicle reaches
the circle trajeectory in a smooth perpendicular line before starting the
orbit execution.
Before it was:
- not used anywhere
- copied from an old mission implementation version
- didn't plan in advance
- had a lot of broken cases
- dependent on a lot of parameters
I'm starting with a new relatively simple implementation that works as
expected for a minimum viable implementation and can be improved over time.
The first version is used to approach the circle path in Orbit mode to
verify the interface and get testing such that it gets eventually used
everywhere.
* This fix is necessary because usually uORB structs get initialized with
all zeros and then get filled with the fields that are actually in use.
* The number 0 for the mode slot was already commanding to switch to the
mode in slot one even though for example the joystick input via mavlink
does not use this mechanism at all.
It doesn't affect fixed wing flying anymore. I disabled it for the
deltaquad since I presume @sanderux prefers to have the feature disabled
even when flying in multicopter mode.
AAs discussed in the devcall this functionality is only useful for
rotary-wing (multicopter) flying since it's a big safety hazard to
accidentally bring a fixed wing out of an auto mode e.g. a mission
and fly away in a straight line or into an obstacle.
@bkueang and me realized that on every frame we tune the integral gain for
the roll and pitch rate controller is much too low. Usually it needs to be
increased to 0.3 or even 0.4 to have better "locked in" flight performance
and 0.2 seems like a good compromise for a safe default.
CMAKE_TESTING should automatically be enabled
but I hoped to do that in the test.cmake
target specific options and not in the main
CMakeLists. I have to see if I can make that
order work. Here the hotfix to make CI work
again.
But fix the two crucial problems:
- When to begin the ramp?
There's a calculation now for the velocity ramp initial value
such that the resulting thrust is zero at the beginning.
- When to end the ramp?
The ramp is applied to the upwards velocity constraint and it
just ramps from the initial value to the velocity constraint
which is applied during flight. Slower/going down is always possible.
Without always updating the takeoff state it will not get skipped when
the takeoff happened manually and when you switch from manual to position
mode the drone goes to idle and falls.
There are two local_position_setpoint in the position controller.
One describing the setpoint the task gives to the position controller
and a second one with the output of the position controller. I corrected
the wrong one during takeoff because the new takeoff thrust ramp runs after
the controller and not before.
The velocity ramp had problems with:
- different vehicle tunings resulted in the start value of the resulting
thrust ramp staring either higher and lower than zero thrust.
lower -> delay of beginning
higher -> small jump at beginning
- when a task set position and velocity at the same time during takeoff
(which AutoSmoothVel does) it resulted in a velocity setpoint
jump at the end of the ramp because the additional velocity
setpoint correction from the position controller was not considered.
The thrust ramp should now be very deterministic:
- always start at zero
- always end at the curreant thrust setpoint output
of the complete position controller
The initial idea of the flight task architecture was that
a task can freely set it's setpoints and doesn't have to
worry about takeoff and landing. It would just takeoff
when it's landed and there's a setpoint to go up and
land when it puts a setpoint that pushes into the ground.
With the takeoff logic there are some significant interface
problems depending on the way a task is implemented:
From the setpoint is not high enough to trigger to
an unexpected takeoff because of some estimator
fluctuation affecting the setpoint. It's easiest to solve this
by allowing the task to determine when a takeoff is triggered.
If no condition is implemented by default a task is not
allowing a takeoff and cannot be used to get the vehicle
off the ground.
After boot the user is in manual mode and if he has an RC
but doesn't switch out the thrust gets set to the throttle stick
position. When he then starts a takeoff from tablet the thrust is still
high while arming and the land detector immediately sees a takeoff
skiping smooth takeoff from the position controller.
- start from a velocity setpoint pushing into the ground
to ramp from idle thrust up.
- start with a bit higher velocity setpoint threshold to make
sure the vehicle has a chance to really get off the ground.
- calculate ramp slope from initialization setpoint to the desired one
instead from zero to the desired. this ramps up quicker when you demand
a very small upwards velocity like the AutoLineSmoothVel and
ManualPositionSmoothVel tasks do at the beginning.
- don't stay in the takeoff ramp depending on the land detector, this
is unnecessary.
The comments and variable names were partly misleading.
I grouped all members, hopefully gave them more
understandable names and adjusted the comments.
There were two rather confusing function calls one to check
if smooth takeoff needs to be ran and one that updates it.
I combined them and documented the interface correctly
making the parameters non-reference const floats.
Example: Before when you passed "make tests TESTFILTER=Attitude"
and subsequently "make tests TESTFILTER=Atti" it found the string
"TESTFILTER=Atti" in "TESTFILTER=Attitude" and hence the check if
the configuration is already correct passed. The fix checks for
the configuration parameter including the subsequent space separator
and after that strips the space away again such that the list
VERIFIED_CMAKE_OPTIONS doesn't contain trailing spaces.
visibility.h is included globally in PX4 via cmake compile flags.
It contains poisoning the exit() command which is used by gtest
to close the test application. Removing the flag for gtest compilation
fixes the compile error:
gtest.cc:4757:7: error: attempt to use poisoned "exit"
To be able to still infer the direction of the thrust vector we
limit it to a minimal length even if MPC_THR_MIN is set to zero.
Note: This is a hotfix for certain specific applications.
The direction of the thrust vector in this corner case is very
likely to get into the tilt limit which is generally undesired.
the condition to enter the rc mode switch evaluation was neglecting
the first connection of an RC when "no RC switch changed". this means
depending on the actual initialization values of _last_sp_man and the
desired mode preselected on the RC while connecting it would not get
evaluated.
It wasn't possible to fly faster than cruise speed even if planned
in the mission.
Limiting the planned cruise speed is necessary because
the smoothed trajectory mission plans to the _mc_cruise_speed and
if that's higher than the maximum it gets capped for safety by the
position controller and the result is a jerky flight.
- Remove unnecessary in between rate limits member vectors.
- Only switch the yaw rate limit in auto modes,
other values stay the same anyways.
- Fill gain vectors with parameters in one line.
Before if you were above the maximum altitude you could not command to
go down anymore until the position controller had overshoot to under the
maximum altitude again.
Matthias Grob