Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Translating continuous sensor data into abstractions suitable for use in Beliefs-Desires-Intentions (BDI) style agent programming languages is an area of active study and research [6, 7, 17]. Work in [7] provides an architecture for autonomous systems which explicitly includes an abstraction engine responsible for translating continuous data into discrete agent beliefs and for reifying actions from the agent into commands for the underlying control system. The architecture includes an operational semantics that specifies the interactions between the various sub-systems.

This paper reports on three autonomous systems based on this architecture, recommends changes to the semantics and then presents a fourth system using the new architecture. In particular we recommend moving away from a view based on a fixed number of sub-systems, to one based on a variable number of communication channels; and abandoning the idea that the abstraction engine works with data present in a logical form.

2 Agents with Abstraction Engines

Hybrid models of control are of increasing popularity in the design and implementation of autonomous systems. In particular there has been interest in systems in which a software agent takes high-level decisions but then invokes lower level controllers to enact those decisions [14, 15, 20]. In many applications the ability of a rational agent to capture the “reasons” for making decisions is important [11]. As the key programming paradigm for rational agents, the BDI model (Beliefs-Desires-Intention [18]) is of obvious interest when designing and programming such systems.

A key problem in integrating BDI programs with control systems is that the data generated by sensors is generally continuous in nature where BDI programming languages are generally based on the logic-programming paradigm and prefer to manage information presented in the format of discrete first order logic predicates. A second problem is that the data delivered from sensors often arrives faster than a BDI system is able to process it, particularly when attempting to execute more complex reasoning tasks at the same time.

Work in [7] proposes the architecture shown in Fig. 1 in which an abstraction engine is inserted between the rational agent (called the reasoning engine) and the rest of the system. The abstraction engine is able to rapidly process incoming sensor data and forward only events of interest to the reasoning engine for decision-making purposes. The abstraction engine mediates between the reasoning engine and a physical engine (representing the software control systems and sensors of the underlying autonomous system) and a continuous engine which can perform calculation and simulation, specifically, in the original architecture, with a view to path planning and spatial prediction.

Fig. 1.
figure 1

Abstract architecture for agent based autonomous systems

Full size image

The reasoning engine reasons with discrete information. The abstraction engine is responsible, therefore, for abstracting the data from sensors (e.g., real number values, representing distances) to predicates (e.g., \(too\_close\), etc.). In [7] it is assumed that the abstraction engine works with sensor readings represented in logical form – for instance of the form distance(2.5). A function, \( fof \), is assumed which transforms data from sensors into this representation. The reasoning engine makes decisions about actions, but may also request calculations (for instance estimates of whether any collisions are anticipated in the next time window). The abstraction engine is responsible for translating these actions, which it is anticipated will be expressed in a high level fashion, into appropriate commands for either the physical engine or the continuous engine.

A variant of the Gwendolen BDI programming language [8], named EASS, implements this architecture. Specifically it provides BDI-based programming structures for both abstraction and reasoning engines (so both are implemented as rational agents). It also provides Java classes for building middleware environments for the agents which implement the operational semantics of interaction from [7]. These environments can communicate with external systems by a range of methods (e.g., over sockets or using the Robot Operating System (ROS)Footnote 1 [16]) and provide support for transforming data from these systems into first order predicate structures (i.e., providing the fof function). We refer to the EASS language and associated environment support as the EASS framework. The EASS framework was used in an extensive case study for the architecture involving satellite and space craft systems [10, 13].

3 Practical Systems

We now discuss three systems built using the EASS framework. The first is a demonstration system in which a robot arm performs sort and segregate tasks. The second is a simulation of a convoy of road vehicles. The third is a public engagement activity involving LEGO robots.

3.1 An Autonomous Robotic Arm

The autonomous robotic arm system performs sort and segregate tasks such as waste recycling or nuclear waste managementFootnote 2 [1, 2]. The system is required to view a set of items on a tray and identify those items. It must determine what should be done with each one (e.g. composted, used for paper recycling or glass recycling, etc.) and then move each item to a suitable location.

