Group AI for stacking robots on Oracle SQL XE

    imageIt is good to think about robots and artificial intelligence after hours in front of a home computer and a cup of coffee. And it’s another matter when you are faced with the need to develop high-level software for a robotic warehouse in a short time. And while practical experience in this subject area is completely absent, but there is a rich theoretical. You say that a smart person should not be in a similar situation. Well, maybe you're right, but life is a very complicated and non-linear thing. Therefore, when my friend, the director of the company, producing iron for robotic warehouses, approached me with a complaint that the previous developer of high-level software threw them (took an advance payment, fed them breakfasts for a long time, and then completely disappeared in an unknown direction) - I promised to think that here you can do it.

    Robotic warehouse

    A few words about iron (ASK - an automated warehouse complex), for which it was necessary to develop high-level software. Perhaps some of the readers will not agree with the statement that the device in the photo above is a robot. It looks more like a kind of machine: two rails are installed below and above, on which a robot with a sliding platform moves. Left and right are racks with cells in several levels (up to 12 meters high). The goods are stored in standard inexpensive containers of various sizes. A stacker robot can ride on rails, load a container from a specific cell, and unload a container into a specific cell. Details can be found on the manufacturer's website .


    As I said, I had no practical experience in either artificial intelligence or robot control. However, there was a lot of experience in DBMS and in various visualization systems. The low-level software for the robots themselves was written in C #. My team had people with a lot of experience in C #. Therefore, it was logical to use C # to develop a module that will communicate with robots.
    The previous unfortunate developer used an Oracle SQL server as a DBMS. We had great experience working with this server, so we decided to leave this particular server for the DBMS.
    However, I was overcome with doubts - will my team cope? Therefore, we decided to try to make a small piece first - we called it the stacker server. This server actually had only one command - to move the container from one cell to another. The difficulty was that the cells could be located in different sub-stores, or in ring sub-stores with two robots. The previous developer’s stumbling block was the constant collisions of robots and the inefficiency of the chosen option.

    Stacker server

    The module for interacting with robots was written quite easily. Mindful of my past experience working with any glands, I decided to primarily implement the emulator and smart visualizer of a robotic warehouse. Well, it's not on living robots to debug the algorithm - the number of collisions that they can withstand is strictly limited. Robot manufacturers already had an emulator for one robot, and they kindly provided me with the source code in C #. As for the visualizer, our fellow developers of low-level software for robots had strong doubts that it could even be implemented theoretically. However, after several days of meditation, the form shown below somehow emerged by itself.
    That is, the visualizer shows the ASK as if from above, while the robot’s busyness is distinguished by various animated effects from WPF . Everyone liked the found form of visualization so much that it was decided to use it at all levels, up to the marketing one, when designing commercial offers.

    Favorite triggers from Oracle

    The main logic of the ASK operation is the management of a finite state machine (it seems that we were told this at lectures at the university). There is a set of warehouse conditions, and you need to switch the system between different states depending on a specific set of conditions. And for these purposes, Oracle SQL Server turned out to be an ideal development tool. Triggers from Oracle made it possible to quickly and conveniently program the entire logic of the warehouse. Debugging was very convenient. It turns out that it is incredibly pleasant to work when the domain model is well correlated with the development model.
    There were still doubts about the speed of Oracle - the database size was small, but the number of table modification operations sometimes reached 20 per second. However, Oracle did not fail here, even the free Oracle SQL XE.


    All this idyll lasted until it was the turn to write a module for efficient control of two robots on the same ring path. It seemed something simpler - there is a common resource (rail), there is a rule for its allocation. But how to make a decision - which robot to execute which team and in which direction? After a week of stomping on the spot, I suddenly found that such things as choice of strategy, decision making, optimal path, and the like, firmly entered into our everyday life. And the understanding came that we seriously wandered into the swamp of artificial intelligence, from which we had to get out as quickly as possible. Time was limited. Remembering the institute course (remembering the kind words of his teachers), that in the event of problems with time, developers in artificial intelligence problems resort to a simulation model and a method of exhaustive search, decided to do the same. It may not be quite beautiful, but it will definitely work.

    Decision Visualizer

    However, even simulation of such a simple system with two robots on the same rail turned out to be a very difficult task. The number of diverse behaviors of the system grew, almost exponentially, and, starting from some point, the developer no longer understood the course of simulation. I had to realize one thing, the mention of which I met only with V. Pelevin in his <anti-aircraft codes from Al-Efsbi> : a visualizer of decision-making. That is, because as a result of simulation, the system often made suboptimal decisions, and it was necessary to understand where the error was, and debugging in real time was not an option - everything changed every second, then in the decision-making process (no more than 1 second) the system generated easy to read text file. The graphics in it were drawn with text symbols - again it’s cool, but it allowed the developer to quickly modify the visualizer itself and track and correct errors quite quickly.


    As a result of the incredible stress of the forces of our entire team, we were able to implement high-level software for controlling robots within the specified time. After some thought, I called it “ group artificial intelligence for stacker robots” , because it is it that makes the actions of robots pseudo-conscious, aimed at realizing a given goal. The development of a decision visualizer was a watershed in the entire project. We realized that we can do such systems, and they work. Although there were a number of problems after this (for example, the conceptualization of the interaction of ASK with a specific information system of the Customer with the goal of unification), but these problems were already solved in the usual working order. If it is interesting, I will talk about these points in more detail in the following topics.
    And what else turned out to be interesting - not all of my programmers were able to work precisely on the artificial intelligence module of the system. Despite over 10 years of programming experience. Apparently, the task of imagining yourself not even as a robot, but as a group of robots, is solved only by programmers with a certain mentality. True, those specialists who worked especially intensively on the artificial intelligence module were haunted by nightmares for some time, as if they were stacker robots who could not find their optimal path.


    Despite the fact that the system has been implemented and has been working successfully for more than six months now, I clearly see some of the shortcomings of the created product. First of all, I would like to hire a mathematician and try to make a classic mathematical model of the process of work of stacker robots. However, as I recall from the institute course, not every task from simulation has a solution in the form of mathematical formulas.
    There are also thoughts to do everything on a full-fledged object-oriented approach. Due to time limitations, every now and then I had to break into writing classical procedures and functions.
    There is still an idea to get acquainted with world practical experience in creating such systems. However, nothing was found quickly. Maybe this is the strictest know-how of the developers, or I don’t know the necessary keywords?


    I will not say trivial words about the inevitability of robotization of the entire national economy. I will say it easier. In my opinion, another 10 years will pass, and at least 30% of the existing warehouses around the world will be robotic. For a number of reasons, and not only because of economic feasibility (increased storage density and staff reduction). And I will be pleased to be aware of my small contribution to this process in the direction of ridding a person of routine labor.

    Also popular now: