# 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.

good idea, man