CSCI445 –
Introduction to Robotics
Final
Project Report
Spring 2008
By Sherwin Gao,
Jason Higuchi, Kazu Miyahara, Johnson Wang
1.
Introduction:
The goal of this project was to design a humane robot that would accomplish a search and rescue mission. The mission would take place in a rectangular arena with one rectangular obstacle in the center. Seven immobilized victims were placed inside the arena and the robot had the task of rescuing them. Within ten minutes, the robot must rescue as many victims as it can and then exit the arena. In the process of rescuing the victims, the robot must be as humane as possible, i.e. it cannot run over the victims, drag the victims, or shoot the victims.
2.
Initial Design Plan:
Our initial design plan was to implement a robot with a conveyer belt design that could rescue all the victims at once. The problem that we had was figuring out a way to get the victims off the floor and onto the conveyer belt. To solve this, we thought of several ideas. One was flipping victims onto the conveyer belt; another was using a crane or claw design to grab victims onto the conveyer belt; and finally, we considered using a sweeping mechanism to sweep the victim onto the conveyer belt.
From the beginning of the design phase, our goal was to implement a manipulation mechanism that had not been done in past years. The final idea that we decided on was a horizontal “sweeper” mechanism that would bring the victims into the conveyor belt – we called it the Claw. We recognized that one of the biggest problems with picking up the victims was that the victims would be oriented at random angles. The sweeper mechanism was chosen to account for this unpredictability; irrespective of the victim’s orientation, the sweeper would re-orient the victim by gently nudging it left and right so that victims would always enter the conveyor belt straight.
Once a victim had been re-oriented and swept on to the conveyor belt mechanism, the belt would transport the victim upward. Eventually, the victim would exit the top of the conveyor belt, gently dropping into a container below that would carry all the victims. The conveyor belt and box are essential to the design of the robot because it allowed us to collect all the victims at once. The conveyor belt created a height difference that would allow the robot to “stack” the victims on top of each other when they were placed in the container.
Please see Figure 1 for the preliminary design concept.
Figure 1: Sketch of the
Initial Design Concept
3.
Implementation
a. Claws
To implement the claw mechanism, we have two immobile arms. Although we initially thought of using a rubber tubing drive shaft that was driven by two plastic wheels for each arm, the final design was just two wheels with rubber tires driven by a series of gears and a motor. The reason for using rubber tires was because after numerous test trials, we found that the rubber tires had more friction, surface area, and a more stable and durable structure.
The reason for the arms being immobile is because after further tests, we found that positioning the arms at specific angles made it unnecessary for the arms to be swung back and forth by servo motors. At the specific angles, the victims can be eased into the robot regardless of the victim’s orientation; the wheels on the arms can reposition the victims so that they always enter the conveyor belt straight. In addition, we decided not to use servo motors to move the arms because it would make the robot structure even less stable; most importantly, we had also run out of servo ports towards the end of our project (see 3.e for the explanation on servo motors).
Please see Figure 2 for a photograph of the claws.
Figure 2: Claw Mechanism Photograph
b. Conveyer Belt
To implement the conveyer belt, we have a Lego tunnel in the body to hold the mechanism. The conveyer belt is composed of several wheels with varying torque. The torque of the conveyor belt wheels is gradually increased (the top wheels with the least torque, and the bottom wheels with the most). This is to account for the fact the bottom wheels initially had trouble bringing up the victims from the floor. However, as the victim is transported upwards, there is more momentum to convey the victim to the victim transport unit.
To further help the bottom wheels bring up victims from the floor, we initially played around with the idea of attaching Velcro to the wheels. The problem we encountered was that the Velcro would get dirty over time and there was no way to clean it while the robot was running. In addition, the victims often get caught on to the Velcro. Instead of Velcro, we decided to just attach a ramp leading up to the first set of wheels. This way, the victims could be eased onto the conveyor belt by the claw arms.
Please see Figure 3 for a photograph of the conveyer belt.
Figure 3: Conveyer Belt Mechanism Photograph
c. Emergency Victim Container Transport Unit
(EVCTU)
For the Emergency Victim Container Transport Unit, we first implemented a stationary trash bag behind the top of the conveyor belt where the victims were emptied. A cardboard plate was then taped onto the bottom of the trash bag to increase stability and provide structural rigidity. However, this design did not work because the unit was too rigid and not easily attachable to the robot. A modified design was then implemented. This design had a cardboard box with a plastic cover that swiveled on the back of the robot which increased mobility and flexibility when turning. More specifically, when turning adjacent to a wall, the flexible design of the swivel prevents the robot from getting stuck against the wall.
Please see Figure 4 for a photograph of the container unit, and Figure 5 for a photograph of the EVCTU’s swivel in action.
Figure 4: Emergency Victim Transport Container Unit Photograph
Figure 5: Photograph of EVCTU’s Swivel Preventing the Robot
from Getting Stuck
Against a Wall
d. Sensors and Handy Board Microcontroller
For the robot to navigate through the arena and rescue the victims, several sensors were used: the infrared sensor, sonar sensor (Figure 7), compass sensor (Figure 8), camera sensor (Figure 9), and bend sensor (Figure 10). They are all connected to the Handy Board microcontroller (Figure 6).
Figure
6: Handy Board Microcontroller Photograph
To know when to start rescuing victims within the arena, the infra red sensor was used to detect the black line that signified the start of the emergency area of the arena.
To navigate through the arena, the sonar and compass sensors were vital. The sonar sensor provided wall proximity, and the compass sensor provided direction. The reason the compass sensor is situated at a higher altitude is to avoid electronic interference from the Handy Board microcontroller.
Figure
7: Sonar Sensor Photograph
Figure
8: Compass Sensor Photograph
To collect the victims, the camera and bend sensors were imperative. The camera was able to detect the victims by their green color, and the bend sensor informed the robot when a victim had been rescued. We placed the bend sensor at the exit of the conveyor belt; this meant that a victim would only be considered rescued once it had completely exited the conveyor belt (bending and then unbending the bend sensor) and placed in the transport unit.
Figure
9: Camera Sensor Photograph
Figure
10: Bend Sensor Photograph
e. Servo Motors
Servo motors are essential components of our robot for three reasons.
One reason is because of their capability to rotate the shaft to a specific angle within the 180 degrees defined by the servo motor. Because of this, we mounted our sonar and camera sensors on separate servo motors; this enabled us to rotate the sensors to optimal angles of interest. With the sonar sensor on a servo motor, it can detect wall distances not only in front of and in the back of the robot, but also on the left side of robot. With the camera sensor on a servo motor, the camera can tilt up and down to detect victims at far and near distances.
The second reason for using servo motors is to activate a customized relay system. We created a customized relay system because the relay systems available in lab required a large amount of current to be activated that we could not supply by normal means. So we designed a new relay system consisting of servo motors and a simple on-off switch. Plastic extensions were attached to the rotating shaft of the servo motors. The extensions could be rotated to an exact position that would activate and deactivate the simple mechanical switches. These switches are connected to a battery system which in turn is connected to a motor system. The motor system will activate the claw and conveyer belt mechanisms whenever the servo motors turn to the right position and activate the switches. This way the claw and conveyer belt mechanisms will be powered by independent battery systems.
The third reason why we need servo motors is for the robot’s locomotion. We originally used four Lego motors but they could not provide enough torque to move the robot. Thus, we used continuous rotation servo motors instead. These servo motors provided enough torque for the robot to move and turn effectively.
f.
Batteries
Our battery system consists of four batteries. Two are connected in parallel to power the Handy Board and the continuous rotation servo motors. They are connected in parallel because the continuous rotation servo motors require a significant amount of power to run; we found that using two batteries in parallel provided enough power for the robot to run for ten minutes. The other two batteries are each connected to the customized relay system (described in 3.e) so they will not have to draw power away from the Handy Board and the continuous rotation servo motors.
4.
Software Algorithm
Due to limitations by the Handy Board microcontroller’s ability to only run at 2 MHz, we have implemented a simple sequential algorithm, rather than executing tasks in parallel. However, the algorithm empowers the robot to run with clever behaviors.
To understand the algorithm, one must first understand the capabilities of the software for the Handy Board microcontroller. The Handy Board microcontroller connects to all the sensors and the servo motors, thus the software for the microcontroller can manage sensor actions, read sensor outputs, and control servo motors’ positions. The software can run multiple threads, but because of the slow processing speed, context switching between threads is costly and can cause sensors to malfunction. This is why we do not use multi-threading in our software. The software is written under the integrated development environment called Interactive C, which closely resembles the C programming language. To be able to easily use sensors and the servo motors, we have programmed our software modularly. For example, to change the servo motor’s position that is responsible for the camera tilt angle, we have implemented a function that we can easily use without worrying about the actual servo motor’s position values (Figure 11).
Continuing on, our robot’s algorithm runs as follows:
(1) Robot starts:
The robot will move forward until the infra red sensor detects the safety line (the black line in arena). The safety line signifies the start of the area where the victim rests and the robot will begin step (2)’s routine.
(2) Robot turns and scans for victims:
The robot will now turn right twice at 15 degree increments, stopping to scan for victims at each increment. It will then reposition itself to the center and turn left twice at 15 degrees increments, stopping to scan for victims at each increment again. The center degree of the robot is the heading the robot was facing before the start of turning and scanning. After turning left, the robot will then return to the center again and scan for victims in front of it. The robot will also make sure to rescue any victims directly below the camera by tilting the camera down and scan for victims. To position itself to the desired headings for each increment, the robot stores the center degree given by the compass reading at the start of this routine and applies the increments to it.
The robot’s algorithm is clever enough to know if it is stuck while it is turning by checking the compass reading every time the robot tries to turn. If the compass reading gives the exact same degree three times in a row, the robot will know that it is stuck against some object. We first assume that the front of the robot is stuck, and thus the robot will attempt to move backward and turn again. If the compass reading is still the same afterwards, then we know that the back of the robot is stuck and thus the robot will move forward at a greater distance and try to turn again.
The robot scans for victims by using the camera sensor to detect whether there is a blob that matches the victim’s color. If a victim is detected during any of the scans, move on to step (3). Otherwise, finish all the incremental turns and scans for victims before moving on to step (4).
(3) Robot rescues victim:
The robot will begin to rescue a victim by first turning on its claws and conveyer belt mechanisms. It will then move toward the victim. While the robot is moving, if the victim’s X position value given by the camera sensor’s output goes outside of the camera’s center view, it will indicate that the robot is not aligned with the victim anymore. Thus, the robot will then continuously adjust itself to become aligned with the victim again so that the victim will never be outside of the view of the camera when the robot is moving towards the victim.
With the robot being able to align itself to the victim and move towards it, the robot knows when the victim is within its grasp as soon as the victim is out of view of the camera. This is because the camera sensor for detecting the victims is positioned in a way where it is not able to detect victims that are right in front of the conveyer belt mechanism. Thus once the victim is outside of the view of the camera, the robot will stop moving. The claw mechanism will then ease the victim onto the conveyer belt, and the conveyer belt will place the victim into the container unit. When the victim is placed into the container unit, the bend sensor will be bent and then unbent, indicating a victim has been successfully rescued and the robot will move on. However, if for some reason the victim has not touched the bend sensor in 10 seconds, we assume the victim is somehow caught between the claw or conveyer belt mechanism. Thus to alleviate this, the robot will do a “jiggle”, which is moving in all 4 directions in quick bursts, for seven seconds. If the bend sensor still hasn’t been bent after “jiggling” for this long, then the robot will give up and move on.
Regardless of whether the robot has successfully rescued a victim or not, the robot will then retreat back to the area it came from. This is done by moving in reverse for the same amount of time that the robot has moved forward to rescue a victim. Once the robot has returned to its original area, the robot will rescan for victims again at the same heading. This is to ensure that there are no more visible victims in front of the robot. This will also help the robot to try to re-rescue a victim that it has given up on earlier. Once the robot is sure that there are no more victims in the current heading, the robot will continue step (2)’s turn and scan for victims routine until it is finished and proceed to step (4)’s move forward routine.
(4) Robot moves forward:
Once all the turn and scans has been finished, the robot will then move forward for a short amount of time and then stop. The distance moved forward by the robot will be approximately the same as how far the camera could see so that the robot does not move into unchecked territories of the arena. While the robot is moving, the sonar sensor will also be checking for wall distances in front of the robot. If the sonar sensor has found a wall that is close to the robot, the robot will turn to another direction and then stop. This direction will always be the right except for the robot’s first turn so that the robot will navigate through the arena in a clockwise fashion. For the robot’s first turn, it will have to turn left to maintain the clockwise navigation around the arena since the robot has just come from the entrance of the arena.
Once the robot has stopped from moving forward, the robot will repeat a cycle as described in step (5).
(5) Robot repeats cycle:
Once the robot stopped moving forward, the robot will continue the same sequence from step (2) to (4) repeatedly until one of two conditions occurs:
- When the ten minute time limit is almost up, such as when eight minutes has passed in the arena
- When all the victims has been rescued (number of victims is announced before hand)
When one of the two conditions occurs, the robot will proceed to exit the arena as described in step (6).
(6) Robot exits arena:
For the robot to exit out of the arena, the robot will continue to move in a clockwise fashion until it has reached the wall that contains the entrance/exit of the arena. Once it has reached the wall, the robot will turn to move in parallel along the wall. The sonar sensor will also be rotated to the left through the use of its servo motor so that it can detect the distance between the wall and the robot. Thus, the robot will continuously move in short distances and then stop to find the distance to the wall. When the robot has detected a wall distance that is much greater than usual, then it is most likely a wall opening. Thus, the robot will turn to face the exit. The sonar sensor will also face forward again and conduct another wall distance calculation to make sure that the robot can fit through the exit. If the robot can fit, then it will move forward and exit the arena. Otherwise, the robot must travel along the wall again and retry until it succeeds.
Once the robot is outside of the arena, then the robot has successfully completed the mission.
