robotics

Sensors First – Progress Report

I wrote previously about my plans to change how I teach programming to my LEGO robotics students. By including sensor use as a starting point, my hope is to equip students with the experience to know when sensors can do a better job than simply aiming the robot toward the target and hoping for the best.

Yesterday was my first open ended challenge after beginning this approach. Students needed to build and program their robots to retrieve the loops located at the ends of the black line paths. The time available for them to do so was kept short. As one more way to advantage sensors over a trial and error approach, I told them that I might tell them to start their robot anywhere along the line, and that they could only pick up their robot once while retrieving the two loops.

I really didn’t need that final requirement. Students quickly figured out how to adapt the line following tricks I taught them to this task. In a forty minute period, all of the teams made progress and were able to make contact with the loop using a collection mechanism.

The most satisfying result? Not a single group spent significant time aiming their robot. They clearly didn’t feel the need, which is a step in the right direction.

Sensors First – A Changed Approach

I presented to some FIRST LEGO League teachers on the programming software for the LEGO Mindstorms EV3 last week. My goal was to present the basics of programming in the system so that these teachers could coach their students through the process of building a program.

The majority of programs that students create are the end product of a lot of iteration. Students generally go through this process to build a program to do a given task:

Make an estimate (or measurement) of how far the motors must rotate in order to move the robot to a given location.
Program the motors to run for this distance.
Run the program to see how close the robot gets to the desired location.
Adjust the number in Step 1. Repeat until the robot ends up in the right location.

Once the program gets the robot to the right location, this process is repeated for the next task that the robot must perform. I’ve also occasionally suggested a mathematical approach to calculate these distances, but the reality is that students would rather just try again and again until the robot program works. It’s a great way to introduce students to the idea of programming as a sequence of instructions, as well as familiarity with the idea that getting a program right on the first try is a rarity. It’s how I’ve instructed students for years – a low bar for entry given that this requires a simple program, and a high ceiling since the rest of programming instructions are extensions of this concept.

I now believe, however, that another common complaint that coaches (including me) have had about student programs is a direct consequence of this approach. Most programs (excluding those students with a lot of experience) require the robot to be aimed correctly at the beginning of the program. As a result, students spend substantial time aiming their robot, believing that this effort will result in a successful run. While repeatability is something that we emphasize with students (I have a five in a row success rule before calling a mission program completed) it’s the method that is more at fault here.

The usual approach in this situation is to suggest that students use sensors in the program to help with repeatability. The reason they don’t do so isn’t that they don’t know how to use sensors. It is that the aim and shoot method is, or seems, good enough. It is so much easier in the student’s mind to continue the simpler approach than invest in a new method. It’s like when I’ve asked my math students to add the numbers from 1 to 30, for example. Despite the fact that they have learned how to quickly calculate arithmetic series before, many of them pick up their calculators and enter the numbers into a sum, one at a time, and then hit enter. The human tendency is to stick to those patterns and ideas that are familiar until there is truly a need to expand beyond them. We stick with what works for us.

One of my main points to the teachers in my presentation was that I’m making a subtle change to how I coach my students through this process. I’m calling it ‘sensors first’.

The tasks I give my students in the beginning to learn programming are going to require sensors in order to complete. Instead of telling students to program their robot to drive a given distance and stop, I’ll ask them to drive their robot forward until a sensor on their robot sees a red line. I’ll also require that I start the robot anywhere I want in the test of their program.

It’s a subtle difference, and requires no difference in the programming. In the EV3 software, here’s what it looks like in both cases, using wheels to control the distance, and a sensor:

What am I hoping will be different?

Students will look to the challenges I give them with the design requirement built in that aim-and-shoot isn’t an option that will result in success. If they start off thinking that way, they might always think how a sensor could be used to make the initial position of the robot irrelevant. FLL games always have a number of printed features on the mat that can be used to help with this sort of task.
When I do give tasks where the students can start the robot wherever they choose, students will (hopefully) think first whether or not the starting position should matter or not. In cases where it doesn’t, then they might decide to still use a sensor to guide them (hopefully for a reason), or drop down to a distance based approach when it makes sense to do so. This means students will be routinely thinking what tool will best do the job, rather than trying to use one tool to do everything.
This philosophy might even prompt a more general need for ways to reduce the uncertainty and compound error effect associated with an aim and shoot approach. Using the side of the table as a way to guide straight line driving is a common and simple approach.

