I recently got a lot of responses about my use of a pinhole camera as a lab to introduce functions and curve fitting during *Unit 0, Scientific Reasoning* in modeling instruction.

**Here’s my original post:**

As another introductory lab for the scientific reasoning unit, I made some pinhole cameras from two boxes that could telescope inside each other so students could adjust the distance from screen to the hole. Students think the camera is cool, so it’s a memorable lab, you can get linear, inverse, squared and inverse square curves from the data, depending on how far you want to go with it, and the meaning of the trends relates to directly observable sizes of the object or the image. To get the squared fits, you find the area of the image by box counting, which reviewed the concept of area. All of this proved very useful later in the year, as they actually remembered the lab, and could think about whether sizes were increasing or decreasing to help recall the association between graph shape, equation and meaning.

I used the circle lab as a follow-up, and I still like it, but the students just don’t tend to remember it as well. Other labs such as the pendulum or a bouncing ball are memorable, but the relationships are more abstract and the students don’t seem to hold on to the visual picture of them as long, so they weren’t as good of a recall aid.

And here are more details:

**Building Plans:** I built the cameras out of black foam core I got at the office supply store.

**Materia**l

black foam core 30”x40”

**Outer box**

L = 57cm

W = 19cm

**Inner box**

w = 17cm

**Cuts**

With a box cutter, cut all the way through to separate the outer and inner boxes. Score the other lines leaving the bottom paper/cardboard surface in place to hold it together. Bend and tape to form a box. I taped all of the edges for extra support, even though I left one layer of paper on most of them.

For the screen, I used 1/4” ruled vellum from Dick Blick.

Here are some photographs of a camera already cut out and ready to fold, and then completed.

For an image, I projected a cartoon of an elephant onto the screen at the front of my room and turned out the room lights. Everyone pointed their camera at the same object. Having the object on a screen and the image on another screen created some confusingly redundant language, so when I do it again, I’ll use an actual object outlined with lights. Maybe I’ll use a string of white LED Christmas lights and let the students tape it to a whiteboard in the shape of an animal of their choice. I want the object to be some irregular shape, though, so that it is easiest to get the area by counting boxes instead of calculating.

**Update August 2017 – Light bulb for object, cheaper and better screen**

We just got done with this lab this year. Thanks to my colleague, Rachel Atay, we made some improvements to the screen and decided on a bare light bulb for the object and it worked well. Any incandescent or LED bulb that was bright enough worked fine, so long as it was frosted and bulb shaped so that it made an irregular shape on the screen. We ordered some of these sockets, which plugged right into a power strip at each lab station – inexpensive and easy.

For screens, we got some tracing paper at Staples and traced a cm grid onto it. It is thinner than the velum we were using before so the image is brighter, the grid lines are darker, and they are more closely spaced. This all made it easier for the students to take good data, and the tracing paper was available locally and a lot less expensive.

**Results**

Here is a whiteboard with results from one student group. Note the independent variable and dependent variable and resulting graph shape and equation for each experiment. I did not try to combine the results into a single equation or derive it using similar triangles and ray tracing, as my objective was just to introduce and practice experimental design (identifying the IVs and DVs in the pre-lab discussion), data-taking and curve fitting.

Here is some sample data from another student group and their graphs from Desmos.

]]>

- After input from users, the software to run the robots was re-written and updated with new features.
- The Science House at North Carolina State sponsored a summer workshop through their summer modeling institute program. It was attended by almost a dozen experience North Carolina modeling teachers, who went through every activity alternating in student and teacher modes modeling workshop fashion and gave it a thorough critique. Every single activity was revised based on their input, new exercises were added and the sequence was altered to be more effective.

- The updated full curriculum is available from the American Modeling Teachers Association at http://modelinginstruction.org/teachers/resources/, and for AMTA members it is also available in the resource section of the members area.
- My article, The Maiden Voyage of a Kinematics Robot was published by the American Association of Physics Teachers in The Physics Teacher. It outlines the whole project, including a summary of the new curriculum sequence and a brief description of some of the activities.
- The Science House has agreed to hold a workshop in late July this summer as well. Unlike last summer’s workshop that was funded through a DOE grant, this workshop will cost about $600 (including two robots and software), but is also open to participants from outside of North Carolina. Low cost housing is available on the NC State campus.

Future plans include the design of a robot dedicated to this project that will be faster, more precise and hopefully lower cost. It will initially be available just as plans, then perhaps a kit and in the distant future perhaps as a complete robot. In addition, I will be re-writing and upgrading the motor driver for the robot and the graphical user interface. Finally, I hope to extend the use of robotic physics apparatus that takes advantage of control of error to other areas of the introductory physics curriculum.

Please stay tuned for information about further developments, blog posts about the revised robot activities and their use in class, and more specifics about the summer workshop as they become available.

For now, please continue to contact me via e-mail at matt_greenwolfe@caryacademy.org to purchase software. I hope to have an online store attached to this blog at some point in the future.

]]>

As you can see, the constant velocity robot’s distance doubles when time doubles and triples when time triples, while the constant acceleration robot’s distance quadruples when time doubles and “nine-tuples” when time triples, creating an easy to see demonstration of the scaling rules. It’s also a nice display of the accuracy of the robots. I set both robots to travel one foot (one square of tile) in the first second. The accelerated robot stops less than a cm from the ninth tile and all the rest are at least as accurate. I think the value as an introduction to the position vs. time graph for accelerated motion is obvious, and this could be repeated for comparison with a robot that slows down or one that starts with an initial velocity and then speeds up. Students often have difficulty seeing differences in the different curved graphs, which can be very subtle for them at first glance.

]]>

I also gave a presentation on the robots at the AAPT NC Section meeting at High Point University and at the Southeastern Brain and Learning Conference.

]]>

… encouraged by the testing of their solutions with the robots. They wanted to see it really work, and went back with enthusiasm to search for a more accurate method or to track down errors in mathematics.

Over beers at late night physics teacher gatherings, conferences like the American Association of Physics Teachers (AAPT) or Physics Teacher Camp, it seems someone almost always pipes up to say, “I just love lab practicums. They’re great! I wish I could do all lab practicums rather than textbook type problems.” Well, I and a collaborating teacher just turned some classic physics problems into lab practicums using my reprogrammed Scribbler 2 Robots. First is the patrolman and speeder problem, a great student exercise because it lends itself to so many different problem-solving approaches.

**The Patrolman and the Speeder**

Here’s the classic statement of the problem.

(a) A speeder driving down the road at a constant 20 m/s, passes a patrolman parked on the roadside. The patrolman waits 3 seconds, then pursues the speeder, accelerating at a constant 4.0 m/s

^{2}. How long does it take the patrolman catch the speeder? How far has he traveled before doing so?

And this is all it takes to turn it into a lab practicum with the robots.

(b) This can be modeled with robots if we use cm instead of m and multiply the speeder’s velocity and the patrolman’s acceleration by 0.3 (i.e. if robot 1 starts with a speed of 6.0cm/s and robot 2 starts in pursuit 3 seconds later with an acceleration of 1.2cm/s

^{2}). Repeat your calculation with the numbers for the robots, then program and run them to test your conclusions.

I love this problem, because students can get the answer by solving two simultaneous equations leading to a quadratic formula, graphically through the intersection on a position vs. time graph, using graphical estimation based on area and the meaning of the slope on a velocity vs. time graph, or most elegantly as discovered by a group of my students in my first year of modeling by using a single line of simple algebra after setting up an equation using the velocity vs. time graph. Now they can also test their answers in the lab. (Details about how the students program the robot with graphical GUI’s are in a previous post.)

Typically student groups started by trying either the mathematically intensive simultaneous equations or else graphical estimation based on the the position or the velocity graph. The former groups would typically make mistakes – often leading to tests with the robots that were way off the mark – because this approach was stretching their mathematical background and ability, while the latter groups would more quickly arrive at an answer that was in the ballpark, but wonder how to get a better answer using a more deductive procedure.

By the time they were finished, most groups had done repeated tests and ended up using more than one method. This was definitely encouraged by the testing of their solutions with the robots. They wanted to see it really work, and went back with enthusiasm to search for a more accurate method or to track down errors in mathematics. The groups who started with the more mathematical approach would often wonder if there weren’t an easier way to get an accurate answer, and really appreciated the elegant mixed graph/equations approach based on the velocity vs. time graph. Observing the groups using graphical estimation helped them appreciate that approach as an aid to track down mistakes in their mathematics.

Students at this level are often uncomfortable with approximation and estimation as they transition from more concrete to more abstract reasoning. It’s not uncommon for students to undervalue graphical estimation or even feel personally diminished because they had to resort to that method. Both the method and the students using it got a boost when the robots confirmed that they were on track.

**Crash!**

Robot’s 1 and 2 start 131cm apart and move towards each other. Robot 1 travels with a constant speed of 15cm/s, while robot 2 starts from rest and has a constant acceleration of 3.0cm/s

^{2}. Set the time in your programs so they stop simultaneously just before colliding.

Much as the last practicum, students were disappointed when the robots stopped short (which was fortunately more common than accidental collisions!), and wanted to improve their problem-solving method or experimental technique to get it closer.

