Team Three/Final Paper

From Maslab 2007

Overall Strategy

Our overall strategy was to have a robot that was fast in software (multithreaded finite-state machine) and robust in mechanical design (sturdy under impact at a reasonable speed). A key part of our original strategy was a the usage of an optical mouse for reasonably accurate odometry. Based on distances from the mouse and angle headings from the gyroscope, we planned on using dead reckoning for keeping a record of the robot's position over the course of the competition. With an accurate position history, our robot would preferentially choose unexplored areas of a map while wandering. By virtue of efficient exploration, we planned on collecting lots of balls.

We opted for a simple mechanical design that allowed for:

• The chassis of the robot to be assembled and disassembled quickly.
• A front-wheel driven robot with a front-mounted cage with large storage volume.
• A robust mouse mount that kept the mouse on the line-of-motion of the robot.
• An active ball collection mechanism like a front roller that collected and scored.

This, of course, worked differently in practice and took longer to implement than we expected. Due to short time before the final competition, we opted for abandoning our belt drive in order to have a working robot within a week of impounding.

Mechanical Design

On the first week of MASLab, we made a rough design of our robot in SolidWorks. Our first mechanical revision was an almost exact implementation of our original design. Pictures of it can be found at the very end of this paper.

The baseplate of the robot's chassis was made from 3/4" thick birch plywood that was acquired as scrap wood from the MIT Hobby Shop. Working with wood was a reasonable decision. It was easy to manipulate with a variety of machine tools (mill, band saw, drill press, & jigsaw) as well as by hand power tools (Dremel tool, screwdriver, hammer, etc.). If you do plan on working with wood, I would recommend some multi-ply hardwood of reasonable thickness as opposed to the material provided by the MASLab staff. Based on weight and distribution of your chassis components, it's easy to cause unwanted warping and bending of your frame if you use something less robust.

We also fashioned our own L-brackets for mounting components to our chassis. These were made from a sheet of 1/8" thick, 2" wide narrow rectangular piece of aluminum. That was then bent in half and drilled to form an L-bracket with spaces for bolts.

Ball Cage & Belt Drive

A rectangular aluminum sheet of 1/16" thickness (2.25" tall) was bent into a rectangle (roughly 6"x6") and mounted to the bottom of the baseplate using L-brackets. The ends of the cage at the front of the robot were narrowed and then bent to the sides to collect balls that came into the path of the wheels.

In order to accommodate the cage underneath, the drive motors provided by the MASLab staff were mounted on top of a measured wooden block mounted to the top of the baseplate. Timing pulleys and belts of appropriate size were ordered from McMaster-Carr, in addition to mounted bearings for the wheel axles. To couple the timing pulleys to the motion of the motor and the wheel, we had to fashion our own axles & motor couplings from aluminum. (Note: Of all the things we did mechanically, this took the least time). We used the lathe at MITERS to do this during off hours (Edgerton Shop closes at 8 PM).

After our first mechanical revision of the robot (see last section), we discovered that lower friction bearings were actually needed for our wheels to exert enough torque for the robot to move over carpet. With the hope of keeping our original design (foolish, in retrospect), we successfully created our own mounted bearings with lower friction. Our second mechanical revision had our robot continuously leaning to the left on vinyl flooring and driving in circles on carpeting (certain doom for the final competition). At the end of the second mock competition and with a week and a couple days before impounding, we abandoned our belt drive (too much troubleshooting at that point) for a straight bushing mount with the drive motors on the bottom of the baseplate.

Ball Collection Mechanism

D'Arthur Petron (MASLab staff) suggested using a right-angle motor for driving an aluminum shaft to which we could mount compressible foam as a roller. The right-angle motor was mounted to a flat arm of Lexan that was subsequently mounted (adjustably) to the chassis by L-brackets. Upon discovering that the speed of the motor made compressible foam ineffective in imparting (to the ball) the required impulse for scoring. We finally opted for a rubber band roller made by stretching thick rubber bands between two round plastic pieces that were mounted to the aluminum shaft by L-brackets.

Sensors

Interestingly enough, if you take apart the camera, you'll notice that the fastener holding the camera to its base is the same width of the standard MASLab bolts that are ubiquitous in pegbots. We hot glued a bolt to the interior of the camera so we could screw the camera into an aluminum plate mounted to the chassis by long bolts and nuts.

Short-range IR sensors were fastened to adjustable servos on a second plywood plate (see bottom photos). The Analog Devices "MIT NOISY" gyroscope was wired into the OrcBoard in the center of the robot and held steady by a wooden block eventually added to the chassis (not pictured).

The USB optical mouse is mounted on the center line of motion of the robot. An aluminum bracket is bolted to the back of the ball cage and additional bolts (and a spring) extending from the bracket into the plastic case of the mouse, forming an improvised suspension that allows the mouse to move up and down when moving over rough surfaces. The mouse was also useful for detecting motion stalls from obstacles.

Software Design