These sorts of problem solving approaches are exactly the way successful engineering design cycle works. Solutions should be found that maximize the effectiveness of a design while minimizing costs. I’m hoping this small change to the way I teach my students this year gets them spending more time using the tools built into the robot well, rather than trying to make a robot with high variability (caster wheels, anyone?) do the same thing two times in a row.

Tea with Lee Magpili and the LEGO Mindstorms EV3

Though my schedule being back in the US this summer has been busy, when I learned that Lee Magpili was going to be in town, I cleared my schedule. I first met Lee when I was working with the Bronx FIRST LEGO League initiative several years ago. He was a quiet presence in comparison to the energetic middle school students that attended our workshops to play with LEGO robots, but I quickly learned of his prowess with building with LEGO elements. His rovers navigated the FLL field with ease and used mechanisms that balanced simplicity with effectiveness. Eventually he mentored an FLL team to do exceptionally well. Like all great FLL coaches, however, he insisted on the students doing the work. In our conversations at that time, I quickly understood that Lee believed (and continues to believe) that LEGO is an amazing platform upon which to learn an enormous range of useful skills. Robotics, in particular, capitalizes on the unique blend of play and learning through LEGO to get students to understand the engineering design process. Lee is a believer in the potential for students to be quickly engaged and motivated to work hard when the right tools are around.

It was consequently no surprise when I learned Lee had been selected for a job with LEGO education in Denmark a couple of years ago. He and I wrote back and forth periodically about the position and what it entailed, but for a while our conversations turned noticeably away from the details of his work. I figured this was just a consequence of the distance and I left it at that.

This ended last January with the announcement of the LEGO Mindstorms EV3. When Lee posted a link to the announcement on Facebook, I suddenly understood. It made me realize that like any good designer, he kept his ideas secret until they were ready to share with the world. (I assume a pretty airtight NDA was also involved.)

Lee sat down with me at Saints Alp Teahouse in New York for some bubble tea, snacks, and conversation about the EV3. What struck me was that Lee’s enthusiasm for using LEGO as a learning tool hasn’t just been maintained, it has grown considerably since becoming part of the EV3 team. As you might also expect, he was excited to show me the bits and pieces of the kit that will be coming out in August.

From a LEGO designer’s perspective, the attention to detail in acknowledging the desires of the LEGO fan community and the limitations of the NXT set will most definitely be appreciated. There are some subtle changes that made me excited given my own experiences building with the curves of the NXT and its parts.

For example, a reshaping of the motor has made it much easier to attach pins and secure it to designs:

Sensors can be attached using a single pin if needed:

I also suspect that many people will discover ways that alignment between different components will be much easier with the new set:

Lee also spoke a lot about the care that he and the team have taken to make the bar for entry with the kit low, and the ceiling high. The education kit will include instructions for building modules that can be used in different designs. A conveyor belt doubles as a set of tracks. A motor-wheel module can be built that is sturdy but easy to build upon. This will help students (and teachers) minimize the frustration that inevitably occurs when straying from build instructions to pursue an idea for a new design. The strengths associated with building with Technics parts will be a lot more intuitive to newcomers that may have only worked with bricks.

I am excited to get my hands on one of these kits. In my robotics class this year, students grew considerably in their ability to conjure up a design and make it happen with the bricks. Students often got frustrated by the curves of the NXT motors getting in the way of their designs. The ease of attaching motors directly to the programmable brick of the EV3 will make it even easier to get students learning programming techniques. The on brick features for prototyping and programming will make things much easier for trying out quick ideas, especially on an FLL field.

