Team Four/Final Paper
From Maslab 2007
In the first weeks we agreed to keep the robot design simple making sure that the shape of it wasn’t something that would require too much machining. The motors were to be mounted on the rear of the robot with two caster wheels in the front. We considered making the robot circular so that wall edges would not be a problem. We decided against the circular design because the motor position would not be changed and more space would be utilized in a square design. This would make the robot relatively short and the camera could be mounted at a lower height. The chassis has two slits where the wheels rest. We did this so there would be space between the wheels and the outside of the robot. This is because if the robot got stuck in corner the wheels would continue spinning allowing us to escape. The motor mounts were made to keep the wheels centered and also distribute the weight evenly. They were sanded down to support the circular encasing of the motor and sheet metal was used to secure them. This made sure that the motor would not shift in position during testing and game play.
The team agreed that the ball collector should be similar to spindle on a vacuum cleaner with a helix formation. The material we choose was zip-ties because of their flexibility and strength. Originally the formation was to be a single helix, but during testing we found some problems with this. The helix was too big and had gaps through which the ball could go through once captured. The idea of using a double helix was mentioned but then the spaces would be too small and the ball would get stuck during collection. The final design for the spindle was three rows of evenly spaced zip-ties. They would be about 120 degrees apart allowing us to catch balls without cluttering the ball collector. This design was placed on a half inch diameter of PVC which was coupled to a motor that was attached to the left front side of the robot. The spindle was driven in one direction to collect balls and the other direction to score.
The container in which the balls were collected was originally going to be a five inch by nine inch box of sheet metal that was angled at about five degrees. The problem with this was that the balls would get caught on the edge of the bottom of the box and never enter it. A quick solution was to cut the bottom of the box so that the balls would no longer get stuck on that edge. This caused some clearance issues since the sides were cut uneven making them too low. So that two sides were cut evenly to rise about one inch from the playing field. The final piece to the container was keeping the balls from going out the back of it. For this we drilled four holes evenly spaced and made a zip-tie net.
A raised platform was built for the camera and IR sensors. The camera needed to be mounted in the front in the center so that it could detect balls directly in front of the ball collector. We also wanted one IR sensor to be mounted in the front and center so that we could detect walls directly in front of the robot. The raised platform was necessary because we had to cut a five by four inch space in the main platform so the ball collector would function properly. The last two IR sensors were placed diagonally facing on the front corners of the robot.
The final addition to the design were bump sensors. The Nintendo buttons were inadequate because the area that it was sensitive to was very narrow. They could detect head on collisions, using this we molded thin pieces of sheet metal into a semicircular shape. This allowed for the maximum sensitivity since the bump sensors would now register, even if hit at an angle.
Our initial plan for the robot’s navigation was somewhat ambitious, given that we started out with a software team of three people. Our idea was to use the barcodes extensively in order to keep track of where we had been and where we still needed to go. We would read each barcode and put them into a visibility graph. Since it was guaranteed that at least one other barcode would be visible from each barcode, we would never get into a situation where we reached a dead end and could not see any more barcodes. Our plan was to navigate the playing field by moving from one barcode to the next, collecting balls and scoring along the way.
The first problem we ran into was that the robot would get stuck in an infinite loop between two barcodes. This would happen when a previously-seen barcode was detected before a new barcode. To fix this, we ignored barcodes that we had already seen. If we couldn’t see any new barcodes within a certain amount of time (which we knew was a possibility), we had the robot transition to a random walk. This basically consisted of going straight until one of the IR sensors sensed a nearby wall (in which case we would turn), or we saw a ball. If we saw a barcode, we would transition back to barcode navigation.
Originally, we had planned to actually utilize the graph itself when looking for goals. If we saw a goal, we would associate it with the nearest barcode and put it into our graph. Once we collected enough balls, we would then use a graph search to navigate the barcodes, find the goal, and score. There were two problems with this approach. The first was that given the design of our ball collector, we could not think of a way to reliably determine when we had captured a ball, or alternatively, how many balls we had in the container at a given time. The second, and more fundamental, problem was that in the third week of IAP our software team was reduced from three to one. Testing this graph thus became a very low priority and was never implemented. The plan Steve came up with, somewhat at the last minute, was to ignore goals for the first two and a half minutes of the competition. After that, we would attempt to score whenever we saw a goal, no matter how many balls we had in the container at that time.
The process of detecting and collecting balls was significantly harder than we thought. For checkpoint 1, we used a low-mounted IR sensor to detect balls when they became too close to be seen with the camera. However, the design and position of our ball collector prevented us from mounting an IR sensor in the center and low enough to reliably detect balls. This caused a problem, since when we got close to a ball and lost sight of it, we were not able to determine if we were lined up well enough to actually capture it. This problem was exacerbated by the fact that the ball collector was not as wide as the robot. This was necessary because we needed space for the motor that spun the collector, and we did not have time to reposition the motor and transfer power to the ball collector via a belt. During the first few hours of testing, the robot would often barely miss balls, as they would go between the wheels of the robot but wide of the ball collector. We tried to solve this problem by using finer and finer adjustments, hoping that this would force the robot to be exactly lined up with the ball before approaching it. This, however, did not work. The robot would often overshoot the ball at the last minute. Desperate for ideas, Steve tried increasing the tolerance (thus making the adjustments coarser). Surprisingly, this worked, as the robot would go straight toward the ball for a long time and would not overshoot.
We really did not have enough time to test our code for approaching the goal. Basically, my idea was to try to determine how slanted the picture of the goal was, and if it exceeded a certain threshold, the robot should try to recenter itself. It worked about half the time during testing, and unfortunately did not work in the competition.
In the end, two factors really hindered our team’s performance in Maslab. The first was that Juan, who was building the robot, had his life consumed by 2.670 during the first two weeks of IAP. Thus we were testing our code on the pegbot for all of this time. It is very crucial that the robot be built as soon as possible so that the code can be tested on the final product, and any mechanical problems can be fixed early. The second factor was that two of our three software people quit the team midway during IAP. This basically meant that Steve was working by himself debugging the code for the last week and a half. Obviously, this limited what we could accomplish in terms of navigation and scoring.
