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.

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.

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.