Motor Setup - Won't start when on load

I am running a setup using a Komar Controller and a Motres CIAG 100_30.

I followed this guide Yakut CLI tool - Telega v1.0 Reference Manual to configure the controller using the Babel Convertor.
This is the config I used:

125:
  # DRIVE task: run strategy.
  drive.runner.0_ramp.velocity_stall_spinup: [5, 20]

  drive.velocity_ctl.2_indi.acceleration_pi: [50, 0]
  drive.velocity_ctl.2_indi.mass:           1.0e-5        # Use best guess if unknown.
  drive.velocity_ctl.type:                  2

  motor.current_max:                        110.45
  motor.mechanical_ratio:                   12            
  motor.flux_linkage:                       0.004491
  motor.inductance_dq:                      [1.34e-05, 1.34E-05]
  motor.resistance:                         .0051
  motor.current_ramp:                       15000          
  motor.thermistor_v2k:                     [104.47, 71.43, 54.99] 

  vsi.bridge_resistance:                    [0.002, 0.003, 0.002, 0.003, 0.002, 0.002]
  vsi.dc_voltage_gain:                      18.8
  vsi.phase_current_gain:                   [100, 100,  25,  25]
  vsi.phase_current_stderr:                 [0.3, 0.3, 0.2, 0.2]
  vsi.thermistor_v2k:                       [223.15, 100.0, 0.0]
  # Cyphal/CAN parameters.
  uavcan.can.bitrate:                       [1000000, 0]
  uavcan.can.count:                         1             # In this setup we are not using CAN2.
  # Cyphal ports.
  uavcan.pub.dq.id:                         1010
  uavcan.pub.dynamics.id:                   1011
  uavcan.pub.power.id:                      1012
  uavcan.pub.temperature.id:                1013
  uavcan.sub.setpoint_rat_torque.id:        1101
  uavcan.sub.setpoint_velocity.id:          1102
  # Aux I/O pin.
  aux.pull:                                 1             # Enable pull-up for the motor thermistor.
  # General parameters.
  sys.debug:                                false         # Debug interfaces shall be disabled in production use.

I drove the motor with a torque request of 100%.
The motor will run fine when no load is applied to the motor → https://youtube.com/shorts/3WTO6VrU7ec?si=KrIqgQfw1DLtHrMy
When load is applied to the motor, it fails to start → https://youtube.com/shorts/TvwYlTLJ4Xk?si=jLuT24K6tlWXuJZA

I monitored the current when load is applied and it never spiked over 4A. When the motor is running continuously with no load, the current value is at 10A.

Do you think there is a configuration error?
What do you think could solve this problem?
Any tips to debug the problem?

If I can provide any additional info, please let me know.

The spinup behavior is documented here in section “Ramp spinup”: Drive - Telega v1.0 Reference Manual

A possible initial config is as follows:

drive.runner.0_ramp.velocity_stall_spinup:  [5, 20]
drive.runner.0_ramp.spinup_current_pu:      [0.8, 1.0]
drive.runner.0_ramp.spinup_duration:        [0.1, 0.0, 2.0, 0.0, 1.0e-3, 0.6]

Soon – in v1.1 – we will provide a new spinup strategy that uses HFI at low speed, allowing high stall torque.

Thank you for the quick response!

I’ll try the config and get back to you.

Hello @pavel-kirienko ! We have just begun trying to drive the car with the CIAG 100_30 and Komar again.

We implemented the changes you suggested but didn’t get too much of a difference.

However, from looking at the Ramp Spinup strategy from the provided link we figured that we could decrease the velocity stall spinup.

The car started moving when we significantly decreased the parameter:

drive.runner.0_ramp.velocity_stall_spinup:  [0.01,0.05]

However, we still have this stuttering at startup (pay close attention to the transmission chain):

The transmission is far from ideal, there is a bit of play right now and we are working to fix that.

Still, no matter what we changed in the spinup strategy, we couldn’t get currents upwards of 10A.
Here’s what we saw for the most part (DC currents from battery):



We managed to get the alignment current phase longer, we tried increasing the VCVF period and also decrease or increase the number of steps for the ramp (to the point where we could actually hear the motor whining pitch get higher as the frequency was increasing), but still couldn’t get higher currents, and we know that this is the main limiting factor for the slow startups, since current dictates torque.

Do you have any suggestion / hint?

Alright, when Lada Cyphal?

What do you mean?

Hi Andrei,

It really looks like you could benefit from the HFI spinup method; sadly it is not available yet but stay tuned.

To help you tune the existing ramp spinup strategy, please send the full configuration dump from the device. You can save it like this (replace 124 with the node-ID of Komar):

y rl 124 | y --yaml rb 124 --only=mp > configuration.yaml

Someday I’d like to work on a car that would be completely built on Cyphal.

