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.

Robot Project: Results

My Electrical Engineering elective ran a term-long project (in the vein of project-based learning) this spring with the goal of building a robot to overcome an "obstacle" (taken in the broadest sense).

Some previous posts on this project:

• EE: A Project-based Course
• EE Project: Obstacle Sheets
• EE Project: Arduino Project Videos and Specifications Sheets

First-time logistical hiccoughs aside, the projects were generally successful, whether that was complete success (robots successfully overcoming their obstacles) or partial success (all subsystems working, some sort of late-game failure or unexpected exception).

I built an 'arena' for this, with each robot having its own triangular area in which to place its robots, obstacle(s), and goal:

A few of the robots:

A successful robot (obstacle was darkness - it switches to battery backup when the solar panel output drops):

I was happy with the amount of dedication that the project inspired in the students - they worked very diligently and picked up a lot of skills in the engineering and coding realms. A few tweaks for next year, but it's a keeper!

Physics and Art: Pollock

This winter, one of my students came to me with an idea to create an 'art robot' - a robot that could create a piece of art. After some research, she found a Discover article summarizing Richard Taylor's work on fractal analysis of Jackson Pollock's drip paintings. Note that there is considerable disagreement over whether this is valid, as the range of available scales (only about three orders of magnitude) is generally considered too small to adequately authenticate fractal structure.

This hiccough notwithstanding, we set about to create a chaotic pendulum that could create paintings with similar fractal dimensions to Pollock's. The general idea of structural complexity is shown in a graphic from the first reference:

The fractal dimension measured by Taylor of Pollock's works is in the middle range: 1.5-1.6. A non-chaotic conical pendulum's traces are not complex enough to reproduce this (left image below), but a chaotic pendulum can (middle and right below, from second reference above):