The system integrates computer vision, a robot arm and agent-based decision making. It is implemented in the Robot Operating System (ROS) [16]. Computer vision identifies items on a tray [19]. These identities and locations are published to a ROS topic – a communication channel. The abstraction engine subscribes to this topic and abstracts away the location information informing the reasoning engine what types of object can be seen. The reasoning engine makes decisions about what should be done with each object. These decisions involve, for instance, sending: anything that is plant matter to be composted; paper for recycling; and bricks for landfill. These decisions are published to a different topic by the abstraction engine (adding back the information about object location) to which the robot arm control system subscribes. The control system publishes information about what it is doing which the reasoning engine uses to make sure new instructions are not sent until previous ones have completed.

Fig. 2.
figure 2

Architecture for the Robot Arm

Full size image

The architecture is shown in Fig. 2. The abstraction and reasoning engine operate as described in [7]. We also show the Java Environment that supports interaction. There is no equivalent to the continuous engine. The physical engine is a combination of the arm control system and the computer vision system. The computer vision and robotic arm sub-systems communicate with each other for coordination when moving objects.

This system has subsequently been extended to deal with the sort and disrupt problem [1]. A canister is presented, which must be lifted and placed in a set of v-shaped grooves, before it is opened using a pneumatic cutting tool to inspect the contents which then undergo sort and segregate. This demonstrator consists of a KUKA IIWA arm, with a payload of 7 kg. The location of disruption is indicated on a canister via a laser-pen to prevent physical destruction of the test pieces. As well as handling the sort and disrupt task the agent can reason about faulty equipment (simulated using laser-pen failure). The reasoning engine uses a reconfiguration strategy [9] to instruct the arm to use a different laser-pen to complete the task. Similarly the agent reasons about the accuracy and reliability of the information received from the computer vision system.

3.2 Vehicle Convoying

We view an autonomous vehicle convoy as a queue of vehicles in which the first is controlled by a human driver, but subsequent vehicles are controlled autonomously. The autonomously controlled “follower” vehicles maintain a safe distance from the vehicle in front. When a human driving a vehicle wishes to join a convoy they signal their intent to the convoy lead vehicle, together with the position in the convoy they wish to join. Autonomous systems in the lead vehicle then instructs the vehicle that will be behind the new one to drop back, creating a gap for it to move into. When the gap is large enough, the human driver is informed that they may change lane. Once this is achieved, autonomous systems take control and move all the vehicles to the minimum safe convoying distance. Similar protocols are followed when a driver wishes to leave the convoy.

Maintenance of minimum safe distances between vehicles is handled by two low level control systems. When the convoy is in formation, control is managed using distance sensors and wireless messages from the lead vehicle. These messages inform the convoy when the lead vehicle is braking or accelerating and so allow smooth responses from the whole convoy to these events. This reduces the safe minimum distance to one where fuel efficiency gains are possible. In some situations control uses sensors alone (e.g., during leaving and joining). In these situations the minimum safe distance is larger.

The agent system manages the messaging protocols for leaving and joining, and switches between the control systems for distance maintenance. For instance, if a communication break-down is detected, the agent switches to safe distance control based on sensors alone. The abstraction engine, therefore, is involved primarily in monitoring distance sensors and communication pings.

The system was developed in order to investigate issues in the verification and validation of these convoying systems  [12]Footnote 3. A simulation of the vehicle control systems was created in MATLab and connected to the the TORCSFootnote 4 racing car simulator. The architecture for this system is close to that in [7] with a single physical engine, but still no continuous engine. Several agents connect to the simulator, via the Java environment. The agents use the Java environment for messaging between agents. This architecture is shown in Fig. 3.

Fig. 3.
figure 3

Architecture for a simulated convoying system

Full size image

Following verification and validation phases based on simulation, we are in the process of transferring the system to Jaguar 4 \(\times \) 4 wheeled robotsFootnote 5 for hardware testing in outdoor situations.

3.3 LEGO Rovers

The LEGO Rovers system was developed to introduce the concepts of abstraction and rational agent programming to school childrenFootnote 6. It is used in science clubs by volunteer members of the STEM Ambassador scheme, and has also been used in larger scale events and demonstrations. The activity introduces the user to a teleoperated LEGO robot and asks them to imagine it is a planetary rover. The robot’s sensors are explained, the user is shown how the incoming data is abstracted into beliefs such as obstacle or path using simple thresholds and can then create simple rules, using a GUI, which dictate how the robot should react to the appearance and disappearance of obstacles, etc.

