LearningForward

Kent Chesnut's technology in education blog.

November 22, 2009

Scratch as a Simulation Engine - Part 3

Filed under: Simulation, Scratch — kchesnut @ 10:33 pm

For the 3rd post on using Scratch as a Simulation Engine, I’ll be moving back to a High School classroom example.  The following is a problem from my daughter’s Physics class:

“Crazy Joe Clayton parks his 57 Chevy close to a cliff overlooking the ocean.  The land leading up to the cliff is on an incline of 37 degrees below the horizontal.  Joe runs to meet his sweetheart Thelma, but leaves the Chevy in neutral.  The car begins to roll down the incline with a constant acceleration of 4.0 m/s2 and travels 50.0 m to the edge of the cliff.  The cliff’s edge is 30.0 m above the ocean.

a. Find the time the car is in the air.
b. Find the position of Joe’s car relative to the base of the cliff when it lands in the ocean.”
 

The problem is  a simple 2 dimensional trajectory problem… but with a twist.  Brittany does not have enough of a math background to comfortably view this as a single problem!  For most High School students, the best way to solve the problem is to break it down into 2 pieces; the car accelerating down the slope to the edge of the cliff and the trajectory problem of the car careening into the ocean.  (Actually, maybe everyone would solve the problem as 2 separate steps.  If one were trying to impress someone, however, one could solve for the velocity at the end of the first part of the problem as an equation and substitute the equation into the 2nd part of the problem.  But would anyone really solve the problem this way?  I wonder.)

 Physics problem simulationA screenshot from the Scratch simulation I created for this problem is shown below.  The project can be run here.  The project file can be downloaded here

Reset the simulation by clicking on the green flag.  Run the first part of the problem by clicking on the car.  Run the final part of the simulation by clicking on the car again.

 What’s hard about this problem and simulation?

  • As in most of the simulations I’ve looked at, the actual math is not too complicated.  However, the scaling of the movements of the sprites to match a graphic can be fairly challenging.
  • With the problem broken down into 2 parts that can be readily solved, it is necessary to realize the the starting x and y velocities of the 2nd part of the problem are equal to the ending x and y velocities of the first part of the problem.  This was not intuitive for Brittany.  In fact, she argued pretty forcefully that the starting y velocity of the 2nd part of the problem should equal the ending x velocity of the first part. 

Could a simulation like this be used to help students understand Physics in a High School Physics classroom?  I’ll consider a few possibilities, and my thoughts on them…

  • Assign students to develop a simulation of the problem? - Probably Not!
    Although this would be a very constructivist (or constructionist) activity, I believe that assigning the students to develop a simulation of the problem would probably be too tough for all but the most advanced students.  And the time it took to build the simulation of this one problem would probably be better spent practicing several more problems.
  • Use the simulation as an in-class demonstration?  - I think so!
    The simulation could be used in-class to demonstrate how the problem can be broken down into the 2 separate problems.  Further, it could be used to explain the relationships of the x and y velocities as the 2nd part of the simulation begins.  These relationships may be easier to explain / understand given the simulation.
  • Use the simulation as an in-class demonstration of debugging? - Hm, I’m not sure!
    If you compare the results of the simulation with the results of working the problem by hand, you’ll find that the answers provided by the simulation are not quite right.  These inaccuracies are caused by what I would refer to as quantization limits.  The simulation moves based on a clock tick and the accuracy of the simulation is limited due to this.  An understanding of this phenomenon might be within the scope of a High School Physics class.  However, If I used the simulation as an in-class demonstration as discussed above, I wouldn’t include a discussion of the quantization problem because I think it might interfere with the point of the problem - which is to set up and properly solve the problem.  I might consider discussing quantization and accuracy, however, whenever discussing the accuracy of experiments carried out in class (or in the real world).  In such a discussion, the simulation might make a useful demonstration.

As always, I’d love to hear what readers think of these ideas.  Is the use of Scratch for simulations a useful school activity?

November 13, 2009

Scratch as a Simulation Engine - Part 2

Filed under: Simulation, Scratch — kchesnut @ 10:32 pm

In this post I’ll be considering a fairly complex simulation with Scratch.

Control systems commonly use a control algorithm called the PID Control loop.  The PID stands for Proportional - Integral - Differential.  You can find more information about the PID algorithm here.

A few months ago at work we were putting together a control system that would control the level of fluid in a tank.  Fluid was coming into the tank from various systems, with rates that could change over time.  Fluid was to be pumped from the tank using a pump driven by a Variable Speed Drive (see here if you’re really interested).  As we did not have access to the actual system, but wanted to try to test the control, a colleague had built a simulation of the tank level into our device.  We weren’t really understanding what we were seeing (turned out there was an undesirable feature in the PID algorithm in the software - what most folks refer to as a bug).  In an effort to understand what was going on, I decided to model the overall system.  And I decided to see if Scratch could get the job done.pid.jpg

