A hardfault was happening on:
fmu stop
fmu mode_pwm
pwm info
The _mixer was null and being dereferenced to access the trim
setting that were moved to the mixer from the fmu.
This commit fixes that but making the getter issue a warning
and the setter fail.
- use the orb topic safety to check the safety state, because the actual
safety state can come from the IO
- fix initialization if circuit breaker is set
- Telemetry is only enabled on omnibus, since on Pixhawk it seems we cannot
write to the RC UART due to how the board is wired
- For the Telemetry the UART needs to be opened RW
On SPM4649T receivers with firmware versions at least 1.1RC9, the
serial data will contain an rssi value in dbm, as outlined in the
Remote Receiver Interfacing document section 8.3.1.
If the value received is greater than or equal to zero, the receiver
does not support rssi data, and the incoming value will be ignored.
However, if the value is negative, we can use the rssi value.
When we have a valid rssi, it gets mapped to a percentage from 0 to
100 as expected by mavlink. This mapping is constructed as a
logarithmic function over Spektrum's published minimum and maximum
rssi values, -92dBm to -42dBm as 0 to 100:
100 Log10[1 + (x - min) * (9 / (max - min))]
This change updates all calls to the dsm input rountes to return
the rssi value.
Note that one place this doesn't work with the px4io enabled.
There is a comment left in the absence of analog rssi that:
"we do not actually get digital RSSI regs[PX4IO_P_RAW_RC_NRSSI]".
This restriction has been left in place, as removing it exposes a
problem where the frequency of the control tick is greater than
that of valid dsm frames so the rssi isn't valid every cycle.
Platforms that provide HW versioning tend to have
more FLASH and can have a PX4IO as an option.
(E.G.) FMUv5. This change provides run time
decision to control the safety switch on
platfors that have BOARD_HAS_VERSIONING.
On platforms with no versioning and have
BOARD_HAS_STATIC_MANIFEST defined as a 1
The decision is compile time only. When a PX4IO
is present the fmu control of the safety is
not built.
Flight tested: ekf2 w/ mag and compass by @nathantsoi: https://logs.px4.io/plot_app?log=79b81031-cf1e-41f0-890b-d6cd7d559766
NOTE: external I2C devices need a pullup. I have tested with a 3.3v 2.2k pullup.
Working:
- mpu6000, bench tested and verified via nsh
- fmu
- all 6 ch output bench tested w/ pwm and oneshot via nsh
- ppm input bench tested
- dsm input bench tested
- bmp280, bench tested and verified via nsh
- hmc5883, bench tested and verified via nsh, but requires an external i2c pullup
- gps on uart6
- startuplog, nsh, mavlink on uart4, but params are not sent for some reason. RSSI pin is TX, MOTOR 5 is RX (normal mode, 57600 baud)
- rgbled over i2c, bench tested and workingp
- sbus via the shared sbus/ppm pin (which includes an inverter to the mcu SBUS in pin), remove the solder bridge or jumper to the ppm pin before use
Not yet implemented:
- ADC
- OSD: passthrough video is untested, use at your own risk until a basic driver is implemented.
- initialize rc lost with true
- refactor for simpler downstream code-plugin
- allow for the addition of different binding commands
- fix st24 RC lost logic
Beat Küng