Team Thirteen/Final Paper
From Maslab 2007
Contents |
Introduction
This report summarizes the design, construction, testing, and ultimate demise of the robot constructed by Team 13 for the 6.186 Mobile Autonomous Systems Laboratory IAP course. Mechanical, sensor, and software subsystems are detailed in separate sections. The following section focuses on major problems encountered, comments on the robot's final performance, and recommendations for future teams.
Initial Concept and Strategy
The following are the features that the team agreed upon during checkpoint one:
- Circular base to avoid getting stuck in corners.
- Pivots about center of circular base to facilitate obstacle.
- Fixed camera positioned high on robot.
- Collects balls and releases them as a batch.
- Ball collector: two revolving doors that capture the ball when rotated one way and release them when rotated the other way. The balls are stored in a hopper.
- Finds distances using visual (camera) and IR inputs.
- Limited mapping capability; uses gyros and possibly other sensors for calculating its position.
The following sections describe the actual design that evolved from the above ideas.
Mechanical Design
Mechanically, the robot consists of the following parts and subsystems:
- Chassis
- Wheels and casters
- Camera mount
- Computer and battery
- Capture mechanism
Chassis
The robot chassis consists of a 14 inch diameter circular plywood piece with two slots for the robot wheels to stick up as the chassis is elevated by an amount smaller than the wheel diameter. The floor clearance of the chassis is roughly 3.25 inches. The other components are mounted on the chassis by a variety of methods including glue, bolts and screws.
Wheels and Casters
Our robot uses the 2 standard wheels and motors provided in the maslab kit. The motors are mounted underneath the chassis in such a way as to minimize ground clearance. A sliding caster is placed at the rear of the robot and shimmed to touch the ground.
Camera Mount
The camera is mounted on at wood piece placed on top of the battery. We removed the legs of the base that came with the camera and glued the swivel joint in place. The camera is mounted 10 inches back from the front of the robot and about 5.75 inches high from the chassis. It is angled so that the top of its field of view just reaches the blue line on the walls of the playing field.
Computer and Battery
The battery is mounted close to the center of the chassis as it is the heaviest component of the robot and we wanted to avoid a laterally imbalanced load on the wheels of the robot. Right behind the battery to computer is mounted vertically in such a way that the ports are located at the top and easily accessible for connecting peripheral devices.
Capture Mechanism
The capture mechanism is mounted at the front of the robot under the chassis. It consists of two suspended . Two counter-rotating turnstiles are are driven by a DC motor. The power transfer for mechanism connecting the turnstiles to the motor consists of both gears and belt drives. 1 Belt Drive is used for each turnstile and tool rails are located between the belt drives to guide the ball to the rear of the robot.
A sheet metal container is suspended below the chassis to contain the balls. The container has a capacity of four balls.
The capture mechanism can capture several balls and hold them until such time as the robot decides to release them into a goal. While scoring is achieved by rotating the turnstiles in the opposite direction thus pushing the balls out of the suspended platform.
Sensing
Initially, we planned to use a variety of sensors to accomplish our task. These included camera, gyro , IR, encoders and bump sensors. At the end, however, we did not have time to incorporate the bump sensors into our software design. The following sections detail the use of each of those sensors.
Sensor Mounts
Two infrared (IR) sensors were mounted using glue on top of the battery. Another two IR sensors were mounted on "c"-brackets made from sheet metal and glued on top of the chassis. The gyro was mounted using glue on top of the battery at approximately the center of the chassis.
Camera
The robot not only uses the camera to find objects in the playing field based on color but also uses the positions and sizes of those objects found from the images to calculate their distance and angular deviation from the edge of the robot.
Infrared (IR)
We had initially planned on using for IR sensors. Two of these would be used for wall avoidance. These were mounted on the battery at approximately 15° angle from the centerline of the robot. The other two sensors were to be used to align with the goal. These are mounted approximately 10 inches back from the front of the robot, parallel to the centerline of the robot and at the height such that their beams strike the walls above the goal opening.
Ultimately, we ran out of time to incorporate these into our code. Also, our distance measurements from the camera were accurate enough for purposes of the competition.
Gyro
The MIT "Noisy" Gyro was one of the most critical sensors. Since camera images were used to determine the angular deviation target objects, the plan was to use the gyro to change the robot's path to correct for the deviation. The gyro suffered from sensor drift, which accumulated over time and was found to be fairly significant. It was estimated that after five minutes the gyro readings could contain up to 20° of error. To counter the sensor drift, the gyro was calibrated for a short period of time before the robot would begin to drive. The gyro was a crucial element in the mapping procedure, described below.
Encoders
Each of our two wheels was mounted with optical encoders. These proved to be the Achilles' heel of our robot. We had several malfunctions and replacements. In the end, we found that actually two of the ports on our orcBoard were fried and were causing all the problems. After changing to different ports, we had high hopes for a robot to do well in terms of following the instructions provided by the mapping software. However, another of the ports also got fried a couple of days after that and we didn't have any alternative ports to plug the encoders into. For this reason, our robot could not judge distances accurately and ran into walls.
Bump Sensors
Four mechanical bump sensors (two at front, two at rear) were added to serve as a fail safe in the event the robot accidentally collides with a wall. The sensors are comprised of momentary SPDT switches with sheet metal extensions to increase the span over which contact can be made. The sheet metal extensions are 6" long by 0.75" wide strips of aluminum with curvature along both long and short axes. The radius of curvature along the short axis proves flexural rigidity, while the curvature along the long axis matches that of the robot's chassis. The sensors are connected to four digital I/O ports with the appropriate 10k pull-up resistors on the +5V leads. Due to time issues, the bump sensors could not be interfaced in the software.
Software Design
our software design was very modular. Several different functions were created in the following main categories: image analysis, mobility, ball capture and release and sensing.
The mobility category included functions for basic tasks like driving, right and left short turns, coordinated turns etc. the sensing category included functions for reading data from encoders, IR sensors and gyro. Functions in both categories were used to calibrate the mobility of the robot.
Our image analysis software was quite advanced. We used image analysis to map the playing field. The algorithm maps (it can detect walls at quite a long range), and figures out waypoints to drive .
Here is a sample map ('W' means wall, 'U' means uncertainty. '.' means likely a floor tile (not important for driving, but important to determine what robot will explore. This run had robot using "explore" rather than "pick up balls" function. 'X' is robot's position, 'b' and 'x' are balls (depending on confidence, and floor status. Each ball is placed in 9 squares to compensate for possible error in future mapping, so the picture below has 2 balls):
. .. .. .. ...
. . . .. ...
WW . .. .. ....
WW .. . .. ....
... .. .. .. ... .
WW. .. .. .. ... ..
WW W W... . .. . ... ...
.WWWWW .... . .. .. ... ....
...W.WW WW... . . .. ... ....
.......WW.... .. .. . .... ....
............ .. . .. ... ...
............ . .. .. ... .... .
............ . . . ... ... ...
........... . .. .. ... .... .....
.......... .. .. .. ... ... ......
.......... .. .. . ... ... ......
........W . .. .. ... ... ......
......... . . .. ... ... ......
.bbx....WW. .. .. .. ... ......
bxb.....W. . .. .. ... ......
bxb.....W. .. . ...... .....
.......W . .. ...... .....
W......WW.... ..... ..... .
W.......W. . W.... ..... .....
W....bbbW... .W.. ..... .........
W....bxbW.. ...W...... ..............
W....bbbWW .....W.. ..................
W........WW.....W .................
W.........WW....W ...............
W..........W....W..........
WW..........WWW..W...
W.....X.....W.WW.W
........WW...........W.WW.............................
..................W ..W.WW...........WWW .............
............. ...... .WWW..........WW .............
....... ....WW.........W ..
...... ..... WW.......WW
W ... ...... ..........W
....... ..........WW
... .. WW.......WW
.... ... ........WW
.... ... ........WWUU
... ... ...........U
.... ... ...xxx......UU
.... .. ...xxx.....W.U
.... ... ....xxb.....W.
.... .. ............WWW
.... ... ..W...........W
This (walls) looks very much like the playing field, including, amazingly, the wedge of the top, that is ~12 feet away from the robot. There are a few "extra" walls on the left, but they have low confidence (due to being far away), so once robot gets close they'll be replaces by whatever it sees there, so they won't cause the problem. (In a "normal" run robot only pays a lot of attention to walls it has seen from more or less up close. But the bigger map that shows what it thinks it sees is likely more interesting).
The DP-type algorithm (an adapted A-star algorithm), given direction to drive to unknown while avoiding walls (and a penalty for being close to walls), gives the following way points:
Path to way point: 9.0 , -27.0 cost: 1508.6048916900277
Path to way point: -9.0 , -57.0 cost: 1254.9558132621592
Path to way point: -21.0 , -75.0 cost: 1072.9354881259915
Path to way point: -33.0 , -69.0 cost: 1000.0
(way points are in inches, one map " letter" is 6 inches, first coordinate is left-to-right, second is top-to-bottom) -- this does look like an optimal path.
Then driver is engaged.
Finally, the ball capture and release category includes functions for turning the servo one way or the other for capturing or releasing balls at the appropriate time which is determined using sensors.
Final Configuration and Performance
The following picture shows the final robot:
Due to several problems with sensors, the capabilities of our robot were significantly less than those initially planned. The only working sensors were the camera and gyro with the gyro being extremely noisy. Because of inaccurate odometry, we decided to disable the drive function of our robot. Due to this, our robot could not actually complete the competition task of collecting balls.
During the competition, our robot did a demo run showcasing our mapping abilities. The maps constructed by the robot were quite accurate, thus our mapping software performed quite well. Additionally, the robot displayed an optimal travel path. Again, due to malfunctioning sensors, we could not actually follow this path.
Conclusions and Recommendations
in conclusion, our mechanical design was fairly straightforward and simple which is always a good design philosophy. On the other hand, our software performed fairly advanced tasks. Due to this, we spent a lot of time developing the software and making it intelligent. In the end, we did not have enough time to interface the hardware and software properly.
From our experience, we would recommend that teams try to make their robots progressively more intelligent. The robots can start out with quick and dirty and dumb software and this can be tweaked to make it more advanced later on. Also, it's best to choose major hardware design specs early so that you have enough time to test out the hardware and change it if something is not working.
