Original for anyone who needs it idk

As I alluded to this was the final lab project for my class on microcontrollers. Microcontrollers are small computers used all over the damn place. They're mainly distinguished from say your phone or PC by being cheaper (i.e. this one is five bucks a pop if you buy in bulk, and still less than ten if you don't) and slower (80 MHz max clock here), which is usually fine for the application. My entire class made robots like this and most of them were fancier than mine. 3D-printed cases for the screen and shit, man.

The robotics platform is a PIC32 microcontroller board mounted on a solid surface. The surface has two motorized wheels screwed to it in the front, and a sort of friction stand in the back, basically just a piece of plastic to keep it balanced. The robot is powered by four AA batteries (did not realize how few things use these any more until I had to find some) providing a voltage of 5 V.

The motors are DC, and the lines between the microcontroller and the motors are intercepted by an H-bridge allowing the motors to be run in either direction. The motor lines also have rotary encoders and variable voltage controlled digitally with a simple PWM mechanism, but I didn't use either for this.

The sensors are three reflective infrared sensors mounted facing downwards in the front of the robot. The table (white) is reflective, and the electrical tape path is not. The sensors themselves are analog but their output is fed through a potentiometer ("pot") which provides a threshhold for a digital output. tl;dr the robot gets three bits input, one if the sensor sees white and zero if it sees black, assuming the potentiometer is adjusted correctly. Which took me half an hour of twisting a screwdriver back and forth repeatedly.

There's also an LCD screen piled on top haphazardly. I don't think you can see it in the video, but it says "left" when the robot turns left, and "right" when it turns right. I did that out of a combination of showing off (learning how to use the LCD was optional) and making sure my function to turn left was actually turning left.

The actual control, i.e. the part I did, is very simple. The program was written in assembly. After some initialization the program enters a main loop, which reads the sensor values and compares the read value with the last sensor read; if it's changed, it adjusts the motors. The check is so that it doesn't try to reorient the motors every twenty cycles. The microcontroller clock is 80 MHz, so I mean, futzing with the motors every 250 ns... not good.

The possible motor configurations are looked up in a table, i.e. all eight combinations of the three sensors have a table entry saying essentially "forward", "left", or "right". As I said earlier, the voltages to the motors aren't adjusted, and all the program changes is the directions of the motors. For "forward" they're run forward, and for "left" and "right" they're run oppositely to turn the bot in place.

The core of the logic is basically one line of C, "while(1) direction = (30481 >> read_sensors()) & 3;". 30481 is the lookup table, giving two bits for direction (one for each motor) for each possible sensor combination; in binary 30481 could be written 01,11,01,11,00,01,00,01. For example if the sensors read 101 - reflective surface on the sides, nonreflective path in the middle - it would count over five from the right in that comma-separated list and find 01, which drives the robot forward. In reality I used some motor control functions I'd already written, so it's the equivalent of more like 20 lines of C, but I think this is clearer to explain.

Therefore the robot doesn't make its "decisions" based on any internal state, unless you count the motor adjustment timing thing I already explained.

This has advantages:

It is really really dirt simple, which is great when a combination of procrastination and finals week have left you four hours to do your final project.

Debugging is mostly a matter of fiddling with the pot and speed settings.

The lookup table says to go forward if there's no path in sight, so you can put it pretty much anywhere on a table and it'll just charge forward until it finds a path.

If there's a break in the path, as some of the other paths not in the video have, it just goes straight across it, for the same reason.

The sensor loop is extremely fast, so if the pot is configured correctly the robot can make arbitrarily sharp turns assuming it's moving slower than a few kilometers per second.

The disadvantages:

It's unreliable - this video was my third attempt at getting something suitable for film.

If it comes up on a T intersection from the base of the T it will just keep going forward, rather than staying on one of the divergent paths.

Sometimes if it comes up on a 90° turn at a bad angle, all three sensors report nonreflectivity, so it doesn't turn and just charges off the path instead.

Seriously, it's unreliable. I had to keep futzing with the pot as the batteries ran down. Ugh.