This activity has been through two versions. In the first, the EASS framework was used off-the-shelf with LEGO NXT robots, once again with no continuous engine. The GUI ran on laptops. The system used the leJOS Java-based operating system for Mindstorms robots [4, 5] and classes from this were used for direct communication with the robot. Sensors needed to be polled for data in contrast two our other applications where sensors continuously published data to a stream. While the activity worked well, some issues were observed, particularly the robot’s response to rules sometimes lagged more than could be accounted for simply by delays in Bluetooth communication. Investigation suggested that, even when concerned only with processing sensor data, a rational agent was more heavy-weight technology than was required for abstraction. The rational agent used logical reasoning to match plans to events which were then executed to produce abstractions. We discuss an amended version of the system in Sect. 5.

4 An Improved Architecture and Semantics

Practical experience has shown that the provision of a continuous engine is not a fundamental requirement and that it is unrealistic to think of a physical engine as a monolithic entity that encompasses a single input and a single output channel. The use of agent-based abstraction engines that work with first order formulae also seems unnecessary and, in some cases, causes additional inefficiency in the system. This leads us to an adaptation of the semantics in which the purpose of the abstraction engine is to link the reasoning engine to a variety of communication channels which can be viewed as either input or output channels. Input channels include channels which the abstraction engine polls for data so long as it does not execute further until it has received an answer. Communications, like those handled by the continuous engine, in which a request is made for a calculation and, some time later, an answer is received can be handled by placing a request on an output channel and then receiving an answer on an input channel. The abstraction engine (and reasoning engine) can be responsible for matching received answers to requests in an appropriate fashion.

We group these channels into two sets. \(\varPi \) are output channels where the abstraction engine writes information or sends commands to be interpreted by other parts of the system. \(\varDelta \) are input channels. Input channels may operate on a request-reply basis but the abstraction engine does nothing between request and reply. Figure 4 shows this new architecture.

Fig. 4.
figure 4

Refined architecture for agent-based hybrid systems with abstractions

Full size image

In [7], \(\varPi \) is the physical engine, \(\varOmega \) the continuous engine and \(\varDelta \) is a set of sensor inputs. The semantics also references A (the abstraction engine), R (the reasoning engine) and \(\varSigma \), \(\varGamma \) and Q, sets of predicates which are used in communication between the abstraction and reasoning engines. \(\varSigma \) is a set of shared beliefs which stores abstractions, \(\varGamma \) is a set of commands the reasoning engine has requested for execution and Q is a set of queries from the reasoning engine. The whole system is represented as a tuple. In the modified version of the operational semantics, we no longer consider \(\varOmega \) and Q. \(\varDelta \) and \(\varPi \) are now sets of channels rather than explicit sub-systems. Therefore, we represent the system as a tuple \(\langle \varDelta , \varPi , A, R, \varSigma , \varGamma \rangle \). The operational semantics specifies a labelled transition system on this tuple. For clarity in discussion, we will sometimes replace parts of this tuple with ellipsis (\(\ldots \)) if they are unchanged by a transition.

Most of the rules governing interaction between the abstraction and reasoning engine are largely unchanged. We show these rules in Fig. 5 for completeness but do not discuss them further here. We refer the reader to [7] for further discussion and motivation. Three rules involving “queries” (the set Q) intended for the continuous engine have been removed.

Fig. 5.
figure 5

Unchanged semantic rules

Full size image

We turn our attention to the remaining rules in the semantics. It should be noted that all subsystems may take internal transitions which change their state.

Only one rule involving interaction between abstraction and reasoning engine needs modification. This semantic rule governs transitions the system takes after the reasoning engine has placed a command in the set \(\varGamma \) for the abstraction engine to reify. The original semantics views this reification process as a combination of the transitions taken by the abstraction engine in order to transform the command and any subsequent changes to the physical engine. We simplify our view of this so we consider only the change in A when it reads in the command \(A \xrightarrow {read_C{\gamma }} A'\). The abstraction engine may make subsequent internal transitions as it processes the command. The changes to the system when it passes the command on to the physical engine are shown in semantic rule (9). The new version of this rule is shown in (8). In this rule when A performs a read on \(\varGamma \) the whole system makes a transition in which A is transformed to \(A'\) and \(\gamma \), the command A has read, is removed from \(\varGamma \).

