Hello,
I’m using Odrive 3.6 to drive a mige 130st-10010 motor
The motor spec reads:
line-line resistance 2.7ohm
line-line inductance 8.8mH
after AXIS_STATE_FULL_CALIBRATION_SEQUENCE I get
phase_inductance: 0.0037994771264493465 (float)
phase_resistance: 1.3909415006637573 (float)
I understand the resistance of line-line will be doubled but I don’t know how inductance of 3.8mH relates to 8.8mH.
Should it also be half so 4.4mH? should I configure these by spec or trust auto calibration?
Thanks!
I found the formula for in series inductors, it should be a straight sum like resistance, so this value should be closer to 0.0044 per spec. Should I go with that or use the calibration as sensing circuitry/method may have a bias/offset and it is better to use what it found?
I keep answering my own questions, I set the parameters per spec and the heavy cogging I was experiencing went away, smooth as butter now.
1 Like
That’s quite the motor. You can probably just run it in Gimbal mode tbh.
Interesting, what is the gimbal mode? I haven’t found much explanation about it.
This is a very efficient high torque low speed motor lots of sim racers use for their dyi force feedback wheels. Mige 130st10010. 20Nm at 9A
As you can imagine it’s stalled most of the time and we only use torque control mode and high frequency polling of encoder position via can bus.
Odrive is a great fit for that application, especially for the ramped, chopped brake resistor to eat away the spikes generated by lively steering action.
1 Like
Gimbal mode just turns off the closed loop current control, because it’s not really needed if the resistance/ inductance is so high and the speed is low so V = IR holds.
3.6 has a fair amount of current sense noise, even at the lowest possible current range, something like ± 0.25A. But gimbal mode has none 
the only issue in 3.6 code is that everything is in terms of volts instead of amps, which was recently changed on Pro / S1 for a more unified experience
Very interesting, 0.5A noise is 1.1Nm on this motor which is very noticeable for force feedback.
We usually replace the shunt resistors to reduce current range and therefore noise.
If I understood it correctly, gimbal mode would give us smooth precise torque control mode even with the default high range shunt resistors, right?
Sorta. Gimbal mode is feed-forward only (i.e., voltage applied to the motor windings = Iq_setpoint * phase_resistance. It won’t have any noise though, because it doesn’t measure anything (except the vbus_voltage)
The torque equation is approximately:
\tau = k_t R_{phase}(V_{bus} * duty - \omega k_v)
Since we know torque_constant k_t and phase_resistance R_{phase} from the datasheet, and vbus_voltage V_{bus} is measured with little noise, the tricky part is compensating for the motor back-EMF (\omega k_v). But at zero speed \omega = 0 so that term drops out anyway.
Question 1: How fast do you poll encoder estimates over CAN? It can automatically send the encoder data at up to 1kHz, do you need it faster than that?
Question 2: Do you use the torque mode velocity limiter? If so, do you find it smooth enough? Getting Started — ODrive Pro Documentation 0.6.3 documentation
Also, ODrive S1 (coming Soon 
) is going to be about perfect for these applications.
- Much lower current sense noise thanks to better board design
- Built in magnetic encoder
- Built in brake chopper
- CAN FD
- Up to 52V (12s LiPo) nominal, 40A continuous
- ~ 75% of the size of a credit card, so easily mountable to the back of the motor
This should work really well for our application. I can’t wait to try it next week. The exact torque doesn’t matter much, the simulation outputs a percentual 0-100 and the FFBoard scales that to torque range or current range. All we need is for it to be consistent (52% always feels same) and mostly linear and smooth.
Speed is almost always 0, but some quick steering jerks exceeded the velocity limit so we have to keep that turned off. Ideally the simulation will stop sending torque if you just left the wheel spin freely to the angle of least resistance of tires. If the Simulation hangs at high torque, hopefully the dedicated force feedback board will hit its soft limits and invert torque causing hard stop. If that hangs too, the motor is 1000rpm at 200v, we run it at 48v so likely 250, odrive cuts 20% more, so the liability may be a 200 rpm free spin, but for that we have manual e-stop close by.
I believe the FFBoard uses the 1khz auto update. That is plenty. AFAIK, Most simulators are nowhere near that refresh rate for their physics engine.
Question: what range of resistance/inductance/speed could work well in gimbal mode? What is the failure case? Lower than max current/torque due to unaccounted back emf? Could it cause higher than max when turning the wheel the opposite way?
1 Like
You should be able to increase the velocity limit (controller.config.vel_limit and controller.config.vel_gain so that it doesn’t activate while the driver is hands-on.
We usually recommend it for motors > 1ohm, ish.
Worst case, you set the phase_resistance value way too high, which means it generates much higher than expected current for a given torque command.
Does it mean that at 9A max and 1.35ohm phase I could use a 12v PSU?
Probably not, still need overhead for back-emf when the motor’s rotating.
Is back emf taken into account in gimbal mode?
@Wetmelon, gimbal mode did not pan out exactly as expected.
When on CONTROL_MODE_TORQUE_CONTROL and AXIS_STATE_CLOSED_LOOP_CONTROL and dev0.axis0.controller.input_torque = 0 the wheel offers great resistance to being turned, but turns as if it was dampened, when let go it stays still, with input_torque = 1 it spins very slowly.
Dutty cycle doesnt seem to move from 50% even with torque=0 as you can see in this scope snapshot, with phase voltage and different phase current.
suspicious. I guess in that mode, it’s not driving to 0 torque, but 0 voltage which isn’t going to behave the same. Will have to think about that some more
