The main problem ist that at medium-high RPMs, the (measured) current ripple is so large that the controller easily reaches the maximum allowed current for a split second, which it turn causes it to shut off.
This also happens in the torque controlled mode, when the applied torque is high enough. What is very strange is that the motor does not turn at all in torque mode unless i increase the torque to ~0.2Nm, which is a third of the total torque it can produce.
What is also strange is that when plotting I_q and I_d i can see that the controller correctly tries to produce no I_d at all (setpoint is zero). Still, the controller measures that therre is I_d current flowing.
A friend suggested that the alignment between mechanical and electrical axis may be off somehow. The phase resistance and inductance seems a bit off after the measurement routine, but is still in the correct ballpark. Also after changing the values to the ones given in the datasheet of the motor, nothing changes.
Unfourtunately, i can only use the hall sensors on the motor itself as the rotor is directly mounted to a geabox with a 30:1 reduction, so i cant attach a “real” encoder there.
One idea i had was that the hall sensors are improperly placed in the motor and the controller somehow expects a different layout. They are not 120° apart and i read that this does not necessarily have to be the case, but i was unable up to now to come up with the correct necessary placement. (The hall sensors are soldered onto the stator from the manufacturer, so i dont have any way to change it.)
One additional curiosity: I am fairly certain that the pole pair count is 10. I read that the placement of hall sensors is usually 120 electrical degrees apart, which would mean 12 mechanical degrees in our case.
I measured the placement and they are in fact 60 degrees apart (but they are ordered 1,3,2), not 12. Does this matter in anyway?
The main problem ist that at medium-high RPMs, the (measured) current ripple is so large that the controller easily reaches the maximum allowed current for a split second, which it turn causes it to shut off.
Interesting.
A friend suggested that the alignment between mechanical and electrical axis may be off somehow. The phase resistance and inductance seems a bit off after the measurement routine, but is still in the correct ballpark. Also after changing the values to the ones given in the datasheet of the motor, nothing changes.
I agree with your friend. However, the phase resistance/inductance shouldn’t affect this much. This is likely an issue with the hall encoder calibration.
One idea i had was that the hall sensors are improperly placed in the motor and the controller somehow expects a different layout. They are not 120° apart and i read that this does not necessarily have to be the case, but i was unable up to now to come up with the correct necessary placement. (The hall sensors are soldered onto the stator from the manufacturer, so i dont have any way to change it.)
The ODrive actually doesn’t care! It’ll automatically measure the hall angles, whether they’re 60° or 120° (or some random other set of angles) and use those.
I think there may be some issues with the hall calibrations here. Typically we strongly recommend that calibration is done under no load, and your gearbox may be adding a bit of load here. I’d recommend changing your “calibration lock-in current” (assuming you’re using the GUI) to the maximum continuous motor current of 5.6A, and remove the gearbox for calibration, if at all possible. Additionally, this is a pretty high inductance motor, you may need to reduce the current_control_bandwidth to around 100-200 (this can be done in the inspector tab of the GUI, just make sure to run save_configuration() afterwards).
Thanks @solomondg ! I think this maybe improved some things, but i still have the same problem.
I am fairly certain it is the control loop completely getting out of hand, since i seem to be able to influence the RPMs at which this happens by modifying the velocity P & I values.
As i previosuly tried to use a different controller which constantly complained about an improper hall sensor state (either all three low or all three high), which i suspect is EMI related, i tried to see if the ODrive sees the hall sensor readings correctly.
Shouldnt at least one of those two graphs increment from 1 to 6 and then go down again constantly to reflect the six different hall states? Os does the odrive do the “calibration” which sensor is which internally? Even then, the signal should look the same at every revolution at a constant speed right?
EDIT: At very low speeds or when turning the rotor manually, the hall state correctly increases from 1 to 5, so maybe this isnt a problem after all.
I can remove the gearbox for the calibration sequence, but due to an unfourtunate design choice, this adds friction at a different place and im unsure if thats better.
Right now, we dont necessarily need to high velocities, but we have a different problem: In high torque moments, the ODrive faults with a MISSING_ESTIMATE error, which is very interesting since thats basically the same error we got with a totally different controller. I have shielded the phase cables individually and connected the shielding together at one end (but they arent connected to ground) and used shielded cable for the hall sensors (all signal wires are enclosed under one shield), which is both connected to ground on the controller side and the motor side, but that didnt change the MISSING_ESTIMATE error.
Shouldnt at least one of those two graphs increment from 1 to 6 and then go down again constantly to reflect the six different hall states? Os does the odrive do the “calibration” which sensor is which internally? Even then, the signal should look the same at every revolution at a constant speed right?
I think this is just an issue with the sampling rate of the GUI – if the ODrive isn’t complaining about the hall sensors, I’d generally assume they’re fine. There’s some internal conditioning from the sensor signals that should mitigate EMI issues. It’ll throw an error if it detects an invalid hall state; the fact you haven’t seen this yet makes me think it’s not an issue.
Regarding shielding – I would connect the shield of the phase cables to ODrive DC-, and the shield of the hall cables to ODrive GND on the J11 connector (e.g. pin 16 or 26).
I can remove the gearbox for the calibration sequence, but due to an unfourtunate design choice, this adds friction at a different place and im unsure if thats better.
Totally understood, in that case I’d just crank calibration lock-in current to the motor’s maximum continuous current.
Right now, we dont necessarily need to high velocities, but we have a different problem: In high torque moments, the ODrive faults with a MISSING_ESTIMATE error, which is very interesting since thats basically the same error we got with a totally different controller. I have shielded the phase cables individually and connected the shielding together at one end (but they arent connected to ground) and used shielded cable for the hall sensors (all signal wires are enclosed under one shield), which is both connected to ground on the controller side and the motor side, but that didnt change the MISSING_ESTIMATE error.
Very interesting. Can you make sure you’re on firmware 0.6.11, and then let me know the value of detailed_disarm_reason next time it throws the missing_estimate error?
Note overall that just due to the low resolution of hall sensors, you’ll have to tune the control loop a bit less aggressively, so I’d definitely expect that your achievable gains will be lower than what would be possible with a proper encoder.