In order to make the traces chaotic, we attached a pulley controlled by a stepper motor to the pivot of the pendulum and had an Arduino quickly oscillate the pivot infrequently (slightly lower period than the pendulum's natural period). A Glowscript simulation of two such pendula starting with nearly identical initial conditions show quick divergence, the result of the nonlinear chaotic system.

In practice, we gave the system some random horizontal driving as well, as it lost amplitude. The result is a set of five attractive canvases. The set will adorn the hall near my room, along with a poster explaining the process, showing the derivation, and discussing the results (I co-opted some MATLAB code to determine the fractal dimension of each foreground color-layer of each painting and each painting's average fractal dimension).

EE Project: Arduino Project Videos and Specifications Sheets

Two of the deliverables that students need to submit during the course of my Electrical Engineering robotics project are Arduino project videos and what I'm calling a "specifications sheet."

The Arduino project video involves them finding a pre-existing project - from the Make Arduino text that they have or the Sparkfun Inventor's Kit book or the Parallax Robot kit's materials or anywhere else - for the Arduino that they think might have some relevance for their robot build, to build it, then to modify it in some way to change its behavior, then to present a short Youtube video explaining the process and its relevance, and providing the commented code in the video description.

These have gone really well; the students haven't had training in coding for the Arduino, but they're fine with the electrical assembly issues, so it's a platform for them to modify code and hardware, which leads to them unpacking some of the working of the scripts. Lots of the projects have combined two functions, which is terrific. For example, several groups took sensor input and used it to output status messages to an LCD.

Here's one example using the LCD and a pushbutton:


...and here's one using the LCD and a photocell, complete with director extras.


The specifications sheet is like a datasheet for the robot. One of my goals is to get students to the point where they can read and use a datasheet, because it's ridiculous to think that they could ever learn all of the devices that they might encounter in their projects after this course. Instead, I want to train them to use the resources at their disposal - Stack Exchange, online tutorials, datasheets, etc. - and learn how to learn to use a new device, software package, or programming language.

These came in with varying levels of success, and I think that I can be more specific with these next year (though they can revise them this year to address any lack of specificity). The one below is a pretty good example, though I wanted some more detail on the values fed to the servos - what do those numbers mean? What's PWM, and how does it work? It's a great start, though.

Input:
● Pin A0 - photocell
○ Gives a number value and identified as “pcellreading”
○ When the light value reads 250 or lower, the car will stop
● Pin A1 - ultrasonic sensor
○ Need to wire sensor and input code
○ Will give number value and identified as “ultrareading”
● Pin 7 - right whisker
○ Equal 0 when the right  whisker is touching something
○ identified as “wRight”
● Pin 5 - left whisker
○ Equal 0 when the left  whisker is touching something
○ identified as “wLeft”
Outputs:
● Pin 13 -left servo wheel (input of 200 means the amount of continuous pulses are being generated) (can be anything from 1-250) (corresponds to amount of time spent rotating the wheel)
● Pin 12 - right servo wheel (input of 200 means the amount of continuous pulses are being generated) (can be anything from 1-250) (corresponds to amount of time spent rotating the wheel)
● Backs up and turns left 120 degrees
○ If pcellreading>650 & wLeft=0 & wRight=0
○ Or if ultrareading>6
● Backs up and turn right 60 degrees
○ If pcellreading>650 & wLeft=0
● Back up and turns left 60 degrees
○ If pcellreading>650 & wRight=0
● Moves forward
○ If pcellreading>650
● Stop moving and it has reached the goal
○ If pcellreading<650 br="">Expected exceptions:
● Car goes up ramp at angle so that one wheel goes over the edge before the ultrasonic sensor detects the cliff edge
● It gets stuck in a corner area so that it keeps hitting the 2 wall in front of it without turning around

EE Projects: Obstacle Sheets

In my electrical engineering classes, student pairs are hard at work tinkering with Arduino sketches that they think will have some utility towards their ultimate goal of building a robot to defeat their landscape's "obstacles." (project summary here)

Here is some of their project work - I call these the "Obstacle Sheets," where they outline the challenge that their robot will face and provide some ideas for overcoming them. It's just broad strokes at this point; they needed to generate some ideas to explore, and the next task for each of them will be building three Arduino projects (we have a couple of books - The Sparkfun Inventor's Kit and the Make Arduino Book), modifying them to change their functioning, and documenting that process in a Youtube video.

Balloon-Cushioned Robot

Task:

-We will initially drive the robot off of some moderate height

-We are going to use CO2 canisters to inflate balloons

-We are having the robot activate an airbag (the balloons) so that it survives the fall

-This will be motion activated- It will notice that it is in freefall

-Needs to right itself after it hits the ground

-Needs to escape the balloon (Overinflate them)

-Needs to find goal


Items/Research:

-Research Mars Pathfinder

-We also need a 9v gas valve

-c02 canisters

-balloons

-regulator to control pressure

Scared of Everything Robot (meant to be used in an indoor environment, normal floor)

Objective:
Find the most optimal spot
 -Search for darkest spot, only stay if spot meets other sensor requirements
  -quiet, not too hot
Make comments about its surroundings based on sensors
 (optional if rest of project is finished)

 Obstacles:
-Getting around objects that are in the way of robot finding best spot
 Algorithm for getting around object, avoid getting stuck circling room
-Avoiding light (photo sensor)
 Photo Resistor, pg. 41
-Avoiding noise of certain decibel (directional microphone research)
-Avoiding temperature that’s too hot
-check dark spot for space heater
-only turn on sensor when dark spot has been reached
-Getting the robot to speak for certain light levels (speaker and photo sensor)
  Play certain sound files when sensors reach certain levels

Actively search for darkest place (mission)
 -multiple sensors
Secondary move away from loud noises and avoid objects (avoid obstacles)
Final: Turn off when optimal hiding place is found

 Projects Pertaining to Robot:
P. 64 light sensors
P. 65 (SIK Guide) Spinning a Motor:
P. 54 thermostat sensor

 Robot Course of Action

Scan for darkness w/ multiple photosensors, travel using random search (like Roomba)
Constant sensors
Noise (Directional Microphone)
Shake (pivot back and forth) when it detects sound of certain decibel until sound goes away
Physical Obstacle
Move along edge, until turned 180 degrees (close enough)
Sonar
Avoiding walls, follow step 1 until travelled x centimeters in straight line, then give up and turn 90 degrees and restart search
Darkness Reached
Check if good enough
If it’s dark enough
If it’s quiet enough (small speaker)
If it’s not too hot (space heater)

Solar Robot

     The robot runs off of solar power, and when a photocell detects a lack of light it wirelessly triggers a lightbulb above it that is powered by a wall outlet. The robot will have ultrasonic proximity sensors to detect and avoid boundaries. Its search algorithm will initially be random (like that of iRobot’s Roomba).

Goal
- Get the vehicle to central location
- Need voltage regulator

Robot Car: Ditch/cliff Avoidance

Obstacle: Ditches and cliff in the terrain
 Solution: Ultrasonic sensor will be in front of the cart to detect the change of distance between the cart and ground. The distance for it to work is 1 inch to 10 feet.
(page for the sensor)   http://learn.parallax.com/KickStart/28015

 Large objects as barriers
 Solution: multiple flex sensors on different sides of the car

 How does it navigate to the Goal?
 It will have a navigation algorithm. In the algorithm the bot continues to move forward until it reaches an obstacle. At the obstacle, it will back up and turn a certain amount of degrees depending on which flex sensors are touched. It will repeat this until it reaches the goal.

 How does it know that it’s in the goal?
The goal will be under cover like in a cave, so it will be dark instead of light out at the goal. The robot will have a photocell to detect the change of light to identity the goal

 Sources to help us
http://learn.parallax.com/node/235

http://blog.miguelgrinberg.com/post/building-an-arduino-robot-part-iv-a-not-so-basic-robot-firmware

Robot Arm Upgrade (expansion of Science Olympiad project)

 Obstacles
Moving quickly and efficiently
Grabbing objects
Pencils
Legos
Dice
Ping pong balls
Programming movement
Increasing precision of movement
Grabbing objects of different textures and moving them.
Robot does not grunt enough or say enough old man things.

 Solution ideas
By building an Arduino that can use programmed macro movements we can move arm to the area of the objects quickly and then human controls will be in charge of the micro movements.

 By using stepper motors controlled by the Arduino, we can move the arm more quickly and more slowly as we need to. We will be able to move the arm specific distances by programming the motors.

 We will shift from belt operated motors and actuators to more precise rack and pinion mechanisms.

 We will reduce the amount of clamps as currently the arm is lousy with clamps.

 We will build more precise actuators, reducing the amount of syringes we have, which is currently a [90's movie reference] amount.

 We will have parts on the robot be of uniform length and ensure the even level of the arm in order to increase precision.

 We will add a speaker that will speak randomized, programmed sounds related to the activity of the arm in order to let users know his feelings and to demoralize the enemy.

 Experiments Related

Circuit #11
Circuit #12
Coding pg. 94, 137
Driving bigger loads pg. 72

Honors Projects, 2015

I'm quite a bit behind the times, but here is a selection of the independent projects from Honors Physics last year - it was a great crop of creative projects!

• A project examining the physics of the zipline scene from Divergent: would the cable/device really get red hot?

• An examination of a unique binary star system: two identical stars orbiting, with a planet in the center. How far away do they need to be so that the planet isn't torn apart? What would the surface gravity be?

• An examination of the energetics of the world-record trampoline bounce: is that as high as they could've gone?

• The creation and evaluation of a model describing head impacts: the brain is taken to be an object connected to the skull by springs. Values for parameters are determined and the behavior is simulated via Excel spreadsheet and compared to actual concussion data.

• Some myth busting here: is this video of a baseball player hitting a ball so that it bounces off of multiple ball returns and back to him real?

•  Investigation of the physics of a railgun; some parameters determined via Python modeling, once the equations of motion are determined

What Can You Do With This? feat. Phineas and Ferb

I love the "What Can You Do With This?" variety of problem prompts: give the students a situation, photo, video, sound, or piece of equipment and then ask them: "what can you do with this?" That is, "what questions can you ask of this?"

Students have great ownership of these questions, and must really engage with the modeling process - identifying what principles apply, making and justifying assumptions and approximations, determining what information is available, etc., as well as practicing the process of asking interesting but focused and answerable questions. None of these purposes are served well by "textbook problems," not to mention that the process is more enjoyable and engaging for students when they're such a big part of it.

Here's my most recent - a video prompt that I saw while watching Phineas and Ferb with my son:


The students came up with some great questions, made measurements (including scaling) from the video, and did their analyses. It took about 35 minutes, and here are the three whiteboards from this section:

"What's the stiffness constant of the 'trampoline'"?

"What would his maximum acceleration be as he's caught?"

 "What's the maximum force exerted on him by the trampoline?"

Also explored by this group, but not pictured: "From how high could he fall and not die?"

 "How high does Phineas bounce?"

"How much energy was lost during the bounce?"

Independent Friction Labs

At the end of the first term, I give my honors physics students a couple of days to design, implement, and present an independent investigation involving friction. That's about all that I specify, other than the size of the poster and a few details about requiring equations set with software, citations, etc.

This year's crop was great!

This group investigated the "friction" effects of oobleck on a block, dragged through it at constant speed. They determined that the relationship could be modeled in a friction-like way, but only if the "coefficient" was a function of speed.

This group tested the idea that the mass shouldn't affect the acceleration due to friction; three kids wore the same clothes and slid across the floor, using video analysis to determine the acceleration.

This group tested and modeled the friction between interleaved pages of books. They first modeled the friction on a single page, under some number of pages above, and then did a summation to predict the total possible static friction force between the books.

This group tested the classic physics approximation of ice being frictionless. They made pucks out of ice and dry ice, and determined friction coefficients for each.

This group tried to find the optimum pulling angle for breaking the static friction on an object, both experimentally and theoretically.

This group determined the coefficient of static friction between two blocks, then predicted the hanging mass necessary in a half Atwood machine to cause the top block to slip against the bottom block (which is attached to the cart in the half Atwood).

Another half Atwood exploration - they set up a vertical surface on a cart and increased the hanging mass until an eraser would accelerate along with the cart, instead of slipping down. 

This group dragged a boat through water at different speeds, trying to determine whether they could model fluid drag as a friction force. They showed that the "coefficient" would be velocity-dependent, so that drag is not really a friction force.

Graphical Solutions _and_ Symbolic Algebra in Physics

Graphical solutions are terrific tools to build understanding in motion, momentum, energy, and nearly every area of physics. Even better than that, they allow a large number of students to successfully solve problems that really struggle with a strictly algebraic approach. Kelly O'shea and others have some great resources for you to peruse; the approach can be eye-opening for those of us brought up in the traditional system.

One thing that I struggled with a few years ago when first exposed to graphical problem-solving was all of the numbers. With my honors physics classes, I put a lot of emphasis on building their skills in exclusively symbolic solutions to problems - students are expected to do every solution with "no numbers until the end." That is, they have to first derive an expression giving the desired quantity in terms of nothing but given quantities; only then can they use any numbers. This approach has several big advantages:

• It's a pain to carry around units in the algebra (and necessary, because it's unthinkable to have "naked numbers"); symbolic algebra means that we don't have to
• We can re-evaluate for different values of the parameters easily
• We can check how our solution depends on the variables - should the Atwood's acceleration increase or decrease when this mass increases?
• We can learn how our solution depends on the variables - maybe we didn't know that the mass would cancel out of the expression for the minimum speed in the Gravitron!
• We can check how our solution behaves in special cases - should the acceleration go to g if that mass goes to zero?
• We can learn how the solution behaves in special cases - hey, the position function of a falling ball with drag becomes linear in the large-t limit!
• We can still check the units of the answer, without having to carry them through the algebra - if the units don't work, then it's not even worth plugging in the numbers
• This is a skill that ultimately is a part of how "big kids" do science - it's an great skill to have going into college science and math courses (the course that I took this summer had, out of about sixty HW and exam exercises, exactly three problems that involved numbers!)
• It helps to refine and develop student algebra skills (the more abstract end of the concrete-to-abstract progression of their skill development)

These advantages don't have to be lost in graphical problem-solving - students can still label the graph (naming every labeled quantity, whether it's known or not) and can still build slope and area relationships from the graph (involving those variables that they labeled). Solving these symbolically gets them the best of both worlds: graphical analysis and its lower barrier to entry and improved understanding, and symbolic algebra, with the skills listed above.