$$\begin{aligned} \frac{ \gamma \in \varGamma \qquad \quad A \xrightarrow {read_C(\gamma )} A' }{ \langle \ldots , A, \ldots , \varGamma \rangle \xrightarrow {do_A(\gamma )} \langle \ldots \ldots , A', \ldots , \varGamma \backslash \{\gamma \} \rangle } \end{aligned}$$
(8)

Example. Assume a simple BDI agent, A, represented as a tuple, \(\langle \mathcal{B}, \mathcal{P}, \mathcal{I} \rangle \) of a set \(\mathcal{B}\) of beliefs, a set \(\mathcal{P}\) of plans and an intention stack \(\mathcal{I}\) of commands to be executed. Assume that when A reads a formula, \(\gamma \in \varGamma \), it places it in \(\mathcal{B}\) as \(do(\gamma )\). Consider the Lego Rover example and a request from the reasoning engine for the robot to \(turn\_right\) when A has an empty belief set. Before execution of rule (8), \(A = \langle \emptyset , \mathcal{P} \rangle \). After the execution of Eq. 8, \(A = \langle \{do(turn\_right)\}, \mathcal{P}, \mathcal{I} \rangle \).

Our view of the interaction of the abstraction engine with the rest of the system is considerably simplified by the removal of an explicit continuous engine. Two complex semantic rules are removed and we need only consider what happens when the abstraction engine publishes a command to an output channel and when it reads in data from an input channel.

