And fix some IO bugs:
- PX4IO_P_STATUS_FLAGS_RAW_PWM was never cleared. This meant that after a
'pwm test' command, normal mixing was not possible anymore.
Fixed by remembering when we are in test mode and not sending
PX4IO_PAGE_CONTROLS during that time. PX4IO_P_STATUS_FLAGS_RAW_PWM is
cleared when PX4IO_PAGE_CONTROLS are received.
- when entering test mode w/o specifying all channels, the other channels
were not set at all, which means they could still be set to values from
a previous test call.
This is fixed by setting all channels to disarmed when entering/leaving
test mode.
Required for pwm_out_sim: only publish actuator_outputs when we get
actuator_controls. Otherwise lockstep startup does not work.
The issue was there before but hidden, due to a long poll timeout.
Works with HIL too.
Checking the first output_limited for a disarmed value is fragile.
For example a disarmed value might be within the range of min/max output
values and could then be triggered while armed.
This could happen in the following cases:
- IRQ/publisher rate is faster than the processing rate, and therefore
WorkQueue::Add is called at a higher rate
- a long-running or stuck task that blocks the work queue a long time
Both cases are not expected to happen under 'normal' circumstances (if the
system runs as expected).
px4_sem_timedwait expects an absolute time (from CLOCK_REALTIME), but a
relative time was provided.
This is only relevant if FLASH_BASED_DATAMAN is set (only on Intel aero).
Fixes a potential buffer overflow if an MC/helicopter mixer is used that
exceeds the number of physical pins.
This is not a useful/flyable configuration, but the system still should
not crash.
But only on the first 4 FMU outputs, as the next ones conflict with px4io
serial dma (UART8_RX)
RX DMA is disabled on the GPS port as well (conflicts with TIM1).
This reloads the timer configuration before triggering DMA. Without that,
in rare cases, there were 17 bits sent instead of 16.
The 1. bit (1. pulse) was always wrong (too much), the rest of the bits
were the correct DShot packet that was meant to be sent.
Script to update include paths:
for i in $(grep -rl 'include <px4_work_queue' src platforms); do sed -i 's/#include <px4_work_queue/#include <px4_platform_common\/px4_work_queue/' $i; done
- the last check expects pre_arm to run so we need to enable the
preflight checks. This is closer to the real system.
- as a result we need to enable HIL for other tests so that the sensors
are not checked.
This allows to bypass preflight and prearm checks.
During development there are regular cases where I just want to arm the
board/vehicle no matter what, and the preflight checks are guaranteed to
fail (e.g. sensors uncalibrated, inconsistent, powered via USB, etc.).
Allowing an easy and quick way to arm (assuming you know what you are
doing) helps to speed up development considerably and is less frustrating.
Reason: if you don't want preflight checks, you don't want prearm checks
either (these are the circuit breakers, like usb connected check).
The other changes are cleanup and rework of operations.
In most cases, arming_state_transition is called with fRunPreArmChecks set
to true, so no change in behavior.
The cases with fRunPreArmChecks=false are:
- unit tests
- in_arming_grace_period=true (quick arming after disarm)
- VEHICLE_CMD_PREFLIGHT_CALIBRATION (does not transition to armed)
The file writer thread could get into a state where it blocked infinitely
on pthread_cond_wait() (or rather until the logging stops).
This is very rare and the following conditions must be met:
- the buffer is almost empty (<4KB filled), so that the writer thread does
not write anything.
- an fsync call is scheduled (happens once every second)
- the fsync call takes a long time (several 100ms), during which time the
complete log buffer fills up.
The main thread would then get into dropout state where it does not call
_writer.notify() anymore.
Notifying the writer thread on every loop update of the main thread fixes
that.
It does not increase resource usage.
This fails the build if a wrong version tag is used.
A wrong tag leads to wrong reporting in QGC, and incorrect error messages
about minimum required PX4 version.
It also leads to wrong statistics on Flight Review.
NuttX 7.28 seemed to handle this gracefully, but officially passing NULL
results in undefined behavior, and with 7.29 leads to a hardfault.
This happens on configs with flash-based params, on the first unsuccessful
import attempt.
A board only needs to define:
#define RC_SERIAL_PORT "/dev/ttyS4"
Then it can optionally define one or more of the following:
#define RC_SERIAL_SWAP_RXTX
#define RC_SERIAL_SINGLEWIRE
#define RC_INVERT_INPUT(_invert_true) px4_arch_gpiowrite(GPIO_SBUS_INV, _invert_true)
Beat Küng