3DR/DIY Drones Servo Board Project

Hi All,

Let me offer an EMC2/LinuxCNC perspective.

A common way of controlling a cnc machine with servos using linuxcnc is this:

- a "dumb" power-stage which essentially is just a powerFET or other current-switching circuitry drives the motor current. It takes PWM input. For a DC brushed servo this is just a singe H-bridge. For a 3-phase brushless motor or an induction motor this would be 3-phase H-bridge.

- an FPGA generates the PWM-signals, as well as reads the servo encoder signals. For a 3-phase motor the FPGA firmware does commutation also. The FPGA runs on a 50 or 100 MHz clock.

- LinuxCNC running on real-time linux closes the loop with a PID-controller. This loop usually runs every 1 ms. As argued previously in this thread the mechanical bandwidth of most cnc-machines is not very high, thus 1 ms is enough.

MESA-electronics makes some excellent FPGA-cards (PCI or PCIe I think) which have good support under linuxcnc. The firmware VHDL is open-source, and is compiled with Xilinx tools that Xilinx provides for free. MESA as well as pico-systems/Jon Elson also makes power-stages both for brush-DC and brushless.

I also agree with previous posters that making your own servo-controller is probably not going to be faster or cheaper than buying something ready-made.

My suggestion: stand on the shoulders of linuxcnc. get a MESA fpga-card, use the existing VHDL for encoder-counters and PWM generation. Start with an ultra-simple L297/298 power stage and a small motor with an encoder. Get familiar with modifying and compiling the VHDL. If you want the PID-loop to run on the fpga with step/dir inputs then work on that. If you want a stand-alone solution the get a stand-alone FPGA from MESA, or make your own fpga-board. If you want a high voltage/current powerstage then look at the IRAMS modules or similar.

cheers,
AndersW

I have a little bit of experience here with servos. Basically, unless you want to get crazy on the control software side, most setups use a step based pulse system. Nothing wrong with that and of course it allows for cheap stepper drivers and motors. Some of the high end servos take velocity inputs via serial data connections and special protocols.

My suggestion is to get step/dir pulse based working, then you can always add in front end code to accept other formats.

Both Gecko Drive servo controllers and these makerbot ones below can use step and direction pulses:

http://wiki.makerbot.com/dc1

The problem here is that I was too in search of a DIY servo driver, based on step and dir pulse inputs, using common microcontrollers.

Here's what I know:

Messing with the open source Makerbot servo, the firmware is not in any way good to use at this time stock. Maybe someone can fix the magic bullet, but the system right now has horrible response in one direction. In other words, the comparator loop only works well (fast update) but in the reverse, a horrible lag. Knowing that using the Arduino IDE introduces lots of wasted cycles in the compiled code is at least somewhat to blame for the performance. I say this because some other designs based around PIC microcontrollers pretty much use assembly code to massively speed up the feedback comparator loop to a reasonable rate. Again, this is my limited understanding with a fair amount of hands on testing.

This forced me to just buy Gecko drivers which are reasonably priced. If you look at the gecko drives structure, they use FPGA which is insanely fast since it's hard coded logic that performs at near analog rates. By that, I mean update is so fast, the main comparator is running in the several kilohertz range as the drive is outside the range of my hearing. No hiss, no squeak, no buzz. I don't ever think you are going to get a microcontroller, even with assembly, as fast as FPGA.

Here are some videos:

Arduino based servo drive= very bad performance.

https://www.youtube.com/watch?v=lrpXtdeTUNg&feature=g-upl

Gecko based

https://www.youtube.com/watch?v=wBnbQrs6JsQ&feature=plcp

Stucture, no matter what is the same for all servos.

You basically have a comparator that takes a commanded position VS sensed position. It outputs to an H bridge. There is ususally a front end module to interface to quadrature or other encoder to get the sensed position, and then of course, there are gain and dampending modules in the feed to the Hbridge. Last is a safety and control module.

