My school district has a STEM course in the high school that is meeting the district’s computer science graduation requirement. That means that the STEM students need to be meeting the CSTA K-12 Computer Science Standards. Curriculum development can be quite the balancing act, especially in a course like this. How do you fit serious CS into a course that is already chock full of basic physics, engineering and math? Without adding any more time, of course! Here is an example of a unit I converted to include more CS.
Cell Phone Amusement Park
This is the first unit of the STEM 1 course. Students are introduced to the engineering cycle, the role of the engineering notebook, and how to read and create engineering drawings. I emphasize planning before building (I refer back to this when we get to pseudo code and programming).
The class brainstormed ideas for rides we could build with our materials (VEX robotics kits). They then broke into pairs and started reverse engineering their chosen ride, often using videos and photos found on the Internet. This stage focused on engineering drawings. We broke the ride into stages of development, starting with the base and how the motor and gearing would create the required motion. Once the teams built this first stage of the ride, I introduced them to the programming language we would use for the VEX, RobotC.
I introduced pseudo code as if they were writing specs for someone else who would do the programming. If they were too vague, I would give it back to them and say “I don’t really know what you want me to do.” When the teams shared their pseudo code, we were able to make a list of what they needed to know how to do in the programming environment. They wanted their motors to start slowly, and gradually ramp up to full speed, run at full speed for a set period of time, then slow down gradually to a stop. They felt that this is what a “real” ride does. Since the VEX motors can only take one value, power, I taught them how to use variables and loops to ramp up and ramp down. After writing some code and testing their programs, they decided they also wanted a start button, just like a real ride. Since touch sensors are binary, this led into a lesson on binary and sensor values.
After some more engineering and building and testing of the rides, we were ready to load some cell phones in. Why cell phones and not dolls or some other representation? The accelerometer data! We installed an accelerometer app onto our smart phones that allowed us to record the output of the accelerometer on our phones as a csv file. We had at least one csv file per ride, and each file consisted of many data points.
Analysis of large data sets is now naturally a part of the curriculum. The students collaborated to decide what makes a ride “fun” and how to use the sensor data to support that idea. I taught them various strategies to analyze the data according to what they came up with. At one end we had a ribbon for the best ride for thrill-seekers and at the other end a ribbon for the best ride for young children.
This unit takes the same amount of time as the Rube Goldberg machine unit it replaced. The new unit still contains all of the science, engineering, and math that the previous unit did, but it now also includes an introduction to pseudo code, programming in RobotC, variables, control structures, conditions, binary and analysis of large data sets!
Perhaps best of all, the students loved what they had made and are looking forward to our public display of the “Cell Phone Amusement Park” at our school on Halloween.
Tammy Pirrman
CSTA School District Representative