Team Seven/Final Paper
From Maslab 2011
MASLAB 2011: Final Paper
Roberto Meléndez, Christian X. Segura, Rafael Crespo, and Javier E. Ramos
This paper serves as an introduction and technical description of our robot, the Mighty Duck. The paper discusses: overall strategy, mechanical design and sensors, software design, overall performance, and future suggestions. It is informal, but as complete as possible to provide guidance to future Maslab teams.
In terms of the general and high-level approach to the challenge, our team decided to develop a simple, yet very maneuverable robot. This is mainly due to the fact that we only had one programmer, and three MechE’s. We decided to score by throwing the balls over the fence. Our approach was mechanically simple and designed to be easy to assemble.
From a high-level design standpoint, our robot was driven by two geared motors with a caster wheel in the back. Our mechanical strategy was to collect the balls using a mechanism that collected the balls by pinching them between sets of rubber-bands placed in parallel. Our robot was designed to place the balls above the fence separating the teams to score the maximum amount of points possible.
As mentioned above, our robot employed a rubber-band basket mechanism to collect the balls. The basket was attached to rotational arms that raised and lowered the basket on top of the balls. As the basket came down, the balls got pinched between the rubber-bands placed on the underside of the basket. The basket would then rotate up and let the balls drop through the back of the robot using the computer as a ramp. The strategy was to collect the balls and then have the robot back up to the fence. After the robot was properly aligned, the robot would then deposit the balls.
Also, we designed and built our own wheels, to benefit from improved traction over the stock ones. The robot employed a servo to rotate the arm and most of the weight was placed close to the ground for improved stability. The circular design of the base prevented the robot from getting caught in corners.
It is important to note that our team built two robots. The first robot was built during the first 2-week period, and the second robot was built during the last week of the competition. Our decision to build the second robot was based on that we couldn’t score that maximum amount of points with the first robot. We could only dribble balls and place them in the floor goals. Even though we built a second robot, the first robot served as a coding and prototyping base for the team. It is important to choose a strategy from the beginning and stick to it. It was very costly for our team to start building a new robot.
The code for written by our time was focused on simplicity. The team had only one programmer which meant that the time spent on vision, navigation and the logistics of the code had to be split up and was probably the main reason why the robots ended up underperforming.
The state machine used for both of our robots was similar. As the Mechanical Design shows, one of our robots could only go up to balls and pick them up while the other had the ability to grab them and then throw them over a wall.
The first robot we built had only the ability to store balls and score in goals. Since the scoring mechanism was not very reliable it would only try to score during the last 40 seconds of the match. Even though the robot did not score consistently, the navigation and grabbing balls actions were consistent and incredibly efficient. Here is a rough version of the state machine:
The second robot was a bit more complex in its behavior. It was capable of scoring over walls with some success and this is why we decided to make a state machine that would prioritize ball grabbing only if the robot did not have any balls already stored and scoring otherwise. Since we did not have time to accurately tell whether the robot had in fact grabbed a ball, we decided to make the robot try to score if the time limit was approaching. Here is how the state machine looked like:
One of the teams’ biggest flaws was the vision code. As suggested by the TA’s, we tested and made the vision of the robot an early priority. Sadly, we never got it to work consistently or had enough time to test it in real life action. It is important to point out that even if the pictures are taken in 26- 100, once you start testing your code while the robot moves, the results become less precise.
The code consisted of looking for balls, walls and goals. The robot could easily tell balls apart from the rest of the elements seen on the picture since they were either red or green, but when it tried to distinguish goals and walls it would be inconsistent since both where yellow. The differences between a goal and a wall where minor, so it is very important to put some time aside just to tackle that problem. It is also crucial that your vision code is efficient. We managed to do process images with only one iteration of the picture’s pixels which allowed our robot to make decisions at a rapid rate.
For the navigation part, we did not use any fancy PID controller. We went for simplicity and efficiency and that is what we got. We used 3 IR shortrange sensors and did a simple wall follower to navigate the map. It did remarkably well and explored most maps to completion. The only problem with this strategy is that if one of the sensors fails, then your robot will not navigate correctly, which is what happened to us in the final competition.
Results and Recommendations
It is highly recommended that you give your coder(s) time to do their work and that you have at least 2 coders. Our team lacked man-power in this department and thus our performance was heavily affected since we did not have time to perfect neither the vision nor the navigation code. We would also recommend writing very simple navigation code. No PID controller is necessary unless you are looking for precise movements. The gyro is not very useful (open loops worked better than gyros in our case…) so don’t use them! Finally, prioritize on the vision code! Without a good vision code, you robot will not work well!
Final Conclusion and Remarks
The robot performed remarkably well during the tests, given the time constraints (1 week to build a new robot), but did not perform as expected during the final competition, which was a bit disappointing. The main suggestion we have for future teams is to build early to have a plenty of time for testing and tweaking. Choose a strategy early, or before the competition and implement it as fast as possible. Also, there are many things that can be done before the competition, such as writing code, making parts, and deciding on a navigation strategy.