## Monday, December 2, 2013

### Independent Friction Labs and Another Capstone Project

I have my Honors Physics students prepare small electronic posters for their final lab of the first term, the Independent Friction Lab. In this lab, students have to come up with an experiment, make an informal proposal, execute the experiment, and analyze the results.

The experiment really just needs to have something to do with friction, and I get a wide variety of them. I have them create a single PP or similar slide, sized 24"x18"; they're great to print at Staples. I ask them to email me a draft a day or so before the presentations, and they present the revised projects.
Here are a few of this year's experiments:

This group used a Pasco friction cart; they let it slide on a cart track, used the velocity graph to determine the coefficient of kinetic friction, and then determined the hanging mass that would pull the friction cart at constant speed (verifying that with another motion detector graph).

This group found the coefficient of static friction between a block and a ramp in a neat way: they used a half-Atwood setup, changing the mass until the block slipped, but performed that experiment at several angles. They then predicted a function for that maximum mass as a function of the block's known mass, the angle, and the unknown friction coefficient. Graphing their data, Logger Pro found the static friction coefficient by regression, providing both a quality value and confirmation of the model that they used to describe the situation.

These students compared the effective coefficients of friction for a ball rolling (without slipping) and the same ball under backspin (backspin persists until it turns around). They're essentially determining the coefficients of rolling and kinetic friction, showing that the kinetic friction coefficient's much larger.

This one seems to come up every year, and it's always fun. They used video analysis to determine the coefficient of kinetic friction between socks and several surfaces. The tricky unseen part is the big possible variation in normal force from foot to foot and moment to moment

A second AP Physics capstone project is also included here; the student was trying to model the interaction between a hockey stick and a puck. It ended up being a very difficult problem, but he gained some valuable ground and ended up with a functional scaled-back model.

Student work:

For my capstone project, I wanted to model the interaction between the blade of a hockey stick and the puck during a shot or pass in ice hockey. Using the ball and spring model of matter interactions, I created a VPython program where a constant force acts on the blade of the stick, but reverses direction at the center (0,0,0) to simulate the slowing down of the stick after reaching the midpoint where the x component of the force on the stick would be at its maximum. The force on the puck, however, does not follow the same constant pattern. Since materials act like springs with miniscule stretches, the force on the puck oscillates during the entire blade-puck interaction time even though the oscillation and resulting compression of the blade would be impossible to see with the naked eye. While this is not a perfect model since the blade remains at a constant angle, 90°, and the force magnitude remains constant in the direction of velocity and only changes direction by 180°, it does illustrate how matter interacts at the atomic scale. During the collision, both the force on the puck and the compression of the blade oscillate, but so slightly with the large spring constant that, looking at the velocity graph, the puck behaves like it would with a constant force and constant acceleration during contact.

 Screenshot at the moment of collision

 Graphs of the "spring" compression, force exerted on the puck, and velocity of the puck as functions of time

from __future__ import division
from visual.graph import*
from visual import*

#create objects
h=.025

l=.76
l=.02

stick=box(pos=beginpos, length=l, height=.076, width=0.3175, material=materials.wood, velocity=vector(0,0,0), mass=.7,)# axis=norm(R-beginpos)*.076, k=500000)

#R=vector(0,((2l)**2-stick.pos.x**2)**.5,)

scene.autoscale = False

#create forces

Fdirection=vector(-1,0,0)#norm(vector(-stick.axis.y, stick.axis.x,0))

Fmag=200

k= 10000#310575#414172.6

Fp=vector(k*s*Fdirection)

Fs=Fmag*Fdirection

#graph
gd =gdisplay(x=0, y=0, width=600, height=150, title='Fp vs. t', xtitle='t (s)', ytitle='Fp (N)', foreground=color.black, background=color.white, xmax=.25, xmin=0, ymax=100, ymin=-100)

Fpg=gcurve(color=color.red, gddisplay=gd)

gd2 =gdisplay(x=0, y=0, width=700, height=150, title='compression vs. t', xtitle='t (s)', ytitle='Compression (m)', foreground=color.black, background=color.white, xmax=.25, xmin=0, ymax=.01,ymin=-.005)

sg=gcurve(color=color.green, gdisplay=gd2)

vg = gdisplay(x=0, y=0, width=600, height=150, title='v vs. t', xtitle='t (s)', ytitle='Puck Velocity (m/s)',foreground=color.black, background=color.white, xmax=.25, xmin=0, ymax=0,ymin=-30)

vg=gcurve(color=color.blue, display=vg)

print s
#create loop

t=0
dt=.00001

while t<.25:

rate(10000)

