Sunday, November 10, 2013

When a Challenge isn't Met

I created a challenge for my students called Escape in which the goal was to program the robot to find it's way out of the box. The students quickly realized that they didn't need to use any sensors at all, that they could just have the robot rotate around and go forward for a few seconds until it found the opening.


I adjusted the requirements and created Escape 2. This time the robot could not touch the walls of the box. Of course, they tried to wiggle out of this one by asking if the cords could touch. "Okay" I said looking at the cords sticking out of the back and thinking that would be fine. Then of course, one pair students takes all the cords out of the kit to wrap around the robot as a bumper. "No. That doesn't work."

Escape 2 turned out to be a fairly significant challenge. Several pairs of students were able to program the robot using the ultrasonic sensor to sense the long distance at the opening of the box and move their robot towards the exit.  But more often than not their robots would catch a wheel on edge of the opening and get stuck. Another group decided to rebuild their robot in a minimalist fashion by changing out the big wheels and tires on the base robot for thin wheels and tires.

Ultimately, this group and one other out of 6 were able to complete the challenge. As the teacher, what to do? We have spent a lot of time already on this challenge and I felt it was time to move on. Some nagging questions remained. Do I allow all students time to complete challenges? Is it okay to move on with some having not done so? My initial thought is YES, this is okay to do. In today's world where many kids are so quick to shout "That's unfair!" when one kid gets something and they do not, this seems like an important lesson. People have different strengths. Many kids expect everything to be easy and doable, and if it is not, they give up. Certainly, if a student wants to take some time outside of class to pursue the challenge, I would gladly provide that time.

Any thoughts, ideas or advice on this topic would be much appreciated.

Monday, October 28, 2013

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. 


Friday, October 25, 2013

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. 




Wednesday, October 9, 2013

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.

Friday, October 4, 2013

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!



Monday, September 30, 2013

Two Words, a Pause and a Smile

There are ten boys and three girls in Robotics Innovation Design this semester. One of the girls began the course very much engaged. The other two needed a bit more coaxing. One of these two girls did not even want to be in the course and lobbied heavily to switch to a different elective. Socializing, drinking water and going to the bathroom were the activities that she was most engaged in. That is why she stopped me in my tracks today with two words.

She and her partner, who are good friends outside of class, were designing their own challenge for the robots. Noticing them both hunched over the computer screen, I asked "OK. What are you doing?" She looked up at me, paused, and said rather matter-a-factly "I'm programming." 

I began to respond normally before I realized that this girl has probably never uttered those two words together before in her life. A beat went by. I smiled to myself and continued with my line of questioning. 

"I'm programming."

I love teaching robotics. Every single day brings something new, some realization by the kids or by me. It's just awesome. And I am quite stingy with that word. 


Wednesday, September 25, 2013

The Warehouse Challenge

Today was a great day. After barreling through many of the benchmark tasks like learning how to program the robots to move straight, turn, spin and reverse, the kids have been accomplishing various challenges. Two students, Eli and Asher are keeping me on my toes and forcing me to be super prepared each day. Yesterday, they completed how to capture and move an object. Today, I put it on them to build the next challenge for the students involving many of the moves they have learned including the capture object skill. Behold, The Warehouse, by Asher and Eli.
Robots will begin on the line, proceed forward to the Warehouse, capture the item within, maneuver somehow to exit on the right side and deliver the object in the square. That's one small square! Attempts should begin tomorrow. 

Monday, September 16, 2013

Robotics Benchmarks 1st Set

Today, the kids really began learning the EV3 programming software for their robots to make them move. They were following the Robot Educator, Basic instructions. They began with Straight Move. As they progressed, I realized that I needed some way to know quickly what the task was and a way to record their progress. I developed the following document for each team. They will keep these in their kits and give them to me when they wish to attempt a task or challenge.

RID Benchmarks Sem. 1

Thursday, September 12, 2013

Robotics Innovation Design

Robotics Innovation Design- new middle school elective
Today was the second day for my pioneering middle school robotics students working with the LEGO Mindstorms EV3 kits. The students opened the software and learned how to program one of the large motors while it was attached to the brick. Some of the things they learned are in the video below.


Below is an earlier video of the kids opening and organizing the EV3 kits.