I have an Odrive 3.4 with a AMT encoder and a T-motor MN5208 motor. I am having some problems getting the motor to work and I wanted to document my debugging steps and see if you have any suggestions.
Problem description— I am able to flash the processor and communicate with it over python. I can send setpoint commands but the motor does not respond. I can read the current encoder value, and then move the motor and verify that the encoder value changes. The Odrive startup routine moves the motor CW then CCW slowly, but at the point of starting the high speed rotation it does not move. However, I tried various polepair numbers and for differing values the high-speed movement moves differently but never fully rotates.
My thoughts— I think the firmware side of things is fine, I can communicate over USB straight out of the box and have no problem flashing the MP. It is the commutation side of things that I am having trouble with. The three main uncertainties I have are:
I have the wrong number of pole pairs in the code. I didn’t know exactly how to find this number and spent a while searching around. While trying to figure out how to determine the number of pole pairs I tried different values to see if one would work. In the end I found a resource that said the pole pairs is half the number of permanent magnets. This motor has 22 magnets so 11 pole pairs and this is the number I am using.
Wiring up the ABC phases incorrectly? This motor doesn’t have labeled or color coded motor leads so I have tried different combinations. My gut says wiring ABC, ACB, BCA, shouldn’t matter (just affect rotation direction?). Flawed logic here?
Cheapo power supply, I am using a 12V 1.4A wall wart because I was too lazy to go downstairs and get a proper one. Could this be a problem? I don’t see any error codes on the Odrive through explore_odrive.py so I don’t think this is the issue.
I think suggestions to help debug first time setups would be great and so any comments will help, and maybe some of these questions can be rolled into the readme (maybe just points 1 & 2).
For posterity, I figured out the problem. Laziness on my end using a cheap wall wart power supply to test the motor. When I grabbed a benchtop supply I got it to move just fine. Still needs some tuning, and strangely it still does not do a full spinup during the startup testing. But setting positions causes it to move.
I am running into a similar problem with the N5065 motor & CUI AMT102 encoder from the official kit. I’ve got everything hooked up as detailed in the (very helpful) Getting Started guide, and on power-up the motor goes through its initial motor/encoder calibration routine (slowly spinning around a little more than one revolution).
When I use the explore_odrive.py script, I’m able to connect to the ODrive board & read the encoder’s current count (my_odrive.motor0.encoder.encoder_state). (Notably, my_odrive.motor0.encoder.pll_pos always returns 0.0 even though the script’s commentary says it should return the current encoder position.)
However, setting my_odrive.motor0.pos_setpoint to any value does not result in the motor moving at all. In fact, it looks like the motor current is being completely turned off after the calibration. Before the calibration starts (after the motor initially gets power), I can turn the motor shaft manually & overcome the holding torque, but I have to apply a lot of torque to do so. After the calibration, it feels like I’m just overcoming the cogging torque, which isn’t difficult at all.
I am using a lab-grade 10A power supply, so I don’t think that’s the problem.
I have left the firmware unchanged for now (though I am able to successfully build it & flash the ODrive board). All of the default parameters should be OK for this motor.
Have you checked that there is no motor error after startup? If there is an encoder or motor error during calibration the motors will not be enabled. In explore odrive check my_odrive.motor0.error.
Alright, got it all working. There were multiple things wrong in my code & setup, possibly exacerbated by some of the default behavior (or, more likely, my misunderstanding of how the startup routine is controlled).
First facepalm moment: I had the motor leads plugged into M1, not M0. D’oh! I didn’t notice this because I had the encoder leads plugged properly into the M0 locations, so when I manually moved the motor, the encoder’s value was changing.
The second reason I didn’t notice this was because I had un-commented out the lines in low_level.c and low_level.h relating to .enable_control, .do_calibration, and .calibration_ok, setting them to true for M0 and false for M1. I thought this meant that only M0 would go through the calibration routine on startup. Nope! The motor was going through a complete rev, despite being plugged into M1 and .do_calibration being set to false. Clearly I’m going to need to look into how those are used (or not used), so I can understand the startup routine better. In any case, the motor was rotating, and I thought M1 was disabled, so it took me that much longer to realize it was plugged into the wrong terminals.
@ngg, thanks for the hint to check the motor error. Once I got everything working with the ODrive-supplied N5065 motor, I switched over to a (much lower-power) BLDY17 motor from Anaheim Automation, which is a nice drop-in replacement for some NEMA17 steppers that I’ve been using. It wasn’t completing the calibration routine, and the error code (error 22: ERROR_ENCODER_CPR_OUT_OF_RANGE) clued me in to the fact that I had misinterpreted the spec sheet, and they have 8 poles, not 8 pole pairs.
Went through the tuning routine, and everything is working nicely! Looking forward to starting to integrate BLDC control into my test rig tomorrow & try out current control.
