The sensors app assumed that all topics are published on boot which is not necessarily true and it assumed that all publications had valid data. This change ensures that topics are initialized as they update the first time and that the consistency check only runs on topics which carry valid data.
- weathervane on takeoff
- separate cruising speeds for VTOL in MC and FW
- cruising speed resets
- mission work item logic is more clear
- fixed double execution of certain work item states
- enable cruise speed change on the fly by command
- moved VTOL transition target position generation to mission code and set always
Move RC and DL failsafe actions handling from navigator to commander (credits to @AndreasAntener)
Separate manual kill switch handling via manual_lockdown to prevent override and release of software lockdown by RC switch
Other changes:
Add failsafe tune
Fix LED blinking for Pixracer
Return back support for rc inputs in simulator but now it is configurable via cmake
this fixes a race condition between the DMA completion handler
updating registers in px4io and the mixer used for handling the
override state. The register set code could set r_page_servos[]
between the time when pwm_limit_calc() is called and the servos are
actually output.
* Loosen thresholds for gyro consistency check until temperature compensated units are the norm
* Cut down string lengths so they make it through the MAVLink transport as a whole
This change makes the mixer load and reset operation closer to thread-safe. It was guarded one-way before and in only one location. This change ensures that its being locked out from both directions. The accesses to the locking variables still need work because they are non-atomic.
This change makes the operation more robust as it flags the whole group invalid in the first step. This should not be confused with being thread-safe - to be thread-safe, all accesses to _first and the following linked list need to be guarded by a mutex. This should be done outside of the mixer in the driver though, as the method depends on the board architecture.
NuttX had the CRTSCTS define incorrectly set for only output flow control, which broke our flow control logic. This commit patches NuttX and puts in addition a guard in place to prevent any future issue with the non-POSIX define being incorrect.
This has been debugged and identified by @ecmnet, which was the main contribution for this patch.
This patch fixes two issues:
* It sends the message on the first call, making sure that the first update gets sent out.
* It improves the rate scheduling. In an experiment with 0.5, 50 and 250 Hz all rates were correct within 0.3% of the intended rate.
Paul Riseborough