The goals of this project were simple and straightforward. How we decided to handle them was almost entirely up to us, but the overall robot requirements were as follows:
We were given a few requirements by our instructors as well such as using the XBC as the main controller. (See the Mobile Robotics projects page for more XBC use.) Another thing expected of us was to use the PSoC microcontroller boards for lower level tasks such as motor control. These development boards were widely used at our school, but I never did much of anything with them.
As for the casks to be manipulated, these were standard sized soup cans with varying levels of sand inside them. We were not told how much sand would be in them or what the weights would be until the day of the competition. The correct placement of each cask based on weight was also only told to us moments before our round in the competition, so we had to have some way to quickly select an operational mode for the robot before each round. On either side of the cask was a 4 square inch piece of foam board which sealed the can and allowed it to stand on its side off of the ground.
Right from the start we ran into a few issues. The CS students usually spent their entire first semester working on presentations and reports, but we needed to get started building. I started jotting down notes in my spare time-anything that I thought might give us an advantage in the competition. The previous year's team had come in fifth place in their competition (the tasks and requirements change each year) so we had high expectations and pressure from the university staff. Then, just when we were starting to get good ideas flowing, our computer engineer decided to take a semester off for personal reasons so we were down a teammate.
Although it probably wasn't the best place to start, the first things we discussed were ways of picking up and moving the casks. There was never really any thoughts other than a typical, wheeled, mobile robot. Here are a few of the fork lift ideas I came up with.
Most of these ideas were shot down due to potential unnecessary difficulty; however, compared with the rest of our design, most of these lifts would have been simple! After deciding on using a simple two pronged fork lift, we started thinking about types of drive trains. The previous teams had used standard differential drive arrangement, but because of their four wheel drive architecture they had difficulty making accurate turns. The only other easily achievable options would have been to use free wheeling castors (also not good for accurate turns) or a motorized turning wheel. It was at then point that our imaginations ran wild, and we started digging on our graves, metaphorically speaking of course. We began to tinker with the idea f using omnidirectional wheels instead of typical castors. Omni-wheels could move laterally due to their unique make up. From here, we dreamed up a drive train consisting of four powered omni-wheels arranged such that robot could move in any direction at any time without rotating. So much for keeping it simple. This was my initial design sketch:
If that wasn't complicated enough, the next bright idea I had is what really did us in. Since the robot didn't need to turn to drive around, I imagined a central "turnstile" which held the fork lift. This would allow the fork lift to revolve around the robot without the robot needing to change direction or rotate itself. If only we had more time or were amazing programmers, this overall strategy would have been pretty amazing.
Of course, it wouldn't have been good enough for the entire upper portion of the robot to turn, only the central layer needed to turn. That only increased the overall mechanical complexity, so it took longer for me to build.
After assessing what would potentially work and what materials I had access to, I ironed out an actual design for the turnstile layer. Since we had easy access to the Lego Mindstorm pieces used in the Mobile Robotics class, that would be the primary ingredient in this disaster recipe.
The rest of the design such as sensor use and electronic placement was created as needed. We didn't really know what we would need, so we just added things as thought of them.
The frame itself was made entirely out of aluminum stripping from Lowe's. It was basically a lightweight tank until the motors and wheel were added. They contributed the majority of the weight to the entire robot.
Also, a lot more nuts and bolts then were probably needed were used to hold this thing together. Taking the frame apart for any alterations was not an easy task, but I did have to do it quite a few times before this was over. If nothing else, it taught me a valuable lesson in terms of what is needed versus what is wanted. The robot wasn't going to be going to war, so it didn't need to be strong enough to survive heavy impact, but it did look pretty cool.
It was then on to designing the turnstile frame and attaching a gear box for the forklift. Because we didn't know how much the casks would weigh, we had to consider the maximum weight of a soup can completely full of sand. That wasn't exactly light, so a large gear reduction was used. I built a few different versions before finalizing on one that seemed to be stronger then we would ever need. The worst part about the lift gear box was it's vertical size. We had all anticipated the turnstile layer being a very thin such that its operation would be an unexpected surprise to anyone watching, but the end result was a tall, top heavy monster that gave away its secret at first glance. To power the rotation, a second motor was placed perpendicularly to the track and attached to a large Lego wheel to allow rapid movement. Small Lego wheels were used as guides on the track as seen in the conceptual design.
At some point in this process, I tried to improve the aesthetic qualities of the robot by adding some paint to make it both more visually appealing and full of school spirit. This explains the red, black, and white color scheme seen throughout the robot. Another bit of color unrelated to the aesthetics is seen on the base of this layer. Anticipating the use of an IR sensor to know how far the turnstile has rotated, a series of black and white stripes were painted on the wood to act as a very large encoder.
The most notable problem with the turnstile was the lack of traction in the wheel used for the turning. This would not have been a problem if the entire upper level spun, but keeping this rotation to the lift required a lot of additional thought. One solution was to add weight to the drive wheel to keep it on the base. Small wheels were also placed at the top of the turnstile level to keep it pressed down from the layer above it. A simple fork was designed and mounted to a servo motor to keep the robot under the size limitations.Once the sensor board was completed, each individual IR pair was tested before the entire system was attached to the base of the robot.
In the end, the robot was a lot taller than we really wanted, primarily due to the thickness of the lift gear box and turnstile design. What gears were actually needed could have been spread around the turnstile to reduce height, and a much smaller drive wheel could have been used.
The one thing going for ASLOC was mystery. No one really had any idea what was going on or how it would work until he started. Everything mechanical you see here I built.
All in all, five different regulation circuits were used: 9V for the controllers, 7.2V for the motors, 5V high current for the sensors, 5V low current for various chips, and 3.3V for a few sensors. All of this was packaged neatly on a single board that I designed, but I don't have any documentation of the design. The only thing I really know about this circuit is that the 9V, 7.2V, and 3.3V rails were created using a modified version of the regulator designed for the Mousey Power Supply. To increase the current capacity, three Darlington pair transistors were used in parallel to create the motor voltage.
The final power layout called for four 22mAh batteries, with two groups of two parallel packs. A central switch would select which battery set was in use, while two additional switches controlled whether the battery was connected to the circuitry or to the charging jack. We really like our switches! Lastly, fuses were used to protect each of the batteries and the high current regulation circuits and a small fan was placed near the regulation circuit to keep it cool.
here. Because no additional components were needed with this chip, we didn't come up with any sort of schematic. Also, the two outputs of each chip were used in parallel to allow a higher current limitation resulting in one chip used per motor. All six chips were mounted on a single board.
Each sensor output goes through a NOT gate to digitize the data. The array of 7402 and 7432 gates are there to provide a "four corners" indication for easy alignment at intersections because each row of sensors was only seen at one of the two motor controlling PSoCs. The actual schematic is pretty big, but here are the connections for a few sensors.
To weigh the casks, a Wheatstone bridge was used. Strain gauges were applied to the fork lift such that as a cask was picked up, the fork support was bend slightly and change the resistance of the sensors. This was measured and sent to the PSoC to be interpreted into a weight. This system worked incredibly well, yielding very accurate measurements.
To detect and align the robot with the casks, three Sony infrared distance were attached to the fork lift - one either side and one in the middle. These sensors work by emitting a modulated IR light which reflects off of an object and bounces back into the detector. The distance to an object is determined by the angle of reflection. These three sensors ensured perfect alignment with the casks for retrieval, but eventually cost us the competition because we did not have any sort of error detection code to tell the difference between an object's reflection and a bright flash of light from a camera. When someone took a flash photograph (a strictly forbidden but all too common of occurrence at competitions) the robot "thought" it had seen the cask and began trying to align with it. This error not only caused it to miss picking up the cask it was attempting to retrieve, but changed its trajectory, causing the robot to loose track of its place on the board. Lesson learned - always anticipate and account for sensor error and junk data!
The robot was to be placed in the center of the arena with the fork lift facing the central cask. Upon start, it would lower the fork lift and line follow until it detected the first cask. The alignment and retrieval would follow. The robot would then weight the cask and revolve it around the base using the turnstile. It would then line follow to the appropriate drop off point based upon the weight of the cask. Cask weights and placement were random, so this movement could not be hard coded. Once the robot had dropped off the cask, it would spin the turnstile back around and approach whichever cask it was closest to at that point (the left one if the first drop off point was in the center). The process was repeated until all three casks were retrieved.
In the event we had made it to the final round, a camera was in place on the front of the robot to be used for color recognition. The robot would first scan the three colored bins, and the above process would be repeated with each weighed cask being delivered to a specific colored bin instead of just a drop off point. It all sounds so simple when you lay it out in such terms, but getting a robot to act even semi-intelligently can be a completely different experience.
The night before the competition, we were scrambling to improve our code, as were most of the other competitors. A few major successes were found in increasing the speed. The robot was actually able to complete the entire course in a little over a minute, butt with one last alteration of the code, ASLOC was never the same. The robot started to move unexpectedly and unlike any previous test runs. Previous versions of the code were installed, but the results never improved. I even swapped out the XBC in use for the backup with no improvement. A few too many last minute gambles had greatly decreased the robot's stellar performance, and as the hours past by and we approached the morning, it was clear we were not going to win. We ended up having to skip our first round just to get the robot to work at all, and put all of our bets on our second and final trial round.
Everything started fine, with the robot approaching the first cask beautifully, but with the flash of a single camera, the front distance sensors reported a series of junk data that "confused" the robot into thinking it had seen the cask. This caused it to begin alignment much to soon, missing the cask completely. As the robot approached the edge of the board, it knew it had missed the cask and resulted to our "fail safe" of giving up on that cask. The turnstile spun around, actually catching the cask in the process. The cask remained attached to the fork as it tried to return to the lines to approach a second cask, but it could never figure out where to go from that point, eventually running off the board and disqualifying us from the competition. A year's worth of hard work was completely destroyed a single moment of robot confusion.
The single most important lesson to be learned from this experience was to keep all of my designs as absolutely simple as possible. This is still hard for me to do, as my imagination tends to run wild with incredible possibilities. If nothing else, this was great learning experience in the actual application and implementation of electronics and robotics. Someday I hope to create a robot loosely based on ASLOC, but that will be a project for another day.
Dimensions for the casks
One of our test casks
Vex Platform omni-wheel
Mechanum wheels in use
The dual "transwheels" we used were 4" in diameter and had a rubber coating on each individual castor for better traction.
The custom wheel mounts
Motors mounted to the aluminum frame
Completed base frame
Turnstile track on wood
Lift motor and gears
The turnstile encoder
The turnstile mounted to the chassis
Mounting the fork to a servo allows it to be tilted up when not in use.
Showing both upper layers
"Custom" 12V battery pack
Power regulation circuit
Mounted power circuitry
The 3 "ET" sensors allowed cask to fork alignment.
The XBC (lower center) commands each of the two PSoCs (left and right sides) which control the motors and read sensors.
The CS team members work on some last minute code changes.