Tag Archives: robot

Graphical Systems in Geogebra and crashing LEGO robots in Algebra 2

In the Algebra 2 class, we started our unit on solving systems of equations. From a teaching perspective, this provides all sorts of opportunities for students to conceptualize what solutions to systems mean from a graphical, algebraic, and numerical perspective. Some students seem to like the topic because it tends to be fairly straight forward, is algorithmic, and has many ways to check and confirm whether it has been done correctly.

I used this as my warm-up activity today:

a) Estimate the solution of the system.

b) Write an equation for each line in standard form.

c) In Geogebra, select CAS view and type the following using your two equations: Solve[{7x+3y=6,3x-4y=12},{x,y}]

d) Use your calculator and convert these values to decimals. How close are these to your estimate?

We had some great discussions about the positives and negatives of graphical solutions to equations. Weaker students got some much needed practice writing equations for lines. For all students, this led to some good conversations about choosing two points that the lines clearly pass through for writing equations (if possible) rather than guessing at the y-intercept. The students also got the idea of how Geogebra can solve a system of equations exactly as a quick check for their algebra, an improvement over substituting (which is at times more trouble than it's worth for students with poor arithmetic) and slightly faster than solving for y on a graphing calculator and finding the intersection.

I also like the unit, though I don't tend to like the word problems. It's hard to convince students about the large scale importance of coin problems (especially in an international school with everyone used to different currency) or finding how many tickets were sold at the door or advance since anyone with a brain would just ask the person tallying the tickets.

I also found myself thinking about Dan Meyer's post over the summer about how many word problems are made up for the purposes of math, rather than using mathematics to analyze cool situations and create problems out of the situations. Getting students to figure out how to use the math to do this is ultimately what we want them to learn to do anyway. Figuring out when trains pass each other is not exciting to students, but I realized this morning while brushing my teeth that doing this problem with real robots either crashing into each other or racing adds a neat dimension to this problem. The question of figuring out both when they will crash or catch up to each other, and also where they will do so is a clear motivation for finding a solution to a system of equations describing their positions as functions of time.

So I gave the students the two robots (videos of them posted at http://bit.ly/vIs0lu and http://bit.ly/u9jSPB) . I told them I was going to set them apart a certain distance that was tentatively 80 centimeters, but said I wanted the ability to change that at any time. I wanted them to predict when and where they would collide.

The rules:

No, you can't just run the experiment and see where they crash. That not only defeats the purpose of this exercise, but we will be doing this sort of activity in a couple different ways during the unit, so being able to do this analytically is important. You also can't run both robots at the same time - that's for those of you that are going to try to be lawyers and break that first rule.

You can measure anything you want using any units that you want using either robot individually.

At some point, you should be able to show me how you are modeling the position of each robot as a function of time.


And I set them off to figure things out. Despite the fact there were only two robots, the 12 kids naturally divided themselves up into a couple teams to characterize each robot, and there was some good sharing of data amidst some whining about how annoying it was to actually measure things. In the end, most students at least had some idea of how they were going to put together their models, and some had actually written out what they were. As one would hope for these types of activities, there were plenty of examples of students helping others to understand what they were doing. The engagement was clearly there, as confirmed by students visibly excited to run the robot and time how long it took for it to move around.

It was a fun exercise that I plan to return to in a few ways during this unit - perhaps some interrobo-species interaction (my iCreate robot is charging up as we speak). Fun times.

UPDATE: This is the video of the next day's class when students solved their functions. I set the robots apart from each other and the students did the rest.

Build the robot the way you want...No, you're doing it wrong!

I teach an exploratory class for middle school students in robotics. The students rotate between robotics and some other electives during each quarter of the year, and there are no grades - just an opportunity to learn something interesting while doing. I like the no grades part, particularly because assessing progress in robotics is quite hard to do. My usual model is saying you get x points for doing the bare minimum (a D) and then incremental increases in the grade for doing progressively more challenging tasks.

It works, but I really like getting the opportunity to not have to do it. There are so many things you could measure to assess the students in their building and programming skills, but in my experience, the students don't tend to explore or tinker as much in that situation.

Today while working on the day's challenge on using sensors and loops, a student was fixated on building the following:

There weren't any instructions to do this - he just started putting things together, liked what he had created, and continued building it today.

I had to stop myself for a moment because teacher Evan started to come out and remind him to stay on task and contribute toward his team's solution to the challenge. Thankfully robotics Evan intervened and let it happen.

This is an exploratory class. It's supposed to expose the students to new situations that might interest them later on. Why in the world would I stop the exact sort of thinking and exploring the class was designed to provoke? It also turned out that this student, along with the other two in the group, were all taking turns in the programming and building so that each would have a chance to play in this way. In spite of their taking time to free build, this group actually solved the three challenges before the rest in the class.

It connects to a great TED talk on doodling by Sunni Brown. One idea from her talk was that doodling contributes to "creative problem solving and deep information processing." I think that these students (and all of us that 'play' with building toys like LEGO) are engaging in a similar process by free building. The connections students are making in figuring out how the tools work through play are not easy to measure. This is a horrible reason not to provide them time to do so. I do think there is an interesting connection between the tendency of these students to play and their ability to figure out the subtler parts of the class challenges.

After all, as David Wees pointed out, giving explicit step-by-step instructions on how to use creative tools like LEGO takes the creativity (and much of the fun) out of it. There has to be time to experiment and learn by doing how the tools work together, and that's exactly what this student was doing.

My final reaction during the class today was that I told them all that I wanted to take a picture of every off-topic LEGO design they create. Document it all. If it's cool enough to engage you for the time it takes to create it, I want a gallery of those designs to celebrate them.

The sad part? This made some of them stop. I can't win!