This set of graphs brings up an issue, the distinction between *going backwards* and *moving in the negative direction, *that only seems to arise when applying these concepts in the lab. The graphs above programmed both robots with a forwards orientation, but the way they move towards each other, one of them should have a negative velocity. Similar issues have come up in past years when detecting motion of students or other objects with motion detectors, but never in a written problem with no lab component. As this confused some students, I’ll need to think more about how to address the issue next year.

**Parking in the Garage**

Google is developing these cool driverless robotic cars, which surprisingly few of my students had heard of. So what if you wanted to program one of these? Your speedometer reads 16m/s and your obstacle sensor detects your garage 160m away. How do you program your car to make a smooth stop in your garage? Well, just change m to cm and you can test it with our own robots. This a relatively easy, but fun lab practicum with a practical application that got students warmed up for the more difficult ones.

Did you notice that the robot backed out of the garage slightly? This was a great opportunity for a Socratic question to the students, who quickly figured out what they must have done ever so slightly wrong when they programmed it, thus previewing a new feature of the constant acceleration model.

**A Prototype for a Subway Run**

Engineers routinely build prototypes during the design process for a full scale system. I’ve given my students this problem for years, partly because it is so much easier to solve it graphically. This year, with just a few more minutes of work, they were able to test their solution with their own prototype. Although this problem is pretty finite, I like the concept of getting students to apply their physics to a more open-ended transportation design problem. The potential is there.

The classic problem:

A subway train starts from rest and accelerates at a rate of 1.8 m/s

^{2}for 15s. It runs at a constant speed for 50s and then slows down at a rate of 3.5m/s^{2}.

And this is all it takes to turn it into a lab practicum with the robots:

This can be modeled by a robot if we use cm instead of m and divide all the times by 3. (i.e. the robot would accelerate at 1.8cm/s

^{2}for 5s, run at constant speed for 16.67s (50s/3), and then slow down at 3.5cm/s^{2}). Repeat your calculation with the numbers for the robot, then program and run it to test your conclusions. Programming a model to test a full scale system is common engineering practice.

As you can see, it travels very close to the predicted distance of 184cm. My goal at the beginning of the project was to program a robot so that its motion was accurate to within 1mm/s and 1mm/s^{2}. Over the course of 25s of motion, 1mm/s of error can add up to several cm, and the robots are at least that accurate – accurate enough and reliable enough that the students can tell when they’ve solved the problem correctly.

**Differentiation**

One advantage of being able to do so many different lab practicums with the same lab set-up was to allow students to choose their tasks. Following the garage practicum, some groups jumped immediately to the more difficult problems like the patrolman and speeder or car crash, while others preferred a more moderate-difficulty task like the subway problem or problem 4 below. The students were more engaged because they were given a choice, and I was easily able to move among groups checking work and asking probing questions.

4. Robot 1 travels with a constant velocity of 8cm/s for 18s. Robot 2 starts 6s after robot 1 with the same velocity of 8cm/s. Program robot 2 to catch robot 1 exactly at 18s by using just one constant acceleration.

**Graph Matching again – Honors and AP Physics**

My colleague, Jennifer Rotolo, who teachers the honors sections of physics and an APC mechanics class, had her students do an exercise based on the following velocity vs. time graph.

Here’s her description of the class.

Students were given a velocity vs. time graph along with a robot that was programmed to move according to that graph. Students were asked to describe exactly what the robot would do and then map out the robot’s motions on the floor. Students marked off how far forward they predicted the robot to move, how fast the robot would move, and where the robot would finish. Then they were able to watch the robot in action, to see how it actually moved. It was really neat to see all of the students’ eyes glued to that one robot! They were watching intently to see if their predictions were accurate.

The next task was for students to program their own robot to move exactly like the first robot. The catch was that students had to program their robots with position vs. time graphs, rather than the velocity vs. time graph they had just interpreted. Once students were finished, they watched their robot move alongside the first robot to see if the motions matched. The lesson was engaging for students and really helped them to grasp a tough concept that comes up in the first few weeks of physics. In the past, I have taught velocity vs. time graphs by talking through the qualitative motions out loud with students. The robots allow students to see these ideas for themselves, rather than me telling them.

The robots are a fantastic tool for learning physics. I think that one day every physics classroom will have them, and I feel very lucky to be one of the few that has them now. The robots can be used demonstrate endless concepts. They sort of make problems a game for students.

Here’s the graph-matching video.

**The River**

Toye Eskridge, our school’s marketing coordinator, described another of Jenny’s experiments for our school’s magazine.

