Team Five/Final Paper

Contents 1 Mechanical Design 1.1 Drive 1.2 Catapult 1.3 Tiemill 2 Software 2.1 Sensors 2.2 Odometry 2.3 Camera, Vision, and Mapping 2.4 Behavior 3 Random notes 4 Lab Life

Mechanical Design

Our original design had the following traits:

• 3-Omniwheel drive
• Catapult
• Tiemill roller

Drive

Our Omniwheel drive ended up being our failing point. There were a few things:

1. The omniwheels required more torque, and thus more current than normal two wheel drive. With two motors on a Qik motor controller, this caused us to draw over 2 amps continuously. The Qik motor controllers are only designed to handle 2 amps peak. Consequently, we ended up burning out a total of 9 motor controllers. Future years, use an ammeter to measure your current if your motor controllers are burning out. This took use pretty much 3 weeks to figure out. The last week we finally decided to use H-bridges to control the motors, requiring three H-bridges. They are much messier to wire than motor controllers. The H-bridges did work, and could handle up to three amps of continuous power. It was an expensive and tedious route to using them though, because we also couldn’t test much of the robot effectively and the motor controllers cost $30 each. So future years, use H-bridges, or different motor controllers, or just don’t use omniwheels because they’re not worth it.
2. Omniwheels did not turn well using the stock drive motors. They tended to slip on the carpet, or stall. We had to discard our catapult and tiemill two days before the final competition because our robot could not move effectively with the weight.
3. The advantage of omniwheels is maneuverability. However, unless you’re going to use more than one camera and capture from more than one direction, you can’t fully realize that maneuverability. We ended up usually just turning and going forward, which is the exact same movement as a normal two wheel drive. Therefore, omniwheels are pretty much a bad choice unless you build them into your strategy. (One interesting possibility for omniwheels was wall following with our back to the wall, allowing our camera to scan for balls facing inward; however, due to the hardware problems noted above, and not thinking of this strategy until two days before the competition, this never had a chance to be fully implemented.)
4. The motor placement for omniwheels caused troubles because the motors got in the way of our desired box.

From a software standpoint, they were fairly straightforward (barring the mechanical problems that made them unusable). The one caveat was that since they slip as part of normal operation, you can’t use encoders for odometry. This is why we opted to use USB mice instead, but that came with its own share of problems (see below).

Catapult

1. We had a large box and catapult, which we didn’t use above due to omniwheels. It was made of aluminum tubing, which was good for structure, but caused increased weight.
2. The catapult was a bulky way of launching balls because you don’t actually have to launch balls. pleit! (Team 7) and Maslol (Team 4) had method of launching is much more elegant.

Tiemill

1. I believe zipties on a shaft work just as well as rubberbands, however they require more torque and rubberbands work, so I recommend just going with rubber band rollers.

Software

Sensors

We originally planned to have an array of bump sensors all around the robot that would alert us whenever we hit a wall. This didn’t quite happen because we ran out of time and it didn’t seem that necessary anyway, since we had stuck detection based on timeouts and distance traveled. We noticed that some teams who relied on bump sensors during the final competition became stuck when the bump sensors failed, so I think we made a good decision here.

We also mounted two IRs for wall following, but never used them.

Odometry

Having heard from past teams that the given encoders were noisy and bad quality (and we couldn’t use them anyway due to our omniwheel setup), we used two USB Apple Pro Mice to track our motion in x, y, and theta. This theoretically had some accumulation error but seemed to work quite well in practice.

The main problem was figuring out how to attach the mice. Due to bumps and unevenness in the carpet, the mice either dragged on the floor and created excessive friction, or wasn’t close enough to give a reading. This added to our problems with omniwheels and made it difficult to move.

Camera, Vision, and Mapping

We opted not to use the Kinect, because it was unsupported and we didn’t think we would need the depth perception. With a regular webcam, using connected blob detection plus some simple trig we could determine distance to objects and even implement wall avoidance based on vision alone.