It was good catching up with Lee – he is a person to watch in the world of LEGO Education. He was at the FIRST World Festival to demonstrate the EV3 to FIRST LEGO League teams, not to mention members of the Board of Directors at the LEGO group. He told me that his plans include photographing Gyro Boy in Times Square and Washington Square Park. Though he assures me that the robot named ‘Evan’ that has been touring the world to demonstrate the EV3 is not named after me, I’m going to continue to assume that it is.

Playing with robots – a weekend well spent

This weekend marked the culmination of a few months of work from my robotics students. We traveled to Shanghai to compete in the FIRST Tech Challenge tournament with 47 other teams. I got involved in FIRST nine years ago when teachers at my school in the Bronx tracked me down after hearing of my engineering background. They had just won the Rookie of the Year award the season before, and were excited to have an engineer around to help. Given that it was my first year teaching, I wasn’t able to be nearly as involved as I wanted to be. It was enough of a hook to get me to see how powerful programs like FIRST really are for working on the ‘demand’ side of the educational system, the problem-solving-hands-on-building stuff that makes students see what the end game of education can be. Playing with robots on a competition field is no more ‘real world’ than estimating the number of pennies in a pyramid, but the learning opportunities in both are rich and demanding. Nine years later, I am still as convinced as ever that these are the types of activities our students need to understand the context of the skills we teach them in our classrooms.

This weekend, we met stiff competition from our Chinese competitors. They built cascaded elevator systems, scissor lifts, and sensor systems that helped to play this year’s game, a tic-tac-toe variant played using colored rings on a set of horizontal pegs. More impressive for me was seeing the mentors noticeably bored and checking their phones while the students were the ones focused on tweaking their robots and fixing programming snafus.

This, however, was not our main challenge. The biggest issues that we faced were of our own creation – how to achieve consistency in our lifting mechanism using a web of zip-ties, or discovering just how unstable our own lifting mechanism was. The students were constantly sawing different parts of the robots off to make room for the solution to the last problem they created while trying to solve another. Clearing the complex residue of multiple good ideas to leave a simple, capable solution is the ultimate goal of a good design. The overall process of doing this is difficult, even with experience. They are early enough on the curve to know that there is much that they do not know though, and their positive and cheerful manner throughout was inspiring. Even after multiple technical issues and defeats on the field, they left the competition today feeling accomplished and full of ideas.

I was most inspired by my students’ reactions to seeing the clever designs of their Chinese counterparts. I have witnessed students wandering the pits at FIRST events and greeting unique and capable designs with accusation as the immediate reaction. “They could do that because they have so much more money” or “the mentors did all the work – it isn’t fair because we do everything on our team.” I understand the sentiment, but have always passed it off as being overly pessimistic. Some skilled teams make it look easy without always making obvious the associated level of effort required to execute such designs.

What made me particularly proud of my students this weekend was seeing them look at other designs and go through two stages of processing them. First, they would remark how cool it was that the team was able to solve the problem in such a unique way. Second, with some thinking about just how, they would say something along the lines of we could have done that.

While our ranking was closer to the bottom than I (or they) will reluctantly reveal, I don’t care much at this point. The team is young and will hopefully have more opportunities to learn and build together over the next couple of years. Their satisfaction was evident in watching the final matches with a clear sense of accomplishment, even while not being part of them. Their sense of togetherness is stronger than ever.

Our bus lost its headlights on the way back, forcing us to spend an hour and a half at a repair place while the driver and nine other people figured it out while the usual pattern of loud Mandarin was punctuated with hacking and drags off cigarettes. The team, meanwhile, procured a healthy supply of snacks and seemed content to sing along to music played off their school laptops. This is a close group that has only grown closer. Easily the highlight of the whole weekend right there.

Computational Thinking & Spreadsheets

I feel sorry for the way spreadsheets are used most of the time in school. They are usually used as nothing more than a waypoint on the way to a chart or graph, inevitably with one of its data sets labeled ‘Series 1’. The most powerful uses of spreadsheets come from how they provide ways to organize and calculate easily.

I’ve observed a couple things about the problem solving process among students in both math and science.