In a lesson with her Advanced Mechanics class, Rotolo presented a classic physics problem that asks how long it takes a boat, moving perpendicular to a river current, to cross the river. “The idea is that the time it takes the boat to cross the river depends only on how fast the boat moves, and not on how fast the river flows,” she explained. “In other words, the time required for the boat to cross the river is independent of the current. This problem comes up for us in our study of vectors. We set up a lab in which some robots towed ‘rivers’ (poster board) to simulate a current, and some robots moved perpendicular to the current simulating the boats. The robots doing the towing were attached with string to the poster board. The students timed how long it took the ‘boats’ to cross the still river and then compared this time with how long it took the ‘boats’ to cross the river with current. They saw that the time was independent of the speed of the current. This is normally a tough concept to grasp, but I think seeing it with the robots really helped.”

And here’s what it looked like.

**Conclusions**

It was great fun creating these exercises and seeing some of the problems jump off of the printed page into real life. Because I could do so many things with just one apparatus that was intuitive for the students to use and did not require an elaborate set-up on my part, my class was even more hands on than usual. This is obviously just the tip of the iceberg.

]]>I knew from their graph what would happen, but didn’t say anything. I didn’t have to. When the students saw the robot go fast, then slow in segments 2 and 3, they commented “It’s opposite.” … And sure enough, they were then able to correct the issue themselves with no intervention from me.

This summer, I reprogrammed the Scribbler 2 Robot from Parallax Corporation to be a physics apparatus. (I intend the robot project itself to be the subject of a future blog post.). In this post, I describe three similar lab-practical exercises with the robots. **In all three tasks, students programmed a robot with a graphical user interface so that it’s motion matched another robot.** In the first, students programmed their robot with a position vs. time graph so that it matched one programmed by me. In the last two exercises, they programmed a robot with one graph (position vs. time or velocity vs. time) and the second robot with the other.

Each lab in the sequence also carefully introduced one additional concept for students to add to their pre-existing mental structure. The first task was student’s first encounter with motion in the negative direction, so the term *velocity* was introduced in the post-lab discussion and distinguished from speed. The second task challenged students to use a *velocity vs. time graph* for the first time. The third task provided more practice with velocity vs. time graphs and also introduced the concept of *area under the curve*. The whole sequence took six 45-minute periods of class time. The principle of introducing new information in carefully graduated amounts is another feature that distinguishes modeling instruction from teaching methods that would instead introduce all these ideas at once.

These types of exercises where students must change representations, for example here from position to velocity graphs or vice-versa are powerful tools for revealing whether students have built a coherent model of the phenomenon. If students work primarily or exclusively with just one representation – and most commonly in physics classes this is equations – then the work can easily become rote and mechanical. Using the robots, students are maintaining a strong connection to the motion itself while changing representations. When their graphs didn’t match, the conversation about how to fix it was never confined to language about the graphs, as in “When this graph has a slope, this graph is horizontal.” Even their graph-matching mistakes generated further discussion about how the graph related to the observed motion.

**Lab Practicum 1: Using a Position vs. Time Graph to Match a Pre-programmed Robot
(introducing velocity)**

I programmed each group’s first robot to go forward and back at different speeds and for different times and stop in the middle, and I broke the student’s task down into three phases. First, they had to program their second robot with the correct graph shape (so that it went forward and back, fast and slow and stopped in the same order as the first one, without necessarily matching it exactly). Second, they had to get their second robot to match the first one exactly *by taking the smallest possible number of measurements*. Third, they had to calculate the slope of each graph segment, with units, and show the graphs and calculations on their whitebaords. The following videos and graphs document one group’s problem-solving process. (I described the graphical user interface and the simple process the students use to program the robot in a previous post.)

- Graph shape test. Notice that the two robots do the same actions in the same order, but the timing and speeds are not identical.
- Quantitative test. (The initial picture is the position vs. time graph the group used to program the robot.)

Here’s the quantitative test for a second group

and a comparision of their shape-matching graph and their final quantitative graph.

The full class discussion adhered to the principle of concept first, name afterwards, as the students calculated the slope, found it to be negative, and explained that this meant the robot was going backwards. Only after contrasting this with the speed, which is always positive, was the term *velocity* introduced. In addition, I also had each group run their robot for the class so that the rest of the students could vote on which graph from the set below matched the observed motion. This generated several productive discussions about how to tell which graph shape matched which motion. Students were also sharpening their observation skills in a way that just doing a textbook exercise and describing the motion in words cannot do.

**Task 2: Position vs. Time Graph to Velocity vs. Time Graph
(introducing the velocity vs. time graph)**

