REVOBOTS 5/6: The end of the REVOBots Story

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

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 4: Rebobot Factory

Robot Factory!

Videos: Part 1 Part 2

Guide: TSK4

Today AC113 was turned into an assembly line for pololus robot chassis kit.  The lecture today was about controlling big things with little things, with interrupts (which I thought was an important topic) thrown in in the context of encoders.  The turnout was a little below what it normally is, but still pretty good.  Word on the street is that the freshmen have a lot of stuff due this coming week, so there is a big crunch to get that done and therefore there are less REVONauts (as I call them).  Still, there was a good turnout.  Next time I would definitely teach the class in pairs of two to a robot, but one to an arduino.  I am afraid that there is going to be too much debugging of implementations of different robots/hardware that it will be hard to get to each student individually.  Working in teams raises the threshold for when people come to me, and it might actually increase the quality of the exercise for everyone so that people get more done.

Here are some shots of the assembly line:


Attendance was not too shabby

REVOBots Week 3: Halfway There

Another good turnout. Obviously, this is not a picture of everyone who attended…

Material for week 3:

Videos: Part 1 Part 2

Guide: TSK3

And by halfway there, I mean halfway done with REVOBOTS!  So far, we have built a $5 arduino clone, learned about several kinds of sensors, and finally, this week I (properly) showed them how to write code that runs on the clone.  I think it went well.  This class alleviated a lot of the previous frustrations people were having with the device as far as having hardware but not knowing how to use it.  By the end of class several people had actually managed to build a breakbeam sensor, which I thought was awesome.

Debug ALL the problems!

On the other hand, the actual devices that the students built are starting to show some wear and tear; often people have some trouble connecting them to their computer.  Often, the problem is that the USB cable had come unstuck from the header pins and needs to be resoldered, or the ground and power wires are touching (Which shuts off the USB port), or the usb cable came out of the breadboard and was plugged in backwards (D- and D+ swapped).  I think it might be worth my time in the future to cad up a board for these bootloaded atmega328s so that they are less likely to fall apart, or be put together wrong.

Inspiring student gets breakbeam sensor to work.

Despite the frustrations and the general roughness of the first pass at teaching revobots, I think it is worthwhile for both me and the students.  Hopefully I will teach this again soon, but better.

REVOBots Week 2: Gotta Switch up The (Teaching) Plan

This week we talked about sensors. The amount of light on the LDR changes the brightness of the LED

Class two videos: Part 1, Part 2, Part 3, Part 4

The Guide: TSK2

REVOBOts continues to be a fun class to teach.  We had another great turnout, considering that it is candidates weekend, which is always on of the buisiest times of the year.  I would say there were at least 20-25 people, which is about 2/3 of the class.

The topic this week was sensors.  Sensors are handy things, and we talked about resistive sensors (LDRs or photoresistors, thermistors), photodiodes, switches, and digital sensors.

My feedback was again mixed.  Some people enjoyed hearing about the broader material that we did not immediately use, and really liked seeing the datasheets, while some people thought it was too in depth or not valuable.  Next time I should definitely check out the datasheets before I pull them up; one of the sheets had all sorts of useful stuff on it, while the other one was lacking the very graph that I wanted to show everyone!

One area I need to improve on is retention.  I made an almost-joke last time that I am just throwing mud at a wall and seeing what sticks; this is becoming all too true, and the wall is starting to look more like a teflon pan in terms of stickiness.  It seems like people are getting a lot of information about the things they have, like these sensors or parts I am handing out, but they don’t know how to combine them.  I guess it is hard for me to anticipate some of these problems because I expect them to have some modicum of electronics knowledge, or sense from the required freshmen classes.  I guess Brian Storey and Brad Minch are having the same problems with I am, as far as balancing the “coolness” and “breadth” vs. teaching people electronics basics.  People also had a lot of questions about the “arduino language” that is used for programming these devices, and that is something I have not covered as much because as freshmen, they all have done quite a bit of matlab coding.  I see now that I should always provide code examples.

