This fixes a potential dead-lock when 'uorb status' was used via MAVLink
shell.
The dead-lock chain is: DeviceMaster::lock() -> printf -> output to a pipe,
which blocks until a reader reads the data. In that case it's mavlink.
If mavlink makes a call that requires DeviceMaster::lock() (such as
orb_exists), it dead-locks.
This patch moves all printf's out of the locked state.
- when either terrain data was temporarily not valid (flying at high
distance to the ground) or the vehicle was not close to the ground
(_param_ekf2_gnd_max_hgt) the ekf switched to using the land detector
ground effect flag.
Signed-off-by: Roman <bapstroman@gmail.com>
- takeoff help is used for fixed wings, it increases the altitude setpoint
after a launch. A vtol does not need this as it's already sufficiently
high up in the air.
Signed-off-by: Roman <bapstroman@gmail.com>
the condition to enter the rc mode switch evaluation was neglecting
the first connection of an RC when "no RC switch changed". this means
depending on the actual initialization values of _last_sp_man and the
desired mode preselected on the RC while connecting it would not get
evaluated.
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.
* 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>
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.
Beat Küng