The primary goals of this project were fairly straightforward; the robot must be able to do the following things:
Of course, each of these goals requires several other abilities such as monitoring distance traveled in a movement, but most of this is taken care of in programming.
The previous robot would not be capable of completing all of the tasks of this assignment, so a new one was constructed. The first objective was to build a robot capable of climbing the ramp. Although it is very possible to calculate the exact amount of power needed to climb the ramp given the incline and robot weight, we did not have the necessary specifications of the motors in use, so we relied on a "guess and test" creation method. A robot was designed with a large gear ratio and a front claw to grab objects, but when trying to ascend the ramp, it would simply spin out or flip over backwards due to the XBC weight on at the rear.
This basic robot was disassembled and rebuilt with a new goal of moving the XBC to more the center of the robot instead of the rear. Moving the weight forward would provide for more drive wheel traction, but too much forward weight would result in a potential front flip problem when an object was picked up by the claw or when descending the ramp. Various arrangements were tested on the ramp until a final design proved effective. This version of the robot had many new features unseen in previous incarnations including rear omni-wheels, a forward gripper, and three drive wheels per side to aide in support and balance. It was more then capable of climbing the ramp and grabbing an object, or doing both at the same time!
Many sensors were added to this robot to help it complete it tasks. In the back, to spring loaded whisker switches were used to allow alignment along a wall. Each side contained two infrared distance sensors for wall following, and break beam sensor were in place to count wheel rotations for moving accuracy down to a centimeter. Two shielded light sensors were placed on the front of the robot to track changes in light as well as another IR distance sensor. The MCU camera was also attached to a servo motor on the front which allowed for camera panning. It would be used in an attempt to locate the "fire" as well as a colored can to be moved. As seen in the above picture, a shield was placed around the camera to block out any unwanted distractions within its peripheral vision.
A simple "left turn rule" was used for navigation. In this setup, the robot will drive straight as long as something is to its left. When an opening is detected, it will turn left until forced to make another decision. The only time a right turn is made is when a wall is seen to the left and in front of the robot. By using this rule, our robot was able to navigate the entire arena within the ten minute time limit. The two IR sensors on the side were used to keep a fairly consistent distance from the wall at all times. The robot would also occasionally stop and pan the camera, looking for any fire. When the light bulb representing the fire was discovered, the robot left is current path to investigate and record the exact location of the fire in the warehouse before returning to its initial trajectory.
A basic map of the warehouse was also created with 1s representing wall and 0s representing free space. This map was updated wirelessly to a host and was also used to ensure no back tracking took place. Eventually, the robot came to the incline and successfully climbed it, exploring the upper room. The descent was just as smooth, and the final rooms of the warehouse were explored before the robot exited the arena. After the arena had been navigated, the secondary test was initiated. A green can was placed in front of the robot, and after detecting the can with the camera, rotating until it was centered, and calculating the distance to it, the can was grasped by the front gripper and moved to an arbitrary location.
As it would turn out, this was our most successful assignment given the overall difficulty of it compared to previous projects. Although the robot did contain many sensors which were not actually used, this was primarily due to the fact that we didn't know how well the robot would preform to our initial strategy, and so we planned ahead with other various options in case of failure.
In all reality, our initial over planning was an important step to take in most any design. Robots are very likely to fail, especially when they have not been adequately tested. It would be best if there were many points of failure and active back up plans which would trigger in a certain circumstance. In our case, we just didn't want to have to redesign the robot to add a new sensor or two. Most all of the abilities created in this project as well as those previously used would be crucial in completing the final project.
Although the robot would not know what it was driving into, we were given a map ahead of time just to ensure there would be no unnecessary surprises.