When their graphs didn’t match, the conversation about how to fix it was never confined to language about the graphs, as in “When this graph has a slope, this graph is horizontal.” Even their graph-matching mistakes generated further discussion about how the graph related to the observed motion.

I instructed students to program one of their robots with a complicated 4-segment motion using a position vs. time graph. Their task was to program their second robot using a velocity vs. time graph so that its motion would exactly match the first. Once again, I suggested matching the graph shape first, although most groups calculated the slopes of their position vs. time graph first and used that information to help construct the velocity vs. time graph. Here are graphs and video documenting one group’s problem-solving process.

- This graph shows the position vs. time graph the group created for their first robot.
- The thumbnail of the video below is the velocity vs. time graph the students used to program the robot. The video compares the resulting motion of the two robots. Notice that the first segment of the velocity vs. time graph slants upwards, making it a copy of the position vs. time graph. In fact, the entire velocity graph is a copy of the position vs. time graph with the exception of the second segment, where the students realized that the velocity must be zero if the robot is not moving. The students were surprised that copying the graph did not lead to matched movements. It is my hope that this experience will serve as an anchor helping to rid them of the graph-copying misconception, which in past years I have found to persistently linger for most of the year for many students.
- Here, the student’s were just testing the first segment. Their idea was to try a downward-sloping line, since the upward-sloping one did not work. The thumbnail below shows the velocity graph, and the video shows the resulting motion. They noticed that the upward-sloping line made the robot speed up and the downward-sloping line made it slow down. This led to an examination of how graphing velocity was different than graphing position and finally to the correct graph and test.
- This group was able to get to the correct idea themselves by generating and testing hypotheses and discussing with each other, so I did not have to talk to them much after the successful test, as they had all been involved. I witnessed the tests, but did not otherwise offer suggestions or guide them through the process. With other groups, one individual would make more of the intellectual leaps or do more of the work and I had to make sure that all the group members understood why the segments on the velocity graph had to be horizontal. There were also one or two groups that needed a lot more guidance from me. I’ll write more on these groups in another blog post.

This process was a typical of the stages every group had to go through before finally figuring things out, although one or two were able to discard slanted segments in favor of horizontal ones without first doing a test, and most groups did not have to test both upward and downward sloping lines before reaching the correct conclusion.

**Task 3: Velocity vs. Time to Position vs. Time
(introducing area under the curve)**

I would not have dared give students this varied and complex of a set of graphs as homework in previous years. They would have found it overwhelming. In this context, it was a straightforward exercise.

This time, students programmed their first robot with a complicated four-segment velocity vs. time graph, and then had to program their second robot with a position vs. time graph. Since they already had some experience with both graphs, the problem-solving process was smoother. Here’s one example.

- The velocity vs. time graph GUI does not allow students to send a graph to the robot if it contains a vertical segment. The students must make these segments almost, but not quite vertical. This led to some practical discussions of what this meant. In homework problems, the segments are usually drawn completely vertically, which is confusing to some students because it is physically impossible. By introducing the velocity vs. time graph with the GUI and robot, this issue was cleared up for everyone right from the start. Here’s the velocity vs. time graph one group sent to their first robot.
- At the end of this video, the students explain how they matched all but the last segment on their first try. (The thumbnail is the position vs. time graph that they sent to the robot.)
- And on their second attempt, they nailed it.
- The students had already worked out the calculation with units on their board. In full class discussion, we identified the result as change in position and not distance or position by looking at all four segments. To introduce area under the curve, it was only necessary to identify the area with the calculation they had already done and (hopefully) already understood.

Here’s a second example. This group ran into another issue along the way, but pretty much resolved it themselves.

- Velocity graph for first robot. Notice in segments 2 and 3 that this robot will go slow, then fast.
- The thumbnail for the video below is the position vs. time graph this group sent to their second robot. I knew from their graph what would happen, but didn’t say anything. I didn’t have to. When the students saw the robot go fast, then slow in segments 2 and 3, they commented “It’s opposite.”
- And sure enough, they were then able to correct the issue themselves with no intervention from me.

To conclude the full class discussion, I had the students draw the shape of all of their velocity vs. time graphs from the previous two practicums on the main board. Each group then went up to the front of the room and picked a student from the class to describe the motion that went with each of their graphs. Most of the students selected could explain the motion, although in one case a student was caught who could not explain the motion due to a fixation on the vertical rather than the horizontal segments on the graph. He was willing to actually go to the front of the room so he could point to different parts of the graph as he tried to explain it. The class was able to help him out. I’m not sure he understood completely by the end, but he had made progress. I suspect in this case that the student had been too passive during the group work (or else his lab partner had been too active and come up with all the answers without letting him participate). I was going to intervene with this group by discussing the issues, but one of the students was absent the next day for a sporting event, and that led to a more natural reshuffling of groups, which will hopefully resolve the issue. I plan to keep watching both students now.

