US20160075014A1

US20160075014A1 - Asynchronous Data Stream Framework

Info

Publication number: US20160075014A1
Application number: US14/941,199
Authority: US
Inventors: David Bruemmer
Original assignee: 5D Robotics Inc
Current assignee: Humatics Corp
Priority date: 2011-08-30
Filing date: 2015-11-13
Publication date: 2016-03-17
Also published as: US20130054125A1; US9195911B2; US20160039091A1; WO2013033351A2; WO2013033354A3; US10226864B2; US20130050180A1; US20150285646A1; US8972053B2; US20150269757A1; WO2013033338A4; WO2013033354A2; US9731417B2; US20130054024A1; WO2013033338A2; US20130054023A1; WO2013033351A3; US9053394B2; US20130050121A1; WO2013033338A3

Abstract

An architecture comprising a hardware layer, a data collection layer and an execution layer lays the foundation for a behavioral layer that can asynchronously access abstracted data. A plurality of data sensors asynchronously collect data which is thereafter abstracted so as to be usable by one or more behavioral modules simultaneously. Each of the behaviors can be asynchronously executed as well as dynamically modified based on the collected abstracted data. Moreover, the behavior modules themselves are structured in a hierarchical manner among one or more layers such that outputs of behavior module associated with a lower layer may be the input to a behavior module of a higher letter. Conflicts between outputs of behavior modules are arbitrated and analyzed so as to conform with an overall mission objective.

Description

RELATED APPLICATION

The present application is a continuation of and claims the benefit of priority to U.S. Non-Provisional patent application Ser. No. 13/597791 which in turn claims priority to U.S. Provisional Application 61/529,206 filed Aug. 30, 2011, both of which are hereby incorporated by reference in their entirety for all purposes as if fully set forth herein. The present application if further related to the following commonly assigned patent applications: U.S. patent application Ser. No. 13/597,911 entitled, “Vehicle Management System”, U.S. patent application Ser. No. 13/597,991 entitled, “Modular Robotic Manipulation”, U.S. patent application Ser. No. 13/598,021 entitled, “Graphical Rendition of Multi-Modal Data, and U.S. patent application Ser. No. 13/598,114 entitled, “Universal Payload Abstraction, all of which filed on Aug. 29, 2012.

BACKGROUND OF THE INVENTION

1. Field of the Invention
Embodiments of the present invention relate, in general, to computer and software architecture and more particularly to systems and methods to facilitate robotic behaviors through an underlying framework of asynchronously updated data streams.
2. Relevant Background
Robots have the potential to solve many problems in society by working in dangerous places or performing jobs that no one wants. One barrier to their widespread deployment is that they are mainly limited to tasks where it is possible to hand-program behaviors for every situation they may encounter. Simply stated, existing robots do not make behavioral decisions. For example, a child as it grows is subjected to numerous learning environments in which the behavioral outcome is supplied. For example, a parent or teacher informs the child how to respond based on their experience or societal norms. Eventually, and as the child matures, it applies these prior experiences to make new behavioral decisions on entirely new environmental situations. Behavior based robotics attempts to provide a robotic system with similar cognitive abilities.
It has been a long established goal and challenge to artificially model human intelligence. One early approach to solving this task is to first build a model of the environment and then explore solutions abstractly before enacting strategies in the real world. This approach places emphasis on symbolic representation and while to a human designer such an approach makes conceptual sense, to a robot which has little or no autonomy, it has little applicability.
One architecture associated with behavior based robotics is known as Subsumption. Subsumption architecture is a reactive robot architecture that decomposes complicated intelligent behavior into many “simple” behavior modules. Each of these behavior modules are in turn organized into layers wherein each layer implements a particular goal and wherein higher layers are increasingly abstract. Each layer's goal subsumes that of the underlying layers, e.g. the decision to move forward by the “eat-food layer” takes into account the decision of the lowest “obstacle-avoidance layer.” Thus subsumption architecture uses a bottom-up design. The general idea is that each behavior should function simultaneously but asynchronously with no dependence on the others. This independence theoretically reduces interference between behaviors and prevents over complexity.
In such an approach, each layer accesses all of the sensor data and generates actions for the actuators for the robot with the understanding that separate tasks can suppress inputs or inhibit outputs. By doing so the lowest layers can act as-adapting mechanisms (e.g. reflexes), while the higher layers work to achieve the overall goal.
Another robotic architecture known in the prior art is the Autonomous Robot Architecture (AuRA). This architecture is a hybrid deliberative/reactive robot architecture. Actions that must mediated by some symbolic representation of the environment are often called deliberative. In contrast, reactive strategies do not exhibit a steadfast reliance on internal models, but place a role of representation of the environment itself Thus, reactive systems are characterized by a direct connection between sensors and effectors. Control is not mediated by this type of model but rather occurs as a low level pairing between stimulus and response.
Structured tasks with predictable outcomes are best suited for a deliberative approach while environmentally dependent task are better suited to the reactive model. Reactive strategies do not exhibit a steadfast reliance on internal models, but displace some of the role of representation onto the environment itself And instead of responding to entities within a model as is with a deliberative model, the robot can respond directly to perception of the real world. Reactive systems therefore exhibit a direct connection between sensors and effectors and are best applied in complex, real-world domains where uncertainty cannot be effectively modeled.
Some behavior-based strategies use no explicit model of the environment but for more complicated domains it is necessary to find an appropriate balance between reactive and deliberative control.
Increasingly, researchers have abandoned the quest for high-level cognition and instead begun to model lower animal activity. Biology serves not only as inspiration for underlying methodologies, but also for actual robot hardware and sensors. For example, a simple household fly navigates using a compound eye comprised of 3,000 facets which operate in parallel to monitor visual motion. In response, an artificial robot eye has been constructed with 100 facets that can provide a 360-degree panoramic view. In another example, artificial bees have been crafted to simulate the dance patterns and sounds of real bees sufficiently well to actually communicate with other bees.
As conceived by one artificial intelligence researcher, “cognition is a chimera contrived by an observer who is necessarily biased by his/her own perspective on the environment. Cognition, as it is a subjective fabrication by an observer, cannot be measured or modeled scientifically.” Accordingly, the development of an artificial intelligence capable of cognition remains a challenge. While it remains debatable whether a machine can truly become cognitive, it is generally agreed that a bottom up behavioral approach lays the foundation for all artificial intelligence and a basis for future research. Therefore, a challenge remains to develop and implement a bottom up behavioral architecture that can be both deliberate and reactive in response to a multitude of sensory inputs. These and other challenges of the prior art are addressed by one or more embodiments of the present invention.