Thus, if you think of the blocks we have to build, it's not impossible and there is plenty of open source available. The question in my mind is can we get the speed we need out of cheap micros to even make this work. I say that because I have the FPGA based Geckos and to me, there is no way it can be built any other way. In other words, if you want a good servo, from the hardware point, it's FPGA or bust. This 200Hz loop rate claimed in the arducopter firmware (I haven't tested to see what it is) is no way fast enough for our intended usage in servos. We need 1KHz minimum and more than 10KHz is insanely better. I say this because otherwise if the loop rate isn't faster than human hearing, this thing will be louder and more expensive than steppers and then what's the point. Servos only become viable when they are more quiet than steppers or the whole position feedback is an absolute requirement rather than a desire. They cost more period just because of the requirement for an encoder. BTW cheap encoders are in every printer which I documented here : http://www.thingiverse.com/thing:6814

So what I can contribute today to the project is that you can get cheap encoders anywhere that interface to the Geckos. If we can come up with an open source driver that beats or matches the Gecko in performance while also being less cost, then that's saying something. To me, knowing what's been put into the commercial product from both a hardware and research, the fact that it works extremely well and is resonably priced, makes this a serious challenge.

Anyway, I have a test bed, different motors and supplies, different masses, and the reference standard geckos alone with the makerbot versions. If you guys want to hack the makerbot code, I can run side by side tests for everyone and make videos. If you come up with a good design I also have some PICs lying around and of course, H-bridges are no problem so we can go to town as far as testing goes.

Replies

Anders Wallin August 28, 2012 at 8:06am

Hi All,

Let me offer an EMC2/LinuxCNC perspective.

A common way of controlling a cnc machine with servos using linuxcnc is this:

- a "dumb" power-stage which essentially is just a powerFET or other current-switching circuitry drives the motor current. It takes PWM input. For a DC brushed servo this is just a singe H-bridge. For a 3-phase brushless motor or an induction motor this would be 3-phase H-bridge.

- an FPGA generates the PWM-signals, as well as reads the servo encoder signals. For a 3-phase motor the FPGA firmware does commutation also. The FPGA runs on a 50 or 100 MHz clock.

- LinuxCNC running on real-time linux closes the loop with a PID-controller. This loop usually runs every 1 ms. As argued previously in this thread the mechanical bandwidth of most cnc-machines is not very high, thus 1 ms is enough.

MESA-electronics makes some excellent FPGA-cards (PCI or PCIe I think) which have good support under linuxcnc. The firmware VHDL is open-source, and is compiled with Xilinx tools that Xilinx provides for free. MESA as well as pico-systems/Jon Elson also makes power-stages both for brush-DC and brushless.

I also agree with previous posters that making your own servo-controller is probably not going to be faster or cheaper than buying something ready-made.

My suggestion: stand on the shoulders of linuxcnc. get a MESA fpga-card, use the existing VHDL for encoder-counters and PWM generation. Start with an ultra-simple L297/298 power stage and a small motor with an encoder. Get familiar with modifying and compiling the VHDL. If you want the PID-loop to run on the fpga with step/dir inputs then work on that. If you want a stand-alone solution the get a stand-alone FPGA from MESA, or make your own fpga-board. If you want a high voltage/current powerstage then look at the IRAMS modules or similar.

cheers,
AndersW
Vernon Barry August 16, 2012 at 12:57pm

I have a little bit of experience here with servos. Basically, unless you want to get crazy on the control software side, most setups use a step based pulse system. Nothing wrong with that and of course it allows for cheap stepper drivers and motors. Some of the high end servos take velocity inputs via serial data connections and special protocols.

My suggestion is to get step/dir pulse based working, then you can always add in front end code to accept other formats.

Both Gecko Drive servo controllers and these makerbot ones below can use step and direction pulses:

http://wiki.makerbot.com/dc1

The problem here is that I was too in search of a DIY servo driver, based on step and dir pulse inputs, using common microcontrollers.

Here's what I know:

Messing with the open source Makerbot servo, the firmware is not in any way good to use at this time stock. Maybe someone can fix the magic bullet, but the system right now has horrible response in one direction. In other words, the comparator loop only works well (fast update) but in the reverse, a horrible lag. Knowing that using the Arduino IDE introduces lots of wasted cycles in the compiled code is at least somewhat to blame for the performance. I say this because some other designs based around PIC microcontrollers pretty much use assembly code to massively speed up the feedback comparator loop to a reasonable rate. Again, this is my limited understanding with a fair amount of hands on testing.

This forced me to just buy Gecko drivers which are reasonably priced. If you look at the gecko drives structure, they use FPGA which is insanely fast since it's hard coded logic that performs at near analog rates. By that, I mean update is so fast, the main comparator is running in the several kilohertz range as the drive is outside the range of my hearing. No hiss, no squeak, no buzz. I don't ever think you are going to get a microcontroller, even with assembly, as fast as FPGA.

Here are some videos:

Arduino based servo drive= very bad performance.

https://www.youtube.com/watch?v=lrpXtdeTUNg&feature=g-upl

Gecko based

https://www.youtube.com/watch?v=wBnbQrs6JsQ&feature=plcp

Stucture, no matter what is the same for all servos.

You basically have a comparator that takes a commanded position VS sensed position. It outputs to an H bridge. There is ususally a front end module to interface to quadrature or other encoder to get the sensed position, and then of course, there are gain and dampending modules in the feed to the Hbridge. Last is a safety and control module.

Thus, if you think of the blocks we have to build, it's not impossible and there is plenty of open source available. The question in my mind is can we get the speed we need out of cheap micros to even make this work. I say that because I have the FPGA based Geckos and to me, there is no way it can be built any other way. In other words, if you want a good servo, from the hardware point, it's FPGA or bust. This 200Hz loop rate claimed in the arducopter firmware (I haven't tested to see what it is) is no way fast enough for our intended usage in servos. We need 1KHz minimum and more than 10KHz is insanely better. I say this because otherwise if the loop rate isn't faster than human hearing, this thing will be louder and more expensive than steppers and then what's the point. Servos only become viable when they are more quiet than steppers or the whole position feedback is an absolute requirement rather than a desire. They cost more period just because of the requirement for an encoder. BTW cheap encoders are in every printer which I documented here : http://www.thingiverse.com/thing:6814

So what I can contribute today to the project is that you can get cheap encoders anywhere that interface to the Geckos. If we can come up with an open source driver that beats or matches the Gecko in performance while also being less cost, then that's saying something. To me, knowing what's been put into the commercial product from both a hardware and research, the fact that it works extremely well and is resonably priced, makes this a serious challenge.

Anyway, I have a test bed, different motors and supplies, different masses, and the reference standard geckos alone with the makerbot versions. If you guys want to hack the makerbot code, I can run side by side tests for everyone and make videos. If you come up with a good design I also have some PICs lying around and of course, H-bridges are no problem so we can go to town as far as testing goes.

This reply was deleted.

DIYDrones - CNC Project

Replies