Special handling for LAND mode: always allow to switch into it such that if used
as emergency mode it is always available. When triggering it the user generally wants
the vehicle to descend immediately, and if that means to switch to DESCEND it is fine.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
The command is sent by a dedicated mavlink command and forwarded to the fixed wing position controller.
The pattern is defined by the radius of the major axis, the radius of the minor axis and the orientation. The pattern is then defined by:
The upper part of the pattern consist of a clockwise circle with radius defined by the minor axis. The center of the circle is defined by the major axis minus the minor axis away from the pattern center.
The lower part of the pattern consist of a counter-clockwise circle with the same definitions as above.
In between, the circles are connected with straight lines in a cross configuration. The lines are always tangetial to the circles.
The orientation rotates the major axis around the NED down axis.
The loitering logic is defined inside its own class used by the fixed wing position control module. It defines which segment (one of the circles or lines) is active and uses the path controller (npfg or l1-control) to determine the desired roll angle.
A feedback mavlink message is send with the executed pattern parameters.
- simplify vehicle_status.arming_state down to just armed and disarmed
- ARMING_STATE_INIT doesn't matter
- ARMING_STATE_STANDBY is effectively pre_flight_checks_pass
- ARMING_STATE_STANDBY_ERROR not needed
- ARMING_STATE_SHUTDOWN effectively not used (all the poweroff/shutdown calls loop forever in place)
- ARMING_STATE_IN_AIR_RESTORE doesn't exist anymore
- collapse ArmStateMachine into commander
- all requests already go through Commander::arm() and Commander::dismarm()
- other minor changes
- VEHICLE_CMD_DO_FLIGHTTERMINATION undocumented (unused?) test command (param1 > 1.5f) removed
- switching to NAVIGATION_STATE_TERMINATION triggers parachute command centrally (only if armed)
---------
Co-authored-by: Matthias Grob <maetugr@gmail.com>
Otherwise the flight time restriction flag gets cleared too early, before
disarming (which puts the vehicle into the previous mode and it might
take off again).
Do the same as DO_REPOSITION wit only the altitude field populated
and MAV_DO_REPOSITION_FLAGS set, which means:
- switch to Loiter mode if not already in it
- set the current altitude to what is specified in the altitdue field,
keep current altitude setpoint otherwise
- keep current position setpoint
- fall back to current estimated position in case a position setpoint
is not finite
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
In review it was requested to have a different name for
manual_control_setpoint.z because of the adjusted range.
I started to investigate what naming is most intuitive and found
that most people recognize the stick axes as roll, pitch, yaw, throttle.
It comes at no surprise because other autopilots
and APIs seem to share this convention.
While changing the code I realized that even within the code base
the axes are usually assigned to a variable with that name or
have comments next to the assignment clarifying the axes
using these names.
To be consistent with all other axes of stick input and avoid future
rescaling confusion.
Note: for the MAVLink message 69 MANUAL_CONTROL it's using the full range
according to the message specs now [-1000,1000].
previous change in logic to hold after mission clear also broke rtl, as non-mission takeoff still published a mission result which allowed entering the mission finished condition and always changing state to loiter (ignoring rtl). new logic only switches navigation states if mission is finish and the nav state is explicitly in takeoff state, or in mission state
- avoid the possibility of unsigned underflow from subtracting two HRT timestamps (uint64_t)
- most of these aren't problematic, but people tend to replicate the pattern, so it's better to be safe
- likely wasn't a problem when people were using hrt_absolute_time() in place, but if using an existing timestamp there's the possibility it's older than a more recent topic update