Physics students see the step of writing out all of the information as an arbitrary requirement of physics teachers, not necessarily as part of the solution process. As a result, it is often one of the first steps to disappear.
In math, students solving non-routine problems like Three Act problems often have calculations scrawled all over the place. Even they are written in an organized way, in the event that a calculation is made incorrectly, any sets of calculations that are made must be made again. This can be infuriating to students that might be marginally interested in finding an answer in the first place.
Showing calculations in a hand written document is easy – doing so in a document that is to be shared electronically is more difficult. There are also different times when you want to see how the calculation was made, and other times that you want to see the results. These are often presented in different parts of a report (body vs. appendix) but in a digital document, this isn’t entirely necessary.

Here’s my model for how a spreadsheet can address some of these issues:

Why I like it:

The student puts all of the given information at the top. This information may be important or used for subsequent calculations, or not. It minimally has all of the information used to solve a problem in one place.
The coloring scheme makes clear what is given and what is being being calculated.
The units column is a constant reminder that numbers usually have units. In my template, this column is left justified so that the units appear immediately to the right of the numerical column.
Many students aren’t comfortable exploring a concept algebraically. By making calculations that might be useful easy to make and well organized, this sets students up for a more playful approach to figuring things out.
Showing work is easy in a spreadsheet – look at the formulas. Depending on your own expectations, you might ask for more or less detail in the description column.

Some caveats:

A hand calculation should be done by someone to confirm the numbers generated by the spreadsheet are what they should be. This could be a set of test data provided by the teacher, or part of the initial exploration of a concept. Confirming that a calculation is being done correctly is an important step of trusting (but verifying, to quote Reagan for some reason) the computer to make the calculations so that attention can be focused on figuring out what the numbers mean.
It does take a bit of time to teach how to enter a formula into a spreadsheet. Don’t turn it into a lecture about absolute or relative addressing, or about rows and columns and which is which – this will come with practice. Show how numbers in scientific notation look, and demonstrate how to get a value placed in another cell. Get straight into making calculations happen among your students and in a way that is immediately relevant to what you are trying to do. Then change a given value, and watch the students nod when all of the values in the sheet change immediately.
Building off of what I just said, don’t jump to a spreadsheet for a situation just to do it. The structure and order should justify itself. Big numbers, nasty numbers, lots of calculations, or lots of given information to keep track of are the minimum for establishing this from the start as a tool to help do other things, not an end in and of itself.
Do not NOT

NOT

hand your students a spreadsheet that calculates everything for them. If a student wants to make a spreadsheet for a particular type of calculation, that’s great. That’s the student recognizing that such a tool would be useful, and making the effort to do this. If you hand them a calculator for one specific application, it perpetuates the idea among students that they have to wait for someone else that knows better than them to give them the tool to use. Students should have the ability to make their own utilities, and this is one way to do it.

Example from class yesterday:

We are exploring the way Newton’s Law of Gravitation is used. I asked students to calculate the force of gravity from different planets in the solar system pulling on a 65 kilogram person on Earth, with Wolfram Alpha as the source of data. Each of them used a scientific or graphing calculator to calculate their numbers, with the numbers they used written by hand (without units) on their papers with minimal consistency. They grumbled about the sizes of the numbers. When noticeable differences arose in magnitude between different students, they checked each other until they were satisfied.

I then showed them how to take the pieces of data they found and put them in the spreadsheet in the way I described above. In red, I highlighted the calculation for the magnitude of the force for an object on Earth, and then asked a student to give me her data. This was the value she calculated! I was quickly able to confirm the values that the other students also had made.

I then had them calculate the weight of an object on Earth’s surface using Newton’s law of gravitation. This sent them again on a search for data on Earth’s vital statistics. They were surprised to see that this value was really close to the accepted value for g = $latex 9.8;m/s^2$. I then asked them in their spreadsheet how they might figure out the acceleration due to gravity based on what they already knew. Most were able to figure out without prompting that dividing by the 65 kilogram mass got them there. I then had them use that idea and Newton’s Law of Gravitation to figure out how to obtain the acceleration due to gravity at a given distance from the mass center of a planet. I then had them use the spreadsheet model on their own to calculate the acceleration due to gravity on a couple of different planets, and it went really well.

