- this was never read
- it was implemented wrong, leading to memory access violations in
publishFence (an integer was passed instead of the fence_s struct)
* msg: add reporting of multi rotor drag fusion
* ekf2: add reporting of multi rotor drag fusion
* ekf2: Add parameters required to tune multi-rotor wind estimation
* ekf2: Add correction for static pressure position error
* ekf2: Use correct air density for position error corrections
* ekf2: fix parameter documentation error
* ekf2: Add separate forward and reverse position error correction factors
* ekf2: Fix formatting and parameter descriptions
* ekf2: Improve comments
px4_shutdown_request() was called from the power button IRQ callback, which
invoked a work queue callback. But on NuttX, the work queue uses a
semaphore, and thus it cannot be called from IRQ context.
This patch switches to publishing an uORB msg instead, which is handled in
the commander main thread.
To increase failure resistance, we could subscribe to the same topic in
another module for redundancy, in case commander runs wild.
The message handling was not obeying action focused messages and high-rate messages properly before. With this change update rates track the desired rates closely. Critical high-rate messages such as ADS-B are queued additionally to guarantee that all received packets are being correctly forwarded.
voltage3V3_v - the sensor 3.3V voltage rail
v3v3_valid - the value of voltage3V3_v may be 0. This
field is a 1 when the HW provides voltage3V3_v
brick_valid - is now a bit mask. A 1 in the postion inticate the
Power controler HW has a valid supply voltage
present (in V window) on that priority
(channel V1..Vn).
The mapping is formed by 1<<battery_status.msg.priority
or using the manifest constanst BRICKn_VALID_MASK
usb_vaild - is now indicated from the Power controler HW or
the usb_connected if Power controler is
not present.
brick_valid == 0 and usb_vaild = 1 implies the FMU is powered
from USB only
brick_valid != 0 and usb_vaild = 1 implies the FMU is powered
from the higest priority brick, providing a 1 bit in brick_valid
and from USB
system_source - This battery status is for the brick that is
supplying VDD_5V_IN
priority - Zero based, This battery status is for the brick
that is connected to the Power controller's
N-1 priority input. V1..VN. 0 would normally be
Brick1, 1 for Brick2 etc
Battery now assigns connected from the api in the
updateBatteryStatus, as well as system_source and priority
This PR is preliminary ground work for FMUv5.
PX4 does not use the NuttX adc driver. But used the same format
for the data returned by the nuttx ADC driver.
There was a fixme:in src/platforms/px4_adc.h "this needs to be
a px4_adc_msg_s type" With this PR the need for
src/platforms/px4_adc.h goes away as the driver drv_adc.h now
describes the px4_adc_msg_t.
This enables control loops that are sensitive to vertical velocity offsets to use a vertical velocity that is kinematically consistent with the vertical position.
José Roberto de Souza
Beat Küng
Vicente Monge
Mark Charlebois
Daniel Agar
Dennis Mannhart
Paul Riseborough
Lorenz Meier
David Sidrane
Nicolae Rosia
ChristophTobler
Paul Riseborough
Mohammed Kabir
Andreas Antener