* FW actuators fully on the entirety of front and back transition
* back transition ramp up to full MC weight half way through back transition
* increase maximum front and back transition times
* navigator don't reset transition altitude
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.
Lorenz Meier