Overhauls the DShot driver with per-timer BDShot selection, multi-timer
sequential capture, Extended DShot Telemetry (EDT), and AM32 ESC EEPROM
read/write via MAVLink. Expands ESC support from 8 to 12 channels.
BDShot:
- Per-timer BDShot protocol selection via actuator config UI
- Multi-timer sequential burst/capture on any DMA-capable timer
- Adaptive per-channel GCR bitstream decoding
- Per-channel online/offline detection with hysteresis
Extended DShot Telemetry (EDT):
- Temperature, voltage, current from BDShot frames (no serial wire)
- New DSHOT_BIDIR_EDT parameter
- EDT data merged with serial telemetry when both available
AM32 EEPROM:
- Read/write AM32 ESC settings via MAVLink ESC_EEPROM message
- ESCSettingsInterface abstraction for future ESC firmware types
- New DSHOT_ESC_TYPE parameter
Other changes:
- Per-motor pole count params DSHOT_MOT_POL1–12 (replaces MOT_POLE_COUNT)
- EscStatus/EscReport expanded to 12 ESCs with uint16 bitmasks
- Numerous bounds-check, overflow, and concurrency fixes
- Updated DShot documentation
* refactor(mixer_module): change MixingOutput to use float outputs
MixingOutput now passes float values to output drivers instead of
uint16_t. This removes the need for the 8192 offset encoding and
allows reversible motors to receive negative values directly.
* fix(mixer_module): fix float safety issues
-EscClient and voxl2_io: replace outputs[i] with fabs(outputs[i]) > 0.fto fix compilation issues
-GZMixingInterface: add explicit double cast to prevent compilation error
-PWMSim: replaced unit16 cast with lroundf given that now motors outputs can be negative and casting a negative float to unit16 is undefinder behaviour
-mixer_module: same fix of PWM (unit126 cast on negative float is undefined behaviour)
* refactor(mixer_module): float rounding suggestions
* fix(pwm_sim): fix inverted disarmed condition
* fix(mixer_module): more float rounding improvements
* fix(mixer_module_tests): use casting method which are now in drivers for rounding tests
---------
Co-authored-by: Matthias Grob <maetugr@gmail.com>
Add a new parameter to map a MAVLink MANUAL_CONTROL button to turtle
mode activation. When the manual control data source is a MAVLink
instance, the driver uses the buttons field directly instead of aux
channels. When the source is RC, the existing aux channel behavior
via VOXL_ESC_MODE is preserved. Set to -1 (default) to disable.
dshot: fix motor test on CANnode
Also includes fixes for the DShot driver since stop_outputs is removed. The esc info command has been removed because it doesn't work with AM32, can only be used via command line, and complicates the driver
* brought in the Vertiq Cpp API as a submodule. updated the serial rx handling so that we can parse out IQUART data packets
---------
Co-authored-by: Luca Scheuer <scheuer.luca@gmail.com>
* Made Serial API open the UART in NON BLOCKING mode
* Updated voxl_esc driver to latest from ModalAI fork
* Ported voxl_esc driver over to new Serial UART API
* Removed voxl_esc serial abstraction since new Serial API is already a serial abstraction
- always publish esc_status
- when enabled via MODAL_IO_VLOG param, enable actuator debug output
- for modal_io commands, use ESC HW ID values instead of motor number for easier use
- publish esc_status message for command line commands
- Uncommented the code that fills in the cmdcount and power fields in the esc_status topic
---------
Co-authored-by: Travis Bottalico <travis@modalai.com>
- update motor mapping to use new UART_ESC_FUNC* auto generated params
- add support for actuator_test msg to support Actuator Testing in QGC
- modalai_fc-vX targets start driver if configured
- keep track of ESC spin direction in own param
- set ramp up param in MixerOutput to false
In review it was requested to have a different name for
manual_control_setpoint.z because of the adjusted range.
I started to investigate what naming is most intuitive and found
that most people recognize the stick axes as roll, pitch, yaw, throttle.
It comes at no surprise because other autopilots
and APIs seem to share this convention.
While changing the code I realized that even within the code base
the axes are usually assigned to a variable with that name or
have comments next to the assignment clarifying the axes
using these names.
Jacob Dahl