Patent Application
20250042032
This disclosure relates to robot automation, and more particularly to techniques for ensuring safe execution of AI-generated robotic commands. This disclosure presents advanced techniques that utilize generative artificial intelligence (GAI) to generate safety-related semantics pertaining to ensuring safe robotic operation in dynamically-changing environments.
The state of machine learning had advanced to the point where even casual observers have access to technologically advanced machine learning models (e.g., large language models (LLMs)). Across a wide swath of technical endeavors, engineers and, in some cases, marketeers are wrestling with how LLMs (e.g., ChatGPT and other generative AI entities) and corresponding interfaces (e.g., conversational exchanges, application programming interfaces (APIs) etc.) can be used to ease the burden placed on human users when the users want to convert natural language statements (e.g., commands, objectives, mission statements, etc.) into a series of precise and interrelated steps. In certain domains corresponding to certain endeavors, LLMs are able to “break it down” into easily understood steps.
In specific endeavors involving robotics (or any sort of autonomous or semi-autonomous machinery), and irrespective of how an ordered series of steps is synthesized, there is always the looming question, “Is it safe to carry out this next step?” More particularly, since robots are operated by computers, the looming questions might be, “Given the choice of two obstacles in a path to a desired endpoint, which obstacle, if any, should I avoid,” and/or “Which obstacle can I safely move in order to proceed on a path to a desired endpoint?” and/or “Which obstacle can I safely collide with (or ignore) in order to proceed on a path to a desired endpoint?”
Typical non-LLM answers as well as naive LLM-provided answers to the first question often involve avoiding all obstacles. Typical non-LLM answers as well as naive LLM-provided answers to the second question often requires touching/moving some of the obstacles, but such naive LLM-provided answers do not give details for how to reach the desired endpoint or achieve some particular goal. As such, the robot is unable to achieve the stated objective. This is (at least) because the LLMs do not fully grasp the concept of safety and how the concept of safety changes relative to a dynamically-changing real-world environment.
One way to address the deficiency of LLMs in this regard is to not use the LLMs at all, however this fails to take advantage of the LLMs for their ability to bridge the chasm between high-level (e.g., human-issued) commands and the needed lower level (e.g., code or robot language) maneuvering steps.
Another way to address the deficiency of LLMs is to train LLMs on various safety-sensitized corpora, however this is often a non-starter due to the cost of such training and the vagaries of determining what constitutes (and how to access) the aforementioned safety-sensitized corpora.
What is needed is a way to address the foregoing deficiencies of LLMs as it pertains to safe operation of autonomous machinery. The problem to be solved is, therefore, rooted in various technological limitations of legacy approaches. Improved technologies are needed. In particular, improved applications of technologies are needed to address the aforementioned technological limitations of legacy approaches.
This summary is provided to introduce a selection of concepts that are further described elsewhere in the written description and in the figures. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Moreover, the individual embodiments of this disclosure each have several innovative aspects, no single one of which is solely responsible for any particular desirable attribute or end result.
The present disclosure describes techniques used in systems, methods, and computer program products for ensuring safe execution of AI-generated robotic commands and/or for ensuring the safe execution of robotic commands using safety semantics provided by an LLM. The various respective and herein-disclosed techniques advance the relevant technologies to address technological issues with legacy approaches. More specifically, the present disclosure describes techniques used in systems, methods, and in computer program products for transforming natural language (or computer markup language) output of LLMs to comport with safety constraints. Certain embodiments are directed to technological solutions for translating a language-based description (e.g., of an environment and/or of constituents therein) into robotic signals that comport with applicable safety constraints.
The disclosed embodiments modify and improve beyond legacy approaches. In particular, the herein-disclosed techniques provide technical solutions that address the technical problems that arise due to the deficiency of autonomous systems to ensure safe behavior while pursuing step-oriented tasks. Such technical solutions involve specific implementations (e.g., data organization, data communication paths, module-to-module interrelationships, etc.) that relate to the software arts for improving computer functionality.
The ordered combination of steps of the embodiments serve in the context of practical applications that perform steps for translating natural language into robotic signals that comport with dynamically feasible safety constraints. Such, techniques for translating natural language into robotic signals that comport with applicable safety constraints overcome heretofore unsolved technological problems associated with the inability of autonomous vehicles to ensure safe behavior while pursuing step-oriented tasks.
Many of the herein-disclosed embodiments for translating natural language into robotic signals that comport with applicable safety constraints are technological solutions pertaining to technological problems that arise in the hardware and software arts that underlie robot deployments. Aspects of the present disclosure achieve performance and other improvements in peripheral technical fields including, but not limited to, commanding robots using natural language and purpose-driven labeling of large language model output.
Some embodiments include a sequence of instructions that are stored on a non-transitory computer readable medium. Such a sequence of instructions, when stored in memory and executed by one or more processors, causes the one or more processors to perform a set of acts for translating natural language into robotic signals that comport with applicable safety constraints.
Some embodiments include the aforementioned sequence of instructions that are stored in a memory, which memory is interfaced to one or more processors such that the one or more processors can execute the sequence of instructions to cause the one or more processors to implement acts for translating natural language into robotic signals that comport with applicable safety constraints.
In various embodiments, any combinations of any of the above can be organized to perform any variation of acts for transforming natural language output of LLMs to comport with safety constraints, and many such combinations of aspects of the above elements are contemplated.
Further details of aspects, objectives and advantages of the technological embodiments are described herein and in the figures and claims.
The drawings described below are for illustration purposes only. The drawings are not intended to limit the scope of the present disclosure.
FIG. 8C1 depicts a block diagram of an interstitially situated supervisory agent, in accordance with some implementations.
FIG. 8C2 depicts a block diagram involving a human operator's safe manipulation of a robotic control system, in accordance with some implementations.
Aspects of the present disclosure solve problems associated with using computerized robot systems to ensure safe behavior while pursuing accomplishment of a robotic mission. Some embodiments are directed to approaches for translating natural language and/or high-level markup language into robotic signals that comport with applicable safety constraints. The accompanying figures and discussions herein present example environments, systems, methods, and computer program products for transforming natural language output of LLMs into robotic control signals that comport with safety constraints.
The present invention pertains to a safety supervisory agent designed to facilitate safe and efficient robot operations by interpreting high-level environment descriptions expressed in a natural language or markup language format, and then ensuring that only safe robotic commands are carried out. Traditional methods of robot control often require programming skills and extensive human intervention to ensure safety while pursuing specific tasks. This novel safety supervisory agent aims to bridge the gap between high-level intent and low-level execution, enabling robots to operate autonomously and safely, even in dynamic environments, and even in the absence of the aforementioned programming skills or ongoing human intervention.
The safety supervisory agent employs advanced natural language processing (NLP) techniques, leveraging cutting-edge machine learning algorithms to comprehend and extract the underlying meaning of human-provided high-level objectives. By parsing the input text, the system effectively translates ambiguous human language into clear and concise low-level safety specifications, encompassing actions, behaviors and constraints that the robot must adhere to throughout its operation. Various embodiments include the steps of (1) obtaining a high level objective, (2) processing the high level objective through a prompt builder, (3) providing the engineered prompt to an artificial intelligence entity, (4) interpreting the response of the artificial intelligence entity to the prompt, and (5) passing portions of the interpreted response to a supervisory agent.
To ensure the robot operates within safe boundaries while pursuing the desired objective, the supervisory agent incorporates state-of-the-art safety algorithms. These algorithms continuously analyze the robot's actions and environment, identifying potential risks and hazards. If any prescribed robotic action would violate any one or more safety constraints or otherwise pose a danger, the safety supervisory agent promptly intervenes, adjusting the robot's trajectory or halting its operation altogether to prevent accidents or damage to assets or damage to the robot itself.
The safety supervisory agent presented in this disclosure revolutionizes the way robots interact with their environments by using an artificial intelligence agent to translate knowledge of an environment and high-level constraints (e.g., expressed in natural language) into safety-conscious low-level action or avoidance specifications (e.g. robotic signals) that are carried out autonomously by a robot. Enabling robots to operate with a higher level of autonomy while nevertheless ensuring safety advances the technology facilitates widespread adoption of robots in various industries.
Selected features of this approach are given in Table 1.
Imagine a room where there is a miniaturized terrestrial vehicle (e.g., similar to a toy remote control car) sitting stationary on the ground. In this imaginary room, situate a camera in the corner of the imaginary room. Now, consider what happens when the “mission” is to get the miniaturized terrestrial vehicle to the other side of the room, in spite of the fact that there are two objects (both being detected by the camera imaging and post processing) in the room blocking a direct path. Using classical computer vision techniques, one object is identified as a vase, and the other one is a blanket.
Now, suppose we prompt a generative AI large language model (e.g. ChatGPT), “Given an environment of a room where there are two objects (specifically a vase and a blanket) blocking a direct path from where the miniaturized terrestrial vehicle is now to the other side of the room, how can the miniaturized terrestrial vehicle be controlled to get from where it is now to the other side of the room?” In this example, and given the foregoing prompt, the AI large language learning model responds, “To get the miniaturized terrestrial vehicle from where it is now to the other side of the room while avoiding the vase and the blanket, you can perform the sequence of steps as given in Table 2.” Additionally or alternatively, consider if the AI large language learning model was a multi-modal large language learning model, in which case the image of the room was provided to the large language learning model. In this case, the large language learning model would classify the objects, as well as provide safety analysis. Consider the sequence of steps given in Table 2.
When carrying out a conversation with a generative AI entity (e.g. one that employs one or more large language models), the AI entity can incorporate context that was garnered from previous prompts. As such, suppose that the AI entity is given the prompt, “Can you write me code that allows the miniaturized terrestrial vehicle to safely reach the other side of the room, yet still avoids damaging any potential obstacles?” The AI entity might be able to generate low-level commands that, as a whole, carry out the foregoing steps 1, 2, 3, and 4 of Table 2. The AI entity's might be pre-trained to provide highly detailed commands. Or, the AI entity might be pre-trained to output code (if requested). In some cases, an AI entity can be ‘forced’ to respond in a particular format (e.g., by providing a description of the particular format in a prompt). As such, when an AI large language model is prompted with a command, the LLM provides a high-level step-by-step response that comports with a particular format. For example, if during the conversation with the AI entity, such as when describing any aspects of the particular then-current environment to the LLM, the LLM can be commanded via a purposely contrived prompt to return results in a tabular format. Then in response to the purposely contrived prompt, “The mission is to get the miniaturized terrestrial vehicle to the other side of the room, and I need a tabularized step-by-step response, as well as an assessment and prioritization of the safety considerations of objects in the room” the AI entity might respond with all or portions of the steps/descriptions given in Table 3.
As can be seen, this second AI entity response as shown in Table 3 is at a lower level than the first AI entity response as shown in Table 2. Various approaches to achievement of a robotic mission can be expressed in varying degrees of abstraction, and the degree of abstraction can be controlled by prompt engineering. Moreover, the degree of abstraction in the “how to” steps given by an AI entity can be fine-tuned to facilitate transformation of the AI entity's “how to” steps into safe robotic control signals. For example, a “how to” step that carries the semantics of, “pick up the object” might be transformed into a safe robotic control signal that carries the semantics of, “pick up the object using no more than 1 Newton of force,” or “pick up the object only by the object's handle.”
Various techniques to transform an AI entity's “how to” steps into safe robotic control signals are shown and described with reference to various example embodiments.
Some of the terms used in this description are defined below for easy reference. The presented terms and their respective definitions are not rigidly restricted to these definitions-a term may be further defined by the term's use within this disclosure. The term “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the word exemplary is intended to present concepts in a concrete fashion. As used in this application and the appended claims, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or is clear from the context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A, X employs B, or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. As used herein, at least one of A or B means at least one of A, or at least one of B, or at least one of both A and B. In other words, this phrase is disjunctive. The articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or is clear from the context to be directed to a singular form.
Various embodiments are described herein with reference to the figures. It should be noted that the figures are not necessarily drawn to scale, and that elements of similar structures or functions are sometimes represented by like reference characters throughout the figures. It should also be noted that the figures are only intended to facilitate the description of the disclosed embodiments—they are not representative of an exhaustive treatment of all possible embodiments, and they are not intended to impute any limitation as to the scope of the claims. In addition, an illustrated embodiment need not portray all aspects or advantages of usage in any particular environment.
An aspect or an advantage described in conjunction with a particular embodiment is not necessarily limited to that embodiment and can be practiced in any other embodiment even if not so illustrated. References throughout this specification to “some embodiments” or “other embodiments” refer to a particular feature, structure, material, or characteristic described in connection with the embodiments as being included in at least one embodiment. Thus, the appearance of the phrases “in some embodiments” or “in other embodiments” in various places throughout this specification are not necessarily referring to the same embodiment or embodiments. The disclosed embodiments are not intended to be limiting of the claims.
The figure is being presented to illustrate how an improved processing flow might be configured to operate in systems that transform natural language robot commands into low-level commands or signals. More specifically, the figure is being presented to illustrate how the herein-disclosed techniques advance over legacy techniques.
Specifically, the left side of the figure presents a multi-step processing flow including the shown naive path 101. At the shown step 1 (left side of the figure), a robot mission statement 105 is provided to artificial intelligence entity 104 as a large language model (LLM) prompt in order to receive robot instructions (e.g., LLM response 1060). At step 2, the robot autonomy stack's (e.g., robot autonomy software stack 1081) outputs are consumed by robotic control stack 1220 at processing step 3. As shown, this naive path fails to traverse through the shown supervisory layer 110, which in turn means that in this naive path, any of the planning signal outputs from the robot autonomy stack (e.g., planning signals 1231, planning signals 1232, . . . , planning signals 123N) are directly consumed by a robotic control stack 1220 without being at processed with respect to the shown supervisory layer 110 and robotic safety constraints 114. This is highly undesirable, at least in that this naive flow leaves open the possibility that signals provided to the robot might result in unsafe robot behavior. This is highly unwanted since human life as well as assets might be jeopardized by said unsafe robot behavior.
In accordance with this naive path 101, there is no guarantee that the steps to accomplish the mission (e.g., outputs from the artificial intelligence entity) are safe. In fact, since outputs from an LLM are merely the most likely words that follow a prompt and its context, there is every possibility that the most likely words that follow this type of prompt and its context are inherently dangerous or at least unwitting with regards to safety.
What is needed is a way to turn outputs from an LLM into low level robotic commands that are guaranteed to be safe. One way to do so is shown as safe path 103. In safe path 103, rather than merely providing the artificial intelligence entity with a naked robot mission statement, step 1A serves to provide the LLM with a high-level environment description 117, possibly in the form of imagery from an imager 113, such that when the LLM response from artificial intelligence entity 104 is received into operational elements of the safe path, the received LLM response is based on informed characteristics of the environment. This is shown in the specific embodiment of
An autonomy stack (e.g., robot autonomy software stack 1081) might or might not be consulted in the safe path (as indicated by the dotted line boundary). Regardless of the specific implementation or configuration of any autonomy stack, at step 2B, the set of steps output by the LLM (e.g., a set of steps to accomplish the mission) are interpreted at step 2A and reformatted as needed into planning signals. At step 2B, the planning signals undergo processing by the supervisory layer which in turn applies robotic signal constraints to modify the planning signals, resulting in safe maneuvering signals (e.g., modified planning signals 1271, modified planning signals 1272, . . . , modified planning signals 127N). These safe maneuvering signals 116 are, in turn, used to drive robotic control stack 1220 which, at step 3 (safely) performs the set of steps to accomplish the mission by executing robot controls in accordance with said safe maneuvering signals.
The foregoing written description pertains to merely one possible embodiment and/or way to implement an improved processing flow. Many variations are possible, for example, the aforementioned supervisory layer and/or any variation of its inputs and outputs can be implemented in any environment or in accordance with any architecture, one example of which pertains to a robotic system stack as shown and described in the following figures.
Those of ordinary skill in the art will recognize the architecture of a robotic system stack, whereby a mission or command stack (e.g., the shown autonomy software stack 1201) interfaces with an actuator subsystem (e.g., the shown robotic control stack 1221).
In this two stack architecture, planning signals flow from the mission or command stack to the actuator subsystem. What is needed is a way to intercept planning signals before they reach the actuator subsystem. A technique for such interception is shown and described as pertains to
As shown, autonomy software stack 1201 is composed of several layers, which layers interoperate so as to carry out specific types of processing. Strictly to illustrate, consider the layer assignments given in Table 4.
As shown, robotic control stack 1221, is composed of several depicted as layers. These layers are interfaced with each other so as to perform under a wide variety of stack architectures. Strictly as examples consider the stack architectures as discussed in Table 5.
Unfortunately, even in implementations that do include an emergency control layer, such implementations are often insufficient for safe operation, since merely dealing with emergency stops and human takeovers fails to consider the full range of safe operation of the robot. Moreover, use of such emergency controls often negatively impacts ongoing operations of the robot. For example, use of such emergency controls often introduces unwanted downtime-sometimes requiring a full system reset.
As can now be seen, the architecture of legacy implementations such as depicted in
The foregoing is merely one modularized implementation of a supervisory layer. More (or fewer) or different functions of the supervisory layer can be implemented using any known computer module partitioning techniques and/or using any known signal processing techniques. Further, although the foregoing discussion characterizes the planning layer as being composed of an autonomy software stack, any portion of the planning layer can include or be interfaced with hardware components and/or further software components.
An example of instancing a supervisory layer is shown and described as pertains to
The figure is being presented to illustrate how a prompt optimization module 107 might produce a prompt (e.g., LLM prompt 102, image 109), which in turn is provided (e.g., as image 109PROCESSED) via alternate mode-specific path 143 as an input to artificial intelligence entity 104, which artificial intelligence entity 104 might include multiple modes (e.g., text mode mode1, audio mode mode2, image mode mode3, etc.), where the multiple modes are configured to receive a prompt that corresponds to the mode. For example, when operating in a text mode, the artificial intelligence entity receives prompts in the form of a textualized natural language description, whereas, when operating in an audio mode, the artificial intelligence entity receives prompts in the form of an audible natural language description (e.g., speech), whereas, when operating in an image mode, the artificial intelligence entity receives prompts in the form of an image or as a series of images.
Further,
A data gathering module 150 is interfaced with the artificial intelligence entity 104 so as to be able to receive LLM response 1061. Such a data gathering module, as well as any other supervisory layer components 111, can be configured to interpret an LLM response with respect to the particular artificial intelligence entity. This is shown in this embodiment by the appearance of LLM version information 129 as an output from the artificial intelligence entity 104, which is an input to the data gathering module. In some cases the LLM version information informs how labeling is performed in labeling module 152. More specifically, the LLM version information informs how natural language processing (NLP) is performed (e.g., via NLP module 151). Strictly as one example, the LLM version information might inform, via the NLP module, what language (e.g., English, French, German, Japanese, etc.) is being used by the artificial intelligence entity's LLM. In other cases, the LLM version information corresponds to the level or granularity of the corpora that were used to train this particular version of the LLM. In still other cases, the LLM version might carry information about the modality and/or capabilities of the LLM.
In some cases, one or more of the supervisory layer components feed back to prompt optimization module 107, which might begin the flow anew from the top. As is known in the art, the scope and style and format of the output of an LLM depends significantly on the prompt. As such, it often happens that loop 139 is traversed several times before the supervisory layer components output labeled planning signals 156. The specific labels that correspond to the foregoing labeled planning signals are present so as to inform planning signal modification module 146 with sufficient metadata (e.g., information about the signal and/or the signal's constituent components). Such metadata informs processing within the planning signal modification module on what robotic safety constraints 114 might be applicable to any particular planned movements.
Outputs from the planning signal modification module are deemed to be safe maneuvering signals 116 that are deemed to be safe if the robot performs the maneuvers within the then-current environment. To this end, planning signal modification module 146 outputs the then-current, updated environmental information 125, some of which then current environmental information might be provided to robotic control stack 1222. The robotic control stack then applies the safe signals to motors and actuators of the robot. To explain (1) how a label affects modification of a planning signal for safety and (2) how the labels (aka metadata) are generated in the first place, consider the label information representation and meaning as shown in
As shown, natural language constructs (e.g., parts of speech) and/or high-level language constructs can be distilled into canonical forms, either singly or in combination, which canonical forms can in turn be construed as planning signals. More particularly, such canonical forms can be processed (e.g., via a labeling module) into of a variety of representations that constitute labeled planning signals (see the labeled planning signals 156 of
Using these labeled planning signals, it is possible to generate a modified (safe) planning signal for maneuvering to a particular position. This is because the robot is subjected to a set of in-force robotic safety constraints that cover robot movements. In some cases, the set of in-force robotic safety constraints pertain to protection of assets in addition to the robot itself. In some cases, the set of in-force robotic safety constraints pertain to protection of the environment or aspects thereof.
The foregoing written description pertains to merely some example embodiments and/or to merely some way to implement a supervisory agent. Many variations are possible, for example, the supervisory layer partitioning as comprehended in the foregoing can be implemented in any environment or control flow, one example of which is shown and described as pertains to
The figure is being presented to illustrate how a planning signal modification flow might be configured into a planning signal modification module 146 that is designed to provide safe signaling to a robot that is deployed into a particular environment.
Specifically, and as shown, planning signal modification module 146 breaks down a signal into contributory parameters. Then, for each extracted parameter (step 202), one or more robotic safety constraints are applied to the parameter (step 204). In some cases, this results in bounding the parameter value range only to a particular safe range of values. For example, a signal that carries the semantic, “Go forward 5 feet” might be implemented by the robot logic as “Turn forward thrusters on until your position increases by 5 feet,” which might be modified to specify a speed, as in “Set forward thrusters to not more than 50% of full power until your position increases by 5 feet.” Such signals are guaranteed to be dynamically feasible. That is, a robotic command that expresses the semantic of “don't hit the wall”, becomes dynamically feasible by bounding a parameter value range to a particular safe range of values. By applying the techniques discussed herein, a command such as “don't hit the wall” can be recoded into signals that carry the semantics of, “slow down to 4 m/s if ever you are 2 meters or less away from the wall” (e.g., because the robot can only safely brake within a given acceleration range).
The foregoing application of robotic safety constraints can be carried out to consider any/all of a plurality of extracted parameters. Moreover, while the foregoing discussion of making modifications to planning signals, it often happens that safely carrying out steps corresponding to the planning signals might need to be considered relative to the robot's then-current environment. That is, while it might be intrinsically safe to command a subject vehicle to, for example, “Set forward thrusters to not more than 50% of full power until your position increases by 5 feet,” it might be deemed to be unsafe when considering the robot's then-current environment. Accordingly, the further steps that implement planning signal modification module 146 serve to consider all of what can be known about a particular environment, whether the particular environment is static (e.g., substantially unchanging) or whether the particular environment is dynamic (e.g., frequently changing). In order to consider all of what can be known about a particular environment, knowledge base 208 is defined. The contents of knowledge base 208 might be static (e.g., substantially unchanging) or might be dynamic (e.g., frequently changing). In fact, the knowledge base might be informed wholly or partially by outputs of an LLM.
At step 206, the environment is considered and, more specifically, any/all characteristics or parameters, or values, etc. that are constituents of knowledge base 208 are considered with respect to safety. Safe values or ranges of any/all of the constituents of knowledge base 208 are organized into a computer representation of a safe projection. That is, safe values or ranges of any/all of the constituents of knowledge base 208 are combined (e.g., into a multivariate surface) such that no parameter is allowed to take on a value that is deemed to be unsafe. The definition of safe can sometimes be dynamic. More specifically, the definition of safe can sometimes be derived from dynamically-changing parameters and/or from dynamically-changing environmental variables, and/or the definition of safe can sometimes be derived from dynamically-changing constituents of knowledge base 208.
Strictly for illustration,
At step 210, all information that can be garnered from the knowledge base with respect to the labeled planning signals is applied to form modified planning signals, where a modified planning signal is modified in a manner that considers both the aforementioned robotic safety constraints as well as the safe projection.
In some situations, the foregoing constraints are so called “worst case” constraints, which might be overly conservative and in some cases can lead to safe, but non-optimal robotic behavior. Unfortunately, it can happen that multiple overly conservative constraints combine onto robotic behavior that is safe, but extremely non-optimal. In some cases, multiple overly conservative constraints combine onto robotic behavior that is infeasible to the extent that the robot is unable to proceed in accomplishment of its assigned objective(s). In order to completely avoid such non-optimal (or otherwise undesired) robotic behavior, and/or to reduce the frequency of occurrences or severity of such non-optimal robotic behavior, step 212 serves to apply collision tolerance rules. The semantics of collision tolerance rules is in a range of permissiveness to avoidance, where a ‘high’ value of permissiveness (e.g., a value of ‘1’) on one end of a spectrum might permit an actual collision (e.g., a vehicle collision with an insect), and where a ‘low’ value of permissiveness (e.g., a value of ‘0’) might lead to absolute avoidance.
The notion of a collision permissiveness spectrum or a collision tolerance spectrum and/or the notion of collision tolerance awareness can be codified using any technique, some examples of which are shown and described as pertains to
The figure is being presented to illustrate how a collision tolerance spectrum might be codified to operate in a particular environment. Strictly as a non-limiting example, a collision tolerance spectrum might be mapped onto a unit scale, where each position on the unit scale corresponds to a fraction of the unit scale in the range [0,1). Any one of more of the fractional values can correspond to human-understandable semantics, such as to “avoid”, referring the points or ranges on the spectrum labeled as actively avoid 215, or do not approach 216 and referring to semantics that mean or imply an utter intolerance for any kind of collision or other contact (e.g., an immovable or dangerous object or boundary). Additionally or alternatively, any one of more of the fractional values can correspond to human-understandable semantics such as benign 226 or as false object 227, referring to a complete tolerance for collision or touching (e.g., a stratus cloud).
Of course the foregoing are merely examples, and many other human-understandable semantics are possible. Moreover, any one or more human-understandable semantics can be grouped based on some similarity of the tolerance and/or based on some a priori predictable subrange of tolerance (e.g., the shown touch tolerant or collision tolerant subrange 222). The subrange itself might be defined in whole or in part based on aspects of certain robotic actions and/or based on aspects of an a priori known safety constraint relaxation (e.g., safe to proceed 2241, safe to touch 2242, safe to move 2243).
Again, the foregoing are merely examples and other semantics are possible. Moreover, some values along the collision tolerance spectrum might be dynamically calculated based on then-current conditions of the robot, and/or based on then-current conditions in the environment.
One of ordinary skill in the art will recognize that different configurations of collision tolerance spectra can be defined (e.g., a priori) based on knowledge of the environment. For example, while it might be deemed to be safe for a terrestrial vehicle to make contact with “Botts' dots” or even some small debris while negotiating a maneuver on a highway, it would be deemed to be highly unsafe for a space-borne vehicle to make any sort of contact with “space junk.”
Representation of collision tolerance spectra can be purely numeric (e.g., across a fractional scale, or in across a percent scale, or across an arbitrary fixed-point or floating-point scale). Additionally or alternatively, representation of collision tolerance spectra can be based on an ordered series of human understandable words or phrases that are in turn mapped to a representation that facilitates real-time calculations.
As can be seen, the notion of collision tolerance pertains to a fairly low level of granularity of robotic planning. For example the semantics of “safe to touch [a Botts' dot]” might well be applicable (e.g., actionable) when executing a “turn right at the corner” planning signal in a terrestrial vehicle, however it would not be immediately applicable if the robotic planning signal were of a higher level, such as “proceed from the Long Beach seaport to Third and Pico Avenue in Los Angeles.” Accordingly, it is felicitous to consider safety at lower levels of granularity. Fortunately, most AI entities, specifically LLMs, can be prompted to provide robot instructions at any desired level. Accordingly, systems that ensure safe execution of AI-generated robotic commands need to be aware of not only the granularity of the contents of an LLM response, but also be able to stimulate the LLM in a manner such that the LLM provides robot instructions at a particular desired level. Doing so is known in the art as “prompt engineering.” One way to do prompt engineering is shown and described as pertains to
The figure is being presented to illustrate how an environment-aware prompt engineering flow might be configured to operate in, or in conjunction with supervisory layer 110. As shown, prompt engineering flow 3A00 includes feedback path 381, whereby artificial intelligence entity 104 can be prompted and re-prompted any number of times until the LLM returns robot instructions at a particular desired level of granularity. In this particular embodiment, LLM response 1062 is parsed into descriptions of individual steps (at step 364), where each individual step is then classified (at step 366) to produce a classification 371 that refers to a level of granularity.
Strictly as an example of such classification, a particular step description 365 can be classified as a point-to-point (PTP) step (via test 367) or the particular step description 365 can be classified as a continuous path (CP) step (via test 369), or the particular step description 365 can be classified as some other type of low-level step (not shown), or the particular step description 365 can be classified as being a higher-order step (at test 374). In that case, the “Yes” branch of test 374 is taken and the higher-order step then becomes the subject of prompt engineering involving gathering additional data (e.g., at step 376) and forming a revised prompt (e.g., at step 378).
Strictly as examples of the foregoing classification possibilities, if a particular step description 365 were to be classified as a point-to-point (PTP) step, then the “Yes” branch of test 367 would be taken and processing to associate PTP safety constraints with this classified step would be undertaken (at step 368). Additionally or alternatively, if a particular step description 365 were to be classified as a continuous path (CP) step, then the “Yes” branch of test 369 would be taken and processing to associate CP safety constraints with this classified step would be undertaken (at step 370). A particular step description 365 (e.g., a PTP step or a CP step) may contain a dimension, and/or a limit. In some embodiments, steps or other information in the LLM response may contain a safety rating pertaining to one or more aspects of the environment. Various representations and meanings of a dimension, as well as various representations and meanings of a limit, as well as various representations and meanings of a safety rating are discussed infra.
In this embodiment, prompt engineering involves gathering prompting data (e.g., at step 376), forming a revised prompt (e.g., at step 378) based on the gathered prompting data, and submitting the revised prompt 380 to the artificial intelligence entity.
At some point in this flow (e.g., after the END FOR), and possibly after multiple passes through the feedback path, all of the steps have been classified as being defined at a sufficiently low level that safety constraints and/or collision tolerance constraints that have been, or can be applied. Accordingly, the safe and possibly collision tolerant steps can be cast (at step 384) into planning signals 123.
There can be many classifications of any portions of the robot instructions given in an LLM response. Shown here for illustrative purposes are two examples of low level steps, namely PTP steps and CP steps. More particularly, when it is determined that a particular step description is a PTP step or that a particular step description is a CP step, the step description can be subjected to further safety processing as provided by the shown safety constraint application module 390.
Such a safety constraint application module may apply any number of constraints to a low level step. In this particular flow (e.g., through step 368 or through step 370) all or a portion of a point-to-point step (e.g., move from point ‘A’ to point ‘B’), or all or a portion of a continuous path step (e.g., move along a straight segment between point ‘A’ and point ‘B’), might be constrained to comport with movements (e.g., articulator movements) that are human-like. For example, when commanding a robotic arm to move its gripping utensil toward some object of interest, the various articulators such as elbow joints and/or wrist joints and so on can be constrained to move in a manner that models (e.g., via constraints) how human elbow joints and/or wrist joints move.
When operating a robot in a particular environment, both the characteristics of the robot (e.g., the robot control system) as well as the environment, may be replete with constraints. For example, a robot arm might only be able to move within a certain range of velocities, or for example, the environment might include boundaries or obstacles. Such constraints that at least potentially apply to characteristics of the robot itself as well as constraints that at least potentially apply to the environment are to be considered in systems that guarantee safe robotic behavior when executing AI-generated robotic commands. One possible technique to guarantee safe robotic behavior when executing AI-generated robotic commands is shown and described as pertains to
This safe behavior guarantee technique implements a multivariate projection module based on real-time parameter and signal streams. In this illustrative embodiment, parameter and signal values are plotted on a multi-variate spider chart. More particularly, three different sets of parameter and signal values are drawn from three different corpora; specifically, a first set of parameter values are drawn from system characterization values (e.g., derived from the shown system parameters 302), a second set of parameter values are drawn from real-time actuator signaling (e.g., derived from an ongoing planning signal stream 305), and a third set of parameter values are drawn from environmental conditions (e.g., derived from an ongoing environmental sensor measurement stream 325).
As shown, various modules are configured to ingest parameter values from the aforementioned corpora so as to process (e.g., normalize) any ingested set of parameter values for comparison to any other set or sets of parameter values. In the embodiment of
The three different types of parameters are normalized with respect to a given dynamic range. For example, a parameter that has a narrow range (e.g., minimum=1 through maximum=10) might be represented as a value from 1 to 10; however, a parameter that has a wide range (e.g., minimum=1 through maximum=10,000,000,000) might be represented as (for example) log10 of the given value. In some cases a compression shape (e.g., a continuous non-linear curve or a non-continuous piecewise planar surface) might be applied to a range so as to process parameter values for comparison to other parameter values.
Once the three different types of parameters have been prepared for comparison, they can be projected onto respective three different spider charts. One of ordinary skill in the art can now recognize that the spider charts can be superimposed. To explain carrying out of such superposition, consider the three torsion-related parameters: (1) a torsion limitation 306 deriving from system characterization, (2) a rotational movement 320 that arises from actuation of a motor, and (3) measured external torsion force 328 that arises from aspects of the environment as they act on the robot. Strictly as one example, observe that the shown value of the external torsion force is very nearly the same (normalized) value of the torsion limitation. In this case the desired actuation corresponds to an actuation signal that adds very little or no additional torsional force.
As another example, observe that the value of the shown cycle rate measurement 330 is far less than the (normalized) value of the shown cycle rate demand 322. Moreover, neither the cycle rate measurement nor the cycle rate demand is in excess of cycle rate limitation 308. In this case, the actuated cycle rate is within the given cycle rate limitation. As a still further example, consider the scenario where ongoing planning signals specify application of actuated flexural force 324. The plotted value of that actuated flexural force is within the bounds of the flex limitation 310. It would thus be acceptable to apply the shown actuated flexural force only if the environment were not also applying appreciable amounts of external flexural forces 332.
Again, once the three different types of parameters have been prepared for comparison, they can be plotted onto a respective three different spider charts, and those three different spider charts can undergo superposition analysis where the lesser of respective values from any of the aforementioned three different types of parameters results in a projection that is deemed to comport with the given limitations. This plotting of three different spider charts can be accomplished by the shown multivariate projection module 3360. In the shown example, operation of multivariate projection module 3360 produces the shown resulting multivariate guaranteed safe projection 338.
In many cases, limitations such as the foregoing torsion limitation, even if continuously observed across all points in time, may not guarantee safety under all possible circumstances. This is especially true in dynamically-changing scenarios where a multitude of sensors are streaming real-time environmental data that are to be compared with streaming environmental measurements that represent ongoing changes in the environment and/or the juxtaposition of the robot with its environment. One mechanism to guarantee safe operation is to observe still further safety limitations. Such further safety limitations may come into play when sensor data is known to be merely an estimate, and/or when sensor data is delivered late or is otherwise temporarily not available for safety calculations. Example uses of these further safety limitations as inputs to a multivariate projection module are shown and described hereunder.
As shown, the embodiment of
Robotic safety constraints for guaranteeing safe robot behavior may be expressed as a static limitation (e.g., no more than 100 foot-pounds of torque), or robotic safety constraints for guaranteeing safe robot behavior may be expressed as a formula (e.g., TorqueTOTAL=TorqueSOURCE1+TorqueSOURCE2), or robotic safety constraints for guaranteeing safe robot behavior may be expressed as logic (e.g., IF this THEN that), or as an algorithm (e.g., “Except during takeoff, do not allow TorqueSOURCE1 to be greater than 90 foot-pounds of torque”).
The foregoing discussions refer to uses of robotic safety constraints for guaranteeing safe robot behavior. One possible advance in techniques for generating such robotic safety constraints comprehends the notion of collision tolerance. One way to implement collision tolerance is shown and described as pertains to
The figure is being presented to illustrate how a step description (e.g., step description 365 comprising a portion of a response resulting from prompting an LLM) can be considered with respect to any collision tolerance rules. More specifically, the figure is being presented to break down the application of collision tolerance into an algorithm that can be carried out by a computer. Still more specifically, the figure is being presented to explain how collision tolerance rules can be expanded into constituent terms, and how each term can be individually considered with respect to collision tolerance.
Any number of rules can be applied to a given incoming instance of step description 365. As shown, step 404 serves to identify a set of rules 408 that are drawn from path rules 406 based on the type or classification 371 of the incoming instance of step description 365. In this implementation, nested FOR EACH loops serve to perform operations over each individual rule of the set of rules 408, and further to perform a set of operations over each term (e.g., rule term 4071, rule term 4072) of a particular rule.
To illustrate, suppose the step description carries the semantics of “Move the articulator arm from point A to point B.” Now, further consider that the set of rules includes a rule that says, “Except when overridden, define articulator arm movements using anthropologically-accurate motions for elbow and wrist joint.” In this illustrative case, there are two terms: a first term pertaining to the elbow joint, and a second term pertaining to the wrist joint. Each term is considered, either individually, or together in combination.
As shown, step 410 serves to determine if there are potentials for collisions when carrying out “[ . . . ] anthropologically-accurate motions for elbow and wrist joints.” A potential for a collision might happen due to motion predicted by the planning signals (e.g., the robot arm could potentially collide with another member of the robot itself). Additionally or alternatively, a potential for a collision might happen due to relative motion predicted by the planning signals when considered with respect to a predicted motion of something in the environment. For example, a planned path of a robotic arm might be on a collision path with the arm of an adjacent robot. In this case, a collision would not be tolerated (e.g., as deemed by taking the “No” branch of test 412). Even though the foregoing rule specifies use of “[ . . . ] anthropologically-accurate motions for elbow and wrist joints,” that rule might be overridden by collision avoidance processing (step 416). Alternatively, rather than overriding a rule by collision avoidance processing, the potential collision might be tolerated—at least at that particular moment in time.
Recall that there is an ongoing stream of planning signals, and moreover that there is an ongoing stream of environmental sensor measurements. Accordingly, it can happen that a first time processing of step 410 detects there to be a potential collision, whereas at a second, later time, a second pass through the processing of step 410 detects that there is no longer that same potential collision.
Similarly, it can happen that a potential collision need not be remediated at that moment in time. For example consider the case when two terrestrial vehicles are approaching each other while going in different directions through a curve. There are many moments when the two vehicles are on a collision course with each other, however evasive maneuvers are not (yet) needed by either vehicle. The shown step 410 can be configured to consider a variety of possibilities, including, (1) consideration of a straight line progression of motion based on the most recent two measurements, or (2) consideration of a continuous curve-fitted progression of motion based on the most recent two measurements, or (3) some other predictions based on any available data and using any known prediction techniques. Accordingly, step 414 might at least temporarily permit planned robotic maneuvering in spite of the potential collision path.
The foregoing written description covers merely a small subset of possible scenarios under which predicted collisions might be (at least temporarily) tolerated. There are other scenarios where collision tolerance considers aspects of the environment. One such scenario where certain collision courses are tolerated based on consideration of aspects of the environment is shown and described as pertains to
The figure is being presented to illustrate one scenario where a particular type of autonomous vehicle's control system is configured to operate in a corresponding particular environment. Specifically, the figure is being presented to illustrate collision tolerance as applies to how a submersible type of autonomous vehicle is operated underwater.
As shown, autonomous submersible 418 is given a mission to move to the bow of the sunken vessel 426 and send video to submersible launch vessel 417. One of several lower-level steps to accomplish this mission might be to navigate to a given intended point-of-view location. In carrying out this lower-level step (e.g., to navigate to intended point-of-view location 428) it can happen that, in this underwater environment, there is a school of fish 422. A naive execution of this lower-level step (e.g., to navigate to intended point-of-view location 428) might avoid “collision” with the school of fish, thus hindering progress toward achievement of the mission, possibly even disabling the autonomous submersible for a long period of time (e.g., disabling the autonomous submersible for as long as the school of fish are detectably present on the path to the intended point-of-view location). To remediate this, one or more collision tolerant path rules might be defined to cover the predictable happenstance in this underwater environment that there will be fish present.
As can be seen, when a particular type of autonomous vehicle's control system is configured to observe collision tolerance in a particular environment, there can be a permitted collision segment 420 at the same time, and in the same environment, as when there is an impermissible collision segment 424.
Much of the foregoing written description pertains to systems that observe pre-codified sets of robotic safety constraints, however in the context of systems that transform step-oriented LLM outputs into safety constraints, it is desirable to include robotic safety constraints that are formed dynamically—that is, derived in real-time based on contents of an LLM response from an AI entity. Reliance on manual intervention is to be eschewed. One possible way to address manual intervention so as to reduce or eliminate reliance on manual processes is shown and described as pertains to
To explain, when deploying robotic systems in new environments, robotic safety constraints need to be identified, codified and validated before deployment of the robot(s) into a new environment. Legacy approaches are labor intensive, often involving multiple manual techniques (e.g., hand-coding of software, manual testing, and manual deployment, etc.). In contrast, the techniques disclosed herein provide a way to fully automate the identification, codification, and validation of robotic safety constraints, thus saving valuable resources and time and thus enabling more rapid deployment of robotic systems. In fact, using the techniques disclosed herein it is possible to form and deploy robotic safety constraints fully automatically-even in dynamically changing environments. That is, robotic safety constraints can be generated and deployed fully automatically and in real-time by processing LLM responses from one or more AI entities. Differences between the foregoing labor intensive approaches for dealing with robotic safety constraints and the disclosed computer-implemented approaches for dealing with robotic safety constraints are shown and described as pertains to
Specifically,
In contrast, the computer-implemented approach shown on the right side of
To explain in still more detail, although the computer-implemented approach shown on the right side of
As is easily understood by one of skill in the art, the environment in which a robot operates can change very quickly. In some cases, an environment of interest changes completely within a moment's time. Consider a robot drone that is flying northward, but then make a U-turn to fly southward. In this case, in a first moment the environment of interest is north-facing, whereas in a second moment, the environment of interest is south-facing. As such, it is desirable to generate robotic safety constraints dynamically, where new sets of robotic safety constraints are derived automatically and in real-time based on contents of an LLM response from an AI entity. One possible way to implement dynamic derivation of robotic safety constraints based on LLM responses from an AI entity is shown and described as pertains to
The left side of
As shown, processing in the primary autonomy pipeline begins when an LLM prompt 102 is presented to artificial intelligence entity 104. Output from the artificial intelligence entity includes an LLM response 1063 that is then provided to one or more operational units of labeling module 152. As can be seen by inspection of this embodiment, execution of operational units of labeling module 152 is carried out after receiving outputs from artificial intelligence entity 104 and before commencing with processing of the supervisory layer 110. In this embodiment, performance of steps within, or directed by, labeling module 152 results in a labeled LLM response 517. The primary autonomy pipeline is merely one possible partitioning choice that is presented as a non-limiting illustrative example.
In this embodiment, the constraint derivation pipeline performs various functions on behalf of the primary autonomy pipeline. Specifically, and as shown in this example partitioning, the constraint derivation pipeline includes steps for: (1) performing prompt engineering iteratively until the LLM response returned is in a step-wise form that can be labeled (e.g., when the steps given in the LLM response are at the desired level of detail), and (2) loading derived formal safety constraints into the robotic safety constraint database. The computer code that performs the function of performing prompt engineering is configured such that the LLM is offered an information-rich prompt. Specifically, a prompt is enriched with sufficient information and details in the prompt to cause the LLM to return a commensurately detailed LLM response. Then, given such a commensurately detailed LLM response, aspects of the LLM response are labeled in a manner that facilitates derivation of formal safety constraints from the labeled LLM response (step 518).
Those of ordinary skill in the art will recognize that an LLM will return responses at substantially the same level of abstraction as is given in the prompt. Also, those of ordinary skill in the art will recognize that formal constraints are mathematical constructs that are at a low level of abstraction. This presents a mismatch that needs to be addressed. To illustrate the foregoing mismatch, an LLM counter example is presented in Table 6. To contrast, Table 7 presents an improved LLM prompt having been enriched with sufficient information and details in the prompt so as to cause the LLM to return a commensurately detailed LLM response.
As can be seen, the LLM response does indeed return a step-wise solution to accomplish the given mission 506. However, it does so in a way that evades the possibility of deriving relevant safety constraints that bound a robot's behavior. What is needed is a more detailed prompt, one example of which is presented in Table 7.
Before discussing Table 7, it is instructive to note that step 508 includes an image processor 510, which is able to produce an environmental assessment 512 with or without consideration of any mission statement. For example, an environmental assessment might be generated by considering images 504 as produced by camera 502 (e.g., images of the environment of interest). Any known techniques (e.g., edge detection, 3D dimensional analysis, object classification, etc.) can be used to generate information about the environment that can, in turn, be used to enrich the prompt offered to the LLM. Moreover such an environmental assessment can be generated in real time (e.g., at least as fast as the rate of the imager device of the camera). It should be noted that there are many real-word situations where real-time imaging is carried out even in absence of a mission statement. Strictly as one example, there are many real-world situations where a human operator is operating robotic controls-leading to the situation where the robot cannot know the mission (e.g., some final state), but merely tactics 507 or steps (e.g., “go left”, “go right”, etc.) that putatively lead to accomplishment of the mission in the mind of the human operator.
In this particular embodiment, selected information about the environment is given in the latter portion of the engineered LLM prompt. Specifically, the prompt text corresponding to index 6 of Table 7 is an example of information about the environment that can be generated automatically through use of a camera and an image processor—and with or without any knowledge of an intended mission or outcome.
As can be seen from inspection of the foregoing LLM prompt of Table 7, the LLM is presented with ground rules (e.g., as given in the prompt text corresponding to index 1 of Table 7). Further, the LLM is presented with a task statement (e.g., as given in the prompt text corresponding to index 2 of Table 7), as well as various requirements for the desired LLM output (e.g., as given in the prompt text corresponding to index 3, index 4, and index 5 of Table 7).
When a prompt having the degree of detail and specificity is constructed (e.g., at step 514) and provided to an LLM (e.g., to artificial intelligence entity 104), the LLM response is commensurately detailed and specific. Table 8 breaks down the LLM response that is returned by the LLM.
As can be seen by inspection of Table 8, the LLM response to the LLM prompt of Table 7 does indeed comport with the instructions of Table 7. Specifically, the LLM response as shown in index 4 of Table 8 follows the instructions (e.g., formatting requirements) provided to the LLM in the prompt (e.g., as given in index 4 Table 7). Moreover, the objects in the environment each have corresponding (i.e., have been labeled with) safety indexes, as requested.
The foregoing discusses labeling in particular formats, in this case the well-known YAML markup language and the well-known JSON notation language, however other languages or formats such as other markup languages can be supported. Moreover although the foregoing paragraphs emphasizes requesting that the LLM provide responses in accordance with some particular type or class of formatting, the LLM can be requested to provide any known environmental safety constraints and/or to provide any known controllable condition safety constraints. For example, an LLM might be prompted in a manner that requests an LLM response that includes dimensions of a room, which dimensions (e.g., dimensions in feet, etc.) inform safe operating distances from room features (e.g., distances in inches from walls or doorways, etc.), or the LLM can be requested to produce an LLM response that corresponds to various safe operation limits (e.g., “limit speed to less than 1 meter per second”) and/or that corresponds to controllable condition safety constraints (e.g., “velocity<1 meter per second”). Any such known environmental safety constraints and/or any such known controllable condition safety constraints as provided by the LLM are nevertheless checked by, and in accordance with the then-current configurations of the herein-discussed supervisory layer components.
As is known in the art, an LLM uses context provided in the dialog. Accordingly, a further prompt might request the LLM to produce a step-wise solution to a robotic mission. Such a step-wise solution to a robotic mission as given by an LLM can sometimes be used as inputs to a robot autonomy software stack (autonomy software stack 1203). Alternatively, a further prompt might request the LLM to produce a signal-wise solution to a robotic mission (e.g., where the LLM response includes planning signals (e.g., planning signals 1231, planning signals 1232, . . . , planning signals 123N) in a format that is specified to the LLM.
Now that the safety constraints have been augmented (e.g., the robotic safety constraints 114 as enriched by the derived formal safety constraints of step 518), and having a set of planning signals, supervisory layer 110 can output a set of safe maneuvering signals 116 as a series of modified planning signals (e.g., modified planning signals 1271, modified planning signals 1272, . . . , modified planning signals 127N). The robot can thus safely carry out its mission.
The foregoing description of
As an initial consideration, and referring back to
The data structure also includes a location (e.g., in three dimensions, x, y, and z) corresponding to each structure or object entry. Such an environmental assessment 512, in combination with mission 506, serves to inform prompt construction module 550. Step 526 serves to determine the robotic system's autonomy stack characteristics, which characteristics are then used in processing of step 528. In some cases, determination of said characteristics can be obtained using standardized application programming interfaces (APIs). In other cases, vendor-specific APIs are used to determine the robotic system's autonomy stack characteristics. In still other cases, step 526 is configured to determine the robotic system's autonomy stack characteristics by stimulating the robotic system's autonomy stack with sample stimulus, and then determining at least some representative ones of the stack's characteristics based on the stack's outputs to the provided stimulus. The determinations made in response to carrying out step 526 are used to inform step 528, which, in some embodiments, draw from additional LLM selection criteria 524.
As is known in the art, different LLMs are trained on different corpora of training data, and as such produce LLM responses that are drawn from their training data. Strictly as illustrative examples, an LLM that had been trained exclusively on high-level step-wise approaches to accomplishing a mission will return high-level stepwise solutions, whereas an LLM that had been trained exclusively on low-level planning signal approaches to accomplishing a mission will return solutions based on a series of low-level planning signals. Accordingly, step 528 is configured to select an LLM (e.g., selected LLM 530) that has been trained using training data of a desired level.
For example, as suggested above, the selection may depend, in whole or in part, on characteristics of whatever autonomy software stack is being employed in the overall processing flow of the robotic system. Continuing the foregoing example, if the autonomy software stack is being employed and the overall processing flow of the robotic system is able to comprehend step-wise codifications of missions, then an LLM that has been trained on high-level step-wise approaches might be selected, whereas if the autonomy software stack is being employed and the overall processing flow of the robotic system is absent or of limited capability, then an LLM that has been trained on low-level planning signals might be selected.
Once a particular LLM, and possibly a particular version of the selected LLM, has been determined, the prompt construction module can construct an LLM prompt that is at the same level of abstraction as is the training data of the selected LLM (step 532). Such an LLM prompt (e.g., LLM prompt 102LEVELIZED) is made available for downstream processing.
The foregoing written description pertains to merely the shown and discussed example embodiments. Many variations are possible, for example the many variations as given in the appended claims.
Variations of the foregoing may include more or fewer of the shown modules. Certain variations may perform more or fewer (or different) steps and/or certain variations may use data elements in more, or in fewer, or in different operations. Still further, some embodiments include variations in the operations performed, and some embodiments include variations of aspects of the data elements used in the operations.
Next, a human operator attempted to drive the robot 712 around within the bounds of the pre-imaged portions of the physical setting. The hierarchical CBFs in fact prevented the robot from touching obstacles. This was attempted multiple times, including multiple drive-arounds when the human operator purposely tried to “run over” an obstacle.
At a later time, when a human (or other safety-critical being or asset) arrived on the scene and attempted to purposely (i.e., for purposes of the experiment) walk into the robot, the human was prioritized over the inanimate objects on scene and the robot walked over the skateboard/basketball in order to avoid contact with the human.
When new objects (e.g., further obstacles) entered the scene, they were detected automatically, and a new prompt was generated and fed into the LLM. The LLM responded with an updated set of safety ratings, against which an updated set of hierarchical control barrier functions (CBFs) were generated.
The foregoing pertains to merely one experiment that was carried out in a particular environment. Safe operation in other environments having different characteristics is of course possible. In fact, the foregoing experiment was constructed merely to illustrate the generality of safe operation in a dynamically-changing environment. Additional experiment have been conducted where the supervisor is able to generate safe signals based on CBFs that are configured based on any one or more, or any combination of, speed, inertia, contact, including purposeful contact, and other kinematics, as well as actuator parameters, aspects of materials (e.g., hard, soft, elastic, brittle, etc.), and shapes.
According to some embodiments of the disclosure, computer system 8A00 performs specific operations by data processor 807 executing one or more sequences of one or more program instructions contained in a memory. Such instructions (e.g., program instructions 8021, program instructions 8022, program instructions 8023, etc.) can be contained in, or can be read into, a storage location or memory from any computer readable/usable storage medium such as a static storage device or a disk drive. The sequences can be organized to be accessed by one or more processing entities configured to execute a single process or the sequences can be configured for execution by multiple concurrently running processing entities. A processing entity can be hardware-based (e.g., involving one or more cores) or software-based, and/or can be formed using a combination of hardware and software that implements logic, and/or can carry out computations and/or processing steps using one or more processes and/or one or more tasks and/or one or more threads or any combination thereof.
According to an embodiment of the disclosure, computer system 8A00 performs specific networking operations using one or more instances of communications interface 814. Instances of communications interface 814 may comprise one or more networking ports that are configurable (e.g., pertaining to speed, protocol, physical layer characteristics, media access characteristics, etc.), and any particular instance of communications interface 814 or port thereto can be configured differently from any other particular instance or port. Portions of a communications protocol can be carried out in whole or in part by any instance of communications interface 814, and data (e.g., packets, data structures, bit fields, etc.) can be positioned in storage locations within communications interface 814 or within system memory, and such data can be accessed (e.g., using random access addressing, or using direct memory access (DMA), etc.) by devices such as data processor 807.
Communications link 815 can be configured to transmit (e.g., send, receive, signal, etc.) any type of communications packets (e.g., communication packet 8381, . . . , communication packet 838N) comprising any organization of data items. The data items can comprise a payload data area 837, a destination address field 836 (e.g., a destination IP address), a source address field 835 (e.g., a source IP address), and can include various encodings or formatting of bit fields to populate packet characteristics 834. In some cases, the packet characteristics include a version identifier, a packet or payload length, a traffic class, a flow label, etc. In some cases, payload data area 837 can comprise a data structure that is encoded and/or formatted to fit into byte or word boundaries of the packet.
In some embodiments, hard-wired circuitry may be used in place of, or in combination with, software instructions to implement aspects of the disclosure. Thus, embodiments of the disclosure are not limited to any specific combination of hardware circuitry and/or software. In embodiments, the term “logic” shall mean any combination of software (e.g., instructions stored in/on a non-volatile medium), or hardware that is used to implement all or part of the disclosure.
The terms “computer readable medium” or “computer usable medium” as used herein refer to any medium that participates in providing instructions to data processor 807 for execution. Such a medium may take many forms including, but not limited to, non-volatile media and volatile media. Non-volatile media includes, for example, optical or magnetic disks such as disk drives or tape drives. Volatile media includes dynamic memory such as RAM.
Common forms of computer readable media include, for example, a flash memory drive, a spinning hard drive, a floppy disk, a flexible disk, magnetic tape, or any other magnetic medium; a CD-ROM or any other optical medium such as punch cards, paper tape, or any other physical medium with patterns of holes; semiconductor memories such as RAM, PROM, EPROM, FLASH-EPROM, or any other memory chip or cartridge; or any other non-transitory computer readable medium. Such data can be stored, for example, in the shown external storage device 813, and/or in any form of an external data repository 804, either of which can be formatted into any one or more storage areas. Certain forms of computer readable media comprise parameterized storage 839 accessible by a key (e.g., filename, table name, block address, offset address, etc.).
Execution of the sequences of instructions to practice certain embodiments of the disclosure are performed by a single instance of a computer system 8A00. According to certain embodiments of the disclosure, two or more instances of computer system 8A00 coupled by a communications link 815 (e.g., LAN, public switched telephone network, or wireless network) may perform the sequence of instructions required to practice embodiments of the disclosure using two or more instances of components of computer system 8A00.
Computer system 8A00 may transmit and receive messages such as data and/or instructions organized into a data structure (e.g., communications packets). The data structure can include program instructions (e.g., application code 803) communicated through communications link 815 and communications interface 814. Received program instructions may be executed by data processor 807 as they are received at the data processor. The program instructions can be copied any number of times (e.g., into an intermediate memory and/or into a CPU cache) for later execution. Computer system 8A00 may communicate through a data interface 833 to a database 832. Data items in a database can be accessed using a primary key (e.g., a relational database primary key) and any number of secondary keys.
Processing element partition 801 is merely one sample partition. Other partitions can include multiple data processors and/or multiple communications interfaces and/or multiple storage devices, etc. within a partition. For example, a partition can bound a multi-core processor (e.g., possibly including embedded or co-located memory), or a partition can bound a computing entity having a plurality of computing elements, any of which computing elements are connected directly or indirectly to a communications link of any sort. Furthermore, a first partition can be configured to communicate to a second partition. A particular first partition and a particular second partition can be congruent (e.g., in a processing element array) or can be different (e.g., comprising disjoint sets of components). A partition can include a single module or a partition can include a plurality of modules.
As used herein, a module refers to any mix of any portions of system memory and any extent of hard-wired circuitry including hard-wired circuitry embodied as all or portions of a data processor 807, which data processor can be used to realize, with or without reliance on the system memory, all or portions of processor-implemented systems or subsystems. Some embodiments of a module include one or more special-purpose hardware components (e.g., sensors, transducers, power control, actuator control logic, etc.). Some embodiments of a module include instructions that are stored in a processor-accessible memory for execution so as to facilitate operational and/or performance characteristics pertaining to fitting a robotic system software stack to interface with an interstitial supervisory layer. A module may include one or more state machines and/or combinational logic used to implement or facilitate the operational and/or performance characteristics pertaining to fitting a robotic system software stack to interface with an interstitial supervisory layer.
Various implementations of database 832 comprise storage media organized to hold a series of records or files such that individual records or files are accessed using a name or key (e.g., a primary key or a combination of keys and/or query clauses). Such files or records can be organized into one or more data structures (e.g., data structures used to implement or facilitate aspects of fitting a robotic system software stack to interface with an interstitial supervisory layer). Such files, records, or data structures can be brought into and/or stored in volatile or non-volatile memory. The occurrence of, and organization of the foregoing files, records, and data structures improve the way in which the computer stores and retrieves data in memory so as to implement all or portions of a robotic system stack. Strictly as one example, various of the disclosed embodiments improve the way data is accessed when the computer is performing operations pertaining to fitting a robotic system software stack to integrate with an interstitial supervisory layer, and/or for improving the way data is manipulated when performing computerized operations pertaining to robot behavior.
As shown, environment interface modules 817 include a selectable set of environment sensor interface modules (e.g., environment sensor interface module 8181, environment sensor interface module 8182, . . . , environment sensor interface module 818N; human I/O module 8191, human I/O module 8192, . . . , human I/O module 819N; and artificial intelligence I/O module 8201, artificial intelligence I/O module 8202, . . . , artificial intelligence I/O module 820N). Any of the foregoing constituents of the environment interface modules can be configured for any particular application. Any combination of environment interface modules can be juxtaposed in any topology and/or in any order or organization.
As shown, component interface modules 821 include a selectable set of component sensor modules (e.g., autonomy stack interface module 8221, autonomy stack interface module interface module 8222, . . . , autonomy stack interface module 822N; and robotic control stack module 8231, robotic control stack module 8232, . . . , robotic control stack module 823N). Any of the foregoing constituents of the component interface modules can be configured for any particular application. The component interface modules may further include a database or other storage of interface configuration specifications. Any combination of component interface modules can be juxtaposed in any manner.
As shown, signal processing modules 825 include a selectable set of various signal processing modules (e.g., signal conditioning module 8261, signal conditioning module 8262, . . . signal conditioning module 826N; signal translation module 8271, signal translation module 8272, . . . signal translation module 827N; and signal prioritization module 8281, signal prioritization module 8282, . . . , signal prioritization module 828N). Any of the foregoing constituents of the signal processing modules can be configured for any particular application. Any combination of signal processing modules can be juxtaposed into any organization.
As shown, value processing modules 829 include a selectable set of various value processing modules (e.g., constraint processing module 8301, constraint processing module 8302, . . . constraint processing module 830N; component health processing module 8311, component health processing module 8312, . . . , component health processing module 831N; and system characterization module 8401, system characterization module 8402, . . . , system characterization module 840N). Any of the foregoing constituents of the value processing modules can be configured for any particular application. Any combination of value processing modules can be juxtaposed into any organization. Moreover, in some settings, any of the foregoing modules and specifications can be included (or excluded) in any particular deployment.
The particular deployment shown includes an example supervisory layer implementation 872. Such a supervisory layer may include one or more implementations of a behavior guarantee module (e.g., the shown example behavior guarantee module implementation), which in turn may include one or more optimization problem solver (e.g., optimization problem solver implementation 8431, and optimization problem solver implementation 8432). A behavior guarantee module can be configured with any manner of environment interface modules, which in turn are configured to be able receive an ongoing stream of updated real-time condition signals 842. Those updated real-time condition signals can be combined with an ongoing stream of real-time constraint signals 855 to express a then-current safe operation requirement into codification that is in a form of a problem that can be solved by one or more optimization problem solvers.
The ongoing stream of real-time constraint signals 855 can derive from any combination of environmental safety constraints 850 and/or any combination of controllable condition safety constraints 849. In some cases, the ongoing stream of real-time constraint signals is output from a constraint calculation module 851. Such a constraint calculation module can be configured to process any combination of environmental condition signals 845 and/or any combination of robotic control system condition signals 846.
In many cases environmental condition signals can change in response to signals that are sent to the robotic controls. For example, consider the scenario where there is an obstacle (e.g., a stationary object or a moving object) on the trajectory or path of a movable mechanical device (e.g., a robotic manipulator, an autonomous robotic vehicle, an autonomous aerial drone, etc.). Supposing that the controllable condition safety constraints include a constraint that has the semantics of “stay at least 10 feet from any obstacle,” then the path of the movable mechanical device can be changed so as to “veer away” from the obstacle. Once the movable mechanical device has maneuvered away, the newly updated environmental condition signals might indicate that there is no longer an obstacle in the path (or close to the path) of the movable mechanical device. Now, further consider that the “veer away” action was taken because of the aforementioned environmental safety constraint. However, it might be that there is a currently in force controllable condition safety constraint 849 that has the semantics of “stay at least 20 feet from any obstacle,” in which case, when considering both the environmental safety constraints as well as the controllable condition safety condition constraints, the constraint calculation module might form a real-time constraint signal that is more restrictive (e.g., safer) than when considering environmental safety constraints alone.
In exemplary scenarios, real-time candidate robotic planning signals are considered with respect to real-time constraints (e.g., environmental safety constraints, controllable condition safety constraints, etc.) so as to produce safe real-time signals, which are then provided to various robotic control systems. More particularly, candidate robotic planning signals corresponding to a robotic operation or a manipulator movement, or a robotic vehicle maneuver can be modified in accordance with the foregoing techniques so as to generate real-time robotic control signals that are deemed to be safe.
Further details regarding general approaches to producing safe robotic vehicle maneuvers are described in U.S. application Ser. No. 18/324,042 titled “SYSTEMS AND METHODS FOR HIGH-SPEED GEOFENCING” filed on May 25, 2023, which is hereby incorporated by reference in its entirety.
There may be many other scenarios and many other types of environmental safety constraints 850 as well as many other types of controllable condition safety constraints 849. For example, it can happen that a particular controllable condition safety constraint might be less constraining than a corresponding environmental safety constraint. The optimization problem solvers would solve for optimal solutions that still satisfy the then-current safety constraints. As such, it can happen that optimal safe robotic behavior is not necessarily any less optimal in any regard than optimal robotic behavior even in the absence of any given controllable condition safety constraints. On the other hand, it frequently happens that observance of controllable condition safety constraints overrides mere environmental safety constraints so as to result in safe behavior of the robot.
The supervisory layer implementation of
FIG. 8C1 depicts a block diagram of an interstitially situated supervisory agent. More specifically, FIG. 8C1 depicts block diagram 8C100 that includes a safety module 877 (e.g., constituting example supervisory agent 879) that is situated between a planning module 873 (e.g., comprising example autonomy stack implementation 870) and a kinetic control module 875 (e.g., comprising example robotic control stack implementation 874).
In this juxtaposition, the example supervisory agent implementation can be configured to (1) intercept signals from the example autonomy stack implementation, (2) process such intercepted signals, and (3) provide modified versions of the intercepted signals to downstream processing. Additionally or alternatively, the example supervisory agent 879 can be configured to receive and process signals from any one or more of a variety of environmental sources (e.g., from environmental condition sensors 8781 and/or from environmental condition sensors 8782).
In this illustrative example, downstream processing includes processing of the modified versions of the intercepted signals (e.g., by robotic control module 8661, robotic control module 8662, . . . , robotic control module 866N) so as to provide signals to any of a plurality of motors 869 and/or actuators 868.
In this manner, the interstitially situated supervisory agent can support any one or more robotic control applications in various settings (e.g., involving robotic terrestrial vehicle control, manufacturing floor robot control, unmanned aerial vehicle control, anthropomorphic robot control, etc.). In this particular architecture, example supervisory agent 879 includes a signal intercept module 860, a signal modification module 862, and a signal data publisher module 856SAFETY. The signal data publisher module 856SAFETY is configured to enter modified versions of the intercepted signals (or portions thereof) into one or more modified signal queues, as exemplified by modified signal data queue array 859. As shown, the contents of the constituent queues of the modified signal data queue array (e.g., modified signal data queue entry MS11, modified signal data queue entry MS12, modified signal data queue entry MS13, modified signal data queue entry MS21, modified signal data queue entry MS22, modified signal data queue entry MS23, . . . , modified signal data queue entry MSN1, modified signal data queue entry MSN2, modified signal data queue entry MSN3) are made accessible to downstream processing.
Strictly as one possible implementation, access to the contents of the constituent queues of the modified signal data queue array is facilitated by one or more subscriber modules. The shown example is security hardened by virtue of the communication protocol between shown signal subscriber module 864 and signal data publisher module 856SAFETY, where such a communication protocol serves to securely communicate information (e.g., authentication credentials 857) between the modules.
The shown example robotic control stack implementation 874 includes a signal subscriber module, shown as signal subscriber module 864, which signal subscriber module can be configured to access entries that are stored in any one or more queues of the modified signal data queue array 859. In some cases, a signal subscriber module can be configured to access entries according to a first-in-first-out (FIFO) regime, and/or a signal subscriber module can be configured to access entries according to a last-in-first-out (LIFO) regime, and/or a signal subscriber module can be configured to access entries according to a random access regime, in which random access regime a subscriber can access entries from any position of any one or more queues of the modified signal data queue array.
Variations of the shown supervisory agent can be deployed in any environment that corresponds to any particular mission. Merely to illustrate one possible implementation, the environment of FIG. 8C1 includes a repository of mission-defining data structures 876. Particular types of data that might be populated into the foregoing mission-defining data structures may serve to inform various respective information collection and processing modules of an autonomy stack (e.g., information collection and processing module 8521, information collection and processing module 8522, . . . , information collection and processing module 852N). These information collection and processing modules take in information from the environment (e.g., via environmental condition sensors 8781) and process such environmental information in conjunction with data of the of mission-defining data structures so as to produce processed information in the form of signal data 854, which processed information is made available for publication to and access by any types of subscribers. As shown, a signal data publisher module 856AUTONOMY is interfaced with signal data queue array 858 to provide access to signal data (e.g., as may be present in signal queue entry S11, signal data queue entry S12, signal data queue entry S13, signal data queue entry S21, signal data queue entry S22, signal data queue entry S23, and signal data queue entry SN1, signal data queue entry SN2, . . . , signal data queue entry SN3). Any signal data queue entry within the individual constituent queues of the signal data queue array 858 are accessible by signal intercept module 860. For security purposes, signal intercept module 860 may interact with signal data publisher module 856AUTONOMY so as to establish authenticated and secure access to the content of the signal data queue array.
The foregoing example of FIG. 8C1 exemplifies an embodiment where the autonomy stack or its constituent autonomy agents publish signal data in a manner that the supervisory agent can intercept and process such signals. However there are situations where, rather than having an autonomy stack that generates signals destined for the robotic control stack, instead, a human operator generates signals destined for the robotic control stack. In similar fashion to how an interstitially situated supervisory agent can generate safe robotic control signals based on instructions from an autonomy stack, some embodiments generate safe robotic control signals based on instructions from a human operator. One example embodiment involving generating safe robotic control signals based on instructions from a human operator is shown and described as pertains to FIG. 8C2.
FIG. 8C2 depicts a block diagram involving a human operator's safe manipulation of a robotic control system. More specifically, FIG. 8C2 depicts block diagram 8C200 that includes an example supervisory agent 879 that is situated between an example human operators' environment 853 and an example robotic control stack implementation 874.
This figure is being presented to illustrate how a supervisory agent can produce safe robotic control system signals based on signals received from a human operator. In this particular example, operator 865 uses his or her senses to process any of a variety of environmental signals 867. As shown, the user processes visual signals, auditory signals and other sensory signals, and then, using human faculties, resolves such sensory signals into man-machine interface inputs. The shown human-machine interface 871 can accept any manner of real-time inputs (e.g., human-derived inputs 863) as well as any manner of settings 861 that the user establishes. In some cases, a particular instance of a human-machine interface receives information from a robotic control stack, which information can be used to calibrate the human-machine interface. Such calibration can take place statically (e.g., when the user is not actively providing human-derived signals to the human-machine interface), or such calibration can take place dynamically (e.g., during time periods when the user is actively providing human-derived signals to the human-machine interface).
As is known by those of ordinary skill in the art, a human operator can be a system's “own worst enemy.” That is, given a set of controls, and in absence of any modules that constrain or otherwise modify human inputs, a human operator, in spite of any amount of training and scenario simulation practice, can operate a robot in an unsafe manner. This of course is to be avoided. The foregoing supervisory agent serves to constrain or otherwise modify human inputs so as to guarantee safe operations with respect to all known environmental conditions. Strictly as one example, a supervisory agent can generate safe signals that govern speed of a manipulation and/or a supervisory agent can generate safe signals that govern the path taken (and safe space buffer required) by any articulation of the robot. There are many ways to implement safe signal generation and governance of a robotic system. On possible approach is shown and described as pertains to
In a second phase (e.g., the shown candidate robotic planning signal generation phase 883), a candidate planning signal 884 is generated. This candidate planning signal corresponds to the real-time signals that would need to be provided to the robotic control system in order to carry out a robotic operation or maneuver. In the illustrative example, the candidate planning signal already has some headroom or margin of error. Specifically, the candidate planning signal 884 corresponds to controlling the robot to maintain an even greater distance away from obstacles in the environment as was predicted in the environmental situation prediction phase 881. This is evident in the plot in that the candidate planning signal is plotted as maintaining an even greater distance away from any obstacle than is plotted by the environmental prediction signal. A candidate planning signal 884 may have within its range any number of local maxima and/or other types of critical points. In the shown example, there is a local maximum at time=T1 and another local maximum at time=T2.
After a candidate planning signal has been generated, possibly under control of an autonomy stack, the safe signal generation technique proceeds to a third phase (e.g., the shown safety constraint gathering phase 885) in which phase various safety constraints are gathered (e.g., from the shown controllable condition safety constraints 849). The specific constraints that are gathered (e.g., applicable safety constraints 889) may depend on whether or not a safe mode indication is enabled and/or whether an override mode indication is enabled, and may further depend on—and correspond to—any one or more of the then-current conditions. For example, if the currently under consideration maneuver requires movement through three dimensional space, then safety constraints corresponding to an X direction as well as safety constraints corresponding to a Y direction as well as safety constraints corresponding to a Z direction are gathered. Furthermore, in this safety constraint gathering phase, constraints pertaining to the mechanisms of the robotic control system are also gathered for potential use in the safety constraint application phase 887.
In most situations, accomplishment of some particular robotic maneuver involves control of actuators and/or control of motors. The operational characteristics of such actuators and/or motors is to be considered in the context of safety constraints. More specifically, application of any set of gathered safety constraints should not result in exceeding the operational capabilities of the robotic control mechanisms (e.g., actuators and/or motors). As an example, one way to avoid an obstacle is to “quickly maneuver” away from the obstacle when approaching it. However, in real robotic systems involving real motors and real actuators, operations intended to “quickly maneuver” are limited by characteristics that are designed into or inherent in the underlying robotic control system. Knowledge of such limitations are often pertinent to safe operation. To further explain, one way to “quickly maneuver” away from the obstacle so as to avoid a collision is to apply a great deal of acceleration in one or more directions that maneuver around or away from the obstacle. However, the amount of force needed to “quickly maneuver” might exceed the capabilities of the robotic control system. As such, safe operation needs to consider the limitations of the robotic control system when applying constraints.
After gathering applicable safety constraints in the safety constraint gathering phase 885, those gathered constraints can be applied. This is shown in
In some cases, a particular incoming candidate planning signal is deemed to be safe even as unmodified (e.g., when the particular incoming candidate planning signal satisfies all applicable constraints). In other cases, a particular incoming candidate planning signal would need to be modified in order to be safe. In this latter case, any number of points and/or any number of ranges of points along the particular incoming candidate planning signal are modified to satisfy all applicable constraints. In the example shown, a particular range of points along the candidate planning signal 884, shown here as modified robotic planning signal range 886, are modified so as to send a ramped control signal (e.g., ramped during the time period from time=T0 and time=T1) to the robotic control system, rather than to apply an impulse signal to the robotic control system.
Of course the foregoing illustrates merely one type of situation. Other situations abound where some aspect of, or information from, the robotic control stack is used to inform how a candidate planning signal should be modified in order to produce a safe robotic control signal.
The foregoing techniques for guaranteeing safe behavior can be implemented in any environment and/or in any robotic system and/or in any deployment scenario. As a first example scenario, consider the situation where a first vehicle is approaching a second vehicle (e.g., in a speed/distance scenario where the first vehicle is a few seconds away from rear-ending the second vehicle. Now, assume unskilled driving where the driver accidentally presses the accelerator rather than the brake. In this situation, one or more safe behavior guarantee modules had prospectively characterized exactly how quickly the car is able to decelerate including consideration of characteristics of the vehicle's braking system, characteristics of the road, consideration of characteristics such as the weight of the vehicle and driver, as well as consideration of how much distance is covered during a braking maneuver. The one or more safe behavior guarantee modules calculates and actuates safe signals such that prior to a collision, the safe signals cause the first vehicle to decelerate (e.g., by applying brakes) on behalf of the driver. As a second example scenario, consider the situation where a robotic arm is repositioning a mechanical member from one position to another position. During the repositioning, a human being walks into the general proximity of the robotic arm. This presents a dangerous condition for the human being. As such, one or more safe behavior guarantee modules are configured to calculate safe parameters based on (1) the velocity (path and speed) of the human walking towards the robotic arm, as well as (2) how quickly the robotic arm can decelerate and stop. The one or more safe behavior guarantee modules use both pieces of information to intercept any unsafe reference signals that were intended to be sent to the robotic arm's actuators and motors. In addition to merely intercepting unsafe signals before they are sent to the robotic arm's actuators and motors, calculated signals are sent to the robotic arm's actuators and motors. As a third example scenario, consider the situation where a semi-autonomous mobile robot is moving around a factory floor. A maximum speed parameter indicates that the mobile robot is limited to less than 2 m/s speed. Now, if the operator instructs the robot accelerate to a speed of 3 m/s., then one or more safe behavior guarantee modules will intervene to intercept signals corresponding to the operator instructions and modify them down to the safe maximum speed of 2 m/s. This particular example might not require characterizing the dynamics of the semi-autonomous mobile robot since, if there is sufficiently accurate absolute position sensor data available (e.g., hi-resolution GPS data) the speed can be limited to the specified 2 m/s.
The foregoing discussion is presented here merely for illustrative purposes. The presence or absence of any particular feature in the drawings is not intended to be limiting. Moreover, the extent or scope of discussion of any particular feature or the absence of discussion of any particular feature is not intended to be limiting.
In the foregoing specification, the disclosure has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure. For example, the above-described process flows are described with reference to a particular ordering of process actions. However, the ordering of many of the described process actions may be changed without affecting the scope or operation of the disclosure. The specification and drawings are to be regarded in an illustrative sense rather than in a restrictive sense.
The present application claims the benefit of priority to U.S. Patent Application Ser. No. 63/516,839 titled “ROBOTIC SIGNAL SUPERVISOR FOR SAFETY GUARANTEES” filed on Jul. 31, 2023, which is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63516839 | Jul 2023 | US |