The focus from that point on was on figuring out what those numbers meant relative to Earth. Often with these types of problems, students will calculate and be done with it. These left them a bit curious about each other’s answers (gravity on Jupiter compared to the Moon) and opened up the possibilities for subsequent lessons. I’ll write more about how I have grown to view spreadsheets as indispensable computing tools in the classroom in the future. A pure computational tool is the lowest level on the totem pole of applications of computers for learning mathematics or science, but it’s a great entry point for students to see what can be done with it.

Files:

Spreadsheet Calculation Template

Centripetal Acceleration of the Moon – a comparison we used two days ago to suggest how a 1/r^2 relationship might exist for gravity and the moon.

Bringing robotic cars and Udacity to my classroom

I was really excited to learn about Udacity, a new online education system that premiered two courses on February 20th. That a course on programming a robotic car would appeal to me is probably not surprising to anyone that knows me. I also love having yet one more excuse to continue learning Python, especially one that gets me working with an expert in the field such as Professor Sebastian Thrun. I recall reading about him shortly before his team’s successful bid at the DARPA Grand Challenge, and have since seen his name repeated at many key moments along my development as a robotics enthusiast.

The course is structured really well, with short videos introducing concepts, quizzes and programming tasks (with solutions) along the way to check comprehension, and homework assignments. The students love that I have homework.

I am busy, but this was too cool to pass up.