SUMMARY OF THE INVENTION

An architecture and associated methodology for asynchronous robotic behavior is described hereafter by way of example. An architecture comprising a hardware layer, a data collection layer and an execution layer lays the foundation for a behavioral layer that can asynchronously access abstracted data. A plurality of data sensors asynchronously collect data which is thereafter abstracted so as to be usable by one or more behavioral modules. Each of the behaviors can be asynchronously executed as well as dynamically modified based on the collected abstracted data.
According to one embodiment, behaviors are associated with one of two or more hierarchal behavioral levels. Should a conflict arise between the execution of two or more behaviors, the behavioral outcome is determined by behaviors associated with a higher level arbitrating over those associated with lower levels.
Another feature of the present invention rests in the architecture's ability to support modular behavioral modules. Unlike robotic architectures of the prior art, the present invention provides an architecture in which data collected by a variety of sources is simultaneously available to a plurality of behaviors. For the purpose of the present invention, a behavior is a process by which a specific output is achieved. A behavior may be to identify a target based on a thermal image or it may be to move the robot without hitting an obstacle. Clearly each of these tasks or behavior requires different data, however, the sensors that collect the data may be common. Using the embodiments of the present invention data collected by, for example, a thermal sensor, can be used by both behaviors. The data is collected and processed to a form so that both behaviors can have equal asynchronous access. Moreover, the data remains available to other behavior modules that may yet to be connected to the robotic platform. In such a manner the operation of the sensors, processors and behaviors can all operate independently and efficiently.
The behavior engine of the present invention provides a safe reliable platform within onboard intelligence that enables reactive, dynamic and deliberate behaviors. Using an independent asynchronous data collection process, recursive sensor maps can be customized to allow access to data abstractions at multiple levels. Such abstracted data can be used by multiple behavior modules on multiple levels while still providing the ability to dynamically modify the behavioral outcomes based on collected data.
The features and advantages described in this disclosure and in the following detailed description are not all-inclusive. Many additional features and advantages will be apparent to one of ordinary skill in the relevant art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter; reference to the claims is necessary to determine such inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

The aforementioned and other features and objects of the present invention and the manner of attaining them will become more apparent, and the invention itself will be best understood, by reference to the following description of one or more embodiments taken in conjunction with the accompanying drawings, wherein:

FIG. 1 shows an abstract block diagram depicting component layers of an asynchronous data streaming framework according to one embodiment of the present invention;

FIG. 2 presents a high level block diagram for a framework for asynchronous data streaming according to one embodiment of the present invention;

FIG. 3 is a high level block diagram showing general behavior abstraction according to one embodiment of the present invention;

FIG. 4 is more detailed rendition of the behavior abstraction diagram of FIG. 3 with example behaviors and abstractions according to one embodiment of the present invention;

FIG. 5 is a high level block diagram of an example of behavior orchestration using one embodiment of asynchronous data streaming according to the present invention;

FIG. 6 is a flowchart showing one method embodiment of the present invention for asynchronous data streaming according to one embodiment of the present invention.

The Figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.

DESCRIPTION OF THE INVENTION

