background on rotor position detection in consumer electric vehicles
Every teardown of a hybrid drivetrain that I've seen so far shows variable reluctance (VR) resolvers that are used for rotor position detection. Sadly, our motors didn't come with the resolver stators, just the laminated rotor punchings. I was curious how these things worked so I looked at patents and papers and even tried making my own. That didn't work, so we plowed ahead with the “standard” (familiar to us?) way of sensing position on brushless motors – three latching hall sensors.
in part 1, we spun up the motor. We even put hall sensors on it. but the output waveforms looked like this:
huh, that's not right…
purple and yellow look almost reasonable, minus the glitching on yellow. the spacing looks to be about 120 degrees. but blue? it is almost a perfect inverse of yellow. This was the cause of much head scratching around MITERS until bayley figured out that the hall sensors we'd collected from various sketchy sources including the floor of MITERS were not all the same part. They had different hysterisis characteristics, which means: given an identical magnetic field input, they will turn on and turn off at different times.
conclusion #1: make sure you're using three of the same hall sensors.
Before conclusion 1 was reached, I thought that inadequate/wonky fringe fields at the end of the rotor were causing the issues. I designed and printed parts of a “Shane Array”, named after scolton, perhaps the most legendary motor + motor control person at MIT ever. A Shane Array is a second set of rotor magnets used exclusively for position detection.
the magnet holder looks like this. It is screwed to the rotor.
The hall sensors go down in the bottom of the housing, pointing up at the Shane Array.
It produced a waveform like this:
dang
the spacing looks about right, but the jiggle is unacceptable. We guessed it came from unwanted interaction with the rotor fringe fields and/or interaction with the the active stator windings. The glitching was less prominent but still present at lower speeds and when the motor was turned by hand (unpowered electrically).
conclusion #2: maybe don't stick your hall sensors inside the motor.
it's an iffy conclusion because sticking hall sensors inside a motor is usually a totally legit thing to do. I'm calling it here because the issue went away when relocating the Shane Array to the outside of the motor, but that's not until conclusion #4.
Next up: CD drive hax. After seeing ben's cool hack for the chibi-atomic-jeep alternator drive, I decided to try the same thing. Most CD drives have a little three phase permanent magnet motor inside, often with hall sensors. Ben's nifty assembly was sitting around unused after the chibi-jeep-gang decided to replace the alternator with a more powerful “melon class” RC plane motor.
it worked great – with the minor caveat that the rotor had 6 pole pairs instead of 4 (like the motor it's going on). Bayley considered writing code to downsample or interpolate or something but that would've been a bit to much of a hack given the knowledge that hall sensors outside the motor can work fine.
I crufted a bunch of CD drives and took them apart to see if any of the rotors had four pole pairs. Sadly they did not…
conclusion #3: most CD drives have 9 tooth stators and 6 rotor pole pairs.
but I did make some interesting observations.
The laptop drives appeared to be sensorless, or at least I couldn't find hall sensors on the boards. It was perhaps cheaper to buy an IC capable of doing sensorless control than it was to buy three hall sensors when the newer laptop drives were designed.
all of the drives except for one preloaded the motion of the read head with a sprung follower on a lead screw
one drive used anti-backlash gears: two thin identical gears on the same shaft with a spring to push them to clamp snugly around the teeth of the (black) driving gear.
The drives were also filled with soft rubber vibration dampers. I wish I'd known these existed back in the multirotor days.
OK this is the last hack I swear. Bayley drew some CAD for a new external Shane Array and it was so. The magnet holes were a bit snug and the print snapped at the seams, so I snugged it back together with dental floss and super glue, a tremendously tough composite material.
yup it works
conclusion #4: put the Shane Array on the outside of the motor.
with Working Sensors Finally, I drew and printed some parts to hold the motor leads and to cover up the sensor setup. The motor lead support thing had some epic bed warp, but somehow survived. The critical dimensions were unaffected, so it does the job just fine. Square M6 nuts are pressed into slots in the print. Combined with cap screws, they clamp the three chunky wires to the three phase leads on the motor.
Next, we hooked it back up to the prius brick.
We're using bayley's prius controller-controller to speak to the prius brick. (post) The purple board contains a couple of buffers, three LEDs that show when each phase is active, a voltage regulator, and connectors for the prius brick, external power, hall sensors, and a throttle. The board underneath is an STM Nucleo F411RE, a.k.a. Arduino Killer.
Like every other “Arduino-Killer” out there it is faster and has more functionality than an Uno.
Unlike many other “Arduino-Killers” it has the same pinout as an Arduino Uno (can support the same shields), and it has a surprisingly functional web based IDE. Cloud-duino? You download the .bin files to the board, which shows up as a flash drive. oh yeah and the board costs 10 bux.
Well the Finally Functional hall sensors got us going, but they still left some things to be desired. Low speed control was not beautiful. Since each of the six hall states only tells us the rotor position to within 60 electrical degrees, startup was jerky. In addition, the hysteresis band on the sensors introduces some backlash (slop) in the measurement when reversing direction. Bayley interpolated an estimate of absolute rotor position in code by calculating velocity from the time between hall state changes. That worked pretty well, but we weren't satisfied. We checked ebay a few times to see if it was possible to obtain a resolver (stator – the motor's rotor already has a 4 pole stamped steel resolver rotor on it). The answer seems to be nope, especially not for these motors. We might have had better luck with Prius parts as they seem to be more available.
two analog hall sensors – a resolverless resolver hack
Ben (Local MITERS guru of moters and many other thing) suggested that we try using analog hall sensors to get a finer position estimate. That turned out to be a REALLY NICE IDEA!
These are Allegro A1324 analog hall effect sensors, leftovers from MAS.863. Rather than latching high or low like the digital halls we used before, these return an output voltage proportional to the magnetic field strength and orientation. They're fed off the 5V rail and return a signal centered at 2.5V that's proportional to the magnetic field strength normal to the package.
Using the Extra Structural MITERS Glitter Glue Gun, I gooped the linear halls right next to the digital ones.
After incorrectly wiring them into the same input pin as the throttle (and wondering why the controller was acting strangely), I Got It Figured.
Very much like the VR resolver that this setup is meant to mimic, the analog hall sensors provide two orthogonal components to the rotor (electrical) position vector. We can estimate rotor angle by computing the arctangent of the two components.
Although you can map any 2D space with a pair of nonparallel axes, orthogonal axes make the math easier. Because of that, the sensors are spaced 90 electrical degrees apart. Since this motor has 4 pole pairs (4 full electrical cycles per mechanical revolution), the mechanical angle is 1/4th of the electrical angle. So I placed the analog halls about 22.5 degrees apart, then adjusted them until the oscilloscope showed about a 90 degree phase offset in the two waves.
code?
To get familiar with Bayley's controller-controller, I implemented the code that solves for angle. After normalizing (-1 to 1) and dividing (y/x) the two components, it uses a lookup table containing the arctangent function to solve for rotor (electrical) angle.
The highlighted lines contain manually calibrated offsets for the analog hall sensors as read by the microcontroller's A/D converter. It seems like they drift. A little doesn't hurt, but a bunch results in clipping of the tops of the sine waves that are sent to the motor.
The block of six “if” statements checks which quadrant the motor position vector is in by looking at the signs of the x and y components. It then adds the appropriate angle offset to the arctangent.
To make sure it did The Thing, I recorded some data and then dumped it over serial. This microcontroller is fancy, but not fancy enough to speak serial while doing 3 phase sinusoidal control.
the right image shows spoolup to constant speed.
here's what the output of the analog hall sensors looks like:
the fuzz in the signal doesn't get picked up by the A/D converter. The difference in height (peak-peak voltage) of the waveforms is calibrated out in code. We'll have to find a less kloogey way of doing that in future. auto calibration?
and here's a test at 60V (the two halves of the power supply are in series). The scope shows phase-to-ground voltage, nice and sinusoidal!