Reverse Engineering with Loop Blocks

Last week, I introduced students to the loop block in the Robot Educator. Afterwards, I produced the program below but did not show it to the students. Instead, they observed the robot's actions based on the program. Their challenge: to observe my robot and reverse engineer a program that would make their robot mimic mine.

The first group came up with their program and we set our robots side by side. Pretty darn close, if you ask me. The robots are to lead in with 3 seconds of Love eyes on the display; keep the Love eyes throughout the program; rotate roughly 180 degrees; click twice and repeat indefinitely until the touch sensor is pressed; display Dracula mouth for 5 seconds.

The students produced a program quite a bit different than mine, indicative of the fact that there is more than one way to solve a problem.

This was a fun challenge. I am hoping to get all seven robots doing this together in sync. I would be willing to bet that there would be at least 4 different solutions to this. In addition, some of the students are designing their own reverse engineering challenges. Check back here later for updates. 

Classroom Conflict: Old Teacher vs. New Teacher

Today, I present two conflicts between Old Teacher, stuck in the traditional teacher-centered mindset of teaching, and New Teacher working in a progressive student-centered mindset.

My students were learning about the Loop block in the EV3 software. They were using the tutorial in the Beyond Basics palette of the Robot Educator. The program looks as shown below:

"Mr. Kahn, we got it." One group shouted to get my attention. As I watched their robot go through the program, I realized that yes, indeed, they did have it. As they pressed the touch sensor the loop was interrupted and the robot stopped. Before I was able to tell them to move on to the next step in the tutorial, one of them said "Can you use the touch sensor to turn it on?" Decision time. Old Teacher would dismiss the question and tell the students to move on to the next step. Old Teacher would tell the students to complete the tutorial, maybe because Old Teacher doesn't at that moment know the how to solve that very problem. New Teacher would say "Great question. Give it a try. See if you can make it so that if the touch sensor is pressed again, the robot continues." I ask: Which activity would the students be more interested in? Which teacher would be more effective in inspiring students to explore, take risks and learn?  New Teacher won the battle and the two students looked at each other, ideas flashing in their eyes as they attacked to the computer. 

Scanning the room to assess the progress of the other students, I saw this:

Old Teacher would have responded by telling the students to remove their extra pieces because it was not in the tutorial within the software. Old Teacher would have told them to get back to programming. New Teacher would have reacted by commenting on the new features in some positive manner to encourage the students' desire to design and build, maybe even making some suggestions about how to stabilize the structure. Or New Teacher may have just smiled to himself, not said anything at all and allowed the kids to keep their unique modifications. The end of class arrived. The students powered down their robot and placed it into the cabinet in the above configuration.  

I have a confession to make: I am both those teachers. Old Teacher exists within me, but New Teacher is muscling him out of the way. The thoughts of Old Teacher live briefly before the thoughts of New Teacher slay them and take over. There may be moments when Old Teacher is necessary to summon, but presently, New Teacher is in complete control, and I am truly enjoying this more natural and satisfying way of teaching and so are my students. 

EV3 Wait Block- Ultrasonic Sensor

Last night I spent nearly two hours trying to figure out the introductory program called Stop at Object using the ultrasonic sensor in the Robot Educator.

An ah-ha moment came when I realized that when the wait block's mode for the sensor was changed to "compare" from "change" that I needed to adjust the "less than, greater than" parameter. I felt better about having to teach this on the next day to my students.

There was still something nagging at me though, so I resolved to call up LEGO Education in the morning. I did, and Tim, the fellow I spoke to was extremely helpful. 

My question: What is the exact meaning of the "compare" mode and the "change" on the ultrasonic sensor when using a wait block? I tried the help menu and it was sort of helpful, but I needed to hear it explained from a person. 

Here is what I found out: 

The "Change" setting for the mode refers to a change from an initial reading of the sensor. For example, in the program above: 

Block 1- steering: results in the robot moving forward unlimited (forever) at a positive power parameter of 50. 

Block 2- wait: directs the robot to continue moving forward until the distance to the object has decreased (1) by 11 cm from the original distance detected by the ultrasonic sensor. Therefore it does not matter how far away the object is from the sensor. 

Block 3- steering: directs the robot to stop. 

Block 4- wait: wait for 1 second

Block 5- steering: using a negative power of 50, directs robot to go in reverse for unlimited or forever. 

Block 6- wait: directs robot to continue moving in reverse until the distance from the object has increased (0) by 6 cm from this second starting distance from the object. 

Block 7- steering: directs the robot to stop. 

Example: If robot starts at 25 cm away from object, it will move towards the object until it reaches 14 cm (25 cm - 11 cm). After a 1 second delay, the robot would then move in reverse, 6 cm back from 14 cm from the object to a final position of 20 cm (14 cm + 6 cm) from the object. 

The "Compare" setting was what I was looking for. This setting sets a threshold for the robot to cross before doing something. For example, using this setting a robot will move until it is a certain distance from the object.

There is one crazy thing that happens with the program above. I have put this to my students to figure out as a star-worthy challenge. If the robot is set at a distance from the object less then 11 cm, then it will just move forward forever because it never satisfies the parameter of being able to move 11 cm towards the object. In addition, my students have not figured out that the robots will move the same distance towards the object as long as the robot is 11 cm or more away from the object. If it were 50 cm away from the object, the robot will still only move 11 cm towards the object and then 6 cm back as long as there is not interference by anything in the surroundings. 

This is an excellent puzzle for my students to try and figure out. We'll see how day 2 goes.

PB & J Program

After several weeks of programming with the EV3 robots, it was time to conduct the classic PB & J Program Demonstration. The lesson was wildly successful. One particularly illustrative example of programming sequencing errors is shown in the images below.

The student did not specify the size of the slices of bread and therefore one is a cocktail size slice and the other is normal sandwich size. In addition, the student did not specify how much peanut butter or jelly to use. Finally, while it is not numbered, the last statement of the program suggests that "you can toast the pieces of bread." Certainly!

The rich discussion after the demonstration included comments such as: the robot does exactly what you tell it to do; our robots will not interpret directions; any errors that occur are a result of the programmer's program; also the errors are compounded, meaning that as more errors occur the final result is further off from the expected result. 

The basic idea that the programs need to provide very specific directions in order to achieve the desired result was grasped quite easily by students. In addition, the idea that it is a good idea to write and test one piece/task at a time, rather than the entire program. This makes it much easier to debug and problem solve. 

The demo took place during the first period of the day on Friday. What a way to begin the last day of the week. So much fun! 

Disclaimer: no properly functioning toasters were harmed during this demonstration. This toaster toasted only one side of the bread and the lever did not hold the bread down anymore. My son and I tried to take it apart and fix it, but my wife had already purchased another toaster at a garage sale. Isabel's PB & J program was the only one that mentioned a toaster. Perfect!

Brentwood School Newsletter Article

Robotics in the Classroom, A Two Way Street: Reflections on Teaching Robotics for the First Time