Team Thirteen/Final Paper

From Maslab 2011

< Team Thirteen
Revision as of 20:32, 31 January 2011 by Rhan (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

overall strategy

Two weeks into Maslab, January 14th, we decided to radically change our strategy and robot from a simpler design for goal-scoring to a complex and roller-intensive launching mechanism for scoring over walls.

Given the nature of this year’s competition, there was a clear dichotomy in design plan: namely, a goal scoring mechanism versus a wall scoring mechanism. No team built a robot that could do both. Logically, if one could construct a sound design for scoring over walls, it was entirely advantageous to do so and entirely disadvantageous to try scoring in goals.

We originally planned to only score goals for easier mechanical design. However, we realized that while our exploring and ball-collecting abilities were on par (if not better) than those of our competitors, we could only hope to earn 4 points per ball as opposed to their 6.

mechanical design and sensors

Review of previous literature emphasized a few key points in mechanical design. Robustness, a small (round) footprint, and as few complicated moving parts as possible, all figured prominently in the design of previous winners.

Our first robot fit the criteria. Although it was more square than round, it was essentially two plates of acrylic with supporting walls. The motors directly drove the two wheels mounted on either side, and a roller mechanism in front sucked balls into the body of the robot where a ramp reliably funneled the balls into the back. A servo attached to a sheet of metal opened and closed to score balls into goals. The only flaw was that we were unable to score balls over walls.

A.W.E.S.O.M-O was a far more complicated design. It was larger, elliptical, and had a launching mechanism consisting of home-cut gears turning rollers which brought one ball at a time up a ramp and ideally, over the wall. Though perfectly sound in theory, the practical implementation of this design was limited by the unevenness of the gears which consistently jammed. Eventually, we settled with a single belt that ran over the rollers (reducing the number of gears which had to synchronize and turn), which seemed to work slightly better at propelling the balls up the ramp.

When deciding the lift mechanism, we had to consider whether we wanted a ground-level or wall-level hopper; in retrospect, a wall-level hopper would have made scoring easier and more reliable. At the time, that was vetoed in favour of a LIDAR system (with long-range IR sensors) we had planned to implement.

Ultimately we did not construct our LIDAR because mapping became less necessary given our reliable wall-following and navigation. Our navigation system was remarkable, considering that we only used four short-range IR sensors. Two were mounted diagonally in the front left and front right, scanning for obstacles ahead in case the robot wanted to “turnLeft”, “hallFollow” or “wallEnd”. The other sensor was mounted in the right side, in the back, and used to maintain distance from the wall for our “hugRight” state of wall following and to detect a “wallEnd” scenario.

The camera was only used for ball detection and goal detection. We originally considered implementing stereo vision with two cameras but the unreliable FPS output (ranging from 7 to 30 FPS for no apparent reason) was a deterrent. We also briefly toyed with quadphase encoders on our first robot, but the getDistance() method returned irrational and nonsensical readings. Although we had dead reckoning and velocity inputs on our first robot, and they were more convenient to use, we were ultimately satisfied with the quality of A.W.E.S.O.M-O’s navigation as it was.

software design

In terms of software our robot was quite simple and robust. Our robot, A.W.E.S.O.M-O, had a default state of wall following, but would break behavior, and start to approach a ball or yellow wall if one was detected. Once an object of interest was detected (ball or wall) the robot would approach using a simple PD control loop. After each collected ball or wall scored the robot would enter a scan state, that would break upon seeing a ball. With this behavior we hoped to successfully explore the entire field, and in practice we seemed to do so.

To make programming the robot easier for all members of the team , we crated HAL (the part of the robot that developed consciousness). HAL is short for hardware abstraction layer, and served as a communication link between the state machine and the robot. HAL handled things like overriding the watchdog, velocity to pwm conversions, voltage to distance conversions for rangefinders, and all other robot inputs and outputs.

Since our robot was heavily wall follow reliant we decided to make our wall follow state a state machine as well. The wall follow state machine had the following 4 states that handled any scenario possible in the maslab world: “hugRight”, “turnLeft”, “hallFollow”, and “wallEnd”. In the end we did not implement hall follow as our hug right stayed close enough to the wall that we deemed it unnecessary.

The goals presented a slight problem for our wall following code. Although the edges were yellow the goal itself was black and the camera interpreted that as empty space. Therefore, the robot tried to turn into the goal every time. Eventually we added a panic response; if the camera saw a goal 12 inches or closer, it would abruptly veer away from the goal. Impressively, if the robot had been wall following it would veer back on course after panicking.

We also had stall detection implemented in vision. If the frame did not differ enough over a certain time the robot would assume it was stuck and would run a freak out function. This feature was a little buggy. When the robot would traverse a large enough room, the subsequent frames would be similar enough to make the robot think it was stalled even though it was crossing a room as wanted.

overall performance

During the competition our robot performed admirably. Despite two burnt motors and a broken camera we placed 4th. In terms of software, we benefited greatly from our freak out function. Like other teams, our robot was sometimes confused by the field and stuck in a rut. However, having a freak out function allowed us to essentially “reset” what the robot was thinking and resume activity. Our mechanical design was the weakest point in our robot, with the scoring mechanism jamming or malfunctioning almost every round.

conclusions/suggestions for future teams

  • DO NOT CUT YOUR OWN GEARS!!! Despite being warned by multiple people we tried it anyway and paid the price by having our gear train jam at the worst possible times.
  • On a mechanical note, simpler is better. The more quickly and easily a robot can be put together / taken apart, the more likely one can fix unexpected last-minute issues.
  • Use SVN or some form of version control. Two weeks into Maslab our eeePC kernel panicked and we almost lost all of our code. Luckily we got it back but we still lost 2 days of work time.
  • Plan your state machine and software architecture. Because we had planned everything out we were able to write and test each state separately before putting everything together. This allowed us to find bugs faster, and helped us maintain clean, easily changeable code.
  • Gearing down motors is not that beneficial, the motors provided are powerful enough to drive most robots and speed becomes a critical factor towards the end of the competition. Faster robots collect more balls and explore more of the field.
Personal tools