An architecture for asynchronous robotic behavior is hereafter disclosed by way of example. The asynchronous architecture of the present invention provides an underlying framework for the application and utilization of asynchronously collected and updated data streams. Asynchronously collected data is abstracted and thereafter provided to a plurality of behavior modules. These modules are combined to form behavior suites which can thereafter be asynchronously executed. These behavior suites operate in what is referred to as a behavior layer that operates on top of a core architecture. The core architecture combines hardware, data collection and execution layers to form a foundation on which a plurality of distinct behaviors can operate.
Embodiments of the present invention are hereafter described in detail with reference to the accompanying Figures. Although the invention has been described and illustrated with a certain degree of particularity, it is understood that the present disclosure has been made only by way of example and that numerous changes in the combination and arrangement of parts can be resorted to by those skilled in the art without departing from the spirit and scope of the invention.
The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of exemplary embodiments of the present invention as defined by the claims and their equivalents. It includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted for clarity and conciseness.
Included in the description are flowcharts depicting examples of the methodology which may be used to asynchronously execute robotic behavior. In the following description, it will be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by computer program instructions. These computer program instructions may be loaded onto a computer or other programmable apparatus to produce a machine such that the instructions that execute on the computer or other programmable apparatus create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable apparatus to function in a particular manner such that the instructions stored in the computer-readable memory produce an article of manufacture, including instruction means that implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operational steps to be performed in the computer or on the other programmable apparatus to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.
Accordingly, blocks of the flowchart illustrations support combinations of means for performing the specified functions and combinations of steps for performing the specified functions. It will also be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.
The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the invention. Accordingly, it should be apparent to those skilled in the art that the following description of exemplary embodiments of the present invention are provided for illustration purposes only and not for the purpose of limiting the invention as defined by the appended claims and their equivalents.
Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information. By the term “substantially,” it is meant that the recited characteristic, parameter, or value need not be achieved exactly, but that deviations or variations, including for example, tolerances, measurement error, measurement accuracy limitations and other factors known to those of skill in the art, may occur in amounts that do not preclude the effect the characteristic was intended to provide
As used herein any reference to “one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).
In addition, use of the “a” or “an” are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.
Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for a system and a process for asynchronous robotic behavior through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.
The behavior-based approach of the present invention is applicable for use in a wide variety of areas, including military applications, mining, space exploration, agriculture, factory automation, service industries, waste management, health care, disaster intervention and the home. To better understand the novelty of the present invention and what behavior-based robotics is, it may be helpful to explain what it is not. The behavior-based approach does not necessarily seek to produce cognition or a human-like thinking process. While these aims are admirable, they can be misleading. While it is natural for humans to model their own intelligence, humans are not aware of the myriad of internal processes that actually produce our intelligence.
A fundamental premise of the behavior-based approach is that sophisticated, high-level behavior can emerge from layered combinations of simple stimulus-response mappings. Instead of careful planning based on modeling, high-level behavior such as flocking or foraging can be built by blending low-level behaviors such as dispersion, aggregation, homing and wandering. Strategies can be built directly from behaviors, whereas plans must be based on an accurate model.
In the architectural style according to one or more embodiments of the present invention, behaviors are arranged into simple, asynchronous layers, each of which corresponds to a task. Higher layers equate to higher-level tasks, and each has the ability to override and interact with children (lower) layers. According to one embodiment of the present invention, behaviors are synchronous and arranged in a tree structure, allowing multiple tasks to occupy the same level or priority. Higher behaviors arbitrate the actions requested by each sub-behavior rather than subsume the lower-level behaviors as has been practiced in the prior art.
The subsumption architecture of the prior art gives each behavior direct, synchronous access to sensors, which the behaviors use to make reactive decisions. The architecture of the present invention also provides access to data collected from the sensors, but it is gathered asynchronously and transformed by a process to abstract the data into a more useful format. Moreover, in the present solution, the data from the sensors can be passed and handled by any of a plurality of behaviors and can be used with different levels of abstraction in different places. Behaviors in the present architecture are not limited to be reactive; they may indeed be dynamic or deliberate. Furthermore, the output of one or more behaviors can be the input to another behavior.
One or more embodiments of the present invention provide a synchronous behavior hierarchy (tree structure) wherein higher-level behaviors arbitrate outputs and requested actions from lower-level behaviors. Behavior modules make decisions from abstracted sensor information that is collected asynchronously and abstracted based on the distinct needs of individual behaviors. The same sensor data can be abstracted differently for other distinct behaviors.
FIG. 1 presents a high level block diagram for a framework for asynchronous data streaming according to one embodiment of the present invention. Five (5) layers comprising a framework 100 for asynchronous data streaming include a hardware layer 110, a data collection layer 130, an execution layer 150, and a behavioral layer 170. As shown, the hardware layer 110 is also associated with a plurality of sensors 115. As one of reasonable skill in the relevant art will appreciate, the depiction shown in FIG. 1 is illustrative only. In other embodiments of the present invention, more or less layers providing additional or less functionality can be included. Indeed, the present labeling of the layers shown in FIG. 1 are arbitrary and merely illustrative.
In a subsumption architecture, complicated intelligent behavior is decomposed into many simple behavior modules that are in turn organized into layers. Each layer implements a particular goal of the agent with each higher layer being increasingly abstract. Each layer's goal subsumes that of the underlying layers, thus the name of the architecture. Like the present invention, subsumption architecture is a bottom up design.
In a subsumption architecture, each horizontal layer can synchronously access all of the sensor data and generate reactive actions for the actuators. However, separate tasks can suppress (or overrule) inputs or inhibit outputs. Thus, the lowest layers work like fast-adapting mechanisms while the higher layers work to achieve an overall goal.
The architecture of the present invention invokes the same bottom up structure and each layer can access sensor data but the data is gather asynchronously. Moreover, data in the present invention is made more versatile by an abstraction process. By doing so, the data is placed into a format that can be utilized by a number of different behavior modules simultaneously. Data can also be used with different levels of abstraction in a variety of different locations and, according to one embodiment of the present invention, behaviors associated with the architecture for asynchronous data streaming are not limited to being reactive but are also dynamic and/or deliberate. Behaviors of the present invention are synchronous and arranged in a tree structure, allowing multiple tasks to occupy the same level or priority. Higher behaviors arbitrate the actions requested by each sub-behavior rather than subsume the lower-level behaviors.
Turning back to the architecture for asynchronous data streaming shown in FIG. 1, a behavior layer 170 can be comprised of a plurality of different behavior modules each of which can asynchronously access the data 130 collected by plurality of sensors 115 associated with the plurality of hardware modules 110.
To better understand the organization of the present invention and of the architecture for asynchronous data stream, consider the high-level block diagram shown in FIG. 2. FIG. 2 shows a behavior engine 280 asynchronously receiving inputs from a plurality of behavior modules 270, a plurality of data modules 230, and a plurality of hardware modules 210. According to another embodiment of the present invention, the behavior engine 280 also incorporates input from an operator interface 240. The behavior engine 280 enables various behavior modules to arbitrate actions and tasks requested by any sub-behavior or behavior of an equal level.
Each hardware module 210 is coupled to a physical sensor or other input device and collected data asynchronously from other hardware modules. Thus, a plurality of hardware modules and sensors interact to provide a web of data that can be asynchronously accessed by the behavior modules 270. Moreover, the hardware modules not only are responsible for data collection but also report on whether a specific type of hardware exists and whether the data that is collected is valid. In essence, the hardware modules read data from the corresponding physical hardware sensor or some other type of input device and access its validity. These hardware devices can operate autonomously or be tied to a direct input from a system operator of another component. According to another embodiment of the present invention the hardware modules can operate on a variety of communication mediums such as radio, Internet, USD, and the like. Each hardware module runs in parallel and asynchronously thus allowing data to be collected at a speed that is optimized for the underlying hardware in the overall computing environment.
The data modules 230 gain data from each hardware module 210 as well as from other data modules 230 and prepare a high level abstraction of the data that can be later used by all of the behavior modules 270. Each data module 230 runs independently or asynchronously from each other unrelated data module. According to one embodiment of the present invention, data modules 230 are organized into a directed graph architecture in which individual modules can either push or pull data depending on the environment in which they are operating. Accordingly, each data module represents a specific abstraction of the data. The directed data graph is formed by establishing higher-level data modules as an aggregation of a set of lower-level data modules. The abstraction of data is accomplished by data manipulation to achieve its proper and specified format. Abstraction processing is performed asynchronously with any other type of data or hardware module thus removing any unnecessary alliance between or among unrelated modules.
Behavior modules of the present invention make informed decisions as to what actions take place using the data continuously shared by the data modules. Thus the behavior modules 270 leverage the information gained by the data modules 230. Since the underlying data collection is asynchronous in nature, the speed at which the behavior modules execute is not constrained by the speed of data collection, abstraction, and interpretation. According to one embodiment of the present invention, behaviors are organized into a hierarchy, where additional inputs to each behavior module may be the action or set of actions suggested by lower-level behaviors. However, each behavior module is designed in such a way that it remains encapsulated and does not require higher-level behaviors to operate.
The data modules arbitrate amongst themselves and among sub-behaviors to determine which action should take place. While there is a tree hierarchy among the behaviors, that is there are behaviors and sub-behaviors, the behaviors at the same level possesses equal priority and thus arbitrate among themselves to determine a course of action.
Sensor modules (not shown) which are associated with the hardware module 210 shown in FIG. 2, operate asynchronously to collect and push data to the data modules 230. Once the data is received by the data modules 230, it is abstracted so that it can be equally accessed and utilized by a plurality of behavior modules 270.
The asynchronous architecture of the present invention decouples the collection of data from one or more behaviors seeking a particular type of data. The embodiments of the present invention enable data to be gathered at an optimal rate based on sensor or hardware capability. Each sensor/hardware module operates independently. Accordingly, each behavior can operate at its maximum frequency and capability since it is not slowed by any sensor processing or data delay. And unlike the architectures of the prior art, the asynchronous architecture of the present invention enables behaviors to be incorporated, modified, or removed freely without requiring any changes to the processes and procedures necessary for the gathering of information, as each sensor or hardware module runs independent of the behavior modules. Through the data collected by the hardware modules 210 is independent of the data modules 230 and the behavior modules 270 the data can be stored in a shared data structure making it unnecessary to maintain redundant copies of the data. And as each behavior module, data module, and hardware module operate independently each can run on different processing units or computers based on their individual, computational requirements. As one of ordinary skill in the relevant art will appreciate, the various embodiments of the present invention and the asynchronous architecture for data streaming described above enhances the flexibility and capability of autonomous robotic behavior.
FIG. 3 is a high level hierarchal depiction of the asynchronous data streaming architecture of the present invention. Mission logic 370 is achieved after the arbitration of a plurality of behaviors 340, 350 which asynchronously receive and process abstract data collected by plurality of sensors 310, 315. Each behavior 340, 350 can equally access and utilize various tiers of abstract data 320, 325, 330, 335, which are collected by a plurality of hardware sensors 310, 315. Each tier of abstract data 320, 325, 330, 335 modifies/transforms the data so that may be universally used by one or more behaviors 340, 350.
For illustration purposes, consider the hierarchal structure shown in FIG. 4. FIG. 4 is a depiction of an asynchronous data streaming architecture for achieving a mission logic 470 of “follow target.” As can be seen the architecture includes a plurality of sensors 210, the data collected by each of the sensors 230 and a plurality of behavior modules 270 each of which has its individual capability and task. In this example, two separate range sensors 410, 415 provide data for the various behavior modules. The data collected by the range sensors is abstracted by a plurality of methods so as to provide a variety of tiers of data that can be accessed by the various modules. For example, the 1st tier of data is Filtered Range Data 420 while the second tier of data is an Ego Centric Map 425. In addition, Occupancy Grid 430 and a Change Analysis Map 435 is also provided. Each of these tiers of abstracted data is formed from the raw data collected by the range sensors 410, 415.
The various tiers of data, also referred to herein as data modules or data collection modules 230, are equally accessible by each behavior module. In this example the Guarded Motion Module 440 accesses the Ego Centric Map tier 425 to make its determination or recommendation for action. Likewise, the Obstacle Avoidance module 442 seeks data from the Ego Centric Map data tier 425. Similarly, the Follow Path module 444 and the Identify Laser Target module 446 access data from the Occupancy Grid data tier 430 and the Change Analysis Map data tier 435, respectively. The Plug-in Behavior modules do not access abstract data from the range sensors 410, 415 at all. The Visual Target behavior module 448 and the Thermal Target Identification module 450 operate independently of the data collected from the range sensors 410, 415.
One of reasonable skill in the relevant art will appreciate that each and every behavior module 440, 442, 444, 446, 448 and 450 can equally access each and every tier of abstract data 420, 425, 430, 435 asynchronously. Moreover, each behavior module is not limited to access to only one data tier. For example, the Follow Path module 444 accesses data from the Occupancy Grid tier 430. While the Follow Path Module 444 only accesses a single abstract data tier it could easily access other data tiers such as the Ego Centric Map 425 or the Filtered Range Data 420. Just as two modules, the Thermal Target Module 450 and the Visual Target Identification module 448, do not access any of the data tiers, any behavior module can access any abstract the data tier as necessary.
The depiction in FIG. 4 shows that each behavior module is provided with data necessary to make its recommendation for an action determination. Each is equally situated to provide input to the mission logic, which in this case is to follow a target. In cases in which the action of one or more modules conflict, the actions are arbitrated to arrive at the desired outcome.
FIG. 4 also shows an overlay of the model architecture shown in FIG. 2 to give the reader a better appreciation for how the various modules interact in arriving at ignition module. In this example, the range sensors 410, 415 are two examples of hardware modules 210. The four tiers of data including Filtered Range data 420, Ego Centric Map data 425, Occupancy Grid data 430, and Change Analysis Map data 435 are modules of collected data 230. Lastly the behaviors including Guarded Motion 440, Obstacle Avoidance 442, Follow Path 444, Identify Laser Target 446, Target Visual Identification 448, and thermal target identification 450 are all behavior modules 270. And while not shown, the behavior module 280 arbitrates the various inputs or action recommendations generated by each behavior module.
Another aspect of the present invention is unique ability to specify and reconfigure behavior orchestration. According to one embodiment of the present invention, the asynchronous architecture described herein enables a mission logic/output to be specified as a unique combination of a plurality of behaviors, sensors, and behavior parameters. As the behavior modules of the present invention are modular and operate independently and mission logic or mission objective can be identified and formed as a combination of these independent modules. The present invention then seeks and incorporates hardware/sensors, abstract data, and various mission behavior outcomes to arrive at the mission logic objective. In this manner, a behavior engine provides a means to optimize the mission behavior dynamically by changing input parameters to the various behavior modules so as to interpret and to respond to various collected data and user input.
Suites of behaviors can also be compiled as separate libraries that can each be customized and distributed to different platforms and/or utilized on different missions while maintaining the same core behavior architecture. Accordingly, the core architecture remains unchanged over various application layers/behaviors that can be continually, and dynamically customized, repackaged and distributed. The asynchronous architecture of the present invention provides cross-application platform technology that is dynamically reconfigurable such that a behavior or outcome can be prioritized based on decision logic embedded in one or more of the behavior modules. A top-level function or behavior module of the overall mission architecture to provide as a means by which prioritize different behavior outcomes and, as described herein, use as the basis to arbitrate between conflicting behavior directives. In essence, each application-centric layer cake uses the same basic behavior modules (modular and reusable modules) but orchestrates these individual behavior modules differently using unique behavior composition and prioritization specifications. By doing so, a user through what is referred to herein as a user control unit or user interface can change behavior goals dynamically and thus reconfigure the mission logic to arrive at the desired optimization and outcome.
FIG. 5 presents a high-level interaction block diagram of an illustrative arbitration process by which a mission logic/outcome is comprised of a plurality of individual/modular behavior inputs. As shown, behavior engine 510 possesses predetermined behavior outcomes or receives a mission logic outcome from a user via a user control unit 575. As illustrated in FIG. 5, the user control unit 575 can be communicatively coupled to the behavior engine 510 via a radio link 570. The behavior engine 510 issues logic directives to a variety and plurality of behavior modules 520, 530, 540, 550, 560 to assemble behaviors based, in one embodiment, on the use of distance and heading cues. By using standard inputs such as heading and distance the behavior engine can provide overall behavior orchestration. In the example depicted in FIG. 5 a behavior engine 510 communicates directly to a Wander module 540 and a Follow module 530. The behavior engine 510 also communicates to the Follow module 530 and a Way Point Traverse module 520 via a Shared Control module 515. The output of the Wander module 540, the Follow module 130, and a Way Point Traverse module 520 is supplied as input to an Avoid module 550 which in turn provides an output to a Guarded Motion module 560. The Follow module 530 and a Way Point Traverse module 520 each receive heading information from the behavior engine 510. This heading information may, in this example, be a general direction which the user wishes the robotic device to traverse.
Using the basic input of heading the Follow module 530 and a Way Point Traverse module 520 provide the Avoid module 550 an initial heading, desired speed and distance. The Follow module 530 (also referred to herein as target follow or lead/follow) can function in tandem (parallel) with the Way Point traverse module 520 (or other modules) to calculate a path to the target or to specific targets along a path. The Way Point module 520 (also sometime referred herein to as the path follow module) receives a heading input from the Shared Control module 515 and uses a control loop to direct a specific robot heading so as to maintain its position on a path. These heading directives can either be waypoint-based (where there are individual intermittent waypoints) or track-based (where the path is a continuous curve or line. The arbitration between path following and target following is accomplished by the Behavior Engine behavior at the top level. The Shared Control module 515 is a behavior element that modifies heading as an input to Way Point Traverse module 520 and the Follow module 530. This allows an external planner (user) to influence or assume control from the path following or target following behavior. The extent of the heading change and the decision to either assume or augment the heading input is calculated within the Shared Control module 515.
The Wander module 550 provides no heading information but nonetheless provides the Avoid module 550 with a general plan for surveying a general area. The Wander module 550 provides a means by which to explore as well as sort out challenging situations in which the device has failed to achieve established goals or directives of the Behavior Engine 510 in terms of a specific traverse. For example, a failure for the device to traverse a desired path, to make progress toward a certain target, or accept user input can be addressed by wandering to some degree. The Behavior Engine 510 remains responsible for directing a “Wander” behavior as it may impact the object's activity. Wandering provides an element of randomness or resourcefulness that can be useful in a cluttered or highly dynamic environment in which deterministic path following or directive headings are ineffective.
Inputs from the various and independent behavior modules are used by the Avoid module 550 to determine a suitable output. Presumably, the Avoid module 550 has certain predefined or user input locations in which the robot is to avoid. Essentially, the Avoid module reactively navigates around either static or dynamic obstacles that may not have been accounted for in other behavior elements. As described hereafter, these obstacles can be also identified using an active position tag. Thus the inputs of desire heading, distance, and speed are used and processed by the Avoid module 550 to provide a direction of traverse that both meets mission objectives and the avoidance criteria.
Finally, the output of the Avoid module 550 is provided as input to a Guarded Motion module 560. The Guarded Motion module 560 ensures that there are no collisions. While the Behavior Engine 510 has little input into the Guarded Motion module 560, it can turn it on or off as well as determine the acceptable distances used as safety buffers between the object (robot) and various other objects (e.g. people, vehicles, plants, walls, etc.). In this example, the Guarded Motion module 560 may also prevent the robotic device from exceeding a particular angle orientation on a hill so that it will not tip over, speed, or any other motion that would jeopardize the success and/or wellbeing of the platform. The Guarded Motion module thereafter produces an output sent back to the Behavior Engine 510 for comparison with the overall mission objective. If the mission objective and the output of the Guarded Motion module 560 are aligned the Behavior engine 510 provides commands to the drive mechanism 580 which correspondingly turns the wheels 590 or acts on a similar device.
The Behavior Engine 510, in combination with the asynchronous architecture of the present invention, enables modular behaviors to modify collective outcomes so as to meet an overall mission objective. The Behavior Engine 510 uses heading, distance and a plurality of other parameters to arbitrate between different lower level behavior elements such as those produced by the Follow module 530, Way Point Traverse module 520, Wander module 540, Shared Control Module 515, Guarded Motion Module 560 and the Avoid module 550. The Behavior Engine 510 does this, in one embodiment, by modifying the heading and distance inputs that go into each behavior to arrive an an optimal result that yet meets mission objectives. Alternatively, the Behavior Engine 510 can also completely turn off an individual behavior element in which case, no execution of that behavior occurs. Moreover, the Behavior Engine 510 can also execute two or more behaviors in parallel and then, based on the outputted heading and distance, decide how to select between the competing outputs, or, in an different embodiment, combine them in some meaningful way. It is also possible to assign specific prioritization to individual active positioning tags so that certain tags (e.g. a hazard tag or avoid tag) have a defined priority over other tags (e.g. a follow tag). In this manner the Behavior Engine 510 allows for the orchestration of behaviors to be in part dependent on a mission level behavior specification but also use tag prioritization to influence behavior coordination.
Assume for example, and as illustrated above, that an operator communicated to the particular platform a desired outcome or goal to reposition a robotic device from one point to another. Prior to that input the platform had possessed a general directive to scan and survey a particular geographic region using the Wander module 540. Thus, the new directive provided new direction or goals dynamically that would modify the implementation of the currently operational behavior modules. In this case the wander module 540 was the lowest priority or mission objective and whose output may be modified by the new mission objective.
The new directive to move from one point to another required the Follow module 530 and a Way Point Traverse module 520 to produce a specific heading, speed, and distance. It is possible that the same heading, speed, and distance matched that which had been output by the Wander module 540. Alternatively, the heading, speed and distance would not conflict with the Wander module output. However, should there be a conflict the output of the Follow module 530 and a Way Point Traverse module 520 would override that of the Wander module 540. Thus, the Follow module 530 and a Way Point Traverse module 520 would be viewed as being in a higher layer than the Wander module 540.
Another layer higher than all previous modules would be the Avoid module 550. This module ensures that the robotic platform avoids certain predetermined or communicated positions or hazards as identified by onboard sensors. For example, perhaps an onboard sensor identifies a thermal hot spot (fire) that should be avoided or a wireless communication conveys the precise location of an explosive device. The Avoid module 550 would avoid these positions. And lastly, the Guarded Motion module 560 is yet another, and higher, layer than even the Avoid module 550. This module may, for example, guard the platform from certain types of motion that would jeopardize its safety. Each module described herein accesses abstract and asynchronously collected data simultaneously to determine the optimal outcome for that particular module.
Once each module has determined its optimal outcome based on required input data, that being either supplied by another behavior module or data that has been asynchronously collected by one or more sensors, the architecture of the present invention arbitrates the outcomes based on a hierarchal structure determined by the overall mission objective. The behavior engine 510 thereafter compares the recommended course of action based on the arbitrated behaviors of one or more behavior modules to that of the overall mission objective to confirm that the recommended course of action is in compliance with the overall mission objective. Once the directed course of action is confirmed by the behavior, is it is thereafter conveyed to various hardware and logic components to implement commands.
One of reasonable skill in the relevant art will recognize that the example presented above and is depicted in FIG. 5 is only one possible combination of a variety and plurality of modular behavior modules that can be implemented according to a hierarchical architecture using asynchronously collected data. Another aspect of the present invention is the use of one or more active position ultra wide band (UWB) transceivers or tags. These ultra wide-band (UWB) radio frequency (RF) identification (ID) tag systems (collectively RFID) comprise a reader with an antenna, a transmitter, and software such as a driver and middleware. One function of the UWB RFID system is to retrieve state and positional information (ID) generated by each tag (also known as a transponder). Tags are usually affixed to objects so that it becomes possible to locate where the goods are without a direct line-of-sight given the low frequency nature of their transmission. A tag can include additional information other than the ID. For example, using triangulation of the tag's position and the identity of a tag, heading and distance to the tag's location can be ascertained. A single tag can also be used as a beacon for returning to a specific location or carried by an individual or vehicle to affect a follow behavior from other like equipped objects. As will be appreciated by one of reasonable skill in the relevant art, other active ranging technology is equally applicable to the present invention and is contemplated in its use. The use of the term “UWB”, “tags” or “RFID tags,” or the like, is merely exemplary and should not be viewed as limiting the scope of the present invention.
In one implementation of the present invention, a RFID and/or UWB tag cannot only be associated with a piece of stationary infrastructure with a known, precise, position, but also provide active relative positioning between movable objects. For example, even if the two or more tags are unaware of their precise position that can provide accurate relative position. Moreover, the tag can be connected to a centralized tracking system to convey interaction data. As a mobile object interacts with the tag of a known position, the variances in the objects positional data can be refined. Likewise, a tag can convey not only relative position between objects but relative motion between objects as well. Such tags possess low-detectability and are not limited to line of sight nor are they vulnerable to jamming. And, depending on how mounted and the terrain in which they are implemented, a tag and tracking system can permit user/tag interaction anywhere from 200 ft to 2-mile radius of accurate positioning. Currently, tags offer relative position accuracy of approximately +/−12 cm for each interactive object outfitted with a tag. As will be appreciated by one or reasonable skill in the relevant art, the use of the term object is not intended to be limiting in any way. While the present invention is described by way of examples in which objects may be represented by vehicles or cellular telephones, an object is to be interpreted as an arbitrary entity that can implement the inventive concepts presented herein. For example, an object can be a robot, vehicle, aircraft, ship, bicycle, or other device or entity that moves in relation to another. The collaboration and communication described herein can involve multiple modalities of communication across a plurality of mediums.
The active position tags of the present invention can also provide range and bearing information. Using triangulation and trilateration between tags, a route can be established using a series of virtual waypoints. Tags can also be used to attract other objects or repulse objects creating a buffer zone. For example, a person wearing a tag can create a 4-foot buffer zone which will result in objects not entering the zone to protect the individual. Similarly, a series of tags can be used to line a ditch or similar hazard to ensure that the object will not enter a certain region.
The process by which an asynchronous data can be used to, in one example, determine robotic behavior in accordance with an overall mission logic is further illustrated by the flowchart of FIG. 6. According to one embodiment of the present invention, a process by which to asynchronously provide data to a plurality of behavior modules begins with the collection of data 610. As has been previously described, data is collected asynchronously by a plurality of hardware modules or sensors but is used independently by behaviors. Said differently, behavior execution is independent of data collection. As the data is collected it is abstracted 620 and provided for asynchronous access by a plurality of behavior modules 640. According to one embodiment of the present invention, one or more behavior modules can be combined 670 to form what is referred to as a behavior suite. Behavior suites can then be treated either independently or in conjunction with other behaviors in the determination of a recommended action. And finally, the behavior suites are executed 680 to achieve the desired mission outcome.
The Behavior Engine of the present invention is a reusable behavior framework. Elements such as 3D mapping, position fusion calculations, guarded motion, obstacle avoidance, follow, path planning and path following represent behaviors which the behavior engine can implement to achieve mission objectives. These behaviors can also be combined. For example, guarded motion, obstacle avoidance, and reactive follow work together to form a primitive reactive behavior core. This core behavior can thereafter couple with reusable interfaces to achieve higher level of outcomes such as 3D mapping, path planning, hazards and path trajectories.
In such a manner reactive behaviors can be used across any object or vehicle or application. Moreover, the connectivity between reactive behaviors and application layer representations can be universal even when specific applications algorithms differ. For example, an implementation of these concepts may be vastly different but the core concepts will remain the same. The behavior engine manages basic handoffs between behaviors such as guarded motion, obstacle avoidance, follow, path planning and path following. While a follow algorithm may change (e.g. Akerman vs. skid steer) as may a follow algorithm (bread crumb follow vs. regular follow) the interplay between the behaviors remains the same.
The architecture of the present invention facilitates the development and implementation of modular robotic behaviors. By providing an underlying framework of asynchronously updated data streams that can be universally accessed by one more more behavior modules, the capabilities of a wide variety of robotic platforms can be modified and tailored to meet specific mission needs. Moreover, the same platform can be quickly modified using plug-and-play modules to provide new capabilities without having to modify the the collection and preparation of sensor data. Modules can be interchanged between platforms with confidence that each platform will provide to the newly incorporated module the information it needs to accomplish its mission.
The core architecture of the present invention comprised of the hardware layer, the data collection layer and the execution layer enables behaviors associated with the behavior layer to operate independently and to be modified dynamically. Asynchronously collected data is abstracted so as to be useable by a plurality of data modules simultaneously. Moreover, the use of a set of abstracted data by one behavior module is completely independent of the simultaneous and continuous use of the same data, albeit abstracted differently, by a different behavior module.
The architecture of the present invention also enables behavior modules to be dynamically modified responsive to collected data. Should data indicate that the current parameters of a particular behavior are not compatible with the overall mission objective based on the collected data, the parameters can be modified without modifying the data collection means or processing. Once the module has been modified it can again access the collected data to initiate a responsive action.
In situations in which two or more actions developed by behaviors of the same hierarchal level conflict, a resolution is reached as to which behavior should be applied based on desired higher level behavioral outcomes. The architecture and associated methods of the present invention provide a significant advance over the prior art and address many of the challenges in robotic behavioral control.
As will be appreciated by one skilled in the relevant art, one preferred means of implementing the present invention is in a computer system as software, hardware or a combination thereof. These implementation methodologies are known within the art and the specifics of their application within the context of the present invention will be readily apparent to one of ordinary skill in the relevant art in light of this specification and as described below.
For example, one more embodiments of the present invention may be implemented in a computer system as a program of instructions executable by a machine. In such an implementation, the program of instructions may take the form as one or more program codes for collection data asynchronously, abstracting the data, accessing the abstracted data asynchronously by one or behavior modules and then code for executing the modules.
Some other possibilities for implementing aspects of the systems and methods include micro-controllers with memory (such as electronically erasable programmable read-only memory (EEPROM)), embedded microprocessors, firmware, software, etc. Computer-readable media in which instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) and carrier waves that may be used to transfer such formatted data and/or instructions through wireless, optical, or wired signaling media or any combination thereof.
As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the modules, managers, functions, systems, engines, layers, features, attributes, methodologies, and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions, and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the modules, managers, functions, systems, engines, layers, features, attributes, methodologies, and other aspects of the invention can be implemented as software, hardware, firmware, or any combination of the three. Of course, wherever a component of the present invention is implemented as software, the component can be implemented as a script, as a standalone program, as part of a larger program, as a plurality of separate scripts and/or programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims

We claim:

1. An architecture for asynchronous robotic behavior, comprising:

a hardware layer generating sensor data from a plurality of sensors wherein the plurality of sensors includes a plurality of ultra wide band (UWB) transceivers and wherein each of the UWB transceivers generates positional information;

a data collection layer wherein the data collection layer asynchronously collects sensor data from the plurality of sensors and thereafter abstracts the collected sensor data making abstract collected sensor data simultaneously available to each of a plurality of behaviors;

a behavior layer including the plurality of behaviors wherein the behavior layer dynamically prioritizes each of the plurality of behaviors based, in part, on positional information; and

an execution layer wherein the execution layer asynchronously and in parallel executes one or more of the plurality of behaviors responsive to behavior level prioritization.

2. The architecture for asynchronous robotic behavior of claim 1, wherein the collection of sensor data and prioritization of the plurality of behaviors is decoupled.

3. The architecture for asynchronous robotic behavior of claim 1, wherein the plurality of behaviors includes reactive behaviors and deliberate behaviors.

4. The architecture for asynchronous robotic behavior of claim 3, wherein the behavior layer dynamically prioritizes reactive and deliberate behaviors based on positional information.

5. The architecture for asynchronous robotic behavior of claim 3, wherein reactive behaviors are selected from a group consisting of guarded motion, collision avoidance and follow path behaviors.

6. The architecture for asynchronous robotic behavior of claim 3, wherein deliberate behaviors include follow path and way point traverse behaviors.

7. The architecture for asynchronous robotic behavior of claim 3, wherein the behavior layer continuously prioritizes each of the plurality of behaviors based on positional information.

8. The architecture for asynchronous robotic behavior of claim 1, wherein the execution layer executes a deliberate behavior until directed by the behavior layer to modify the deliberate behavior with a reactive behavior based on positional information.

9. The architecture for asynchronous robotic behavior of claim 8, wherein priority with respect to the reactive behavior and the deliberate behavior changes in response to a change in positional information.

10. The architecture for asynchronous robotic behavior of claim 8, wherein the reactive behavior is a guarded motion behavior.

11. The architecture for asynchronous robotic behavior of claim 1, wherein each of the plurality of behaviors is associated with a priority based on positional information and the priority changes in response to a change in positional information.

12. The architecture for asynchronous robotic behavior of claim 11, wherein the execution layer executes a deliberative behavior, and, responsive to the change in positional information, the execution layer merges the deliberative behavior with a reactive behavior possessing priority greater than the deliberative behavior.

13. The architecture for asynchronous robotic behavior of claim 12, wherein the deliberative behavior is a way point traverse behavior and the reactive behavior is an obstacle avoidance behavior.

