NEW! LEGO eV3 Kinematics work has begun! Here is a link to the latest files.
The Big Idea In 2010-2011, I officially got sick of using those Arbor Scientific Constant Velocity Buggies for teaching kinematics in Physics class. They never went straight and you couldn't predict ahead of time how fast they ran. I was told about LEGO NXT robots and decided these were an excellent possibility for creating a quantitatively accurate car for teaching kinematics. This site contains much of the work I've done in creating programs for LEGO NXTs which make cars move quantitatively accurately. Idea 1: Graphs to Motion
Students can use a customizable app created using Processing to drag out a position vs time graph or a velocity vs time graph. When students press the "Run Car" button, the graph's instructions are sent to an NXT via bluetooth which then moves according to the graph. This idea came from what Matt Greenwolfe has done using Scribbler 2 Robots from Parallax. The apps look like this to the students. Students simply click and move the mouse several times to form a connected line segment graph. Since the line segments are thick, it must be noted that the value of each line segment is based on the bottom of the segment.
Each graph is customizable inside their source programs by editing NXTpositionVsTime.pde and NXTvelocityVsTime.pde. You can change the min and max position and velocity values as well as the min and max time values which will redisplay with evenly spaced values along each axis. You can also change the graph titles and axes titles.
 BLUETOOTH SETUP The most success I have had connecting LEGO NXTs and my MacBook is when I initiate the connection via bluetooth on the NXT by searching bluetooth sources and then connecting to my laptop. The NXT's serial port must be known in order for the app to establish a connection to it. This can be found using bluetooth preferences on your Mac or PC. For a Mac with only one NXT ever connected via bluetooth, the device name will be TTY.NXT-Dev-B. In general, it will be TTY.(NXT name)-Dev-B. You can also use Terminal on a Mac to search the /Dev folder of your Mac once the NXT has already been connected. Look through the device names for "TTY.(something)-Dev-B".
 A text file named "RunCar.txt" is created on the NXT when the "Run Car" button is pressed. This means if the NXT is pre-loaded with the myblock "RunCar", the student simply runs the "RunCar" program on the NXT and it performs the graphed motion.
NOTE: The car design I use allows the car to move with a maximum speed of 40 cm/s. MoveCar is currently programmed to make a loud beeping sound whenever either motor hits power 100 because any data taken will be messed up by either motor hitting the top speed. The graphs, however, are not limited to only physically feasible graphs so you may hear some beeping when doing this with your classes! The Processing App is used to customize the graphs and create your own stand-along app (Mac, PC and Linux) for students to use. Processing version 1.5.1 works on Snow Leopard. I have not attempted this on Lion or later but there is a version 2.2.1. The NXTpositionVsTime Folder and NXTvelocityVsTime Folder are the folders containing the programs which can be run in order to customize graph options (NXTpositionVsTime.pde and NXTvelocityVsTime.pde). RunCar.rbt and RunCar2.rbt is the program you will want to download to the NXT and run each time for this idea.
Students receive an NXT which is preprogrammed to move with constant velocity, constant linear acceleration, or constant angular acceleration depending on the level of the student. The student may input different variables directly to the NXT using the left, right and enter buttons and prompts on the NXT display. STUDENTS DON'T NEED TO USE COMPUTERS TO DO THIS! This is what the student sees after running the programs MoveCarT.rbt, MoveCarTV.rbt, MoveCarTVA.rbt, MoveCarTVAR.rbt, and MoveCarTAVAAR.rbt (and MoveCarT2.rbt, MoveCarTV2.rbt, MoveCarTVA2.rbt, MoveCarTVAR2.rbt, and MoveCarTAVAAR2.rbt). Each distinct program allows the student to input different run values depending on your teaching objectives. (In the above program names, T = time, V = initial velocity, A = linear acceleration, R = radius of turn, AV = angular velocity (in degrees per second) and AA = angular acceleration (in deg/s2). After all variables are inputted, students run the car and take different measurements of it depending on your learning objectives. For example, if you wanted to have students investigate the relationship between the time a car moves at a constant velocity and the position at which the car ends its motion (the way the Modeling Physics curriculum does it), you could customize the files MoveCarT.rbt or MoveCarT2.rbt by setting the initial velocity of each car to 12 cm/s by changing the initial velocity passed to the MoveCar/MoveCar2 myblock towards the end of the program to 12 (see picture below), and setting the acceleration passed to the MoveCar myblock to 0. The time value does not matter because it is being passed by the variable block data wire to MoveCar.
 These types of lessons work best when the students are given as little information as possible. For example, instead of the marble on a ramp lab used to establish the t2 dependence of a constant acceleration, you could use this same program MoveCarT.rbt passing in 0 to the initial velocity of the car, and choosing an appropriate constant acceleration value which keeps the final velocity of the car less than its upper limit (40 cm/s for the car design I use) for the times the students will be using.
