Integrating Computer Science Across the Core by Lynch Tom Liam; Ardito Gerald; Amendola Pam & Gerald Ardito & Pam Amendola

Integrating Computer Science Across the Core by Lynch Tom Liam; Ardito Gerald; Amendola Pam & Gerald Ardito & Pam Amendola

Author:Lynch, Tom Liam; Ardito, Gerald; Amendola, Pam & Gerald Ardito & Pam Amendola
Language: eng
Format: epub
Publisher: Taylor & Francis Group
Published: 2020-03-17T00:00:00+00:00


A Tale of Two Robotics Projects

We, your authors, have all used robots as vehicles to introduce novices to software programming. The work described in this chapter was inspired by two such robotics projects: one conducted with sixth-grade math and science students, the other conducted with high school students in grades 10 to 12. (We will also hear about Pam's more humanistic robotics project in Chapter 7.)

Why Robots?

In our various experiences with introducing students to programming, we have found that many of them relate differently, and sometimes more positively, to a physical object rather than a digital one. Robots provide the combination of physical and digital experience that seems to be a sweet spot for young people.

As described in Chapter 3, we think of it in terms of abstraction. When older elementary or younger middle school students are working to program digital objects, there is always a moment when the object being programmed is beyond the student's world, “out there” somewhere. This becomes especially relevant when something is not working as intended. Later, students learn the term “debugging,” but early in the process they just say, “It's not working!” When encouraged to describe the problem, they often use opaque language: “Scratchy the cat won't meow when I want him to!”

With robots, this process is far less abstract. In the robotics projects that Gerald developed, one of the earliest challenges he gives to students working with robots for the first time is some version of a race. To meet this challenge, students must program the robot to travel, as quickly as possible, in a straight line—say, down a hallway—and then come back again. When they see that their robot is not doing what they intended it to do, meaning their program does not work properly, the robot's physicality seems to reduce the level of abstraction with which they are dealing. When something is not working, their descriptions are far more concrete. Instead of “my robot is not doing what it's supposed to do,” they say, “I want the robot to turn right for three seconds, but it's not doing that.” Students pick up the robot. They look at it. They then look at the code. Their work is no longer about coding for its own sake. Rather, it is about discovering how to realize one's intention for and with this physical device. Students want the robot—that physical metal thing right over there—to actually behave the way they want it to. We have seen this difference to be a profound one for secondary students.

(As an aside, there is also something about the process of physically assembling their robots that is similarly meaningful to students. Robots often come unassembled, and each time Gerald has begun a robotics project with either middle or high school students, he has them assemble their robots themselves. This process takes about twenty to thirty minutes. During that time, a small transformation takes place in which students form a relationship with the device, often naming their robot whether asked to or not.



Download



Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.