Robot Buggies engage diverse learners in computer science

The Raspberry Pi "Robot Buggy" culminating project has become a 7th grade tradition at my school, and
a pathway to engaging all students in computer science. Inspired by my experience as a Picademy attendee in 2016, and by the robot buggy project posted on the Raspberry Pi projects webpage, the unit is designed as a hands-on approach to learning and applying introductory coding, design and making concepts-- and more importantly, to get a wider variety of kids interesting in computer science. It has become my favorite unit of the year, and is the project in which my students are the most motivated and engaged all year. 

As a required enrichment class in our school, I teach a very diverse group of students every year with (like any other class) varying levels of interest in computer sciences & coding. With the robot buggy project, students do not have to be a "coder" to be successful in the project, and can find engagement in computer science through other skills and interests. Students who may not love coding, can become excited about constructing the robot buggy, exploring more hardware skills, or learning how to use basic hand tools. 

The skills students cover in this unit include: 

• learning & applying Python coding skills in a practical context (libraries, functions, loops, inputs/outputs, and more)
• learning & applying electronics skills to connect motors and other choice elements (simple circuits, using jumper cables, buttons, motors, troubleshooting)
• engineering & design skills as they design a chassis and creative casing to hold the weight and size of their components (computer, other electronics, battery pack)
• arts & making skills, including cutting; gluing; line art & laser cutting; how to use hand tools (drill, screwdriver, screws and bolts...); painting and other arts for decorating their bots
• thinking mathematically about how to program their buggy bot to move in certain directions (i.e. how to program a turn without a "turn" function in the ExplorerHat library)
• perseverance through challenging tasks
• thinking creatively about their design and movements
• practice project management & collaboration

Project Outline

1. intro to hardware & software integration
2. exploring the ExplorerHat
3. rapid prototype a chassis
4. discover how to code a turn with the .forward, .backward, and .stop functions
5. design plans for final robotics project (students must meet certain basic requirements in their project, but can go beyond to customize and/or add additional electronics or coding elements of their choosing)
6. construct & code buggy bots
7. setup VNC (virtual network computing) for controlling bots with Chromebooks
8. showcase projects at our Robotics Exhibition

Why not just use a kit?

I've had some families ask why I don't just use a robotics kit for this unit, so the students have instructions to follow for the build, or so the final bot "looks nicer". Since the project isn't just about coding, I intentionally do not use pre-created robots for this unit. And I do not want students to simply use a manual and follow the instructions to complete their build. My intention is for students to learn design, math, science, engineering, maker and coding skills by experimenting on their own. I want them to develop their own ideas for what their bot will look like and how it will function. 

And yes, there is a lot of failure along the way, some frustration, some disappointment, but there is also a much greater sense of accomplishment when teams get their bots built and moving. No matter how simple some of the final projects may look, every team has a story about the challenges that they had to overcome to finally get something working, and what they learned along the way.

Teams & Timeline

Generally, the initial introduction to hardware & software, exploration of the ExplorerHat, and integrating electronics with coding happens several months in advance. Final projects are created in about 8 class sessions (although it's not uncommon for students to also show up during lunches, office hours and during other classes to put in extra work). Teams have mostly been determined by students, with my final approval and adjustments. This may or may not be the case moving forward-- for some, choosing teams means they are comfortable speaking up with their teammates, but for others, it is too distracting to be working with friends. 

Exhibition

I have discovered that having an authentic audience for my middle schoolers is the greatest motivator. Students always work their hardest on a project that they know they will be sharing with someone other than me. We invite families, other classes from our TK-8 campus, district-level administrators and other guests to view students' work and provide feedback. My "plus 1" this year was to provide feedback forms to our audience members, to help them ask better questions and provide teams with feedback while visiting our exhibition.

Next Steps for the Project

• Develop more concrete team roles 

One of our district board members (and a software engineer, herself) has been extra supportive of this project from the beginning, coming to all of our exhibitions and brainstorming next steps with me after her visits. We have several times discussed that not everyone in the comp sci industry is a programmer, so why not have students work within certain roles on the teams (designers, developers, engineers, team lead, etc...). While the teams tend to do this informally, I would like to develop a more concrete structure for the teams to follow. I also need to teach the model explicitly, so that it's not assumed that just because student A didn't do any coding, that student B was the one who "did all the work".

• Teach project management

One of the biggest barriers for students is being able to manage a long-term project and to keep up with their timeline. While I love the energy and dedication of students showing up during lunches and office hours, I want that to be because they are super engaged and trying to add extra details to their project, not because they have fallen behind on their work. Next year I plan to schedule in time for teaching project management skills, including breaking down the project in more detail, flowcharting and developing a realistic timeline. 

• Improve the feedback system at exhibition 

While it was great to see so many guests picking up and filling out the feedback forms for teams, they did not know what to do with the forms when completed (give to me or give to team directly?). I didn't have an opportunity at the exhibition to explain the forms to people, nor did I have any signage up.

• Provide question-asking scripts to exhibition guests 

I always appreciate the huge family and peer turnout at our robotics exhibition. The support means so much to our students. But as a staff we often discuss ways that we can coach our community members to ask better questions at our showcases, as this will help students grow as reflective learners and as presenters. Next year I want to include, on the back of the feedback forms, questions that guests can ask to get students talking in more detail about the work that they did and the learning that took place.