What does it look like? Here's a bit of student work, from a recent assessment on CVPM (constant velocity particle model) and the a whiteboard with the first (!) CAPM (constant acceleration particle model) problem that three students did this year.

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
puck=cylinder(pos=(1,0,0),radius=0.038, height=h, axis=(0,h,0), mass=.17, velocity=vector(0,0,0))


l=.76
R=vector(0,((2l)**2-puck.radius**2)**.5,0)
l=.02
beginpos=vector(puck.pos.x+puck.radius+l/2,puck.height,0)


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



r=puck.pos+vector(puck.radius, puck.height/2,0)-stick.pos

s=stick.length/2-(stick.pos.x-puck.pos.x-puck.radius)  #stick.height/2-(r.mag)*cos(arctan(abs(stick.axis.y/stick.axis.x)))

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

        r=puck.pos+vector(puck.radius, puck.height/2,0)-stick.pos

        s=stick.length/2-(stick.pos.x-puck.pos.x-puck.radius)  #stick.height/2-(r.mag)*cos(arctan(abs(stick.axis.y/stick.axis.x)))

        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
        r=puck.pos+vector(puck.radius, puck.height/2,0)-stick.pos

        s=stick.length/2-(stick.pos.x-puck.pos.x-puck.radius)  #stick.height/2-(r.mag)*cos(arctan(abs(stick.axis.y/stick.axis.x)))

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

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"
       

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:

iPad (red), calculator (blue)

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.

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.