Tag Archives: American Modeling Teachers Association

Building The Central Force Model

From Lines To Angles, and Particles To Rigid Bodies

We dove straight into circular motion with the 2nd year students this past week. The primary focus of last year was linear dynamics and although we did study objects that moved along curved paths (projectiles), we were still looking at two-dimensional motion as being composed of two component motions along straight lines.

In the second year program, a good part of the first semester is dedicated to looking at objects that rotate around a central axis. There are two major shifts that will be introduced. The first is the introduction of an entirely new coordinate system – polar coordinates. The students spent most of last year learning about two dimensional vectors in Euclidean space, but this year, we will see that for objects traveling in various curved paths, a polar coordinate space can actually be much easier work with. The other shift will introduce students to collections of particles composed into continuous rigid bodies. This requires some significant changes in how the students view an object’s orientation in space and how an object’s mass is distributed. No longer can we assume that the object’s mass is located at a single point in space. In both cases, we are adding to the complexity of our conception of the universe by adding new representations of both space and the objects that inhabit that space.

Observing Circular Motion

In the modeling pedagogy, a new concept or collection of concepts is introduced using a paradigm lab. These labs are meant to introduce students to a new phenomenon and to be the launching off point of the actual building of a conceptual model.

Using the video analysis and vector visualization tools of LoggerPro, I had the students track the motion of a Styrofoam “puck” that was placed on our air hockey table (yes, we actually have an air hockey table that was donated to the school!) but was also attached to a thin thread to a fixed point on the table. The students used the video to track the motion of the puck as it essentially traveled in a circular path.

Although the lab is a bit tricky to set up, the ability to not only track the position of the object in two dimensions, but also the ability to attach velocity and acceleration vectors to the object is really helpful in engaging students in a great conversation around why the acceleration vector points to the inside of the circle. It also allows us to discover a whole new set of mathematical functions for describing motion. After tracking the position of the puck, we are ready for a class white board discussion.

The Graph Matching Mistake Game

I ask the students to draw the motion map of the puck’s motion in two dimensions including the velocity and acceleration vectors. I then ask them to include the graphs created by LoggerPro. LoggerPro produces a really interesting position vs. time graph in both the x and y dimensions. At this point the class knows the drill, and they use the mathematical function matching tool in LoggerPro to match the graph. I ask the students to include on their whiteboards the function that they think best fits the plotted data. This is where it gets really interesting.

IMG_1223

Notice in the above photo that the students used a polynomial function. I then ask the students to use Desmos to plot their graphs. Then I ask them to zoom out on the graph.

iozt61kwui

This is where they discover how this function can’t explain the position vs time data for an object that continually repeats the same path. Some of the students in the class recognize that the data is better explained using a sine function. Because not all the students have been introduced to this function, it presents an opportunity for some students to teach the other students about how these functions work.

IMG_7065

I allow the students to explore the sine function in Desmos, asking them to change the coefficients of the function in order to discover how these coefficients affect the graph.

zukr7fdnxr

The next step is to investigate more thoroughly the relationship between the acceleration and the velocity, as well as introduce the benefits of using polar coordinates to describe how an object’s position changes when you are dealing with an object that is traveling in a circular path. Desmos has the ability to change the graph type from the x,y coordinate plate to a polar representation. We discuss the difficulty of representing an object’s circular path using x(t) and y(t) functions as opposed to r(t) and theta(t) because r(t) is just a constant.

Next up, trying to answer the question: “If it’s accelerating inward, then why isn’t it speeding up towards the inside of the circle?!” Once again, the difficult concept of inertia…

Building the Electrical Current Model with The Amazing $25 Programmable Power Supply

Not Just For Teaching Robotics

Thanks to the generous donations of supporters of the Physics Academy, we were able to purchase a new set of Arduino Uno micro-controllers for use in this year’s robotics competition. As I was planning out the unit on teaching DC circuits, I realized that some of our DC power supplies might need to be replaced. I got to thinking – could the Arduino replace these hulking, expensive power supplies?

product.exps._hero.001.590.332

The answer has been (with one caveat) – yes. The above power supplies are nice, no doubt about it, but they are big, costly ($199) and they are not as nearly as extensible as a micro-controller.

Arduino_Uno_-_R3

The Arduino micro-controller can act as a fixed 5V power supply, or using its PWM pins, you can vary the voltage from 0V to 5V with a resolution of about 20 mV. The other advantage about using the Arduino is that it gives you a chance to teach a little bit of programming too! In our case, it allows for a great introduction to robotics well before we are ready to start our unit on robotics.

