HappyServo - Open Source Brushless Servo Controller
Hello all. As there is some traffic on a servo board being designed by Xerxes, it seems like a good time to start discussion about a similar effort that I have underway, instead of cluttering his thread.
The purpose is a low-cost sinusoidal brushless motor controller capable of driving a range of AC servo motors commonly available on surplus sites and Ebay, in the 100w - 1000w range. The only difference in that range (besides the external motor and power supply) is heat sinking requirements.
The controller itself will be "open source" in that its schematic, board layout, and microcontroller source code will be freely available and licensed under the usual open source licenses.
I do not really intend to make this a "business" in the sense of trying to make a profit or selling complete assembled units. However, I will likely make partially assembled kits with all required parts available. I do not have full pricing worked out yet for that (especially since the design could change due to the demands of potential users), but I expect that kit to cost between $80 and $100, which does not include an enclosure or heat sinking.
Features:
---------
Computer I/O: optically isolated step/direction/enable connections to a PC. The current design does not input and pass through limit switches, reasoning that it is more properly the function of higher level control to do this. I could be convinced otherwise if there is a strong opinion that the extra expense and complexity is worth it. The basic idea is to work with TurboCNC, Mach, and other hobby-level PC-based CNC control systems using standard step/dir interfaces up to approximately 100,000 steps per second.
Motor Inputs: The board requires standard Hall sensor outputs and A,B incremental encoder signals. For now, this leaves out the frequently-available motors that use resolvers for position feedback. Supporting resolvers would add significantly to the expense and a better option would be the development of a resolver-to-encoder interface board. The motor connections are NOT optically isolated in the current circuit. If that is strongly desired, an external isolation board (which would need its own power supply to truly isolate it from the HappyServo board) could be designed. The board can handle encoder pulses up to 500,000 transitions per second, and that can be increased to about 1,000,000 per second with the installation of an on-board jumper. The surplus center motor series gives 8000 transitions per revolution; at the max speed of 4500 rpm that's 600,000 transitions per second. Most other motors in the "surplus/ebay" category have encoders with fewer counts per revolution.
Input power: The board requires two power supplies. The first supply is for motor power and ranges from about 48 to about 170 volts DC. With the change of a few components the input range can be extended to 350V DC; you can often see motors with that high voltage range, though building a power supply for them is not simple. Additionally, an input of 18-30 volts is required to power board logic; this supply shares a ground with the high voltage supply and has low current requirements.
Software: The board requires a PC-based configuration utility that talks to the board over a serial port connection. This utility sets board settings and is used to tune the control algorithm. This program is written for Windows and is freely available. I will eventually make the code for the PC side open source as well.
The circuit board is a standard Eagle 4x3 board. Fitting all the components onto a board this size is a challenge but it is necessary to make sure that everybody who is interested can get the free version of Eagle and mess around with the board however they like.
The board has a hardware-based hard current shutdown limit of about 30 amps to guard against most short circuits. It also has "de-saturation" protection to guard against ground fault short circuits. Current use is monitored to provide soft current limits that can be set to the operating conditions of the motor being used.
A circuit driving an optional externally-connected braking resistor is supplied to assist with deceleration of high-inertia loads.
Technical Details
----------------
PWM Frequency: 16 kHz
CPU: Atmel ATMega64 running at 16 Mhz
Gate driver: International Rectifier IR2137
Power Transistors: ST Micro STGW20NC60VD
Heat sinking: depends on power needs, exact requirements to be determined. The smallest 100w motors will require very little heat sinking; motors up to 1 kW will require careful heat sinking. My current thought on the extreme cases is to adapt PC CPU coolers which are often available cheaply and have very good heat transfer.
Status
------
Schematic: Undergoing some final touches
Board: Design roughly complete except for trace routing.
Circuit: Prototype assembled and functional enough that it works. Braking is not in place yet, nor is voltage regulation, and some of the component values are still being decided.
Microcontroller Software: over half done. All PC and motor signal code is done and working. Commutation is functional enough to begin exercising the power section. PID loop not yet complete.
PC Software: about half done. Able to communicate with the board and graph positions/velocities streaming off the board.
Timeline
--------
Roughly, here's what to expect (these are estimates only)
November 15: Schematic posted for comments. I need to build an actual board instead of a ratsnest prototype to really evaluate and tune the board, but I'd like feedback on potential stupid things I did before doing that. In the meantime I want to get all the circuitry functioning properly in the prototype and get the commutation code finished.
November 22: while the board is off being fabricated, I need to finish building my test harness. I want 8 different makes or models of servo motor (I have 6 so far). The test harness consists of an adjustable-torque clutch to simulate different torque requirements, and also a variable-weight disk to simulate different inertial loads. So far I have acquired the clutch but need to actually build the test stand. I also need to finish a 150v 20A power supply which will be needed to drive the 1kW size motors.
December 1: presentation of initial stress-testing results on various motors. The software should be complete at this time.
The timeline after that depends on the results of testing. If redesign is needed, there will be a delay.
I'll be making a web site to organize all this data more effectively.
Any comments are welcome. I am not attempting to compete with existing commercial products or other hobbyist controller efforts. I have no intention of making money off of this so no motivation to do marketing efforts or comparative analyses with other efforts. There's lots of room for different options (look at stepper driver boards, there must be 50 different products or designs out there). However, with the exception of circuit boards and transistors, I have enough parts on hand to build about 20 boards, so I'm motivated to get this thing to work :-)
Similar Threads:
Derek,
Sounds like an interesting project! I'm playing around with an "ordinary" DC servo design based on the atmega16, ir2183, irf530. I'm just doing it as a learning project. I would be interested in exchanging design ideas.
Are you using any form of protection for the gate drivers? My prototype failed after about a day, so I suspect that it need additional protection.
Hi H500,
I'll be posting a schematic in a week to 10 days, that's the best way I can think of to share design ideas. The gate driver chip is supposed to be pretty robust to anything it would usually see (it is designed to be connected to the power transistors and the high voltage rail after all).... I'll think on any necessary extra protection but I can't think of anything particularly helpful right off the bat.
Pefect timing on the project!!
I was looking for somethink like this for a while.
Basically your controller will work kind of like a VFD out putting pulsed DC to run a AC motor?
Dennis
Hi Derek,
I'm looking forward to the schematic.
I suggest you make sure the A or B channel from the encoder is run to a counter capture input. That way you can decode it in software at low speeds when you need to discriminate direction. As the input frequency gets higher the interrupt code eats more CPU. Then you can change strategy and just count pulses on one channel. At speed you know it will not change direction, so there is no need for discrimination. Also the need for a high resolution is needed only to keep a static position, so it does not matter that the resolution at high speed is 1/4 of low speed resolution.
But why the ATmega64? Would not the 44/58/168 have enough codespace and IO?
And stress testing 1KW motors sounds fun! But for the inexperienced it may not. Bolting everything properly down and keeping the paws away from the power circuits is getting very important at these power levels.
Dennis,
Yes, it is very much like a VFD with extra features for position control. A usual VFD unit would have an interface with buttons and a readout on it to set the speed and would include logic to ramp the speed up and down smoothly; this unit will not do that because it is under computer control.
ESjaavik,
I am using a decoder chip from US Digital (the LS7183) to help with decoding the encoder signals; the outputs from that chip feed directly into counters on the AVR just as you suggest. I chose the Mega64 not so much for the code space as for the combination of timer/counters and PWM channels. However, I'm kicking around the idea of using TWO Mega168 chips instead which would save a couple of bucks and be a little more flexible. In particular, the short duration of the deadtime provided by the IR2137 driver chip has me concerned especially at higher current levels. I can provide my own extra deadtime but to do that I need six PWM channels which I can't do even on the Mega64 if I still want two hardware counters for the encoders. Switching to two Mega168s would let me do that, and it's a pretty minor design change (some of the code goes in one AVR and some in the other). Plus with the cost savings it's looking like a good idea. I didn't really want to be making design changes like that at this point, but the deadtime issue is looking like a potential bug to me.
I don't know the IR2137. But I just looked up the data sheet and it mentions "soft turn on". I assume that the deadtime can be shorter then? At worst you would have unwanted EMI, but probably not a puncthrough of the power transistors. Dealing with the deadtime in the MCU does not appeal to me. A software bug could easily pop the power stage. Bugs in interrupt code can be quite tricky to catch.
@DerekZahn: Of course you're the one making the decisions. I just want the arguments to stand up and be counted:
1. I believe the LS7183 is not second sourced. My experience is that this is bad news.
2. It's really not needed because the AVR is fast enough to do the discrimination in SW at low speed, and it's not needed at high speed. It is physically impossible to reverse without going through a low speed transistition phase.
3. No pins to save. The LS7183 have 2 outputs, so does the encoder.
4. Parts saved. Not so much for the cost in $, but for the cost in PCB real estate and increased layout difficulties. Layout becomes a headache when only 2 layers and a couple of high pin density parts (AVR & Driver) are involved.
Re deadtime:
(Regarding IGBT power stages I have no experience, only a thin layer of theory. So always regard my comments as questions rather than arguments.)
There is a faster version (HD) of these devices. Would that solve any upcoming problems with deadtime?
What about my 240V line voltage? My bus voltage will be 340V mominal. Of course it also means the surplus motors found here are for that bus voltage. (Actually they often are for 400VAC/570V bus voltage.) It would be nice if you can suggest appropriate parts for 340V. Obviously it needs to be tested.
Re using motors with resolver.
They can be converted to encoder. Check out Swede's conversion from encoder to encoder: http://www.5bears.com/cnc22.htm
If what you have is a resolver, you probably have to fabricate a bracket since you are unlikely to be lucky enough to fit it to the same mounting points as he describes it. In addition a commutation disk + 3 optical sensors must be mounted. But if you have a large servo motor for which a drive is unavailable or very expensive, it would be worth the trouble.
Nice to see some progress in your project too! It's little bit different approach than mine.
I'm interested about that tuning software. There are many servo drive builders around (I know at least 4 or 5 AC drive projects) so a common sofware would help many people. I would be glad to see a GPL'd and platform independent tuning software where I could participate in development. How does it sound?
I have seen this output used in comercial units at these bus voltages. It is made by Fuji Electric.Originally Posted by ESjaavik
What about my 240V line voltage? My bus voltage will be 340V mominal. Of course it also means the surplus motors found here are for that bus voltage. (Actually they often are for 400VAC/570V bus voltage.) It would be nice if you can suggest appropriate parts for 340V. Obviously it needs to be tested.
Darek
ESjaavik, thanks for the comments! As I'm sure you have seen elsewhere in life, people (like me) become attached to their own ideas and will resist change unless the reasons are compelling (like: it won't work). I do appreciate the comments and will try to answer all points, but sometimes people just disagree about stuff.
Regarding the "soft turn on", I believe that is a reference to the way the chip allows different size gate resistors for turn on and turn off. I don't think it helps the issue I'm concerned about. And regarding the reliance on perfect PWM, I don't think it's really an issue because the pulses are done by the hardware and there is no real "programming" involved (that is, set one register to X and another to X+1 and you're done with what is required here). Even if there was a problem it would not blow up the power stage because the IR2137 is protected against turning both transistors on at the same time (it won't let you).
Regarding the LS7183, I will stick with it for two reasons: 1) although your coding idea is a clever one that should work, I am worried about implementing it perfectly and testing it adequately in the border cases. 2) I have 20 of the LS7183 that I don't have another use for :-) If the chip gets discontinued, that can be dealt with (just as if the other single source components -- the AVR and the IR2137 disappear that would be necessary as well).
Regarding the high speed version of the IGBT, thanks that's a good find. They are more difficult to obtain and it appears like using them would add about $1 per IGBT, but it might be worth looking into. As long as the somewhat anemic gate drive current from the IR2137 is adequate, any IGBT should really be usable. The idea of using two PWM channels per half bridge is I think not unusual... it's just a pity since the deadtime thing is a feature of the gate driver chip anyway.
Regarding higher voltage, all of these parts are designed to deal with 350v bus voltages. I can only see two changes to the thing I am actually building: 1) the board has a rather sizable capacitor across the input high voltage supply. That goes up in price with voltage so I'm using a 250v part, but putting in a higher voltage part instead should not be a problem. 2) there's a voltage divider to monitor bus voltage; a minor component change would make it able to handle a higher range (one resistor value changed).
Thanks again for the comments!
Xerxes:
I will eventually release the source code to the PC side of the application, but that will only happen after the rest of it settles down, either into a successful stable design that I'm not changing any more or into something that died out for lack of interest or success. The big advantage of making the actual hardware and firmware open to inspection is that people can detect flaws in the design, and manufacture it (or variants of it) as they wish. Those things are not as important for the PC software side.
My experience with internet collaborations on such things is that it rarely works and is almost always more frustrating than helpful. However, it's not a very complicated application and any software coder could build a similar program with little effort.
In your poll thread you said that your design did not require tuning; I thought that was an extremely cool feature, have you changed that in the last couple days?
Xerxes, just a little more clarification: a collaborative effort on a platform independent UI for this type of application could be a great thing. I would be interested in contributing snips to it if somebody else organized it. But here is what happens in 90% of such efforts:
Participants argue for a long while about which platforms to support and how to make it platform independent. Joe wants to use one GPL'd framework, Jane wants to write the core in Python, Bart said he had something half developed but isn't answering his email any more..... then everybody has their own idea about which communication protocol should be used and what values should be communicated between the board and the PC... that turns out to be dependent on the hardware so a general mechanism has to be agreed on and a fight breaks out about whether to use modbus or xml. Meanwhile Jane lost interest and Joe decides to go off and do his own thing because the group didn't agree with his ideas. Ernie joins the project and has to be brought up to speed. He has his own ideas. Three months have gone by and everybody is waiting for Bart's code that is supposedly almost done.....
That sounds like my job, not something I noodle around with in the evenings for fun!
Derek, you are right about what kind of mess open source development can be if it's badly organized without clear objectives.
But I partially disagree with that part you said that it is less necessary to have open PC software than open firmware. The software and hardware on drive itself are married and inseparable. There is no risk that software becomes incompatible with hardware or software suddenly stops working when nothing has changed. And it is rare in open source world to someone else than developer himself read the source carefully or fix any bugs. Usually users just report the bugs and the developer fixes them, open source or not.
But when it comes to PC side software there are thousands of different machines where it must run, it is impossible to test it on every system. PC environments are also changing over time so it can not be told if software runs two years from now. There are also some hardware connectivity issues (i.e. parallel and serial ports are disappearing). So I think the most important part to be open is PC software especially when hardware part becomes useless if PC software refuses to work. But I noticed that you are releasing the source of PC software as well so everything is OK in your project.
I agree!That's why I wrote that I will just present my arguments. I also agree on your comments on the difficulties of a collaborative effort on a basis where the commitment is not rooted in placing bread on your table. So my opinion is you make the decisions. We make arguments, up until the item in question become a decision. I now know a couple of those.
As the source is open (so I understand), we can make contributions, refinements, additions, change of use, whatever. But those also become open for anyone to use. Including you. That way there can be some collaboration, although the decisions are yours. But I suggest you get moderators rights to the thread so you can close or move out any posts that just clutter up. Maybe like this one?I've seen a similar project on a German forum that had 749 postings in 3 months! Enough to make a "why did xxx blow up?" forum.
At least if the cheaper one turns out a problem.Regarding the high speed version of the IGBT, thanks that's a good find. They are more difficult to obtain and it appears like using them would add about $1 per IGBT, but it might be worth looking into.
But I assume the capacitance goes down as well? Anyway I have a number of hi voltage, hi capacitance, hi ripple caps. So I still volunteer for testing and debugging.1) the board has a rather sizable capacitor across the input high voltage supply. That goes up in price with voltage so I'm using a 250v part, but putting in a higher voltage part instead should not be a problem.
I don't have a lot of experience in high powered electonics, so I was wondering if the ir2137 is simply 3 bridge drivers in a single package? In other words, can six ir2104's be used instead? This are 8 pin SOIC chips costing $2.00 CAD each and is readily available from digikey.
Also, do IGBT's have any advantage over mosfets in motor control apps? The IRFP460 is a low cost 20amp 500v mosfet.
My project usually results in a few casualties, so I'm very partial to low cost, easy to obtain parts.
Yes. Assuming you put a bit more into the expression "bridge driver" than older devices.
No. The IR2137 have ..... (IRF says that much better than me->) http://www.irf.com/technical-info/wh...whitepaper.pdfIn other words, can six ir2104's be used instead?
Also the IR2104 is for one leg of a H-bridge.
If your priority is low cost, I think this thread may not be the right one for you. It seems to me this one is more like a "hot rod of servodrives" for those that want to build something that really kick azz. But just like the car analogy, the resulting pile of junk can make loud noises and become expensive if you fail.My project usually results in a few casualties, so I'm very partial to low cost, easy to obtain parts.
H500,
Sure you could use 2104s and other transistors of your choosing when designing a board like this, if you work through whether they are a decent match or not. There are many, many different alternative schemes because there are so many different products out there, and they wouldn't sell by the thousands if they were stuipid so for some application at least they are all good options. I made my choices (and could change my mind if my choices turn out to be horrible).
Cost is an interesting question certainly; my goal was low-cost, but not trying to cut wherever conceivable. Here's a rough analysis of the absolute minimal servo drive system of the rough type being explored by myself here and Xerxes in his thread (these costs reflect relatively low quantities, quantity 1000 could cut prices significantly!):
PC Board: $5
Power stage: $25 (either a module or low cost discrete components)
CPU etc: $5
Serial interface (for configuration): $3
Input capacitor: $2
Sensing: $2
Misc components: $2
--------------------
Total: $44
When figuring "actual costs", it probably makes sense to add about 20% for shipping of components, mistakes, and so on (the actual amount varies on volume of course, but there is some overhead involved in collecting all the parts for assembly and errors will occur). So figure $53 as a more realistic component cost.
The costs of the HappyServo add on to this base as follows:
$4: screw terminals. The above scheme assumes that all incoming wires from the power sources, computer, and motors will be soldered directly to the board. That's not very convenient and screw terminals are worth the cost IMO.
$2.50: LS7183. Could be coded around. I'd still prefer some sort of buffer chip but that could be much cheaper than using this chip, which helps with noise issues and takes load off the CPU.
$2: Optical isolation from the PC. Possibly this might be provided by a breakout board anyway. I prefer not to assume that and put it onboard.
$6: Braking resistor support (gate driver and transistor mostly). Not required to make the motor turn, but desirable for responsiveness during deceleration.
$7: More capable power stage. On this board, that's the IR2137 and the 30A transistors.
$0.50: LED. Blinky lights are cool.
$3: Onboard 5v switching regulator circuit. The base module above would assume a stable 5v external source. I'm choosing not to require that and generating it on board from an 18-30v external source which also generates a 15v signal for the gate driver. The large voltage drop makes a switching regulator a much better choice than a cheaper linear regulator, but for $1 or less you could get the linear regulator as a compromise position.
So, that's $25 extra for the HappyServo over the bare minimum. With the abovementioned overhead, call it $30 extra for a total component cost of about $83.
For three boards, that's almost $100 extra and it's a valid debate whether the extra money is worth the extra functionality and convenience. It would be a fun project to design the "cheapest possible" board (somebody clever could probably save money over my "baseline" above). I can only work on one project at a time though, so somebody else will have to do it.
Thanks for the feedback everybody!
Esjavic & Derek,
Thanks for the info. The price for the drive is quite reasonable, considering what it does.
I'm just getting into high voltage designs and the components are far less forgiving of design oversights. I'm just going to order a bigger box of goodies to feed the hungry beast.
A quick update, as my original timeline had me releasing a schematic today. Unfortunately, I have been having difficulties in the design and testing of the power stage and have now destroyed all of my spare transistors. Apparently I have a lot to learn about the details of discrete design.
For the time being at least, I am switching to an integrated power module for the first version of this board. The advantage of this is that professional engineers built and designed them and it is likely to be more robust than what I can design myself at present. The cost is roughly equivalent. The downside is that the power capability for this first version will be greatly reduced. I would not want to use it with a motor bigger than 400 or 500 watts.
Once I get this version working I will move back to designing my own power stage (I still have 20 of those IR2137 chips I need to do something with!), but that will not be for some time.
I expect to have some info on the redesigned system in a couple weeks, but I'm not going to give dates any more, as who knows how many other things I can screw up.
I know the feeling. They are quite expensive as party crackers.
Getting things working at a lower power (and cost) level is a good strategy. When you have a working design parts of it can be changed to increase the capability. Split and rule.The downside is that the power capability for this first version will be greatly reduced. I would not want to use it with a motor bigger than 400 or 500 watts.
Uhh... I will not discourage you by guessing. Been there, done that, as who knows how many other things I can screw up.
Posting Permissions
Reply with Quote
