During the first few seconds after takeoff, the failure detector is allowed to
trigger motor lockdown.
This is done for safety reasons to detect tipping-over or unstable
tuning gains
- update to NuttX with stm32f4 and stm32f7 SPI DMA internal buffers
- remove explicit DMA buffer allocations from new IMU drivers
- restore original BOARD_DMA_ALLOC_POOL_SIZE
- decrease SPI DMA thresholds based on fmu-v2/v3/v4/v5 bench testing
Supposedly multiple sensor callbacks were supported; in reality, this
was not the case, as the mag SensorBridge in particular can only
calibrate one compass, leading to a race condition on which compass
appears first on the bus to get published and calibrated (with no
warning to the user that the 'wrong' compass is being used).
For sensors with existing generic driver classes (baro and mag) the
sensor bridges use these classes for the driver registration, and uORB
publication, and calibration interface (ioctl) handling.
UavcanGnssBridge did not support more than 1 GNSS callback/publisher.
This has now been fixed; it works the same as the baro, mag, and flow
sensor bridges. The EKF2 still doesn't support more than 2 GPS
publishers, however.
10kHz sampling seems excessive, given that the sensor is expected to output
at 100Hz.
Also don't reschedule immediately in case we have not received any data.
This is another new InvenSense sensor with max output data rate of 32 kHz (both accel & gyro), on board anti-aliasing filter, and accel range 32G. Overall quite similar to the ICM-42688-P added in #14420, but with doubled accel range and without the optional high resolution output or clock sync.
This is a new InvenSense sensor with max output data rate of 32 kHz (both accel & gyro), on board anti-aliasing filter, optional higher resolution output (18 bit accel, 19 bit gyro), and clock sync.
This commit handles incoming MISSION_REQUEST_LIST messages such that
they are no longer ignored if the previously requested mission has
sent all mission items but the ack has never been received.
This was the cause for frequent "IGN REQUEST LIST: Busy" warnings
The landing thrust limit was after the position controller and
could be inconsistent with what the takeoff limit did. This
resulted in different thrust values sequentially getting applied
during landing.
This was only necessary for stabilized mode before #10805.
The unit length thrust setpoint will anyways not be available
anymore soon because it gets replaced with the acceleration
setpoint in m/s².
This is an attempt to fix an edge case in the triplet publication which
can lead to crashes on autopilots with slow SD cards.
The sequence of events before this patch is:
1. Switch to POSCTL when disarmed. At this point current valid with
setpoint idle is published.
2. Arm, takeoff, and fly using joystick/RC.
3. Switch to RTL (or trigger RTL using RC loss). At this point the
setpoint is valid but still idle and the motors will shut off.
4. Once navigator has published the new setpoint (which can take up to
1.5 seconds on slow SD cards) we will hopefully recover.
With this patch we omit this edge case, so we never publish this idle
setpoint when landed. The assumption is that this idle setpoint is no
longer required with the current flight task code, however, that needs
to be further verified.
Removes the calibration on startup, as these values were overwritten by
the system calibration values anyway.
So the only difference is that if all calibration scales were equal to 1,
the driver startup would have failed.
