HappyServo - Open Source Brushless Servo Controller

[DerekZahn]

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 :-)

[H500]

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.

[DerekZahn]

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.

[DennisCNC]

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?

[ESjaavik]

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.

[DerekZahn]

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.

[ESjaavik]

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.

[ESjaavik]

@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.

[Xerxes]

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?

[HillBilly]

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.

I have seen this output used in comercial units at these bus voltages. It is made by Fuji Electric.

Darek

[DerekZahn]

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?

[DerekZahn]

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!