Archive | March, 2012

Using your Arduino as an ISP

26 Mar

Using your Arduino as an ISP

ISP is short for In-System Programmer and is one of several ways to turn a blank Atmel chip into an Arduino. The basic chip is just a microcontroller, but with the right bootloader, you can load your Arduino-based programs onto it. It all seems so easy, doesn't it? You just buy this shield from Adafruit and follow the tutorial.

That would be much too easy! The Adafruit shield probably works, but since there's no real listing of what hardware it's actually compatible/tested with it's sort of useless. By browsing the forums I realized that while it can be used to BURN an UNO, it can't be used with an UNO. I have a Duemilanove 328 but the didn't work either. I gave up on the shield and I also tried this the official ArduinoISP tutorial to no vain.

Today I tried this tutorial and it's very much the same, but explains an option to not use a crystal. I had a bunch of problems that I eventually solved, so am posting the results for others to find. 

To use the Minimal Circuit setup (without the crystal/capacitors) you'll try to follow the instructions listed only to get the first problem.

Problem:
"pins_arduino.h: No such file or directory"

Solution:
Copy the contents from the downloaded boards.txt in your src/hardware folder to the boards.txt in App folder instead. On OSX: right click the Arduino app and browse Contents/Resources/Java/hardware/arduino/boards.txt.

You may also need to add the line below after the other text you pasted as it's missing in the downloadable example file:
atmega328bb.build.variant=standard

After this, the ArduinoISP example compiled fine and uploaded to the Duemilanove board that I'm using for burning the bootloader. The next problem I bumped into was that when I selected Tools -> Burn Bootloader, avrdude couldn't communicate with my board.

Problem:
stk500_getsync(): not in sync: resp=0x00
You can also get other hex numbers like resp=0x15 and resp=0xf0

