Tag: Atmel

REVOBOTS 5/6: The end of the REVOBots Story

Leave a comment

Students in REVOBots

For schematics and code, check out the revobots page here.  For video of the bot, look here.

Well folks, it is about time I wrapped up REVOBots, which turned out to be just as much work as expected; which is to say that it took more time and effort that I had planned.  And as expected, attendance dropped off towards the end of the semester as our project based classes go into full swing and spring (and the opportunity to lounge around outside) starts to warm up the weather.

REVOBots 5 ended up being an explanation about some code that I wrote, and an introduction to EagleCAD.  I have attached the code to the revobots 6 pdf because if fits in better there.

A student testing a ‘bot in the dark

REVOBots 6 was a build day dedicated to making the revobots go.  There were two critical failures on my part before revobots 6:

  • Did not spec out the motors/H-bridges properly.  The motors turn out to run at 3V, while the H bridges run at 5- ~30 V.
  • Did not order parts early enough

That said, the bots still work at 5 volts, albeit with a drastically shorter motor life.  But operating at 5V this seemed to cause too much of a current drain on the power supply, so we got some weird twitchy behavior during the class.  Since then I have developed a cheap fix using two 2n3906 NPN transistors, and a smattering of decoupling caps.

Top view of the ‘bot

What is a decoupling cap though?  Doesen’t the five dollar arduino already have them?

The answer to the second question is yes, but the cap was not big enough.  The problem the circuit was having was that the batteries were  trying to output a constant voltage.  This means that as current demands changed in the circuit, the battery had to adjust the output current.  With the microcontroller taking only a few miliamps, the circuit is not drawing much power.  BAM!  Motor turns on and what happens?  The battery needs to supply more current, but can’t.  Then the mcu shuts down as it looses power, sending a short pulse to the motor.  So bigger decoupling caps were needed to smooth out the power supply, which the caps do by charging up to 5V, and then discharging if the voltage drops due to sudden current demand.

So the symptoms were: mcu turning on and off, which I could tell because the status LED I had attached was flickering.

The prescribed cure was: Find all the capacitors on my floor, and stick them across the power rails.

Result:  REVOBot works!  Check it out here!  (In this video it is running away from light because I have the motors running in reverse).

REVOBOTS: Manny the Manual Line Following Robot

Leave a comment

Manny, the manually operated robot

So the other day I got bored and prototyped something which I quite liked for revobots.  It might be to people advantage to see it here before revobots meets again in two weeks, so I thought I would do a post.

One might wonder what a manual robot is.  Well, thats what I am calling this.  It doesn’t have any actuators, so you have to move it around with your hand, but if you follow the instructions it gives you (via the LEDs) it will follow a line!

The pseudoalgorithm for this is that each sensor has some threshold so that it reports a status back- either light or dark.  If the middle sensor is dark, and the outer sensors are light, then light no LEDs.  If any sensor is not on the proper darkness, a corresponding LED is lit.  So if the left sensor strays onto the line, and the other two are off the line, then the middle and left sensor LEDs turn on, indicating the need for a right turn.

Oh no! Hard to port!

Soon I will have this mounted on a revobot chassis with power, then I will post a video and documentation!

 

 

REVOBots Week 1: A Success, Overall

Leave a comment

Microcontrollers, Yo.

Links to videos and handouts for class:

Part 1, Part 2, Part 3

REVOBots handout 1

REVOBots week 1 was a success, in my opinion.  Teaching a class is tricky.  This first class was doubly so because it was my first time giving a long lecture, and because I had about 25 people to distribute tiny parts to, and then I had to walk them through manipulating these tiny, unfamiliar parts so that they worked.

The first mistake I made was not printing out the handouts ahead of time.  This was a big mistake- there were four color pages + a black and white feedback page, and for 25 people + extras, it took the xerox about 10 minutes to print them out.  This delayed me getting to class on time!

Lots of people=lots of prep

