We launched the digital making project as a part of the ecosystems NGSS & ELA unit that we were working on, as a way of addressing CS standards as well as the NGSS standard that students make observations of plants and animals.
Before diving into making our wildlife cameras, my teaching partner, Terri Hughes, and I did a little background work with students to make sure that they had some understanding of the hardware that they were going to be working with. We read Hello Ruby: Journey Inside the Computer to each of our classes and discussed the difference between hardware and software. We also taught students computer-related vocabulary so they could speak accurately about their machines and the work we'd be doing (monitor, mouse, cursor, inputs, outputs, etc.).
Next, we brought all of the 2nd graders together and launched our digital making project with a question. We reminded the students that we had watched lots of animal videos throughout our ecosystem unit, and that we noticed their interest in animals on our own campus--so we asked them, "how might we better observe urban wildlife in our own community?"Before ever mentioning that we were going to make our own wildlife cameras, we had students practice their brainstorming skills by coming up with all the methods they could think of to make observations of nature on our school campus without disturbing that nature. When several started talking about cameras, it was at that point that Mrs. Hughes and I announced that we thought that sounded fun and that Mrs. Haughs had everything we needed to create and program our own wildlife cameras.
Day 1 of digital making involved getting students into teams of 3. I've found that groups larger than that don't tend to work well-- there's not enough for everyone to do. I told students that we wanted the teams to be balanced, so that each team had a strong coder, editor and builder/electronics person (or, even if they weren't sure they were strong in an area, that at least it was a skill they were very interested in) and then had the students develop their own teams. They did a fantastic job of making the teams themselves, and took the process very seriously, pointing out to me who would be the "expert" in each skill on their team as I approved each team.
Next, we reviewed the parts of the computer that we'd learned with Hello Ruby as a whole group, and pointed out each of those parts on the Raspberry Pi. I asked students what was missing from our Raspberry Pi so that we could use it and they had to list off the other parts of hardware that we'd need (keyboard, mouse, monitor, power). Then we took turns, one person at a time from each team, picking up those materials from our computing corner until teams had everything that they needed to get started.As for electronics components, I decided to use Pibrella HATs, motion sensors and PiCameras on this project. I put the Pibrella HATs on the Raspberry Pis ahead of time so students wouldn't have to learn that on day 1, and left PiCameras off for the first couple of lessons, while students learned how to setup the code that they needed in Scratch in order to program the Pibrella. The goal was to get the motion sensors up and running first, as I tend to struggle with these from time to time. I've found that they end up being way to sensitive or not working at all, and I wanted students to be able to get over this hurdle in the beginning and leave the "easier" stuff, like the Picamera, for last.
To help students learn how to program each element, I made a Pibrella-focused slide deck/activity card deck that we printed off for the groups. I like the "copy to learn" format for getting students started. With the printed card deck, groups could move as slowly or quickly as they wanted through the project and then customize as they learned how their program worked. This format helped teams worked more independently and try to solve their own problems while I circulated the room.As I suspected, we ended up not able to get the motion sensors to work quite right, and as we didn't have much time for troubleshooting, we reviewed the term "prototype" and how sometimes in design we put things together as a sample of how the real thing might work, even if it's not exactly how we want the final product to look. Then, we learned to program buttons instead and by the end of the unit, every team was able to program their button to turn on at least 1 LED and take their picture.
In the end, one small set of students wanted to keep working on their project independently and so in their free time they recreated the camera project, adding a Makey Makey and copper tape for touch activation and trying to create some "camouflage" elements to the prototype so that we could more easily hide the cameras somewhere on campus (even color matching our school walls to the paint they used for camera cover).
