Open vertiq-jordan opened 1 year ago
dagar
commented
1 year ago As a start I'd like to change the unsigned integer mixing range and just move to floating point. For each output module I'd like to respect its native units (and range) and move beyond uint16 that worked well for PWM, Dshot, etc.
henrykotze
commented
1 year ago https://github.com/PX4/PX4-Autopilot/pull/21656 The PR moved all mixer range to int16, and I have done successful bidirectional ESC test bench tests.
Plan is to move it to floating point as @dagar mentioned, but will do this a bit later.
Describe problem solved by the proposed feature
From my understanding, the ESC control pipeline gets handed a value [-1, 1] ([0, 1] for throttle), which is grabbed by the UAVCAN ESC Mixer (_mxing_interface_esc), and turned into a DroneCAN throttle command. As it stands now, the UAVCAN driver only knows how to deal with positive throttle commands, and cannot output the [-8191, -1] range defined by the DroneCAN standard. I’ve tried changing the module.yaml file to make the standard_params include the negative values, but the generate_params.py script throws an error that module.yaml values must be positive. This appears to happen in the get_actuators_output_params function. Now, this makes sense for PWM actuator commands since we can’t make negative times, but limits DroneCAN as a result.
Describe your preferred solution
Ideally, we could allow actuator values to be negative, meaning we could directly put -8191 as the minimum in module.yaml. This would require updating generate_params.py script to allow us to input negative actuator values. This solution would require associated firmware work in order to deal with negative values moonlighting as uint16s.
Describe possible alternatives
Theoretically, we could update the mixer to accept values from [0, 16384] where 13192 represents 0 throttle, and the other extremes represent -1 and 1. This echoes how PWM protocols work with reversibility, but would be a bit strange to look at, specifically through QGroundControl (those familiar with DroneCAN would see a maximum of 16384 rather than the expected 8191). We could also keep the current setup, but break the 8191 in half to emulate the [-8191, 8192] range. This, obviously, would cut the resolution, giving less granularity between throttle steps.
Each of these would require a new parameter that would decide whether or not to split the throttle range (2D/3D flight).
Additional context
I am not necessarily looking for someone to solve this for me, just looking for guidance/advice for moving forward so that I may make a PR that includes approved solutions.