|
|
Challenges
These are some of the biggest challenges we faced throughout the build. If any of these had not been figured out, it would have brought an end to our robot, preventing us from even going to competition.
Mounting gearboxes to chassis - Our first chassis involved corner pieces that blocked access from the bolts required to hold the gearboxes. We had to remake the chassis with large "L" plates, one on each of the four corners.
Ripped keys - The keys that force the wheels to turn when the motors turn ripped when our 12:1 ratio gearboxes attempted to spin 14" wheels. Maximum speeds were implemented for the motors as well as an incremental acceleration system that reduced stress on the keys. This was not enough, so the aluminum keys were replaced with steel keys and they stopped ripping.
Limited to zero manueverability - The four wheeled robot was expected to turn as if it was on tracks. This setup had worked on carpet in previous competitions. However, the combination of grass and large 14" wheels made it almost impossible for the robot to turn. It had to be redesigned with two 14" drive wheels in the center and four casters on each corner.
Hills impossible to climb - The two 12:1 ratio gearboxes were not powerful enough to propel the robot up a moderately steep hill from a standstill. This was fixed by purchasing 48:1 ratio gearboxes.
Weight Limit - This was probably the most depressing time of the season. We found out that the "Robot Weight Range" of 50 lbs was indeed a strict limit. Our robot weighed in at 90 lbs. Besides the frame, the parts that were required including the wheel setup, electronics, battery, and some sensors weighed 45 lbs. Our frame could only weight 5 lbs. We ended up simply attaching our electronics to a metal plate and mounting the wheel assembly onto the bottom of the plate. It looked much better after the electronics were made more compact, the plate was cut down and a plastic see-through frame was made. After the rebuild we were still a few pounds over the weight limit. This was solved by attaching a lighter caster wheel and purchasing smaller and lighter batteries.
GPS data - After receiving the Garmin eTrex GPS, neither of us had any idea how to receive the serial data from the device. It turned out that we needed a null modem in between the two devices so that the signals would be properly transmitted. Unfortunately, this was only discovered after about 36 hours of investigation into NMEA protocol and Garmin protocol decoding as well as serial handshaking and ACK/NAK protocols. Luckily, we got our GPS position right before Ben's parents and grandma came to check it out. It was an exciting moment.
Random loops and spins - Every once in a while when navigating from checkpoint to checkpoint, the robot would do a full loop or turn 270 degrees in one direction instead of 90 in the other. This was a hard puzzle, because instead of being an error in the code, it was a flaw in our logic. Since not all angles were kept positive throughout our code, the robot would sometimes end up turning the wrong way. This was fixed by adding 360 to all negative angles. We probably went through a whole pad of paper making diagrams that night. I would have cried had I gone home with that bug.
Sonar data - This was the first sensor that we were trying to hook up besides the GPS that had no code or explanation provided. After considerable research into pulse timing and reading digital signals, it was discovered that the sonars outputted analog signals and the values could be retrieved easily.
CMUcam2 -- orange cone detection - We figured out how to get the camera to pan around and search for an object in Sergiy's room. It could even track a book as he moved it around. It was all well and good until we moved outside into the sun. If the camera was pointing into the sun, an orange cone would look almost black. If the camera was pointing away from the sun, an orange cone would look completely white. This presented a huge problem when trying to find a range of colors that would designate an orange cone.
There were a few different methods to improve the situation. An orange light filter was purchased to block out non-orange colors. This proved to be worthless. Blurring the image actually helped a lot in getting a good reading from an orange cone. Since the image was blurred, there were less radical orange colors and it all looked more uniform. Therefore, spotting a large blob of orange was much easier. On top of that, the blur also helped with far away noise. There were lots of red rooftops where we were testing the robot which were in the range of colors we told the CMUcam to look for. The blur made those rooftops blend in with the sky and with the grass, which eliminated that problem.
The most significant contributor to solving this problem was cycling auto exposures. A high auto exposure creates a bright image and a low auto exposure creates a dark one. Eventually, we were able to have the camera cycle through a set of three or so exposures that were manually chosen based on the weather patterns at the moment, ensuring detection of the cone. We also had to figure out the specific exposure the camera would use to see cones in shadows.
Our worst nightmare was weather, when clouds would sometimes cover the sun and sometimes let it shine through. In this type of weather, neither our "cloudy" or "sunny" exposure settings would work for all cases. Of course, this is exactly how it was during competition. We ended up blending cloudy and sunny settings right before our first run. Amazingly, it worked.
Two sonars at once - Our avoidance algorithm was designed to use two sonars mounted on the front of the robot. This way, the robot would have an idea of which way to turn depending on which side of the robot the obstacle was. However, when we put two sonars facing straight forward, they interfered with each other. This was circumvented by pulsing them back and forth. The right sonar would get a reading, then the left sonar, then the right, and so on. This on and off pattern still gave enough readings from each sonar to successfully avoid obstacles before crashing.
Touch sensor - About three weeks before competition, we realized that a touch sensor would be necessary for the robot to know when it had touched a cone. It could guess, but this would be unreliable. The first mechanism was made with two touch sensors with whiskers attached to them that spread out over the front of the robot. These worked most of the time on cones, yet they were very flimsy. Not to our surprise, one of the whiskers broke after only a few test runs. Later that night, one of the shocks used in the mechanism broke when being used as a fake gas pedal. Fortunately, this forced our minds into creative thought about possible single shock solutions. The final design incorporated one bar across the front that could be pushed in to press the microswitch embedded inside the system. This was fabricated and mounted that same day.
Compass - Since the sonars sent analog signals, the Devantech CMPS03 digital compass was our first real experience with pulse timing. After a few hours of breaking our heads open, we figured out that the problem was that we were not initializing the interrupts. There's no need to state how frustrating that was. Even though we could get readings from the compass, they were not accurate at all.
The compass relies on two things. First, it has to lie completely horizontal to the ground. At first this seemed like a hard thing to accomplish. Then, a simple gimbal was designed that used gravity to keep the compass level. Granted, this gimbal jiggled violently when moved, but accurate readings could be taken when the robot was still. An algorithm was programmed in to make sure that the readings were consistent (a.k.a. that the robot was at a standstill) before they were used.
Second, the compass must be calibrated whenever it is moved far away geographically. The Earth's gravitational field acts differently at different points on the globe, so calibration keeps the compass accurate. This took us a few hours to figure out, due to the fact that two wires were touching. Once that was discovered, calibration took only seconds. (Imagine listening to Shine on You Crazy Diamond Part 1 all the way through while turning a compass on a roll of duct tape just to find out later that there was a short. I don't have to. I saw it happen. Great song though.)
Auto Pause - After implementing a pause button on the robot, it started auto-pausing itself once it got to its first GPS checkpoint. This was very odd, because nowhere in the code except in the pause function was this possibly happening. This problem was hotfixed by simply removing the pause feature. It manifested itself again later in code errors and auto resets of the microcontroller. It turned out that robot was not pausing when it got to the first location, but resetting once it got to the first location. It just happened to be that we told the robot to start out paused, so when it reset, it paused. The resetting was due to a stack overflow -- the microcontroller's way of saying "I can't take it anymore!".
Code Error/Auto Reset - It's the very last day of testing on the robot and there are only a couple minor improvements that we can think of to make on the robot. All of a sudden, the robot reports a "Code Error" after getting to its first cone. There is no other information given. We try everything from eliminating loops to making prototypes of all global variables and functions. Nothing fixed the problem. Later on, it stopped giving code errors and instead auto reset itself at the first cone. This was very strange. It would go to its first location which didn't have a cone, then proceed to the first cone, then go back to the first location, and then back to the cone. This is when Ben's mom and sister came to take a look at the final product. Hopefully this was the worst demo either Ben or Sergiy will ever have to give, especially because we only had a few hours to fix it or the gig was off. Finally, we discovered that stack overflows on the microcontroller could be the cause of auto reset behavoir. The function that handled the GPS did call itself one time after it reached a checkpoint with a cone. After eliminating this recursive call, the robot worked like a charm. On the last day of work, the microcontroller was pushed to its absolute limit, yet it is still alive (given our luck it should have set itself on fire). Go Zippy!
Overweight Again - After installing a plexiglass shield around the insides of Zippy as well as a PVC pipe for the compass, gimbal, and GPS, the robot ended up being overweight again. Our batteries weighed 15 lbs, so we decided to buy smaller 12V batteries. After they came in, we weighed in at 45 lbs, which was 5 lbs below the weight limit. Perfect.
Broken Gearbox - The Wednesday before we drove up to the competition we went to test the robot one last time. In pure excitement at how well Zippy was doing, we pushed the robot as fast as possible back to its starting location after it finished a run. This ended up breaking one of its gearboxes. The retaining ring that held the shaft of the gearboxes in place slipped off of its groove, causing the shaft to be pushed back into the gearbox. Our wheel no longer span. The gearbox was repaired and disaster was evaded.
The limits of the human body - This was probably the largest problem of them all. We had decided to do the project just two months before the competition, during our Junior year in high-school, with the SATs and the most important finals of our high-school careers coming up. Also, Sergiy is a swimmer who, during this time, got to league finals, and Ben is a black-belt in karate. Looking back on it now, entering the competition was a very stupid decision to make given that we knew nothing about autonomous robots or any of the sensors they used. In the end, however, we are very glad that we did this project, not just because we won, but because we found out what truly hard work really is. From day one until the very last day we averaged maybe 5 hours of sleep per night at best. As soon as we would get home from school we would drink a monster, turn on some trance or some metal, and work on the robot. Regardless of what homework had to be done, or what the next day had in store for us, we would work into the late hours of the night, every night. Some nights Ben did not get home until 5 AM! On the weekends Ben would simply stay over at my house so that we could get to work that much sooner. On the weekends we would work until 1 or 2 AM and wake up at 7 AM, as soon as the sun came up, so that we could work on the CMU cam. I can honestly say that we took absolutely no rests until Zippy was done. Every night we worked until we just could not think anymore, but we forced ourselves to continue so that we could meet our schedule.
Most importantly this project has taught us that hard work and hard work alone gets the job done, and that there are no excuses to be made when it comes to achieving what you want (even if you are on the brink of insanity!).
|
