SparkFun Forums

[andylippitt]

Over at http://OpenServo.com we are working on an open source hardware and software motor controller that can replace the existing boards in hobby servos. The primary goal is to turn a cheap servo into a sophisticated actuator for building robots. Anyone is welcome to participate!

[NleahciM]

Your all's work is very neat. One question: have you looked at trying to convert micro servos? I'm using Hitec HS-81MGs and would love to see a digital control for it. Problem is there is not much room inside the servo case for anything to elaborate.

[wiml]

Cool! I was thinking about doing exactly this a little while ago. Maybe I can pitch in.

[andylippitt]

we've kicked around the idea of different sized (including smaller) boards. So far we haven't had a major fork, but to support them we'd have to. We just move to the the ATMega168 for the onboard mcu and I seriously doubt that we'll squeeze that chip in a micro servo.

wiml, please do! We could use the help!

[Philba]

I looked at that project. Very nice work but I can't help but think going to the 168 was the wrong direction. A lot of wasted pins on that puppy and it's moderately pricey. Since you moved to it because you ran out of code space, I wonder how much effort was put into reducing the code size. 4K is a lot of code space in a micro.

[Kuroi Kenjin]

That's pretty cool! I took a look at the v1.1 schematic. I notice you're going the tranditional route with the pot sensor. One thing that always annoyed me about servos are the limit on the range of motion that is usually due to the range of the pot's motion. Have you ever given thought to replacing the pot with a quadrature encoder? Although it would be a little more work, it would give nice crisp readings and reduce part wear. I know on a PIC the interrupt-on-change would help with this, but I don't know if this is also on ATmegas. An encoder should be about the same size as a pot, or smaller if you find some way to rig it up on the shaft with the LEDs and phototransistors on the motor casing (?).

[SOI_Sentinel]

I've actually considered doing up a full DC motor control like this. My major differences were the choice of Microchip parts (QFN dsPIC, regulated buck/boost converter for the electronics, etc) and using CAN networking (compatibility with my other projects/ideas), and probably overly complex current sensing methods. I work with industrial motor and servo drives these days, so it's familiar territory.

I'll have to look into contributing later on.

As for the quadrature encoder, it's hard to say. I'll have to sit down and do a gear ratio count of the HS-422's I have. I was considering quadrature encoding on the motor with absolute feedback from the pot for one application. A better method for you would be to combine a motor mounted quadrature and a spline mounted absolute encoder of limited accuracy. If you (or anyone else) was considering putting the quadrature encoder on the output spline, you'd need a very small and very high count encoder wheel. That's rather expensive.

[Kuroi Kenjin]

Hmm I have notes on an idea like that... just collection of useful modules over CAN. CAN is very nice and (at least I think) a very easy multi master communication for high noise enviroments.

Yeah, the quadrature would only work if you had a good encoder or things are geared just right. Although GH7294-ND from Digikey would work with a bit of shaft modifications, at least on the larger servos, in place of the pot. It's 16 position, so a 2:1 (encoder to output rotation) ratio would make it work well. $5.15 per unit.... maybe a little pricey for this application.

[NleahciM]

OK a couple comments, after looking at the 1.1 and 2.0 schematics on your website. Understand that my interest is getting something like this for a micro servo, so my opinions will not be the same as everybody else's.

First of all - I think you're going in the wrong direction with v2.0. An atmega168 is complete overkill, imho. Are you honestly being limited by the 4KB of flash of a atmega48? I haven't looked at your code - but I can't possibly imagine needing that much code for such a simple application. Did you write it in c? Alot of the built in c functions use a ton of code. Like the scanf and printf functions are huge. Floating point stuff is also huge. Anyways, I think the attiny design makes alot more sense - atmega168s are big chips, they will be a serious limitation. Is code space your only reason for the 168?

I think having onboard voltage regulation is a terrible idea. Since you're running it through a 5v vreg you're making it impossible to use the standard 4 nicad battery pack to power the servo. I would highly advise just having a seperate line for the voltage supply. Would save you some space on the board, as well as some cost. Also - the servo supply line is going to be noisy, no matter what. You have a big cap on there to smooth that I see - but still, I just don't think it's worth it.

