Trying to get started with ODrive and 1500w Golden motor. Following the ‘getting started’ guide. Tried both CUI encoder and motor hall sensors. Details below. All help much appreciated!
Hardware seems to work, I’m using OdriveTool on Windoze PC, it works, I can talk to the ODrive, all looks good. Running from a 5A 48V power supply for now to limit current. No load on motor.
Encoder A and B signals look good on a scope when spinning motor by hand. I did not hook up the Z line since it is optional. Cui 102 encoder.
As suggested in the doc I hooked up DC to one winding and counted bumps when turning the motor by hand. I counted 5 bumps in one revolution and entered that 5 in the “pole pairs” field. Repeated the test several times. Saved config and rebooted.
I can run the calibration command, it jumps and the motor turns one way, but usually it does not turn back the other way. Then I can find errors, usually they are encoder errors.
The encoder by default was 2048 PPR so the Odrive default 8192 is good. So why am I seeing “cpr out of range” or whatever the exact error code is?
Yikes, at 5000 RPM 2048 PPR is 10MHz, that’s not so good. So I set the DIP switches in the encoder to make 100 PPR, and entered 400 in the ODrive software. Still no good.
Since i was getting encoder errors, I decided to ditch the encoder and use the hall sensors built into the motor. Wired it up, with .02uf bypass caps. Set the CPR to 5*6 = 30. But when I do the calibration routine I’m still getting errors. I can easily switch between hall and encoder, so advice about either mode will be helpful.
The hoverboard part of the ‘getting started’ guide mentions a lot of different parameters because the motor is so different from a typical R/C plane motor. I wonder if this is the root of my problem. How to choose reasonable starting parameters for my motor? The motor is Golden Motor # BLDC-108, you can go here and scroll down, but they don’t provide a lot of tech data. https://www.goldenmotor.com/frame-bldcmotor.htm
So I have yet to get the motor spinning. I can get partway or (once, I don’t know why it was different0 all the way through the calibration procedure, but then it leaves error flags and I can’t get the motor to run. Any advice about what I should try next will be much appreciated! It looks like the ODrive is a good system that will meet my needs… but the learning curve feels a bit steep right now.
I have seen the inside of several motors, and think that you have the pole count wrong. That is a high torque motor, and there should be dozens of poles. 12-48 poles on a large diameter hub motor is not unusual. There should be a multi of 2 more magnets than poles. Also the pole found is usually a multiple of 3.
I am planning a similar project soon, and am curious of the answer
I got it working. I’m a complete newbie to Odrive so I was making several mistakes. But I’m not a newbie to motors and motor controls.
I had to turn up the current used in the motor calibration process.
And I did not realize that error states latch in and need to be cleared. So I’d try something, then try something else and it wouldn’t work because the controller was shut down.
I don’t think the pole count was the problem. I got it from the “apply DC and count the bumps” method described in the Odrive docs. And it’s a high speed motor (5000 rpm) so a fairly small pole count makes sense. It’s not a like a hub motor.
Yeah I changed the encoder to lower PPR when we were floundering. 600kHz seems fast to me for cables perhaps 2M long, shielded but no special precautions. Then we got it working, and we never went back to try the higher PPR. So the encoder might not have been the problem, I don’t know.
The motor does not feel like it has high cogging torque when you rotate it by hand. But it does have significant inertia. Again this is one of many things we changed on the way to getting it to run. I can’t say for certain that this was the problem.
Update: We have set the Odrive aside for now. This project has a really short deadline and we just ran out of time, so we switched to a controller we have used before. We’ll come back to ODrive later when we have more time. So while I’m still interested in this topic, it is no longer time critical. Thanks to all for your help!
It may not matter, and that’s OK, but here is why we have (for now) changed away from O Drive:
trouble getting started, climbing the learning curve. We knew these issues were solvable but they delayed the project and cost us time.
Serious EMI (electromagnetic interference) issues. If I recall the Odrive emits a lot of switching noise at around 50kHz, and this was getting back into our DC bus and causing problems elsewhere. We could solve it I’m sure… but not quickly and certainly.
Then the O Drive board died, became totally un-responsive. Sure, very likely we killed it, but there was no event we could point to, no overpower event or slipped scope probe or “pop” or anything. So we have a spare O Drive but we have lost confidence, at least for this time-critical part of the project.
Hi, noob alert - I’m just getting to grips with odrive and am finding it something of a steep learning curve!
I have the same issue as Erik. I get everything connected, can speak to the board etc. The encoder is sending what seems reasonable position data.
However, when I run the calibration sequence, the motor just turns one way. Then the motor becomes unresponsive to further commands until I reboot the odrive. The whole setup is on a baseboard at the moment so there’s no load other than the encoder itself.
I did increase the current as suggested by Erik as the solution to his problem - but no difference.
If anyone can point me in the right direction, I’d be grateful. I feel I’m close but am struggling to find a way through the maze!
So our project is a small electric vehicle. It has two hub motors but at this time we are not using O Drive for those. It’s a narrow three wheel vehicle so it needs to lean into the turn to balance. Like a motorcycle or bicycle. The tilt is computer controlled, and the tilt motor is what we were trying to use O Drive for. The vehicle was presented at Y Combinator demo day online yesterday. You can see a short video here:
It was a very intense three month design and build process. We simply ran out of time to climb the O Drive learning curve. Likely we will investigate O Drive further for future versions when we have more time.
