Rationale of Activity: Robotics is a medium through which students can develop 21^st century skills by thinking and learning in the ‘hands on’ classroom for application to undiscovered ventures.

Strategy

Fortunately for our team, Anne and I have had the opportunity to work together over the past two years as teacher and consultant sharing literacy strategies for her primary classroom. With this pre-established relationship we had an understanding of our methodologies and approaches to learning. The new challenge was how to combat such a task with robots – a medium neither of us felt ‘expert’ at. We decided, as good elementary teachers do, to follow the modules as outlined by the instructors of this course to experience some preliminary success. Therefore, we did not explore too many trial and error methods initially in fear of veering too far off course. As we were advised to operate off both computers, one person worked with the Mindstorm software and the other person with the NXT tutorials. Working side by side all the while ensuring both parties understood the same concepts and paused to take individual notes. As well, one was working closely with the robot manipulating and resetting programs and the other annotated code for recording our detailed findings for this logbook.

In terms of approaching the process of programming and both of us being fairly new to robotics we decided to follow the tutorials and structures put in place by the instructors of this course. We took organized notes of the steps we took to complete the phases of the challenge and copied the final code into our journals. We definitely got better at this as the day end approached and switched to an electronic-only system instead. I’m not very artistic so I didn’t make too many drawings because the way I learn best is through mapping and talking. I’m definitely a verbal processor and talked my way through the logical steps we wanted our robot to complete.

While learning through the modules we were constantly talking through how we were going to build our Tablebot making notes for where the links will be needed for later phases in the challenge. Ironically, we created an island unto ourselves and completely immersed ourselves into our approach of the challenge. Immediately, we chose the ultrasonic sensor and came upon our first challenge on how to attach it to the front of our robot. Settling that issue we built a code to send the robot straight on the table detecting the edge with the threshold value. For the most part we knew what we wanted our robot to do but had to spend some quality time figuring out how to write program in ‘robot language’. Big issues for us surrounded the areas of the threshold value, using the loop forever block and when a reset block was useful and when an alternative command was a cleaner or clearer way of fulfilling the same command. All our changes and programs were moving in a positive and forward direction to achieving our goal of successfully completing the Tablebot challenge. A long first day of the course but all the while successful and fun!

]]> http://soniasblog.wordpress.com/2009/08/04/tablebot-strategies/feed/ 0 soniasblog http://soniasblog.wordpress.com/2009/08/04/tablebot-issues-obstacles/ http://soniasblog.wordpress.com/2009/08/04/tablebot-issues-obstacles/#comments Tue, 04 Aug 2009 15:00:34 +0000 soniasblog http://newnxtportfolio.wordpress.com/?p=96 ]]> Issues and Obstacles

Feeling quite confident that if we followed the prescribed method outlined by the course instructors then we would definitely find success in the challenge but it was not as black and white as we anticipated. The first challenge was to attach the ultrasonic sensor. We did not really play around with which pegs and arms were used for which purposes and were surprised that our ‘creative’ way of attaching the sensor was appreciated by the instructors. It did work for our intended purpose but perhaps playing with the pieces and exploring the uses of the different components of the two kits would help in modifying future robot designs.

The next issue we encountered was multi-layered and evident after seeing the robot take action to the first phase of the task. We noticed the speed of the robot was too fast causing the read time and react time to fault due to distance covered. Between action and reaction, our Gertrude fell off the table. Like the fairytale goes “slow and steady wins the race”, we adopted that slogan for completing the rest of the challenge. The immediate changes included extending the sensor arm, slowing down the speed in which the robot travels as well as changing the threshold to the number between the surface of the table and the floor. This set us up to be ready for the remainder of the challenge to add the five stop and turns followed by the spin-o-rama.

The final obstacle we faced was the spin-o-rama. Although an instructor walked by and said ‘you’ve got it’ we knew it wasn’t a real spin. Visually it was true, the robot appeared to have completed the challenge, something made her spin at the end of the phase two task, but not due to our brilliant programming code. We committed to being honest and headed back to the computer to build a swing turn command code so Gertrude could really complete the challenge. As educators this is something we want for all our students – to be honest. Cheating doesn’t really prove anything. The great thing about building your own code is that there are so many possible right ways of completing the challenge. We thought that later on the learning from the ‘spin-o-rama’ would pay off and we wanted to be honest in our work ethic. Resulting in a truly successful challenge on day one!

One of the things we learned from our in-class presentations was to isolate the parts of the code that were working well to identify where the code was breaking down. We struggled with the spin-o-rama. Why did Gertrude spin all by herself? We simplified the code to the basics: one forward command on motor C and stop. To allow the robot to swing turn we added the opposite command on motor B – backward and stop. Now things were balanced and a swing turn should result. But no change. Gertrude didn’t appear to have changed her motion at all. We studied the whole code in action again, checking to see we were running the right program and downloaded the updated version. It appeared that all the while the robot was quivering – through every motion. This ending up being a physical error, not the table being unbalanced or the weight of the sensor being off-center, the wheel was actually on backwards. Wow, how things in the early building stage impact the results of the programming codes! Reset the program with the complete code and voila: success. Gertrude completes all phases of the task. A job well done, ladies!

Changing the speed of the motors was important. 50% power was fast enough for the task to be smooth enough between forward motion and turns at the edge of the table. The instructors commented on how the robot was managing at a good speed for the particular challenge.

The last obstacle we had was the threshold which allowed us to go back into our notes and the NXT powerpoints to verify the proper calculation of threshold values. Being accurate in our calculations is important especially with the ultrasonic sensor.

