Projects‎ > ‎Robotics‎ > ‎

ASLOC - Asycronous Split-Level Omnidirectional Construct

At Southern Illinois University Edwardsville, where I got my undergraduate degree in electrical engineering, everyone is required to complete a "senior project" in order to graduate. While some departments only require their aspiring business people, nurses, or teachers to create a simple presentation or copy someone else's work and call it "research," we were required actually create something. I was grouped with another electrical engineer, a computer engineer, and two computer scientists to form a team to compete in the 2008 IEEE robotics competition held in Kansas City, MO. The theme was the handling of hazardous waste, and we were to create a robot capable of handling and sorting small casks representing said waste. We would then give periodic presentations regarding our project status and a final presentation and report detailing every step of our journey. This project was full of obstacles beginning with the leaving of our computer engineer and ending with an all-nighter in Kansas City trying to get the robot to work properly. Although the end results weren't as good as we had hoped for, this experience taught me a lot about the design process and working in a multidisciplinary team.

Project Overview

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:

  • Create a completely autonomous robot capable of manipulating a soup can
  • Robot can move my any means but flight (seriously?)
  • Robot must be able to determine weight of can
  • Robt must display weight of can
  • Robot must relocate can based on weight
  • Robot must be able to distinguish colors for final round can placement
  • Robot must complete tasks within 3 minutes
  • Root cannot leave the playing field
  • Robot must fit within a 12" by 12" square

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.

Conceptual Designs

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.


Although the overall complexity is undoubtedly what cost us this competition, I am pretty proud of the fact that I built 100% of this robot myself. I can't take the sole blame for the design, but it was up to me to make sure this thing didn't fall apart.


I actually got off to a great start building this thing, starting with the drive train. The only real obstacle I had was trying to mount the motors we decided on to the transwheels we planned to use because they were designed to be free-wheeling. After a few failed prototypes and a lot of time spent at Lowe's, I pieced together the perfect size coupler with a couple of washers and a fabricated hub for the motor. The brass couplers were epoxied to the wheels and connected to the hubs with a long bolt. The only known issue from doing this was a slight wobble in a couple of the wheels that kept the robot from driving in straight lines without any sort of feedback.

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.


The middle layer was by far the most difficult part of the entire build. It might not have been as bad if I hadn't insisted on only the fork lift section rotating instead of the entire top level of the robot. Again, this looked cool, but it didn't do anything but increase complexity. The base of this layer is a thin sheet of wood that cut down to the dimensions of the frame. A thin aluminum strip was then bent into as perfect of a circle as the tools in my dorm room would allow to form a track, and this was epoxied to the board.

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.

Mounting Layer

This was all of the mechanical work done until most of the electrical was designed because the next layer would be to mount all of the circuits, and we didn't know what would be put there. Two top layers were actually used. A smaller "sandwhich" layer held all of the power circuitry and batteries while an exposed top layer contained all of the electronics which need to be accessible. These were created using wood in the same fashion as the turnstile base had been withe various holes drilled for wires and mounting bolts.

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.


Strangely (and sadly) enough, for a team of two EEs, not a lot of electronic design went into this robot. There were a few circuits designed and built, but the bulk of the electronic design was figuring out what sensors to use and how to hook it all together. Another factor in my discontent for this project is the lack of documentation I have on what we did do.


Looking back, this is still a sore subject for me, but what isn't? The batteries we inherited from the previous team were 7.2V 2700mAh NiMH rechargeables, and had been used well beyond their rated charge/discharge life cycle. During a moment of stupidity fueled by frustration and lack of sleep, I decided the voltage level needed to be 12 instead of 7.2, mostly because the battery system in the XBC controller was 9V. I was also under the allusion that increasing the total available voltage would increase the total available current. This is obviously incorrect, but no one seemed to notice at the time. I didn't really consider that there was a regulator in the XBC and PSoCs, so they would have taken the 7.2 V perfectly well. To create the new source voltage level, I purchased a few more 2700mAh AA cells to put in series with the other batteries. (Did I mention how stupid this was?) Even though these batteries were eventually replaced due to bad performance, the power scheme had been designed using a 12V battery, so that could never be altered. The real problem with using the 12V was that the motors were only rated for the original 7.2V, so a lot of power was wasted in regulation.

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.

Motor Control

There really isn't much to be said in this department except that we had a lot of motors to control! To drive the motors, the L239 chips were used. A datasheet can be found 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.


Aside from building the robot, adding sensors is what consumed most of my time. An encoder was placed on the shaft of each drive motor to allow accurate wheel speed measuring, although this wasn't really used. The robot did use an experimental line following algorithm based on my cross IR sensor design. Because of the orientation of the drive wheels and the fact that the robot could move in any direction, special care had to be used when placing the line follow infrared sensor array. A row of nine sensors was placed along the axle line of each wheel set, forming a cross under the center of the robot. Here is the original concept schematic for the line following IR sensors.

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.

Once the sensor board was completed, each individual IR pair was tested before the entire system was attached to the base of the robot.

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!


Quite possibly the biggest flaw of this robot was the system of main controllers. We were somewhat required by our sponsors to use the XBC robot controller, but it was also suggested to use a PSoC to control any lower level algorithms, such as driving the motors and reading the sensors. The XBC would then make decisions and send commands to the PSoC on where to go. Because we had so many motors to control and sensors to read, we ended up using two PSoCs, one to control each direction of travel. Because of this, an over-complicated communication was used between each device. Being the naive college students we were, it never occurred to any of us to simply use a type of I/O expander, and I had never worked with microcontrollers before, so I had absolutely no idea what I was doing. This portion of the design was handled almost entirely by the two computer science students and the other electrical engineer. If I were to rebuild this robot today (and was still require to use the XBC), it would read all of the sensors through I/O expanders, and the motors would be controlled through individual driver circuits on the I2C or SPI data bus. Oh well, hindsight is 20/20.

Strategy and Performance

There is no dancing around this fact - the robot did not work, plain and simple. With all of the intricate designs, we had planned on an easy victory, but writing code for three separate controllers and getting them to communicate was no easy task. From the beginning, I had said I could built basically anything we could come up with but I would have no idea how to program it. That was no lie. With that said, I have absolutely no idea what was going on with the majority of the code. The only things that I did write was the PWM control for the turnstile and reading any of the associated sensors. I do, however, understand what the robot was supposed to do\, and that is what I will describe here.

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.


The competition track

The final round would require color recognition.

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

Motor encoders

Thin foam board is used to hold the IR sensors.

It's a mess of wires with the sensors installed.

The finished sensor board looks pretty nice.

The sensors are secured to the base.

The LED indicators were a must to see what the robot could "see."

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.