Team Two/Final Paper
QuartZar
QuartZar is the most feared predator in the land of MASlab. Hidden beneath his coat of crystal is a soul forged in hell. Carved to perfection by MechE senior Kameron Chan and infused with life by EECS seniors Rishi and Kartik, this monster disheartens the bravest of bots with his speed and precision. The agony of having been beaten in the seeding competition has only injected him with more fire. He is ready to break his shackles and burn down anyone who comes in the path of his glory.
Come watch him unleashed as he stalks his prey (innocent undoubting balls) with stealth and technique and admire him as he devours them.
Contents |
Members
Rishi Naidu Kartik Palani Kameron Chan
Our Team Strategy
Our team was a balanced team with each member having knowledge in different parts of the bot and each one of us were equally involved in the coding of the bot. Kameron took part of the mechanical design and was timely involved in giving his opinion in the coding part. Rishi took care of the electronics and was responsible for the vision part of the bot. Kartik took care of the whole coding part and integrating the different modules of the code.
Our team basic strategy was to always go for the pyramid and try to score in the top of the pyramid. However in the end due to the limitation of the design we positioned the camera in such a way that it looks towards the yellow of the pyramid or the yellow of the opponents wall. This way we were ensured that the bot will score in any of the two near the end of 3 minutes. The code was written such that the bot will be in ball finding state for most of the time, only in the last 45 seconds it will try to search for the yellow wall and score. This way we ensured that the we collected maximum ball before entering scoring state.
Software Design
The main part of the code consisted of the Vision and the Exploration state.
Exploration State
Wall following method was used as part of our exploration state. This was accomplished by using two short range IR sensors. We used PD controlling method to achieve the efficiency in wall following. It was really a difficult task to come out with the exact values of Proportional and Derivative constants.But finally we were able to get the right value of the constants by trial and error with the bot. The PD controlling gave us decent wall following without too much deviation from null error. The wall following method took care of our exploration state and we were able to cover the whole field. We didn't have anything for mapping as we were just a three team member and were quite behind in the schedule, so our main focus was to make wall following work perfectly which will ensure us to cover the whole field and to also compensate for our lack of mapping.
Vision State
Vision state was a completely independent state and the only input it took was the switch which controlled the color of the ball that needs to be captured. It did the image processing using openCV and gave the co-ordinates of the ball to the main code. Our initial problem with the vision was that as we were running it in series with the whole process there was too much of lag and the bot was not able to see the ball properly. So in order to speed up our vision process we down sampled our output from the webcam using the RESIZE function of openCV to 160x120. This increased our image processing to some extent, however the lag in the feed was still too much and it was not good enough to detect the ball while in motion. So the final thing that we did was to implement Multiprocessing in python, so that the vision was running as a different process all the time and kept sending the ball co-ordinates to the main process. This increased our vision process by great extent and we had a lot better results. One more problem we faced in our vision process was that earlier we were finding the center of mass of the whole red or green pixels found in the webcam image. However this created a problem when there were two ball in a single frame. In this case the center of mass was in between the two balls and hence the bot was not going towards the ball. To solve this problem we detected each ball separately using contour and then based on the area of the blob we found the nearest ball and then send the coordinates of this nearest ball.
State Machine
Our state machine consists of three main states which includes Explore state, Ball Capturing state and Scoring state.
In the Exploration state the bot explores the field using wall follower technique for the first 2 min and 15 sec. While in exploration state if the bot finds the ball then it enters ball capturing state. Once the ball is captured the bot again returns to the exploration state. In the last 45 seconds the bot enters finding yellow state in which the bot looks for the yellow of the opponent wall or the yellow of the pyramid. Once it finds the yellow wall it centers itself and then scores.
When the 3 min timer is done the bot enters stop state where all motors are stopped irrespective of the state of bot.
Mechanical Design
Bot Design
Our bot was mostly made of laser cut plexiglass. We first designed the bot in Solidworks and started laser cutting the different pieces. The design was done so that there is maximum space in the front to take in more balls. In order to get this maximum space the motor was fitted at the top and we opted belt drive of our wheels. This gave almost the entire width of the bot for the roller. Also the bot was designed such that it will not topple in any case considering the height of the bot. The battery was mounted in the rear and the roller and motors in front properly balanced the bot.
The design of belt drive wheels was really useful, however this resulted in repeated changing of belts as most of the time the belts would wore out and halt the progress of our testing. Also using a rubber belt was really a bad choice as getting the belt of right size was difficult and motors would not stall in case the bot is stuck due to the slipping of the belt. So finally near the end of the competition we replaced the rubber belts with plastic chain belts. This solved our problem of wear and tear of the belt and the motors also stalled when the bot was stuck.
Sensors
We used 5 short range IR sensors and 4 bump senors to minimize the possibility of having a blindspot. Two of the IR's on the right side of the bot were for wall following and rest of three IR's were there to avoid obstacles. 4 bump sensors, 2 in the front and 2 in the rear sides were there to avoid getting stuck at many places. The bump sensors were placed after testing the bot on field and finding out the possible places where the bot is stuck.
Conclusion
Our team was well balanced but lacked the perfect coordination as we were always behind in schedule, which ultimately resulted in last minute debugging. This last minute debugging was not enough to run the bot properly in the competition. However our bot had attained enough progress that it was able to easily collect balls and score in the pyramid or across the opponent wall in some cases which were not debugged properly.
Before the final competition, our wheels which were fixed with epoxy came out and there were some last minute drilling and fixing. This was fixed properly and then we didn't have problems with wheels. Also just before the competition we made a serious error in the code which resulted in a really bad performance and our bot didn't move in the final competition. It was really unfortunate, if only we could had got some more time to fix the bug in the code, there were pretty good chances for our team advance well in the competition.
Suggestions for Future Teams
- Divide the responsibility equally in the team, working together is good but it is really time consuming and time is the only thing that we don't have in MASLAB
- The mechanical design of the Bot should be ready as early as possible. You should have the bot nearly ready by the stating of the third week.
- One should not think of taking any other class along with MASLAB if the team is just of 3 members.
- Testing it thoroughly is the key and you should have maximum time for debugging in the end, which is only possible if the bot is completely ready ASAP
- Having more coders in the team is really important
