This paper describes the development of an architecture that combines non-monotonic logical reasoning and deep learning in virtual (simulated) and real (physical) environments for an assistive robot. As an illustrative example, we consider a robot assisting in a simulated restaurant environment. For any given goal, the architecture uses Answer Set Prolog to represent and reason with incomplete commonsense domain knowledge, providing a sequence of actions for the robot to execute. At the same time, reasoning directs the robot's learning of deep neural network models for human face and hand gestures made in the real world. These learned models are used to recognize and translate human gestures to scenarios that mimic real-world situations in the simulated environment, and to goals that need to be achieved by the robot in the simulated environment. We report the challenges faced in the development of such an integrated architecture, as well as the insights learned from the design, implementation, and evaluation of this architecture by a distributed team of researchers during the ongoing pandemic.
per) waiter in a simulated restaurant, as shown in Figure 1.
The robot has to perform tasks such as seating customers
at suitable tables, taking and delivering food orders, and
collecting payment. To perform these tasks, the robot
extracts and reasons with the information from different
sensors (e.g., camera, range finder) and incomplete
commonsense domain knowledge. This knowledge includes
relational descriptions of the domain objects and their
attributes (e.g., size, number, and relative positions of tables,
chairs, and people). It also includes axioms governing
actions and change in the domain (e.g., the preconditions
and effects of seating a group of people at a particular
table), including default statements that hold in all but
a few exceptional circumstances (e.g., “customers
typically need some time to look at the menu before they
place an order”). Since the domain description is
incomplete and can change over time, the robot also reasons
sor observations). However, practical domains make it
difficult to provide a comprehensive encoding of domain
knowledge, or the computational resources and examples There is a well-established history of the use of
logneeded to augment or revise the robot’s knowledge. Fur- ics in different AI and robotics applications. The
nonthermore, circumstances such as the ongoing pandemic monotonic logical reasoning paradigm used in this paper,
make it rather challenging for a distributed team of re- ASP, has been used by an international community of
researchers to design and evaluate such architectures for searchers for many applications in robotics [
This paper makes a two-fold contribution towards ad- decades on integrating logical and probabilistic
reasondressing the above-mentioned challenges. First, it uses ing [
main knowledge at a finer granularity; Given the use of deep networks in different applications,
• Reasons with domain knowledge to allow humans there is much interest in understanding their operation in
making hand gestures in the physical world to terms of the features influencing network outputs [
The interactive interface between the virtual and physical Methods in the other group provide descriptions that make
world helped the three undergraduate student authors de- a reasoning system’s decisions more transparent [
The remainder of this paper is organized as follows. We reasoning and learning in integrated robot systems that begin by discussing related work in Section 2. Next, we combine reasoning with incomplete commonsense dodescribe our architecture and its components in Section 3. main knowledge and data-driven learning from limited The execution traces and results of evaluating our archi- examples. We seek to demonstrate that this objective can tecture’s components are described in Section 4, and the be achieved by building on KR tools. To do so, we build conclusions are described in Section 5. on some of the prior work of the lead author with others. Knowledge Representation+ Reasoning domain knowledge (relations, action theory) non−monotonic logical reasoning
probabilistic reasoning virtual world physical world Interaction Interface deep/reinforcement
inductive
Interactive Learning providing a bill and collecting payment; and (iv) responding to requests from the customer(s) and the designer. The robot uses probabilistic algorithms to model and account for the uncertainty experienced during perception and actuation. Interactions of the robot with a human supervisor are handled through the interface that interprets hand gestures made by a human in the physical world. The robot has incomplete (and potentially imprecise) domain knowledge, which includes number, size, and location of tables and chairs; spatial relations between objects; and some axioms governing domain dynamics such as: • If the robot allocates a group of customers to a table, all members of the group are considered to be seated at that table. • The robot cannot seat customers at a table that is
not empty, i.e., is occupied. • Any customer cannot be allocated to more than one table at a time.
In particular, we build on work on: (i) a refinement-based
architecture for representation and reasoning [23]; (ii)
explainable agency and theory of explanations [24, 25]; This knowledge, e.g., the axioms describing dynamic
and (iii) combining non-monotonic logical reasoning and changes and the values of some attributes of the domain
deep learning for axiom learning and scene understand- or robot, may need to be revised over time.
ing [
CR-Prolog, an extension of Answer Set Prolog (ASP) that introduces consistency restoring (CR) rules [27]. ASP is based on stable model semantics, and supports default negation and epistemic disjunction, e.g., unlike “¬” that implies a is believed to be false, “ ” only implies a is not believed to be true, and unlike “ ∨ ¬” in propositional logic, “ ¬” is not tautologous. ASP can represent recursive definitions and constructs that are difficult to express in classical logic formalisms, and it supports non-monotonic logical reasoning, i.e., the ability to revise previously held conclusions based on new evidence. We use the terms “CR-Prolog” and “ASP” interchangeably in this paper.
A Pepper robot operates as a waiter in a restaurant. Its tasks include: (i) greeting and seating customers; (ii) taking food orders and delivering food to specific tables; (iii) ¬((, ), ) ← ¬ℎ(( ), ) (1e) (1f) ℎ(( , 1), ), 1 ̸= 2
Reasoning. Given the representation of domain knowledge described above, the robot still needs to reason with (1a) this knowledge and observations perform tasks such as inference, planning, and diagnostics. In our architecture, we automatically construct the CR-Prolog program Π( , ℋ), (1b) which includes Σ and axioms of , inertia axioms, reality
check axioms, closed world assumptions for actions, and (1c) observations, actions, and defaults from ℋ; a basic version of this program can be viewed online [29]. For planning and diagnostics, this program also includes helper axioms (1d) that define a goal, and require the robot to search until a consistent model of the world is constructed and a plan is computed to achieve the goal. Planning, diagnostics, and inference are then reduced to computing answer sets = (1, 2). The object constants relevant to of Π ; we use the SPARC system [30] to compute answer this transition then include 1, 1, 2, and ℎ. set(s). Each answer set represents the robot’s beliefs in a possible world; the literals of fluents and statics at a time Definition 2. [Relevant system description] step represent the domain’s state at that time step. As The system description relevant to a transition = stated earlier, our architecture’s non-monotonic reasoning ⟨ 1, , 2⟩, i.e., ( ), is defined by signature Σ( ) ability supports recovery from incorrect inferences due to and axioms. Σ( ) is constructed to comprise: incomplete knowledge or noisy sensor inputs. • Basic sorts of Σ that produce a non-empty inter
Prior work by the lead author and others resulted in an section with ( ). architecture for reasoning with transition diagrams at two • All object constants of basic sorts of Σ( ) that resolutions, with the fine-resolution diagram formally de- form the range of a static attribute. ifned as a refinement of the coarse-resolution diagram [23].
This definition differs from recent work on refinement and • The object constants of basic sorts of Σ( ) that abstraction of ASP programs and other logics [31, 32] in form the range of a fluent, or the domain of a how the transition diagrams are coupled formally to satisfy lfuent or a static, and are in ( ). the requirements in the challenging context of integrated • Domain attributes restricted to Σ( )’s basic sorts. robot systems. This relation guarantees the existence of a Axioms of ( ) are those of restricted to Σ( ). It path in the fine-resolution transition diagram implement- can be shown that for each transition in the transition diaing each coarse-resolution transition. The robot can then gram of , there is a transition in the transition diagram use non-monotonic logical reasoning to compute a se- of ( ). States of ( ), i.e., literals comprising fluents quence of abstract actions for any given goal, implement- and statics in the answer set of the ASP program, and ing each abstract action as a sequence of fine-resolution ground actions of ( ), are candidates for further exploactions by automatically zooming to and reasoning prob- ration. Continuing with the example in Definition 1, for abilistically with the part of the fine-resolution diagram = (1, 2), ( ) will not include axioms relevant to the coarse-resolution transition. We build on corresponding to other actions, e.g., for seating customers that notion of relevance to automatically: (a) constrain the at a table or giving the bill to a customer. If the robot has robot’s attention to the nodes and regions relevant to any to perform fine-resolution probabilistic reasoning for acgiven transition or plan that the robot has to execute—this tion execution, only the refinement of the relevant system supports selective grounding; (b) limit recognition of hand description will be considered. gestures to the subset relevant to the task at hand, e.g., gestures for placing an order once customers are seated, A robot waiter equipped with the representation and reaand limit learning to previously unknown hand gestures soning module described above, still needs to interact with and related axioms—see Section 3.3; and (c) provide rela- humans. To support design and evaluation when in-person tional descriptions of decisions by tracing the evolution of interaction with the robot is not possible, we incorporated relevant beliefs and application of relevant axioms—see the interactive simulation module, as described below. Section 3.3. For ease of understanding, we define the notion of relevance for a given transition; similar definitions can be provided for a given goal or literal. 3.2. Interactive Simulation and Hand
Gestures
Let = ⟨ 1, , 2⟩ be the transition of interest. Let ( ) be the set of object constants of signature Σ of identified using the following rules: • Object constants from are in ( ); • If (1, . . . , , ) is a literal formed of a domain attribute, and the literal belongs to 1 or 2, but not both, then 1, . . . , , are in ( ); • If body of an axiom of contains (1, . . . , , ), a term whose domain is ground, and (1, . . . , , ) ∈ 1, then 1, . . . , , are in ( ).
vant to . For example, consider an initial state 1 with (1, 1) and (, ℎ), and action
the design and evaluation of our architecture. We used PyBullet [33], a Python-based module for simulating games and domains for machine learning and robotics. It enables us to quickly load different articulated bodies and provides built-in support for forward and inverse kinematics, collision detection, and simulation of domain dynamics.
In our architecture, PyBullet is used to automatically generate a restaurant layout, e.g., see Figure 4, based on the domain information encoded in the ASP program, e.g., Figure 3. Using the built-in blender of PyBullet, we are able to populate the simulated restaurant with a Pepper robot, tables, chairs, and the desired number of customers. We are also able to make on-demand revisions to the domain, e.g., to match changes in the domain knowledge.
In addition, our simulator supports the movement of the The architecture described so far reasons with incomplete domain knowledge, which may lead the robot to make incorrect decisions or cause the robot’s performance to suffer, e.g., the robot may compute incorrect or unnecessarily long plans for any given goal. Also, the encoded knowledge and models may need to change over time. We address this requirement by introducing a module for interactive learning and generation of relational descriptions as “explanations” of the robot’s decisions and beliefs.
Table 4 Table 5 Order fries ponent of our architecture has two parts. Given the use of hand gestures for human-robot interaction, the first part seeks to detect new gestures and learn models for these gestures. A new hand gesture is detected when Order steak Ask for the bil the observed gesture differs significantly from any of the ITnhduemxb known gestures. A significant difference is experimenLRMiitindtgldele tally determined as a difference in 15% of the keypoints in a sequence of images. When a new gesture is recognized, the robot automatically gathers a sequence of image tFi oignusreto5r:o(bLoetf;t)(RSiugbhste)tTohfeha2n1dkgeeypstouirnetss pursoevdidtinogmdoirdeecl- frames, extracts features from these images, stores them each hand gesture. in a separate file and quickly updates the hand gesture recognition models to include this new gesture. A key feature of our architecture is that reasoning and learning robot in the restaurant based on the axioms encoded in the inform and guide each other. For example, when the robot ASP program. Furthermore, it is also possible to introduce has to recognize and respond to gestures, it automatically new objects in the simulator (e.g., using hand gestures, limits itself to gestures relevant to its current category of see below) and automatically add this information to the tasks, e.g., a robot delivering food cannot respond to direcASP program for further reasoning tion from a supervisor to seat new customers1. Also, any
Recall that communication of human instructions to the newly learned gesture is placed in the appropriate caterobot waiter is based on hand gestures made in the physi- gory of gestures (determined based on purpose of gesture) cal world. To support such interaction, we first enabled for subsequent reasoning. This use of reasoning to direct our architecture to recognize a base set of hand gestures; learning speeds up recognition and learning. a subset of these gestures are shown in Figure 5(left). The second part of the learning component focuses To model and recognize hand gestures, we integrate the on acquiring axioms corresponding to any new gesture, OpenPose system [34] that characterizes gestures using and merging the axioms with the existing ones. This is 21 keypoints, as shown in Figure 5(right). After the inte- achieved by taking the label provided by human for the gration, the simulator allows us to capture images of the new gesture and checking if the corresponding instruction hand gestures made in the physical world to quickly train (e.g., seat two people) can be executed with the existing deep network models that can accurately recognize these knowledge. If that is possible, no further learning is pergestures in new videos (i.e., image sequences). We used formed. If existing knowledge is insufficient to execute an existing Python library for training these deep network the new instruction, or if the human provides feedback, models with experimentally determined loss functions— e.g., a textual or verbal description that is processed using Figure 6. Note that the modularity of the architecture existing tools, which includes an action, literals extracted makes it easy to quickly explore the different deep net- from the feedback are used to construct an axiom that is work models without changing other parts of the architec- merged with existing ones. Once again, reasoning helps ture. The known hand gestures with trained models are then grouped in different categories based on whether they 1Associating priority levels with tasks will enable the robot to interrupt its current task to execute a higher-priority task. Epoch
8
improved
baseline
direct this learning by limiting scope to the relevant ob- Paths from the root to the leaves in these trees provide
ject constants and description. For example, assume that explanations. If multiple such paths exist, we currently
the robot is shown a new gesture for seating a group of select one of the shortest branches at random; other
heuriscustomers at a table. The robot will use human feed- tics could be used to compare the explanations. For
exback about this new gesture, and only consider literals ample, if the robot is asked why it seated a group of three
corresponding to: the location of these customers, its own customers at 5, it can trace the current belief about
location, and the occupancy of tables in the restaurant, to the group back to the initial state through the
applicalearn axioms for the new action. tion of relevant axioms, and come up with an explanation
such as: “The three customers came to the restaurant and
Tracing explanations. Our architecture supports the wanted to be seated as a group. 5 at node 7 was the
ability to infer the sequence of axioms and beliefs that table closest to the entrance that had the desired number
explains the evolution of any given belief or the non- of seats available. I seated the customers at 5”.
selection of any given ground action at a given time. We In addition to tracing the evolution of a target belief
build on the idea of proof trees, which have been used to and justifying the non-selection of a particular action, our
explain observations in classical first-order logic [ 35], and architecture can also provide: (a) a description of any
adapt it to our architecture that is based on descriptions computed or executed plan in terms of literals in the plan;
in non-monotonic logic. Our approach is based on the (b) justification for executing a particular action at a
particfollowing sequence of steps: ular time step by examining the change in state caused by
the action’s execution and how this state change achieves
the goal or facilitates the execution of the next action in
the plan; and (c) inferred outcome(s) of the execution of
hypothetical actions based on a mental simulation guided
by the current domain knowledge. In all these cases, the
identified literals are encapsulated in a prespecified
answer template to provide the descriptions. For proof of
concept examples in simplistic scene understanding
scenarios, please see [
in the head. 2. Ground literals in each such axiom’s body and check whether these ground literals are supported (i.e., satisfied) by the current answer set. 3. Create a new branch in the proof tree (that has the target belief or action as root) for each selected axiom supported by the current answer set, and store the axiom and the related supporting ground literals in suitable nodes. 4. Repeats Steps 1-3 with the supporting ground lit- Control loop. Algorithm 1 is the overall control loop erals in Step 3 as target beliefs in Step 1, until all for the architecture. The baseline behavior (lines 3-8) is branches reach a leaf node without further sup- to plan and execute actions to achieve the given goal as porting axioms. long as a consistent model of history can be computed.
If such a model cannot be constructed, it is attributed to
an unexplained, unexpected observation, and the robot triggers interactive exploration (lines 9-12). Interactive exploration is also triggered if no active goal exists to be achieved (lines 13-15). Depending on the human input, the architecture either acquires the previously unknown gestures and axioms, or attempts to provide the desired description of a target decision or belief (lines 19-21). When in the learning mode, the robot can be interrupted if needed (lines 17-18), e.g., to pursue a new goal.
Meaningfully evaluating architectures for integrated robot systems is challenging. It is difcfiult to find a baseline that provides all the capabilities supported by our architecture, and it is also difficult to evaluate the capabilities of each component of the architecture in isolation. Also, given that reasoning and learning guide each other in our architecture to automatically identify and focus only on the relevant information, task complexity and scalability do not necessarily change substantially by increasing the number of tasks, and just reporting success in many scenarios is not very informative. In addition, it was difficult to use a physical robot to conduct the experimental trials during the pandemic. We thus focus on illustrating the capabilities of our architecture using a combination of execution traces (i.e., use cases) and some experiments that provide quantitative results. The key hypotheses to be evaluated are:
and execute plans to achieve desired goals; H2 : having reasoning inform and guide learning improves computational efficiency of learning and recognition accuracy of the learned models; and H3 : exploiting the links between reasoning and learning provides suitable relational descriptions as explanations of decisions and beliefs.
(Section 4.1), and provide experimental results in support of H2 (Section 4.2). 4.1. Execution traces We provide two execution traces to illustrate the operation of our architecture in specific scenarios. Videos corresponding to these traces can be viewed online [29]2. In all the scenarios, the human user (in the physical world) uses hand gestures to create different situations and also to mimic the gestures to be made by the customers or the supervisor in the restaurant environment. The layout used to generate these traces is shown in Figure 7; it is simplified version of Figure 3.
Consider a scenario in which there is one customer 1 seated at 1 in the restaurant, and the robot waiter is in the region of node 4. In this scenario, the restaurant is organized into regions corresponding to eight nodes: 0 − 7. The subsequent steps in this scenario are: • Three new customers (2 − 4) are introduced in the restaurant as a group by the human designer showing a suitable hand gesture. This information is also added to the ASP program automatically. • The hand gesture also lets the robot waiter (1) know that the new customers are to be seated at a table. The robot comes up with a plan based on the updated ASP program and the vacant table that is closest to it: (1, 5), (1, 0), (1, 1), (1, 5), (1, 6), (1, 1, 2) • Note that applying the action to any customer in a group causes the same effect on all customers in the group. This plan is executed and the state is updated accordingly, e.g., 2 − 4 are seated at 2 after the plan is executed. • The robot can be asked about the executed plan.
Human: “why did you seat all the customers at 2?” Pepper: “Because all the customers wanted to sit together and 2 was the closest available table.” • After some time, 1 has finished eating and would like to leave. The designer imitates the hand gesture that the customer would do in the restaurant to ask for the bill. This is translated into a goal in the ASP program: ℎ(1). • The robot computes and executes a suitable plan to give the bill to 1, collect payment, and provide a receipt, after which 1 leaves the restaurant.
Consider another scenario in which the restaurant initially has no customers. Robot waiter 1 is in the region of node 1 and knows that 1 and 2 have capacity two and four respectively. Once again, the restaurant is organized into regions corresponding to eight nodes: 0 − 7. The subsequent steps in this scenario are: • The human (in the physical world) makes a hand gesture that is unknown to the robot waiter. The robot responds by identifying this as a new gesture and conveys that this will be added to the database of hand gestures. • Robot adds the new hand gesture and solicits feedback about the gesture. The human (designer) intentionally provides a complex instruction (textually) that this gesture corresponds to “serve steak to a group of three new customers, and then give them the bill”.
• Since 1 knows that serving a customer implies giving them the food item they want, it is able to parse this complex instruction into the component actions. When the human then makes the same hand gesture again and introduces three new customers (2 − 4) near the restaurant’s entrance, 1 computes a suitable plan (some steps omitted to promote understanding). (1, 2), . . . , (1, 2), . . . , (1, 2, 2), . . . , (1, , 2), . . . , (1, 2), . . . , • Plan is executed and the state is updated accordingly at different time steps, e.g., 2 − 4 are achieve the assigned goals, identify and learn previously unknown knowledge, and provide on-demand explanations of decision and beliefs. 4.2. Experimental results
ing, we conducted some quantitative studies. The first experiment examined the benefits of reasoning guiding the learning of deep network models for hand gestures. Deep learning methods typically need many labeled training examples and epochs to learn models for the target classification task. However, since learning in our architecture is constrained (by reasoning) to specific gestures or classes of gestures at a time, it took fewer samples and fewer epochs to acquire the desired models that provide high accuracy—see Figure 10.
The second experiment examined whether reasoning helped improve the recognition accuracy. In this experiment, we considered 30 hand gestures. One round of testing included 40 iterations of each hand gesture by a person who did not participate in training. We conducted multiple rounds of testing and ground truth information was provided by the designers (i.e., student authors). In the absence of the coupling between reasoning and learning, the learned models had (on average) an accuracy of 85% over the different hand gestures. However, with learning being directed to specific (classes of) gestures, the learned models resulted in better classification accuracy— ≈ 100%.
The third experiment examined the ability to provide explanatory descriptions in response to different types of queries in different situations. A description was considered to be correct if it had all the correct literals but no additional literals. Overall, the interplay between reasoning (with relevant knowledge) and learning (of previously unknown knowledge) led to the correct relational descriptions in 95% cases, with the “errors” being descriptions containing additional literals that were not essential to answer the query posed but were not necessarily wrong. In the absence of the learned knowledge, the accuracy (averaged over query types) was 65 − 80%. 5. Discussion and Conclusions • Once the designer has provided the domainspecific information (e.g., arrangement of rooms, range of robot’s sensors), planning, diagnostics, and plan execution can be automated. The coupling between reasoning and learning enables more complex theories (of cognition, action) to be encoded without increasing the computational effort substantially.
This explanation is based on the previously- architecture: described approach to trace beliefs and the application of relevant axioms.
We evaluated the architecture in many other scenarios grounded in the motivating (restaurant) domain; the robot was able to successfully compute and execute plans to 1.005 1.000
Future work will further explore the interplay between reasoning and learning for explaining decisions and beliefs while performing reasoning and learning in more complex robotics domains. We will also investigate the use of our architecture on a physical robot interacting with humans through noisy sensors and actuators. The longer-term objective is to support transparent reasoning and learning in integrated robot systems operating in complex domains.