“If it’s above the line it’s going forwards. If it’s below the line it’s going backwards. If it’s on the axis, then it’s at rest.” Nice!

In another section, a student was more open about not understanding the graphs, so the class helped her through in a more cooperative manner, resulting at one point in the terse explanation, “If it’s above the line it’s going forwards. If it’s below the line it’s going backwards. If it’s on the axis, then it’s at rest.” Nice!

Here is the set of graphs from one class. I would not have dared give students this varied and complex of a set of graphs as homework in previous years. They would have found it overwhelming. In this context, it was a straightforward exercise.**Conclusions**

Last March, the idea to use programmable robots in my physics class was just a glimmer of an idea, and I was not at all sure that I could pull it off.

Last March, the idea to use programmable robots in my physics class was just a glimmer of an idea, and I was not at all sure that I could pull it off. It took a great deal of work, and I have to say I’m pleased with the results so far. All of the class activity to date have been labs or lab practicums with the robots. The students haven’t encountered a single programming bug that I can recall. This alone is amazing for such a complex programming project, and unprecedented in my experience.

Since the robots are able to perform even the most complex motions that students previously encountered in written work, all of these exercises can now be translated into the lab. I did not expect the robots to be working so well that I would choose to use them entirely, but each step of the way it was obvious how they could be put to use.

One goal was to enable students to work more independently, generating and testing their own hypotheses, and checking their understanding themselves in the lab, rather than have me grade or check exercises. The robots have definitely enabled this to happen. I plan to turn them loose even more now that they are comfortable working with them. Using my graphical user interfaces, the robots can only perform step-function constant acceleration motions. This sets limits on the motions the students can investigate. Within these boundaries, they are safe to explore independently and test their own ideas. The robots are thus the first step in creating a physics microcosm.

In past years, students worked problems similar to these lab practical tasks on whiteboards in class or for homework, but by programming and observing the robots students forged a stronger connection between an observed motion and its graphical representation. In addition, the breakdown of the task into graph shape and quantitative parts was something I was trying for the first time this year. In past years, I had observed students, especially those with a weaker mathematical background, coping with this or similar tasks by mechanically performing microscopic second-by-second calculations. They would construct the graph point by point, but never elevate their understanding to see a graph as a whole and understand the motion. The standards by which student’s would be graded on the upcoming quiz mirrored the instructions for the task. One standard is qualitative and involves matching motion and graph shape. The second standard is quantitative and involves finding the slopes and areas.

]]>“So we should just play with this, then!”

This summer, I reprogrammed the Scribbler 2 Robot from Parallax Corporation to be a physics apparatus. (I intend the robot project itself to be the subject of a future blog post.) This lab practicum is the student’s first opportunity to program a robot themselves. **Each group is given two robots, one programmed in advance by me that students studied in their first robot lab, and a second one which they must program themselves through a position vs. time graphical user interface.** Students must understand how a position vs. time graph describes motion in order to get the robot to complete the assigned task.

Having limited prior background, students typically decide to graph distance and time and calculate speed when asked what they can change and measure to describe the robot’s motion. So this is what happens in robot lab 1. The purpose of this second lab is to present the students a task that requires the more sophisticated concept of position. Following the precept, “idea first name afterwards,” which modeling instruction adopted from the research of Arnold Arons, students draw a position vs. time graph because a distance vs. time graph is inadequately descriptive of the situation, then compare and contrast their new representation to the distance vs. time graph. Only when students can clearly articulate these differences does the instructor provide the name *position* to describe the new concept.

In robot lab 1, students created a distance vs. time graph by measuring the robot’s motion and graphing the individual points. The Position vs. Time Graphical User Interface (PvsTGUI) allows the students to do the same thing in reverse, to draw a position vs. time graph on their computer and send it to a robot, which will then perform the motion described by the graph. The screen shot below shows the GUI. To operate it, students grab a line segment from the blue bar at the top and drag it onto the graph. By grabbing and dragging, they can move the endpoints of the segment to a different location. Clicking on the robot icon in the upper right corner sends the program to a robot, if one is attached to the computer through a USB port. The PvsTGUI allows multiple segments of motion and parabolic curved segments, but these features are unnecessary for the task at hand, so I just demonstrate the basics at this time.

It’s implicit in the activity that you can use physics knowledge to manipulate your environment by controlling a robot. No heavy handed discussion about “real world applications” necessary. The students are doing it themselves from day 3 of their physics class.

