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.
In the normal sitl `commander takeoff` case, the takeoff jump was never
actually carried out because the default altitude radius is set to 3m
and the takeoff altitude to ~2m which means that the takeoff waypoint is
"reached" immediately.
This works around this edge case by using the altitude between the home
altitude and takeoff altitude divided by 2 as a acceptance radius.
This adds the capability to forward the commands
- MAV_CMD_VIDEO_START_CAPTURE
- MAV_CMD_VIDEO_STOP_CAPTURE
- MAV_CMD_IMAGE_START_CAPTURE
- MAV_CMD_IMAGE_STOP_CAPTURE
at waypoints which will then be sent over mavlink to component id
100 aka MAV_COMP_ID_CAMERA.
We don't need to poll for vehicle commands, we will get them anyway by
doing orb_check. Also, the polling for them wasn't implemented correctly
anyway.
It makes more sense to set the optimization flags on a platform basis
instead of individually for each module. This allows for different
optimization options for SITL, NuttX, Snapdragon, etc.
This reset the cruise speed which can be set by mission items/waypoints
to set a custom speed. Once, switched out of mission, it makes sense to
use the speed set by the param again.
* navigator/mavlink: always send last reached item
Since we can't rely on mavlink that every message arrives, it makes
sense to continuously send the last reached waypoint.
* navigator: don't report reached for takeoff
If a takeoff waypoint has been inserted, we should not report that we
reached a mavlink mission item because we actually have not.
The mission feasability checker was called with the same arguments
twice which made it hard to understand when a mission is marked valid.
The mission check should run in these two cases:
- When initializing (if home comes up) if there is already a mission saved.
- When the mission gets updated.
The mission feasability checker was called with the same arguments
twice which made it hard to understand when a mission is marked valid.
The mission check should run in these two cases:
- When initializing (if home comes up) if there is already a mission saved.
- When the mission gets updated.
- voting is now at a central place instead of duplicated within the
estimators
-> this also means that estimators that did not do voting so far,
now have voting, like ekf2
- estimators requiring more than that can still subscribe to the raw
sensors
- allows sensors_combined to be 3 times smaller
- reduces logger, memcpy (cache) & RAM overhead
- all modules requiring only 1 or 2 sensor values now automatically get
the voted result
- this also adds voting to baro
Lorenz Meier