Hi,
tl;dr new motor only runs for a few rotations, then the motor stops without error. Within the band of a few rotations it can go back and forth at high velocity for hours.
Setup:
I’ve used ODrives with motors like the D5065 successfully for many years. Great project, it’s been incredibly helpful to my work. I’m currently trying to work with a scooter hub motor like:
15 pole pairs, with a rigged external encoder looking like:
The timing belt is tight and I don’t think there’s slipping; position mode can run back and forth for a very long time without a problem as long as it’s within those few rotations. I can’t imagine it’s encoder noise, because I can have it whipping around within a couple of rotations for hours, using tons of current and dumping loads of back emf, but the slowest velocity or position move will die when it hits a few rotations.
This seems to be related to these problems, perhaps, but it’s hard to tell if these were resolved.
probably, the ‘gear ratio’ of your belt is not exactly 1:1, so after a couple of turns, the ODrive is out of calibration as to which coils to energise to produce force against the permanent magnets.
I’d recommend that you use the Hall sensor built into the motor for commutation. There is some experimental support for dual-encoders that will let you use your external encoder for high resolution position feedback.
Hi @towen, thank you very much for the reply. I’d assumed the hall effect sensors wouldn’t be able to give me very smooth motion. I will give it a try, but before moving on, I’d like to understand this conceptually.
You are correct, the encoder is at a 5:1 ratio to the motor, ie the motor has a 100 tooth pulley and the encoder’s pulley has 20 teeth. My assumption was that the Odrive would simply see the encoder as 40960 CPR. Each of the 40960 pulses should always land on the same position in a rotation – and thus I’d thought that they would always align with the magnets in the same place. So yes, the pulleys aren’t 1:1, but the encoder/motor ratio should be consistent and repeatable. Of course, I didn’t expect the index to work… I know there are threads of people using magnetic ring encoders, etc., but I assumed that was to avoid extra and possibly sloppy mechanical parts.
The Founder @madcowswe wrote something that makes me think this should be possible:
Is this not the case? If not, can you tell me why (or point me somewhere)? I’m guessing i’m not the first to run into this misconception, as my searches through this site didn’t tip me off.
I’m seeing the dual encoder approach, and I will try to research more on that soon! Thanks so much for your help! I’m sorry if this is 100 level stuff.
You’re right that a toothed timing belt shouldn’t slip, and that a 5:1 ratio should be /exactly/ a 5:1 ratio, so maybe I could be wrong there.
If you were going the other way (as is more common) and had a reduction gear between motor and load, and you had mounted the encoder on the load lets say, then 8192 does not go into 5, and you would be in trouble.
However, with a 5:1 /multiplication/ to the encoder, you’re quite right that you should see a 40960 count encoder…
However, the fact that you can run perfectly back and forth within a certain window even at high speeds, indicates that the only possible problem is that your cpr is slightly off (it only needs to be off by one count to cause this)
Maybe you should check by manually rotating the wheel by 10 turns or more, and checking that the encoder reads as you would expect?
you can zero the count with encoder.set_linear_count(0)
Hi Tom, YOU are right. I forgot the cardinal rule: it’s always the encoder.
I manually spun and counted as you suggested, and the number was indeed off. This led me to look more carefully into the pulleys and find my wheel pulley had some gunk in a few consecutive grooves: this caused it to ride up on the (shallow) guards, but not every rotation. Spit, polish, and I’m now able to go thousands of rotations without a problem.
It’s a testament to my experience with ODrive that I never doubted it, I just assumed that I was missing something about BLDCs or making some error. Thanks again for your help. To the barricades!
