Exclusive open is not required, but we now need to ensure the queue size
is set atomically.
It avoids a race condition between 2 single-instance advertisers,
where one of them would fail to open the node with -EBUSY.
Possible race conditions (they all happen between the check of existence
of a topic and trying to create the node):
- single instance, with multiple advertisers during the first advertise:
both advertisers see the topic as non-existent and try to advertise it.
One of them will fail, leading to an error message.
This is the cause for telemetry_status advert failure seen in SITL in
rare cases.
- multi-instance: subscription to non-existing instance -> px4_open fails,
and the subscriber tries to create the node. If during that time a
publisher publishes that instance, the subscriber will get (instance+1)
(or fails if the max number of instances is exceeded).
This is a race that goes pretty much unnoticed.
- multi-instance: 2 publishers can get the same instance (if is_published()
is false in case both have not published data yet).
This can also go unnoticed.
Therefore the patch changes where _advertised is set: it is now set
directly during the advertisement instead of during publication.
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.
@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.
Reduce the I gain for high rate errors to reduce bounce-back effects after
flips. Up to 200 degrees the gain is almost not reduced (<25%), so this
will only take noticeable effects for large errors (setpoint changes),
where we actually want to have an effect.
This allows to increase the MC_*RATE_I parameters w/o negative effects
when doing flips (i.e. bounce-back after flips).
The 400 degrees limit and the x^2 are empirical.
The better the rate tracking in general (high P gain), the less this is
required (because of the lower tracking error). At the same time it also
does not harm, as the i_factor will always be close to 1.
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.
This tries to make the visibility.h header clearer and better
structured. We don't actually need the ifdef for lockstep enabled or
disabled because that's now handled elsewhere.
This makes sure we add the lockstep_scheduler_test even if the
ENABLE_LOCKSTEP_SCHEDULER is not set to yes. This means the
lockstep_scheduler is not used for SITL but the CMakeLists.txt file
still used and the test added.
Beat Küng
Fabian Schilling
dlwalter
RomanBapst
Mathieu Bresciani
Lorenz Meier
Angel
Matthias Grob
David Sidrane
Martina Rivizzigno
TSC21
Daniel Agar
Julian Oes