Conception

With the relative success of Apocalypto and Piracy Based Learning, I felt a great deal of pressure to do something big. I also felt myself getting bored with mechanical apparatus and I was starting to develop my personal skills as a programmer through tinkering and a database consulting gig I landed. My teaching partner and I had also sacrificed our common prep period to recruit a math teacher to our interdisciplinary team. Initial project ideas included Drone Artillery and The Meta-Fabricative Machine (MeFab). However, after a great deal of discussion and brainstorming, we chose to stick with the interconnectedness of Apocalypto and started to focus-in on our initial project idea for ElectriCity-States. The attached document illustrates our initial project pitch (click the image below to see the project pitch).

Scaffolding & Skill Building

Going into this project, I knew that it was going to be very technical and complex. We would be using concepts, skills, and materials that I didn’t get exposure to until my second year in college as an Electrical Engineer. Is this crazy to do with 9th graders? Maybe. But I was sure that it was possible with the right scaffolding and support. Ignoring the humanities (dilemma research) and mathematics (infographic) side of the project, the technical nature of this project can be broken down into mechanical engineering, electrical engineering, and programming components. This is how I went about scaffolding each section.

General

In the beginning of the project I built a simple example of what this project may look like when complete. Although it wasn’t a fully accurate representation of the final result, it was enough to get students started and was the basis of much of my scaffolding. Unfortunately, I didn’t have the foresight to photograph this  prototype and it has since been scrapped for parts.

Mechanical Engineering

Mechanical Engineering Scope: Students had to create a physical interface to house their electronics. In it’s simplest form, students need to design, and draw in Illustrator, a 2-dimensional cutout per supplied specifications. This cutout would be designed to fit all of their electronics but remain thematically connected to their chosen dilemma. In it’s most complex form, this design would also include mechanical interfaces that either supplemented the user interface (mechanical switches, slides, etc.) or worked with their feedback system (mechanical scales, gears, etc.). Examples of these two extremes are shown below:

Mechanical Engineering Scaffolding: Our introductory project this year was MAKEshift Poetry. Within this project, students created gear systems and other mechanical apparatus of varying complexity. This project served as an introduction to project based learning but also explicitly taught students how to design and build mechanical systems. We started with simple sketches then progressed to paper prototypes, cardboard prototypes, and MDF prototypes before eventually cutting them out of finish materials. In addition to allowing students to experience a complete design process, MAKEshift Poetry also explicitly taught students how to use Adobe Illustrator, gear generator software, and how to prepare files for laser cutting (tutorials here). With this project already under their belt, the mechanical engineering aspect of ElectiCity-States was meant to be straight forward.

Programming

Programming Scope: Students had to design and write a program for their Arduino using the programming language C++. Their program had to control and operate a physical user interface. Students interfaces included buttons, LEDs, LCD character displays, OLED character displays, shift registers, brushed motors, stepper motors, servos, and other miscellaneous hardware. In addition to controlling interface components, students had to design and implement the logic behind their interface in order to control the user experience. It’s worth noting, however, that programming on this project is a means to an end. I included it in the scope of this project because I believe it to be a great tool for developing problem solving skills and an understanding of causal relationships. That being said, this project was not meant to be a comprehensive introduction to programming. Programming is just one of many tools employed on this project.

Programming Scaffolding: Most of my students had no experience with programming. In fact, many were uncomfortable with using a computer at all. Before even mentioning programming as a part of my class, we went through a mini project using SCRATCH. SCRATCH is a …