This of course, meant that I didn’t have time to parcel out the tiny components we were going to use to build the arduino.  This took up more class time, but it was not something I was willing to spend my own time on.  Since I am the one doing basically everything for the class (aside for actually paying for parts, which has been graciously funded by CORE, the Council of Olin REpresentatives), and that takes a lot of time, I try to minimize the amount of extra time I spend on it for just one person.  In other words, I try to optimize my bang-per-hour.  That means I have to stop myself from hunting people down and delivering their parts because they couldn’t make it, because that takes too much time (10 people x 10 minutes is an hour and 40 minutes!).

Once the handouts were out I started in on a very broad lecture about microcontrollers.  I tried to cover all the important aspects; brands, memory size, programming, and how PWM, ADC, and counters worked.  I intentionally went broader than the scope of what we were going to do in class because, I am basically throwing mud at the side of a barn and seeing what sticks.  I might as well throw a lot of mud, because people are not going to be able to devote a lot of time or effort to this class since it is once a week and not for credit; more mud means more will stick, which is the point of this class.

Now I know how the guy in the blue (one of our professors) feels sometimes!

After the talking at people was completed, I asked that people fill out the first half of the feedback sheet.  Then parts were passed out, the building of secret knowledge arduinos began!  I wish I had been able to prevent people from starting to build the circuit, but since some of them knew how to read the schematics (aided in large part by my guide), people began to build the circuit.  I tried to walk people through step by step, but I was often interrupted by people who needed help or by needing to supply tools to do part of the assembly.

This of course, fragmented everyones build process, much to my chagrin.  I saw everything wrong with the circuits over the next hour; D+ and D- switched, power shorted to ground, diodes in backwards, resistor in the wrong spot, chip in upside down…the works.  Many cries of “it gets really hot” were heard, and some magic smoke was released, although only two chips were damaged permanently.

Oh Windows 7, y u no work?

By the middle of the build session a few software problems had come up, particularly with windows users.  Linux users are advised to start the arduino IDE with sudo arduino, which works well and gives you USB privileges.  Windows users will need an installer designed by Kevin Mehall, which I will try to add to the downloads page.  It also turns out that the new version of the arduino software does not work very well, as in it couldn’t compile its own example code, so people had to revert to the old version.  Other than that, everything went well.  I tested everyones board before they left, to ensure that they were ready for the next class!

REVOBots: Getting Ready!

Leave a comment

Custom SMD Attiny45 USBISP programmer doing its job!

Last night a small package from monoprice, and a huge box from pololu arrived.  In it were the materials for the REVOBots class I am going to teach.  Since the first class is this weekend, I really needed to finish the guide/handout!  I spent all night building a Tamaiya gearbox (pictorial instructions soon!), re-building a $5 arduino, and eventually fixing an attiny45 based usbisp programmer.  The git repo for the bootloader of the $5 arduino is here.  It took about 6 hours to finally get everything working.  There were several stumbling blocks, like the gearbox having 3-4 configurations, and a dead ATMega chip.  But when I finally got the arduino IDE to talk to the chip, it was worth it- it was much easier to sleep knowing that the parts coming in from digikey would work.  Anyways, the first REVOBots guide is posted now, in the downloads section, or with this link.  REVOBots are coming!

REVOBot 001

Attiny45 based USBtinyISP Programmer

10 Comments

For a long time, I was looking for a solution to the size of my stk500.  Its big, fragile, and requires external power and a large USB to serial cable.  It seemed like the solution was one of these, a tiny (haha) programmer based around an attiny45/48.

Since I had the parts left over from The Secret Knowledge (more on this later) that would let me implement v-usb, and some attiny45 in my room, I decided to give it a shot.  Along the way there were a few roadblocks:

1. I didn’t read the instructions carefully enough, so I didn’t set the fuses properly the first time around.

2. Mysteriously, I couldn’t program the target chip if some of the outputs were set to high at the time of programming.  I resolved this with a .1uF capacitor across power and ground.

The rest of this post will be documentation on how to build the programmer, which hopefully will improve upon the instructions in the instructable.

