Since using more than 256 mission items has been tested and fixed, the
limit can now be raised to more than 256 (but smaller than UINT16_MAX).
Since the whole file is allocated in advance on NuttX, the limit there
is (arbitrarily) set to 2000. For POSIX archs such as SITL, we don't
really need to constrain ourselves any longer.
If the vehicle was already in air on takeoff and the waypoint gets converted to a regular waypoint the wait / delay time does not get reset to zero. This change ensures the next mission item is approached immediately.
We don't want to reset the current waypoint because this means that the
ground stations see a current waypoint of 0 if the current waypoint is
not updated e.g. when we're not in mission mode.
However, it is wrong to send 0 as the current waypoint because if we
switch back to mission mode, it will actually go to the last current
waypoint and not 0.
- weathervane on takeoff
- separate cruising speeds for VTOL in MC and FW
- cruising speed resets
- mission work item logic is more clear
- fixed double execution of certain work item states
- enable cruise speed change on the fly by command
- moved VTOL transition target position generation to mission code and set always
Move RC and DL failsafe actions handling from navigator to commander (credits to @AndreasAntener)
Separate manual kill switch handling via manual_lockdown to prevent override and release of software lockdown by RC switch
Other changes:
Add failsafe tune
Fix LED blinking for Pixracer
Return back support for rc inputs in simulator but now it is configurable via cmake
The stack size was generally ok but seemed to get exhausted in the case
of a waypoint which is too far away and therefore exercises some more
code in the mission feasability checker.
Generally, we should have more margin in the navigator stack size
because there are a bunch of different code paths that can happen.
The stack size was generally ok but seemed to get exhausted in the case
of a waypoint which is too far away and therefore exercises some more
code in the mission feasability checker.
Generally, we should have more margin in the navigator stack size
because there are a bunch of different code paths that can happen.
This fixes the following corner case:
1. Upload a mission.
2. Set mission mode.
3. Set loiter mode.
4. Arm.
At this point it will shoot up and go to the takeoff waypoint even
though we're not in mission but in loiter mode.
The fix makes sure that the triplet is reset to invalid (and idle) in
loiter mode if we're landed and disarmed.
It will lead to the vehcle sit in idle on the ground until you issue a
start mission (or takeoff) command.
Current implementation checks against geofence only if it is in polygon form.
When it's created via params, it accepts all the waypoints as the number of vertices = 0.
Thus, changed the function to the one that is used to check whether geofence is breached in flight.
This change fixes a wrong behaviour when a takeoff command is sent.
An example:
- MIS_TAKEOFF_ALT set to 10 meters
- Takeoff command with alt setpoint of 2 meters
Old behaviour:
1. Climb to 10 meters -> takeoff WP reached
2. Go to setpoint at 2 meters
New behaviour:
1. Climb to 10 meters and stay there but notify that altitude was
overridden.
Julian Oes