The one disadvantage is that you can’t test any circuits that need over 5V of electrical potential difference, nor can you test things like motors or other higher current (> 40 mA) circuits. We didn’t find this to be a big problem, but if you do, you can actually purchase a shield (an attachment that fits on top of the Arduino) from Adafruit Industries that allows you to use a higher voltage, higher current power supply that is controllable through the Arduino.

Mapping Electrical Potential (Voltage)

One of the first activities that the students do, which is a great activity from the AMTA curriculum repository, is to have the students “map” the voltage between two metal bars that are partially submerged in water.

IMG_1870

Using the Arduino as the power supply, the students use a multimeter to check the voltage at specific locations on a grid that is placed under the transparent pan holding the water. These numbers are recorded into a spreadsheet. Excel has a great tool for doing a 3D map of the values.

potentialmap

What results is a really nice visualization of the potential isolines and the spacial variance of the voltage, and thus the electrical field.

Ohm’s Law – A Flow Model

We then move from voltage maps to flow model. The students investigate how voltage, current and resistance are related to one another. The students begin by investigating the current flowing into and out of a resistor, and most are surprised to find that the current in the same flowing into a resistor as it is flowing out. They expect that current should be “used up” by the resistor – causing a bulb to glow for example. When they find that this is not the case, they either think that they have done the experiment incorrectly or that perhaps the multimeter is not precise enough. This confusion comes from the idea that they are expecting current and energy to be equivalent.

IMG_1918

The hydrology analogy is introduced as a possible model for describing this phenomenon. We discuss the movement of water past a water wheel, and how the water flowing into the wheel is equal to the amount of water flowing “out” from the wheel. Students quickly realize that the wheel still turns, not because the water is “used up”, but because the water looses energy.

The final challenge for the students is to confront the oddity that is parallel circuits. This is made a bit easier by thinking about the flow model, but the confusion with parallel circuits stems from the idea that a battery is a constant current supplier – which of course it is not. The Arduino, just like a battery, will increase the amount of current flowing from its digital output pins when more pathways are added for the current to flow. This is where I would be careful to make sure however that you don’t approach the 40 mA limit. If you do, you can get some weird results in your observations as the Arduino will naturally cut off current draws around this range to protect its electronics.

Conclusion

The switch to the Arduino has been quite successful, and as stated before, it launches the students into the robotics project with a knowledge that the Arduino is simply a controllable power supply. They learn very quickly from that point on that the Arduino can also act like a voltmeter too! Using its analog input and switching the digital pins to be input pins, the Arduino can also mimic the functionality of a multimeter. If you are considering new power supplies, I would recommend looking into this as an option.

Investigating The Projectile Particle Model

The Class Designs The Deployment Experiment

The video above shows the recent deployment activity where students predicted the vertical position of a projectile (a Hot Wheels car) as it traversed a known horizontal distance. The student predictions are identified by green sticky notes on the the left hand side.

The students first had to work out the problem on their own whiteboards before being given the sticky note that indicated the vertical position as measured above or below the red line. Most groups calculated the same position with two groups noting a sightly different prediction!

In this deployment, I set up the ramp, and told them that they had a photogate sensor at their disposal. They had to design the experimental procedure. A great discussion followed, and the class was quite successful as you can see (the students who had the significantly different prediction were able to hunt down their mistake – so everyone felt that the model “worked”).

Analyzing Projectile Motion in Video and Code

Prior to the deployment, students were asked to use a video camera to record the motion of a projectile. This is a great experiment to do with LoggerPro or some other video analysis tools that allow the students to track the position of the ball or some other projectile.

The students have also been learning how to simulate constant velocity and constant acceleration particle motion in Processing. We extended this to now include projectile motion, and the students analyzed simulated projectiles and compared the data gathered in the real universe to that gathered in the virtual universe. I will be writing about this process in more detail soon.

Simulating Planetary Motion (Using Code!)

Simulating Newton’s Law of Universal Law of Gravity

Interactive simulations (like those created by the University of Colorado – PhET) can be really nice for impressing students, and giving them a way to explore the dynamics of a simulation. If incorporated into a lesson well, they can add to the active learning process. The question that I always struggle with though is “are the students learning how the simulation works, or are they learning how nature works?”