if s>0 and stick.pos.x>0:

#stick

stick.velocity.x=stick.velocity.x+Fs.x/stick.mass*dt

stick.pos.x=stick.pos.x+stick.velocity.x*dt

#     R=vector(0,((2*l)**2-stick.pos.x**2)**.5,0)

#        stick.axis=norm(R-stick.pos)*stick.length

#puck

puck.velocity.x=puck.velocity.x+Fp.x/puck.mass*dt

puck.pos.x=puck.pos.x+puck.velocity.x*dt

#s

Fdirection=vector(-1,0,0)#norm(vector(-stick.axis.y, stick.axis.x,0))

Fp=vector(k*s*Fdirection)

Fs=Fmag*Fdirection-Fp

elif stick.pos.x>0:
#stick

stick.velocity.x=stick.velocity.x+Fs.x/stick.mass*dt

stick.pos.x=stick.pos.x+stick.velocity.x*dt

#        R=vector(0,((2*l)**2-stick.pos.x**2)**.5,0)

#        stick.axis=norm(R-stick.pos)*stick.length

#puck

puck.velocity.x=puck.velocity.x+Fp.x/puck.mass*dt

puck.pos.x=puck.pos.x+puck.velocity.x*dt

#s

Fdirection=vector(-1,0,0)#norm(vector(-stick.axis.y, stick.axis.x,0))
Fp=vector(k*s*Fdirection)

Fs=Fmag*Fdirection

elif stick.pos.x<0: abs="" arctan="" cos="" fdirection="vector(1,0,0)#norm(vector(-stick.axis.y," fp.x="" fp="vector(k*s*-Fdirection)" fs="Fmag*Fdirection" if="" puck.height="" puck.pos.x="puck.pos.x+puck.velocity.x*dt" puck.velocity.x="puck.velocity.x+Fp.x/puck.mass*dt" puck="" r.mag="" r="puck.pos+vector(puck.radius," s="stick.length/2-(stick.pos.x-puck.pos.x-puck.radius)" stick.axis.x="" stick.axis.y="" stick.axis="norm(R-stick.pos)*stick.length" stick.height="" stick.pos.x="stick.pos.x+stick.velocity.x*dt" stick.pos="" stick.velocity.x="stick.velocity.x+Fs.x/stick.mass*dt">0:
Fp.x=0

if stick.velocity.x>0:
stick.velocity.x=0

if s<0: abs="" arctan="" cos="" else:="" fp.x="" fpg.plot="" pos="(t," pre="" print="" puck.pos.x="puck.pos.x+puck.velocity.x*dt" puck.velocity.x="" puck.velocity="" r.mag="" s="" sg.plot="" stick.axis.x="" stick.axis.y="" stick.height="" stick.velocity.x="" t="t+dt" vg.plot="">

## Wednesday, November 13, 2013

### Capstones! Gravitational Slingshot edition

My AP class does capstone projects at the end of each term. It's a short independent project, having to do with anything from the term, which they execute and present in such a way that we can post them here.

Here's the first of the crop of this fall's capstones: a VPython project simulating a gravity assist.

Student work:
The goal of my Capstone project was to create a program in VPython which simulates the gravitational slingshot used by satellites such as Voyager I or Cassini.  This method, officially called “gravity assist”, is used by space programs such as NASA to send probes to distant targets without draining resources since it uses the natural gravitational forces as ways to propel the probes into space.

In the program, I send a 15,000 kg probe into orbit around the Earth while also having the Moon orbit the Earth.  By adjusting the initial velocity of the probe, the probe would be able to pass by the moon and use the Moon’s gravitational force to “slingshot” it off to a “target” asteroid away from the Earth.  Finally, I graphed the speed of the probe during its journey and compared it to the velocity graph of Cassini.  The small boost in the graphs shows the moment the probe uses the gravitational slingshot, similar to the Cassini graph when it orbits around Venus.

Images:
 Cassini's speed graph (wikipedia)

 The program, after probe has made it to the target

 v graph from the program, showing the boost

Cassini Graph citation:

"Cassini's Speed Related to the Sun." Chart. Wikipedia. Wikimedia, n.d. Web. 12 Nov. 2013. .

Code (syntax highlighting finally works!):
    from __future__ import division
from visual.graph import*
from visual import*

#Richie Lou
#Gravitational Slingshot - CAPSTONE

#OBJECTIVE: to use a gravitational force to send a space shuttle from Earth's orbit
#to a target asteroid by using the moon as a gravitational slingshot

