Intro:
The following is a detailing of the final design of the robot that competed in the Robotics Day 2018 Competition.
Hardware:
Line Sensors:
While the line following is fairly decent, it sometimes corrects too far or causes the robot to move in an awkward fashion. It also sometimes causes the robot to mess up while turning off an intersection due to it being off-center. This is mostly due to the large space between the line sensors. A potential fix would be to either put the sensors closer or to have a third line sensor in the middle. We could have also properly implemented PID control if we had the time.
IR Sensors for Wall Detection:
Our wall sensors often worked, but sometimes the robot obviously would crash into walls. The wall detection code is based off set thresholds, but our searching algorithm can sometimes clash with the wall detection, and the robot decides that it should move towards an unvisited node behind a wall anyway.
Microphone:
The final robot has never started without an actual button press. An simple resistor and button circuit is used to trigger a start as the pin state transfers from high to low. After the lab involving creating the 660 Hz tone detection, the circuit was proto-boarded. After this transfer of circuitry, its functionality was destroyed and was inaccurate and unreliable.
IR Detection:
The IR Detection of the robot was a protoboarded version of the result of Lab2. The circuit was able to take up a very small amount of space on the robot as it was shrunk to a 4cmx4cm circuit.
Servos:
Two days before the competition, our right turns stopped being in place because one of the servos stopped responding to the command to spin counterclockwise, so we changed all of our U-Turns to be based on the left turn rather than the right turn. This suggests that the servos are among the weakest links on the robot.
Protoboard:
An additional simplification made for the wiring of our robot was to create a power ground protoboard. The board had two long rails for both power and ground connections at a difference of 5V. The protoboard allowed for a simplified wiring of the entire device and allowed the wires to remain quite short overall.
Final Robot Construction
Software:
Line Following:
Our line sensors are mildly sensitive to differences in lighting, and only one sample is read every decision, but the loop only consists of a short three branch if else block, with ir detection happening every 20th time through the loop. This allows incorrect readings to quickly be corrected, and prevents the robot detection from interfering with line following stability. When an intersection is detected, the robot stops before reading the wall sensors and making a decision for the next square to explore, then continues through the loop.
Wall Detection:
Our wall sensors average 16 readings before making a decision, and the robot stops before making those readings, so given properly aligned walls, the robot detects walls very robustly. Due to not wanting to detect phantom walls, the thresholds are set not to detect farther than approximately 3/4s of a square away, and sometimes will miss a wall that is poorly placed.
Robot Detection:
The IR detection worked most of the time, and we were able to reduce the memory space taken up by the FFT by reducing the number of samples actually taken, as well as decreasing the total time to run the FFT by only sampling the values that were relevant for detecting robots. Improvements could come from trying to optimize the number of samples taken to balance memory space with robot detection.
Search Algorithm:
The current implementation of the search algorithm uses a neighbor array and visited array to keep track of nodes it should visit and nodes it has already visit. Everytime we hit an intersection, we check if there are walls to the front, left , or right. We then add to the neighbor array based on which direction does not contain a wall, and we just store the x and y coordinates to visit. We also store the x and y coordinates of the nodes that we have visited. The algorithm chooses to continue to a neighbor that is within one square of the robot’s current position. If there is no neighbor within the one square proximity, then we move to the visited array to backtrack to a previously visited node. From there, we ensure that we don’t re add nodes to the neighbor array by checking if had visited the node before. Finally, we can check for a neighbor again and the robot continues from there. This search algorithm has worked on the nine by nine mazes and also functions exceptionally well on smaller 5 by 4 maes. It has shown the ability to avoid nodes that we have visited before and move towards nodes in the neighbor array, but needs more robustness to incorrect wall detections.
Sending Maze Information:
Our transmission data was an unsigned long that consisted of an x coordinate, y coordinate, and wall data that would tell us which walls were present. Before the competition we found that the x coordinate was often calculated as a negative number depending on which corner in the maze we started. (If we started in the right corner and went left, the x-coordinates would be calculated to be negative. We did a quick fix by simply calling the absolute value of the x coordinate. A more robust improvement we could have made was to calculate the x coordinate correctly with positive numbers. Furthermore, the data bits we send do not send anything about treasure due to our camera and FPGA not correctly functioning. If it did, the obvious improvement would be to add bits to represent that data.
GUI:
One bug with our GUI is that it works optimally when we begin in a different orientation than we were required to begin in the competition. This made the GUI a little messier than it needed to be in that walls that were otherwise correctly detected were flipped. Another issue was that even when it was in its optimal orientation it sometimes created phantom walls behind it. This could be due to either a bug we didn’t see or because our wall detectors were a little too sensitive. The receiver initially had an issue with the 3.3 V pin on the Arduino because the signal was too noisy, but this was fixed by placing a large capacitor between the 3.3 V pin and ground. We could then avoid using the voltage regulator.
Unincluded Components:
FPGA and Camera:
The camera currently produces unreliable images that are difficult to process, with a lot of noise around the shape. The output detects treasures very inconsistently, but when a treasure is actually present, the signal is correct for a much higher percentage of the time, which enabled us to correctly detect treasures from the Arduino by requiring a certain percentage of samples to be high to declare a treasure detected. However, due to the penalty for incorrect treasure identification, the camera was left off of the final robot. Since the camera functionality was unreliable, the FPGA was also removed from the robot as it did not serve another function.
Budget:
Parallax Servo (2) = $26
Line Sensor (2) = $6
Wall Sensor (3) = $21
Arduino Uno(1) = $16
TOTAL COST = $69
Other Improvements:
On the first competition round, we used a fresh battery, which destroyed the performance because all of the turns are calibrated with small delays to move off of the lines initially. To turn in place, the robot first needs to go straight to center itself on the intersection it detected with the line sensors on the front, then turn. The code then waits for the line sensor on the direction it is turning to detect a line, and then delays to continue turning a little more in that direction so that it is more centered on the line. This could have been improved by adding a third line sensor in the middle, and stopping the turn when the middle line sensor reached the line, or by calibrating all of the delays based on the time elapsed between detecting two intersections. When the battery was within the correct voltage range, turns were very robust and reliable.
Anothe area for improvement would have been to have cleaned up the wiring more on the robot. The reduction in wrie lengths would have made the aesthetics that much more enjoyable but also limited noise from cross wire interference.
One final system wide improvement would be to have designed our own elements of hardware to better integrate all necessary components together. Having a more well defined system with more precise configuration would have been helpful in areas of detection as well as general organization.
Final Remarks:
The robot was able to perform better the night before the competition as compared to the competition itself. This was due to the switch in 9V batteries which made the servos operate faster than was accounted for. Specifically,the night before the robot could search through almost 70-80% of the 9 by 9 maze. It makes good decisions based on nodes it has already visited and will visit in the future.
However, the day of the competition the video shows an issue with a certain part of the maze that is sticky and makes our robot unable to continue forward without some additional downward pressure. Later in the run, we start the robot going straight up the maze and explore a good portion of the bottom right corner (not shown in video). The first run produced poor results since we had changed 9V batteries, changing the speed the servos ran at.
Competition Video
Night Before Video