We used ball detection in conjunction with odometry data from the mice to implement a simple forgetful mapper, which allowed the robot to maintain a list of memorized ball locations and yellow wall sightings. We didn’t account for accumulation error, but continually updated the map with whatever the camera was seeing presently (forgetting whatever it had seen before within the camera’s viewing angle).

Behavior

Our behavior was modeled by a simple state machine, with two important additions. One was a list of memorized locations powered by a forgetful map, as mentioned above. This allowed the robot to act like it had “memory” without explicitly using any planning algorithms.

The second was our stuck detector, which amounted to essentially a meta state machine with two states: “stuck” and “unstuck”. When our normal state machine was running, our stuck detector would use several metrics, such as “time since last state transition” and “total distance traveled within the last 5 seconds”, to determine whether we had gotten stuck. This would tell our state machine to transition to an alternate state that would be able to deal with the situation.

Random notes

Tim:

• I CADed our design in the first week, however our ultimate robot was nowhere near the final robot. Testing and prototyping along the way is important. Also sanity check your design with other members of your team. Better yet, have more than one person doing build. Even better, laser cut most of your parts so that you don’t spend a lot of time rebuilding parts.
• Jumper cables are awesome. Staff may or may not have them early on, but they are great for testing and changing electrical things quickly.
• Laser cutting and T-nutting acrylic is the way to go. We waterjet aluminum, which was ultimately worse than acrylic because we had a giant hole in our design originally for the box, which we ultimately didn’t use. Acrylic is easily re-cuttable and able to accommodate changes.
• You do not need a very big robot, staying within the recommended size limits is good.
• Being able to move well is very, very important.
• Make sure your team has good communication.
• Sneaky strategies aren’t very useful to simply collecting and dumping balls. It was clear that pleit! and Maslol would win, simply because their robots were designed well and effective at basic elements. That being said, if you want to go with a strategy like color the yellow wall red, you should go for it 100% at the beginning because that’d be hilarious.
• We used a lot of our own metal because I just happened to have extra lying around and we needed a good support structure for a catapult. Metal is not a good choice for large parts though.
• Staff will appreciate it if you put a cheesecake on your robot. We used this recipe http://allrecipes.com/recipe/no-bake-cheesecake-i/detail.aspx and it was pretty good.

Anthony:

• Always test along the way. Unit test if possible. Toward the end of the competition, we had a large body of code, some of which were working individually (like vision), but none of which had been tested against each other.
• Along those lines, if you're doing something fancy like omniwheels, be sure to have a robot to test it on, and make it a priority to get it working early, so you have time to make whatever changes you need, or decide that it won't work and switch to something else. Always have a Plan B.
• Check and double check your electrical connections, and check the current going through your motors. Multimeters are your friend. Nonfunctional Qik motor controllers are not.
• Even if you're on software, make an effort to understand your robot's mechanical design, and vice versa. Strategy informs design. Make sure your design makes sense with the strategy you choose, and that you make good use of your robot's strengths (or consider something different).
• Make a separate file for all your software parameters, for easy tuning.
• If you’re doing a lot of vision processing and it’s taking a long time, Python might be the problem. Python is slow. We used Cython for the critical parts of our vision code and it sped up the processing 100 times.
• Have an agenda, and push to get something done every day. If you're blocking on something, go work on something else.
• Big boxes are nice for carrying things around. Carts are even better, if you have one.
• Having plenty of snack food around increases morale.

Lab Life

• MASLAB is pretty chill, at least environment wise. We worked in 36-5xx, a place with some lab benches and tables. There are no strict times that you have to be in lab, so we ended up working from noon to 10 PM normally, then go back to EC or somewhere and work more.
• The tools in MASLAB lab are useful, but not terribly so. It’s probably enough to use for most things, if you lasercut a lot of parts.
• MASLAB is like a class and a competition. If staff had a team, they would win or come very close, which makes it feel like a class. Some staff are more knowledgeable than others though.