I have a nagging feeling that the students would possibly get more out of being able to see the simulation source code, specifically the rules of behavior of the simulation, and then through “tweaking” the code, see how those rules govern behavior. I would like to develop curriculum that would allow my students more opportunities to explore the code “behind” the simulations. This presents a few challenges that have been identified by other great physics educators, and if you are thinking about doing the same thing – I would suggest reviewing their insights. I include a quote from Ruth Chabay’s brief, but very interesting article on this topic:

To integrate computation, especially programming, into an introductory course, it is necessary to minimize the amount of non-physics related material that must be taught. To do so it is necessary to teach a minimal subset of programming constructs; employ an environment and language that are easy to learn and use; ensure that program constructs match key physics constructs; provide a structured set of scaffolded activities that introduce students to programming in the con- text of solving physics problems

This was my first attempt at doing just this, and I had some success and realized that I have some work to do.

Which Code?

A popular programming language in the Physics Modeling community is VPython. I have chosen to use a different language to use called Processing. There are reasons I chose this language, but I am sure there are reasons one would choose VPython (or other languages). At this point, I have not had the opportunity to work with VPython, so this post will not attempt to compare Processing to other languages. Perhaps I will do so in the future…

Here are some general reasons why I like Processing:

  1. It’s free and open source.
  2. Because its built on a visual programming interface, its really easy for the students to create visual content on the screen, and it is very easy to create visual animations due to the embedded “draw” loop.
  3. The official website has great examples and tutorials. It is full of great code samples and quick tutorials. You can loose yourself for hours (or days!) just having fun exploring the examples and tutorials.
  4. The IDE is simple and very similar to the Arduino IDE, so if you plan on doing any Arduino programming, the similarity is nice for the students.
  5. There is a nice vector library for doing vector operations (.add, .mult, .norm, .dot, etc.)
  6. Its object oriented so that you can have the added benefit of teaching important programming concepts – though this might be why some people might not like it.

The Simulation

The simulation that the students were introduced to was a simulation that modeled Newton’s Law of Universal Gravitation. The students were given some instructions on the basic structure of the program, and I made sure that there was some guiding comments embedded in the code. This program was inspired/adapted from a similar program created by Daniel Shiffman who has also written an amazing book on simulating nature through code called Nature of Code.

The program defines two classes. First, there is the parent class called Particle. This class defines some basic attributes like location, velocity and acceleration as well as mass. It also has some basic functions that allow it to move and allow it to respond to a force. The second class is the child class called Planet. It can do everything that a Particle can (because it inherits from the Particle class), but it can also exert an attractive force on other Planets.  Here is the code below:

/* A parent class for all moving particles
class Particle {
  PVector location;
  PVector velocity;
  PVector acceleration;
  float mass;

  Particle(float x, float y, float m) {
    mass = m;
    location = new PVector(x, y);
    velocity = new PVector(0, 0);
    acceleration = new PVector(0, 0);
  }
  
  void applyForce(PVector force) {
    // Newton’s second law at its simplest.
    PVector f = PVector.div(force,mass);
    acceleration.add(f);
  }

  void move() {
    velocity.add(acceleration);
    location.add(velocity);
    acceleration.mult(0);
  }
}

/** 
 This class defines an object that behaves like a planet.
 Planet objects extend Mover objects, so they can move. They
 also can attract other planet objects.
 **/
   
class Planet extends Particle {

  float size;
  float G = 1;

  // To create a planet, you need to supply coordinates, mass, and size
  Planet(float x, float y, float m, float s) {
    super(x, y, m);
    size = s;
  }

  // This function allows a planet to exert an attractive force on another planet.
  PVector attract(Planet p) {

    // We first have to figure out the direction of the force
    // This creates a unit vector for the direction
    PVector force = PVector.sub(this.location, p.location);
    float distance = force.mag();
    distance = constrain(distance,size + p.size,500);
    force.normalize();

    // This is where we use Newton's Law of Universal Gravitation!
    // The stength of the attraction force is proportional to the
    // product of the mass of this planet and the mass of the other planet
    // as well as the value of G. It is also inverseley proportional to
    // the distance squared.
    float strength = (G * mass * p.mass) / (distance * distance);
    
    // To get the final force vector, we need to 
    // multiply the unit vector by the scalar strength
    force.mult(strength);

    // Return the force so that it can be applied!
    return force;
  }
  