NOTE: The car design I use allows the car to move with a maximum speed of 40 cm/s. MoveCar is currently programmed to make a loud beeping sound whenever either motor hits power 100 because any data taken will be messed up by either motor hitting the top speed. The MoveCar programs, however, are not limited to only physically feasible variable values so you may hear some beeping when doing this with your classes!
Students predict and test where 2 cars would "collide" or occupy the same position at the same time. The students input different variables directly to the NXT cars using the left, right and enter buttons and prompts on the NXT displays. STUDENTS DON'T NEED TO USE COMPUTERS TO DO THIS! This type of activity is typically done after students have learned the mathematical models for motion. Students can demonstrate their understanding of the models by predicting the collision point for catch up from behind or head-on "collisions" involving constant velocity, constant acceleration or both (as in the famous police officer - speeder problem). The instructions for which files should be downloaded to the NXTs are the same as in the Mathematically Modeling Motion section above.
IDEA 4: Graph Matching
Students receive position or velocity vs time graphs which are to be matched with physical motion. The graphs are delivered via the computer program LoggerPro which interfaces with a Vernier motion sensor to graph the physical motion it detects on top of the graph to match. This activity has typically been done using people to move in front of a motion sensor. This means appropriate graphs need to be created for matching NXT motion (max speed is 40 cm/s, the more acceleration the more oscillatory the velocity). In order to facilitate the creation of flexible graphs, I created a Google Sheets Position Matching Template and Velocity Matching Template for quickly generating position or velocity vs time match data which can then be copied and pasted into a LoggerPro position graph matching template file and velocity graph matching template file so that it displays the match graph along with the actual motion graphed over top.    Students will run MoveCarTV.rbt or MoveCarTV2.rbt on the NXT in order to input multiple runs of constant velocity using the NXT buttons, or MoveCarTVA.rbt or MoveCarTVA2.rbt to input multiple runs of constant acceleration using the NXT keys. Care must be taken to press the NXT enter button JUST AFTER the LoggerPro collect button for the motions and graphs to be in sync. You will either need to reverse the signs of all velocities and accelerations or face the NXT away from the motion detector and create a large, flat target on its back to reflect the motion sensor. With newer Go!Motion sensors, you can reverse the positive direction so that when the car moves towards the sensor, it reads positive on the graph and vice versa. TEMPLATEpositionMatchingNXT.cmbl and TEMPLATEvelocityMatchingNXT.cmbl are customizable LoggerPro files that let you copy and paste in match data and automatically generate the match graph, and display the actual motion along with the graph to match.
IDEA 5: (Actual) Collisions - Newton's 3rd Law
Students predict where and when 2 cars would collide head-on. This time, however, the cars are carrying Vernier wireless force sensors and will collide force sensor to force sensor. The students investigate how differences in approach speed and differences in mass affect the force experienced by each during the collision.  This type of activity teaches Newton's 3rd Law in an investigative way. A lab hand out can be given for the activity, or you could come up with the basic outline of the investigation as a class or in lab groups. The beauty of using LEGO products is that LEGOs can be used to create helpful attachments such as the apparatus, created by my colleague Sam Meyers, that holds the wireless force sensors. Vernier wireless force sensors work really well for this because they are wireless, but they are also really expensive. Vernier dual-range force sensors can also work though you're tethered to a laptop. Special thanks to the Science House at the Science Museum of Minnesota for letting Minnesota teachers borrow expensive sensors! LABcarCollisionsN3L.pdf is a short lab hand out my student teacher from the fall of 2013 Eric Dooley and I came up with for this investigation. It certainly can be improved upon! This video summarizes the investigation we used in the fall of 2013 with our students. The experimental process will probably be modified in coming years. UPDATE: I have implemented a better PID solution which uses the percent error of the velocity to calculate the correction instead of the difference in errors. All files marked (filename)2.rbt have the updated method. It performs much better. |
