Page 24 - Designing Autonomous Mobile Robots : Inside the Mindo f an Intellegent Machine
P. 24

Measure Twice, Cut Once

               So what could go wrong? The answer is just about everything! The first problem has
               to do with timing. If the task that gets the sonar ranges is actually running the sonar,
               or it must wait for the ranges to be determined by another system, then the length of
               time required to process the range information will vary depending on conditions.
               Furthermore, the calculations of the various states will take variable amounts of
               time. The reason that this is important is that the states must calculate accelerations
               and velocities, and to do this they must be related to a consistent time base.
               The final task of running the motors will be executing a control program that will
               also require consistent timing. It is therefore necessary that the program loop at a
               constant and known rate so that these calculations can be made. Reading a hard-
               ware clock is not an option, as the sampling rate of the system needs to be constant
               to assure stability. If the reader is familiar with filter theory, all of this will sound
               very familiar! The simplest solution to the problem of achieving constant timing is
               to eliminate the loop back to the top of the process, and execute the whole process
               from a timer interrupt.
               If we assume that the process is timer driven, it will be necessary to assure that the
               task is completed before the timer fires again. If the timer starts again before calcula-
               tions are complete, then partially calculated parameters may be overwritten and
               contaminated. A task like this one is thus said to be nonreentrant. Worse yet, re-
               peatedly reentering a nonreentrant task can cause the processor to eventually
               overflow its stack and crash. This can cause very strange and unwelcome behavior in
               our little appliance.

               Next consider the “straw man” scenario of Figure 1.3. Here our robot encounters a
               target on its left side (State 3), begins turning right, drives into the path of a target
               on that side at an even closer range (State 4). As it turns away from the target on
               the right, it goes back into State 3. The result is that the robot drives forward so that
               the closer target approaches along the right edge of the right transducer pattern
               until the robot comes to a halt, or worse, sideswipes the closer target (Figure 1.4).
               It has already become apparent that our control architecture is flawed. We must
               have a strategy for escaping from such a situation. One problem with our strategy is
               that we are trying to solve the problem instantaneously, without regard to the recent
               past. As soon as we begin to turn away from the closer target, we forget all about it,
               and react to the further target again. Truly, a robot that doesn’t learn from history is
               doomed to repeat it!







                                                        7
   19   20   21   22   23   24   25   26   27   28   29