  // Just displays the planet as a circle (ellipse)
  void display() {
    stroke(255);
    fill(255, 100);
    ellipse(location.x, location.y, size/2, size/2);
  }
  
}


/** 
  This program simulates the gravitational interaction between planet objects
  **/
  
Planet planet1;
Planet planet2;

void setup() {
  background(0);
  size(800,800);
  // Inputs for each planet:
  // (x, y, mass, radius)
  planet1 = new Planet(width/2,height/4,6000,60);
  planet2 = new Planet(width/2,height/1.25,6000,60);
  
  // This is where you can change the initial velocities of the planets.
  planet1.velocity.x = 0;
  planet1.velocity.y = 0;
  planet2.velocity.x = 0;
  planet2.velocity.y = 0;
}

void draw() {
  background(0);
  
  // f1 is a force vector that is created by calling the planet's attract function
  PVector f1 = planet1.attract(planet2); 
  // Now apply that force on the other planet.
  planet2.applyForce(f1);
  // Now deal with the opposite force pair
  PVector f2 = PVector.mult(f1, -1);
  planet1.applyForce(f2);
  
  // Allow the planets to now move.
  planet1.move();
  planet2.move();
  
  // Display the planets
  planet1.display();
  planet2.display();
}

Experimenting With The Code

The students could change the initial values of the planets, such as the starting positions, the masses and radii by changing the input values of these two lines of code:

planet1 = new Planet(width/2,height/4,6000,60);
planet2 = new Planet(width/2,height/1.25,6000,60);

The planets initial velocities could also be modified by changing the values assigned in these four lines of code:

planet1.velocity.x = 0;
planet1.velocity.y = 0;
planet2.velocity.x = 0;
planet2.velocity.y = 0;

The code that actually guides the strength of the gravitational attraction between the two planets is actually very simple. This is the magnitude of the force as defined by Newton’s Law of Universal Gravity in code:

float strength = (G * mass * p.mass) / (distance * distance);

There is some slightly complicated code that controls the direction of the force and how that force is then applied to the planet object’s state of motion, but I didn’t have the time to explain this, which was a bit disappointing (see below).

For The Future

I am currently really interested in incorporating programming into the academy program, but have found myself a bit intimidated by the challenges identified by Ruth Chabay. The most significant challenge is time:

In an already full introductory physics curriculum, there is little or no time to teach major programming skills. Students who are new to programming are also new to the process of debugging; teaching debugging strategies requires even more time…Working on programming activities only once a week in a lab or recitation section may not be adequate to keep knowledge of syntax and program structure fresh in the students’ minds.

I plan on taking some time this summer to see how I could integrate computer programming more significantly into the curriculum without causing the learning of Physics to suffer – that would of course defeat the purpose!

We Have Lift Off!

15414703973_b0258a08ca_h  15846865828_b08d8515cd_h 16033503742_be978fd9ca_h

This is a follow up post to Modeling A Rocket’s Journey – A Synthesis where I described how the students in the first year program were engaged in creating a predictive report for their model rockets. I want to emphasize that these model rockets were not kits. Each rocket was designed using 3D CAD software, and each component was either fabricated from raw material, or was created from material that was not intended for use in model rocketry. The only exception to this is the actual rocket motor.

The next step was to launch the rockets and have the altimeter payload collect altitude data.

Launch Conditions – A Bit Soggy

Unfortunately the week of our scheduled launch happened to be a week of some pretty hefty rains. We rescheduled the launch twice before finally accepting the soggy launch conditions. With umbrellas and rain jackets, we trudged out to the baseball diamond and got to work setting up for the launch. We had some minor difficulties in the wet weather, but eventually had a very successful launch day.

Most of the rockets were able to launch and deploy their valuable payload – the Pnut Altimeter.

15414689283_8197c70584_h

The students seemed very excited to finally see the rockets launch, and to see the successful deployment of the parachutes. Although we all got a little wet and muddy, we had a great time!

The Altimeter Data

The altimeters use a small barometric pressure sensor to collect altitude data (the altimeters also contain a small temperature sensor and voltage sensor). The altitude is recorded in feet every .05 seconds. Here is an example of one rocket’s recorded flight data:

altitude_vs_time

https://plot.ly/~stemples/9

The students were then asked to use the data to create a comparative analysis report. I will detail how the assignment was set up and also discuss how the students performed on this assignment. That will be for another post.

I want to also thank Mr. Kainz for his amazing photos that are displayed here.