14. The architecture for asynchronous robotic behavior of claim 12, wherein the deliberative behavior is a follow path behavior and the reactive behavior is an obstacle avoidance behavior.

15. The architecture for asynchronous robotic behavior of claim 12, wherein based on the change in positional information the deliberative behavior is modified to incorporate the reactive behavior.

16. A method for asynchronously executing robotic behaviors of an object, the method comprising:

collecting data asynchronously and in parallel from a plurality of sensors wherein the plurality of sensors includes a plurality of ultra wide band (UWB) transceivers and wherein each of the UWB transceivers generates positional information to determine a position of the object;

abstracting the collected data wherein the abstracted collected data is simultaneously available to each of a plurality of behavior modules, and wherein each behavior module is associated with a priority level that is continuously updated based on the position of the object;

arbitrating a conflict between two or more of the plurality of behaviors modules based on the priority level associated with each behavior module;

responsive to arbitrating the conflict between two or more of the plurality of behavior modules, merging the two or more of the plurality of behavior modules forming a merged behavior module; and

executing by the object the merged behavior module.

17. The method for asynchronously executing robotic behaviors according to claim 16, wherein the two or more of the plurality of behaviors modules include a reactive behavior and a deliberative behavior.

18. The method for asynchronously executing robotic behaviors according to claim 17, wherein the deliberative behavior is a way point traverse behavior and the reactive behavior is an obstacle avoidance behavior.

19. The method for asynchronously executing robotic behaviors according to claim 17, wherein the deliberative behavior is a follow path behavior and the reactive behavior is an obstacle avoidance behavior.