By declaring the params above the navigator modes inheriting from
mission block we make sure the params in navigator are set before
read in the constructor of mission block.
This should fix the case where the driver initializes even though the
device is not found. The change changes the behavior to return ERROR
if the whoami call fails several times instead of returning OK.
Also, the reset() and thus probe() calls are moved before initializing
the ringbuffer and device name.
* match max vel in col-prev to regular pos ctrl
* change warning criterium to avoid float error
* disable push back from obstacles
* use floats consistently
* Cherry pick the vehicle_imu PR #9756 src/modules/simulator directory work to submit as standalone PR.
* Modify the accelsim init method mag_report usage to match usage in measure() and mag_measure() methods in the class.
* Incorporate review comments in the accelsim.cpp init() method and also make the same modifications in gyrosim.cpp.
* Delete unneeded mag_report initialization from accelsim init() method.
* Deprecate unneeded measure() call from accelsim.cpp init() and gyrosim.cpp init().
When PX4FLOW is connected to PX4 through MAVLink (e.g., through a USB
port), the timestamp assigned to the distance_sensor was wrong. This fix
uses the same timestamp assigned to the optical_flow message created from
the same OPTICAL_FLOW_RAD MAVLink message.
Signed-off-by: Gabriel Moreno <gabrielm@cs.cmu.edu>
It wasn't possible to fly faster than cruise speed even if planned
in the mission.
Limiting the planned cruise speed is necessary because
the smoothed trajectory mission plans to the _mc_cruise_speed and
if that's higher than the maximum it gets capped for safety by the
position controller and the result is a jerky flight.
* drivers, magnetometer: added ak09916 driver to support the mag driver emulated by the Here2 gps
* boards: set yaw 270 rotation for external ak09916 driver and only start it for the PH21
* drivers: only start ak09916 when icm20948 is not available on a ph21 setup
When using QGC and/or the Dronecode SDK it was possible to get in a
state where the two mavlink instances were both publishing their last
heartbeat_time and cause commander to consistently toggle between
data link lost and regained. With this fix, we only ever look at the
very last heartbeat time and therefore seem to avoid this issue.
