BLDC motor control using Atmega328

Turns out that finding motors with integrated sensors is hard to do unless you’re looking for industrial sized motors. There are a few intended for RC cars, but they have a low pole count and are not suitable for precise positioning. In lieu of finding good sensored motors, I decided to add sensors to my own motor. Turns out adding sensors to an outrunner BLDC is pretty straight forward (see my blog post here for more info). Plug these sensors into the control board, make sure you have the 3 motor wires plugged in in the proper order (trial and error is a good approach), and set the timing appropriately and you have all the makings of a sensored BLDC driver.

One thing I’ve found particularly exciting is that I’ve come up with a way to use the hall sensor information to simultaneously keep track of the position of the motor. It’s only as precise to 1/(number of magnets * 3) revolutions, but if you have a high enough pole count on the motor you can get away with using the hall sensors in place of an external encoder. That is a significant cost saver on position feedback. In case a higher resolution is needed, there are two additional pins broken out for the A and B channels of a quadrature encoder, and the software can be updated to monitor the position of the encoder rather than the hall sensors.

As for how the position feedback from the hall sensors work, it is very similar to the method I presented in my quadrature post. If you haven’t done so already, I suggest you go and read it since I’ll only talk about the differences here rather than going through all the details again.

The operating principle of reading quadrature was to use the previous and current states of the two channels combined together to become the index for a lookup table. The value in the lookup table would then be added to the position to either increment it, decrement it, or do nothing. In the quadrature case the index value is a 4-bit integer (2 bits for the previous state of channels A and B, 2 bits for the current state), so the lookup table is 2^4 = 16 elements long. Using the same thought process, it’s possible to build a lookup table using the previous and current states of the 3 hall sensors. Since there are 3 sensors, the index value becomes a 6-bit integer and the lookup table becomes 2^6 = 64 elements long. It’s a lot more work to fill out a 64 element table as opposed to a 16 element table, but it’s a one time deal and the performance is just as fast as the 4-bit quadrature version.

The end result of all this trickery is a free encoder (if you count the cost of the hall sensors as required even without the position feedback). Although it is admittedly coarse in comparison to most quadrature encoders, when a high pole count motor is coupled with a geared down drive (such as a lead screw) the resolution becomes good enough for fine position control. For example, a 22 pole motor gives 66 counts per revolution, and when combined with a 16 threads per inch lead screw the positioning accuracy comes in at (1/16) / 66 = 0.00095 inches per count.

See this post for details on the hall effect sensor PCB.

It’s not uncommon practice in data acquisition hardware for there to be a feature called “sample and hold.” What this feature does is take a signal from the host microcontroller/computer/whatever which then causes the hardware to freeze the values on all the analog inputs. The reason this is important is because it takes a finite amount of time to read the analog signal, especially if there are multiple pins to read. During this read time it’s quite likely that the signals are changing, and by the time the microcontroller gets around to reading the last input some amount of time has passed since reading the first input and the value has changed from what it was when you first started sampling.

Imagine you had analog signals coming in to each of the 6 analog inputs on an Arduino. These incoming signals are changing fast, perhaps reading accelerometers on a vibrating object. You want to sample all 6 sensors at the same instant in time. Without sample and hold, you would read the first input at t=0. Say it takes y amount of time to complete the analog read. Now the Arduino moves on to read the second input at t=y, third input at t=2y… sixth input at t=5y. The sixth sensor has not in fact been measured at the same time as the first sensor, but rather 5y amount of time later. Usually y is not a lot of time (on the microsecond scale), but depending on your application and what else is happening with the sample (perhaps lots of math) it may be important. Sample and hold will eliminate this problem by sampling all sensors instantaneously and holding the value while the measurements are being taken.