The idea is something along the lines of the following tweet:

source

Hi @pavel-kirienko! Thank you for your reply. I’ll send the configuration this evening when i get back to the test site where the laptop with the configuration is.

I’m really inexperienced with software commands like this so thank you very much that you provide the precise command :smile:

Andrei Grigoregrigman

2m

Hi! Now that makes sense. It’s not a Lada, it’s an old Dacia car from our home country, Romania :slight_smile:

I’m working on an EV conversion for my personal car so… maybe we can try something out if you’re willing to provide some support.

1 Like

Hi

This is the config we used and these are the results:

aux.ctl.1_rcpwm.deadband: 9.999999747378752e-05
aux.ctl.1_rcpwm.rev_mid_fwd: [0.0010000000474974513, 0.001500000013038516, 0.0020000000949949026]
aux.ctl.2_voltage.deadband: 0.15000000596046448
aux.ctl.2_voltage.rev_mid_fwd: [0.0, 1.649999976158142, 3.299999952316284]
aux.ctl.dead0: false
aux.ctl.mode: ''
aux.ctl.type: 0
aux.power_output: false
aux.pull: 1
drive.current_brake_pu: 0.20000000298023224
drive.flux_weakening.bemf_pid: [4.0, 2.0, 0.009999999776482582]
drive.flux_weakening.voltage_boost: 1.0
drive.observer.0_ekf.proc_noise: [1000000.0, 3000000.0, 100000000.0]
drive.observer.0_ekf.sched_factor: [0.800000011920929, 0.949999988079071]
drive.observer.1_mras.gain: 1000.0
drive.observer.type: 0
drive.pre_calibrate: false
drive.runner.0_ramp.spinup_current_pu: [0.800000011920929, 1.0]
drive.runner.0_ramp.spinup_duration: [0.10000000149011612, 0.0, 0.20000000298023224, 0.0, 0.0010000000474974513, 0.10000000149011612]
drive.runner.0_ramp.velocity_stall_spinup: [0.05, 5]
drive.runner.1_passive.delay: 0.20000000298023224
drive.runner.1_passive.velocity_off_on: [10.0, 20.0]
drive.runner.type: 0
drive.stall_limit: 20
drive.velocity_ctl.1_pid.feedforward: [0.0, 0.0]
drive.velocity_ctl.1_pid.gain: [0.0, 0.0, 0.0]
drive.velocity_ctl.2_indi.acceleration_pi: [50.0, 0.0]
drive.velocity_ctl.2_indi.mass: 9.999999747378752e-06
drive.velocity_ctl.acceleration: [-2000.0, 2000.0]
drive.velocity_ctl.type: 2
drive.voltage_clipping: false
mns.deadman_timeout: 0.5
mns.local_timestamp: false
mns.pub_interval_min: 0.05000000074505806
mns.ratiometric_setpoint_min: 0.0
mns.ratiometric_to_absolute_mul: 0.0
mns.setpoint_index: 0
mns.status_period: 1.0
motor.current_ctl_bwr: 0.03999999910593033
motor.current_max: 110.44999694824219
motor.current_ramp: 1000.0
motor.flux_linkage: 0.0049230000004172325
motor.inductance_dq: [1.340000017080456e-05, 1.340000017080456e-05]
motor.mechanical_ratio: 46
motor.resistance: 0.005100000184029341
motor.thermistor_v2k: [104.47000122070312, 71.43000030517578, 54.9900016784668]
motor.voltage_ramp: 20.0
servo.profile.acceleration: [-200.0, 100.0]
servo.profile.jerk: 2000.0
servo.profile.velocity: [-50.0, 50.0]
standby.brake_voltage: .nan
sys.debug: false
sys.golden: sys. vsi.
uavcan.can.bitrate: [1000000, 0]
uavcan.can.count: 1
uavcan.node.description: ''
uavcan.node.id: 125
uavcan.pub.compact.id: 65535
uavcan.pub.compact.prio: 3
uavcan.pub.dq.id: 1010
uavcan.pub.dq.prio: 3
uavcan.pub.dynamics.id: 1011
uavcan.pub.dynamics.prio: 3
uavcan.pub.feedback.id: 65535
uavcan.pub.feedback.prio: 3
uavcan.pub.power.id: 1012
uavcan.pub.power.prio: 3
uavcan.pub.status.id: 65535
uavcan.pub.status.prio: 4
uavcan.pub.temperature.id: 1013
uavcan.pub.temperature.prio: 5
uavcan.srv.low_level_io.id: 65535
uavcan.sub.readiness.id: 65535
uavcan.sub.setpoint_dynamics.id: 65535
uavcan.sub.setpoint_rat_torque.id: 1101
uavcan.sub.setpoint_rat_torque_u9.id: 65535
uavcan.sub.setpoint_rat_velocity_u9.id: 65535
uavcan.sub.setpoint_rat_voltage.id: 65535
uavcan.sub.setpoint_rat_voltage_u9.id: 65535
uavcan.sub.setpoint_servo.id: 65535
uavcan.sub.setpoint_velocity.id: 1102
vsi.activation_latency: 0.009999999776482582
vsi.bridge_resistance: [0.0020000000949949026, 0.003000000026077032, 0.0020000000949949026, 0.003000000026077032, 0.0020000000949949026, 0.0020000000949949026]
vsi.calibration_duration: 2.0
vsi.dc_voltage_gain: 18.799999237060547
vsi.hw_fault_latency: 0.10000000149011612
vsi.phase_current_gain: [100.0, 100.0, 25.0, 25.0]
vsi.phase_current_gain_attack_decay: [1.5, 0.36000001430511475]
vsi.phase_current_gain_decay_time: 0.10000000149011612
vsi.phase_current_sampling_window: 1.9000000293090125e-06
vsi.phase_current_stderr: [0.30000001192092896, 0.30000001192092896, 0.20000000298023224, 0.20000000298023224]
vsi.pwm_dead_time: 0.0
vsi.pwm_freq_mul_log2: 0
vsi.shortest_time_in_disabled_state: 1.9999999494757503e-05
vsi.swap_ab: false
vsi.thermistor_v2k: [223.14999389648438, 100.0, 0.0]
vsi.tick_freq: 29402.15625
zubax.cookie: ''