#Create Shuttle
Shuttle=box(pos=(6.4e7,0,0), length=72.8, width=108.5, height=20, color=color.red, make_trail=True)
Shuttle.m=15000 #kg
Shuttle.v=vector(0,-3350,0) #m/s

#Create Earth
Earth.m=6e24 #kg

#Create Moon
Moon.m=7e22 #kg
Moon.v=vector(1050,0,0) #m/s

#Create Target Asteroid

#Create Initial Conditions
G=6.67e-11 #N*(m/kg)^2 #Gravitational Constant

R=Shuttle.pos-Moon.pos #m
r=Shuttle.pos-Earth.pos #m

M=Moon.pos-Earth.pos #m

F=Shuttle.pos-Target.pos #m

FnetShuttle=-(G*Earth.m*Shuttle.m*r)/(mag(r)**3)-(G*Moon.m*Shuttle.m*R/(mag(R)**3)) #N
FnetMoon=-(G*Earth.m*Moon.m*M)/(mag(M)**3)+(G*Moon.m*Shuttle.m*R/(mag(R)**3)) #N

deltat=50 #s
t=0 #s

#Graph Velocity
gdisplay(x=0, y=0, width=600, height=150, title="velocity vs. time", xtitle="t", ytitle="velocity (m/s)", foreground=color.black, background=color.white)
g=gcurve(color.red)

#Animate Orbit
while mag(R) > 1.75e6 and mag(r) > 6.4e6 and mag(F) > 7e6:
Shuttle.pos=Shuttle.pos+Shuttle.v*deltat #m #position update
Shuttle.v=Shuttle.v+(FnetShuttle/Shuttle.m)*deltat #m/s #velocity update

Moon.pos=Moon.pos+Moon.v*deltat #m #position update
Moon.v=Moon.v+(FnetMoon/Moon.m)*deltat #m/s #velocity update

R=Shuttle.pos-Moon.pos #m
r=Shuttle.pos-Earth.pos #m

M=Moon.pos-Earth.pos #m

F=Shuttle.pos-Target.pos #m

FnetShuttle=-(G*Earth.m*Shuttle.m*r)/(mag(r)**3)-(G*Moon.m*Shuttle.m*R/(mag(R)**3)) #N #Force update
FnetMoon=-(G*Earth.m*Moon.m*M)/(mag(M)**3)+(G*Moon.m*Shuttle.m*R/(mag(R)**3)) #N #Force update

t=t+deltat #s #time update

rate(1e100)

g.plot(pos=(t,mag(Shuttle.v)))

print t/8.64e4, "days"
print mag(Shuttle.v), "m/s"



## Thursday, September 26, 2013

### Drag Graphs and Terminal Velocity

This summer, I posted my progression on drag here. One of the new elements was a pair activity where students each calculate the terminal speed of some random object that they come up with and draw (on the same set of axes) the position, velocity, and acceleration curves for the two objects. I then put the values into a VPython script and we check.

We did that today, for the first time, and it went pretty well. The students picked an iPad vs. a calculator and a big (1m on a side) metal box vs. a 747 (nose first). Here's what they got:

Neat that the heavier iPad had a lower terminal speed - it's much bigger!

747 (red), box (blue)

That 747 didn't even come close to getting to its terminal speed from 400 meters: how about from 10,000 meters?
747(red), box (blue)

Not much better there. It took nearly 300 km of fall to get there - very heavy, very low drag coefficient.

It was a bit unwieldy entering the values during class, so I think that I might do a Google form/Googlecl/VPython solution to pull those values in from the cloud next year.

## Monday, September 16, 2013

### A Two-pulley Practicum

In the AP C: Mechanics course, we're working through some extensions to old models - non-constant acceleration as a more general application of CAPM principles, UFPM with non-constant forces, etc.

Even with constant acceleration and constant forces, there are some more subtle, but very powerful, techniques that we can't do the first time around. The first is the "look at the whole system" approach to force analysis. Instead of analyzing the half-Atwood machine, for example, as a hanging mass and a cart, and eliminating the tension algebraically, we decide that the net force accelerating the system is mg and the total mass of the system is m+M, and it's super easy to get the system's acceleration. I know that some folks do this in the first year, but I like having them draw those two FBDs and really puzzle out how the force sizes relate to each other, and I think that this is just a little too black-box (especially with the change in direction of the motion in the middle) for the first year. It's also really good algebra practice.

We'll do that today, but we'll also take a look at this situation:
This can be really tricky to analyze as either a separate or a combined system, but we can make an observation about the rope that's really helpful. When the cart moves a distance d to the right, the rope's downward motion is complicated by the presence of the pulley, but a little careful diagramming can show that half of that d will end up as a longer right-hand vertical rope, and half will end up as a longer left-hand vertical rope, so that the hanging mass m will only drop d/2. Using that, the acceleration of the hanging mass must be half of the acceleration of the cart, which allows us to really easily solve for the unknown acceleration.

