The Universe Tells You If You're Right

Three recent, easy examples of ways that I've let the students know that they're not trying to please me - that I'm not the final arbiter and source of everything physics-y - came this week in the form of lab practica in three different courses:

AP Physics C (Mechanics): The Bouncy Spring
The students program a Glowscript animation of a ball on a spring, initially released from a position diagonally below the pivot point of the spring. Crazy bouncy motion ensues, but... did we do that right? Pair some high-speed video with the animation and see! For fast finishers: relate the loop computation rate to the frame rate of the camera and get the video and animation to move in sync.

Honors Physics: Ramp Rolling
Sitting in announcements last week, I thought about a ball rolling down the long, gentle slope in our auditorium, then hitting the wall after rolling across the flat ground. Hmm... how far up the ramp can I take the ball before it hits that wall? Easy enough: split the kids into three teams: a team to determine how the ball moves on the ramp (they figure out the translation: what's its acceleration on the ramp?), a second team figures out how it moves on the floor (acceleration again), and a third team does a derivation to put it all together, taking assumed results from teams 1 and 2 and deriving a function for the ramp distance. Works pretty well, and the gentle curved transition gives us an opportunity to talk about error analysis.

Electronics: Resistor Circuits
Were your Kirchoff's Laws and Ohm's Law calculations right when you analyzed that three-resistor circuit? Yes? No? Measure it! Really simple here - gives practice breadboarding and measuring that the kids wouldn't get from just a thumbs up/down from me.

The Power of Student Coding in Physics

A couple of weeks ago, I gave a 30-minute talk about student coding in physics at the AAPT National Meeting in sunny Sacramento. I'm including a link to the presentation below. The ideas are several:

• "I don't code in my physics classes: why should I?"
• "What tools should I have my students use to code physics?"
• "How can I help my (esp. younger) students with some CS concepts?"
• "What sorts of programs can my kids and I write in intro physics/intermediate division physics?"
• "I haven't coded much before: I need some examples of code, too!"

The Sky Bike

The Sky Bike at the Franklin Institute (I'm sure also at a lot of other museums) is a great application of energy and stability concepts for AP students!

 When I challenged my students to explain why the bike was stable, I got a lot of "because of the weight underneath," but not much concrete, convincing explanation to justify that intuition. OK; let's back it up a bit. Why - in terms of energy - is a regular bike, when upright and motionless (for simplicity), unstable?

They connected stability (since we had said the word about ten times at this point) to the potential energy graph, and then just needed to do the trig to determine the gravitational potential energy of the Earth/bike/person system and graph it.

The diagram:

The gravitational potential energy (taking h=0 to be the vertical position):

$$U(\theta) = mgh = -mg\dfrac{l}{2}(1-\cos\theta)$$

The graph: 

Why is it unstable? The force exerted on the bike that will act to change the angle is given by $F = -\dfrac{dU}{ds}$, which is another way of saying that the direction of the force is the opposite of the slope of the U graph or... that the system will evolve in the same way that a ball would, if it were rolling on a hill of the same shape as the U graph. Dome shaped? It'll roll downhill, away from the equilibrium point, so the equilibrium is unstable. 

OK, let's add the mass underneath. I arbitrarily decided that it was on a massless pole of the same length as the bike's height, and that its mass was greater than the bike/person mass. This made qualitative analysis easier at the end, but they see how the parameters could be modified once the analysis is done.

The diagram:

The gravitational potential energy (taking h=0 to be each object's vertical position):
$$U(\theta) = mgh = -mg\dfrac{l}{2}(1-\cos\theta) + Mgl(1-\cos\theta)$$

The graph:

The big deal here conceptually is that, when the bike/person goes down, the mass goes up, and it gains more potential energy than the bike/person lost, meaning that we've turned a dome into a bowl, so that we now have a stable equilibrium.

Two interesting asides: if $M = \dfrac{m}{2}$, then $U=0$ for all angles, and the equilibrium is neutral, so the rider could stably sit at whatever angle. Not a super-fun idea, so it's a good time to talk about engineering and designing around such possibilities.

Also, how do we make the ride more stable? What does that mean graphically? It'd mean making the $U$ graph steeper, which we could do by increasing $M$. Note that the masses are intimately related to the "heights" of the domes/bowls:

The connection between forces and potential energy is often a topic that gets short shrift in AP Physics - seen as a small tidbit or something mathematical to be explored, but it's actually a very deep and applicable concept. I've also incorporated some programming exercises on this for students as well. Its use to justify the ball-and-spring model of matter (by approximating the Lenard-Jones potential as a parabola near the equilibrium point) is one of the lynchpins of my want for it in a physics course that uses Matter and Interactions.

VPython, Energy, and Stability

The content in AP Physics C about stability and its relationship to energy is a pretty thin introduction to a fairly deep idea. Classifying equilibria by looking at the derivative of potential energy can be a quick add-on, or we can make it a little deeper with the help of VPython.

When it first comes up, we go through the stable/unstable/neutral equilibrium discussion and the corresponding shapes of potential energy graphs, but I really wanted a way for students to apply that. I've thought of a few, only three of which I have tried out so far:

• Have VPython plot a potential energy vs. tip angle curve for a box that's standing on its end - compare for different heights/widths of box
• Have VPython graph total potential energy vs. stretch amount for a mass on a vertical spring
• Have VPython graph potential energy for a mass of a spring that doesn't necessarily stay vertical (on y vs. x axes, with U value signified by color)
• Investigate the Lenard-Jones (interatomic) potential, both for meaning and location of equilibrium points and to fit an approximate quadratic to it near the equilibrium point, justifying the use of the ball-and-spring model of matter.
• Later in the year, during rotation, have them create a physical pendulum program with a box on a pivot not through its center - modify this to show the graph of potential energy as a function of angle

For the first and fifth, I have some results using VPython to show. (The fourth is great, too, especially if you're using Matter and Interactions!) For the box tipping, the graph is neat, not least of which because of the discontinuity in the derivative at 0. Calculus wouldn't find this minimum on without intervention from the student, and it's easy to forget to check those endpoints! This gives a nice graphical reminder. My one concern is that the geometry is fairly harrowing - determining the height of the CM as a function of angle isn't super-easy, and requires a high-quality diagram. 

Here's a screen shot:

When you vary the parameters, that central well can become deeper (more stable) or shallower (less stable), and vanishes as the box gets narrower (and becomes a pencil).

For the final one, I think that the program, being a modification of a previous one, isn't too difficult to do, though it does bring in the complication of having a "meta loop," where the whole simulation runs several times, with different placements of the axis. 

Here's a screen shot that links to a video of the program running:

The graph here is incredibly rich. Not only do we see two different kinds of equilibrium (three, if you let the pivot be at the middle for the first run through), but we see how the system is forced away from or towards those equilibrium more or less violently as the pivot moves. This helps to bring together their common-sense understandings of stability and the physical principle that we're trying to investigate.

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=sphere(pos=vector(0,0,0), radius=6.4e6, material=materials.BlueMarble)
    Earth.m=6e24 #kg

    #Create Moon
    Moon=sphere(pos=vector(0,4e8,0), radius=1.75e6, color=color.white, make_trail=True)
    Moon.m=7e22 #kg
    Moon.v=vector(1050,0,0) #m/s

    #Create Target Asteroid
    Target=sphere(pos=vector(-1.40837e9, 1.42004e9, 0), radius=7e6, color=color.green)

    #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"
       

Nonuniform Circular Motion

I was trying to create a non-uniform circular motion experiment this summer, but I was barking up the wrong tree.  I thought about swinging a ball in a circle at constant speed and have students derive the tension as a function of time or angle - measuring it with a force sensor - but you have to mess with the pivot point of the string (in a really interesting way) to make the ball move like that. Also - that's not non-uniform CM anyway! I then tried (at Physics Teacher Camp) to put a horizontal pole through the force sensor's mounting point and let a weight swing on a string - nonuniform CM was good, but the non-zero mass of the sensor ended up being a huge issue, and the tension was hardly ever parallel to the sensor's axis.

This week, I figured it out: the sensor is the ball. I attached a string to a rotary motion sensor (so that I could determine the angle and angular v as a function of time) and hung the force probe from it.

Puling it back and letting it swing, I got a good data set, even though I couldn't effectively zero the rotary motion sensor for some unknown reason.

Students then looked at the forces acting on the probe at some arbitrary angle and derived the tension as a function of angle and angular velocity.

To get the model to work without the rotary motion sensor being zeroed, I added an offset to the formula when I created a calculated column in Logger Pro. Once I did that, we could compare the graphs of actual tension (red) and predicted tension (pink):

There's an interesting time offset that I haven't explained yet: ideas?

Comparing Springs

We went through simple harmonic motion derivations two days ago in AP. Writing the second-order diff eq. was easy for them, but it was the first one that they've solved, so we had a nice long guess-and-check for possible solutions. Ultimately, it was pretty clear to them how to take that trig function and get what they needed from it, but the process of using that diff. eq. solution as a model to solve similar ones (especially the hanging spring) was more difficult for them. I don't have any awesome inspirations on teaching that, but looking at a few other situations (two springs, etc.) helped quite a bit, and I assigned the "fall through the Earth" problem last night, which is a great application of SHM.

The point here, though, is to talk about some of the realizations about SHM that they had, and how Python helped that happen. They don't do oscillations in their first course, so this is the first that they've seen it in a physics context. The idea of amplitude independence is always tricky for students, so I just let them make a prediction about what would happen to the period of a spring when I changed the mass, or the spring constant, the amplitude, or g.

It's easy enough to see those results by looking at the derived period function, but it was always difficult to demonstrate some of those things cleanly - springs wobble, students imagine slightly different periods, they can't tell exactly what the amplitude or equilibrium point are (and damping doesn't help), I can't turn off gravity, etc.

I modified our second programming assignment of the year to have two springs instead of one, and demonstrated all of those cases very easily. Because they know how the program works (they basically wrote it), there's more faith in it (well, not faith, since it's based on reason, but they put more stock in it), and it's much easier to see.  The springs will oscillate perfectly forever and I can listen more to the discussion than worry about restarting the springs all the time.

Here's the script - use with attribution and an email:


from visual import *

scene.height=600
scene.width=600
scene.scale=(.6,.6,.6)
scene.center=(0,-.7,0)

# scales
Fscale = .1
vscale =.4

# objects
roof1=box(width=3,height=.05,depth=3,color=color.white,pos=(-.5,0,0))
roof2=box(width=3,height=.05,depth=3,color=color.white,pos=(.5,0,0))

ball1=sphere(radius=.1, color=color.green, pos=(-.5,-.5,0), velocity=vector(0,0,0))
ball2=sphere(radius=.1, color=color.orange, pos=(.5,-.7,0), velocity=vector(0,0,0))
#ballvvec=arrow(pos=ball.pos, color=color.blue, axis=vscale*ball.velocity,shaftwidth=.05)

spring1 = helix(pos = roof1.pos, coils=15, axis=(ball1.pos-roof1.pos),radius=.1)
spring2 = helix(pos = roof2.pos, coils=15, axis=(ball2.pos-roof2.pos),radius=.1)

#forcevec=arrow(pos=ball.pos, color=color.red,shaftwidth=.05)


# physical constants
k = 20
restlength = 1
mass1=.6
mass2=.6

deltat=.001
t=0

while 5 <= 10:
    rate(300)

    # forces
    gravity1=vector(0,0*mass1,0)
    springforce1 = -k * (mag(spring1.axis)-restlength) * spring1.axis / mag(spring1.axis)
    netforce1 = gravity1 + springforce1

    gravity2=vector(0,0*mass2,0)
    springforce2 = -k * (mag(spring2.axis)-restlength) * spring2.axis / mag(spring2.axis)
    netforce2 = gravity2 + springforce2

    # v and r update
    ball1.velocity = ball1.velocity + netforce1 * deltat / mass1
    ball1.pos = ball1.pos + ball1.velocity * deltat

    ball2.velocity = ball2.velocity + netforce2 * deltat / mass2
    ball2.pos = ball2.pos + ball2.velocity * deltat

    # vector and graphical updates
    #ballvvec.pos = ball.pos
    #ballvvec.axis = vscale*ball.velocity
   
    #forcevec.pos = ball.pos
    #forcevec.axis = Fscale*netforce

    spring1.axis=(ball1.pos-roof1.pos)
    spring2.axis=(ball2.pos-roof2.pos)

    # time update
    t = t + deltat
   

 

Speed of Sound

OK, so we're finally there in AP - the speed of sound calculation. Matter and Interactions makes a hand-waving argument based on dimensional analysis to get the longitudinal speed of sound from the interatomic bond length and spring constant and the atomic mass. That's fine, but I wanted to get to the real derivation, which involves a very interesting couple of linear approximations and some possibly bogus calculus, but it's doable.  The transverse one is basically the same story.

It's more guided and less inquiry, but it's a tough bit of stuff. I'm OK with there being less discovery here, because it's going to be a gigantically powerful result - predicting the frequency of a sound using the molar mass, density and Young's modulus? Awesome.

We're applying both of the expressions today in lab.  I'm spitballing the work flow here:

• Wave intro, animations, etc. Define wavelength, frequency, v relationship by analogy to traffic
• Longitudinal wave derivation:
• With known molar mass, modulus, and density, they determine k, d, the atomic mass, and v (using the dimensional analysis result)
• The real derivation - super-guided by me
• Demo singing rod, have them calculate its frequency
• Sing, record, FFT
• Party
• Transverse wave derivation:
• Animations - difference between longitudinal and transverse
• Derivation
• Give them sample of wire - they determine the tension needed to have the sound be an octave below a resonance box (128 Hz); help them with the standing wave's length
• Use force wire strung between two poles (one with a force probe on it) to measure tension. Other end of wire is still on the spool, which is on the rod. Kids twist spool so that the sound is in tune; reveal tension (or vice versa?)
• Party

The setup with the spool (yellow string added so that you can see the path of the wire):

Here's my drawing of the whole process: