I’m trying to get an ODrive working with a somewhat large 24v seemingly 4 pole pair BLDC motor which provides the standard UVW hall sensor output, open drain.
ODrive just gave me a pole pair/CPR mismatch error, so I did a bit of digging and discovered by monitoring the shadow count that I was actually getting closer to 16 counts per cycle rather than the correct 4*6=24, but it only counted even remotely correctly in one direction.
Before you ask, yes I added the 22nF caps to ground! Didn’t improve matters.
So I tried connecting the sensors to an Arduino running SimpleFOC’s hall encoder library (since I could run that standalone) and it got pretty similar counts to ODrive under manual rotation, leading me to think it’s not ODrive’s fault.
On the logic analyzer (without caps) I got a lot of PWM noise, so I put caps to ground, which made it much smoother, but still with odd leading and trailing pulses that shouldn’t be there:
Any thoughts on whether this kind of waveform is likely to confuse ODrive, or is there software filtering for this kind of thing already? Anything else I should try before giving up and putting regular encoders on the shaft?
After a few attempts at things like low pass filtering, I shimmed in an arduino to locate and suppress the leading and trailing extra pulses, with capacitor to remove PWM noise. This was enough to get the ODrive up and running, however low speed operation trips the current limit and the motor is running somewhat rough at moderate speeds, with some hall state errors, so I suspect I’ve introduced too much phase lag on the hall input with the filtering. Certainly I’m seeing somewhere around 0.5ms lag through the Arduino on the analyzer, but I think some of that is a difference in the Arduino vs analyzer detecting the edge as the cap charges, using horribly oversized 100nF caps as I had a pile of them.
So I’m going to try using different encoders to see if that resolves the issues. I’ll post an update after I’ve tried that, in case anyone else has this kind of hall noise and has hope of ever being able to rely on the halls…
Hi! ODrive docs provide some recommendation about using encoders (it applies to hall sensors too): Encoders — ODrive Documentation 0.5.4 documentation . Encoder noise section. But I’m sure that you know this docs by memory It seems like you use low quality Chinese bldc motor (sorry if I’m wrong) and I have an experience where encoders not properly allocated inside the motor (or motor magnets) so in an oscillogram you could see the weird signals that looks like the noise. Nothing could be done with this motor. You could try: ignore_illegal_hall_state = True property in odrive’s config if you see this kind of error and still want to use halls. Hope that all will work properly. But yes, just use another encoders).
Yeah these are Chinese motorized trike geared motors which are usually paired with their own controller that probably tolerates the noise. I imagine they’re usually run at quite high speeds so the halls are really only needed to get the motor started.
I’ve used ODrive on other motors with various other encoders without too much issue. I am already having to ignore invalid hall state to even keep this motor running for a few seconds.
I’m in the process of rigging them up with some leftover AS5047P encoders I gave up on for my last project because mounting them in the real world is tricky!
Yep. So similar situation with mine except that our system works continuously. Guess that it’s some sort of luck) The new motors we recently arrived (similar specs, Chinese also), don’t have that issue
It seems like you use low quality Chinese bldc motor (sorry if I’m wrong) and I have an experience where encoders not properly allocated inside the motor (or motor magnets) so in an oscillogram you could see the weird signals that looks like the noise. Nothing could be done with this motor. You could try: ignore_illegal_hall_state = True property in odrive’s config if you see this kind of error and still want to use halls. Hope that all will work properly. But yes, just use another encoders).