The stuff that I learnt is kind of in the air, so here’s a basic list.

- EMSL posted a tutorial on power dissipation! Pretty cool, especially since this is what I was wondering about for the voltage reg for RB’s servos [link]

- Tried to calculate type of zener diode and resistors would be necessary for brining the voltage down from 11.1V (or 7.4V) closer to 5V. [link] [link] [link]

- Ended up spending an extreme amount of time on this and not getting an answer that made sense. Either there was no zener diode in existence for what I wanted, or the resistor values would be unfeasibly small :l

- There are some great videos here [link]

- Scrapped the zener diode idea and going to go with a SMPS. Have to lay it out on a breadboard first. There was one time when I got it to work, and it was really cool- hardly any heat. But then for some reason it stopped working! Arrrg!

- Watched this EEVBlog video about the same SMPS. It gets a little frustrating when he keeps saying it’s so simple/easy/trivial to make it when I can’t get mine to WORK! [link]

- Tonight I learned from Chuckcrunch about a LM2596, which is also a SMPS. It is rated for 3A, and seems to be promising. It’s worth a shot to try it out since we’re not getting anywhere with the MC34063. [link]

Special thanks to Dago and Wilton for answering all of my questions previously. It helped a lot. I will come back with a more detailed post later with some changes to the board.

I visited Spikenzie Labs on Tuesday (and didn’t get a ticket on the train)! It was so cool, when I visited there the big Arduino box had arrived, and they let me open it! Sweeeet!

Here are some things that we discussed:

- Use a wall plug to go in to the main servo DC jack. With a jumper, you could select if you want to power off of battery (with the plug-in voltage regulator using headers) or not. This would be more safe for schools too.

- For laser cutting it is sometimes better to just design in Illustrator right away rather than import from Inventor. Sometimes there are points that appear from the transition from Inventor to Illustrator that make the laser move slower than it should (because it is jumping to points), and sometimes it just doesn’t work because there are too many points.

- Use the audio jack to get audio in as well, and have the RoboBrrd dance to the music.

I like the audio idea a lot, I never thought of that! It will be interesting to research how exactly to do that!

It’s pretty tiring to be working on RoboBrrd but not have any material progress. I’m really hoping that this LM2596 will be able to work out so that I can get some things done. @_@

More goals/stuff todo:
- Figure out the voltage regulator situation once and for all
- Place drill holes on RB board
- Update RB board with changes discussed above
- Check board

Definitely have to note here that learning more and more about this electrical stuff is quite difficult since I’m more used to software. Not entirely sure yet if it is because of the method of thinking about problems that is making this so difficult, or the fact that the content is much more difficult than software.

At least I’m learning stuff, but the pace is incredibly slow which is extremely frustrating since this was supposed to be done ages ago. GRRR! GET THINGS DONE!

As I was making it, I realized how easy it is to just be able to control actions on your Arduino. So I had RoboBrrd reacting to different shortcuts, so it could easily open/close its beak and flap its wings.

Since this app is more ‘action based’ rather than ‘pin based’, I find it more open ended to be used in different projects!

Here’s a quick video of the app:

I really really really enjoyed making this app. It made me realize how cool Matatino is. Really, I spent 4 hours on getting the hotkeys working, then I drop in Matatino and POOF it works! How cool is that?!

It’s on sale right now for $0.99 on the Mac App Store! The small amount of money goes towards RoboBrrd and funding more development.

…have you ever wondered what ‘funding more development’ really means? I have, and I’m pretty sure the universal commonality between this is buying more junk food to keep us programmers happy. It probably changes from dev to dev though

It’s been a fun week to see this progress come along. Here’s a timelapse of all the action:

This was the board at the point just before starting to fix everything up. I moved the analog lines to the screw terminals to between the proto area because since there is going to be PWM on the proto area, this would interfere with it. Thanks a bunch to dago for pointing this out!

Decided to change the headers to R3 format. It was supposed to be a small task, instead it ended up being this confusing mess that changed into a 40 minute issue. For some reason the pin numbers of the footprint and symbol just weren’t cooperating. Very frustrating:

This spot here will be filled in eventually. Can you guess what it would be for? You probably can, this is such a lame guessing game.

Here is the before shot of the de-zigging:

Here is the after shot of the de-zigging:

Now since I am a noob at all of this making hardware stuff, I have some questions. It would be really nice if people familiar in this area could lend some answers! I really appreciate everyone’s help and everything

(here are larger versions of this image)

1. Should there be a ground plane here? The ground route is actually quite short. If there was a fill, there would be many sides and edges, and wouldn’t be very big. Is there any advantage or disadvantage to this?

2. This is the 7805 for the servos, it’s going to be throwing off a lot of heat. Will this heat mess up any of the pads or the routes? What about the screw terminals and headers adjacent to it?

3. I use this V pattern to via together two of the wires. Is it better to use a V or a T? Why?

4. For joining the routes to these pads, it isn’t a straight line but rather one that angles in on both sides. Will this be okay, or is there not enough surface area on the route touching the pad?

5. Going horizontal are ALL of the power routes: Gnd, 5V (arduino) and 5V (servos). Going vertical are all of the digital inputs/outputs. These routes are on different sides. Will there be any effect on the digital inputs from the power? Why?

6. Will this work since there are going to be holes drilled in each of the pads? (Actually think I figured out this one, since the pads are conductive about their circumference, then it should work)

7. Do zigzags like these have a large effect on the signal from the pin? Is there any way to lessen the effect?

8. Is there any problem with having vertical and horizontal routes on different sides with different signals? Will there be noise? Also, is the spacing between the horizontal routes okay? It is 40 mil between the middle of the routes, and the routes are 15 mil.

9. Is this length of the ‘jump’ between this power route and this signal route okay? It is 70mil long, route is 15 mil. The power route is 20 mil. Just wondering if the length of this jump has any effect on the signal or anything.

10. Does having this power route come right through all the pin routes have any effect on the signal? It is on a different layer…

11. Do the routes close to the oscillator have any effect on the oscillator? Would this be bad?

12. Will these routes between the pins be okay, or will there be interference? The pads are 100 mil apart. The route is in the middle at 50 mil, and has a width of 15 mil. So the actual distance between the route and the pads is less than 10 mil. The distance between the digital and analog route is also less than 10 mil.

13. Do the 7805s for powering the Arduino generally get hot? Would it be better to have this laying down or standing up with a heatsink? Also if it is heating up, is it too close to the capacitors?

14. Are these jumps okay? The length is 80mil and they are going across a 25mil route.

15. Are these capacitors too close together? How close or far away should capacitors be?

16. Similar question to one previously, is it better to have a V or a T?

17. Are these vias big enough for the routes? I use the same size of via throughout the board on routes that are 15 mil, 20 mil, and 25 mil. The size of the via is:
Line width: 6 mil
Hole size: 11.81 mil
Ring size: 24.02 mil

18. What is the best way to go from one route size to another? For example here I’m going from 25 mil to 20 mil, but it leaves a weird sort of outline. Would this effect anything?

—

Thanks to anyone who answers any of these questions. You don’t have to answer any or all of them, but I do appreciate whatever answers there are because I’m still trying to wrap my head around this all I’ll also try to do my own researching for the answers too!

After editing some things based on the answers above, there are a few more things to do:
- mounting holes
- silkscreen labels
- silkscreen imagery (svg into gEDA), really looking forward to this
- change the arduino 5V pads in the proto area to squares to make it easier to understand
- use gerbv and stuff (have to research this more)
- get a few printed up at dorkbot pdx
- order parts for a few at local electronics store (ABRA)

I am kind of wondering how this attribution for the hardware will work. I used EMSL’s Diavolino a lot for reference, and the proto area on the side was obviously inspired by the Adafruit perma protos. Do I include a reference to these two things on the board, or can I do it on the schematic, pcb, and website files?

At least now that I have the dimensions of how big the board is, I can begin sketching out ideas for the shell. We are moving along, WOOHOO!

Also does anyone have any recommendation for testing equipment stuff? All I have right now is a multimeter, will that be adequate to debug this board when the time comes, or should I order something more complex, like perhaps a DSO nano or something? How do you test your boards?

For week 7 the goal is to get this board ordered, and to have some preliminary dimensional drawings done.

The funny part about this post is that you as a reader will think that the board is a long time from being finished, but as a writer I can clearly see how it is beginning to wrap up! Not because I traveled in time, but because after I finished on Sunday (the 15th), I began working more on the routing and improved so many things. I guess this is kind of funny timing for a week 5 progress post when week 6 began half of a week ago, AND the board looks totally different. It will be a good surprise for the end of week 6 then! ^_^

Here was a video I uploaded to YouTube of the routing timelapses of week 5 (good reason to subscribe to my robotgrrl91 youtube channel- you will be alerted of video uploads even when I don’t post them here )

So here is the board half way through this progress… that headphone jack took tons of time to create the footprint for! There are two versions, one with an accurate silkscreen for the dimensions, and one with a silkscreen that is a little pushed out. This part will be added to my github repo of parts eventually- I may have a few more parts to add by the end of week 6!

And here is the final screenshot of this progress.

The progress done in week 5 really set up for the good progress so far in week 6. I’m so excited to share more of the progress of week 6, but it isn’t even finished yet! I do drop some hints on twitter sometimes though

Also, the FIRST Robotics Competition build season has started again! I’m mentoring team #296 again this year, helping with the vision code. We are using LabView this year!

Not sure about your robots, but my robots love to dance along to Domo Arigoto by the Styx. They also enjoy watching movies like WALL-E! However there is a problem on planet EARTH that would hinder the innovation on the web by humans, and hinder robots from enjoying elements of the human culture.

The problem is that some humans have created two things… SOPA and PIPA. Could you imagine a Robot Party without Domo Arigoto? And if I posted a picture of WALL-E on here, there would be no more robotgrrl.com! It’s completely insane!

From the EFF:

The Internet blacklist legislation—known as PROTECT IP Act (PIPA) in the Senate and Stop Online Piracy Act (SOPA) in the House—invites Internet security risks, threatens online speech, and hampers innovation on the Web. Urge your members of Congress to reject this Internet blacklist campaign in both its forms!

From Google:

Millions of Americans oppose SOPA and PIPA because these bills would censor the Internet and slow economic growth in the U.S.
Two bills before Congress, known as the Protect IP Act (PIPA) in the Senate and the Stop Online Piracy Act (SOPA) in the House, would censor the Web and impose harmful regulations on American business. Millions of Internet users and entrepreneurs already oppose SOPA and PIPA.

The Senate will begin voting on January 24th. Please let them know how you feel. Sign this petition urging Congress to vote NO on PIPA and SOPA before it is too late.

From Wikipedia:

Imagine a World
Without Free Knowledge
For over a decade, we have spent millions of hours building the largest encyclopedia in human history. Right now, the U.S. Congress is considering legislation that could fatally damage the free and open Internet. For 24 hours, to raise awareness, we are blacking out Wikipedia.

As you can tell this is a very annoying issue that is taking time away from making our robots take over the world. If SOPA & PIPA were to come true, then it would further frustrate the robots more and they would revolt as is (with all their bugs). I can assure you that such a case would be very, very bad *sinister look*.

Here are three things you can do to avoid the SOPA & PIPA avalanche:
1. Sign the forms on Google & EFF, links above
2. Help spread the word about this in a creative way so that we can make sure that everyone is informed
3. KEEP YOUR ROBOTS CALM BY PLAYING DOMO ARIGOTO FOR THE NEXT 24 HOURS

(okay, maybe #3 is a little excessive)

Note: Yes we are hosted at GoDaddy BUT we are in the middle of figuring out how to switch. We don’t know anything about domains, DNS’, hosting, and whatever, so it is making it a very confusing process.

Apparently I didn’t save the file from week 2, so I had to redo a few things a bit. Here is a timelapse of the routing I did the other night.

Decided to go with the atmega vertically, because it is different and it fits better vertically than horizontally. The Minuino from Spikenzie Labs (given out at the Open Hardware Summit) does it this way, and they are able to make the layout very small. This is good, because the board will need as much room as possible to provide a large prototyping area.

The prototyping area looks like a breadboard (still needs to be routed and measured properly), it makes it easier to transfer ideas from the real breadboard onto the prototyping area. This is really similar/exactly the same as the perma-proto boards from Adafruit.

Still need to think about how stacking a prototype areas will work. Maybe I will just put more Arduino headers along there. Also thinking about more screw terminals along the side that could be jumpered into the breadboard. …and just realized that the screw terminals along the bottom edge of the board have to be moved to the other side. (and need to add more terminals for gnd, 5v)

Still have to add in the servo voltage regulator to the board (that’s the big empty space). It will be a 7805. Since it is standing up, I’ll probably have to shift the Arduino headers farther back. Hah, maybe there is space after all to make the atmega horizontal. Not sure what type of connector for the battery, probably a screw terminal and a jst header.

The trickiest part with making this board is being able to get the parts laid out in a good manner, while making the capacitors as close as possible, allowing for room between pads, making everything as compact as possible. It’s extremely annoying that with the ratsnest in gEDA that I couldn’t tell which net was for gnd. It would have been much faster if there was a magical way to do that.

Here is the gEDA Package of footprints, symbols, etc, that I’m starting on Github. Right now there are only 3 footprints of 3.5mm screw terminals, but hoping to add more as I go along.

It’s kind of disappointing that already we are running behind the schedule we wanted to be on. Not much I can do about that other than keep tanking along :/

Week 5 is beginning, so in the spirit of unprogress this week will be an ungoal: route the wires and do a good job of it- that’s it.

This is off of a whim, but one of the things that was always bugging me with the mini RoboBrrds was how tall their base should be. It should be as tall as an iPhone / Nexus S on its side. It makes perfect sense, and it will be pretty cool to create the laser cut front face panel for the base that can fit the iPhone’s screen and home button through it. Really excited about that part!

Over the next few days we will be slowly migrating the various links over from the old to the new site. As for the Sparkle auto-updating in the Mac Apps, they will point to the new appcast url with their next update.

Since it is a new site, there may be errors all over the place, so definitely feel free to point any out. We will be nailing out the errors throughout the weekend.

Also be sure to subscribe to the Apps For Arduino blog! There will be sneak peaks of upcoming apps, code tidbits, and news posted there.

If you like it, you can flattr it. (teehee).

Happy new year everyone!

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!

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

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!

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.

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:

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!

Arduinos
http://www.evilmadscientist.com/article.php/diavolino
http://jeffrey.co.in/projects/gnuduino/
https://github.com/jeffreyantony/GNUduino

Shields
http://lowvoltagelabs.com/2010/11/16/arduino-shield-board-outline-in-geda-format/
http://lowvoltagelabs.com/products/videooverlayshield/
http://wiki.evilmadscience.com/ISP_Shield

More
http://sites.google.com/site/artcfox/demystifying-the-tlc5940
http://wiki.evilmadscience.com/Bulbdial
http://wiki.evilmadscience.com/Larson_Scanner
http://wiki.evilmadscience.com/Meggy_Jr_RGB
http://wiki.evilmadscience.com/Octolively

Random
http://wiblocks.luciani.org/remix/index.html
http://www.gedasymbols.org/user/russell_dill/cec.html

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

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

Problems:
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

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

Problems:
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

Benefits:
Auto refresh
Openable API

Problems:
Still need a fancy server to enable long running ajax processes

- Processing game, RESTful API

Benefits:
It would work.

Problems:
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
WebRTC
getUserMedia
Device element discussion
Implementing device
WebRTC Group
LUFA
Node.js and Socket.io
Ajax periodic refresh
RESTful API with PHP and Apify
Node.js and WebSockets Demo
Nodejitsu
NodeSocket
Cure
Cloudnode
Webbynode
Nodester
Joyent
Heroku
nowjs

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!