Today, students tested their buggy collision predictions. For the last week, they’ve had access to the buggies to measure speeds. Since Monday, they’ve had their buggy starting positions.

The course was about 6m long:

Students developed a variety of models to predict the collision location. We put an emphasis on the models agreeing:

Students walked into class with a prediction for a collision time and location. We had them put down a target on the floor and coordinate with their project partner to launch the cars at the same time (harder than it sounds). Here a few collision videos:

In retrospect, the release timing is so important I have a few suggestions:

- When assigning start positions for the buggies, try to set all with approximately the same ∆x. This will make it more fair for everyone.
- Allow do-overs if kids obviously release their cars at different times. I hate that all that good physics work can get erased because the cars get released at slightly different times.

Kids left class with instructions to produce a video to present their models of the collision. These videos are due on Monday.

]]>So after running the buggy lab yesterday, I knew we needed to check in on what the students understood. The following warm up question worked great:

Note: *tick* refers to a metronome.

I’d guess 80% of the students got the 9th position of the buggy correct and were able to reasonably describe how they found an average ∆x from the provided data.

Below are a couple of the more elegant solutions. Here’s a pretty textbook solution:

Smart approach to find x_{9} from x_{6}:

Today, students ran the constant velocity buggies across the classroom to collect position and time data.

- The metronome in the background is running at 40 ticks per minute. It was our intent to run the metronome at two different rates but we ran out of time in the 45 minute class period.
- Our giant tape measures were clutch — automatically earning us non-zero starting positions AND half the cars in the room ran in the negative direction.

]]>

This year, my team and I are teaching Physics 1 (9th grade) through Computational Modeling. This curriculum uses Pyret, a language developed in part to help students learn math and science.

Today, we asked the students to think concretely about a square’s perimeter.

One kid asked why we’re learning to code. Clearly I hadn’t answered this question adequately the last few times, so I showed a computational model from next week that models a buggy moving at constant velocity. It’s familiar and they can see where their work is headed.

So, back to the square, I asked:

Then we wrote a Pyret function to find the perimeter of a square. Students worked off a Design Recipe on paper before going for the computer.

With everyone computing some solid perimeters, we turned our attention to finding the area of a square. I assigned writing functions to find the perimeter of a rectangle and the area of a rectangle for homework.

]]>The robotics class consists of nine students in grades 11 and 12. A few have prior programming experience and none have robotics experience. This week, I asked them to make their robot autonomously drive around a square. Success looked a little different around the room but for everyone, this project highlighted the downside of navigation-by-dead-reckoning.

Problems they experienced:

- over time, the wheels picked up dirt from the floor and began to slip
- turns that are slightly off the 90° ideal have compounding error
- the front caster wheel doesn’t turn consistently

We had a blast watching each robot run around the square. Here’s a supercut of the robots performing their task (stick around for the end with the whiteboard marker robot):

Next up, we’ll learn to install an ultrasonic sensor and the course will get walls to aid in navigation.

]]>When we ran out of time last class, I had students put their whiteboards away for us to review today. We’ve done a bunch of whole class board meetings where each group presents their board in turn. It was getting old. But I still wanted an efficient way for students to get and give feedback. That prompted me to modify the gallery walk format. I’ll definitely use this one again.

Biggest advantage: student whiteboards have to stand on their own without students explaining themselves.

This modified gallery walk works well late in a unit when students are basically deploying a complete model. It’s helpful that they basically understand how to do the problems and are merely doing practice.

In the picture above, these students are visiting another group’s whiteboard. They’re leaving feedback for the original board’s authors. Every few minutes, the groups rotate to the next whiteboard. Students were great at identifying something that needed addressing in the original work — missing energy storage modes, trends in ∆E that don’t match the scenario, and system boundary inconsistencies are some of the most common.

Later, the group who produced these diagrams revisited their board and took in the feedback. It was cool seeing the original group decide if the feedback they got was good, bad, or indifferent. For instance, the picture below shows a group responding to an incorrect conception from their classmates:

The student holding the whiteboard is explaining how the commenter was forgetting that the air puck has a battery in it, therefore the puck has some amount of chemical energy stored. The commenter was only thinking of the chemical energy inside the body of the kicker, which is outside the system boundary. As soon as the commenter was reminded of the battery, I heard a number of students go “ohhhhh.”

As a first-year Modeling Instruction teacher, I’m struck by two observations about whiteboarding:

- Variety is important so that students don’t tire (and get less out of) specific whiteboarding modes.
- 9th graders can get fidgety with standing to display whiteboards. That wiggling makes it tough to observe. Now I see why so many of you are using whiteboard stands.

How do experienced whiteboarders keep board presentations from getting so repetitive? The whole class board meeting has kids tuning out or fidgeting while waving a whiteboard around — all while a great debate is happening between a few students over some detail on a board.

]]>Students put a scenario on the whiteboards, then posted them up front once we agreed on the content. In the interest of emphasizing energy flow AND systems with energy coming in from the surroundings, I redefined system boundaries and re-diagrammed the same scenarios above. The picture below shows three problems we worked on during class:

To check their ability to manage the flow of energy into or out of a system, I gave them the following problem:

I throw a tennis ball into the air. States are defined as drawn on the whiteboard. Draw LOLOL diagrams (that’s a 3-state LOL diagram) to show the energy shifts throughout. But let’s make it interesting — half the room should include me in the system and half should leave me, the thrower, out of the system.

]]>

A mass on a spring is pulled down and released, and allowed to oscillate. Student whiteboarded all three representations they now now: system schema, state diagrams, and energy bar charts.

Groups got done at different times, so I pivoted from my original idea for a classwide board meeting. Instead, I put two groups together and asked them to come up with a question for me out of their discussion.

As new bar charters, the students worked to balance several requirements at once: decide which energy storage modes are relevant to the problem; that the total energy in the system has to remain constant throughout all three states; and that the total energy in the system must equal the sum of the amount of energy stored in each of the relevant modes.

Our first quiz is tomorrow (Friday).

]]>A reading assigned for homework the night before did some heavy lifting for us, introducing system schema and state diagrams as representations (even if their understanding was incomplete and students were partially confused). Here’s an example:

We spent most of our time revisiting the observation stations from yesterday, adding system schema and state diagrams. We began on whiteboards and moved to paper during the class.

Here’s a snippet of the worksheet we used:

It’s only the third day of school and the students are already debating when to declare a the *initial state* and *final state* in their state diagrams and are debating what items belong in the system.

In closing, a few fun pictures — it’s year 2 at this school AND Rosh Hashana all at the same time! Happy New Year, indeed.

]]>Time flew today while students visited six observation stations. 3-4 minutes at each of the following gave them a chance to work in small groups and describe their observations:

- Pull back car
- Hover puck
- Mass on a spring
- Bouncing tennis ball
- Rubbing hands together
- Single bulb electric circuit

We had a choice from many more observation stations. Our decision ultimately boiled down two two criteria: 1) the station would be seen again in a future unit and 2) we covered the types of energy storage modes the students would see in this unit.

Background on the environment: this is a Physics First class for 9th graders. Three of us are teaching the course to about half the grade (the other half are in the accelerated course). We’re using Modeling Instruction materials with the Computational Modeling integrated. It’s based on the summer workshop two of us attended.

Since I didn’t write the activity, I feel it’s not my place to share an editable version, so instead, here’s a snippet:

]]>