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 the last post of this series, we spun up the motor.  We even put hall sensors on it.  but the output waveforms looked like this:

IMAG0734

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.

IMG_0453

The hall sensors go down in the bottom of the housing, pointing up at the Shane Array.

IMG_0350

It produced a waveform like this:

DS1Z_QucikPrint4

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.

IMG_0376 IMG_0377 IMG_0378 IMG_0379

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.

IMG_0392 IMG_0393

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

IMG_0394

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.

IMG_0395IMG_0396

The drives were also filled with soft rubber vibration dampers.  I wish I’d known these existed back in the multirotor days.

IMG_0397

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.

IMG_0409  IMG_0411

yup it works

IMG_0412

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.

IMG_0423 IMG_0424 IMG_0442 IMG_0443

Next, we hooked it back up to the prius brick.

IMG_0512

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.

IMG_0513

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.

STMide

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.

IMG_0496  IMG_0500

Using the Extra Structural MITERS Glitter Glue Gun, I gooped the linear halls right next to the digital ones.

IMG_0502IMG_0499

After incorrectly wiring them into the same input pin as the throttle (and wondering why the controller was acting strangely), I Got It Figured.

DS1Z_QucikPrint7

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.

arctan

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.

all_the_halls

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.

code

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.

numCaptureanaloghalls

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!

YOWZERS – CURRENT CONTROL IS NEXT?!