Materials used (sources of parts at end of post):

  1. USB cable.  Any one will do, so long as it plugs into your computer on one end.  This is normally a USB A cable.
  2. Breadboard.  I made some PCBs for this but a breadboard is more accessible, and if they work I will post the files up on this blog.
  3. two 68 ohm resistors
  4. one 1.7K ohm resistor
  5. two 3.6 volt Zener diodes
  6. one .1uF capacitor
  7. one pre-programmed attiny45 in a DIP package OR an attiny45 and a way to program it
  8. .1″ pitch male header pins

The first thing you want to do is cut the USB cable in half, and extract the four wires that are inside.  There should be a red, black green, and white wire inside.  Red is 5 volts, black is ground, green is data+ (D+) and white is data- (D-).  strip the ends of these wires and solder them to the header pins, like in the picture below:

5 Volts and Ground are soldered to one pair of pins, while D+ and D- are soldered to another pair

The next step is to program the Attiny45/85.  I would just grab the .hex file from here, and flash it onto the attiny with whatever programmer you have.  If you are using AVR studio, just open a random project, connect to your programmer, and choose vusbtiny.hex as the file to burn to the chip.  Then, when you are SURE the correct program is written, set the fuses (click the fuses tab on the programming menu) and set the lower fuse to 0xe1 the higher fuse to 0x5d and the extended fuse to 0xff.  you can do this by directly editing the fuses in the menu by just clicking on the numbers the fuses are set to, and changing them.

If you are using avr dude, you want to use the command “sudo avrdude -c *your programmer here* -p t45 -U flash:w:usbtiny.hex” and when you are SURE it is written, you can burn the fuses with “avrdude -c usbtiny -p t45 -V -U lfuse:w:0xe1:m -U hfuse:w:0x5d:m -U efuse:w:0xff:m” (These commands are from the instructable)

You may notice that I emphasize making sure the program is correctly written BEFORE burning the fuses.  This is because you are going to burn the fuse that turns PB5 into an I/O pin instead of RST.  This makes it so that you have to use “high-voltage” (12V) programming to clear the fuses, and some programmers can’t do that.  If you burn the fuse before the program is correctly loaded, you cannot program it with ISP which which the majority of programmers use.  This is because ISP requires the RST pin.

Once you have all of that done, go ahead and build the circuit.  I have drawn up an improved circuit diagram (the one on instructables is awful) that includes a decoupling cap between power and ground.  This is really important because without it I tended to have problems programming chips when the target chips pins were high.  The hypothesis is that there was some sort of voltage surge, and the USB controller in my computer was turning off the device.

An improve schematic without over 9000 overlapping wires. Note the decoupling capacitor, and the orientation of the diodes. The band on the diodes is the same as the bar/z-shape on the schematic.

Once you are done, it should look something like this:

This is how my breadboard looked when I was done. Note the diodes and the orientation of the chip. Specifically pin one is on the upper right hand corner.

Then, take the whole thing and plug the USB A end into your computer.  You should hear a “Dun-Dah!” noise (in windows, linux users can use “lsusb” from the command line), and your computer might search for a driver.  You can get the driver here from ladyada.  If just downloading the driver doesn’t work (windows), plug in the device, go to start>control panel>hardware and sound>device manager and look for a device called something like “tinyusbisp”, and right-click install drivers and then manually search for drivers.  If you are on windows, you will need WinAVR to use this programmer, or if you are on Linux, just “sudo apt-get install avrdude”.

Now this whole thing should work…The easiest way to test is is to try flashing some random .hex onto another Attiny device.  You will need avrdude (included in winavr) to do this.  The command will look something like this “sudo avrdude -c usbtiny -p t45 -e -V -U flash:w:yourfilename.hex”.

Part Sources:

Digikey part numbers for the resistors: 985-1023-1-ND (68 ohm), PPC1.69KYTR-ND (1.69k ohm), 568-5907-1-ND (zener diode), ATTINY45-20PU-ND (attiny45), P4525-ND (.1 uf capacitor).

You can get a breadboard of your choosing (in size), and a USB cable from amazon.