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

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

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.