The TTI / ASRSI project

Some Thoughts on the TTI / ASRS (Automated Storage and Retrieval Systems) Project

The Slate River Systems Inc. | Warehouse Solutions | SRSI

 https://www.redblobgames.com/pathfinding/a-star/introduction.html

 

Hi kk.org, I'm writing this as a wish that it can help make the new project ASRS progress smoothly, also as a way to practice my English. Now I decide to exclusively send the article to you, with the hope that this could be helpful to the hardware side.

 

I'm writing this also because I feel it's quite risky on the hardware side of the new project -- New Kind of Robots, Motion, Calculation, Accuracy; Building Steel Structure, Rails, Elevators; And if a robot gets stuck, it won't be on the ground, we need to lift human up to the air to handle problems... -- Especially at the very beginning when I didn't know/sure there are ways (laser, holes on rails) to help accurately determine the position of a robot, I felt the risk even deeper.

 

I'm writing this also because I feel it's quite risky on the hardware side of the new project -- New Kind of Robots, Motion, Calculation, Accuracy; Building Steel Frame Structure, Rails, Elevators, etc.; and if a robot gets stuck, it won't be on the ground, we need to lift human up to the air to handle the problem -- Especially at the very beginning when I didn't know/sure there are ways (laser, holes on rails) to help accurately determine the position of a robot, I felt the risk even deeper.

 

　　1. How to present multi-layer storage space on a web page?

 

As what is shown in the video above, the physical space of the ASRS system is a steel frame structure which has multi-layers. According to the design, we may consider each layer somewhat resembles the ground we use in FM, so for each layer we can create a distinct map in FM to present it.

 

I agree with this methodology, as by now we are not a powerful company, it's better that we reuse what we already have and do the modification needed to fulfill the requirements of the new project instead of building everything up from the ground again. So we won't do it in a 3D way, no "Metaverse" for the moment. : )

 

In addition to the presentation of each storage layer using the existing grid map technology, we need to do the user interface and software/physical control of the elevators that lift robots and goods among different storage layers. 

 

　　 2. Still use Grid (Integer XY Coordinate System)?

 

As what we have done for Allen (and Nepa), Grid is suitable for QR code based ground. Grid is an integer location (x, y) based coordinate system that use A* pathfinding algorithm to find the shortest path between point A and point B in the grid. The question is, can we still use this for the ASRS project which has no QR codes in the air for robots to scan for the (x, y) info and tell RCS where the robot is?

 

We will still use Grid System and A* Pathfinding to direct robots where to go, but need to do some modification to the protocol for the communication between RCS and the robots. That is, although robots have no QR codes to tell the location (x, y) they are, but they can tell RCS how far in physical length they have moved, and RCS will convert the physical length into integer location (x, y) in the grid, then do the grid pathfinding. Also, conversely, instead of telling a robot which (x, y) to move to, RCS tells the robot how far in physical length it should move.

 

Be more detailed, in FM's MapBuilder when building the map, User will be required to set the physical length between every two Keep points. (e.g. User clicks on Keep point A, and then can config the physical length between point A and each of its four adjacent Keep points in its surrounding directions).

 

And between Keep point A and its adjacent Keep point B (or C/D/E), there are a specific number of Path points, then RCS can figure out how many millimeters each Path point represents, by dividing the physical length User sets between A and B with the number of Path points in between. So when Robot tells RCS how far in physical length it has moved from Keep point A, RCS can tell what the integer x coordinate is in the grid by dividing that physical length with that of each path cell.

 

 

--------------------------------

 

Sorry for the interruption of your weekend and thank you very much for reading this far. Hope this can be helpful for your understanding of the whole system. It should be easy to understand the above if I am not too foolish in thinking and bad at writing. And it seems not that risky, right? (At least for the software side it could be ok)

 

I know little about motion control and hardware, I don't even know if there are any fundamental things that I deserve to have a look at. But on the software side, I know something that is really classic and in good writing. If you would like, please go here https://www.redblobgames.com/pathfinding/a-star/introduction.html

 

---------------------------------

 

 

As mentioned earlier, the reason I originally began writing this article is partially because at the time I was not sure that there are ways (laser, holes on rails) to help diminish the deviation of mileage calculation and determine the position of a robot with accuracy, and thus felt the risk was mainly on the hardware side.

 

What follows is my original thoughts/writing before I became sure about the laser positioning thing (Only until the latest software meeting, I was told laser positioning is rightly the tool for ASRS). The writing below is outdated, and can be over-complicating your thinking. It's here for completeness only. You may simply ignore it, or focus on the number 3, 4 points only.

 

　　1. Still use Grid System (Integer XY Coordinate System)?

 

As what we have done for Allen (and Nepa), Grid is suitable for the identical cell-sized and QR code based ground. But for the ASRS project, as you can see from the video link blow, the rails may have arbitrary lengths, and so may not be easily divided into identical sized cells.

 

The design is to still use the integer xy coordinate grid system for ASRS, but with some improvements to support new requirements. That is, the map will still have identical-sized cells rendered on the web page, but a cell may correspond to 1 meter in the real world, while another cell with the same rendered size on the web page may correspond to 1.7 or 2 meters, etc.

 

(FM's MapBuilder can let User set the corresponding physical length for a specific cell, but the cell will render with the same size on the web page as other cells). As you might wonder, can FM render a proportionally scaled cell on the map? This is technically possible but hard for the frontend to implement (this is the reason I haven't mentioned proportional map rendering to other people yet, with also the consideration that it's not the key point, the key point is whether the hardware side can accept the XY Grid System with varied physical length info for each (x, y) location, but with no QR codes physically for robots to scan for integer xy info).

 

　　2. How do robots know their xy location without scanning QR codes?

 

RCS has decided to use the Grid System (which is currently used for QR code floor) for the ASRS Project with some modification to support cells with varied sizes in the real world. 

 

I know little about hardware and motion control, but with respect to the hardship we endured in the Allen project, I think this one of the most risky things for the hardware team. Scanning QR codes is somewhat easier and accurate, but figuring out xy coordinate from speed or mileage should be extremely hard, especially when the robot is moving way more faster on the rails, it seems impossible to be accurate. Because the deviation/inaccuracy of the mileage calculation by robots will constantly accumulate along the way.

 

Yet to design the new Grid Protocol to work with the hardware motion. I think the new protocol will kind of tell the robot from location x to location x + 1 you will need to move 1 meter; and from location x + 1 to x + 2, you will need to move 1.7 meters, etc. For short distance, it seems this may work; but as the robot continues to run further, the inaccuracy may accumulate to be larger and larger along the way.

 

　　3. How to reduce the risk and progress smoothly?

 

To test the new robot motion control and positioning protocol, before building up the steel scaffolding, how about we get rid of the QR codes on the ground, and see if robots can do the motion and other things accurately and stably or not on the ground?

 

This is the simple way I can think of to test the design/protocol that we will make to direct robot movements without QR codes. Before the manufacturing of ASRS robots which run on rails, we may firstly modify the existing robots to run on the ground with no QR codes to scan against, and see whether we can solve the hard and key points or not.

     

Hope this can lower the risk level of the new project.

 

　　4. Can use laser to help accurately determine the location of robots?

 

As for accurate positioning, can we use laser detection? I think laser is more sensitive and quick to detect than QR codes, the problem is, can we store information (x, y, or mileage, etc.) in laser?

 

If not, then I think the hardware side should be way more risky, as the software side is still based on A* grid pathfinding, but the hardware team needs to produce new kind of robots, the steel frame structure robots run on, elevators to lift robots, and use easily inaccurate mileage calculation to locate itself instead of QR codes.