Here is a drawing of what the electrical layout will most likely resemble for RoboBrrd with it’s custom brain board.
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!
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.
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.
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.
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: SVG to PCB PCB+GL
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!
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. http://dimitridiakopoulos.com/hiduino
Here are some ideas of ways of communicating that I was exploring:
- Socket.io on remote server
Sleek, new way of interfacing
Games are in the browser
Hosting for node.js with socket.io…
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
Still need a fancy server to enable long running ajax processes
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!