I demonstrated the PvsTGUI to individual groups as they completed robot lab 1. In every group, at least one student commented, “cool!” and one student said, “So we should just play with this, then!” Getting the robot to perform to their own commands – with ease – trumped the disparaging initial reaction about the slow speed of the robots. Now the robots were cool, and this engagement was one of the goals of the project. It’s implicit in the activity that you can use physics knowledge to manipulate your environment by controlling a robot. No heavy handed discussion about “real world applications” necessary. The students are doing it themselves from day 3 of their physics class.

The task was to program a second robot so that it had a head start of 60cm but reached the same finish line at the same time as their first robot, then to display the motion of both robots on a single “distance vs. time” graph, so that the head start, the speeds, and the fact that they reached the same finish at the same time was clearly visible on the graph. Although I used the words “distance vs. time” in my instructions to the students – because that’s the only graph of motion they have so far encountered – the quotes are there to emphasize they will really be drawing a position vs. time graph. The new name will not be introduced until the post lab discussion.

Once students successfully programmed their robot and tested the result, every group correctly showed a 60cm y-intercept for the line representing robot 2’s motion. It took some pointed questions from me, however, for any of these groups to recognize that their robot could not have traveled a *distance* of 60cm in 0 seconds. This, as well as examination of additonal points as necessary served to make them realize that their graph’s y-axis label of “distance” was inaccurate. I asked them to write a sentence on their whiteboards explaining what their graph *did* show, getting various descriptions generally stating “where the robot is at, not how far it traveled,” as well as the word “location” and in one case “position,” the correct technical term.

Once the class discussion indicated that this meaning had penetrated to a majority of the students, I finally introduced the word “position,” asking them to change the label on the y-axis of their graph and also to draw what the distance vs. time graph would look like. Comparing the information it was possible to read off of the two graphs below clearly showed the students why physicists prefer the more informative position vs. time graph. A good followup question involved asking students to show how the distance showed up on their position vs. time graphs.

I was pleased with this as an introduction to position. The head start task was less complicated than the the task I had given students in previous years, which involved a slow buggy and a fast buggy moving in opposite directions from opposite ends of a track. Because I wanted students to develop the concept of position from the buggy task, my instructions became complicated and convoluted. I could not figure out how to make them simpler without giving away the answer. By contrast, I was able to provide simple, straightforward instructions for the head start robot, and students developed the idea of position spontaneously and with much less direction from me. Rather than provide any hints about how to solve the problem, I just had to repeat the instructions that the robots must reach the same end point at the same time, and the graphs on their whiteboards must show not only that, but also the head start.

The students definitely had an easier time figuring out how to complete the robot task, but they still encountered some difficulties along the way. Some groups assumed that their second robot would have to have the same speed as the first, and calculated the appropriate time for it to get to the same end point. Some even correctly graphed the two robots showing that they did not reach the end at the same time. They were still surprised when their actual test failed and the robots did not arrive simultaneously.

One of my goals in developing the robots was to enable the students to check their understanding independently, without the need for a teacher to check or grade their work, so I was pleased with the student’s response to “failing” their first test. They went right back to work trying to figure out the error in their understanding. It was not viewed as a failure, but rather as a sign that they had more work to do. I believe that having your understanding impersonally checked in the lab helps set up a growth mindset, where the students focus on succeeding despite the setback. Reaction to getting an answer marked wrong by a teacher, is more likely to be taken personally as an evaluation of ability, as in, “I’m just not good at this.” (Self-checking materials, an idea borrowed from Montessori, will be the subject of a later blog post.)

Many of the other groups struggled to figure out that the time for the two robots had to be the same, even if they did not suffer from the assumption that the speeds would be equal. I speculate that they had some intuitive feeling that both distance and time would have to be different in order for speed to be different. To back this up, I overheard many discussions about the appropriate distance and time for the second robot, and whether these choices would make the second robot faster or slower. Even when they generally knew it would have to be slower, they still had to work through the idea that a shorter distance with the same time would make the speed slower, but a shorter time would actually make the speed faster.

None of these productive and revealing discussions occurred in previous years with the buggies, because the speed of the second buggy was set, and the students did not have to determine it themselves. The more I can give students a task to work on independently the more I am able to learn by listening in to their discussions. Had I just told students about the concept of position, I would never had imagined the number of different issues the students would have to think through in order to really get it.

For example, I’m sure that in my pre-modeling days, I just assumed that students could see the equation speed = distance/time as a relationship among dynamic quantities, perceiving how one would increase or decrease due to changes in another. In fact, I depended on this background understanding as a lever to help them understand the bigger picture. Those many students who were lacking this background could not have hoped to understand my lecture and instead would have fallen back on mechanically plugging numbers into the equation as a survival strategy.