A screenshot of the project stage is shown on the right.  The blue in the upper left illustrates the fluid level in the tank and is reflected by the TankLevel variable.  The IntakeRate is the rate at which fluid is entering the tank.  The PID MaxOutputRate is the rate fluid is being pumped from the tank when the VSD is running at full speed (100%).

Run the project here.   Click on the green flag and then on the big green dot to start the simulatin.  Note that the fish labeled Ft graphs the tank level and the fish labeled Hz graphs the VSD speed.  Download the project here.

It’s beyond the scope of this post to explain the innards of the simulation.  Suffice it to say that you adjust various start values in the PID sprite to try to match the system you wish to simulate and then run the simulation.  Repeat as necessary to optimize the PID response.  The purpose of the post is to describe what I learned in using Scratch to create a fairly complex simulation.runpid.jpg

  • As you can see from the image at right, the actual PI algorithm is not too complicated.  (I didn’t simulate the D term as we seldom use it and the anomaly we were seeing was evident even when we only had a P term.)
  • The stage size was somewhat limiting.  In a simulation of this nature, you’d typically display a bunch of data.  All the stuff I really needed fit, but didn’t leave much room for any graphics or animations (often referred to as “eye candy” at work).
  • Often one wants to save the simulated data to a file as the simulation progresses.  Scratch doesn’t have this capability.  However, one of the things you typically do with the saved data is to graph it to observe the control response (in this case, Drive Speed) with respect to the feedback variable (in this case, tank level).  Scratch can do the graph.
  • I really liked the little fish building the graph.
  • My coworkers and boss seemed either impressed or somewhat amused that I was using a kids’ program to do a “work” simulation.
  • The speed of the simulation was fine on a 3 year old laptop (1.6GHz Centrino Duo processor).

As always, I appreciate any feedback.  In the next post, we’ll look at another example of a simulation - but this time back to a school problem.

November 8, 2009

Scratch as a Simulation Engine - Part 1

Filed under: Simulation, Constructivism, Scratch — kchesnut @ 10:46 pm

Wow!  It’s been 7 weeks since I posted.  That’s a long gap, even by my lax standards.

 For the next few posts, I’ll be looking at Scratch as a tool for simulating events.  Since my interest in this is mainly education, most of these will be simulating a school problem.

The problem for this simulation came to me as a text message from my daughter Brittany… something like this…

“2 bicycles start 20 km apart and move toward each other at 10 km / hour.  A fly flies  between the bicycles at 30 km/hour until they crash together smashing the fly.  How far does the fly fly?”

The statement of the problem leads one to start drawing lines back and forth between the converging bicycles.  This is the hard way to work the problem.  I responded to Brit’s text with a question… “How long until the bicycles crash together?”  Thinking of the problem this way leads to a very simple solution.

I wondered, however, if there is educational merit to actually seeing the problem unfold in a simulation.  I believe building this simulation would be possible for someone at Brit’s level (High School Senior, good programming skills, taking Physics).  I decided to simulate the problem in Scratch in order to investigate the educational opportunities for a student faced with such a problem. 

Simulation ScreenshotA screenshot of the program is shown to the right.  I substituted cats for the bicycles and a butterfly for the fly for ease (as Scratch came preloaded with those graphics).

Run the project by clicking here (click on the green flag to start the animation).  The project is available here.  Note that Scratch 1.4 or later is needed to open the project.

So what’s difficult about this simulation? 

  • Setting up scaling.
    The cats start 20 KM apart and the Scratch screen has 480 horizontal pixels.  Therefore, I chose to let each KM be 20 pixels. 
  • Setting relative velocities.
    I don’t really care how fast the cats and the butterfly move, but their relative velocities must match those of the problem statement.  I chose to let the cats move toward each other at the variable “Speed” pixels per simulation iteration.  So “Speed” was defined as the speed of the cats.  Since the butterfly moves 3 times as fast as the cats, the butterfly moves 3x”Speed” pixels each iteration.
  • Calculating the actual distance moved.
    The velocities are in pixels / iteration, but the problem needs an answer in kilometers.  The distance moved is simply the butterfly velocity / the number of pixels per KM.

So the simulation is probably doable, but challenging for a High School Physics student with some Scratch experience and reasonable programming skills.  But would the exercise of creating the simulation be a worthwhile educational endeavor?  Reasons I believe the exercise might be worthwhile include:

  •  The simulation provides an method for a student who doesn’t see the easy solution to still solve the problem.  If the simulation included the flight time as a displayed variable, the student may make the connection between the butterfly speed and the time to the collision.  I believe such ”aha!” moments are powerful learning times for students. 
  • The activity certainly falls under the Constructivist category.  As such, student learning may prove deeper and more transferrable than just working the problem.

I’d appreciate reader feedback…

  • Would such a simulation be a worthwhile educational effort? 
  • If so, what benefits to the student do you see from such an effort?

Next time… we’ll look at a fairly complex simulation in Scratch.

Powered by WordPress