Tile-based visual programming environment and toolkit, lets kids make games, animated stories, interactive art, and share with others on the Net. (http://scratch.mit.edu/)

I must admit that I have a small crush on SCRATCH. You can put it in front of kids with no guidance or instruction and they just start to play. Before you know it, they’ve inadvertently discovered and implemented all sorts of programming concepts. After a few days of just letting them “make something cool” with a partner, I gave them the more structured task of making an application. They proposed an application they wanted to make using this prompt and proposal form and got to it. Click a thumbnail below to see their complete applications.

Once students finished the SCRATCH project, we began to transition into C++ and Arduinos. We started with some very preliminary LED laboratories that exposed students to concepts of electrical engineering, bread boards, LEDs, buttons, the Arduino hardware, and the Arduino IDE. The full descriptions of these assignments are available here. There was very little (nearly zero) formal class instruction during this time. Students were given time to work while small sub-groups rotated through several stations – each manned by an adult. At these stations they would learn the basics of C++ syntax, LED behavior/design, formatting code, using breadboards, etc.

When we began to discuss finite state machines (FSM), students were asked to create finite state diagrams to illustrate their desired program flow. From these finite state diagrams, students implemented their FSMs using switch/case statements.

Throughout the process, I shared code snippets that were used in my project example. Students were then able to reverse-engineer and tinker with working code to see how they could adapt it for their own use or structurally model their code after it.

Basic programming concepts and resources were posted on my DP here.

Electrical Engineering

The electrical engineering part of the project was initially meant as a supplement to the concepts of Electricity and Programming. It was planned to include simple connections of LCDs, LEDs, buttons, switches, etc. However, as project progressed, student designs required the use of shift registers, multiplexers, laser diodes, photoresistors, linear slide potentiometers, and stepper motors. These additional materials were approved on an as needed basis for student use. Other than the laboratories mentioned in the prior section, there was no formal instruction for these concepts. However, I did refine resources for the students to start their journey from. An example of these assembled resources is available here.

Modifications

As we worked through the skill building  and project planning stages we began to notice and realize some things that worried us, including:

• Class Size – Compared to last year, our class size had grown from 28 to 32 (our team from 56 to 64). This meant that our team had to supports two additional project groups with respect to: one-on-one time, academic support, materials, etc. It may not sound like much but when you have 8 more kids in a space during project time, it made our project style noticeably less effective.
• Student/Computer Ratio – This project was very technology intense. In addition to needing computers for dilemma research and word processing, we also relied on them for programming the Arduinos, creating the infographics (in Adobe Illustrator), and creating the designs for the physical interfaces (also Adobe Illustrator). With three out of four students in each group needing a computer at any one time, we had to be very creative with how we structured work time. Despite our best efforts, however, there was a tremendous loss of student efficacy. Most frustratingly though, our computers were not participating with us.
• Technology Issues – Our school computers run both Windows XP and Windows 7, with our IT staff restricting many of out administrator privileges (for students and teachers). The Arduino IDE (the programming interface software) had huge issues. The drivers which allow the Arduino to connect to the computer would uninstall themselves or not operate properly under student accounts. This meant that a teacher had to manually install the drivers on every computer, every time a student logged in. The process took approximately 3 minutes and students could not proceed with coding until we got to them and it was a huge time waster. We also had issues with the Arduino IDE not recognizing serial ports which we were usually able to overcome with a little USB dance (save, unplug Arduino, close software, plug into a new port, re-open software). Despite our best efforts, and those of our IT staff, this was very frustrating.
• Diversity – This year is an extremely ability diverse class and watching many students struggle significantly with the the introductory skill building activities raised a yellow flag for us.

Because of these concerns, we made a few changes to the structure and end-result of the project. Our changes included:

• Interconnectedness – We shrank the scope of this project significantly. The most significant thing we changed was removing the interconnectedness of the entire exhibit. One project would no longer lead to (or react to) other student projects. Aside from a device network that I created for the projects, student projects would be created on a per-group basis and would stand on their own.
• Enticing the User – The projects were initially going to include a sequence (think psychedelic flashing lights) to draw potential users towards the exhibit. This was also removed from the project scope.
• Libraries – As students started using more complicated hardware (i.e. OLED Character Displays, Shift Registers, I2C Networks, Serial Protocols, etc.) they had to rely more and more on existing code libraries. Where libraries didn’t exist (or were too complicated) I created libraries for them to use.

Student Work

Exhibition

Exhibition was a very busy time and, as a result, I have very little media to share. We were able to mount more than half of the student projects operationally while the other half of our groups displayed their in-progress pieces and explained the process to guests. Our power and communication network was plagued with problems unfortunately which caused intermittent performance by some pieces and a good old fashion electrical fire in another. All in all, it was a mild success.

Reflection

Looking back on this project, I have a few lingering thoughts …

Scope

While my projects are intentionally intense, the engineering scope of this project was excessive. Specifically, the electrical engineering component. Many groups had to use shift registers which required advanced programming concepts to implement, including: binary numbers, bit masking, and bit-wise operations. Furthermore, these devices required an enormous amount of extra wiring. Other excessive electrical engineering challenges include:

• Creating a 3-dimensional gesture sensor using laser diodes and photoresistors.
• Using stepper motors, which required: stepper motor driver boards (each of which had to be customized to reduce overall I/O ports being used), zero-point/registration sensors to guarantee repeatability.

In-Class Help

As a result of past reflections, I went into this project weary of becoming a bottleneck for student progress – especially on the programming (where it is less reasonable to always expect students to find their own solutions). In preparation, I reached out to my social and professional networks for some in-class expertise. I was able to arrange six professional programmers who each spent a few hours a week in my class leading up to the project. However, when the going got tough during project time, many of my experts started getting tied up at work so I ended up being a bit of a bottleneck after all.

The same goes for our Academic Coaches and other integrated support staff. As the content became more and more technical, the students surpass the abilities of our support staff in the first few weeks. Going into future projects, this makes me wonder if I need to scale back the difficulty or intensity of the projects.

Final Installation

When it came time to permanently install our project, we spent a great while determining the right spot. After instaling Apocalypto myself the previous year, I was also adamant that students should perform most of the final installation work. We worked on the installation aside our next semesters curriculum – painting the wall, installing and re-installing and re-installing the work to ensure level, and wiring the entire apparatus. The final work has an electrical and communications backbone far superior to that which I had developed for the exhibition. The original exhibition backbone leveraged all 4 pairs of standard CAT6 cable to support an I²C Bus (the way Arduinos communicated with each other) as well as 12V power. Despite my voltage drop calculations, this was not able to supply adequate power to most projects. The final installation backbone leveraged all 4 pairs but with a different purpose. It supported the I²C Bus and system reset signals but I purposed the other two pairs to run project-independent RGB LED Strip drivers which are what create the backlight for the projects. 12V power was run separately with 16 gauge duplex wire. All of this was hidden in the drywall and some wiremold – including the CAT6 Patch Panel that I scrounged off of craigslist. As students completed the wiring we puzzled for weeks over some mysterious behavior which eventually resulted in some interesting discussions and discoveries of capacitance, induced currents, pulse width modulation, and how to use internal arduino timers to slow down the bus speed.

To supplement the installation, each individual project reports it’s user interactions to a master Arduino which displays the cumulative user input as a “Faith in Humanity” dial. Since the installation – the dial hovers between the middle and “DOOMED”. The video below shows a glimpse of the finished installation … although we hope to add a few more projects soon.