In this light I am going to tweak next weeks curriculum a little bit.  It was supposed to be in depth on different communication protocols, but instead I will only cover the usbsimple library, which is used instead of the serial library on the secret knowledge $5 arduino.  This is because the TSK arduino does not have an FTDI chip, and therefore has no serial output.  Instead, it uses VUSB to talk to the computer, and a python program on the other end to displat the data in the command line.  It might be nice to spice it up a little and have some kind of bar graph or canvas drawing instead of a command line thing, but that will depend on the free time I have between now and next saturday.

By concentrating on the USBsimple library, I will be able to also go through some of the more useful core arduino functions and libraries, like servo.h and map().  I will think of some examples, and then some in class exercises, and try to shrink my talking time to 45 min instead of an hour++ as it has been the last couple times.  To increase engagement and concentration integrity, I will have them work in groups and then present their project.  I don’t know if I will enforce pair programming but that is another way I might be able to increase concentration, because one person will be busy dictating and the other typing, which prevents either of them from checking their email or making memes.

REVOBots Week 1: A Success, Overall

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!

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

Secret Knowledge: REVObots

Recently, the leadershio of the REVO (Research on Electric Vehicles at Olin) club approached me and asked me to drop some secret knowledge on them.  While they have had some experience with EVs, they have no real EE background, and a very limited embedded/microcontroler background, and they wanted me to fix it.

Over the next few days I developed a 6-class course that would get their feet wet in the direction of building and understanding useful devices on an EV, or really any platform using a microcontroller, and even some that don’t (motor drivers and such).  I will be using the arduino platform for what it was intended; as a simple teaching platform.  The six classes are based around these learning goals:

  1. Explain what a mcu is, what it is good for, and what kind of hardware capabilities they have as far as PWM, ADC, timers and counters.  Explain what an arduino is, and build the secret knowledge arduino.
  2. Explain basic sensors that depend on resistance (thermistor, photoresistor) and current (photodiode) work.  Explain digital sensors, show an example with the 1-wire protocol.
  3. Explain various control schemes: on/off, proportional, differential, and integral.  Explain how to actually use them in hardware, using examples like the laser poejector.  Focus on quadrature encoding.
  4. Explain how to control big things like motors or AC current, with little things, like microcontrolers.  This will be all about BJT transistors, H-bridges, and relays.
  5. Explain how to talk to other devices via serial and USB.  This will be pretty theory-heavy, but we will have a USB example.
  6. Putting this all together, we will finish building a small robot and have it do some kind of task.

These six classes will be spread out over six weeks, and each will have both a lecture and a lab portion with a deliverable.  This is similar in structure to the other Secret Knowledge projects, but it differers in a few ways that will hopefully help deal with the problems of students not coming to classes, and students not retaining knowledge.

The difference here is that class is predictable.  Each week of TSK before was planned on the fly, materials were sourced from a withering stockroom, and everything had to be dirt cheap.  This made it hard to say what we would be doing from week to week.  The predictability makes it easy to know when to be where.  There is also a big carrot dangling at the end of six weeks when the students actually finish the robot; this will hopefully help eliminate the week-to-week variation of interest.

To help with the knowledge retrieval after the class is through, I will be putting together a guide ahead of time, with stuff people will learn each week.  Ideally, each deliverable will also be structured as a working example of the concepts covered in the class, and seeing everything work together will help cement the knowledge.  Most of the material will just be me throwing mud on a wall and hoping some sticks; the idea is that people will at least know where to start projects with mcus once this is all said and done.

I will be blogging more about this here as the class begins and things are done.  Classes will be recorded and posted on youtube.  In the Secret Knowledge tradition of flying-by-the-seat-of-ones-pants, and living on the gritty edge of barely being on time, right now I have a two week lead time before the class starts.  Better get going!

Secret Knowledge Time Vol III: Tiny Computer Time

The third week of secret knowledge we decided to move in the microcontroller-hat direction.  This means that we needed an easy to learn platform like an arduino, but we also needed a cheap to buy platform like a raw AVR chip.  Kevin came up with a solution:  a “five dollar” arduino (git here).  The five dollar arduino is a bootloaded AtMega328P.  This means that it is first programmed with the bootloader by a normal programmer (a AVR dragon, STK500, or usbtiny).  Then, it is put into the circuit below, and connected to a computer.  When the button is pressed it runs the bootloader code for 28 seconds, which allows the user enough time to press the upload button on the arduino IDE to upload code to the device.  After 28 seconds, the chip boots into the user code.

