Cyphal: Seperate Subject IDs for hover and propulsion system

I’m using Zubax Komar ESCs with Telega v1 in an VTOL scenario. When using PX4 via Cyphal, I encountered an issue where motors spin up unexpectedly when receiving a setpoint of 0. Upon further communication with zubax, this behavior seems to be expected: As a drive command is published by PX4, the receiving ESC tries to spin up; Since the setpoint is zero, it stops afterwards.

This gets relevant in a VTOL scenario: When fully transitioned to fixed-wing flight, the hover propulsion system should be disengaged but kept ready. With the current implementation, the hover ESCs would still receive drive commands (with a setpoint of 0), causing them to spin up and stop repeatedly midflight.

The root cause is that all ESCs—hover and forward—are subscribed to the same Cyphal subject ID, meaning all motors receive the same setpoint array and then just pick the intended value each by the per-ESC configured mns.setpoint_index.

One possible solution might be to separate the subject IDs for hover and forward propulsion ESCs. For this, some changes would be necessary, probably starting from withing the mixing_module and passing context information down to the driver. The context might group output functions and assign a Cyphal subject id each. That way, the cyphal driver will only publish a message if there is a command for one of the actuators in the group. If not, then there will be no command and thus no spinups.

See the original discussion with @PavelKirienko in the zubax support forum.

1 Like