Here is a video running in torque control mode. We initiated the command when the motor was already freewheeling. As you can see the motor runs for a while and then starts to stall (becomes jerky) until it comes to a complete stop.

We are using torque control mode. A thing that seems weird is that increasing the torque command from 0.6 to 1 doesn’t make a difference, actually the controller works better with a request of 0.6 torque.

For a 0 torque command the motor is not freewheeling and trying to actually start. We don’t know why.

When trying to get some regenerative braking, driving the motor forward and requesting a negative torque, -0.6 it just jerks the motor a bit and then pauses.

What we tried from a configuration stand point is changing the drive.runner.0_ramp.velocity_stall_spinup. We found that [0.1, 5] seems to work for us at the moment. Decreasing the second parameter seemed to improve pick up when the motor was already spinning.

We also reduced the motor.current_ramp parameter. Decreasing it to the current value helped with the controller reaching a steady state faster when the motor was already rotating.

If you have any tips on what we can try configuration wise of how we can debug the current setup, it would be highly appreciated.

This is the correct behavior of the ramp spinup runner. This runner does not allow the motor to decelerate below the stall detection threshold, so if a command is received when the motor is stationary, it will attempt to spin it up. A zero torque command cannot be used to disengage the drive because a transient zero torque setpoint may be received as part of normal operation under load.

Please stay tuned for the upcoming firmware update that will include a new runner policy that will be a better fit for your use case. I am going to post an update in this thread.

Hi @pavel-kirienko! Thank you for the reply.

We are very tight with our schedule - our first competition is in two weeks and we need the motor to run by then.
Is there something that we can do to speed this up? We’re not targeting perfection, but we’d like to make the most out of our hardware.

Hi @pavel-kirienko

We ran some diagnostics. We made a few rolling starts. Motor was freewheeling and then we gave a 0.6 torque request. The motor kept the speed, after a few seconds it started to jerk and eventually came to a stop.

We have a 3.8:1 gearbox installed, 3.8 rotations of the motor = 1 rotation of the load.

Looking at that info, it seems that the motor runs a few moments in normal mode and then losses position and never recovers it.

Also, looking at the current values, they seem also a bit low. Our max current is set at 110A and the battery pack can handle it easily.

What can we do about the motor loosing position? Do you have any ideas what configs should we look at to fix this?
Also, what is the cause of the current limitation? What can we do to increase the current draw?

This is sus. Can you check the DC rail voltage please to ensure it remains stable throughout?

Are you sure you are not exhausting the maximum DC voltage? This is relevant:

Assume f_\text{util} \approx 0.94. If you’re running out of voltage, the current will not go higher than allowed by the available voltage.

I will get back to you with a firmware update as I mentioned earlier soon.

Tnx for the info.

I will check the DC Rail Voltage to make sure it is stable.

umax ~ 23.3V based on the calculations you mentioned. I will try to check if voltage is the limiting factor in our application.

Do you think that modifying the drive.velocity_ctl.2_indi.mass might have any effect on the losing position problem?

Looking forward to the new update. We pushed a bit in the couple of weeks because the car is going to a competition next week and we wanted to get the best out of the controller. The next one is in September, it would be great if we could get the update until then.

You should be using the torque control mode, not velocity control mode, so this parameter has no effect as the INDI (nor any other velocity controller) is not used.