The main class of our robot was class Robot, which was a finite state machine that decided behavior based on the previous behavior and three flag variables: task_finished, ball_in_view, and goal_priority. Task_finished was set to true only if the behavior completed its task without an interruption, such as a stall or seeing a ball or goal. Ball_in_view denoted that there was a ball in the line of sight of the camera, and goal_priority signaled that a goal was in the line of sight of the camera, and there was a ball in the cage. There were eight possible behaviors to choose from: Wander, FollowWall, TrackBall, CaptureBall, ApproachGoal, EjectBall, Spin, and Escape. Wander and FollowWall were two alternative methods of wandering that alternated in the FSM. CaptureBall was never explicitly called within the FSM, rather it was called by TrackBall as it finished. The same is true for EjectBall with respect to ApproachGoal. Spin was not implemented in the final version of the software, as it took far too much time to complete.

Our robot had five other main classes: MouseDecoder, Odometry, EnhancedAnalyzer, and IRHandler, and OrcQueue.

MouseDecoder

MouseDecoder ran in its own thread and constantly grabbed data out of /dev/psaux (mouse output) and converted it to inches. MouseDecoder then integrated these changes to calculate a cumulative dx and dy in inches. Its accessors, getdx, and getdy would then reset these internal dx and dy values to zero each time it was called. MouseDecoder was only explicitly used by the Odometry class.

Odometry

Odometry also ran in its on thread and also was a finite state machine that drove the robot and maintained a location and heading (although we did not have time to use this). Also, Odometry would use data inputted from MouseDecoder to detect whether or not the robot was stalled. Odometry had three main states: Drive, Turn, and Stop. Drive would move the robot forward or in an arc depending on the inputted motor ratios. Turn would turn the robot on its axis for a certain number of degrees. Finally, Stop reset all variables and stopped the motors.

EnhancedAnalyzer

EnhancedAnalyzer was implemented as an object inside of Robot and therefore did not run in its own thread. EnhancedAnalyzer simply analyzed an inputted picture and then would pass back information based on what it had seen. EnhancedAnalyzer also used basic trigonometry to estimate wall and ball distances based on location with relation to the camera and certain given physical constants (camera height, wall height, camera FOV, etc).

IRHandler

IRHandler ran its own thread and took care of IR direction (our IR sensors were mounted on servos), and constantly grabbed data from the IR’s and placed it in a local array. IRHandler was also a finite state machine (although in the final implementation, we only used one state, as the other states were too slow, and we did not have time to fix this). IRHandler could scan in front, scan in back, scan all directions, or scan a fixed angle. We primarily used the fixed angle scan, as the others took too much time. This was caused (we believe) by a problem with the OrcBoard. We had two servos, if we tried to drive both at the same time, the computer would restart. We believe this was caused by the servos pulling too much current, and the computer restarting due to undervoltage. Anyhow, OrcQueue maintained an acceptable delay between the servo commands, so the computed would not crash, but as a result, the scans were too slow.

OrcQueue

Finally, OrcQueue was a task scheduler for the OrcBoard. In retrospect, this class was not as necessary as it first seemed, as we originally thought that Orc was not thread safe. However, we later realized that it was more likely that the servos were drawing too much current and the computer was not getting a high enough 5V rail. OrcQueue did fix the servo problem, but it was probably was not necessary for all of the other classes to use it. However, it did set a nice abstraction barrier between each of my threads and the hardware. As a result, if something changed on the OrcBoard, I would only have to update one location.

Overall Performance During Competition

We did reasonably well during the competition (I provided commentary, so I didn't see so much). We scored 5 points (one ball on the porch, three in the bag) and lost 3 points for being 6 seconds over time. Teams seemed to be consistently over time, so I suspect that Tim Abbott (who was timing) started slightly earlier than the robots did. That being said, there was still a software issue that caused a few additional seconds of execution (see below).

Mechanical Problems

During the final competition we experienced a hardware failure with our robot's left motor. Our set screws were secured and the motor ports on the OrcBoard still sourced current. We had to exert a lot of torque on the left wheel for the motor to actually turn, and when it did, the motor turned ~180deg before starting again. The motor was replaced by another provided by the staff.

Software Problems

There were two primary software problems I observed on competition day. First, Odometry has a threshold for a declaring a stall, and this threshold was too loose. As a result, I observed that the robot would think it had stalled, but really, the motors had just not spun up yet. Second, I implemented the five-minute timeout inside of the main finite state machine. Therefore, the robot only checked to see if it had reached five minutes when it changed state. I did this thinking that it would be OK if it ran a few seconds over. A much more accurate way to achieve a five-minute timeout would have been to place the timeout inside of OrcQueue. OrcQueue is accessed hundreds of time a second at least, so there would have been no doubt that the robot would run for exactly five minutes with no overshoot.

Conclusions

Suggestions

• Taking time to practice with CAD before IAP starts would be a great idea. Other teams (with more mechanical experience) spent a fair bit of time designing their robot in SolidWorks before the fall term even came to an end (see Team 1).
• Using an USB optical mouse was a quick and easy solution to having accurate odometry. Especially if you have problems with properly aligning wheels and motors on your robot (as we did), you might consider using a mouse as opposed to the quad-phase encoders that are usually used.
• With a good design done early (see first suggestion), moving from a pegbot to a first mechanical revision within the first week of IAP is probably a good idea. With a working robot finished quickly, you can easily implement mapping and dead reckoning and move on to more important software issues. On the other hand, MASLab is an excellent opportunity to explore those aspects of mechanical engineering that many people miss.
• Three people is the optimal size for a team. With two, work can be done efficiently on a given aspect of a robot. A third team member would have been useful when additional mechanical tasks were needed to be done in parallel.

Pictures of First Mechanical Revision