We expected a lot more to get done at this secret knowledge time.  We even wrote up some arduino tutorials to go with the hardware.  Unfortunately, we hit a few snags in actually getting all the devices built and programmable.  This may be due to our (lack) of structure; we mostly just give out a handout and parts and expect people to do things on their own while we stand by to help.  Unfortunately, there was a lot of confusion about what that was exactly.  We wanted to avoid sitting them all down and showing them how to do it piece by piece, because that tends to bore and frustrate people.  A good middle ground might be a video tutorial, but that takes a lot of effort to create.

The amount that people got done this session was varied.  There was one group who got most of, but not all of their arduinos working by the end of the session.  There was another group that successfully made and tested several cool tri-color LED display programs based on novel analog input devices, like potentiometers or CdS cells.

Without a doubt, this session was a huge success.  30 (+/-2) students showed up, and as many Arduinos as we could give out were given out and built.  Hopefully over the next few weeks we can develop some sort of path to teach people how to and when to use a microcontroller.

Secret Knowledge Time Vol II: Servos

For documentation on what the activity was, go here (link not active yet).

This Secret Knowledge Time was all about…what we did last week, but slightly different.  At this point, we hoped to gather everyone who wanted secret knowledge, catch people up on what we had done last week, and to stall for time to figure out how to introduce them to microcontrollers.

This week we made the same 555 circuit, but with a twist.  The output from the 555 was inverted and used to drive a servo (Note: the output had to be inverted because the minimum duty cycle of a 555 is 50%, and the duty cycle we needed was 10%.).  I found a few diagrams online, finagled the resistance values into something we could supply from the stockroom, and the built and tested the circuit.  It worked!

Again, errors are marked with red Xs.

However, our circuit diagram was flawed yet again.  Despite testing the circuit, we had not tested our diagram.  Fritzing drew several lines that we had deleted at some point, but did not technically connect them, because there was no large black dot indicating a connection.  This led to confusion in both myself and the people running the activity, and the people building the circuit.  This time the corrections and things that we had to yell out were:

  1. Corrections to the circuit diagram
  2. What the leads of the servo were (GND, V+, and Signal)
  3. What resistor went where
  4. How the pins on the transistor correlated to the pins on the schematic
  5. How to hook up the potentiometer

With all that resolved, most of the people got the circuit working in about two hours, played with it, and went home.  We got less feedback forms this time, indicating that we needed (and still need) to implement some new kind of feedback.

We had several improvements over the first SK this time.  We had acquired additional 5V power supplies.  We asked Sasha to help us again.  We improved the handout to include background information on what we were doing, and we even had a pretty good slightly better circuit diagram.  The problems we ran into were mostly in explaining the components, in which really is based on the problem of sexy vs. critical.

The sexy vs. critical problem is going to be another theme in TSK.  Some information or skills are sexy, cool, or desirable.  Things like reading brain waves, or blinking LEDs, or making a robot are sexy.  Things like understanding ohms law and how the oscillator in a 555 works are less sexy, but in some cases that knowledge can be critical to doing the cool thing.  The problem is that to get people to show up, you need to promise cool things in a short amount of time, but to achieve that, people will need to know a few critical and unsexy things.  This turns into a chicken and egg problem.

Our solution is just to throw the critical knowledge at them as they do cool stuff.  Sometimes this comes across as being unprepared, but it is almost easier to just do it on the fly as opposed to spending hours typing up detailed explanations of every component.  It also limits how “theory” we can be.  We do not want to be “too damn theory”, which is easy to have happen in a writeup that we are trying to make into a complete, definitive document on a part or subject.  It’s hard to tell where to stop; my best estimate is that a page or half a page is probably as much as anyone needs to know, and that is something that might be handy to have as a reference for TSK.

Overall, TSK Vol II: Servos was a success.  The feedback was mostly the same, but we did have a big question hanging over our heads at the end.  People kept asking:

What’s next?

We thought that was a pretty good question ourselves.