Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Automated Warehouse Retrieval

1,420 views

Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

Automated Warehouse Retrieval

  1. 1. RFID Controlled Navigation Progress Report 2 Senior Design 2005-2006 D.L. Molineu Jeremy Podany Jeff Rongish Tyler Tallman April 18, 2006
  2. 2. 1 Introduction...................................................................................................................................3 2 Project Overview..........................................................................................................................3 2.1 Web Interface.....................................................................................................................4 2.2 Navigation .........................................................................................................................5 2.3 Communication..................................................................................................................5 3 Design Implementation.................................................................................................................6 3.1 Hardware Components...........................................................................................................6 3.1.1 DC Motors......................................................................................................................6 3.1.2 Battery.............................................................................................................................7 3.1.3 Photo Sensors..................................................................................................................8 3.1.4 Controllers......................................................................................................................8 3.1.5 RFID...............................................................................................................................9 3.2 Overall sizes and dimensions.................................................................................................9 3.3 Assumptions and Limitations..............................................................................................11 4. Algorithms and Software Descriptions......................................................................................12 4.1 Basic Navigation..................................................................................................................12 4.1.1 Handy Board Driving....................................................................................................12 4.1.2 Server/Ebox Interrupts..................................................................................................13 4.2 Path Finding Algorithm.......................................................................................................13 4.3 Collision Avoidance/Traffic Control...................................................................................14 5. Challenges Faced.......................................................................................................................14 6. The Big Picture..........................................................................................................................15 6.1 Where Our Project Fits In....................................................................................................15 6.2 Future Improvements on Our Project..................................................................................16 2
  3. 3. 1 Introduction Robotics has been playing an ever expanding role in many aspects of human life. They can provide comfort, security, and services that would otherwise not be viable or safe for people. Robotic technology can also help industry be more efficient and provide customers with higher quality/lower cost products and services. Historically robots have been primarily used in industry for manufacturing. In the automotive industry, as well as many other industrial manufacturing sectors, robotic technology has been in use for decades. It is commonly used to perform tasks that are too mundane or hazardous for humans. This technology is most easily implemented for tasks that are very sequential and methodic. That is why it fits so well in manufacturing; typically the same sets of procedures are performed on each product in an assembly line. But in manufacturing, which uses the majority of robotics, which has been changing recently. Robotics is becoming increasingly important is the area of automated warehouse systems. Automated storage and retrieval systems or ASRS range in size from space saving automated file cabinets to very large automated fork lift systems. In these systems, an operator merely enters a command referencing the item to be retrieve or the operator enters an empty location to store a new item and a machine does all the work from there. Our application will be smaller and focus more on the complete automation of the warehouse. 2 Project Overview It has come to be that most of progress in robotics in the past 30 years has been confined to the industry sector. The populous has watched these advances in robotics from a distance, and has dreamed of the day when they would be freed from the repetitive, machine-like demands of 3
  4. 4. an increasingly complex society. They have bought robotic toys and enjoyed automatic doors, but they still wait for relief from everyday burdens and hassles. Our project is an attempt to bridge that gap to allow machines to serve the everyday Joe. This system has increased relevance in the day of phone/mail order E-commerce. Nearly the whole process of shopping could be automated. This would allow companies to cut down on labor costs in the long term as well as improve the speed and convenience for their customers’ orders. Some stores such as Circuit City already have a non-automated version of this system that allows a customer to purchase an item online, prepay, then pickup at the customer service desk. This system does save some time, but it still requires employees to gather and process the order. Only a small fraction of their customer’s use this system because the time savings are minimal and often times customers are not sure what they want or need and sometimes they want to do other leisure shopping while at the store. We feel our system would be a better fit in markets such as grocery stores where people generally have a good idea of what they will be purchasing beforehand, saving them much time walking around the store looking for all the items on their lists, and they could avoid long checkout lines. Because of the advancement in the industry the basic set of technologies are in place. The limitation in this market is not the lack in base technology, but the ability to offer the advancement in a cost effective manor. There are no financially successful systems on the scale of our project, and a large demand is all but guaranteed if an efficient and affordable solution could be provided. 2.1 Web Interface This project will require that we set up a web based store to allow users to purchase products for our robot to retrieve. We have set up a web page that uses Perl based CGI scripts to 4
  5. 5. total the user’s items, and communicate this order via sockets to our warehouse backend. The warehouse backend is essentially a sever for our warehouse retrieval robots. It receives the information from the CGI script, and assigns the order to a robot in the warehouse for retrieval. Our web interface can be seen at http://cse.unl.edu/~jrongish/489/index.html. 2.2 Navigation A warehouse is large, but organized. We plan to utilize the orthogonal nature of warehouse environments to simplify the problem of autonomous navigation. We will place RFID tags strategically along the floor of the warehouse, and reference these tags to their locations on a main server. The tags will be placed along a high contrast line. Our robots are designed to follow this high contrast line on the floor at all times. This line is designed to reduce the number of RFID tags needed to specify location information to the robot. By only allowing the robot to follow lines, we put bounds on where the robots can go, reducing the number of tags needed on the floor, and unpredictable motions of the robot. The robots will be preprogrammed to follow a set path of tags by a central server, and will do so by driving along the lines and reading RFID tags along the way. Decisions will be made at intersections by the robots, which contain a full map of the warehouse in their memory. 2.3 Communication We must be able to track the robot locations within the warehouse, and be able to download paths to them from the server. We will utilize an 801.11 network for this task. The main server will know, by 802.11 communications, where each robot is in the warehouse, and be able to communication with these robots. The server can then control traffic, and prevent collisions by simple commands to the robots such as stop( ), continue( ), and return( ). 5
  6. 6. 3 Design Implementation 3.1 Hardware Components 3.1.1 DC Motors The most crucial part of our robots is the DC motors used for movement. Calculations as to the size and power of the motors necessary are done here. The main parameters in this decision are size and weight of the finished prototype. As we increase the size to hold more components and cargo it comes at the expense of additional mass. More mass will eventually equal greater motor maintenance and slower machine speeds. Assuming current prototype design our current weight is approximately 20lbs without load and 45lbs with a full load. The mass of our robot became a design consideration because of its effect on our drive system. Using our knowledge that acceleration = force / mass. And the net force is applied force fa minus the frictional force ff we get the a = (fa - ff )/M. fa is a result of the toque the motors apply divided by the radius of the wheels. ff is also a function of the wheels and the mass. If we assume the force of friction and mass are linearly coordinated then we can rewrite the equation. a= ( fa - kf * N)/M. Where kf is the coefficient of dynamic friction. The mass = weight / acceleration due to gravity Simplifies to: a = fa/M - (kf * g) Therefore a system requirement is for fa/M > kf * g kf is about 0.015 for a car tire we are uncertain the friction of our tires but assumes they will be worse. So we will prepare for a friction coefficient of 0.05. 6
  7. 7. a= Torque /(M*tire radius) - kf *g Using known values we then have T/(45/32*3/12)=.05 * 32 Resulting In T > 0.5625 lbs-feet = 108 oz-inches Which is the torque necessary to move our robot. If we want an acceleration of 1 ft/sec squared we need a= Torque /(M*tire radius) - kf *g Torque = (a + kf *g)*(M*tire radius) T > 0.914059286 lbs - ft of torque. 175 oz-inches of total torque. The motors we purchased have a torque of 300 oz-inches each, at 120 RPM. We have geared down the motors to 2:1 This gives us a total of 1200 oz-inches of available torque. Thus we have ample power to accommodate additional load and friction. Because of this additional torque an acceleration algorithm had to be implemented to reduce the stress to the drive gears and provide a smoother start for the robot overall. Pulse width modulation is used by gradually increasing the duty cycle to the motors until it reaches the desired power level. When the robot is going at “full speed” it will be at approximately 60% duty cycle. 3.1.2 Battery The second physical components is the Battery we are using a 12V motorcycle battery to provide power for our device because of its ability to provide high current and the economic 7
  8. 8. advantage of a lead acid battery. This battery weighs 12 lbs, thus it will be the single heaviest component on the robot. 3.1.3 Photo Sensors We are using two photo sensors mounted on the front of our robot. They are spaced two inches apart and look directly downward. The photo sensors return an analog signal to the Handy Board, which the Handy Board converts to a digital value between 0 and 255: 0 begin white, and 255 being complete darkness. Each photo sensor is unique and needs to be calibrated with the handy board before it can be used. The sensors we are now using read value from 20-80 which is sufficient for us because our line is high contrast and we get a good median value with this range. 3.1.4 Controllers There will be two electronic controllers on each robot. These will be the Ebox and the Handy Board. The Ebox will likely be replaced by a laptop because of issues with the serial port. These systems provide the brains and crucial logic for the project. The weight and dimensions of these can be found in Table 1. The Handy Board is used to control both the motors and the light sensors. The motors are controlled by two control signals. A 5V digital signal is used to specify the direction of travel for the motors. 0V means backward, and 5V means forwards. The second signal is a 5V pulse width modulated signal used to control speed. The Handy Board outputs a 9.6 volt, 2 KHz PWM signal; which we run through a 5V regulator. The regulator has no effect on the signal, besides the reduction in voltage. The Handy Board also reads analog input from the photo sensors. 8
  9. 9. The Ebox, or Laptop is used to interface with the RFID reader and Handy Board, both serially. It will read RFID information and relay directions to the Handy Board, either to stop, continue or return home. As mentioned before the server is in constant communication with every robot. The Ebox controls communication with the server, and relays RFID tag information to the server, and direction information from the server to the Handy Board. 3.1.5 RFID We are using a SkyTek RFID reader with optional EA1 antenna. The antenna allows us to read our TI 13.45 MHz tags from five inches away. Our RFID reader is mounted 3 inches off the ground, and using geometry we have found that a tag spacing of 12 inches on center gives us a good resolution for reading tags. The tags are 1.75” X 2.5”. These are the largest tags we could find from TI. The size gives us a longer read distance, and a better chance of actually reading the tag while the robot is moving. 3.2 Overall sizes and dimensions The base of the robot is approximately 20 inches wide and 24 inches long with rounded corners and is slightly narrower in the front. The Ebox, Handy Board, and battery sit on top of the base. The hardware placed on the base will take up most of the area, and add around five inches of height to the robot’s base. Another platform identical to the base piece is placed on top of the hardware; the items will be placed on a basket attached to this piece. The basket will be approximately the same dimensions as the base piece and about a foot deep. Light sensors are attached to the front end of the robot hovering about half an inch above the ground. This setup allows them to accurately follow a line on the floor of the warehouse. The light sensors are two inches apart, so that they are close enough that they can provide fine 9
  10. 10. tuned feedback to keep the path strait, but still far enough that both sensors will not leave the line before the trajectory can be corrected. Two fixed 7 inch lawnmower wheels attached to DC motors are fixed to the back end of the robot base. These two wheels are six inches in diameter. The two DC motors attached to the back wheels will drive the robot and allow the robot to turn so that it can navigate the aisles of the warehouse. Two caster wheels are attached to the front of the robot; the caster wheels are free to rotate to allow for easier turning. Due to the prototype nature of this machine it will be smaller than a production model. The prototype can be seen in Figure 1. A summary of the parts, their sizes and weights can be seen in Table 1. Figure 1: Top View of Prototype Robot 10
  11. 11. Component Size (inches) Weight (lbs) Ebox 5x3x4 1 *Laptop 12 x 1 x 8 5 Handy Board 4x4x2 1 Motors 2x2x4 2 Battery 10 x 3.5 x 4.5 12 RFID Reader 4X4X2 0.25 Plastic Frame 20 X 20 12 Cargo Hold (Full) 20 x 20 12 Total Weight: 40.25 *Either the Ebox OR laptop will be used in the final produce Table 1: Weights and Dimensions of Robots 3.3 Assumptions and Limitations For the final design of the robot, we would like to have the design work for an arbitrary number of robots within the warehouse. However, for our project, we are limiting the design to one production robot. From this basis the extension to a multiple robot implementation would be fairly straightforward. We have designed our system from the beginning with the idea of multiple units functioning in unison in mind. The software behind our system contains the framework for multiple robots. Once additions units are built the systems would need to be tested, but the additional programming time should be minimal. The original concept of the robot called for a robotic arm that would take the items from the shelf and place them in the basket on the robot. Due to time constraints and the level of difficulty for implementing such a complicated mechanical device on our robot, we decided to assume that the problem of getting the item from the shelf to the robot is either already solved, or will be implemented by another development team. The final design that we are working on is a proof of concept, focusing on RFID navigation, for the finished complete design. The robot will only need to find a path from its current location to the designated location in the warehouse. The robot needs to be able to complete the route without colliding with anything either walls, shelves, or another robot. For 11
  12. 12. the proof of concept we decided that if the robot is able to successfully navigate the warehouse floor and get to where the desired product is located, that would show that the design would work in its entirety. 4. Algorithms and Software Descriptions 4.1 Basic Navigation In this section we will divide navigation into physical motion, and intelligent choice making. The physical driving is done by handy board and motors, with interrupts from the server via Ebox. 4.1.1 Handy Board Driving The Handy Board is linked to the motors as described in section 3.13. The program that is implemented on the Handy Board can be summarized in the flow chart in Figure 2. Check for Interrupts from Ebox No Follow The Interrupts Line Found? Yes Execute Interrupt Sequences Figure 2: Handy Board Control We can see from the figure that the Handy Board is essentially polling for input, otherwise it follows the line on the floor. The input will consist of stop( ), continue( ), 12
  13. 13. turn(direction) and return( ) bytes, that will have the robot stop, resume from stop, turn at an intersection, and return home respectively. These commands will be passed from the Ebox to the Handy Board serially via unique byte codes for each function. 4.1.2 Server/Ebox Interrupts The Ebox is set up to transmit location data to the server, and receive driving instructions from it. The Ebox transmits its current RFID tag location to the server everytime it finds a new tag. The sever then checks its global map and decides what the robot should do. If the robot is fine, no intervention is required. If the robot is on course for collision or needs to be recalled, the server can stop, or recall the robot with simple commands. 4.2 Path Finding Algorithm Each robot is assigned a complete path to follow by the server before the robot is sent to gather its payload. This path is computed by the server using a weighted breadth first search. The server generates the weights for each tag in the warehouse by calculating when an already deployed robot may drive over that tag. The server then assigns a Gaussian time distribution to the tag, and adds it to the running total for the tag. This allows the server to “guess” when a tag is most probably to be occupied and then plan a path for the new robot to avoid crossing these tags at the dangerous times. Essentially the server looks at the probablility that a tag will be occupied at a certain time when the new robot would want to cross a certain tag. Doing this, along with a BFS, the server can help avoid traffic jams and collisions in the warehouse. 13
  14. 14. 4.3 Collision Avoidance/Traffic Control The server will employ a secondary means of collision avoidance on top of the weighted path algorithm described above. Each robot will “check out” the tag it is currently at, along with a few in front and behind it. This is transparent to the robots, but is implemented by the server. The server can then stop traffic jams before they start, by simply not allowing robots to get within close proximity of each other. As mentioned before, the robots are always transmitting location data to the server, and receiving driving directions from the server. This allows the robots to have no idea where other robots in the warehouse are, but still avoid collisions by listening to the server. We decided to do this passive form of traffic control to reduce the load on the main server, and enable the robots to be semi-autonomous. 5. Challenges Faced This project has provided many challenges to us. We are still struggling to get the serial ports on the Ebox to work. We found that the internal memory of the Ebox was too small, so we attached a hard drive, but it crashed. We are in the process of installing a new hard drive with a different version of Linux on it. We also burned out 2 motors. The first was by accident; we connected a voltage to an output pin and burned out the controller board. The second motor burned out by applying too much voltage to the 12 volt inputs; this also burned out the controller board. The RFID reader gave us a fair share of headaches. It has a very slow read time, forcing us to time out our program when we read a tag. We did not acknowledge this fact initially and were receiving only partial data. We have since corrected the problem and the RFID reader works fine. 14
  15. 15. 6. The Big Picture 6.1 Where Our Project Fits In The entire scope of the idea initially started with the user placing an order online. Our server would receive this order and issue commands to several warehouse robots which would then traverse a path to pick up items from the shelves in the warehouse and return them to the base station. This assembled order would then either be taken to a pick-up area where the consumer could retrieve their order, or the order would be packed and shipped to the consumer’s residence. So far, our project only goes as far as having the robot retrieve the items from the warehouse and returning them to the base station in that warehouse. In order to complete the ordering process, we would have to decide if it would be more cost effective to use an existing shipping company’s services or to ship the products ourselves. Another issue that would have to be resolved is the idea of pick-up locations. If the store is nationwide, it would not be convenient to only have one location where the items can be picked up. Therefore, we would need to establish warehouses and pick-up centers in convenient locations for the customers. Also, the program that receives the orders would have to be able to determine where the most convenient location for the item to be picked up from would be. Finally, the main idea for this project was to base it around a grocery store. So, there might be a need to have a system that could be used for scheduling orders. The scheduling system would allow for orders to be placed and have them delivered or shipped at a later date. This system would also allow the customer to place a repeating order to get the same items once a month or on some sort of repeating schedule. 15
  16. 16. 6.2 Future Improvements on Our Project As our project is currently, the robots do not “think” for themselves. They are simply given a set of instructions from the server, and they follow those instructions to reach their destination and return to the base station. We would like for the robots to be able to determine a path for themselves. The server would only be responsible for telling the robots where the other robots in the warehouse are, and it would tell the robots the list of items that the robots need to acquire before returning to the base station. We had originally planned to have multiple robots traveling through the warehouse, but due to time and budget constraints, we were unable to implement multiple robots. When more robots are added to the warehouse, it would help to reduce the load on a single robot, and the robots would be able to work together to complete the orders faster. The robot that we have designed is able to traverse the warehouse floor and find a location in the warehouse that a certain item will be located at, but we currently have no way of getting the product from the shelf to the robot. We would like to implement either some sort of grabbing mechanism or a vending machine like system to knock the items off of the shelves. The original plan was to have a grabbing mechanism on top of the robot, but due to time and complexity issues we were unable to implement the grabbing mechanism. Also, due to complications with the Ebox we were unable to implement wireless communication between the robot and the base station. The idea of having a wire connected to the robot as it traverses the warehouse is very unrealistic and this problem would be dealt with in the future. 16

×