I like how you implemented high side current monitoring. I'm not familiar with the particular chip you used but it's quite possible with some other chips (Maxim makes an SOT-23-6 high side 100x current amplifier that I'm using) to use a smaller resistor.

Also - I do believe it's possible to fit your v 1.1 design into a micro servo. It might have to end up being two stacked circuit boards - I'm not sure. Maybe I'll play around with it when I have time.

Well, hope this doesn't sound too critical. I think your work is really cool.

[NleahciM]

I've actually considered doing up a full DC motor control like this. My major differences were the choice of Microchip parts (QFN dsPIC, regulated buck/boost converter for the electronics, etc) and using CAN networking (compatibility with my other projects/ideas), and probably overly complex current sensing methods. I work with industrial motor and servo drives these days, so it's familiar territory.

I'll have to look into contributing later on.

As for the quadrature encoder, it's hard to say. I'll have to sit down and do a gear ratio count of the HS-422's I have. I was considering quadrature encoding on the motor with absolute feedback from the pot for one application. A better method for you would be to combine a motor mounted quadrature and a spline mounted absolute encoder of limited accuracy. If you (or anyone else) was considering putting the quadrature encoder on the output spline, you'd need a very small and very high count encoder wheel. That's rather expensive.

if it were CAN it would be amazing. Problem with CAN is that all uCs with CAN are huge, in my experience. I think Microchip makes some that would fit in a full sized servo, but then when you add in the can transciever it's going to be taking up quite a bit of space compared to an attiny.

[Kuroi Kenjin]

Yeah, CAN enable microcontrollers are a bit on the large side. I know for PIC, althought TQFP and QFN packages are small... pin wise the PIC18F2480/2580/2585/2680 chips are only 28PIN (SOIC, QFN, PDIP) are pretty small, but probably not as small as that ATtiny on v1.1.

[NleahciM]

Yeah, CAN enable microcontrollers are a bit on the large side. I know for PIC, althought TQFP and QFN packages are small... pin wise the PIC18F2480/2580/2585/2680 chips are only 28PIN (SOIC, QFN, PDIP) are pretty small, but probably not as small as that ATtiny on v1.1.

A QFN-28 is nice and small - but not so fun to solder. But the big problem I see is that you'll still need a CAN transciever - and all the CAN transcievers I've seen have been 8-soics. Huge buggers to be sure.

[andylippitt]

We were hoping for some fresh blood and ideas. Please join us at the forums over there. http://openservo.com/forums We've got a small community of people working on it that would all be interested in these ideas.

[SOI_Sentinel]

the dsPIC's I'm looking at are FAR more overkill than any 8 bit AVR A PIC18 is also an option, but this was also going to be a core unit for a larger motor controller in the future. I'd probably also roll a model based on the PIC18F2480 (~$10 Digikey vs ~$15 for the dsPIC), depending on pin count requirements. If I do a lot of the code in C, it should be fairly portable between architectures (although reinforcing the need for my overkill in processor selection).

The motor control unit I was planning was a dsPIC30F4011, QFN package. I might be able to go to a 30F4012 (same package, a bit cheaper) since I may not need I2C anymore (duplexed with the CAN transciever on the 4012, separate on the 4011). Hardware H bridge PWM and hardware quadrature make a lot of the processing overhead bare. Which is nice, as I can then implement a bunch of additional modes I want to (constant torque, low jerk, synchronous feedrate, transparent multi-drive control, etc).

And yes, a CAN chip at 6x6mm of board space is large, with an 8x8 44QFN next to it (or a 6x6 28QFN). I still think it's possible, it'll just take some work.

[andylippitt]

In defence of the chip change, about 1K of our original 4K was taken up by an I2C bootloader. Most of the people working on are planning on using these en-masse in a robot. When I switch over, I'll have 18 in a hexapod. That's a lot of disassembly to do if we didn't have the bootloader. Everything is written in C and we considered rewriting bits like the bootloader in ASM to try to minimize the space. Aside from the pain involved in doing that, there's also the problem that we might make firmware development less accessible.

We were also out of I/O pins. We're looking at doing things like driving the p-ch side of the bridge to implement braking and there's been some talk of back emf measurement, though initial investigations seem to indicate this is non-trivial.

As for voltage regulation, I personally tend to agree about having it onboard. Fortunately, it's easy to leave it out and solder an extra lead on to supply a logic voltage from an external source.

These are my opinions, but I'm not the only one working on the thing, nor did I do the majority of the design. So again, please join us in the forums and jump into the debate or start a new fork of developement.