Service Robot (Mobipick)
Context
This use-case demonstrates sample tasks of the service robot Mobipick that operates in the context of human-robot collaboration. Mobipick consists of a MiR base, a UR5 arm and a Robotiq gripper attached to the arm. Mobipick uses ROS as its middleware, with its capabilities and actions either implemented in ROS or taken from the ROS ecosystem.
The mobile robot can sense, navigate and manipulate its environment, to pick up and bring objects to specified locations. It can navigate the mapped world autonomously avoiding dynamic obstacles using the laser scanners of its mobile base. Additionally, it is able to classify objects and estimate their 3D poses using a camera attached to the robot’s end effector, to then pick them up and place them at a given location. The objects that the robot can grasp are inspired by a workshop environment, they include multimeters, screwdrivers, relays, power drills and boxes. In addition to the physical robot system, a Gazebo simulation of the robot and demonstration environments exists. Details about the Mobipick robot, its capabilities and the simulation environment can be found in a paper by Lima et al.
The overall goal of this use-case is to let the robot autonomously create plans for achieving its goals and to execute them accordingly. This enables the robot to adapt its behaviour to a given goal and situation.
Planning Problem Description
The robot is supposed carry out manipulation tasks that could help a robot worker. This is shown in two demonstration scenarios. The first example involves collecting a power drill and handing it over to the human worker. In the second example the robot has to collect specified objects, insert them into a box and transport the box onto a target table. The objects are scattered on the tables around the robot, and initially the robot does not know the locations of the objects it needs to collect. To accomplish this goal, the robot first needs to search the tables for the desired objects and box, end the search if it finds one, and depending on the item found, then replans to pick it up and to bring it to the target table.
Modelling in UP
For the Mobipick robot a number for primitive action implementations were already available in the form of ROS actions and services that could easily be interfaced via a robot API written in Python. For those robot capabilities, corresponding UP action representations had to be created. For simplifying this process the Embedded Systems Bridge (ESB) has been implemented in collaboration with our partners from the drones use-case. Additionally, Python functions have been implemented on the robot for calculating the symbolic states of the robot’s state and environment. The ESB also provides functions for creating corresponding fluents for those. Furthermore, the ESB maintains a mapping between actions and fluents in the UP representation and the corresponding Python implementations on the robot side.
The planning problem has been modelled both for classical as well as hierarchical planners. The resulting plans are sequential as the robot currently does not have actions that can be carried out in parallel.
Operation Modes and Integration Aspects
The OneShotPlanning`` operation mode is used for generating plans. As the plans should not contain unnecessary actions we set an OptimalityGuarantee`` to the problem to require the planner to produce optimal plans.
However, in addition to plan generation, the execution of the plans on the robot is crucial. For this, functionalities for dispatching and monitoring plans were implemented in the ESB and used on the Mobipick. The ESB converts the plans into dependencies graphs that are used for dispatching the actions and for checking their preconditions. If an error occurs, re-planning is triggered from the updated state of the robot and its environment.
Lessons Learned
During the implementation the use-case we have learned a couple of key lessons:
Efficient Modelling: When modelling the planning problem it is tempting to use a large number of the domain modelling features that UP is offering. However, this reduces the number of matching planners for the resulting problem kind and this way leads to a high planning time. By limiting the features such that the problem kind was suitable for the planner FastDownward we were able to significantly reduce the planning time.
Optimality required for good robot plans: It turned out that if we were using Fast-Downward in its standard mode the resulting plans often contained unnecessary actions. Executing such non-optimal plans on a mobile service robot looked strange to the user and increased the overall execution time as well the risk of execution failures. Setting an optimality guarantee the OneShotPlanner operation mode resolved this issue with a reasonable increase in planning time.