I’m planning to use multiple Komar ESCs with Telega v1 in a UAV scenario with Cyphal.
Having set up the ESCs I can successfully run each motor using yakut: y pub -T0.1 1102:uavcan.primitive.scalar.real16 50
But when I publish 0 as setpoint, then the motor tries to spin up and aborts, then repeats. y pub -T0.1 1102:uavcan.primitive.scalar.real16 0
Why would I publish 0 as a setpoint?
I’m planning to use these ESCs with Cyphal/PX4, where the setpoint ID is the same for all ESCs and the setpoint is given as an array of values corresponding to the esc’s mns.setpoint_index: 1. PX4 publishes a 0 value for every actuator that is not running. Thus this unexpected behaviour appears.
Is there a setting that causes this issue or is it considered a bug?
Find the register values of one of the escs attached. esc_124.yaml (5.6 KB)
+1
After some initial testing with PX4 and Telega V1.0 we had to revert to V0.6 for mostly the idential reason I guess. (We could not fully analyze the problem yet.):
When a setpoint command to an individual motors was send, other motors would spin up for a short moment, before stopping. Rinse and repeat… Setting up the additional enable publisher did not solve the problem, which is to be expected as it is a single channel for all motors.
We are hoping though, that this will be fixed in the near future. Cyphal seems promising.
The described behavior is expected and documented. Telega attempts to spin up because you published a command. As the command is zero, it stops, and then the next command forces it to spin up again. Disengaging the drive upon reception of a zero command is not a sound strategy because zero setpoints may be issued during normal operation by the outer control loops; doing so may unexpectedly shut down the drives in flight.
If you want to prevent repeated restarts while running in any ratiometric control mode, consider using mns.ratiometric_setpoint_min as described here: Cyphal interface - Telega v1.0 Reference Manual. This will allow you to let the motors run at some minimum speed while the command is zero.
The only viable ways to stop the drive are:
Cease publishing commands.
Cease publishing the readiness messages (unless the readiness subject is disabled; if it is, the drive is assumed to be always armed).
There may be an established practice of shutting down the drive in response to a zero velocity setpoint, but it is unsafe and such drives should be disused.
Thanks for the reply, @pavel-kirienko . Using mns.ratiometric_setpoint_min is not an option for my application since the UAV is designed as an eVTOL with hover propellers and pusher propellers.
During fixed-wing flight, the pusher motor should be engaged. Therefor commands will need to get published. These commands will reach all ESCs, since they subscribe to the same topic (e.g. 1102).
These might be valid options, but the current implementation of PX4 couples the armed state directly to the readiness[ENGAGED] publishing. And to my understanding, the hover propellers are not considered disarmed during fixed-wing flight in a VTOL scenario (and vice versa).
Shutting down the drive on a zero velocity setpoint seems quite intuitive to me. I think it would be great having this as an option in the Telega v1 firmware and stating the safety concerns in the documentation.
Since you’re very familiar with the PX4-Autopilot, what would be the best solution in your opinion? Do you think making use of the STANDBY readiness state in PX4 (e.g for inactive hover actuators during flight) would be the way to go? If so, then I’d be happy to help with submitting a patch for that. Another idea would be to publish messages for the fixed-wing actuators to a different subject id. This would also need to be implemented.
This may cause unexpected behavior when the outer control loop emits a zero (and eventually perhaps negative) reference in response to a disturbance. This is why arming commands need to be decoupled from the setpoints.
We could introduce an option that will make the drive refuse to start while the setpoint is zero; this is quite easy to do, but it may not aid in building safe systems.
I think both solutions will require decoupling hover and tractor ESCs into separate topics, because if you pursue the first option you will still use a separate topic for controlling the arming of a subset of ESCs. Also consider that not publishing commands to the hover ESCs during cruise flight conserves network bandwidth and processing power (and a tiny bit of energy, not that it matters here). So I would go with the second option as it is more general.
That would be great! I created a post in the PX4 Discussion forum regarding the suggestion of splitting of the hover/forward flight propulsion systems into separate topics. This latter solution would be ideal, but might need quite a few changes in PX4 since the drivers are not aware of the purpose/function of each output.