Adam Horton

Document Sample
Adam Horton Powered By Docstoc
					           ENGR 117
Semester Project: Lego™ AORRS

           Team 23
       David FitzSimons
        Adam Horton
        Mike Menzer
       Andrew Mundell

          May 1, 2004
    Lab 4, Th 1:30, Enad 138

Executive Summary-

         To develop a prototype system to demonstrate the feasibility of an autonomously
operated robotic retrieval system (AORRS) that is capable of moving manufactured
products from specified storage locations to a centralized repository within a warehouse
facility. This AORRS must operate at a minimum running velocity of 0.5 ft/s, and a total
average velocity of 0.3 ft/s. It must operate within a “corridor system” designed to
resemble hallways in the warehouse facility which are 12” wide. The AORRS must
operate by traveling to a “home location” which minimizes the total distance traveled to
each bin it must go to. Once at each bin, the AORRS must transmit a signal, to resemble
exerting a force to pick up a washing machine, and then return to the home location.
         To accomplish this goal, four subtasks were set up (Subtasks 1-4) to complete
parts of this objective, with the ultimate goal of minimizing the error of movement. These
subtasks involved three different tasks. The first task was to have the robot move forward
and backward a number of distances and return to the point where it started (present in
subtasks 1-3). The second task was to have the robot move forward a given distance, turn
around 180°, come back the same distance, and turn around again a number of times
(present in all four subtasks). The third task was to have the robot travel to a specific
point by any reasonable means (present in subtasks 3 and 4). These subtasks were graded
by the robot’s ability to accurately go to the points specified (home location or given
location), and how close the robot was to its final location.
         For the subtasks, our team mainly used robot designs with two independent drive
wheels, and a set of corrective wheels to keep it going straight, then some type of lift
mechanism to lift the corrective wheels off the ground, allowing the drive wheels to
operate separately, and the robot to turn. However, for the final presentation, our robot
used two separate chasses, orientated perpendicular to one another, and both with the
ability to move forward and backward only. A lift mechanism switched between the two
chasses. We knew that a robot design that did not turn would prove to be more effective
for the final presentation.
         While we know very few exact numbers for each individual subtask score, our
robot performed moderately in the subtasks, specializing in going perfectly straight and
getting to a given location. The reason our robot had difficulty turning is largely due to
the fact that turns were based on time, because the operating system we used for the
subtasks could not handle using a sensor to guide the turns to the level of precision we
needed. For the final demonstration, our robot performed superbly, receiving an overall
score of 90/100 and only missing points for optional redress and timing considerations.

Design Considerations-

      When given the first subtask assignment, which was to move forward and
backward, and to turn 180°, in order to return back to its original position, we were torn
between two robot designs to accomplish this task. We didn’t know whether to use two
leading drive wheels and skids on the back (which would have been more beneficial for
backwards motion) or to use a single pivot wheel on the back (for better turning). When
we arrived at the presentations for the first subtask, we found, to our horror, that the floor
was extremely dirty, and would not be cleaned before our robot was to perform. Neither
of the designs we had debated over would be effective at all under these conditions, as
they both depended on the floor being a relatively flat surface. As a matter of quick
thinking and ingenuity, we redesigned the robot to operate with four large wheels, and no
turning capability at all. We scored very well on the first subtask part and failed the
turning part, along with most of the class. Out of the ashes of this first failure, we learned
something very important with regards to the final project: turning will not satisfy the
needs of this project. As a result of this revelation, we constructed a mental outline of the
final design of our robot: our final robot would have two independent sets of wheels,
perpendicular to each other, so the robot would never have to turn. Unfortunately, for the
rest of our subtasks, the robot was required to turn, so our robot went through several
intermediate design stages in order to earn points on the following subtasks.
        The next robot design featured two independent drive wheels, with two guiding