I also have a pretty hard time hiding the things I’m enthusiastic about in my classroom, so the content of the class has been something I’ve mentioned and shared with students at the start or end of planned activities. The whole classroom gasped at this video from the 25th second onward:
[youtube http://www.youtube.com/watch?v=bdCnb0EFAzk?feature=player_embedded&w=640&h=360]

Based on that reaction, I really wanted to give them a sense for the things I was learning to do. The first week centered on learning about localization – a process that uses probability calculations to estimate the location of the car using sensor readings and a map of the surroundings. I did a quick overview of what this meant as a filler activity to break up work during class, but wanted to find a way to do much more.

Today’s Algebra 2 class was going to be missing a couple students that are attending a Model UN conference, so I figured it would be a good time to try something different.

We started with the following warm-up problems:

Mr. Weinberg tells you we are guaranteed to have a quiz one of the days between Monday and Friday. He tells you that the probabilities of the quiz happening Monday through Thursday are 0.1, 3/8, 1/16, and 36%. What is the probability that the quiz will be on Friday? On which day is the quiz most likely to occur?

This helped review the total probability principle which is key to understanding the localization algorithm. We also did a review of finding the probability of compound independent events, first with a tree diagram, and then using multiplication and the counting principle.

We then went through the following activity for the rest of the period:
Robot Localization activity

I adapted parts of the course material provided by Udacity, primarily simplifying language, cleaning up diagrams, and adjusting the activities for my students who do not have any programming ability. We did have a Python activity back in October, but installing and running Python was a hassle on the 1-1 Macbooks with OSX since I was trying to do it with Python 3 and IDLE. It was only shortly afterward that I learned that an earlier version of Python was automatically installed. Oops. For this activity, we used http://repl.it/ to do the programming. This worked fantastically well.

The students seemed to do really well with the introductory material and filling things in, and modifying the basic programming went smoothly. They ran into some trouble around problem 7, which I half expected – that was the first part of the activity when I told them to do something without any rationale behind it. Most were generally able to implement the procedure and get to problem 9, but at this point at the end of the day on a Friday afternoon, fatigue started to take over. This was after around 45 minutes of working on the activity.

I added a section on motion for possible use in another class, as I ultimately would like them to be able to throw my own homework solution code into a simulator provided by Udacity user Anna Chiara. I did not deal with any of the sensor probability or move probability. The intuition for understanding how those apply in the algorithm is a bit subtle for the background of my students, and would take more of an investment of time than I think my students have the patience for at this state. I think it would be easier to talk about how these issues exist, and then have them observe what they mean by looking at the output of the program.

All in all, it was a cool, low-key way to share my own learning with students after an exhausting week. I think we all needed a bit of a change.

Getting started with LEGO Robotics – the book and the real thing.

This week I got a special early holiday present in my mailbox from my friend Mark Gura. Mark had invited me a couple years ago to be part of a book for helping teachers new to the field of LEGO robotics get started with their students. We had a great conversation one evening after school over the phone during which we discussed the educational goldmine that building with LEGO is for students.

Mark did this with a number of people with a range of LEGO robotics experiences, wrote up our conversations, and then combined them with a set of resources that could be immediately useful to novices in the book.

The book, Getting Started with LEGO Robotics, is published by the International Society for Technology Education. If you, or anyone you know, is just getting started with this exciting field, you will find some great stuff in here to help you work with students and get organized.

It was a particularly perfect time for the book to arrive because we have a new group of students at my school getting started themselves with building and programming using the NXT. My colleague Doug Brunner teaches fifth graders across the hall. He volunteered (or more realistically, his students volunteered him) to take on coaching a group of students in the FIRST LEGO League program for the first time. After building the field for this year’s challenge, today the fifth graders actually got their hands on the robots and programming software. I had the robots built from the middle school exploratory class available so the students could immediately start with some programming tasks.

We started with my fall-back activity for the first time using the software – program the robot to drive across the length of the table and stop before falling over the edge. The students were into it from the start. I stepped back to take pictures and Doug took over directing the rest of the two hours. He is a natural – he came up with a number of really great challenges of increasing difficulty and wasn’t afraid to sit down with students to figure out how the software worked. By the end of the session, the students were programming their robots to grab, push, and navigate around obstacles by dead reckoning. It was probably the most impressively productive single session I’ve ever seen.

It’s always interesting to see how different people manage groups of students and LEGO. Some want to structure things within tight guidelines and teach step by step how to do everything. Others do a mini lesson on how to do one piece of the challenge, and then send the students off to figure out the rest. Some show by example that it’s perfectly fine to get something wrong in the process of solving a challenge by working alongside students. It was impressive to see Doug think on his feet and create opportunities for his students to work at different paces but all feel accomplished by the end of the day. It is also really unique to have to tell a bunch of students at 5:15 PM on a Friday to go home from school, and yet this has now been the norm in the classroom for a couple straight weeks.

Having robotics in my teaching load means that I am thinking about these ideas interspersed among planning activities for my regular content classes. There’s no reason why the philosophies between them can’t be the same, aside from the very substantial fact that you don’t have to tell students how to play with LEGO but you do often have to tell them how to play with mathematics or physics concepts. It’s easy for these robotics students to fail at a challenge twenty times and keep trying because they are having fun figuring it out. The holy grail of education is how to pose other content and challenge problems in the right way so it is equally compelling and motivating.

Note that I am not saying making content relevant to the real world. One of my favorite education bloggers, Jason Buell, has already made this point about why teaching for “preparation for the real world” as a reason to learn in the classroom is a flawed concept to many students that have a better idea than we do about their reality. I never tell people asking about the benefits of robotics that students are learning to make a robot push a LEGO brick across a table now because later on they will build bigger robots that push a real brick across the floor. Instead I cite the fact that seeing how engaged students are solving these problems is the strongest level engagement I have ever seen. The skills they develop in the process are applicable to any subject. The self esteem (and humility) they develop by comparing their solutions to others is incredible.

This sort of learning needs to be going on in every classroom. I used to believe that students need to learn the simple stuff before they are even exposed to the complex. I used to think that the skills come first, then learning the applications. Then I realized how incongruous this was with my robotics experiences and with the success stories I’ve had working with students.

Since this realization, I’ve been working to figure out how to bridge the gap. I am really appreciative that in my current teaching home, I am supported in my efforts to experiment by my my administrators. My students thankfully indulge my attempts to do things differently. I appreciate that while they don’t always enthusiastically endorse my methods, they are willing to try.

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.
[youtube http://www.youtube.com/watch?v=As1JNGVPh0M&w=420&h=315]

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!

NOT

Example from class yesterday: