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.

according to @dagar's review comment.

- 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.

microRTPS_transport: use preprocessor declarations to setup different build contexts for client and agent code

RTPS IDL: fix const names; make IDL template similar to rosidl_generator_dds_idl/resource/msg.idl.em

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 define was not set anyway, and in my opinion we should
not use different code for tests anyway.

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.

* Added Aion R1 airframe
* Tuned PID values for Aion R1
* Changed to generic mixer and cleaned up configuration

Co-Authored-By: Matthias Grob <maetugr@gmail.com>

Add jerk parameter for auto mode MPC_JERK_AUTO. Specify when a parameter is only used in a certain manual or auto mode

timeout is an int, so it wraps when the poll timeout is >2147ms.
This happened in logger, resulting in poll never returning.

For now we need to ignore this warning which GCC 9 shows for the MAVLink
headers.

GCC 9 complained about stringop-truncation which is a cautionary message
to prevent using strncpy with non-null terminated strings.

We can fix this by copying one byte less than the destination size and
then manually adding the null termination, as we already do.

Since I reorder the points every time I open a pull request I thought I might as well propose this order for the template.

When simulating with lockstep we can raise the speed by setting the env
variable `PX4_SIM_SPEED_FACTOR`. Some inputs like RC, MAVLink heartbeats
from a ground station, or offboard controls via MAVLink are still at the
normal speed which leads to timeouts getting detected in PX4.

To work around this issue we can automatically multiply the timeout
parameters by the speed factor.

- fixes #12012

This fixes the IDs of multi UAVs started with ROS/Gazebo.

Previously the 3 vehicles were displayed in QGC as Vehicle 2, 3, 4.
With this change it is more intuitive Vehicle 1, 2, 3 and this is
also consistent with the way it is documented and how it is in
jMAVSim.

We forgot to add the option -s for jmavsim_run.sh which starts jMAVSim
with the UDP port connecting to the SDK (port 14540).

This fixes cross-talk between the QGC and SDK UDP ports for HITL.