Servo Controller Board

This board is [Eric Seifert’s] venture into working with AVR microcontrollers. He has worked with PIC microcontrollers in the past and used the goal of developing a servo controller board as his motivation to try the grass on the other side of the fence. He found he likes the AVR line for its ease of development under Linux, a feature we also appreciate. What he ended up with is a tiny board that controls up to eight servo motors. If you’ve got a project that is spilling over with servo-controlled limbs, maybe this will save you some development time.

17 thoughts on “Servo Controller Board

  1. I really need to learn surface mount. :(

    Old through-hole guy here.
    I’m told I won’t want to go back once I get into it.
    I just need to bite the bullet and get a kit or something.

    Really nice work. That looks like a wonderful piece to do some robotics with.

  2. Soldering surface mount parts is actually very easy, it just seems intimidating until you try it. You do want to have a decent iron for it though. Check out the sparkfun tutorials or watch youtube videos on how to do it.

  3. @strider_mt2k
    You really only need a solder station with decent tips, some tweezers, flux, solder, and a magnifier if your eyes are bad. It may look intimidating, but I can populate a surface mount board with X number of components at least twice as fast as I can populate a through-hole board with the same number of components.

    @eric
    I work with a group of software, hardware, and mechanical engineers. I don’t think a single one of them is a pro at the English language, and their handwriting is even worse. I think you may want to start hanging out in a literature forum or something xD

  4. @Jake

    This *is* a hacking blog, but since it is a writer’s job to, you know, write…we tend to expect that they do it correctly.

    I’m expected to do my job correctly, aren’t you? :)

  5. @andar_b
    Do you really expect hackaday to shell out for a perfectionist writer, or do you want to see as many awesome hacks a day as you can? I know what I want and if grunting could get the message across it would be good enough for me. We all know what it says, no need to be a grammar troll… why would anyone really even care. Another point, its kinda befitting, this isn’t finished-product-a-day, the writing should match, it’s part of the style, actually, that was probably part of his job description, make your writing look as hacked as possible, go count the errors in the NY Times, they’re supposed to be able to write, they even have an editors, but they still end up with errors on every printing, its all relative, this last sentence is just to make those grammar OCD feel uncomfortable.

  6. Nice work! I know first hand the difficulties associated with writing a servo controller, and would like to offer some help. I have spent 2 years developing/testing/ and implementing a communications protocol for small electronics devices. The Bowler Communications System (BCS) is a lightweight packetization system for forming asymmetric star topology communications systems. I am working in developing a company around our hardware that implements the system, but the more people we can get using the BCS, the better it will be for everyone. We have a full implementation in Java and all the protocol descriptions and packet descriptors for C/C++ (we haven’t released the C sources…yet). If you are interested in details, contact me at:

    kharrington@neuronrobotics.com

    Of you can take a look at the protocol and the implementations on our Wiki:

    http://neuronrobotics.com/wiki/Main_Page

  7. “I have noticed an issue that if the servos move to fast, it seems to be resetting the FT232RL”

    Sounds like you need a bigger decoupling capacitor. The capacitor for the motors is rather far away on the circuit board, too.

  8. The AVR tools available are a lot, lot better than the PIC ones. On Windows AVR Studio beats MPLab easily. Sure, it may seem to have a few fewer features but AVR Studio’s genius is that it doesn’t get in your way. It all just works and is easy to customise.

    MPLab doesn’t even have an easy way to organise the workspace windows due to it’s annoying interface.

    Also the GCC AVR target code is quite mature and well documented.

    The AVR line is also very consistent for the most part. Not only is porting easier but all the knowledge you gain working on one part is generally applicable to most of the others.

    Now, if only they would do DIP versions of the USB AVRs…

  9. Back in the day I used to etch my own pcbs to make projects like this. Now my full time job is routing them using Altium and having them manufactured elsewhere. If you have a project in mind that uses difficult parts like BGAs or MLF that is not possible to etch then give me a shout and I can help you out.

  10. Using a software way to generate the pulse does not give a good resolution for the pulse width. This resolution should be better than 2us, and servicing the interrupt is quite long because it save and restore the 32 registers.

  11. Eric,

    Tough love time here. I suggest you learn to stop using magic numbers and start adding some useful comments to your code.

    For example, In your “init_all” function, you init Timer 1 using a bunch of constants that mean… what? Wat is the significance of OR’ing TIMSK1 with the value 0x02? If you had either defined a value (such as TIMER_PRESCALE_64, or whatever the magic number 0x02 represents) or even put in a comment, the code would be readable. Right now, it’s something that requires reading a datasheet to even understand the concept.

    State machines are a good idea, but you don’t want to implement them by simply incrementing a state value. You want to have constants defined and set each state with a constant. Tell me which line below lets the reader understand what the code is doing better:

    command_state++;

    or

    command_state = CMD_STATE_SET_SERVO_HIGH_BYTE

    However, your use of a state machine is suspect here anyway. Why is this not simply inline code? Why loop around and have a state machine if all you are doing is performing some simple, linear sequence of operations. It appears your function could be re-written like this:

    void command_set_servo(){
    uchar servo_number = 0;
    uchar uc_val[2];

    //Server number (1-8)
    if((UCSR0A & (1< 8 || servo_number < 1)
    return;

    //Servo value high byte
    if((UCSR0A & (1<<RXC0))) {
    uc_val[1] = UDR0;
    }

    //Servo value low byte
    if((UCSR0A & (1< pwm_set.pwm_max || ui_val < pwm_set.pwm_min)
    return;
    }

    //Execute byte
    if((UCSR0A & (1<<RXC0))) {
    if(UDR0 == 0xA5) {
    servos[servo_number-1].duty = ui_val;
    }
    }
    }

    It's shorter. It's faster because you're not de-referencing variables in your union and looping. It's much easier to understand as it simply does the work sequentially. Finally, it does the exact same thing your original function does without getting bogged down in a state machine that adds nothing to functionality, but does increase complexity.

    Also, variable names like "x" and "ui_val" (for "unsigned int value") are weak. If the name of your variable is just the variable type expressed slightly differently, then you need to understand what variable names are for. They are there to provide shorthand information about what the variable is used for, not what type it is. Also, naming a menu string "men"? What are you possibly gaining by dropping a single letter other than decreasing readability and comprehension?

    You're looking to get hired with your brand new degree, right? I recommend learning professional habits for code writing. Always write your code as if you're going to get hit by a truck tomorrow and someone else will have to pick it up and work with it.

    Yeah, I know, it's just a quick project. It's a test. It's not finished. I know. These are all excuses. If you don't develop good coding habits from the start, you never develop them.

  12. @Alfred

    Where did he imply that he was a software engineer? I have stated in the past that most of the software engineers I’ve worked with were oblivious dicks who had all sorts of opinions on their software, but ultimately refused to properly understand the hardware they were writing code for. I suspect that you are one of those dicks!

Leave a Reply to ericCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.