ARIAC

Our strategy was to handle all possible challenges (including product flipping), while the primary goals were accuracy and robustness. Parts are handled “with respect”, only faulty products are dropped intentionally to the floor. All unnecessary parts that could be needed later are transferred back to the bins.

MoveIt was not used for trajectory planning and control. The routing for the gantry is based on our graph model of possible waypoints within the shop-floor area.  A simple shortest-path algorithm is used to find the optimal route for the gantry. This trajectory is smoothed over time before adding it to the robot controller. As for the arms, the inverse kinematics are calculated by our code. 

The main entity is the high level controller that performs the system control. Serving the orders are basically decomposed into elementary pick and place actions. The next products to serve are chosen by the scheduler that always evaluates the current situation, handles updates and environmental changes reactively. To achieve this, state management is only applied for the actions and the products of shipments/orders. Thus, there is no need to track all parts available to serve the products since the actual state information of the system is provided by the sensory subsystem. (However, there is an exception to this, when the sensors are blacked out. To keep up the continuous operation, the last snapshots of all sensors are used, and the simplest part tracking is implemented to survive the blackout period.)

Parts arriving on the conveyor belt are challenging to cope with: there is a tradeoff between collecting parts from the belt that are not available on bins/shelves, and the overall speed of serving the actual shipments. This tradeoff is handled by the *greedy_factor“. If we are less greedy, then only those parts are picked from the belt that are already seen to be missing. More greadyness equals collecting one (or more) spare parts to prepare for faulty parts or future order updates. A “wish_list” is updated to store wished parts, with the most wanted parts on top. Pick&place operations are preempted when a wanted part is noticed on the belt.

MOs are taken into account as obstacles blocking the whole corridor between shelves. The robot is able to grab parts on shelves from both sides of the self.

Our strategy was to handle all possible challenges (including product flipping), while the primary goals were accuracy and robustness. The system is (hopefully :) ) able to recover from unforeseen situations when something unexpected happens. Parts are handled “with respect”, only faulty products are dropped intentionally to the floor. All unnecessary parts are transferred back to the original bins when they are not needed.

To take advantage of the ROS environment, our architecture tries to be as modular as possible. The two arms are just separate instances (i.e., nodes), and thus the arm controllers use the same code. Similarly, all sensory devices are collected into one class, and perception-based services are offered in a unified way to the controlling node.

The central entity is the high level controller that performs the system control. We used ROS services for synchronous communication and ROS actions for asynchronous information exchange between the nodes. The latter makes it possible to move the arms in parallel, not blocking each other.. Serving the orders are basically decomposed into elementary pick&place actions. The next product to serve is chosen by the scheduler that always evaluates the current situation, handles updates and environmental changes reactively. To achieve this, state management is only applied for the products of shipments/orders. Thus, there is no need to track all parts available to serve the products since the actual state information of the system is provided by the sensory subsystem. (However, there is an exception to this, when the sensors are blacked out. To keep up the continuous operation, the last snapshots of all sensors are used, and the simplest part tracking is implemented to survive the blackout period.)

A major challenge in controlling the robot arms is to provide the arm controllers trajectories that are collision free, including - most importantly - the avoidance of hitting the other arm. The general MoveIt ROS package was tailored and used for our needs. In situations where it is advantageous to move both arms at the same time, one of them is selected as the master, and the primary goal for the secondary (slave) arm is to keep a safe distance from the master during the operation. It is the master who serves the next product, and the slave arm only helps in doing pre-fetch from distant positions, or handling the product flip. We should note, however, that there is no direct communication between the arms. It is up to the high level controller to manage cooperation.

Furthermore, our system uses a laser profiler over the conveyor belt to detect parts coming in. Image processing is used to detect the type and orientation of incoming parts, with a preciseenough time stamp.