Let's Make Robots!

Great robot shield ideas gleaned from LMR members

I just felt like commenting on how much I have learned from others on Let's Make Robots. This was recently brought home to me when I decided to build a robot shield for the Hobbybotics Hobbyduino Mini. This is a custom bare-bones Arduino compatible board created by LMR member brooksware2000

I had a prototype of this board that I was given for evaluation. I'd always planned to add a shield to it, and finally I have. This blog is about how people on LMR share and learn. Since this board was designed and built by one of our members, with input from myself and other members, it seemed good place to start. 

To design my shield, I must admit I referenced some of the great designs done by Ro-bot-X. I've reviewed several of his designs, and I am always impressed at how well thought-out his boards are. He packs a lot of functionality in to a small space. In fact, his first Arduino robot shield benefited from input and comments from many LMR members. So once again, we see the collaboration and sharing. 

I used the popular sn754410 motor driver, just like Ro-Bot-X. I included a filtering cap for Vcc on the chip, again following Ro-bot-X's lead. I implemented a 3-pin servo-style layout for all the digital I/O pins, which is something Chris the Carpenter is especially fond of doing. In fact, he fairly insists this is the best and only way to do it. Who am I to argue?

The Hobbyduino Mini has a small 5V voltage regulator on board. I wanted to use a 7.2V battery pack. I also wanted to be able to keep the servos and motors powered separately from the 5V logic. Solution? I used a trick I learned from OddBot. By including two series diodes between the battery and the voltage I provide to the V+ pin of the 3-pin digital I/O interface, I drop the voltage from 7.2 to 6V. I route battery power directly from the 7.2V battery to the Vcc2 pin of the motor driver. So my motors get full battery voltage (minus the ~1.5V drop through the driver), and my servos don't blow up.

My own humble improvement is to include two shunt jumpers so that I can bypass one or both of the diodes in case I am running the board from a lower voltage source and don't want to cut the voltage by 1.2V (~ 0.6V per diode).

What else? Oh, yeah. Here's another goodie. Frits recently posted a preview of what is to be a new Start Here robot project. In this post he makes reference to buffered outputs. What is that? His new Instant Robot Shield includes two digital outputs that are buffered with a transistor to provide up to 500mA of current. Since a normal microprocessor can only source or sink a few tens of mA, this is great for driving how power devices like motors. So I included one of these outputs to drive a motor in my project. (It only needs to go in one direction, so no h-bridge was needed.)

I pretty happy, and proud of my little motor shield. I'm even more proud to be part of a community that has taught me so much. Thank you, LMR!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Perhaps a power switch my also be useful?

I now design my boards so that when powered by USB, you can upload the code but devices such as servos and motors remain unpowered. This can protect your bootloader from corrupting when these devices pull the USB power down to a low voltage.

I have also found with projects using the Spider controller that it can be useful to delay the power to the servos until after the processor has started and is ready to generate signals for the servos. Otherwise the servos can twitch uncontrollably when power is applied causing a voltage drop that resets the processor. The simplest way is with a timer made from a resistor and capacitor. once the capacitor has charged above a certain level then it turns on a trasistor or FET to apply power to the servos.

In this case, the board will be used on a robot with its own integrated power switch.

I really like the power options you described; I have wished for features like that on some of the boards I've used for the exact reasons you describe.

In this case, I needed a fairly simple board for a robot I'm building, but I decided to stretch and apply as many good ideas from LMR as I could. I think I will someday make my own custom board and have it fabricated, in which case I'll try to include even more greate features. Building this one on perfboard was limitinng.

You're welcome! I'm glad I had some input in your shield design.

I have to say how I got my desing ideas. Years ago I bought my first microcontroller board especially designed for robots and that was the first time I saw the 3 pin servo style connectors, that also had a jumper to be able to switch the power for a group of 4 pins so you could use either sensors (5V) or servos (Vin). That board was the OOPIC-R. I managed to blow up a few pins by reversing the servo connectors so that board lost about half of it's 16 I/O pins from the 3 pin headers banks (funny, I've done the same thing with one of my µBotino boards and no pins were damaged, I guess the AVR have some protection of sorts?). The OOPIC-R is still usable with what's left of it, but I don't have a use for it anymore. Perhaps someone else wants a free-be?

So, congratulations for your self made shield, Andrew!

Well done. I have to agree with Chris that the I/O's have to be on the board this way. Servos or sensors with 3-pin connectors are very common and every board with a 3-pin servo connector is just perfect. 

Also a good thing is the "power" output with the transistor to drive a motor (also good for driving relays).

Although CtC and mostly all of us think that the servo style 3 pin connectors should be standard for sensors too, many boards have the sensor 3 pins with power and ground reversed, just like the Sharp IR sensor. To prevent accidental insertion of the sensor connectors into servo headers, most manufacturers use a keyed connector for the sensors, similar with the JST connector, but with regular 0.1" pin spacing. Personally, I think that this creates confusion to beginners that don't know all the differences between these connectors, so a standard should be used. I still think it is easier and better to use the servo style, and to make it safer for the user, paint the headers that go to 5V Orange, the ones that go to Vin Red and the I/O headers White, while Gnd remains Black. This way, the user can see immediatelly where to plug a servo, just by looking at the cable colors. Too bad some servo manufacturers do not respect the Black/Red/White colors for their cables. I would use Yellow for 3.3V power and Blue/Green for comms (serial or I2C).