This worked out very well as a practicum for me, using Pasco track, carts, and superpulleys (with 100g clamped into the jaws of the hanging one. The time's long enough (with a cart run of about a meter) to be timed pretty well with a stopwatch.
I think that this does a great job of emphasizing the importance of thinking during the problem-solving process and of adding a new twist to what students might think is a "completed" topic.

## Friday, September 13, 2013

### Follow-up to the Buggy Lab

In a post yesterday, I shared a new piece of my (WCYDWT) buggy lab: having students mark explicitly on the graph which interval denotes their "answer," and having the other groups interpret the graph to determine what the situation and question were.

I had really only done this with one of two sections of Physics, and I have now had both of those sections a second time after that lab. The results for one task seemed pretty clear. I used Matt Greenwolfe's suggestion here to wrap that up by asking them to draw a specific position vs. time graph for all six robots. I actually asked for two graphs: first, for the six robots, if each was programmed to run for 20 seconds and stop (that's how they were actually programmed on the first day). Second, for the six robots, if each was programmed to run for one meter and stop.

The first class had some of the same issues that Matt described: confusing the time and distance intervals, ascribing meaning to the length of the line, etc. After some discussion, they figured it out and went on. The second class had a much higher proportion of correct graphs from the beginning on both questions. It was a large departure from previous classes' performance as well, so it seems to have had a positive effect.

One of the graphs from the second question is below. The others have been erased, but several of them drew dotted lines horizontally or vertically first, then drew their graphs, which is a great sign.

## Wednesday, September 11, 2013

### Standards for the Year

We had a great discussion on standards-based grading at the Global Physics Department tonight. Here are my standards for the year for each course, in response to a request from that conversation.

AP Physics:

• Term 1 (Momentum Principle)
• Term 2 (Energy Principle)
• Term 3 (Angular Momentum Principle)
Honors Physics:
• Term 1 (Motion, Forces)
• Term 2 (UCM, Gravitation, momentum)
• Term 3 (Energy, Oscillations, Static Electricity, DC Circuits)
Physics:
• Term 1 (Motion, Forces)
• Term 2 (Oscillations, Waves)
• Term 3 (Sound, Phases/Eclipses/Shadows, Geometric Optics)

### A New Twist on the Buggy Lab

I usually do the CVPM buggy lab as a WCYWDT? (What Can You Do With This?) challenge. Here's what that looks like:

• Each group gets a slow and a fast cart (this year, I'm using the Scribbler 2 robots, along with Matt Greenwolfe's software)
• Each group has to come up with a unique question - they put the carts into a situation and then make some prediction. Common ones include: "If they start a meter apart, where/when will they collide?" and "How much of a head start (time or distance) does the slow one need in order for the race to be a tie?"
• Groups take data, using only one cart at a time (no testing before the big reveal!)
• Groups create position vs. time graphs to answer their questions
• Along the way, I ask some questions to be sure that they're framing speed correctly (m/s vs. s/m), that they're really representing their situation with the graph (if they don't start at the same place, then they shouldn't on the graph, either), etc.
• They test their predictions, in front of everyone. These always go well, and I think that the inherent slowness of the Scribblers makes them more dramatic and easier to discern whether the test worked or not.
Here's the new part:
• As they're finishing up their whiteboards, I have them bracket the answer to the question on their graph - if they're predicting a distance, then they need to show where that distance interval is located on the graph. If it's a time interval, then they need to bracket that, etc.
• Students do not write their questions on the boards
• The "presentation": students show their WBs, saying nothing. It's the rest of the class's job to figure out exactly what their situation was and what they were trying to find.
Here's why:
• Some students have trouble differentiating between a fast car and a slow one and between a race and a head-on collision at this early stage. Having had to go through that process when they drew their graphs, they now get a few more chances to practice those skills immediately after that first experience.
• Lots of students have difficulty locating different quantities on their graphs. In CVPM, it's not nearly as big a deal, but lots can go off of the rails when trying to find delta v or the final velocity or the displacement, etc. when we get to CAPM, so this is working on those skills early and explicitly.
• It keeps the viewers actively engaged, much like the mistake game or other similar strategies.
Here are a few examples from today. I really like the fourth on, because the time interval that they were looking for was not starting at zero, but instead from when the second cart started. That's the sort of thing that often trips students up, even if they've drawn a correct graph to begin with.