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.
Matt, this looks like a great way to use the robots to develop the constant velocity model. Isn’t it enlightening to realize that what we think are very simple concepts are not as simple for our students. Not only did the activity help them develop the CV model but it laid a foundation for questions about what you needed to do to program the robot to do what you wanted….STEM in action!
Matt, I’m confused by your dialogue. Isn’t the line on top the one with the steepest slope? I’m missing the misconception. Even though you have them plot distance instead of position on the vertical, it seems to me that the graph “on top” would still be the fastest since it has the greatest distance value for a given clock reading (third graph). I know I’m missing something…
When I asked the question, I was expecting just one answer, slope, and I figured I would get a quick answer from the students confirming this obvious conclusion from the activity. Instead, they all paused to think, and then I got several different answers, all plausible, but only one of which – slope – is the correct way to judge speed from the distance vs. time graph in general.
These alternative ideas never came up in past years, but like many misconceptions, they were likely lurking among my student’s beliefs causing them difficulty interpreting position vs. time graphs later on. I asked about the graph when the robots all took the same time to create a counter example that ruled out the idea of the length of the line.
Now that I think about it, it is possible to dispel the faster-is-higher misconception without invoking position. A robot that paused at rest for awhile, then continued into motion could be lower on the distance vs. time graph while having a faster speed. I could even program a robot to do that and ask them to draw the graph. That just didn’t occur to me in class.
This brings up a teaching dilemma. It’s tempting to now build these counter-examples into a worksheet or series of lab questions, but my experience is that this is less effective than addressing the questions more naturally, and seemingly spontaneously, when the students ask them. Several years down the road, when I begin to expect these student misconceptiosn to arise, I also find myself falling into the trap of anticipating them too much and creating a more stilted, artificial conversation, which is also less effective.
I imagine there will be an even bigger payoff to using the robots when you get to constant acceleration. With the apparatus we use for that lab it’s hard for students to collect data with the initial velocity nearly zero and the subsequent acceleration is not so constant. Consequently, the relationship between the slope on the v vs t graph and the x vs t^2 graph is not clear. I just wish there were a slightly less expensive robot than Scribbler for this.
I ended up changing my introduction to acceleration entirely because the robots allowed us to use a velocity vs. time graph directly as the introductory activity, but that’s the subject of a future blog post. I do plan to have my students take data for position vs. time and investigate that graph in more detail, but that will be later in the constant acceleration unit. My own trials of the lab do show that position vs. time data from the robots is easier to take and much more convincing.
I spent a long time investigating different options for this project, at one point attempting to build my own robot when I had not yet found one with the right processing power, sensors (specifically including optical wheel encoders of sufficient resolution), programming language and computer interface. Through my own building efforts, I became familiar with what was required and it was much more sophisticated than I had thought when I started. I was pleased to find that the s2 had everything I needed, although it needed a new motor driver to move more precisely. It would be possible to build a cheaper robot just for the physics purposes, as we don’t need a lot of the other functions that are included in the s2. However, that’s development of a whole commercial product, and then there are economies of scale that might prevent the price from being less. So I think the s2 is the best choice for now. I also plan to talk about the development process in more detail in a future blog post.
I was so impressed with these robots and how easy they are to use with Matt’s software that I wrote a grant to try and get two for my classroom. What I really like about the entire hardware/software combo is the ease of use.
The ability to make a graph of motion, and then see it traced out by the robot to such a high level of precision is rather amazing. Going from motion to graphs is done well enough with motion detectors, but going the other way from a graph to the motion is something I have not been able to pull off with any level of precision. This robot and software allows that to happen, and I think that can be very powerful in teaching motion.
And the price is very reasonable. My grant is with a local funding agency for my school district. But if that falls through I could easily see this being funded next year by school funds. Not that I want to wait that long.
I’m re-reading your blog posts and just wanted to say that I think this is super interesting. I really like that you can precisely program the robots speed, and either run distance or time, which allows students to construct graphs that are far more specific and show much more understanding than the typical buggy labs.
Blogs about accelerated motion coming soon, including the cop-speeder problem as a lab practicum.
Can you provide information on how you set up the software with the graphing interface to program the robots? I would like to do something similar with the new robotics class at our school. I am not sure what kit their robots come from at this point. Thanks.
I don’t mean to be discouraging, but among all the common educational robots and kits out there, the scribbler II was the only one I could find that came with the required processing power, hardware (very accurate wheel encoders), and access to assembly language programming to work for this project.
Most of the educational robots are programmable only with a simplified higher-level language and are designed to accomplish autonomous tasks in a reasonable time, but they don’t care whether the velocity was precisely 15.1cm/s or whether the acceleration was even constant. So long as it follows the maze, avoids obstacles or whatever else you want it to do, and does it in a reasonable time, then its accomplished its goal.
It was an effort of several months of more than full time work for me to re-program the scribbler II to be a physics apparatus, starting with rewriting the motor driver using assembly language and ending with writing the GUI’s and linking them to the robot’s processor.
Don’t get me wrong about these other educational robotics programs. They are terrific and provide students with engineering experience and authentic problem-solving practice and are highly motivating. I love them. But most just aren’t intended to be used for this purpose as well.
I really need to write that long-delayed blog post about the project itself so you and others will have a reference for what is required. If your robotics class has Scribbler II’s or purchases some, and you have PC’s with a recent version of windows, I will be glad to help you set up my software. Unfortunately, that’s the only system I’ve got at the moment.
This looks awesome (all your posts about the robots, not just this one)! Thank you for sharing what you did. Now that I’m convinced this would greatly benefit my students I’m thinking I’m going to write a grant to get my hands on several of these robots. With that being said, I’m wondering about additional hardware/software/parts that you needed to make these robots “physics apparatus.” Is there additional stuff I should include in my proposed budget? If so what? Do you use the Serial port only, or did you get the USB adaptor? Does it matter?
I also see that you have plans for a blog post about the project, so that would probably answer some of these questions, but how difficult is the programming? I’m not even an novice programmer, so would I be “out of my league” to attempt to make this work for me? Have you had your students do any of the programming or is that your job? If you do have students do it, how hard is it to teach that?
Any reply or insights you could give would be greatly appreciated. Thank you for your time.
Thanks for the support! I answered most of your questions, I think, when replying to another post here, but the short answer is that you and your students don’t have to do any programming, just install my software (on recent versions of windows only at the time being), draw a graph and click on the robot icon to send it to a robot.
That is great. Thank you so much for your quick reply. I’m excited to hear you are willing to sell your software as well. I will be writing up a grant and see what that gets me. I’ll be in touch. Thanks again!
I LOVE this idea! I’ve been doing the Buggy Lab for a couple years and I’m really excited about implementing your version. I’ll be writing a grant soon to get some robots. Thank you so much for sharing. Keep the ideas coming!!
You’re one of several teachers who have now purchased some scribbler II’s to try this out. I can’t wait to start hearing back nonce people start using them and come up with their own ideas. Let me know when you need the software. I recently made some changes. You can now delete the last segment, save a file and re-open it. These were some of the most requested features. I’m getting to work soon on improving the accuracy of the GUI’s graphical readout and allowing you to type in exact values for the end points.
Pingback: Modeling and Robots—on a Mac! | Quantum Progress
Pingback: Robots in physics | Gas station without pumps