Patent Application
20160075014
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.
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.
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:
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.
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.
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
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
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
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.
For illustration purposes, consider the hierarchal structure shown in
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
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.
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
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
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.
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.
| Number | Date | Country | |
|---|---|---|---|
| 61529206 | Aug 2011 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13597791 | Aug 2012 | US |
| Child | 14941199 | US |
