Brushless DC Motor Driver now in ObEx
TreeLab
Posts: 138
Greetings All;
I have uploaded to the ObEx a complete description of the Spin-based driver for controlling Brushless DC motors such as those found in hard-disk drives. The control is solid, reliable, and accurate to about 0.5 Hz shaft speed from 10-120 Hz. Total cost is about $10 plus the motor and your preferred flavour of Prop control board; I used SpinStudio, and controlled it using Hanno's ViewPort. The ZIP file includes a long-winded discussion of the operation, the interface, the schematics, details about the home-built encoder, and the code interfaces. It can be found at
http://obex.parallax.com/objects/414/
I hope that it may prove useful to somebody.
Cheers!
Paul Rowntree
I have uploaded to the ObEx a complete description of the Spin-based driver for controlling Brushless DC motors such as those found in hard-disk drives. The control is solid, reliable, and accurate to about 0.5 Hz shaft speed from 10-120 Hz. Total cost is about $10 plus the motor and your preferred flavour of Prop control board; I used SpinStudio, and controlled it using Hanno's ViewPort. The ZIP file includes a long-winded discussion of the operation, the interface, the schematics, details about the home-built encoder, and the code interfaces. It can be found at
http://obex.parallax.com/objects/414/
I hope that it may prove useful to somebody.
Cheers!
Paul Rowntree
Comments
Good application of ViewPort to optimize a project.
Hanno
I'm interested to know:
a) Why you chose to do the speed control by "skipping" activations rather than just changing the pulse width of the activations?. If you see what I mean. Is it because of the problems you hinted at with pulse widths less than 100us?
b) What was the problem with the PID control idea?. Seems like a natural approach many would start with.
Yes, you should never eat or drink alone at work. Also I think the rate of technological advancement will slow down now that it's almost impossible to take a cigarette break with your colleagues on a project[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@ElectricAye : I am delighted with the idea that somebody might make use of this stuff ... it makes spending time on a project easier to justify. As to the docs, I have never been accused of being a man of few words (the package was so big that the ObEx flagged it as 'not for immediate acceptance'.
@Heater :
a) I found that there was enough 'uncertainty' in the timing of the spokes that getting an accurate speed measurement would probably require averaging over several rotations. The spoke-time and cycle-time jitter is clearly visible on the scope even when the motor is running full out (at a specified PWM level) without speed control. This may be due to slight variations in the sector sizes (although CorelDraw is normally pretty reliable) or slight density variations in the toner patterns (more likely, as this Brother MultiUnit does not do very well on transparencies). So I felt that there was going to be a speed uncertainty of at least a Hz based on the PID. THe proper use of the PID meant dragging in floating point, which would make doing PASM less convenient, and I was getting short of cogs for my final app. My feeling is that that the large angular momentum of the spinning disk would lead to extremely long time constants for the PID, and therefore the wheel would be more subject to long-term variations (or at least a long stabilization time). The spin-down times from 100 Hz are ~30 seconds. Last night I played around with using the number of DeadSectors (undriven sectors at the end of a coil time) to change the power dissipation, and found that while heavy acceleration needs 2 or 3 (of 6 sectors per coil), staying at constant rotational frequency is remarkably in-sensitive to this adjustment (as monitored by the proportion of On/Off cycles imposed by the speed control mechanism). So killing the power completely seemed like a good way to get it to cool off a bit.
The 100 microseconds issue means that there is not a linear (or even monotonic) relationship between power dissipation and motor speed; this makes a PID more difficult to tune, and leads to instability if he operating point is on the wrong side of this bump. I don't know if this is the effect of transistor configuration/choice, or the inductance of the motor coils, or ...
b) The PID did seem natural, and that is why I was so surprised to see that the On/Off approach worked so well. The code lets you decide on a coil-by-coil basis or a A-B-C cycle-by-cycle. It seems to work better from the latter, again perhaps the slight variations in the sector patterns requires longer-tem averaging. I had thought of using a PLL to make a higher frequency signal to PID to, but I don't think the Prop's PLL modes work at such low input frequencies. So in the end, practicality won out. At least in Spin, the high end speed requires minimizing all work in the inner loop. I briefly tried to get the counters to generate the variable duty-cycle pulses, but I did not spend much time on this avenue.
*** what I need to do is get an estimate of how many consecutive On/Off cycles are being used. I have an average idea, but not the sequences.
All this being said (by a man not of a few words) : do you think that the PID SHOULD give better control? Would it be more useful for you to have a PID in place?
We have banished all smokers to be at least 9 metres from the doors ... this certainly dampens the enthusiasm for detailed discussions on cold days!
Cheers!
Paul Rowntree
Post Edited (TreeLab) : 2/18/2009 2:14:50 PM GMT
Yeah...this is OT.
I would like to try running a hard drive motor someday. That looks interesting. Perhaps for a laser projector or something....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
I'm also sure that to use PID, without any headaches, one would want a linear response to the commanded output of the PID and for sure at least monotonic. I have no idea why you are not getting that. Switching time of the driver stages could be one thing. As for inductance etc I don't know.
I did once work in a department where they were designing motor controllers to turn huge Radar antenna's, there I saw engineers with many years of experience in such things scratching their heads and wondering why some motor is vibrating like crazy, turning erratically, not achieving speed or generally misbehaving. There seems to be some black art to this.
I'm sure you can do PID in PASM without floating point. Use some 32 bit multiply algorithm and scale things appropriately. I'm always quoting my old boss, from the same radar company who said "If you have to use floating point you don't understand the problem". He had a way to put us junior engineers down[noparse]:)[/noparse]
Would PID be better? I don't know. Depends what this motor has to do for you. I can't help thinking that in a hard drive controller they would not use "bang bang" control. Would it not insert jitter into each rotation and upset the data read/write? But if it works for your application, well, no problem.
By the way, do you have an application? I'm wondering if these things have the power to use them in multi-rotor helicopters for example?
Oh, just thought. You have mentioned a number of times that these motors have a very long spin down time and a very rapid acceleration. This does not bode well for PID, does it? I take it as meaning that the PID would get a rapid increase in speed when it commands so but a slow decrease to the opposite command. I.E. a non-linear response to the commanded output. Well it might at least mean it has difficulty when the set speed is changed. PID might be happier if the motor had a load on it, like a propeller.
Propellers driving propellers, confusing.
Has anyone ever stuck an oscilloscope on the contacts of a hard drive motor in its original hard drive? I love to know what the drive signals look like. Sadly I have no scope.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think the disparity between acceleration/deceleration would make for PID troubles, but maybe that just means I am overdriving the device. Perhaps 5 V would smooth it out. At 100 Hz I am driving the motor at about 6 Watts, and 5 V driving the 3 Ohm coils should be able to give ~8 Watts. Hmmmm.
I would love to see a propeller on one of these things, but since heli-people usually use multi-amp drive motors, I can't help but think that it would not lift. I would like to be wrong here though, because this is a quick and easy way to get nice motor systems going.
My application has this motor spinning a small disk (2-3" diameter) in a vacuum system. The disk has slits to let little bunches of a directed gas through it, and we will get the velocity distribution of the gas by measuring flight times about 0.5 metres downstream. The prop will spin the motor, collect the signal pulses and allocate them to time-bins with ~1 microsecond resolution. It looks like a 5-chip solution that will replace ~$10K in electronics hardware and data acquisition stuff.
I think that real HDD drives are powered by sine-waves, and measure the back-emfs to measure rotation (and position) rather than encoder wheels. There are beautiful VLSI chips to do all this plus voice coil control, but this would be a waste of money and effort for me. I made a tri-phase sine generator, but the idea of working power transistors in linear mode sent chills down my back (as did buying high-current opamps), so I went back to pulses.
Cheers!
Paul Rowntree
Mostly you can get the range you need in 16 or 32 bits or even go to 64 if you like. Over/underflow of intermediate results can be kept under control by arranging your operations in the right order.
If you are lazy write a prototype of your algorithm in ADA using floating point, use ADAs ranges and run-time range checking to be sure nothing explodes. Then write the real thing in fixed point.
I was thinking about micro helicopters, surly they don't requires so much power. Just the power to weight ration must be good. No idea really.
I'm sure real HDDs use a sinusoidal drive with overlapping phases rather than all on or all off for each phase but I would imagine they do it with pulse width modulation rather than analog drive. One could try modern digital amplifiers chips, might be expensive overkill though.
Your application sounds very interesting.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I don't know if the final system would be of much interest to this group, but I could post it once it all running and we have some data to show it's properties. The time-binning pulse couting cog (PASM) works well, the motor drive is in hand ... now all we need is the molecular beam. It should be fully up by March.
Cheers!
Paul Rowntree
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Your comments have made me go back and rethink the speed control (that is why we have the Forum!). Everything that I wrote before is true, but in the end, I am asking myself .. so what? Some more continuous speed control should be feasible and less of a 'bang-bang' approach. Again, thanks to Hanno's ViewPort program I can look at the cycle and coil times as they occur, and correlate them against the On/Off speed control decisions. I think that I am overpowering the device because even within a drive cycle I can see the motor accelerate and then slow down BEFORE the power is cut. I think this means that the rotor is racing ahead of itself, and slows as it comes out of the optimal drive zone. This constant speed change could easily cause the jitter in the spoke timings. Plus, even if it takes 30 seconds to spin down from 100 Hz, that i still several Hz per second, and a good PID or PID type code should be able to work on that time scale.
I am going to try again with a low-level control system, and a less forceful drive conditions. I will let you know how it turns out.
Cheers!
Paul Rowntree
In fact, the warts of the encoder wheel is easily confirmed with a 7x microscope, even when printed on paper. I could imagine doing a photo-reduction to minimize printer effects, which might get a factor of 2-3 improvement .... I will also test speed control based on the roation time for the complete wheel.
I think that the real improvements will be in terms of higher speed via PASM.
Cheers!
Paul Rowntree
http://www.austriamicrosystems.com/eng/Products/Magnetic-Encoders/Rotary-Encoders/AS5040
>I am going to try again with a low-level control system, and a less forceful drive conditions. I will let you know how it turns out.
Are you still working on this object? As heater mentioned earlier in the thread - it might be neat to apply this to a multi rotor craft. The craft I am building has six rotors which adds up to a lot of motor controllers. Right now the default option most go to is the mikrokopter design -there is some detail on their controller here:
http://www.mikrokopter.de/ucwiki/en/BrushlessCtrl
http://www.mikrokopter.de/ucwiki/en/BL-Ctrl_V1_1
The mikrokopter brushless controller is interfaced via i2c. The standard controllers available to the R/C community are too slow via PPM /PWM, my understanding is they max out at 150Hz - most multi rotor craft stabilize best around ~300 to 500 Hz.
My current approach is to build one large pcb that replicates the mikrokopter design 6 times on a single pcb (6 separate Atmega8 and FET arrays)
similar to: http://gallery.mikrokopter.de/main.php/v/tech/PICT0223.JPG.html?g2_imageViewsIndex=2
But I wondered if a single Propeller might handle the FET control too, since I'm already using Propellers for the remote and flight controller. At this point, I won't complicate the project with trying to fit everything into a propeller mold - but I wasn't sure how far you planned to take you controller work...
Thanks for the links. I had briefly looked at mag encoders, but thought they were too slow. The one from AustriaMicrosystems works at 30_000 rpm in the incremental (not absolute) mode; still, with my design based on the hardware counter, this would not pose a problem.
These heli motors are fast! And the ESC board you linked to is a very nice control element. My application is about finished, and the only upgrade that I want to do is the PASM replacement of the spin code. This will increase the top speed, but I don't expect that the BLDC motors that I am using will go anywere near 500 Hz. I will post this when it is done, as well as some idea of how fast I can get these motors to go. My guess is that a single prop would easily be able to do this, especially if the hardware counters were keeping track of rotational position.
Cheers!
Paul Rowntree
I hadn't considered that they were good to 30_000 rpm in incremental mode. I looked at them for other projects, since they have no contacting points and should have long life. Via google you can find many examples of people using them w/ pcb layouts available, etc. - the Reprap extruder being one example. I thought it might make a good solution for wind direction measurement too, most use potentiometers - but I guess I'm getting OT now...
I'll be interested to see what you come up with on the PASM conversion and how it affects update speed - I still have several other aspects to this project to keep me busy before I need to hook up the brushless motor controllers. Perhaps I could use an AustriaMicrosystems sensor on each rotor and use your code to drive the FET section. This would make for some very nice BLMC's : ) ...but then I wonder if the EMI from the motors would interfere with the mag detection of the sensors
thanks!
ian