A, the abstraction engine, can place data, \(\gamma \) (assumed to be the processed form of a command issued by the reasoning engine – though this is not enforcedFootnote 7), on some output channel, \(\pi \) from \(\varPi \). It does this using the transition \(A \xrightarrow {run(\gamma , \pi )}~A'\) and we represent the change caused to \(\pi \) when a value is published on it as \(\pi \xrightarrow {pub(\gamma )}~\pi '\). \(\varPi \{\pi / \pi '\}\) is the set \(\varPi \) with \(\pi \) replaced by \(\pi '\). Rule (9) shows the semantic rule for A publishing a request to \(\pi \).

$$\begin{aligned} \frac{ \pi \in \varPi \qquad \quad A \xrightarrow {run(\gamma , \pi )} A' \qquad \quad \pi \xrightarrow {pub(\gamma )} \pi ' }{ \langle \ldots , \varPi , A, \ldots \rangle \xrightarrow {run(\gamma , \pi )} \langle \ldots , \varPi \{\pi / \pi '\}, A', \ldots \rangle } \end{aligned}$$
(9)

This rule states that if A makes a transition where it publishes some internally generated command, \(\gamma \), to \(\pi \), \(A \xrightarrow {run(\gamma , \pi )} A'\), then assuming \(\pi \) is one of the output channels and then effect of publishing \(\gamma \) to \(\pi \) is \(\pi '\) then the whole system makes a transition in which A is replaced by \(A'\) and \(\pi \) by \(\pi '\).

Example. Returning to our example above, assume that A has plans that reify \(turn\_right\) into a sequence of two commands, one for each engine controlling a wheel on the robot. Internal execution of these plans places these commands on the intention stackFootnote 8.

$$A = \langle \{\mathcal{B}, \mathcal{P}, pilot(right.back()):pilot(left.forward()):\mathcal{I} \rangle $$

We assume \(\varPi \) consists of two output channels pilot (which transmits commands over bluetooth to the leJOS Pilot class) and gui which sends status information to the GUI controlling the robot. The agent executes the command \(pilot(\gamma )\) by placing \(\gamma \) on the pilot channel and removing the command from the intention stack. Assume that the pilot channel is empty and the GUI channel contains the notification of an obstacle \(gui = \{obstacle\}\). So before execution of rule 9, \(\varPi = \{\emptyset ,\{obstacle\}\}\). After one execution, \(\varPi = \{\{right.back()\}, \{obstacle\}\}\) and \(A = \langle \{\mathcal{B}, \mathcal{P}, pilot(left.forward()):\mathcal{I} \rangle \).

Similarly, we indicate the process of abstraction engine, A, reading a value from a channel d by \(A \xrightarrow {read(d)} A'\). We represent any change in state on the channel if a value is read from it as \(d \xrightarrow {read} d'\). This allows us to simply define a semantics for perception in (10).

$$\begin{aligned} \frac{d \in \varDelta \qquad \quad A \xrightarrow {read(d)} A' \qquad \quad d \xrightarrow {read} d' }{ \langle \varDelta , \ldots A, \ldots \rangle \xrightarrow {read(d)} \langle \varDelta \{d / d'\}, \ldots , A', \ldots \rangle } \end{aligned}$$
(10)

Example. Returning to the example, assume that \(A = \langle \emptyset , \mathcal{P}, \mathcal{I} \rangle \) reads from two input channels: a distance sensor and an RGB colour sensor. Let \(\varDelta = \{\{50\},\{\langle 1, 5, 6 \rangle \}\}\) (i.e., there is an object 50 centimetres from the robot and the color sensor is looking at a very dark (almost black) surface). Suppose, when A reads data, d, from either channel it removes the reading from the channel and turns it into a belief distance(d) or rgb(d) respectively. If rule (10) is executed and A reads from the distance channel. Then \(\varDelta \) becomes \(\{\emptyset ,\{\langle 1, 5, 6 \rangle \}\}\) and \(A = \langle \{distance(50)\}, \mathcal{P}, \mathcal{I} \rangle \).

The main advantage of this new semantics is the simplification of the system by the removal of semantic rules involving calculations and queries and the removal of related components from the state tuple. We also believe it has the pragmatic virtue of representing more accurately the architectures of systems that people actually build using abstraction engines and reasoning agents.

5 Implementation (LEGO Rovers v.2)

The new operational semantics required few changes to the EASS framework, many of which had been implemented incrementally during our experience building the systems in Sect. 3. Support for continuous engines was dropped, simplifying both the language and the Java Environment classes. Support for agent-based abstraction engines was kept, but their use became optional. The implementation had never enforced the use of single input and output channels and the nature of Java meant these were trivial to include as an application required.

Fig. 6.
figure 6

Architecture for the LEGO rover system

Full size image

A second version of the LEGO Rover activity was then developed for LEGO EV3 robots with a GUI running on Android Tablets. This version used the new semantics with the EASS based abstraction engine being replaced by an efficient Java class that handled abstraction of data and reification of commands.

The architecture for the second version is shown in Fig. 6. Both abstraction and reasoning engines interact with the GUI which displays the sensor data and the abstractions, and allows the user to define the rules in the reasoning engine. The abstraction engine polls two sensors (ultrasonic and light) for data and publishes commands to the robot. Feedback from demonstrators and teachers suggests that the changes to the activity, including the removal of lag caused by the agent-based abstraction engine, provide a better experience for children.

6 Further Work and Conclusions

In this paper we amended the operational semantics for communication between rational agents, abstraction engines and the rest of a hybrid autonomous system that was presented in [7]. This results in a simplification of the semantics, particularly the removal of an explicit continuous engine and the insistence that abstraction engines handle data in a logical form. The changes are based on extensive practical experience in developing such systems, three of which we have outlined in order both to illustrate the development of agent-based autonomous systems and to motivate the changes to the semantics.

In future, we intend to provide more software support for the implemented framework, particularly for the development of abstraction engines. For instance we aim to expand our abstraction engines, which are currently based almost exclusively on thresholding data, to richer formalisms that would allow abstractions to be formed based on observed complex events and to explore the use of external systems and frameworks to perform the necessary stream processing. In particular it seems desirable to consider abstraction engines either developed in, or incorporating, efficient stream processing tools such as EsperFootnote 9 or ETALIS [3].

We now have a refined and simplified a framework for agent-based hybrid systems that use abstraction engines. The framework is well-supported by practical experience in the construction of such systems and represents a strong practical theoretical basis for agent-based hybrid systems.