I am evaluating using the Zubax Myxa ESCs with the T-Motor MN501-S 360KV (Included on the PMSM parameters sheet). These motors will be used with a lift+cruise VTOL drone and are candidates for replacing our PWM ESCs. I am hoping to use the Myxa ESCs but have been having a series of compatibility issues on v0.6 (please note that switching to Cyphal is not an option for our use case).
I am using the DroneCAN GUI tool to program my 4 ESCs for the VTOL and have programmed the motor-specific parameters on the ESC (see the .parms file attached). The ultimate goal is to connect the motors to a CubePilot Cube Orange and fly the vehicle with that autopilot.
My problem is I am not able to see any difference in motor speed when sending various bench test commands using the actuator test provided in QGroundControl. The motors are either spinning when I give them any command or are off when I do not send a command.
Is my problem with the parameters I am using on the Myxa? Or is there a way to program the Cube Orange to send the proper message? I have the range set from 1 to 8184 for each ESC.
Any help would be great as we are still debating on whether to use the Myxa or keep our standard PWM ESCs. tmotorparams_v1.parm (2.0 KB)
Your motor controllers appear to be configured in the current control mode, which is an odd choice for the attitude control thrusters. Perhaps this is by design, as I don’t know the design of your airframe, but please double-check that this is intentional.
To diagnose the cause of the described behavior, please share a dump of CAN frames exchanged through the bus when the problem is observed. You can simply open the Bus monitor in the DroneCAN GUI Tool and take a few screenshots at the appropriate moment.
Thank you for pointing out the control mode issue. We wish to use the ESCs in the RPM control mode, so I changed that parameters and tuned the ESC response. (See my updated parameters tmotoparams_working10102023.parm (2.0 KB))
A remaining question I have for you is how do I command a desired RPM to the ESCs? I have attached a PX4 log showing my throttle input from the transmitter. However, I do not know how the command from the autopilot maps to an RPM command. Is there an equation for the mapping, or do I need to change some parameters on the autopilot? See the attached bench test PX4 log: BenchTest.ulg (998.4 KB)
and the attached PX4 parameters of my autopilot: dragon_vtol_10102023.params (42.7 KB)
Essentially, I am not sure how the raw command sent from the autopilot corresponds to what the Myxa interprets as the commanded RPM.
I am publishing to the ActuatorMotors topic in PX4 v1.14 and sending commands between 0 and 1 to the motors. They are spinning, however sometimes seem to slightly stop and resume (for .1 to .2 seconds) when I send the commands to this uORB topic. I do not get these same issues when running a bench test through the “Actuators” panel in QGC.
I am getting the following motor failure warnings from QGC
Here is the flight review interpretation of the log from this incident. Note this was a bench test and simply spinning the motors by publishing my commands to the ActuatorMotors uORB topic. I believe the messages at the bottom may hold significance to you / I am curious of your thoughts. Flight Review: Incident Log
I would check the actual command publication rate on the bus using candump or something similar. It could be that it is not high enough, causing the controllers to occasionally detect a missing command message and disengage. For Telega v0, the default timeout is 0.5 seconds; it can be changed via uavcan.esc_ttl.
Thank you for the tip. I have upped the value for uavcan.esc_ttl to 5. I am still getting an issue where the motor sounds as if it’s stuttering (not a physical equipment issue). I have recreated the stuttering at 30%, 80%, and 90% throttle (the command linearly mapped between the minimum and maximum commanded RPM.
Here are the current parameters for one of my motors (all motors have the same parameters, barring indexing): Motor Parameters.pdf (238.0 KB)
Indeed, the problem has nothing to do with publication rates.
If you can recreate the problem in the voltage control mode, then it is likely caused by incorrect motor parameters; specifically, a slight reduction of the flux linkage parameter may be needed. This, however, is unlikely to be the problem because the automatic motor identification procedure is usually fairly accurate (excepting some marginal cases but your motor is not one of them).
If the problem only occurs in the velocity control mode, then it is likely caused by a mistuned velocity controller.
We recommend all new applications to adopt Telega v1, while you’re still using Telega v0. The differences are explained here: Telega v0 quick-start guide
Hello Pavel! After extensive troubleshooting and tuning, we are still having issues with +/-200 RPM spikes at a constant commanded RPM. Do you have a parameter file available for the Zubax Myxa ESCs when using the TMotor MN501-S 360KV? I am curious to see if I am way off on some parameters that are causing these issues.
Please share the log file for us to inspect and also describe how the constant RPM setpoint is commanded. Are you using a dedicated tool to publish the setpoint or are you using the filght controller for that? Are you still using the ratiometric control message? Are you observing RPM variations in the voltage control mode as well?
The orange line is the commanded RPM taken from PX4 taken in the actuator_outputs uORB topic. The dark maroon line is the actual RPM logged from the ESCs in the esc_status uORB topic. When commanding between 1 and 8191 in PX4, how do I know that RPM command from PX4 is being interpreted properly by the ESC? The commanded RPM from PX4 in Figure 1 is consistently ~+400 higher than the RPM that the ESC tracks.
In summary, should I expect the ESC to be tracking the commanded RPM value logged in the actuator_outputs topic or should I change how I am sending my commands through PX4?
That’s not how I’m reading the plot; what I’m reading is \text{RPM}_\text{ref} = 1.2 \times{} \text{RPM}, which indicates that the maximum RPM is configured incorrectly in the motor controller. Multiply the value of the maximum angular velocity parameter by 0.83.
Hello Pavel! Thank you for your prompt response. The best solution I found during lab testing was to increase the the m.max_eangvel * 1.2. The following tracking has resulted:
