If any of the info on this website was useful for your projects or made your head spin with creative ideas, and you would like to share a token of your appreciation- a donation would be massively appreciated!

Your donation will go to my Robotics Fund, straight towards more sensors, actuators, books, and journeys. It takes a lot to continue building these robots, and I’m really thankful of everyone who helps encourage me along the way.



“A wise robot once said to me through Serial.println- that robots teach us about ourselves.”

Archive for December, 2011

Brrd Base Electrical Layout

Here is a drawing of what the electrical layout will most likely resemble for RoboBrrd with it’s custom brain board.

Brrd Electrical Layout

The voltage input for the servos will be located around the same area that the usb and dc jack are for the Arduino. I plan to make it noticeable with a silkscreen which input is for what. Also, there could be a shorting block for using an optional voltage regulator that could be plugged in via headers.

The servo headers would be located in the prototyping area nearest to the Arduino area. Hopefully the distance from the filtered voltage to the headers won’t effect anything too much.

There will be a lot of room for the wires going to the screw terminals, and you will also be able to mount a shield on the Arduino part. The prototyping area is a little smaller, but perhaps there could be a way to stack the prototyping areas if more room was necessary.

The brain will be able to be removed from the base because it will be a sliding drawer. Still haven’t worked out the thoughts as to how it will remain aligned, but an idea like this was explored with the Learning Pet version of RoboBrrd.

This clears up some of the fog I had last post about how the voltage regulator is going to be able to reach the battery. The battery is one of those details in robotics that can be often overlooked, this sometimes happens with FIRST teams that forget to plan for the battery, then end up placing it randomly … only to have it flying around in the middle of a match. Yikes! Hopefully this planning will assist the CAD’ing of the brain board!

RoboBrrd + gEDA Brain Progress

Happy holidays everyone! Last week I worked on the schematic and board for RoboBrrd’s brain. There was also great research done about how to go about the interactive games for RoboBrrd.

Here is are some timelapse clips of this week in gEDA for RoboBrrd:

Watch on YouTube

I based the schematic off of the Diavolino and GNUduino arduino clones, because they are in gEDA too. Learning gEDA gets better with the more practice you have!

Screen Shot 2011-12-22 at 12.28.48 AM

The atmega328 symbol is from Matt Padina‘s TLC5940 knowledge base. It is so nice how it is organized and how the pins are labeled with everything!

The funny part about this schematic now is that I can see many small things that I dislike. For example, the amount of small capacitors. Are they really necessary on some of the power pins? I’m going to poke around at some of the other arduino clones to see how theirs is designed too. It’s kind of interesting, because there’s a boarduino on my desk beside me as I am typing it, and I just noticed it has an orange gumdrop-like component instead of a silver clock. I’ll research more into how that works!

One of the nice things about gEDA is that you can have multiple sheets! I use the input symbol with a custom netname to be able to ‘connect’ the pins from the first sheet to the second sheet. Here are the servo headers, on their own lonely sheet.

Screen Shot 2011-12-22 at 12.34.07 AM

For creating the pcb, in gschm2pcb I was stuck for DAYS on this issue with the footprints. I just couldn’t work it out. For some reason on both the Diavolino and the GNUduino, the headers use a standard footprint that I couldn’t find in my library.

Screen Shot 2011-12-24 at 1.33.01 AM

Finally, tonight I figured out a way to get the footprints! The ones on the Diavolino are nice, so to grab the footprint from the board and put it into a file, you can just do:

Edit > Copy selection to buffer (Ctrl-C)
Buffer > Save buffer elements to file
Save as a .fp > Done!

Since I was editing the schematic and the pcb had to be updated often, I found that the best way to go about this was to always remove the old .new.pcb file. If you don’t, I’ve had it happen where all of the parts get scrambled up.

This is what the board looks like right now.

Screen Shot 2011-12-27 at 11.10.54 PM

I’m not sure about the height of the board (the distance between the rows of headers). I need to figure out how to measure things in gEDA, that would be really handy.

The green rectangles are the screw terminals. They will only be on one side, because the board is going to be in the base on the right. In Impy RoboBrrd right now, it is really difficult to access the left side of the screw terminals because they are below the top face of the base. Plus, some of the wires stick out the side, which isn’t very good. Not to mention that the wires had to be longer, because it is longer to get to the other side of the board. And, they get tangled. Blech! As long as the board will be less than 12cm or so, it should be fine.

There is a large prototyping area on the board. It will be like a breadboard, hopefully this will help students! Also there is a mistake right now, the holes are vias when they should be pads. Have to fix that.

The blue rectangle will be an area to access all of the pins again. It will be handy. The brown rectangles will be some more pads that can be soldered to. The aqua rectangle is where the voltage regulator will eventually be able to plug in!

One of the things that I hope I’ll be able to do is silkscreen both sides of the board, because it will make it easier to see what pins are what when flipped over. I think the Arduino MEGA Protoshield does this, and it is extremely handy.

I’m not sure if I enjoy the placement of the voltage regulator near the back. This means that it would be at the front of the RoboBrrd, making the battery difficult to plug in. I have to think about this more, maybe it will be moved up to the front of the board, before the prototyping area.

Some cool things that I discovered this week that will be fun to play with in gEDA are:

That wraps up week 2. The goal for this week mirrors that of last week, but to complete the progress that was started. FINISH THE BRAIN!

If anyone out there is trying to use gEDA to make Arduino related things, here are some of the resources that I found to be particularly helpful! And of course what better time to learn gEDA than now… there is even a gEDA badge!





RoboBrrd’s Interactive Games Interfacing

One of the things that has been bugging me about RoboBrrd the past two days is wondering how it will interact with the software games. When planning this, I was thinking of making the games in Processing (Java). However, Java is getting old, and with new technologies on the rise, like websockets, I wanted to research this more.

You may be wondering, why are the interactive games so important for RoboBrrd anyway? If you are just trying to create an educational robot, who needs the games and software? We want to create a blended reality between the real RoboBrrd and the virtual RoboBrrd for the student, so that it is always accessible and available to the student to learn, hence the prior nickname ‘Learning Pet’. RoboBrrd is more than a robot, it’s a way to actively interact with virtual based learning applications.

One of the cool ideas that is arising in the hardware-software interface realm is driverless and middlewareless communication. The HIDUINO is a really cool implementation of this. Check out the website and the video for more information.

Here are some ideas of ways of communicating that I was exploring:

– on remote server

Sleek, new way of interfacing
Active community
Games are in the browser
Real time

Hosting for node.js with…
Would have to run some sort of middleware to communicate between the socket and the Arduino.

– RoboBrrd as a keyboard HID

Easy way to interact with a game on a server
No middleware needed

Only one way communication

– RoboBrrd as an audio or video HID

When researching this I found some ways of communicating to a usb webcam, but it is only for video streams mainly.

– RESTful API with AJAX auto-reload

Auto refresh
Openable API

Still need a fancy server to enable long running ajax processes

– Processing game, RESTful API

It would work.

It’s ancient.

Here are interesting links that were explored while researching:
physical-js JavaScript-based physical computing
Circuits@Home lots of USB Host & HID information here
Garmin communicator did some interesting this with communication
Mozilla Audio Data API
jasmid MIDI synthesis
Device element discussion
Implementing device
WebRTC Group
Node.js and
Ajax periodic refresh
RESTful API with PHP and Apify
Node.js and WebSockets Demo

As you can see, the implementation that would most likely work would be the Processing game with a RESTful API back to the server for storing data. So yes, I did pretty much just go around in a complete circle, but I think that learning about more ways to communicate between software and hardware is really interesting.

So, happy holidays everyone- and there will be a week 2 progress update post later this evening!