A Collision-Detecting Robot

Overview:

In our final project, we intended to create a functional collision-detecting and avoiding robot. Utilizing the Atmel 8051 microprocessor, two polaroid sonar devices, inverters, motor drivers and motors. Our current implementation is bare-bones, approximating the functioning of the motors by way of a segmented LED display. Our end aim was to create a right-edge-sensing robot such that it could "feel" its way through a maze or similar structure. Here we describe a basic obstacle-avoidance implementation and are including our proposed modifications for the right-edge-sensing format later in this page.

Hardware Architecture:

Please refer to the schematic diagram for a more thorough presentation of the layout. A basic block/flow diagram is below:



Currently, excepting potentially any motor drivers, all devices are run on +5V powered off of a common board. The following pins on the 8051 are used for the following utilizations:


1. T2EX (P1_1): input - this is where the echoes from both sonars are tied - they trigger an interrupt.
2. P1_2: input - this pin corresopnds to the left sonar echo - used to differentiate the two sonars during an interrupt.
3. P1_5: output - a common Init line for both sonars.
4. P2_1: input - this is connected to a pushbutton, which starts the device.
5. P2_2: output - this is connected to a LED that signals that the left sonar is within minimal distance.
6. P2_3: output - this is connected to a single LED, which displays device ready.
7. P2_4: output - this is connected to a LED that signals that the right sonar is within minimal distance.
8. RXD (P3_0): output - this corresponds to the left motor, input A - implemented as an LED currently.
9. INT0 (P3_2): output - this corresponds to the left motor, input B - implemented as an LED currently.
10. T0 (P3_4): output - this corresponds to the right motor, input A - implemented as an LED currently.
11. RD (P3_6): output - this corresponds to the right motor, input B - implemented as an LED currently.
12. XTAL1: input - the clock input.
13. !EA and VCC: both tied to +5V.
14. GND: tied to ground.

The sonars, when they recieve an echo, pull their ECHO lines high. Since we have implemented the interrupt using timer2, with a negative-edge interrupt (capture mode), we run the ECHO lines of both sonars through inverters, so that the negative-to-positive edge transition appears as a positive-to-negative edge transition to the 8051, thus triggering an interrupt. To descriminate between the two sonars during an interrupt, the ECHO line of the left sonar is also diverted to pin P1_2, prior to inversion. If the interrupt routine does not find this pin high, then the right sonar is acknowledged as the source of the interrupt.

Click here to view the parts listing!

Software Architecture:

Please refer to the c51 code for this project.

Global Constants:

1. WAIT_FOR_NEXT_MEASUREMENT: This value is adjustable, and represents roughly the time between sonar INITs. Ideally, the busywaiting would be miminized using an internal counter such as Timer0. Regardless, as no additional devices are driven by the processor other than the sonars, it is not of great importance until such time as additional functionality is added.
2. DELAY: This is an approximation, allowing for instruction delays, of the time that the echo line of the sonar should be ignored before interrupts are paid attention to. This value was derived through experimentation.
3. TOO_CLOSE: The measurement that we receive from the sonar is compared to this value so that we can define a "safe" range, and a range in which a collision may take place. This value is derived through experimentation, and can be changed to adjust the distance that the robot must keep from objects.
4. MOTOR_CONSTANCY: This value simply reflects the number of loops in which flags will be maintained. When a sonar triggers an interrupt, the interrupt handler flags a value dependent upon which sonar is the source. Having both flag bits high has a differeent effect in most cases than having merely one. If this value is increased, the motors will change direction less-frequently, and if it is decreased, the robot may be too sensitive. This can be confirmed through experimentation.


Global Variables:

1. sonarValue: This is a upper slice of the bytes captured in Timer2 when the interrupt is triggered. It represents the distance as measured by the sonar devices. Only the minimum distance of the two devices is recorded.
2. trigger: This is a bit value that records if the start button has been pressed.
3. ignore: This bit is set at the start of the DELAY loop and cleared before recording the result of a sonar measurement. IF the interrupt is entered prior to this bit being cleared, then the major operations within the handler are ignored, and the processor is put back to sleep.
4. left_triggered: This bit records a minimal distance from the left sonar.
5. right_triggered: This bit records a minimal distance from the right sonar.

When the device is started, the motor outputs are set for it not to move until the 8051 receives some values from the sonars. Additionally, all timer and mode registers are set, and interrupts are enabled (however, the timers are off). The device then waits until the pushbutton is pressed, indicating to it that it may begin. It then enters a continuous loop.

In this loop, the following happens: the 8-segment display is cleared (in a motorized version this may be commented out, as it will cause the motor to briefly slow or stop ), the robot is told to go forward briefly, and then the trigger flags for the sonar are cleared. It then enters the "for" loop, in which flags are maintained.

In this inner loop, the following occurs: INIT goes high on both sonars, they enter the "ignore" phase for a brief while, and the microprocessor goes to sleep until interrupt.

In the interrupt handler, assuming that the interrupt occurs after the "ignore" phase, the following occurs:
1. The Timer2 flags are cleared.
2. The high and low capture bytes of the timer are sampled and divided by 16 (>>4). This puts the values into a range that is easily managable and minimizes some level of error in the sonars.
3. If the value is within proximity to the robot, then the P1_2 pin is checked.
4. If that pin is high, then it is left-triggered. Otherwise it is right-triggered. The appropriate bit is set.
5. Timer2 is turned off and INIT is pulled low.
6. Registers are cleared.

After getting a value, and after the return from interrupt, the sonar trigger bits are looked at to set the motor driver inputs appropriately, and then the device delays, both to allow the motors some time, and to give a gap between sonar pollings.

Note that the 8051 does not drive the motors: it only indicates to the drivers the direction of those motors. The motors move more or less constantly. They should move forward, respond to an object, spin, and go forward again, provided there are not more obstacles ahead.

Proposed Modifications:

As we had planned to make a right-edge "feeling" robot, the following modifications would need to happen:
1. Rather than have one right and one left sonar, we would instead have one in front and one on the right-front side of the body, pointing in a rightward direction
2. The interrupt handler is fine, and should work well. The other major change is in the algorithm that changes control bits on the motors. The movement of the robot should proceed in a right-curving fashion. To implement this, rather than moving forward, as in the above implementation, we should move some proportion of the time forward and the remainder turning to the right.
3. The robot should never just spin to the right to avoid things. Only turn left away from the obstacle, and then resume the rightward-turning motion.

Notes:

We initially had planned on creating this robot using the RTX 51 OS for the 8051. After much labor, and errors involving timing issues and timer usages by the OS, we scrapped this in favor of writing it all in c51 code. Many hours were wasted attempting to make the RTX 51 OS work alongside the sonars, unsuccessfully. The work with c51 turned out to be much more fruitful, and were quickly able to get some results. It did however, take some time to find decent constants so that (1) our values were good, and (2) the sonar didn't freeze due to it never receiving an echo.

As earlier stated, we had hoped to attach motors and get some more physical experimentation with the device. However, we were unable to get the needed hardware in time, and instead approximated results with LEDs. We estimate that upon adding actual motors we would need some additional time to play with constants and the motor bit-setting algorithm.

Contact:

To contact the devoted laborers that contributed many trying hours staring at this project:

• Demian Raven
• Man Chun Liu