Running a Maze

This time, we got to do something with our VEX bots. The aim was to navigate a maze using no sensors besides the bot's internal clock. This means we had to calculate how much time it takes for the bot to travel a certain distance, then hard-code a set of instructions that allows it to follow the path all on its own.

Start in the lower right, and get to the X.

I was partnered with Everette, who's deaf and mute, but he was one of the people I wanted to work with, since he showed interest in the Robotics team earlier. (Plus, I always wanted to learn some sign language.) We have interpreters to facilitate communication too.

Everette seemed to think I should be be leading our efforts, which is cool, since I have some experience in this stuff, and love messing with robots and programming.

He took a picture of the maze on his iPad for us to reference while we prepare the robot and develop the program. I found that the bot needed about 400 milliseconds to travel one floor tile, and using that number as a unit (TILE_TIME), I quickly calculated some approximations of the steps that the robot had to take to complete the maze. I used functions like goForward(int milliseconds) that runs the motors for some milliseconds.

goForward(3500); // The goForward function multiplies 3500 it by TILE_TIME, then divides by 1000.
turnLeft(TURN_90); // TURN_90 is a constant that I recorded for how long it takes to turn exactly 90 degrees
goForward(3000);
turnRight(TURN_90); // etc...

It looked like this would turn out to be pretty easy, but we soon learned that the varying power given by the quickly draining battery made it much trickier. I figured something like this would happened, so I tried adjusting my constants like TILE_TIME to work for our current battery level. (e.g. increase TILE_TIME so a sluggish bot with a low-level battery could go the correct distance)
In the end, we didn't get quite enough time to perfect it, so our bot didn't quite succeed, but it did wind up pretty close to the end of the maze.

The battery was a bit lower than anticipated.

The next challenge was to use encoders to measure how far the robots have traveled. This solves the battery issue, since encoders measure how many rotations of the wheels have occurred, which gives us actual data, and accounts for any friction in the drive-train.

The big problem Everette and I ran into was purely mechanical. The encoders didn't seem to fit quite right on my bot, so we hastily switched over to Everette's. This turned out to be a bad decision, since his drive-train was problematic for ambiguous reasons. Its output was downright feeble on one side. We spent all the rest of class time trying to fix it, but never succeeded, so we went out to present without any prior testing.

The thing that I found hilarious was that even without any testing, my program's encoder counter was dead-on for the distances we wanted the bot to go. it attempted its first turn at just the right spot, but failed to complete it.