Because I was able to direct the students less and listen more, the robot lab revealed several more dimensions to the concepts of position and speed. The robot-head-start task has given many of my students a head start in conceptual development compared to previous years.

]]>Just the simple ability to program the robots with a range of clearly distinct speeds was a productive supplement to the traditional buggy lab.

In physics modeling instruction, the constant velocity particle model begins with a paradigm investigation of the motion of constant-speed buggies. This summer, I reprogrammed the Scribbler 2 Robot from Parallax Corporation to be a physics apparatus , and this was my first chance to use them. (I intend the robot project itself to be the subject of a future blog post.) **For the robot lab, I programmed the robots to have speeds from 10cm/s to 18.5cm/s, but all to go 150cm before stopping.**

When students did the lab, I got a variety of responses. Some groups graphed distance on the y-axis, and others on the x-axis. Some groups used inches, others used cm or feet. One group even did a conversion to km/h.

Groups made a variety of mistakes constructing data tables, setting not-so-even scales for their axes, etc. This collection of responses and mistakes provided a fertile ground for discussion of some important issues, as described well elsewhere (John Burk at Quantum Progress: Buggy Lab, mid teaching analysis and Buggy Lab day 2, first board meeting). Almost all students at this level measure and graph distance vs. time at this point, so the concepts of position and velocity are introduced in the next lab.

When we completed the post-lab discussion of the above issues, more or less as I have done it for years with the buggy lab, I then asked the students to rank the robots from slowest to fastest and to set them on the starting line in that order. This required conversions to a consistent set of units in order to make the comparison, which of course I requested be well-documented on their whiteboards. When they were done, we were able to test their prediction experimentally:

In previous years, I’ve asked students to similarly rank their constant speed buggies, but the buggies do not tend to run in a straight line nor maintain a perfectly constant speed. Their speeds can only be changed by replacing one battery with a metal plug, and slow down significantly as the batteries discharge. And the student’s measuring and graphing abilities typically were not up to the task of distinguishing among members of the one-battery and two-battery clumps of speeds. Experimental verification of a buggy speed ranking was never convincing, so I stopped doing it.

Thinking it would be an easy task, I followed up by asking the whole class to show all five robots on a single graph at the board in front of the room. First, they had to discuss and decide on a standard, i.e. whether to put distance or time on the x-axis. Then they started laboriously plotting individual points. After some prompting from me, they realized they could much more quickly graph the correct “shape,” without numbers. This was an important step, as it required viewing and interpreting the graph as a whole rather than just mechanically plotting points.

They pretty quickly figured that all the lines should start at zero, and the lines representing the faster robots should “be on top” because they “traveled farther in the same time,” resulting in the graph on the left, below. It took a question from me and several minutes of discussion to produce the correct graph at right showing the robots all traveled the same distance. Not such an easy task after all.

Once again, thinking I was posing a simple question to sum up the activity, I asked the students how to tell which robot was faster. When I got back several different answers, including that the one with the longest line was slowest, I had to ask them what it would look like if they all traveled for the *same time*, rather than the same distance. Several minutes of discussion later, they produced the graph below.

Only after producing and discussing the counter-example were they all ready to conclude that they should look at the slope to tell the fastest robot, although I was certain some still harbored the notion that the line that was on top would be the fastest robot, a misconception that would have to wait for the introduction of position to dispel. Once again, not so easy after all. I emphasized that interpreting the shape of a distance vs. time graph, without numbers, was important enough to be one of the standards their work would be graded on, and made sure that at least one student could explain to the class how to tell which line had a greater slope, just by visual inspection.

Initial emotional reaction to the robots was just that they were slow. There are ways to make them faster, and I had anticipated this problem, but development of the programming tools left me no time this summer to further pursue the speed issue. From a teaching perspective, I was very pleased because the post lab discussion was much richer and more spontaneous than previous years’ discussions with the buggy lab. Just the simple ability to program the robots with a range of clearly distinct speeds was a productive supplement to the traditional buggy lab. In subsequent exercises, I noticed the students taking greater care to properly locate the endpoints of their lines in position and time.

]]>a community or other unity that is an epitome of a larger unity (Meriam Webster Dictionary)

I use the word microcosm to refer to a classroom of students acting as scientific investigators to construct and deploy the laws and concepts of physics. The classroom is a microcosm of the larger scientific community.

I also use the word microcosm to refer to the use of technology to create a limited physical world, within which students can explore independently and figure things out for themselves.

]]>