 |  | 
|
The task was to design a basic autonomous platform on which to build our battle robots. It had to drive around continuously in a complex obstacle course without getting stuck. We also needed to use as few sensors as possible to keep the lag down.
This is what I came up with. You could drop it in a circle of cargo containers with random junk strewn about, and it would continue to drive around, swerving to avoid the walls and intervening obstacles. I had to use sawblades as wheels to keep a narrow profile outside the two forward sensors. If it ever got stuck for any reason, it would initiate an "Un-Stick Manoeuvre" which involved terminating forward thrust, backing up for half a second while turning in a random direction, then resuming forward motion relying on the turn-sensors to complete the self-extraction.
Technical Details
Logic Gates and Comparators are the fundamental building blocks of this device, they are color-coded as follows:
| Pastel Green | NAND |
| Pastel Blue | AND |
| Pastel Orange | NOR |
| Yellow | Less Than |
| Orange Yellow | Greater Than |
| Blue | Multiply |
| Light Blue | Add |
| White | Function(Timer, Random, Numeric Storage) |
These logic circuits are driven by input from the following sensors:
| 2x Forward | Rangefinder |
| 1x Center | Speedometer |
| 1x Center | Power Switch |
The Multiply chips are used as amplifying relays to the forward and turning thrusters, allowing me to tweak the performance envelope in the field by modifying the Constant Value storage devices.
Problem: Approaching wall at an angle, or a narrow obstacle on one side?
Solution: Turn in opposite direction of the side on which the range sensor was tripped.
Reason: There is likely to be more clearance on the side which did not sense an obstruction.
Problem: What if both left and right range sensors are tripped due to steep angle of approach at velocities reducing the course-correction latency window to below the isolation condition?
Solution: In this case, one sensor is guaranteed to have fired first, so all we need to do is pass the two sensor inputs through a Quad-NAND Gate with two internal references, and drive the turning thrusters from their output.
Reason: The four NAND gates are configured to be sensitive to initial conditions; as long as one input is triggered(true), this will force a second input to read (false) even when triggered, until the first input is released, allowing the second to take precedence if it is still triggered(true). Thus, the rover will complete its evasive manoeuvre based on the first input it receives in the case of redundant inputs.
Problem: Stuck on something(This is rare, but inevitable with such a narrow sensor spread. Usually happens when a wheel gets caught on a sharp corner)
Solution: Continuously monitor velocity, if it drops below an acceptable value for more than 2 seconds, initiate a 500ms backup procedure followed by a 500ms turn in a random direction. Forward Sensor input must be suppressed via the Quad-NAND gate during this procedure.
Reason: Once I added this feature, contained in the two grid-arrangments of chips on the lower portion of the vehicle, I was able to drop the rover into the obstacle course and walk away for hours to build other things like catapults and airships. Flying over the obstacle course at a later time revealed the device to be happily roaming free!