Team Eleven/Final Paper
From Maslab 2011
MASLab Final Report
William- Vision/ Behavior
Tim- Mechanical Design
Table of Contents
Overall Strategy Mechanical Design (Tim) Sensor/Actuators (Kristen) Software Architecture (Kristen)
RobotMain (Kristen) Stop (William) BallGrabber (Kristen) Navigator (Kristen) getState forward rightTurn leftTurn rightPID leftPID bumpLeft bumpRight WallScorer (Kristen) Data (Kristen) ImageProcessor (William) Conclusion (Kristen)
Overall Strategy - WIN! We decided to put the balls over the walls. We wanted to be able to hold a number of balls and reliably capture and deposit the balls over the yellow wall. For the general behavior, we wanted the robot to circle every so often and look for balls and walls, collect balls that it found and deposit the balls over the walls found. If, however, neither ball nor walls were in the robot’s sight when it spun, the robot would then attempt to wall follow for a certain amount of time before spinning and looking again. In addition, the robot needed to be awesome and fast.
Mechanical Design (Tim) Strategy - balls over the wall or captured Design - initial concept to final design
Sensor/Actuators (Kristen) Our mechanical design required an extra drive motor and servo as extra actuators in addition to the wheel motors. The drive motor was used to spin the roller and the servo to open the trapdoor, which cost 7+5 points. We wanted to follow the wall, for which we used the Long IR sensors. Long IR sensors were chosen due to the speed at which the robot approached, the longest distance on the short range IRs were too close and the did not have enough time to turn and consistently hit the wall. We needed the gyro to turn a set distance reliably and look for the balls, in addition to turn 180 degrees and score. The camera was obviously needed to identify the balls and yellow walls. The bump sensors were needed to safely line up with the yellow wall, as well as to avoid getting stuck. The front bump sensors, specifically, protected against the robot approaching a wall too close where the front IR sensor was out of range, and thus returned an incorrect value. In hindsight, it may have been useful to use an laser motion sensor to see if we were moving or not, as we tended to get caught and not necessarily hit a bump sensor.
Sensors/Acutators Used and Corresponding Sensor Points
0 pts 4 BumpSensors (two front, two back) 12 pt 3 Long IR sensors (one left, one front, one right) 0 pts 1 Camera 0 pts Gyro 7 pts Extra Drive Motor 5 pts Servo 24 total pts < max 30 pts
Software Architecture (Kristen) The software had three main parts, the behavior (RobotMain), the orc interface (Data), and the image processing (ImageProcessor).
RobotMain (Kristen) RobotMain was the main class that created all classes, initialized the gyro, and started the behavior finite state machine (FSM) when the power button was pushed. The behavior FSM consisted of a Stop, BallGrabber, WallScorer and Navigator state. Each of the states were passed into Data, which allowed them to access the orc board and thus all the sensors and actuators.
When the robot entered the BallGrabber state, it continuously takes pictures and processes them with ImageProcessor. The software takes the angle error calculated with the ImageProcessor and ran a PID controller. It continued in this loop until the camera no longer saw the ball. At which point, the robot continued forward for one second to ensure that the ball made it into the ball collector. There is a ball count contained in Data, which the code at this point increments. If at anytime the robot no longer sees the ball, it enters the Stop state again.
As our strategy was to go as fast as possible, the PID controller worked in such a way that when the robot wanted to move left the left motor would slow and the right motor would continue going at it’s maximum. The same worked for the right motor. As the camera angle is very small this worked fairly well as the error was never very big. Unfortunately, the controller was not fast enough for a couple of balls that were just in the camera’s line of sight, however this limitation wasn’t much of a hindrance. The motors were close enough speeds that using the same gains for both the left and right motors worked well.
BallGrabber had a timeout in it, that performed a subroutine contained in Data. This subroutine is used in Stop and Navigator for when it hit a bump sensor and essentially backed up and turned. After this subroutine was finished the FSM entered Navigator.
As our robot’s mechanical design limited it in it’s ability to pick up balls next to walls, this state contained a function that said if the robot had attempted to pick up a ball three times and hit a bump sensor everytime, the behavior FSM entered the Navigator state and went and looked for other balls. It also subtracts three balls from the balls collected count in Data.
Navigator (Kristen) The Navigator state is another FSM which contains 8 states, getState, forward, leftTurn, rightTurn, leftPID, rightPID, bumpLeft, and bumpRight. getState: When the behavior FSM enters the Navigator state, it pulls all of the IR sensors. If the front sensor is less than some minimum the robot enters leftTurn or rightTurn depending upon which sensor reads something closer. If one of the left or right IR sensors are within a certain range then it enters left or right pid correspondingly. If all of the sensor read far away it goes forward. If either of the bump sensors are pressed it enters that corresponding state, bumpLeft or bumpRight. forward: This state makes the robot continue to go forward until one of the sensors is within range at which point it enters the same state as described in getState. leftTurn: In this state the robot continues to turn until the front sensor reads greater than a certain number and the right sensor reads greater than a certain number, at which point it enters rightPID. If a bump sensor is hit, the Navigator FSM will also exit to the appropriate bump state. rightTurn: This state behaves in the same way as leftTurn only reversed. leftPID: In this state the robot is wall following using the left IR sensor. When the computer enters this state, the left_dist is set to the IR’s current reading. The error is then caluclated from the current IR reading and left_dist. This controller used similar logic as the BallGrabber, where it slowed down the appropriate motor. This technique gave quite a bit of leeway in the PID controller and allowed for the noise in the IR sensors. To exit this state, the front IR sensor needs to be less than a certain minimum, in which case it enters a right turn. It will also exit to the turn state if the right sensor returns less than the minimum. It will always exit if a bump sensor is hit. rightPID: This state behaves in the same was as leftPID only reversed. bumpLeft: This state calls a subroutine contained in Data. Originally, the subroutine was only in navigator, but it is also useful for other states as well so it was moved to Data so all Main state could access it. It is the same one described in the timeout of BallGrabber. Essentially the robot backs up and turns. bumpRight: This state behaves in the same was as leftPID only reversed.
All of the individual Navigator states contained a timeout. In the event of a timeout, the state switches to the forward state. If the forward state times out then it switches to left or right turn. There is also a Navigator timeout. The Navigator timeout moves the behavior state to Stop where the robot stops and looks around.
WallScorer (Kristen) The WallScorer contains an approach PID controller, a 180 degree turn, a back up, and a stop and drop trapdoor.
The PID controller is the exact same as the BallGrabber PID. The error is returned from ImageProcesser, in the same units as in BallGrabber, except to the center of the wall. This PID controller is run in a while loop until both front bump sensors are pressed.
When both front bump sensors are pushed, the robot turns 180 degrees, as determined by the gyro. There is not controller in this loop instead a while loop was written which states that if the gyro reads a number less than the a number that corresponds to 180 degrees keep turning. It worked well, despite the lack of controller.
After it has turned a sufficient amount the robot backs up. It will continue to back until it either times out, which it did most of time or both back sensors hit, which indicated a perfect allignment. At this point, the robot lowers it trapdoor and waits while the balls fall out. After this ball count in Data is set to zero, and the main state changes to Stop where the robot looks around for more balls.
There are a couple of different timeout features in this state. First, if the robot times out before both of it’s front sensors are pushed, it assumes that it is stuck and backs up and turns (subroutine in Data). If the robot thinks it has arrived at the wall (aka both bump sensors pressed) it checks and sees if the amount of wall is large enough to be the wall. Otherwise, assumes it is stuck and backs up and turns which is the same subroutine in Data.
If WallScorer times out in any portion after the first two sensors hit the wall it continues on to the next step.
It would have been slightly better if when it was approaching the wall if one bump sensor hit, that side’s wheels spun backwards slightly, and the other’s side wheel went full force.
Data (Kristen) The data class contains all interfacing to the orcboard. It also allows all other states to interface with the orcboard with get, set and update function for all sensors and actuators. Data also contains and global function and variables than need to be known across all states. The most notable function is the avoidBumpLeft() and avoidBumpRight() methods, which simply back up and turn 90 degrees. This turn is based off of the gyro, but it didn’t need to be. It was simply done because we already had the capability and the actual amount turned changed considerably when the battery was low. This class also kept track of time. TimeCompete() was checked at every while loop. This function allowed us to avoid threading. However, if it wasn’t checked at every while loop and on the off chance the robot got caught in that loop, it wouldn’t stop. In hindsight a thread that only checked the time and stopped the main thread if the time was complete would have been more efficient and reliable. We were concerned about the processing power of the eePC, and if we would notice a change if we introduced another thread, but I do not think that this would have been a problem.
Conclusion (Kristen) In conclusion, we did fairly well and placed third. We had a couple of problems getting caught, which could have been improved upon. Our major failure mode was the orc board which we managed to short 5 different times. One of these times was in competition, which prevented us in competing in the final round.