Instruction Guide: Obstacle Detection

In this lesson students explore the technique of embedding a Switch block inside of a controlled loop in order to accomplish continuous obstacle detection.

In the previous unit, under "Repeating Behaviors", the students created a program for a Sensor Controlled Loop that was intended to stop for obstacles. However, what the program actually did was only check for the obstacle periodically and not continuously. The students should have discovered this was due to the fact that while the loop was controlled by a ultrasonic sensor, inside the loop were blocks that took some time to complete, so the robot only looked for obstacles once every few seconds. The solution to this problem is to reverse roles and have the ultrasonic sensor quickly and continuously check for obstacles inside a loop that controls how far the robot moves. The introduction of the Switch block in this unit enables this capability.


Have students work through the "Obstacle Detection" lesson on the "Behavior"s page in "NXT Video Trainer 2.o".


As students progress through, have them document their milestones in the Obstacle Detection Task Assignment Sheet.

For this Task Assignment, final teacher sign-off is the Sentry Challenge, Phase 2 . Although, at first blush, this sounds like a simple extension of the previous unit's Automated Sentry Challenge , in reality this challenge involves integrating and extending a great deal of the skills learned to date. Many students find this the most difficult challenge in the entire NXT Video Trainer series. If students get bogged down at this point, it may be useful to introduce the next sub-unit. Flow Charts II, to help students organize their approach to this challenge.

Sentry Challenge, Phase 2

There are five key stumbling blocks for students with this challenge:

• Software Design: Students need to break the challenge into separate behaviors and then assemble them into a Flow Chart (as covered in the first Flow Chart lesson). This involves using Decision blocks to create parallel branches rather than simple wait blocks - an new concept for students. It may be helpful to walk through the first few slides of the Flow Charts II lesson as it uses this challenge as an example to develop the idea of Subprocesses.
• Incremental Design: Once students have a flow chart to represent their design, they are tempted to jump in and write the whole program at once (especially since they already did the Automated Sentry Challenge). They need, instead, to tackle the software development incrementally as shown previously - get one small piece working and then incrementally add additional small pieces, checking the program as a whole between each increment.
• Lagging Loops: Students often start with a Ultrasonic Switch Block, and place a Stop block on one branch and a Move block on the other. While this is the correct structure to start with, students are usually tempted set the Move block for the duration required to cover one side of the building. However, this is exactly the problem they had with the Controlled Loop Challenge of the "Repeating Behaviors" lesson - if they build a delay (wait-for x seconds, or y rotations) at the core of their Switch Block loop, then the robot will only check for obstacles once per side of the building, rather than continuously. The Switch Block at the heart of a loop must execute without delay, and therefore any Move blocks should be set to "unlimited" (i.e. turn the motors on and then immediately run the next step in the program).
• Nested Loops: To be its most efficient (i.e. smallest number of blocks), this program will have a switch block nested inside a loop (for obstacle detection over a distance) and this inside another loop (to control travel around the building). This can be a very confusing NXT-G program and highlights the need to start with flow chart to keep organized and use comments in NXT-G to keep track of what's what.
• Rotation Sensor Reset: Students have used the rotation sensor to control loops a few times, however, in each of these cases the loop was only run once. Since all sensors are reset to "0" at the start on a program, this method has worked fine up until now. However, the nested-loop structure on this program means that the rotation-sensor-controlled loop is going to run more than once. It will likely work as expected the first time, but on subsequent passes through the outer loop of the program students will get unexpected behavior. They need to understand that they must reset the rotation sensor back to "0" before each pass, otherwise the sensor will continue to accumulate the ever increasing rotation count. This reset must be placed inside the outer loop, but outside the inner loop to have the desired effect. The sensor can be reset using the Reset Motor block or selecting the "Reset" option on a Rotation Sensor block - both of these blocks are found in the complete palette
  • Placing as black line at each corner allow students to control their loops with a light sensor (instead of the roation sensor) ands elminiates the above complication with resetting the rotation sensor.  This alternative approach in shown a in the Challenge Sheet and mentioned in the "hints".

When signing off the Sentry Challenge Phase 2:

• Start with their flow chart to get an overall view of the program
  • Ask how they developed this flow chart
• Use the NXT-G program to show how each block in the flow chart was implemented (including comments that identify the flow chart blocks)
  • Ensure they have no lag in their core Switch block
  • Have them describe the nested loops
  • Ask how they overcame the rotation sensor problem (if used)
• Ask about the program development process - did they use the incremental approach recommended here
  • What other "Best Practices" would they recommend for program development
• What obstacles (no pun intended) did they encounter and how did they overcome them.