In my 3D printer I plan to have multiple motors, each with their own control board. The control boards are keeping track of the position of their respective motors and sending that position back to the master controller when requested. In order to keep the closed loop control of these three motors as accurate as possible, I decided to implement a sample and hold feature on the control boards. It works like this: when the master controller is ready to read the position of all the motors, it sets the sample and hold pin high. This one pin is routed to all of the control boards. Once the control boards see that sample and hold has gone high (on a pin change interrupt), they take their current position and save it into a buffer. Then, when communication for the position begins it is read out of the buffer (rather than the actual current position, which may have changed from the time that sample and hold was set). Once the position has been read from all the control boards, the master sets the sample and hold pin low and the control boards are ready to do the whole thing over again.

Everything I’ve explained to this point is all taken care of by the on-board software and the only hookups required to operate a BLDC motor are power connections (logic power, motor power and ground), motor connections (coils ABC), hall effect sensors, and direction and PWM inputs. For the minimalist user it is very easy to get a motor spinning.

But since the hall effect sensors can keep track of motor position there needs to be a way to get that information from the control board to an external microcontroller. I opted to go with SPI communication for two main reasons: the SPI pins already need to be broken out to a header for programming the on-board microcontroller (via an ISP programmer), and SPI is FAST (up to 4MHz clock rate on Arduino, 10x faster than I2C).

To avoid redundant headers on the board, I chose to go with the standard 6-pin ISP programing header (2×3) used on Arduino and expand it with 4 additional pins to a 10-pin header (2×5) for slave select, direction, PWM, and sample and hold. I particularly like 2 x whatever headers because connection cables are easy to make with ribbon cable and clamp on insulation displacement connectors like this.

The control board is running as a slave on the SPI bus. When the board detects that the sample and hold pin has been set high it takes a snapshot of the position (32 bit integer) and breaks it into 4 byte sized chunks. The master then requests each chunk individually and the slave responds with the appropriate byte. It’s then up to the master to re-assemble the 4 bytes into a single 32 bit integer. So far this is the only SPI communication available on the control board, but in the future I plan to be able to have the master write contents directly to the control boards EEPROM which will be read on start-up to configure things such as the order the motors 3 wires are plugged in.

The Arduino SPI library only supports SPI in master mode. I was a little bit bummed by this, but not too bad since I’ve been digging more into the bare atmega instructions anyway. Through a lot of datasheet surfing, head banging against the computer screen, and trial and error I eventually got hardware SPI working in slave mode. As far as the amount of code it’s not all that bad. Straight forward, really, once you get your head wrapped around it. But getting to that point… not the easiest task ever.

Operating Voltage Levels

As stated at the top of this post, the end goal is to be able to run the control circuit on 3.3 or 5 volts and drive a motor with 8 – 36 volt supply. My current version of hardware falls short of these specs. Currently I am limited to 5v only on the control side and 5-12v for the motor. I have identified the problem in the schematic and updated the design so that it should work to spec, but I have not yet ordered the new PCB’s to verify the design.

For my 3D printer, which was the motivation behind this control board, I plan to use an Arduino Due as the external controller because of it’s impressive speed. The Due only operates at 3.3v, so it is imperative that I get 3.3v working on the control board.

That’s it for the hardware description of this board. I’m really pleased with the progress I’ve made here. I think I’ve come up with a design that offers both simplicity for interfacing with external controllers and a good selection of features for a high performance controller. In an upcoming post I will describe the software that I am running on the controller. Until then, check out this video of the thing in action.

As with all my circuit boards, I plan on selling this one to anybody interested. However, at this time the board has the limitations detailed in the Operating Voltage Levels section. If you want to get your hands on one of this version, or if you’re dying to get the updated version, leave a comment or email me. Depending on the response I get from the public I may choose to accelerate my plans.

UPDATE: V2 has been tested and is running after a few modifications. A V3 design has captured these latest modifications and is on order (hopefully the last version). If V3 works as expected I will post the design files and start selling it in the Makeatronics Store. In the meantime here’s a video of V2 in action. I will post more videos shortly with position and velocity control.