- "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!"
A blog about physics education - student work, demonstrations, lesson ideas, and reflections on standards-based grading. Not endorsed by or affiliated with The Tatnall School
Friday, July 29, 2016
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:
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:
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):
Some previous posts on this project:
- EE: A Project-based Course
- EE Project: Obstacle Sheets
- EE Project: Arduino Project Videos and Specifications Sheets
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!
Thursday, May 19, 2016
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:
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).
Wednesday, May 18, 2016
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 around650>
Tuesday, April 12, 2016
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)
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
Tuesday, April 5, 2016
Electrical Engineering: A Project-Based Course
This year, with the new Electrical Engineering elective (prerequisite: electronics), I'm trying out a fully project-based course. With the background knowledge that they have and a whole lot that they pick up along the way, these students are going to build a robot to respond to this central prompt:
Robots overcome obstacles in many different ways; some are similar to the methods that humans would use and some are markedly different. The goal here is to design an "obstacle" and a robot to navigate the obstacle. Teams will build both the "arena" in which the robot operates and its goal location, and their robot must overcome the obstacle to reach the goal. "Obstacle" could mean many different things, definitely not limited to physical obstacles - a solar-powered robot may have darkness as an obstacle, a robot on Venus would have to overcome high temperatures, and a rescue robot would have to overcome uneven terrain.
Along the way, teams will need to meet several intermediate goals, producing several 'deliverables,' which demonstrate planning, incremental progress, and proof-of-concept for their robot.
Deliverables:
- "Obstacle" description, along with ideas (plural!) about how the robot might overcome it (team evaluation )
- Specifications sheet: details your robot's inputs (information from sensors), outputs (expected behaviors, actions, etc.), and expected exceptions (problems that can occur) (team)
- Three Arduino projects from the texts that could pertain to your problem (individual evaluation; three projects different from your partner's three). For each, summarize how you think it might pertain to your project and show how you modified the project/sketch to change how it functions in some way. Present these as a Youtube video, with commented code (showing especially the modifications) linked
- Program flow chart (detail the sequence of sensor readings, calculations, and outputs that will take place in the loop, as well as the preliminary variables that need to be set) (team)
- Contribution to the WCGW? (What Could Go Wrong?) meeting: brainstorming unexpected exceptions for other projects - if you help them figure out the potential issues, they'll be able to design around them. You'll get the same help (individual)
- Schematic: Arduino and all associated electronics (sensors, motors, LEDs, etc.) (team)
- Sensor and output validation: show, with isolated snippets of code, that you can accurately measure whatever sensors are measuring and accurately control any output devices (individual - one partner designs, executes, and videos illustration of inputs, the other does the outputs). Present these as Youtube videos
- Landscape, including the "obstacles" and a goal. The robot needs to be able to detect when it's in the goal! (team)
- The robot, fully functional (team)
- Reflection on the process and the big question of how robots overcome obstacles and how that is similar to or different from how humans do (individual)
Each of the deliverables will be evaluated on the 11-point scale. Teams/individuals must earn at least 7 on a deliverable in order to proceed, with revision increasing the grade. The final evaluation will take place together, with the five arenas and robots moving towards their goals simultaneously. This is their 'exhibition,' and I'm planning to invite as large a committee as I can to make it an authentic experience.
Monday, January 4, 2016
Electronics: Goals and Ideas
This year, we've added a physics-based elective strand, consisting of Experimental Design, Electronics, and Electrical Engineering. The electronics course is a prerequisite for the EE course, but you don't have to take both. The experimental design course is a bit of a singleton, which I'll get to in another post, but I'm a month or so into the electronics course, and wanted to share some of the paradigms of the course and see if anyone had any helpful ideas or experience teaching HS electronics to add.
Big Ideas
Resistors
Switching
Capacitors
PV Cells
RC Circuits
Diodes
Project
Schematics
Assembly
Units
Algebra
Big Ideas
- The course is more of a phenomenological look at electronics than a physical ones. That is, we're dealing with it as electronics folks would, rather than as physicists would. We can't get into a lot of heavy Maxwell's equations action, and we're not getting into an extremely precise model of the physics of current flow (Matter and Interactions does a great job with this, but it's not within the goals of the course or the mathematical tools of the prerequisites), and no differential equations to deal with RC, RLC circuits, etc. I want students to have a practical understanding, supported by theory where necessary and possible.
- There's a big emphasis on assembly, schematics, soldering, etc. I want students to be able to read and use a breadboard, a schematic, clip leads, meters, and to be able to solder.
- I want to hit the most important devices and concepts - resistors, capacitors, various sensors, etc., and also classic combinations of components (which are applications of these), like voltage dividers, voltage regulators, rectifiers, etc. This is one spot where I'd love a lot of suggestions; my formal electronics training has principally been physical, rather than practical.
- The primary lens through which I'm going to have the students comparing different classes of devices is the i-V curve. Batteries, resistors, diodes and LEDs, and PV cells are the primary devices that I have on that list. Let me know if there's something that I'm missing. Capacitors will be in there, too, but they don't fit well into this paradigm.
- I'm using (supplemented by my own stuff) the Make:Electronics book. There's a great deal that I like about it and some things that I don't (particularly on the theoretical end), but it's a good place to start. Students also get the kit for the first set of experiments, too. That's pretty expensive, and I probably can buy the parts and distribute them to them next year for a much smaller cost to them.
Resistors
- Apply the loop and junction rules to battery/resistor circuits, both qualitatively and quantitatively
- Appropriately use Ohm’s law to describe one or more resistors
- Analyze series and parallel circuits
- Determine and apply equivalent resistance
- Recognize, apply, and analyze iV curves of resistors and batteries
- Determine the power expended by resistors and connect energy and time
- Use current as a measurement of rate of charge flow
Switching
- Identify and analyze open and short circuits
- Use and analyze SPST, SPDT, and DPDT switches
- Use and analyze relays
- Analyze circuits containing PNP and NPN transistors
Capacitors
- Understand relationship amongst voltage across a capacitor, charge stored in it, and its capacitance
- Qualitatively analyze steady-state capacitor circuits
- Apply the loop rule to circuits with capacitors
- Determine and apply equivalent capacitance
- Calculate energy stored in capacitors
PV Cells
- Recognize and analyze iV curves of photovoltaic cells
- Analyze PV cells in circuits
RC Circuits
- Qualitatively analyze (graphs of) voltage, current, and charge as time goes on
- Analyze the steady state of an RC circuit
- Use the loop and junction rules to determine current, voltage, charge at some moment in time
- Calculate and apply the time constant of simple RC circuits
- Advanced: use equivalent circuits to determine time constant
Diodes
- Differentiate between and apply ideal and realistic diode models
- Compare diodes with resistors and batteries
- Recognize and analyze a diode's iV curve
- Understanding and apply the concepts of threshold and breakdown breakdown voltage
Project
Schematics
- Recognize components on schematic:
- Batteries
- Switches
- Capacitors
- Resistors
- Potentiometers
- Diodes
- LEDs
- PV cells
- Junctions
- Draw schematic, given circuit (clip leads or breadboards)
Assembly
- Construct circuit with clip leads, given schematic
- Recognize components visually
- Breadboard circuit, given schematic
- Solder components, with or without perf board
Units
- Properly and consistently use units
- Fluently deal with metric prefixes
- Convert units fluently
- Check for proper unit cancelation
Algebra
- When appropriate, use symbolic algebra (no numbers until the end)
- Recognize unreasonable answers
- Reason proportionally
- Fluently solve equations
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!
$$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:
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 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.
Subscribe to:
Posts (Atom)