- ecl in PX4/Firmware (a730f0f5ce7a2cc909cb3d0dfab5f0106a9b3aeb): bb950a1550
- ecl current upstream: e3d1ade660
- Changes: bb950a1550...e3d1ade660e3d1ade 2021-03-12 Daniel Agar - EKF: use flow for vel test ratio if only active source of horizontal aiding
- rotates accel & gyro FIFO data before publication both to simplify downstream usage (including log review) and fix other issues
- to best handle int16_t data rotations are now either performed with swaps if possible, otherwise promoted to float, rotated using the full rotation matrix, then rounded back to int16_t
- fix sensors/vehicle_angular_velocity filter reset both with proper rotation and new calibration uncorrect helper
- in FIFO case filtering is done before calibration is applied, but we need to handle a possible reset from a completely different sensor (vehicle body angular velocity -> sensor frame uncorrected data)
With this change we prevent the case where arming silently fails within
the first 10 seconds after boot.
Also, we now set the sensors as healthy as soon as the ekf is healthy,
and don't wait 10 seconds without actually checking.
The user-defined literals for milli- and microseconds
should have argument names matching their units. The
current argument names 'seconds' is probably an oversight.
Refering to the refernece manual:
Tx queue operation is configured by programming FDCAN_TXBC.TFQM to 1. Messages
stored in the Tx queue are transmitted starting with the message with the lowest message
ID (highest priority). **In case that multiple queue buffers are configured with the same
message ID, the queue buffer with the lowest buffer number is transmitted first**
Tx FIFO operation is configured by programming FDCAN_TXBC.TFQM to 0. Messages
stored in the Tx FIFO are transmitted starting with the message referenced by the get index
FDCAN_TXFQS.TFGI. After each transmission the get index is incremented cyclically until
the Tx FIFO is empty. The Tx FIFO enables transmission of messages with the same
message ID from different Tx buffers in the order these messages have been written to the
Tx FIFO
The issue will be cancelation:
The FDCAN supports transmit cancellation. To cancel a requested transmission from a
dedicated Tx buffer or a Tx queue buffer the Host has to write a 1 to the corresponding bit
position (= number of Tx buffer) of register FDCAN_TXBCR. Transmit cancellation is not
intended for Tx FIFO operation.
But there is nothing preventing it. This seems to indicate it will
work. When a transmission request for the Tx buffer referenced by the get index is canceled, the
get index is incremented to the next Tx buffer with pending transmission request and the Tx
FIFO free level is recalculated. When transmission cancellation is applied to any other Tx
buffer, the get index and the FIFO free level remain unchanged.
PX4 uses banks of 8 outputs as a logical structure. Boards that have
more outputs than 8 get multiple instances. This is an arbitrary choice
that helps with overall structure and enables the mixing of different
device classes (like FMU, IO or UAVCAN).
- fully respect datasheet quality and shutter metrics for mode changes
- use MOTION pin for scheduling if available
- log light mode
- refactor common enable LED code
- respect read and write time delays
Beat Küng
Daniel Agar
PX4 BuildBot
Mohamed Moustafa
Star Simpson
Lorenz Meier
Julian Oes
Morten Fyhn Amundsen
David Sidrane
bresch
Matthias Grob
Dima Ponomarev
garfieldG
Inhwan Wee