wheels behind them on the same axle. This initial mechanism allowed the robot to go
straight quite effectively. On the back of this design, there was an “erectile motor,” which
picked the guiding wheels up off the ground by literally slamming down a wheel in the
rear of the robot, allowing the drive wheels to turn independently and giving the robot the
ability to turn. With this design, we were able to turn and go straight effectively,
regardless of the condition of the floor (because only large tires were touching the floor at
any given time), but the turning of the robot was based upon time, and until we were able
to use BrickOS, the light and touch sensors weren’t precise enough for use, so we were
stuck with the inaccuracies of time. This robot design proved to be quite inconsistent in
its errors, because of differences resulting in battery power loss. This robot design
                                          seemed to perform best when Britney Spears
                                          music was playing down the hall, so we brought a
                                          few of Ms. Spears` songs to the demonstration
                                          and played them for the RCX. The last song that
                                          was playing before we went to perform was
                                          “Lucky,” and during the turning task, we got
                                          extremely lucky by coming close to going out of
                                          bounds, but staying in bounds and getting a good
                                          score. From this moment on, our robot would be
 Picture 1 (above), Picture 1(right)
and we refer to this particular design as Lucky I.
After this demonstration in Subtask 2, we decided
we would need something more reliable, and
completely remodeled Lucky I. The next robot
design can be seen in Picture 1, and was given the
name Lucky II. Lucky II’s unique features
included a “gear locking mechanism, which can
be seen in Picture 2. It involved putting a
synchronizing gear mechanism on the drive wheel gears, making them turn exactly
                                          together when the gear was introduced. Attached
                                          to this mechanism was a wheel to allow the robot
                                          to turn, as can be seen in Picture 3. Lucky II was
                                          able to go in a straight line nearly perfectly, but
                                          with a time-based turn, she still couldn’t turn
                                          accurately, or consistently. Also, the distance (7
                                          inches) from the axis of rotation to the end of the
                                          Lucky II was too long to turn within the smaller
                                          corridor size of the last subtask. To make turning
                                          possible, we had to alternate the direction Lucky II
               Picture 3               turned and place her to one side of the corridor. This
design was used for Subtasks 3 and 4.
         Finally, with the turning restrictions out
of the way, Lucky could show her true colors.
After two designs (the first one proved to be too
large to operate within the corridors), Lucky III
was born (Picture 4). Lucky III featured two
chasses (Pictures 5 and 6), which operated
perpendicular to each other, and were lowered
by a lift motor mechanism (Picture 7). Lucky III

                                         Picture 4

                                         Picture 5

                                         Picture 6

                                         Picture 7

                                       also featured two light sensors, one on each set of
                                       wheels, used as an odometer. (Picture 8) These
                                       sensor-odometers were found to be highly precise
                                       in tracking how far Lucky would go, in
                                       conjunction with the BrickOS Operating System.
                                       Lucky’s movement for each independent chassis
                                       was considered to be as important as the accuracy
                                       of a 90° turn. This robot design performed
extremely well due to the minimized number of places where error could be a factor.
Using small drive wheels allowed us to control the speed of Lucky III very precisely, so
we could give her the fastest speed possible without the tires slipping. The most difficult
part about designing Lucky III was the right balance of stability and size. The smaller the
dimensions of Lucky III, the more margin for error we would have before going out of
bounds, but the lift mechanism needed to be
strong enough to lift up what was essentially an
entire robot (see Picture 5, the N/S Chassis) in a
perfectly vertical manner, as well as be strong
enough to keep the wheels exactly where they
were designed to be so that Lucky III’s movement
would be perfectly errorless and predictable. The
                                     first design
                                     for Lucky III
                                     (Picture 9)
                                     proved to be         Picture 8 (above), Picture 9 (left)
                                     too large, with dimensions of 9.5” × 10.5”, while
                                     the final design had dimensions of 8.75” × 9.5”.
                                     Using a robot design that, through its inherent
                                     perfection, eliminated the many error factors that
                                     come from using the Lego™ motors and RCX™
                                     proved to be the backbone of the success of Lucky
III, and having a code that complemented and exemplified the unique properties that
make Lucky III the superior robot that it is, allowed us to create a truly wonderful robot.
We can say now with confidence that luck was not a factor in Lucky’s success.

Software (Fortran program)
        The Fortran program was designed mostly for functionality, and therefore did not
implement many unique features. It prompts the user for all necessary data, calculates
the best path for the robot to travel, and prints a map of the travel of the robot. It also
calculated the average velocity of the robot and total time as it went through every step of
the retrieval process. Perhaps the most important thing the program did was create a
header file for the C program which would actually run the robot.
        The points entered were stored in two arrays, one of x locations and one of y
locations. There was also an array that stored the number of visits to each location. A
home location was determined using these points and the equation from the project write-
up. In order to evaluate the equation for the x home location, it was necessary to sum up
the products of the weights and the x-values and divide by the sum of all the weights.
Sums were calculated with for loops. The same process was used for the y home
        Once a home location was determined, the M values of all points were calculated
by finding the product of the weight, the difference between the x and x-home, and the
difference between the y and y-home. Using a standard bubblesort, copied from the first
lab practical, the M values were sorted from highest to lowest. One modification of the
bubblesort was made so that whenever two M values were traded, its corresponding x, y,
and weight values were traded as well. Now a header file for the C program was made
by writing all calculated values to a file. This was done simply by opening a file, and
using write statements to create #define statements that were to be used in our C program.
        Once the order of the values was known, a movement map was made. After a few
simple print statements were made to bring the robot to the home location, we used a
nested for loop for mapping bin retrieval. The outer loop ran for the number of bin
locations, and the inner loop ran for the number of visits for that bin. Within these two
loops, we printed a y movement, a turn (change in axis), an x movement, another turn
(change in axis), pulling into the bin, transmitting, and then all of the steps in reverse.
Distances were calculated by taking the destination location and subtracting from the
current location, which was kept in two variables titled CurrentX and CurrentY. The
time taken to complete a motion was calculated using a predetermined velocity and the
distance. A predetermined time to change the direction of motion was used for times of
this motion. A counter for total time and total distance were kept to be able to print
average velocity.
        The Fortran program went through a number of altercations, most of which were
the result of understanding the project better through questions and explanations in class
and online. Our first change came when we realized that the home location was to
always be located on an intersection of a row and a column. Although this would make
programming the movement of our robot easier, it required us to modify the home
location determined by the equations given in the project write-up. Although this seemed
a difficult task at first, once the idea to use the modulus function was decided upon, it
became an easy task. We simply had to find the modulus of our x-value of the home
location and 4. If the remainder was less than 2, we rounded the x-value of the home
location down to the nearest multiple of 4, and if the remainder were greater than or equal
to 2, the x-value of the home location was rounded up. The same thing was done with the
y-value, but a modulus of 2 was used instead. Another modification that the program
went through was when the loiter time was found to be constant for all of the bins.
Previous to this discovery, we had used an array to store the loiter times. We simply
fixed this problem by having a single loiter variable and replacing every time it was
referred to as an array by this value. One unique feature of our Fortran program that we
noticed many other groups neglected was the use of proper format in the movement map.
Properly using features that aligned all of our columns made reading expected movement
very easy.

Software (C program)
        One of the greatest concerns in the development of the C program was that it
could be easily and quickly modified. Our robot would be subjected to substantial
amounts of testing, and the program would require frequent alterations. We could not
afford to waste time editing an unnecessarily long and complicated main function. For
this reason functions controlling each individual action performed by the robot were
written before the program as a whole was put together. For example, separate functions
were written to run each set of wheels as discussed above, as well as to lower the proper
set of wheels to the ground.
        Once this was done these functions could be used as building blocks to structure a
logical and easy-to-modify program. The next important consideration was how the
robot would determine which columns and rows to travel on its way to and from each
bin. (The first movement to the home location was simple, moving down row zero to the
appropriate column and then up that column to the home location.) After some thought it
was determined that the total distance traveled would be the same regardless of which
columns and rows the robot used, as long as it traveled the most direct path. For this
reason, the robot was coded to move vertically only in the column containing the home
location and horizontally only in the row from which it would gain access to its target
bin. This greatly simplified the movement algorithm, making it easier to read and
understand if changes were needed, as well as faster to upload to the RCX. It also
required the fewest switches between chasses, saving wear on the lifting motor and
improving travel time.
        The use of #define statements also contributed to the ease of modification of the
program. All important values, such as the threshold for the light sensor and the power
settings of the motors were defined at the beginning of the program. To change these
values only one number at the beginning of the program had to be edited rather than
searching through the entire code to find each instance where the number had been used.
        Our C program was also simplified by the mechanical design of our robot, which
was one reason this design had been chosen. Since the robot never needed to turn and
was mechanically forced to move in a straight line, these tasks need not be coded. While
other teams had to code complicated correction algorithms to guide their robot in a
straight line, ours had already been mechanically designed to do so. This allowed our
algorithm to be about as simple as it could possibly be. The robot moved to the home
location, then moved to each bin, transmitted the data and returned to home, performing
each action as many times as it had been instructed to do so.
        The robot used a technique known as dead reckoning to maneuver around the
factory floor. This means that rather than tracking an absolute position, such as with the
use of GPS, the robot kept track of how far and in what direction it had moved from a
starting location. Optical odometers were mounted on both sets of drive wheels to
measure the distance traveled by the robot along the x and y axes. After each movement
the robot would update its position relative to the starting location and store that position
in memory.
        The robot determined where it was to move from an array of bin x-coordinates
ordered in the sequence in which the bins were to be visited along with a similar array of
y-coordinates. These arrays, as well as the force constant, the number of bins, the home
location and the number of times each bin needed to
be visited were read in the form of #define
statements from a header file created by the Fortran
program. The C program did not perform error-
trapping on these values because it was deemed
unnecessary. The Fortran program would already
have ensured that the values were reasonable and
had been tested to guarantee that the output would
be correct and usable. Throughout the execution of
the program, the RCX™ Screen displayed “Lucky.”
(Picture 10)                                                      Picture 10

Results and Discussion-

        After all of the time and testing that we had put into our robot, we were very
confident that our robot would perform well in all areas. Since we had attended the
office hours session where we had an opportunity to test that our robot was transmitting
properly, we were sure that our robot was going to transmit to the bins properly. We had
tested our programs time and time again, and each time our programs proved to us that
they could handle any plausible values. All in all, we think that it is safe to assume that
we tested both our Fortran and C programs with enough different numbers to simulate
what the robot might face in its demo. The lifting times were accurate, as well as the
measure of the robot’s velocity. The movement map was flawless and the C program
directed the robot exactly as the map predicted. The only fear that any of us had before
the demo was whether or not Lucky was going to go straight.
         Going straight is something that had been on all of our minds from the start of the
semester. Especially once we switched to the two-chassis system; it seemed that the only
variable was whether or not we could go straight in either direction. The weekend before
the demo, the robot had been acting a little strange. It was going perfectly straight since
we had switched to the two-chassis system, but then it planted a seed of doubt into our
minds by slightly curving to the left. We finally got Lucky to go straight by twisting the
North/South chassis in the direction opposite the way it was curving. This didn’t seem to
be a permanent fix, but we figured we should leave it alone.
         At the time of the demo, we were sure of everything except that slight curve that
Lucky had shown us the weekend before. Fortunately for us, Lucky came through in a big
way. In the demo, we calculated a home location of (4,6). This was a bit of a relief
because it meant that Lucky wouldn’t have to go straight for too long in order to make it
home. We were given the maximum of four bin locations; (5,3), (2,7), (3,5), (3,5). Our
loiter time was 15 seconds, a time so high that our movement map predicted that our
average velocity would fall below the minimum of .3 ft / s. Lucky successfully went to
home on the first try. She then loitered the correct amount of time and headed for the
first bin location we calculated that it should go to, (5,3). Lucky pulled into the bin,
transmitted, and then returned home to loiter again without incident. We repeated this
bin once more, again with success. We then traveled to (2,7) successfully three times,
and then (3,5) twice successfully. Finally, we needed to travel to (3,5) once more. Lucky
returned home again and was finished with all of her retrievals. Lucky earned us 90 out
of a possible 100 points. Although we do not have the exact values of the points we
missed, we do know the categories in which we were not quite perfect. We missed points
in the following areas: Alignment with the RCX at the bin, repositioning at home, and
estimate of time (both total and round trip per bin). We also did not transmit properly at
one of the bins, but Lucky only needed to transmit 4 times to earn full points, which she
accomplished. Lucky did not have as much trouble going straight as we thought it might,
although we did need to adjust it a couple of times to make certain we didn’t go out of
         There are quite a few factors that went into Lucky’s success. Probably the most
significant factor in its performance is the mechanical design that went into it. The two-
chassis design totally eliminates any error that may come from turning, a source of error
that was most detrimental to us in earlier demos. This design allowed us to move almost
perfectly straight in either a horizontal or vertical direction. This ensured that our robot
would not fail by going out of bounds, a fear that we had from the start. The light sensor
odometer that we used was precise enough to give us accurate, reproducible distances.
The lifting mechanism was durable enough to lift the robot in the exact same fashion time
after time, and powerful enough to get the wheels not being used all the way off the
ground. The wheels we used did not slip on paper, thus keeping our light sensor
odometer accurate. As far as our programs go, the Fortran program’s simplicity was its
best attribute, it did not produce any errors or false values because it was simple enough
to operate predictably. The C program acted much in the same way; it led Lucky from
(0,0) to home in the X direction first, then the Y direction, only changing directions once.
It would then lead Lucky in the Y direction first to the bin location, eliminating
extraneous changing of direction. She always returned to home in the same way that she
came, effectively eliminating any curve that the robot might have had on its way to the
bin location. The C program also relied exclusively on functions for its movement,
loitering, change of direction, and transmission. This means that Lucky will do exactly
the same thing for each individual movement, making her highly accurate and extremely
predictable. Our design had come through many stages, and the final product was one
that was able to perform at a very high level.

Engineering Economics-

       The estimated production cost of a single robot is $165,000. This includes one
RCX at $85,000, three motors at $15,000 each, two light sensors at $10,000 each,
$10,000 in miscellaneous structural parts, and $5,000 for assembly. Our design did not
use any touch sensors, so this was not a cost we needed to consider. The following table
(Table 1, Chart 1) breaks down the cost of a robot:

       Table 1
      Part                                Quantity         Price Each     Subtotals
      RCX                                 1                $85,000        $85,000
      Motor                               3                $15,000        $45,000
      Light Sensor                        2                $10,000        $20,000
      Misc. parts (total)                 -                $10,000        $10,000
      Assembly                            -                $5,000         $5,000
                                                           Total          $165,000

       Chart 1

                         Distribution of Spending (per robot)

                                     6%     3%



                   RCX      Motors    Light sensors   Misc. Parts   Assembly
        To determine the number of robots Whirlpool, Inc. would have to produce in
order to break even, we determined when the total selling price of the robots equaled the
total production cost plus the development cost. This is the equation:

Selling Price × # of Robots = Production Cost × # of Robots + Development Cost (1)

       The development cost was determined by multiplying the total number of man
hours spent on the project by $17,000. This table (Table 2) shows our estimate of the
number of man hours we spent in development:

Table 2
                   Purpose                     # Team          Hours spent     Subtotal
                                              members                         man hours
Subtask 1 robot construction and programming 4                 12             48
Subtask 1 presentation                       3                 3              9
Subtask    2     robot    modifications  and 4                 3              12
Subtask 2 presentation                       4                 3              12

Complete robot redesign and construction          1            9              9
Subtask 3 robot programming and testing           4            16             64
Subtask 3 presentation                            4            3              12
Brick OS meeting                                  1            1              1
Subtask 4 robot programming and testing           4            5              20
Subtask 4 presentation                            2            3              6
Complete robot redesign and construction          1            16             16
Final robot programming and testing               4            18             72
Independent programming                           1            2              2
Transmission and distance testing at office 2                  3              6
Preparation for final presentation          3                  2              6
Final presentation                          4                  3              12
                                                               Total          307

       Development cost = (307) × ($17,000) = $5,219,000

Substituting our costs into Equation (1) to determine the number of robots, we get:

($250,000) × # of Robots = ($165,000) × # of Robots + ($5,219,000)
($250,000 - $165,000) × # of Robots = ($5,219,000)
($85,000) × # of Robots = ($5,219,000)
# of Robots ≈ 62
       There are many things to consider when comparing a robotic delivery system to a
standard forklift. Each system offers its own advantages and disadvantages. First, lets
consider the advantages of a robotic system. With a robotic system, it would not be
necessary to pay forklift operators which can cost a significant amount:

Cost to operate a forklift for a year:
2 operators/hr × 24 hrs/day × 349 days/yr × $18/hr = $301,536 per year
Cost of operating a robot per year:

        These prices exclude both maintenance and fuel, but these prices would be similar
for both the robot and forklift making them irrelevant when comparing the costs. If the
company only wanted to break even on the development by producing 62 units, then the
$301,536 difference in cost per year would become a nearly $19 million difference.
        However, an automated retrieval system also has disadvantages to the forklift
system. For instance, both systems require similar maintenance costs, but a forklift
mechanic is not a difficult position to fill. Technicians specific to our robot design would
have to be trained and certified.        Also, to break even, Whirlpool would have to
implement 62 robots. Assuming that one robot can do the work of one forklift, which
requires 3 shifts of 2 workers per day, this means that at least 372 loyal Whirlpool
employees would lose their jobs. While this might seem like an insignificant number, it
is possible that 372 families would be facing welfare. A forklift system involves human
judgment as well. While this can be both an advantage and a disadvantage, in this
instance, we mention it as an advantage. For example, if a robot is sent to a location to
pick up a washing machine, and for some reason there is a dryer in that location, the
robot will return with the dryer. In the case of a man operating a forklift, he can make a
decision as to whether his boss actually wanted a dryer, or if the dryer was simply in the
wrong location.
        In our opinion the advantages of an automated system far outweigh their negative
attributes. First and foremost is the financial perspective. Assuming that operation and
maintenance costs are equal for the forklift and the robot, there is no cost for operating
the robot after the initial purchase cost. Since the bottom line is often almighty in the
business world, this alone may be enough to tip the scales in favor of a robotic system.
Fatigue is also a very important issue. Simply stated, a robot never gets tired. Forklift
operators may become careless in the later stages of their shifts, which can lead to costly
accidents. A robot will operate exactly the same way as the day it was powered up for
every day that it exists, this also means it doesn’t need to be trained. Also, with a robotic
system, executives know the exact price that they are going to have to pay per unit for as
long as that unit is in operation. With workers working for hourly wages, a company has
to deal with inflation affecting wages, workers demanding benefits, and lawsuits due to
injury. With an automated system, the location and status of each individual robot can be
monitored, whereas with conventional system, each unit is basically independent and
must be monitored by the operator.
Conclusion & Recommendations-

        We feel that the overall project centered on the goal of minimizing both the places
error could occur and the chance of it occurring. The design of the robot, as well as our
programs, was done with this goal in mind. We eliminated the error of turning by
building a robot with two drive chasses. In order to minimize the error in distance
traveled, we determined our distances by rotation of the wheels rather than time the
wheels ran. Our programs did not involve many complex commands and made good use
of functions to simplify the programming of the movement and make them very user
friendly. Our results of 90/100 points show that these methods were highly successful.
        If we were to do this project again, there are a couple of ways in which we would
further modify Lucky III to minimize error. Of the points we lost, most were due to the
inability to consistently predict the time Lucky would take for movement to a bin. If we
could have either increased the speed of the motors or the radius of the drive wheels, the
speed would have been faster and possibly more consistent. As it was, Lucky III moved
relatively slowly and not at a constant rate all of the time. Also, the Lucky’s
programming could have been slightly altered to compensate for her slight coasting after
motion (despite braking). Because of these minimal errors in distance it was required
that we adjust Lucky’s location when she returned home on several occasions.
e on several occasions.