internal PX4IO safety_off state is removed and replaced with a normal safety button event. From this 'commit' commander is taking care of the PX4IO safety.
internal PX4IO safety_off state is removed and replaced with a normal safety button event. From this 'commit' commander is taking care of the PX4IO safety.
This fixes an invalid memory access when exiting the module:
exit_and_cleanup destroys the object, but lock_guard is destructed after
and accesses the lock.
- fixes the deadlock in px4io ioctl mixer reset
- px4io Run() locks (CDev semaphore)
- mixer load goes through px4io ioctl MIXERIOCRESET which calls MixingOutput::resetMixerThreadSafe()
- MixingOutput::resetMixerThreadSafe() stores a Command::Type::resetMixer command in an atomic variable, schedules a work queue cycle, then sleep spins until the command is cleared
- the execution of the cycle eventually calls back into PX4IO::updateOutputs(), which tries to lock (and waits forever)
- previously an invalid decode would continue to be transferred to the FMU (at 50 Hz) and published to the rest of the system as successfully decoded new RC data
- by only publishing new successful decodes we can more effectively discard invalid data in downstream consumers
The current practice of adding topics to the default set isn't scalable,
as it affects all setups.
By making sure topics are advertised on init, logger can just discard
topics that don't exist. This does not work for all topics, so topics are
specifically marked as optional. It can be extended to more topics later
on though.
This reduces the list of topics by ~35 on a pixracer configured as quad,
and reduces RAM usage by ~1KB.
The defaults changed in the previous commit for per-channel params,
so we make sure that the overall params are still used as long as the
per-channel params are default.
Using mixers on the IO side had a remote benefit of being able to
override all control surfaces with a radio remote on a fixed wing.
This ended up not being used that much and since the original design
10 years ago (2011) we have been able to convince ourselves that the
overall system stability is at a level where this marginal benefit,
which is not present on multicopters, is not worth the hazzle.
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
Co-authored-by: Daniel Agar <daniel@agar.ca>
- Updating PWM params on param change was interfering with VTOL
parameter settings (e.g. PWM_MIN is set by VTOL at init, and
was then overwritten here after an arbitrary param change).
These changes remove the two code paths to updates (forceupdate and update) and try to reboot and bootload IO independent of its state, wether it is in bootloader mode already, safety switch is off or if it is in "nominal state" (running and safety on). This ensures that there are no conditions where user error or boot sequence can prevent a successful upgrade. The only state where an upgrade will not be done is if the system is fully armed.
- generate PWM_MAIN 1-14
- generate PWM_AUX 1-8
- generate PWM_EXTRA 1-8
- px4io and pwm_out directly read configuration parameters
- only available and active physical outputs are actually shown for configuration
- overall saves flash despite adding many new parameters
- parameter updates can be quite expensive because they trigger nearly all modules to reload all of their parameters immediately
- limit modules from updating faster than once per second
Igor Mišić