Same Skills, Virtual Car: Constant Velocity Particle Model

I had everything in line to start the constant velocity model unit: stop watches, meter sticks, measuring tape. All I had to do was find the set of working battery operated cars that I had used last year. I found one of them right where I left it. Upon finding another one, I remembered that didn't work last year either, and I hadn't gotten a replacement. The two other cars were LEGO robot cars that I had built specifically for this task, and all I would need would be to build those cars, program them to run their motors forward, and I was ready to go.

Then I remembered that my computer had been swapped for a new model over the summer, so my old LEGO programming applications were gone. Install software nowhere to be found, I went to the next option: buying new ones.

I made my way to a couple stores that sold toys and had sold me one of the cars from last year. They only had remote control ones, and I didn't want to add the variable of taping the controllers to the on position so they would run forward. Having a bunch of remote control cars in class is a recipe for distraction. In a last ditch effort to try to improve the one working car that I had, I ended up snapping the transmission off of the motor. I needed another option.

John Burk's post about using some programming in this lab and ending it in a virtual race had me thinking how to address the hole I had dug myself into. I have learned that the challenge of running the Python IDE on a class of laptops in various states of OSX make it tricky to have students use Visual Python or even the regular Python environment.

I have come to embrace the browser as the easiest portal for having students view and manipulate the results of a program for the purposes of modeling. Using Javascript, the Raphael drawing framework, Camtasia, and a bit of hurried coding, I was able to put together the following materials:
Screen Shot 2013-08-25 at 3.19.57 PM
Car 1 Part 1
Car-2-Model-
Constant Velocity model data generator (HTML)

When it came to actually running the class, I asked students to generate a table of time (in seconds) and position data (in meters) for the car from the video. The goal was to be able to figure out when the car would reach the white line. I found the following:

  • Students were using a number of different measuring tools to make their measurements. Some used rulers in centimeters or inches, others created their own ruler in units of car lengths. The fact that they were measuring a virtual car rather than a real one made no difference in terms of the modeling process of deciding what to measure, and then measuring it.
  • Students asked for the length of the car almost immediately. They realized that the scale was important, possibly as a consequence of some of the work we did with units during the preceding class.
  • By the time it came to start generating position data, we had a realization about the difficulty arising from groups lacking a common origin. Students tended to agree on velocity as was expected, but their inability This was especially the case when groups were transitioning to the data from Car 2.
  • Some students saw the benefit of a linear regression immediately when they worked with the constant velocity model data generator. They saw that they could use the information from their regression in the initial values for position, time, and velocity. I didn't have to say a thing here - they figured it out without requiring a bland introduction to the algebraic model in the beginning.
  • I gave students the freedom to sketch a graph of their work on a whiteboard, on paper, or using Geogebra. Some liked different tools. Our conversation about the details afterwards was the same.

I wish I had working cars for all of the groups, but that's water under the bridge. I've grown to appreciate the flexibility that computer programming has in providing full control over different aspects of a simulation. It would be really easy to generate and assign each group a different virtual car, have them analyze it, and then discuss among themselves who would win in a race. Then I hit play and we watch it happen. This does get away from some of the messiness inherent in real objects that don't drive straight, or slow down as the batteries die, but I don't think this is the end of the world when we are getting started. Ignoring that messiness forever would be a problem, but providing a simple atmosphere for starting exploration of modeling as a philosophy doesn't seem to be a bad way to introduce the concept.

One thought on “Same Skills, Virtual Car: Constant Velocity Particle Model

  1. Hi Evan:
    1) I commend you on thinking quickly on your feet to solve the problems you had to face. I hope you shared this experience with your students so that they realize that life does not come ready for us in a golden platter; rather we must face its challenges with whatever multitude of skills and doggedness we have. Kudos!

    2) For motion modeling, I use the students themselves to add kinesthetic fun to the whole experience. I split the students onto 4 groups with one group being the timers. The challenge of the three motion groups is to execute a relay (without watches of their own) in such a way that the end result will be a model of specs I give them ahead of time. That's it, I do not give any further instructions beyond this. The results get entered, reviewed, compared, and the fun is indescribable. Low tech but still cool modeling with humans themselves "feeling" the motion and the Physix.

    3) So, keep the human element as an option for it may work too.

    Thank you and take great care! 🙂

Leave a Reply