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.

This is a reflection and analysis of how the first Secret Knowledge went.  If you want the (polished) version of our actual activity, go here (link not active yet).

A few weeks ago, an email went out to the entire freshmen class of Olin College, aka “Students-Class of 2015”.  The email was an invitation to learn “all the Secret Knowledge that they required”, if they would only come to the fourth floor (our secret lair) at 7:00 PM on a Friday.  I expected maybe 10 people to show up.  Neal and Kevin were less optimistic.  In the end, we decided to print five copies of the handout we had prepared, and gathered up enough parts for five people.  When 30 or so people showed up, we were both shocked and unprepared.  Who knew that people wanted secret knowledge?

The first Secret Knowledge activity was based around a 555 timer.  The goals of the activity were:

1. Do something cool, and novel
2. Learn to do something

We achieved both goals, but not entirely successfully.  The cool thing that we did was blink an LED.  We did this by setting the 555 timer up as an astable multivibrator, or in layman’s terms an oscillator.  The 555 directly powered an LED.  The frequency of the blinking was variable when one of the resistors was exchanged for a potentiometer.

The goal that was not achieved 100% was the “learn to do something” goal.  First I will explain what happened, and then explain what went wrong.

Even though we had plenty of components for everyone, we did not have a 1:1 ratio of person to breadboard.  However, the real bottleneck to having each person actively prototyping and debugging their circuit was power.  We didn’t have enough time to get 30 of one type of power supply, let alone 30 of any power supply, so we had about 6 power supplies of different types scattered around the room, ranging from computer ATX power supplies, to modified wall worts, to powered breadboards.  We also made some slight errors in our handout for the activity.

Red lines or Xs indicate errors or omissions from handout…Oops!

We did account for people not knowing how to use a breadboard, which is why we included the diagram.  However, the combination of the two diagrams were nearly useless because the students didn’t know the convention for numbering pins on an IC, and so they couldn’t correlate the numbering on the European-style schematic with the breadboard sketch (made in Fritzing).  A similar problem was that we did not supply a guide as to what component was what in the diagram.  Since we had expected a much lower turnout, we had expected to walk everyone through the process, step by step, troubleshooting on the fly.

The combination of these three mistakes made the situation chaotic, noisy and somewhat stressful.  People were discouraged, I thought that we had given them the wrong components…and then someone got it.  Slowly we realized the errors we had made and we corrected for them, by yelling things like “THERE NEEDS TO BE A WIRE BETWEEN TWO AND SIX!” and running around adding wires.  I have to give props to Sasha (a random upperclassman passerby) here, because she decided to stay and help debug, which was super helpful.

We included a feedback section on the handout where people could write in what went well, what went poorly, and what they would like to build.  This was unfortunately attached to the handout that we wanted them to keep, which is something we eventually changed (in later Secret Knowledges).  What we learned from this was that people were curious about what was in the “black box” of the 555 timer, and that they were still mighty confused in about a few things that we had tried to teach them.  The two prevailing positive comments were that building the circuit had taught them the most, or working with a partner had taught them the most.  As far as things they wanted to build, most people wanted to make robots, or something that interacted with the world.

Based on the feedback we received, and what happened, I came to several conclusions about what we needed to do better.  The first thing is that we needed to have equipment.  Six power supplies is not enough for thirty people.  The next problem was that we didn’t have a strong structure, which seemed to confuse some people, and caused them to drift off onto tangents when they went to build.  We only talked for 15 or so minutes, and spent the rest of two hours debugging/building.  Thats good talking to building time, but its bad that it took that long to build due to bad instructions.

Overall I would say it was a success, but that the program was definitely improved upon in later iterations.  Things we took to heart were preparing handouts, and checking them for errors, as well as providing background.  The next couple posts will be about parts II-V, and if you read them you can see how some of the things we did worked out (or didn’t).

Lately, I have been working on what I call the “Secret Knowledge Project”.  Basically, Kevin, Neal and I have been trying to help freshmen bridge the gap between “that would be a cool thing to build” and “This is how I would build the cool thing”.

The gap seems to have two main components; there is a confidence gap, and a knowledge gap.  The knowledge gap is straightforward to explain; people just don’t know how to make things, or where to start, or what their tools are.  The confidence gap is the complex part.  Even though most of these people have science/math backgrounds, and were born into the “computer age” there seems to be some sort of confidence barrier that prevents them from thinking “this would be cool” looking it up on google, and then either finding instructions to make what they want or synthesizing their own instructions from what they learn.

I don’t really know why this barrier exists in general, but I certainly know I run into it now and then.  Personally, it tends to be that I straight up don’t know where to start, or even what to research, or that I have too many options.  The other limiting factor tends to be the uncertainty factor in building something.  Uncertainty is the combination of the risk that the project won’t work based on changing something, not being able to find materials, or that the instructions are bad.  In the case of synthesizing new procedures, uncertainly is caused by a lack of knowledge in the field.

I think uncertainty is the primary reason that projects don’t get done.  Other competing factors are the “cool” to work ratio, and the costs associated with a project.  However, at Olin costs can be mitigated by finding funding or using on campus resources, and the there are plenty of cool projects to do, yet I feel like not many get done.

So, the goal is to bridge that gap and to foster personal projects and learning at Olin.  We want to bridge the gap between thinking and doing, particularly in projects with a lot of parts and a lot of variables and uncertainty.

I will be doing a lot of catching up on this blog, so expect some posts about Secret Knowledge parts I-IV.  Part (or volume) V is tonight!