The manipulation of flexible object is of primary importance in industry 4.0 and in home environments scenarios. Traditionally, this problem has been tackled by developing ad-hoc approaches, that lack of flexibility and portability. We propose an approach in which a flexible object is modelled as an articulated object, or rather, a set of links connect via joints In this paper we present an extended analysis of the framework based on Answer Set Programming (ASP) for the automated manipulation of articulated objects in a robot architecture. In detail, we modeled the same scenario with different grades of precision: a simple model it is used to describe the scenario with an high level of abstraction, while an extended model it used to include more detail and therefore to increase the represented knowledge of such scenario. With respect to the simple reference scenario we analyse the behaviours of our strategy for the action planning module, while, for the extended scenario we introduce the concept of macro action and we then we analyse their performances w.r.t our problem. Our aim is to have an understanding of the performances of these approaches with respect to planning time and execution time as well.1
The manipulation of articulated objects is of primary importance in robotics, and is
one of the most complex robotics tasks [
In this paper we present the analysis of a framework based on Answer Set
Programming (ASP) [
In this section we define the problem addressed, and we present the considered first reference scenario. 2.1
Our goal is to present (i) an overview of the ASP-based architecture for the manipulation of articulated objects in terms of the representation of the desired scenario and the planning strategies developed for the selection of manipulation actions aimed to maximises the reliability of the robot execution, and (ii) give a simple overview on how we modeled macro actions inside our ASP-based architecture.
An articulated object is defined as a pair = (L; J ), where L is the ordered set of its jLj links and J is the ordered set of its jJ j joints. Each link l 2 L is characterised by two parameters, namely a length l and an orientation l. We allow only for a limited number of possible orientations, which induces a finite set of allowed angle orientations for each link. The configuration of an articulated object is modeled as jLj-ple: C ;a = 1a; : : : ; jaLj : (1) 2.2
Simple Model We relay on QR codes to compute and provide to the architecture an overall link pose, which directly maps to an absolute link orientation la. Extended model This scenario it is developed in order to describe with an higher accuracy the robot and its work-space. However, this model does not modify any physical characteristics with respect to the setup introduced in the previous paragraph. Herewith we briefly describe such modelling, and whenever relevant we highlight the main modifications we introduced to the initial scenario. Firstly, The robot grippers are now explicitly modelled. Each gripper is now considered as a resource that can be occupied (i.e., keeping a link firmly, or rotating a link) or free. This open the possibility of representing which gripper will manipulate a given link. Then, each time a manipulation action is carried out on a given link, it is assured that the link is centred in the robot workspace. This is due to the fact that, due to the physical property of the object, some of the link can be positioned outside the reach of the robot arms. Finally, grasping and release actions by the two grippers are now explicitly modelled.
All the above mentioned features allow for mainly two improvements: on the one hand, the encoding is expected to be able to better manage the explicitly modelled robot resources (i.e., the grippers); on the other hand, manipulation actions are characterised by a more precise semantics, which does not make any implicit assumption about actual robot behaviour. 3
The architecture of the Baxter from Rethink Robotics is shown in Figure 2. In the current implementation, perception is managed using a camera sensor located on top of the robot’s head and pointing downward, which provides 6D poses for each link, and in turn update corresponding ASP-based representation structures in the Knowledge Base module. The Consistency Checking module performs a check for knowledge base validation. In case the check succeeds, the Goal Checker module is notified and it process the information given by the Knowledge Base in order to compute which requirements are already fulfilled. In fact, usually due to human intervention, some constrains included in the goal can be already achieved. Tacking this in consideration the problem is then generated. The Action Planner module receives such problem instance and generates a plan in the form of a suitable sequence of actions to be performed. Once a plan is generated, its actions are processed sequentially to drive the overall behaviour of the robot Motion Planner module, which is responsible of the execution.
For the sake of brevity we will focus only on the Action Planning module and how
we modified it in order to implement different approaches.
In this section we describe how ASP is used to implement the Action Planning Module
depicted. In the following, we assume the reader is familiar with ASP and ASP-Core-2
input language specification [
ASP is not a planning-specific language, but it can be also used to specify encoding
for planning domains [
The encoding described in this section is embedded into a classical iterative deepening
approach in the spirit of SAT-based planning [
Inside the context of the extended scenario (see Section 2.2), we explored two different strategies in order to investigate the pros and drawbacks of each approach. Moreover, in this scenario, we investigate the propriety of the macros. The two strategies are: – Simple Actions Extended Scenario (SAES): This encoding models the same actions as the Standard Strategy in the simple scenario but it includes also the robot resources that can be occupied at each time step (i.e. the robot gripper); – Macro Actions Extended Scenario (MAES): Here we have modelled the same scenario as in the SAES. The difference consists of the modelled actions: sets of simple actions are gathered inside just one atoms.
Representing Macros in ASP Given a rule ri representing an action, pre(ri) denotes the body of the rule. Intuitively, it represents the conditions that must hold in order to activate the action represented by the rule. Moreover, del(ri) (resp. add(ri)) represent all the atoms that are set as false (resp. true) whenever the conditions denoted by pre(ri) hold. We encoded a macro action as a single choice rules composed by a fresh atom in its head containing all the variables appearing in its body. Furthermore, the choice rule body it is composed as follows: a macro ri;j is constructed by assembling the rules representing single actions and by generating pre(ri;j ), del(ri;j ), and add(ri;j ), as follows: – pre(ri;j ) = pre(ri) [ (pre(rj ) n add(ri)) – del(ri;j ) = (del(ri) n add(rj )) [ del(rj ) – add(ri;j ) = (add(ri) n del(rj )) [ add(rj ) where ri and rj are two distinct rules. Then, for a macro ri;j , the body of the choice rule is represented by pre(ri;j ). The macro composed as such represent multiple simple action and their effect that are modeled as a set of several simple rules.
Macros for the Extended Scenario. The following macros have been considered: – linkToCentral take: it is the composition of two actions move link to central, that moves the articulated object so that the joint in between the links that have to be manipulated is in the centre of the workspace, and takes links to move, that grasps the links to be manipulated. As links cannot be grasped by the robot if they are not in the centre of the workspace, this macro aims at providing a single rule for cases where links are not in the right position. – changeAngle release: it is the composition of the choice rule changeAngle, that changes the angle of a link, and release links, that releases the links currently grasped. This macro aims at providing a single rule for cases where it is necessary to act on a link and then releasing it. – take changeAngle release: represents the composition of takes links to move, changeAngle, and release links. This macro aims at providing a single action for cases where it is necessary to act on a link that was already in the center of the workspace. In order to obtain an overview of the capabilities of the considered encodings we used as test problems the same problems, with the due adaptations for each model. Eventually, we had 320 instances with 4 and 6, and granularity values of 4, 6, 8 or 12 possible angles, 10 instances for each pair (number of links, granularity). For each testing instance time limit of 300 seconds and memory limit of 16 GB was applied. Clingo was used to solve the ASP-encoded instances. All the experiments were conducted on Intel i7-4790 CPU and Linux OS. We compared the performance of the considered encodings using coverage (percentage of solved instances) and PAR10. Penalised Average Runtime (PAR10) score is a metric usually exploited in machine learning and algorithm configuration techniques. This metric trades off coverage and runtime for solved problems: if an encoding e allows the solver to solve an instance in time t T (T = 300s in our case), then P AR10(e; ) = t, otherwise P AR10(e; ) = 10 T (i.e., 3000s in our case). The above tables summarises the results achieved by Clingo for solving instances encoded in the Standard Strategy, SAES, and MAES. It is worth reminding that the Standard Strategy encoding is much more simplistic then the others, as it ignores the position of the links to be manipulated, and considers high level actions that have to be broken down into a large number of low-level primitives. On the contrary, SAES and MAES encodings provide a more detailed and rich description of the problem, that allows to generate plans that are easier to be put in place by the manipulator. So, a direct comparison between the Standard Strategy and SAES/MAES is not possible, but it is nonetheless interesting to have also the results obtained by the Standard Strategy. The comparison of the performance achieved by Clingo when using the SAES and MAES encodings can shed some light on the usefulness of the macros. It is easy to notice that the use of macros allows Clingo to solve a larger number of instances, and that macros are generally helpful in improving the runtime.
In the future we would like to test with other ASP solvers, e.g. WASP [