From a teacher’s perspective this challenge has so many valid points. Students can experience a wide range of successes that can positively influence their views on science and hands-on learning. From building the robots to adding parts to change the way the robot responds to its environment, from collaboration with a partner to problem solving through a task and from applying new knowledge to test a result to going back into the text to find where the modules address certain concepts. What a great way for teacher’s to empower the students to take learning into their own hands and celebrate the end results in which not all robots look or are programmed the same. Students can feel the success and struggles of authentic critical thinking for a real purpose and a real result that is meaningful to them. The self-paced approach allows for students of all abilities as well as support students who need to refresh their skills in particular concepts at any given time – the tutorials are there to be reviewed. The outlined document of the modules we were expected to complete would be the exact thing a student would need to scaffold through the necessary elements of this challenge. Junior high students would have the skills and background knowledge to take on this challenge. Younger students would have too many obstacles that would put them at a disadvantage to their older counterparts. Elementary students would need the three phases in this challenge broken down into smaller parts for them to achieve the results of the challenge.

Day two and we’re all fired up ready for the next challenge! Today we’re armed with snacks and treats to survive the day and not spend anytime away from the challenge. We also brought memory sticks to save our work electronically as well as a picture camera to capture our little Gertrude in action. Our first strategy, since we were both early for class, was to talk to other groups. That was one thing we did yesterday was isolate ourselves from others – which can be good and bad. Listening to others and how their group operated was important information if we could improve the process of programming and annotating our codes. Now we were ready for the next challenge. It is great to have the support of the different instructors for this course. Everyone has different skills and backgrounds that they bring to the class that as a ‘student’ I truly appreciate.

Luckily we found today’s tutorials really helpful. They were to the point and useful for the code we wanted to write and took the advice of the in-class presentations to chunk the tasks into manageable parts. We adopted yesterday’s strategy of “slow and steady” and put the power at 50%. Most of the morning was successful and progressive toward the first two phases of the challenge. We were driven to complete the tasks and be successful. As the tutorials were helping us decide which approach to use for writing the code for the “Robotracker Challenge” I took a few moments to jot down why I felt the morning had been so successful. I think a big piece of it was that my partner and I felt comfortable working together. I believe this is something that can be missed or taken for granted. Having a good working partner or someone who can work with you is extremely important. I hope classroom teachers who want to create an environment that encourages group work spends some time setting parameters for work ethic and incorporating building community activities to ensure participants feel safe and welcome.

Today’s challenge involved us using the threshold values which we somewhat struggled with yesterday. I mean the values worked well in our code but for some reason we kept tweaking the values. One thing that stood out for me in last night’s in-class presentation was a checklist of ‘all the things to consider before panicking that the code doesn’t work’. Simple things like check for power and/or that you are running the right program in the robot and the list goes on. I paused for a moment and thought that the light from last night in the room must be different than this morning’s sun-filled room. We played around with the light sensor values some more and opted for closing the blinds to control the light in our workspace. The number values of black to white to silver were quite particular – and so close (especially white and silver) that we couldn’t risk having other factors play a role as well.

So the strategy of the day was to focus on one thing – getting the challenge done. That being said we failed to be diligent with all the stages towards the end product. One of the issues we had with programming was transitioning between trials. Sometimes we were too quick to change our game plan. We would delete pieces of code that we wanted to change but left in icons relating to the old code. The thinking through of the ‘why’ for each piece of code was sacrificed in order to complete the challenge. I guess we felt like we were behind the other groups. The few groups around us weren’t completing the tutorials and headed straight for the challenge of the day. But we had a bigger vision for our participation in this course. We needed to know the tutorials, the resources available from NXT and Mindstorm so that we could use it with students in school. There was no point going straight into the challenge and backtracking when we came into difficulties. And we worried for nothing really. I believe we finished the day’s challenge approximately the same time as a few other groups. With the help of the instructors we had extra icons in our final code that didn’t impact the actions of our final challenge and cleaned things up by taking them out. Annotating parts of the code helped streamline this part of our challenge. So when all was said and done for the day, we went back and annotated some of our codes to remember why we did certain programs, why some didn’t work and how those stages lead us to the final phase of the challenge.

Another obstacle we had was turning. For some reason we weren’t simply writing point turns or swing turns into our code, we were rotating the wheels a predetermined number of degrees. This extra piece of code, instead of turn until, complicated our results. We weren’t sure why we were changing the degrees of wheel rotations but this, in retrospect, became an unnecessary element to our coding challenges. Luckily, it worked for us. We could control a lot of the unnecessary movements of the other robots. Ours ‘appeared’ smoother with her turns and less jerky while tracking the black line. We reduced the amount of swing on the turn for Gertrude at the end of the line track and headed for a more logical turn. (The video shown is the right code but for some reason a portion of the line track is skipped because the robot reads the line too late – ahhh, those girls have a mind of their own!)

Starting in the reverse direction due to the accuracy level of the light sensor positioned near the front (actually, the back) of the robot. Gertrude goes forward until a light sensor cues a value of less than 36 this trips the program into the loop and selects the if/then options. This loop is written if the value is greater than 48 it switches out of the loop when it reaches a value of 65, she toggles along the black line and reaches the new value determined by the light sensor. This is the line-tracking loop code for the first portion of the program. Once the loop is tripped the robot stops and swing turns left until the light sensor detects a value less than 48, the black line. But now we are returning along the same line but this time going in the opposite direction wanting to travel on the same side of the line. Hence the code here is flipped. After the line-tracking code is repeated it trips again once the value reads greater than 65, the tin, the loop ends and stops with a victory song!