Solution:
Add either a 120 Ohm resistor (didn't work for me) or a 10uF Capacitor (worked like a charm) between the Reset and 5V Pin:
http://www.arduino.cc/playground/Main/DisablingAutoResetOnSerialConnection

I had to fiddle a bit to get this right and once it worked I ran straight into the next problem...

Problem:
Avrdude dislikes your lovely 328-PU chips and says "avrdude: Yikes!  Invalid device signature." or "avrdude: Expected signature for ATMEGA328P is 1E 95 0F"

Solution:
Unfortunately the 328-pu and 328p-pu are not the the same. They're very similar though so all you need to do is to tweak a setting in your avrdude.conf file as described here.

Also remember to set this back and then restart the Arduino IDE, or you'll get the error "avrdude: Expected signature for ATMEGA328P is 1E 95 14" the next time you try to upload. Below is the final setup where I added capacitors and crystal as well (click to view the full size version on Flickr)

Take 2

So while I had this working nicely, it all of a sudden stopped working on my MacBook Pro. Really? yeah! First I got a bunch of "avrdude: Yikes!  Invalid device signature" and later the dreaded "avrdude: stk500_recv(): programmer is not responding". I have absolutely no idea why it stopped working.

What to do... I had come this far and I had 10 chips that needed a bootloader. I had read somewhere that the power supplied via USB varies and that to burn a chip you're using more juice than normally. I downloaded the Arduino IDE on my gaming PC and plugged the same setup in there and lo and behold - it worked? I tried again and it failed. I then removed the 10uF capacitor that was temporarily inserted between Reset and 5V and now it was burning chips with no problems again. It would work like a charm until I turned off the power to the Arduino. To get it working again I just added the capacitor back in for the first burn cycle and then removed it again.

Is it really as easy as adding a little more USB-power? The MacBook Pro USB ports are spec'ed to deliver to the normal 500mA but maybe they don't? My gaming PC has a massive 1100watt PSU so it definitely has enough. I really don't know, but if you get this issue, try using a different machine as well. It did wonders for me and the burnt chips work as intended when programmed with the FTDI Friend!

Makerbotting

24 Mar

Makerbotting

When people ask me what I do these days I tell them that I still make games and apps, but that I play around with microcontrollers and 3D printing. Most people don't really know what 3D printing involves, but I usually have something in my backpack that I've printed. As soon as they get it they say "Ohhh I want one!". But do they really want it?

Lately I've spent quite a bit of time with the Makerbot Thing-o-matic (TOM) that VariousArchitects has in a back room of our office. It's been so much fun and so much to learn that I've spent most of my free time modeling, printing and testing various designs for my LED Cube project. What I've learned up until now is that Makerbots and 3D printers in general require quite a bit of fiddling to keep them in working order. It's a lot of moving parts that are held together with screws and bolts that constantly move. These come loose and the faster your printer moves, the more chance that things will come loose.

The thing that has caused me the most trouble on the TOM is that my models did not stick the the heated build surface (heated build platform or HBP for short). The model would stick for a couple layers and then one of the corners in the model would loose grip of the platform. The model would bend more and more and in the end it would bend so much that the print head knocked it off. I tried a coulple of the basic tricks like changing the Kapton foil on the build surface but it didn't help much.

My friend Jim at Various was the one that bought the TOM and he suggested that while I was working on the problem, I'd also upgrade and recalibrate it. Sure I thought. How hard could that be? With all my current Arduino experience, the upgrade itself was super easy. Getting the hardware to play nice was harder. After a lot of fiddling, I got everything to work tonight. Yep! I'm in my office in Oslo now at 23 hrs on a Saturday, printing and calibrating. That's how much fun a 3D printer is! Anyway - here's the list of things I did to get the 3mm white ABS filament to play nice:

  • The firmware was updated to the latest version for both extruder and main board (an Arduino Mega 2560)
  • The HBP was dismounted, every single screw beneath it was tightened and the platform was levelled completely
  • I went over every connection inside the bot and sure - the power to the extruder had come loose. It's way to short, so you'll pull it out unless careful
  • I also raised the HBP temperature from the recommended 110 to 115 degrees. This makes the builds stick MUCH better.
  • ReplicatorG was updated to latest (034) but I'm still using skeinforge 35. For some reason, start.gcode isn't included from the default position so I have to set the HBP temperature directly in the generated gcode. Haven't found a description of this being a bug, so I'll just keep looking tomorrow I guess.
  • I failed a lot when it came to the calibration because I didn't properly read the dialogue shown after calibrating: always regenerate your models (both gCode + s3g) completely after recalibrating.

Due to that last one, I had to change the Kapton foil quite a few times after the print head crashing into the platform after a little printing. Think I've spent almost two full workdays fiddling with this now but I finally got a successful print completed now, so time to head home...

But - this is so incredibly fun! So much fun in fact that after some careful consideration I ordered a Ultimaker last week! As opposed ot the Makerbot, this one moves the printer head and not the platform. This solves what I think is the biggest problem with the Makerbot design - if you print too fast, your model will simply fall off the platform. With the Ultimaker this is much less of an issue, just check this video out! That's not the "out-of-the-box" speed though and it comes as a kit.

But when will I get it? Not until 4-6 weeks :(

Making a good cube

19 Mar

Making a good cube

It's fascinating how hard it is to make a good cube. It's such a simple task, but as soon as you introduce features it all gets more complicated:

  • Easy to open and close for changing batteries
  • Walls must have an even distribution of material so light from inside shines uniformly

For every iteration there is a process consisting of modeling in Rhino, generating toolpath with ReplicatorG, checking toolpath with Pleaseant3D, export a .s3g file from ReplicatorG, move to memory card and put into Jim's Makerbot Thing-o-matic, sit by the Makerbot while it's printing the first few layers, drop by to check that the printing goes well and then take the final product out of the machine. So - it takes a bit of time with each iteration but hey! I can think of something and have a working prototype in plastic less than 2 days later? That's just rad!

Here's a rundown of my experiences designing the cube and outputting it on a Makerbot Thing-o-matic. It's harder than it sounds and if you want to check out any of the images in very high resolution, check my flickr account.

Cube 1

I had been thinking a lot about how to make the first cube and everything worked like a charm! This cube only had one problem - the 5mm walls made the light really dim and that won't do. This cube is on Thingiverse as it really works. It's super solid and you could probably drive a huge truck over it without damaging the contents. You can see it in the pic above, or here to see it blinking away.

Cube 2

This was pretty much a complete failure. High on the success of the first cube, I didn't really think through the design of this one. The result was that the locking mechanism worked alright, but the lid could slide off sideways.... Bummer. However - this model showed that you could make really nice looking cubes with just 1.2mm walls. This is only two strands of plastic on the Makerbot and it'll actually print nicely, no matter the height of the object.

Cube 3

The biggest failure yet. It practically fell apart when I took it out of the printer... This cube used twice the thickness of the previous version (4 shells). I couldn't really see it when inspecting the model in Pleasant3D, but the outer two shells didn't connect to the inner two? I now inspect the toolpath much more carefully, but this really isn't an exact science.

Cube 4

In the previous version I had solved the lid nicely, but I didn't really like the look of it. It looked clumsy. I started thinking about how I would make such a cube from Plexiglass and it dawned on me - what if the lid has an inner square that fits into the main cube? That'll add rigidity as well as make the lid "snap" in place. I also started to get annoyed with the "slits" in the lid that this design required for opening. What if I ignored the slits and rather made the lid sort of "loose" so you could just rip it open without any tools?

The only thing that failed for me with this cube is that the things that hold the cube closed (the snaps?) are visible when you apply light inside the cube. Unless you do this, it can serve as a nice, little storage container so it's on Thingiverse for others to download.

Cube 5

This is the version I'm working on now, but I had some issues with the Makerbot. Will have to solve that, but the lid came out well and as you can see, I've sized up the design to 7x7 centimeters so I can fit batteries in the lid.

The initial idea was to use coin cell batteries, but there's actually three reasons for going with AAA batteries instead:

  • Battery life is much better
  • It's easier to get hold of and replace standard AAA batteries
  • I actually couldn't fit the required components onto the space available in a 5x5 cm cube...

The batteries slot in nicely and are held in place, but the holes/slits for the metal bits that'll be at the ends of the batteries didn't come out as intended. I know how to fix them though, so when I have some time I'll redesign that and print a new lid. Below you can see the sample fitting of the components for the 5x5 cube. It's tight so a little extra room will help.

Also used this post as a way to test my new light-box-thingie for taking high quality shots with diffuse lighting. Will use this for the upcoming hardware reference in my Arduino Companion app.

Away3D 4 Basics

12 Mar

Away3D 4 Basics

Finally taking the time to update the tutorials over at Flashmagazine to cover the Away3D 4 Beta that was released a few weeks ago. It's more than 40 code examples mixed into the 12 tutorials so it'll take some time to get through it all. It's mighty fun though and I'm really happy with the speed I'm seeing on both desktop and devices!

I've had a couple requests recently for how to do just a very basic 3D scene using Away3D v4, so here it is in case others need it too. It's just a cube that you can spin with either the mouse or keyboard, but it shows off quite a few of the differences in how to do things in v4. Materials, meshes, lights - there's differences for many core things. I'll summarize all these changes as I go through the code examples.

RGB LED - Common Cathode or Common Anode?

05 Mar

RGB LED - Common Cathode or Common Anode?

One of this things I initially found odd about electronics is how it's not really about the 5V plus and ground, but rather the difference between plus/minus. Some components like diodes and electrolytic capacitors will only allow power to flow one way, so direction matters when you're ordering your RGB LEDs. For my cube project, I've gotten some nice, diffused 10mm RGB LEDs but I didn't really pay attention when I ordered them, so when I started playing around tonight I was fumbling with what to apply to wich LED leg. So for future reference - here's the rule:

  • A RGB Common Anode LED should have it's longest leg (leg 2) connected to the 5V pin on your Arduino (Current sink)
  • A RGB Common Cathode LED should have it's longest leg (leg 2) connected to the ground pin on your Arduino (Current source)

In both cases, you'll connect the R, G and B legs of the LED to IO pins on your Arduino through some suitable resistor (200-330 Ohm) to not burn out the LED. So when should you get what version? Your Arduino can drive a couple of RGB LEDs, but you only have 7 PWM channels and you can't draw more than 40mA from each of these. If you want to drive more LEDs using for example shiftout, you'll need custom driver chips like the TPIC6B595N (that I've used before). This chip can only SINK power, so you should use it with Common Anode LEDs. In other words, a little research may be required.

Most of the tutorials you'll find out there are for Common Cathode RGB LEDs, but I eventually found one showing the Common Anode setup as well.