Robotic signal supervisor for safety guarantees

Abstract

Methods, systems, and computer program products for robotic systems. A safety guarantee layer enhances robot safety by monitoring, diverting, and modifying robotic signals in real-time. The safety guarantee layer is configured to process signals using knowledge garnered from full system characterization. The safety guarantee layer utilizes advanced control-theory algorithms to (1) analyze planning signals, (2) identify potential hazards, (3) safely divert signals from their originally-intended destinations and, (4) modify such diverted signals in a manner that guarantees safe operation—yet without compromising the fidelity of sought-after operational objectives. Computer-implemented safety protocols take into account the robot's physical capabilities and / or limits, and fast-changing environmental conditions, as well as relevant contextual information. The safety guarantee layer provides real-time environmental adaptation and real-time responsiveness thereby ensuring that the robot operates safely under all conditions. The robotic system can be deployed into virtually any environment and / or for any purpose.

Description

PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 ROBOTIC SIGNAL SUPERVISOR FOR SAFETY GUARANTEES TECHNICAL FIELD

[0001] This disclosure relates to robotics, and more particularly to techniques for making and using an interstitial robotic autonomy supervisory layer. BACKGROUND

[0002] Modern robots comprise a mission planner (e.g., comprised of software components, hardware components, firmware components, etc.) that plans a series of successive states and / or paths (e.g., using velocities and / or trajectories) that are achieved by manipulating the robot in order to achieve a particular mission. Further, nearly all robotic systems comprise a control system (e.g., software components, hardware components, firmware components, etc.) that causes movement of the robotic system (e.g., via application of linear forces and torques) as needed to carry out robotic movements that in turn achieve the planned series of successive states and / or trajectories to accomplish the mission.

[0003] Often a mission is divided into a series of individually describable interim states such that accomplishment of all of the interim states in the prescribed sequence is deemed to correspond to achievement of the mission.

[0004] Unfortunately, even the best planning techniques—regardless of how coarse or how granular the individually describable interim states might be—fail to consider and plan for all extant constraints. Moreover, even the best planning systems might not be able to react fast enough toPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 changing conditions that could at least potentially defeat accomplishment of the robot’s mission and / or might prevent the robot from carrying out the mission in a manner that does not endanger assets (e.g., the robotic systems themselves, infrastructure, humans, etc.). Further, as these planning systems become more and more fully featured, they become more and more complicated, which leads to the undesirable situation that as the more comprehensive and fully-featured the planning system becomes, the less capable the planning system is at reacting to fast changing conditions that could at least potentially defeat accomplishment of the robot’s mission. Moreover, the added complexity makes it significantly more difficult, if not impossible, to verify the robot’s safe and reliable operation.

[0005] The problem to be solved is therefore rooted in various technological limitations of legacy approaches. Improved technologies are needed. SUMMARY

[0006] 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.

[0007] The present disclosure describes techniques used in systems, methods, and computer program products that implement a robotic autonomy supervisory layer, which techniques advance the relevant technologies to address technological issues with legacy approaches. More specifically,PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 the present disclosure describes techniques used in systems, methods, and in computer program products for asset protection using a supervisory layer to intercept and modify robotic system control signals. Certain embodiments are directed to technological solutions for situating an automated safety system between the planning and execution layers of a robotic software stack.

[0008] The disclosed embodiments modify and improve beyond legacy approaches. In particular, the herein-disclosed techniques provide technical solutions that address the technical problems attendant to real-time consideration of dynamically-changing boundary conditions. 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.

[0009] The ordered combination of steps of the embodiments serve in the context of practical applications implement and / or perform steps for operating an automated safety system between the planning and execution layers of a robotic system more efficiently. As such, techniques for situating an automated safety system between the planning and execution layers of a robotic system overcome long-standing yet heretofore unsolved technological problems associated with real-time consideration of dynamically-changing boundary conditions so as to guarantee safe operation.

[0010] Many of the herein-disclosed embodiments for situating an automated safety system between the planning and execution layers of a robotic system are technological solutions pertaining to technological problems that arise in the hardware and software arts that underlie autonomous systems. Aspects of the present disclosure achieve performance and other improvements in peripheral technical fields including, but not limited to, automated safety systems and representation of dynamically-changing constraints.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0011] 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 operating an automated safety system that is situated between the planning and execution layers of a robotic system.

[0012] 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 of an automated safety system that is situated between the planning and execution layers of a robotic system.

[0013] In various embodiments, any combinations of any of the above can be organized to perform any variation of acts for asset protection using a supervisory layer to intercept and modify robotic system control signals, and many such combinations of aspects of the above elements are contemplated.

[0014] In various embodiments, even in the event that there are no robotic system control signals to intercept and modify (e.g., in absence of any planning signals), according to the disclosure herein, various modules can nevertheless be configured to generate safe signals, thereby guaranteeing robotic behavior that does not harm the robot or any beings or equipment or structures that may be present in the environment proximal to the robot.

[0015] Various embodiments include a non-transitory computer readable medium having stored thereon a sequence of instructions which, when stored in memory and executed by one or morePATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 processors, causes the one or more processors to perform a set of acts for configuring a movable mechanical device. In some cases, the set of acts comprise: A. Configuring a diverter module with first interfaces to a robotic control module that operates at least one of, one or more actuators and one or more robotic control sensors, wherein the robotic control module is configured to: 1. Receive robotic control sensor data from the one or more robotic control sensors, and 2. Send control signals to the one or more actuators of the robotic control module; B. Configuring the diverter module with second interfaces to a planning module configured to receive operational instructions from a user or from an autonomy agent, wherein the planning module is configured to generate at least one candidate planning signal based at least in part on the operational instructions, wherein the planning module receives environmental data from environmental sensors, and wherein the at least one candidate planning signal is generated based at least in part on the environmental data from the environmental sensors; and C. Configuring the diverter module to receive at least one of: 1. The operational instructions from a user or from an autonomy agent, and / or 2. The at least one candidate planning signal, wherein the diverter module is interfaced with a safety module that processes the at least one candidate planning signal by applying safety constraints over the at least one candidate planning signal to generate at least one modified planning signal, wherein the diverter module operates to output the at least one modified planning signal rather than the at least one candidate planning signal.

[0016] Various embodiments include interconnected modules of a movable mechanical device. Some embodiments include multiple modules wherein a robotic control module is interfaced with atPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 least one of, one or more actuators and one or more robotic control sensors, and wherein the robotic control module is configured (1) to receive robotic control sensor data from the one or more robotic control sensors, and (2) to send control signals to the one or more actuators of the robotic control module. Such a robotic control module is interfaced with a planning module configured to receive operational instructions from a user or from an autonomy agent. The planning module is configured to generate at least one candidate planning signal based at least in part on the operational instructions. In operation, the planning module receives environmental data from environmental sensors, wherein a particular candidate planning signal is generated based at least in part on the environmental data from the environmental sensors.

[0017] The planning module is interfaced with a diverter module, wherein the diverter module receives at least one of (1) the operational instructions from a user or from an autonomy agent, and / or (2) the at least one candidate planning signal, and wherein the diverter module comprises a safety module that processes the at least one candidate planning signal by applying safety constraints over the at least one candidate planning signal to generate at least one modified planning signal. In operation, the diverter module and / or any modules to which the diverter module is interfaced provides modified planning signals (e.g., modified to be safe signals for the robotic control module), rather than the original candidate planning signals.

[0018] In some embodiments, the safety module analyzes the at least one candidate planning signal, wherein the analyzing includes consideration of at least one of, a temperature, a wear level, one or more faults, and / or one or more alerts.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0019] In some embodiments the safety module further analyzes the at least one candidate planning signal, wherein the analyzing includes consideration of at least one of, a coefficient of friction, structure geometry, and / or the structure’s center of gravity.

[0020] In some embodiments, the safety module further comprises analyzing the at least one candidate planning signal, wherein the analyzing includes consideration of at least one of, motor torque, instantaneous forward acceleration, instantaneous rearward acceleration, instantaneous vertical acceleration, instantaneous lateral acceleration, and / or mass centroid.

[0021] In some embodiments, any one of, or any set of, operational instructions from a user or from an autonomy agent comprise, a move to a final position instruction, a move to an intermediate position instruction, a stop instruction, a reverse instruction, an accelerate instruction, an elevate instruction, a dive instruction, or a rotate instruction.

[0022] In some embodiments, the safety module provides a feedback signal to the planning module. In some embodiments, the feedback signal refers to an override to all or a portion of the operational instructions. In some embodiments, the feedback signal causes actuation of a haptic stimulation. In some embodiments, the safety module performs movement tracking by comparing the then-current environmental measurement data or the then-current trajectory data with respect to an estimate. In some embodiments, the comparing is performed at a determined sample rate, and / or the comparing is performed at a sample rate that is varied dynamically based at least in part on changing conditions. (e.g., wherein the determined sample rate is increased during a maneuver, and wherein the determined sample rate is decreased when the movable mechanical device is dormant or stationary).PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0023] Any of the foregoing embodiments and / or any combinations of any elements of the structural components and / or their functions can be combined, and such combinations are contemplated by the disclosure hereunder.

[0024] Further details of aspects, objectives and advantages of the technological embodiments are described herein and in the figures and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The drawings described below are for illustration purposes only. The drawings are not intended to limit the scope of the present disclosure.

[0026] FIG. 1A1 and FIG. 1A2 show example robotic systems that include a diverter module, according to some embodiments.

[0027] FIG. 1B shows an example robotic system intermodular signal flow that includes a behavioral specification module, according to an embodiment.

[0028] FIG. 1C shows an example safety-constrained robotic system intermodular signal flow that includes a safe behavioral guarantee module, according to an embodiment.

[0029] FIG. 1D shows an example robotic system stack that interfaces an autonomy software stack with a robotic control stack, according to an embodiment.

[0030] FIG. 1E shows a supervisory layer that is configured to provide asset protection by intercepting and modifying robotic system control signals, according to an embodiment.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0031] FIG. 2A depicts a first interlayer signaling technique that is configured to provide asset protection by intercepting and modifying robotic system control signals, according to an embodiment.

[0032] FIG. 2B depicts a second interlayer signaling technique that is configured to provide asset protection by considering characteristics of a robot’s physical control system, according to an embodiment.

[0033] FIG. 3A and FIG. 3B show examples of safe behavior guarantee techniques that implement a multivariate projection module based on real-time parameter and signaling streams, according to some embodiments.

[0034] FIG. 4A shows an example robotic safety constraint generation technique as used in systems that guarantee asset protection by intercepting and modifying robotic system control signals, according to an embodiment.

[0035] FIG. 4B is an example rulebase as used in systems that enforce safety limits to guarantee asset protection, according to an embodiment.

[0036] FIG. 5A1 depicts a first example use case that enforces safety limits to observe structural and / or operational limitations of an asset, according to an embodiment.

[0037] FIG. 5A2 depicts a first multivariate projection technique corresponding to a structural limitation use case, according to an embodiment.

[0038] FIG. 5B1 depicts a second example use case that overrides a human operator to enforce safety limits of an asset, according to an embodiment.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0039] FIG. 5B2 depicts a second multivariate projection technique corresponding to a performance limitation use case, according to an embodiment.

[0040] FIG. 5C1 depicts a third example use case that enforces safety limits to observe specified payload handling limitations, according to an embodiment.

[0041] FIG. 5C2 depicts a third multivariate projection technique corresponding to a payload handling use case, according to an embodiment.

[0042] FIG. 6A and FIG. 6B depict system components as arrangements of computing modules that are interconnected to operate cooperatively so as to implement certain of the herein-disclosed embodiments.

[0043] FIG. 7A depicts a block diagram of an instance of a computer system suitable for implementing embodiments of the present disclosure.

[0044] FIG. 7B depicts an environment in which a behavior guarantee module can be implemented.

[0045] FIG. 7C1 and FIG. 7C2 depict block diagrams showing an interstitially situated supervisory layer, in accordance with some implementations.

[0046] FIG. 7D depicts a safe signal generation technique, in accordance with some implementations.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 DETAILED DESCRIPTION

[0047] Aspects of the present disclosure solve problems associated with using computer systems for real-time consideration of dynamically-changing boundary conditions. These problems are unique to, and may have been created by, various computer-implemented methods for real-time consideration of dynamically-changing boundary conditions in the context of autonomous and semi- autonomous (e.g., robotic) systems. Some embodiments are directed to means for situating an automated safety system between the planning and execution layers of a robotic system. The accompanying figures and discussions herein present example environments, systems, methods, and computer program products for asset protection using a supervisory layer to intercept and modify robotic system control signals. OVERVIEW

[0048] The methods and systems disclosed herein facilitate supervision of planning signals. Such planning signals arise from a planning module. The methods and systems disclosed are configured to intercept at least some of the planning signals of the planning module such that the interception prevents at least some of the planning signals from being transmitted directly to the control stack of the robotic system software stack. As such, in the event that any of the planning signals would even potentially endanger assets (e.g., the robotic systems themselves, infrastructure, humans, etc.), then the intercepted planning signals can be modified prior to being transmitted to a control stack of the robotic system software stack to as to eliminate or probabilistically minimize the potential for endangering the assets. Once a planning signal has been considered and modified, various modified planning signals are passed to the control stack (rather than passing potentially dangerous unmodified planning signals to the control stack).PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0049] In one embodiment, the foregoing planning signals are modified in a manner that changes a trajectory of at least a portion of the robotic system. The modification can cause the robot (or component thereof) to initiate an avoidance maneuver. Such an avoidance maneuver can include changing a speed, or changing a direction, or introducing a wait state for additional information, or initiating an emergency protocol, etc. In some cases an avoidance maneuver is based at least in part on results of processing map data. In some cases an avoidance maneuver is based at least in part on results of processing map data with respect to an obstacle or another robotic system.

[0050] In some cases, a planning signal is modified so as to satisfy the one or more control barrier functions (CBFs), where a control barrier function (CBF) is defined as shown below.

[0051] Let ^ ^ ^^be the set defined by a continuously differentiable function ℎ ∶ ^^→ ^: ^ =^^ ∈ ^^∶ ℎ^^^≥ 0^, ^^ =^^ ∈ ^^∶ ℎ^^^= 0^, ^^^^^^ = ^^ ∈ ^^∶ ℎ^^^ > 0^.

[0052] Then h is a control barrier function (CBF) if ∇ℎ^^^ ≠ 0 for all ^ ∈ ^^ and there exists an extended class K function α such that for all ^ ∈ ^, ∃^ ^. ^.: L^ℎ^^^+!ℎ^^^^ ≥ – #$ℎ^^^%where: ^ℎ^^^ ∶= ∇ℎ^^^'(^^^ and!ℎ^^^∶= ∇ℎ^^^')^^^.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0053] Further details regarding defining and using control barrier functions are described in U.S. Application Ser. No. 18 / 324,718 titled “CONTROLLING A MOVEABLE DEVICE UTILIZING RISK CONTROL BARRIER FUNCTIONS” filed on May 26, 2023, which is hereby incorporated by reference in its entirety. Definitions and Use of Figures

[0054] 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.

[0055] 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 shouldPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 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.

[0056] 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. DESCRIPTIONS OF EXAMPLE EMBODIMENTS

[0057] FIG. 1A1 shows an example robotic system that includes a diverter module. As discussed supra, what is needed is a way to divert and modify (e.g., intercept) planning signals before they reach the actuator subsystem. FIG. 1A depicts a robotic system 1A00 that implements planning signal modification. As an option, one or more variations of the robotic system or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0058] A movable mechanical device (e.g., a robot arm, a robot exoskeleton, an unmanned aerial vehicle, an unmanned terrestrial vehicle, an unmanned waterborne vehicle, an unmanned spacebornePATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 vehicle, etc.) is controlled by a robotic control module 166. Such a robotic control module operates in response to signaling from upstream modules. In the example shown, the robotic control module operates in response to signaling from safety module 177. The safety module in turn processes signals received from a diverter. As such, the safety module is able to ensure that movements of the movable mechanical device comport with movements that are deemed to be safe. To explain, even though a user (e.g., a mission commander or a pilot or a driver, or an operator) or directs the movable mechanical device to carry out some command or other sort of operational instruction does not mean that such carrying out the command or other sort of operational instruction will be safe. For example, in an airborne situation, a user 101 (e.g., an actual human pilot, or a remote control operator), or a planning module 173 can attempt a maneuver that would exceed the structural safety limits (e.g., g force limits) that derive from the design of the airborne vehicle. As another example, in a terrestrial situation, user 101 can “yank the steering wheel of the vehicle 90 degrees counterclockwise” so as to (accidentally or purposely) maneuver the vehicle into oncoming traffic.

[0059] One way to prevent sending unsafe signals to the robotic control module would be to apply limits to signals that are intended for interpretation by the robotic control module. However, this would require some way to intercept signals before they reach the robotic control module. In this embodiment, the mechanism for intercepting signals before they reach the robotic control module is to deploy a diverter module.

[0060] As used herein, a “diverter” or a “diverter module” or the function of “diversion” refers to intercepting a signal from a signal producer, and rather than allowing the signal from the signal producer to be received in an unmodified form by a receiver (e.g., an intended recipient), instead modifying the signal from the signal producer before forwarding the modified signal toward the originally-intended receiver. Modification of the signal from the signal producer includes applicationPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 of advanced control-theory algorithms that analyze signals so as to determine if the signal from the signal producer is a candidates for diversion. In such cases, the advanced control-theory algorithms identify potential hazards inherent in the signaling, and safely divert any potentially hazardous signals from their originally-intended destinations in order to modify the potentially hazardous signals in a manner that guarantees safe operation. If a signal is deemed to be not hazardous, it is directed onward on to its originally-intended destination. In some cases, if a signal is deemed to be not hazardous, it might be modified only in a manner that corresponds to addition of an incremental safety margin, and then passed on to its originally-intended destination. Such an incremental safety margin can be represented as a scalar or as a vector or as a signal. Moreover, an incremental safety margin can be calculated based on then-current environmental conditions.

[0061] As shown in FIG. 1A1, a diverter module 103 includes diverter logic 109 and includes (or is interfaced with) a safety module 177. A diverter module can be configured to receive and process robotic control sensor data 115, which in turn derives from robotic control sensors 117. Further, a diverter module can be configured to receive and process environmental data 119, which in turn derives from environmental sensors 127. Still further, a diverter module can be configured operate in a plurality of modes, examples of which modes are now briefly discussed.

[0062] In a first mode of the diverter, the diverter logic causes signals (e.g., operational instructions 113) that are originally directed down an originally intended path to instead be diverted into the safety module over diverted path 1051. In a second mode of the diverter, the diverter logic causes signals (e.g., candidate planning signals 111) that are originally directed down an originally intended path to instead be diverted into the safety module over diverted path 1052. In both of the foregoing modes (as well as in other modes), the operational instructions or planning signals, rather than ever being received by the robotic control module, are instead diverted into the safety module.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 The safety module in turn can analyze the operational instructions and / or planning signals to determine if the signaling is safe, and then, (1) modify the operational instructions or planning signals in the event that the signals can be modified to be safe, or (2) pass on the operational instructions or planning signals onward to the robotic control module, or (3) ignore the operational instructions and / or planning signals and instead, provide a set of signals to the robotic control module so as to bring the robot to a known safe state. The known safe state might be dependent on environmental data 119. For example, if parking on a slope (e.g., as determined by consideration of environmental sensor data), the steering wheel might be turned toward the curb.

[0063] Now, referring to the case where the diverter module will ignore operational instructions and / or planning signals and instead, provide a set of signals to the robotic control module so as to bring the robot to a known safe state, or perhaps through a sequence of known safe states, one of skill in the art will recognize that there may be many reasons why the ignore operational instructions and / or planning signals are unsafe. One situation where operational instructions and / or planning signals might be unsafe occurs when user 101 is not present and at the controls (or apparently not able to operate the controls) or when the planning module is non-operational or not reachable, or at least where candidate planning signals are not being received by diverter module 103. In such situations, diverter module 103, or more specifically, the diverter logic and the safety module of the diverter module must still operate the robot safely. The foregoing situation and a technique for safe operation is shown and described as pertains to FIG. 1A2.

[0064] FIG. 1A2 shows an example robotic system in a state when user 101 is apparently not able to operate the controls and / or when the planning module is non-operational or non-reachable. As heretofore mentioned, this is a potentially hazardous situation. Accordingly, the diverter module, possibly involving the shown diverter logic can determine that the user is apparently not able toPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 operate the controls, and / or can determine that the planning module is non-operational or non- reachable. Responsive to such a determination, and responsive to any receipt of null signals, the safety module will (1) self-generate planning signals that inform the safety module as to how to output modified versions of the self-generated planning signals, and / or (2) provide self-generated safe signals to the robotic control module, which self-generated safe signals serve to bring the robot to a known safe state.

[0065] The foregoing example robotic system of FIG. 1A1 and FIG. 1A2 are merely for illustration. Many alternative embodiments are possible. Some of such alternative embodiments involve a panoply of constraints, which constraints, singly or in combination inform techniques that generate safe signals under all possible operational situations. More specifically, and as heretofore discussed, many state-of-the-art planning techniques fail to consider and respond to all extant constraints. This and other deficiencies of legacy implementations are remediated by the disclosure herein. The following two figures, FIG. 1B and FIG. 1C are presented on the same sheet so as to facilitate comprehension of the differences between the presented systems.

[0066] FIG. 1B shows an example robotic system intermodular signal flow that includes a behavioral specification module. As an option, one or more variations of robotic system intermodular signal flow 1B00 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0067] The figure is being presented to illustrate how and why a robotic system intermodular signal flow might be configured to include a behavioral specification module.

[0068] In the shown robotic system intermodular signal flow, environmental sensor signals flow from sensing activities (e.g., via environmental sensors module 1821) to robotic actuation (e.g., viaPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 actuator subsystem 1891). A command module 183 comprising one or more autonomy agents 185 is configured to emit operational instructions or commands. Such operational instructions may include any one or more of, a move to a final position, a move to an intermediate position, an instruction to an instruction to stop, an instruction to reverse, an instruction to accelerate, an instruction to elevate, an instruction to dive, an instruction to rotate, and / or other instructions or commands.

[0069] The instructions or commands are considered with respect to then-current sensor information (e.g., as may be provided by the status module 1841), and then passed onward to behavioral specification module 186. The behavioral specification module converts then-current sensor information (e.g., shown as f(x, y, z) and f(dx / dt, dy / dt, dz / dt)) and commands or objectives into actuator signals. Changes (e.g., translations) of the representations of signals may be changed by a signal translation module 188. In some embodiments, various constraints such as are exemplified by robotic control constraints 197 may be provided. In this particular embodiment, robotic control constraints inform the behavioral specification module.

[0070] To appreciate the foregoing, consider that a robot might be given a command to “proceed forward 5 feet.” To do so, the flow considers aspects of the robot’s current position in light of the command, and then presents signals to the actuator module, which signals (e.g., hold down the accelerator to MAX to accelerate at 5ft / sec2for one second) are intended to accomplish the command. In some cases, the behavioral specification module may be informed by robotic control constraints. For example, a robotic control constraint might correspond to the semantics of, “Do not accelerate faster that 5ft / sec2” and / or “Do not exceed a speed of 10 ft / sec.” The behavioral specification module is configured to plan a series of robotic actuations where none of the given robotic control constraints are violated, yet the command can be at least potentially carried out under robotic control.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0071] The foregoing robotic system intermodular signal flow 1B00 is deficient, at least in that it fails to consider environmental conditions, and further in that it fails to consider changing conditions of the actuator subsystem. In the former case, environmental conditions such as a slope over which the robot is to travel might present a constraint in addition to constraints of the actuator subsystem. In the latter case, conditions of the actuator subsystem may influence whether or not the robot can even accomplish such a command. As can now be seen, additional information is needed to overcome the deficiencies of the flow of FIG. 1B. Some means for considering changes in the environment as well as changes in the robotic control system as a whole need to be provided.

[0072] Moreover, such additional information needs to be considered together so as to guarantee expected (and safe) behavior of the robot. One possible arrangement of operational modules that is able to consider changes in the environment as well as changes in the robotic control system so as to guarantee expected (and safe) behavior of the robot is shown and described in FIG. 1C.

[0073] FIG. 1C shows an example safety-constrained robotic system intermodular signal flow that includes a safe behavioral guarantee module. As an option, one or more variations of safety- constrained robotic system intermodular signal flow 1C00 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0074] The figure is being presented in the same sheet as FIG. 1B to illustrate advances needed to overcome the deficiencies of the flow of FIG. 1B. Specifically, FIG. 1C depicts safe behavior guarantee module 187 as well as a plurality of inputs into the safe behavior guarantee module. As shown, the robotic control constraints of FIG. 1B are replaced by robotic safety constraints 199 of FIG. 1C. Any individual instance of any such robotic safety constraints 199 can include bothPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 modified and unmodified instances of robotic control constraints 197 as well as robotic safety constraints that were not present in robotic control constraints 197. In some cases robotic safety constraints 199 may include modified or unmodified parameters that were present in robotic control constraints 197. Additionally or alternatively, robotic safety constraints 199 may include parameters that were not present in robotic control constraints 197 (e.g., generated constraints, possibly in the form of limitations given by one or more CBFs. Still further, various other instances of dynamically- changing system parameters 170 inform robotic safety constraints 199, which in turn are used by the safe behavior guarantee module.

[0075] In addition to being configured to receive robotic safety constraints, the depicted safe behavior guarantee module is configured to receive dynamically-changing environmental parameters (e.g., from the shown environmental parameter gathering module 192 and / or from the shown environmental parameter sending module 194), as well as dynamically-changing system parameters (e.g., from the shown system parameter gathering module 198 and / or from the shown system parameter sending module 196). In this manner the safety-constrained robotic system intermodular signal flow 1C00 is able to consider the robot’s holistic environment, including (1) the external environment, (2) the robot’s own operational characteristics, as well as (3) any user-specified constraints.

[0076] The foregoing embodiment facilitates safe operation of the robot. Moreover, at least inasmuch as the safe behavior guarantee module is provided with sufficient information, it can guarantee safe operation (e.g., within the multi-dimensional boundaries of given constraints).

[0077] To illustrate the operation of the safety-constrained robotic system intermodular signal flow 1C00, consider the situation where command module 183 and / or one or more of its autonomyPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 agents 185 emits a command such as “proceed forward 5 feet.” Those of ordinary skill in the art will appreciate that a command by itself might be prima facie wrong or out of date, or it might be impossible to accomplish, or it might be unsafe given then-current conditions. Accordingly, the command needs to be scrutinized. In some cases a command needs to be scrutinized in multiple dimensions.

[0078] With respect to observing safety dimensions (or other dimensions that relate to safe operation of the robot), the safe behavior guarantee module would need to be informed of the then- current status of environmental sensor data (e.g., as provided by or derived from the status module 1842and / or as provided or derived from the environmental sensors module 1822) as well as safety constraints. In this embodiment, and considering the particular command “proceed forward 5 feet,” safety is guaranteed as is discussed hereunder. Redressing Wrong or Out-of-Date Commands

[0079] With respect to wrong or out-of-date commands, the safe behavior guarantee module would need to check the timestamp of a command to consider; for example, if the robot has already moved “forward” 1 foot, then the command “proceed forward 5 feet” might be recast to “proceed forward 4 feet.” Impossible-to-Accomplish Commands

[0080] With respect to impossible-to-accomplish commands, the safe behavior guarantee module would need to check the timestamp of the command to consider, for example, whether or not the robot has the actual then-current capability to accomplish the command. Continuing a variation ofPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 the foregoing example, given the command “proceed forward 5 feet,” if the environment has an obstruction two feet ahead, then the command might be recast to “proceed forward 1 foot and wait.” Unsafe Commands

[0081] With respect to unsafe commands, the safe behavior guarantee module would need to check the command to consider (for example) whether carrying out the command would at least potentially result in unsafe operation. As another variation of the foregoing example, given the command “proceed forward 5 feet,” if the system parameter gathering module 198 is reporting that the forward motion motor is reporting a fault, then the command might be recast to “wait”.

[0082] The foregoing example is formulated as an illustrative example. With the general understanding of how multiple dimensions are considered for safe operation of a robot, consider that many types of environmental parameters that cover then-current physical conditions (e.g., coefficient of friction 179, slope 171, etc.) as well as many types of mechanics (e.g., structure geometry 175, structure center of gravity 178, etc.) can be provided (e.g., via environmental parameter sending module 194) to the safe behavior guarantee module 187. Further consider that many types of system parameters that cover then-current dynamically-changing system characteristics (e.g., torque values 191, mass centroid value 193 of the robot and its payload, altitude 195 of the robot, and other dynamically-changing system parameters 170) can be provided (e.g., via system parameter sending module 196) to the safe behavior guarantee module. Still further, consider that there are many types of robotic safety constraints that are dynamically formulated based on various then-current system characteristics (e.g., temperature, wear level 172, faults, alerts 176, etc.) as well as many other dynamically-changing system parameters that can be provided (e.g., as codified in the robotic safety constraints) to the safe behavior guarantee module 187.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0083] As can now be understood, to facilitate safe operation, commands to the robot are considered, and possibly modified or countermanded, by the safe behavior guarantee module. To do so implies some mechanism to receive commands and then analyze those commands before the commands reach the robot’s actuator subsystem. One possible technique for doing so is shown and described as pertains to FIG. 1D and FIG. 1E.

[0084] FIG. 1D shows an example robotic system stack that interfaces an autonomy software stack with a robotic control stack. As an option, one or more variations of robotic system stack or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0085] 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 1021) interfaces with an actuator subsystem (e.g., the shown robotic control stack 1041).

[0086] 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 FIG. 1E. A description of the architecture and inner-workings of the autonomy software stack and its interface to the robotic control stack follows.

[0087] As shown, autonomy software stack 1021, is composed of several layers where the layers interoperate so as to carry out specific types of processing. Strictly to illustrate consider the following layer assignments:PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 • Information collection and processing 106: This layer (e.g., information collection and processing 106) collects data from higher-level sensors (such as cameras and LIDARs), as well as high-level actions such as “go to position [X,Y,Z].” Reordered this. • Information consolidation 108: This layer updates the system’s understanding of itself and its environment based on a totality of information. In some cases, this layer interprets the totality of information to resolve to some high-level actions. More specifically, this layer gathers specific parameters that are in turn used for decision making. • Reference generation 110: Reference trajectories are generated based on the system’s understanding of the world, a given mission or objectives on the way to achievement of the given mission, and any constraints given by the operator. Sometimes this activity is referred to as high-level planning. This activity is typically calculated / recalculated at a rate of ~1-10Hz. • Low-level planning 112: A low-level planner takes higher-level reference information such as a sequence of desired waypoints and outputs lower-level reference signals such as velocity commands that can in turn be used to track progression through the sequence of waypoints. This activity is typically calculated / recalculated at a rate of ~10-100 Hz.

[0088] As shown, robotic control stack 1041, 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 following stack architectures: • Stack architecture layer 1: Autonomy stack interface 114: This is where the robotic system sends and receives information from the autonomy stack. It receives necessary information needed for the robot to move, such as the reference signal and some worldPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 information. It sends information to the autonomy stack, either the raw sensor data, or the robot’s estimate of its states. In some cases, this layer includes low-level planning. That is, in some cases, rather doing low level planning in the autonomy stack layer, it is done at the robotic control stack layer. • Stack architecture layer 2: Sensor data collection and processing 116: Here, the robot takes in the real-time sensor data and processes it in a way that gives the robot the ability to track the reference signal. In some systems, state estimation is done in, or by, or under control of, the autonomy stack layer. In such cases, sensor data collection and processing 116 can be used for the purpose of producing feedback signaling responsive to actions pertaining to tracking the control signal (e.g., when an estimate has been provided by the autonomy stack layer), and / or the sensor data collection and processing can be used for direct in situ measurements of the state of the robot (e.g., when an estimate has not been provided by the autonomy stack layer). More specifically, the foregoing sensor data collection and processing involves movement tracking by comparing then-current environmental measurement data and then-current trajectory data with respect to an estimate. • Stack architecture layer 3: Reference tracking 118: This layer implements motor and solenoid actuation. The robot, specifically referring to the processing within this layer uses information from the foregoing layers attempts to track to the reference signal by actuating motors and solenoids. This tracking is calculated / recalculated often, such as at frequencies >1000Hz. As used herein, the action “to track” or the term “tracking” and / or the phrase “tracking [a / the] control signal” refers to comparing actual in situ measurements with respect to an estimate. The rate at which such tracking is accomplished can be variedPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 dynamically based at least in part on a set of measured then-current conditions. Moreover, the rate at which such tracking is accomplished can be initially determined (e.g., statically or dynamically) and then varied to accommodate precision tracking even in the case of rapidly changing conditions. For example, an initially determined sample rate might be increased to a higher rate when the robot is undergoing a particular maneuver, whereas any then-current sample rate might be decreased to a lower rate when the robot is dormant or stationary. • Stack architecture layer 4: Emergency controls 120: This is where safety systems like emergency stops and human takeovers can be implemented to shut off or otherwise override the system’s plan.

[0089] 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.

[0090] As can now be seen, the architecture of legacy implementations such as depicted in FIG. 1D fails to implement any sort of arbitration of signaling between the autonomy software stack and the robotic control stack in a manner that provides for safe operation of the robot over all conceivable operational scenarios. What is needed is a supervisory layer, at least a portion of which is situated between the autonomy software stack and the robotic control stack.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0091] FIG. 1E shows a supervisory layer that is configured to provide asset protection by intercepting and modifying robotic system control signals. As an option, one or more variations of supervisory layer or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0092] FIG. 1E is being presented on the same sheet as FIG. 1D to highlight how a supervisory layer can be situated interstitially between the autonomy software stack and the robotic control stack. Specifically, supervisory layer 124 is juxtaposed between autonomy software stack 1022and robotic control stack 1042. As shown, the supervisory layer is composed of signal interception module 128, signal processing module 130, and a reference signal modification module 132. The supervisory layer (1) receives an ongoing stream of planning signals 122 (e.g., planned trajectories) and environmental information 123, (2) processes those signals in conjunction with the environmental information, (3) and modifies the planning signals to create an ongoing stream of modified planning signals 126 (e.g., with modified trajectories that are guaranteed to be safe). The modified planning signals are provided to the robotic control stack such that the robot can be operated in a safe manner.

[0093] 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. Similarly, although the foregoing discussion characterizes the execution layer as being composed of a robotic control stack, any portion of the execution layer can include or be interfaced with hardware components and / or further software components.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0094] Example implementations of supervisory layers are shown and described as pertains to FIG. 2A and FIG. 2B.

[0095] FIG. 2A depicts a first interlayer signaling technique that is configured to provide asset protection by intercepting and modifying robotic system control signals. As an option, one or more variations of interlayer signaling technique 200 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0096] The figure is being presented to illustrate one possible interlayer signaling technique where the supervisory layer 124 is juxtaposed between autonomy software stack 1022and robotic control stack 1042. In this figure, the supervisory layer (composed of signal interception module 128, a signal processing module 130, and a reference signal modification module 132) includes an analysis module 202 and a parameter modification module 204. The analysis module relies in part on signals that have been converted into an intermediate format (step 201) from received occurrences of planning signals 122, whereas the parameter modification module converts signals (step 205) in this intermediate format into modified planning signals 126 that may have different parameter values, but nevertheless comport with the same format as the signals expected by the robotic control stack 1042.

[0097] The analysis module 202 is configured to be able to direct signals down at least three different paths, based on determined semantics of the signals. Referring to a first path, analysis module 202 might direct signals back to the originator (e.g., back to autonomy software stack 1022) via feedback path 206. In a second path, analysis module 202 might direct signals to signal processing module 130 which in turn may invoke any of a plurality of signal processors (e.g., signal processor P1, signal processor P2, … signal processor PN) . In a third path, analysis module 202PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 might direct signals to the robotic control stack without modification (e.g., without passing through signal processing module 130). This is shown as pass-through path 208.

[0098] In making a determination as to which of the foregoing three path any particular signal should be steered, the analysis module might combine information from the planning signals with information drawn from or derived from any sets of spatial constraints 210 and / or from any sets of additional sensor data 211 received into the supervisory layer, and / or any sets of robotic safety constraints 199.

[0099] As is now understood, some aspects of control of the robot depends on characteristics of the physical control systems of the robot. Accordingly, a supervisory layer can be configured to access any portions of the physical control systems of the robot.

[0100] FIG. 2B depicts a second interlayer signaling technique that is configured to provide asset protection by considering characteristics of a robot’s physical control system. As an option, one or more variations of interlayer signaling technique 200 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0101] The figure is being presented to illustrate one possible interlayer signaling technique where a particular configuration of the supervisory layer 124 is juxtaposed between autonomy software stack 1023and robotic control stack 1043. More specifically, the techniques shown and discussed as pertains to FIG. 2B advance over the techniques of FIG. 2A at least in that FIG. 2B includes a physical control system access path 253. Using this path and / or any corresponding agents (e.g., listeners, interrupt service routines, etc.), attributes of any number of control systems (e.g., robotic control stack 1043, physical control systems 2121, physical control systems 2122,) can bePATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 accessed by the supervisory layer using the shown interrogation protocol 251. Some robotic system implementations include physical actuation systems 214 and / or physical manipulation systems 216. In such implementations, aspects of these physical actuation systems and / or aspects of these physical manipulations systems can be interrogated to retrieve robotic control system parameters 250. Strictly as non-limiting examples, aspects of these physical actuation systems and / or aspects of these physical manipulations systems may include operational rates, operational limitations, age, temperatures, wear conditions, current faults or current alerts, limit breaches, etc. Such robotic control system parameters can be considered when generating guaranteed safe robotic signals. More particularly, asset protection can be facilitated by interpreting characteristics of a robotic control system when formulating signals.

[0102] FIG.3A shows a first example safe behavior guarantee technique that implements a multivariate projection module based on real-time parameter and signaling streams. As an option, one or more variations of safe behavior guarantee technique 300 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0103] The figure is being presented to illustrate how a safe behavior technique might be implemented. In this illustrative embodiment, parameter values are plotted on a multi-variate spider chart. More particularly, three different sets of parameter 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).PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0104] 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 FIG. 3, system parameters 302 are ingested and processed by a system characterization module 304, an ongoing planning signal stream 305 is ingested and processed by an actuator behavior signaling module 312, and an ongoing environmental sensor measurement stream 325 is ingested and processed by an environmental measurement processing module 326. Normalization

[0105] 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) log10of 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.

[0106] Once the three different types of parameters have been prepared for comparison, they can be plotted 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 moment 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 thePATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 same (normalized) value of the torsion limitation. In this case the desired actuation adds very little or no additional torsional force.

[0107] As another example, observe that the value of the shown cycle rate measurement 330 is far lesser 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.

[0108] 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 3360produces the shown resulting multivariate projection 337.

[0109] 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 itsPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 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 as pertains to FIG. 3B.

[0110] FIG. 3B shows a second example safe behavior guarantee technique that implements a multivariate projection module based on real-time parameter and signaling streams. As an option, one or more variations of safe behavior guarantee technique 300 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment. This FIG. 3B is being presented for comparison to the foregoing FIG. 3A. Specifically, the embodiment of FIG. 3B includes a series of robotic safety constraints 199 that are ingested by multivariate projection module 3360. Moreover, for purposes of comparison, FIG. 3B depicts a resulting guaranteed safe projection 338 that is different from the resulting multivariate projection of FIG. 3A. In this example, the difference is because, in addition to the aforementioned three corpora of parameters, multivariate projection module 3360includes inputs that derive from robotic safety constraints 199. As shown, the robotic safety constraints may be expressed in normalized forms (e.g., as normalized values 334) and / or may include further safety limits (e.g., alpha safety limit 335) that correspond to respective incoming signals (e.g., alpha signal 362) and / or may correspond to limits that are received from other sources (e.g., alpha limit 360 as received from system characterization module 304).

[0111] 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= TorqueSOURCE1PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 + 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 TorqueSOURCE1to be greater than 90 foot-pounds of torque”). For ease of illustration, an example involving static robotic safety limitations is presented hereunder.

[0112] The foregoing discussions refer to uses of robotic safety constraints for guaranteeing safe robot behavior. One possible technique for generating such robotic safety constraints is shown and described as pertains to FIG. 4A.

[0113] FIG. 4A shows an example robotic safety constraint generation technique as used in systems that guarantee asset protection by intercepting and modifying robotic system control signals. As an option, one or more variations of robotic safety constraint generation technique 4A00 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0114] The figure is being presented to illustrate how robotic safety constraints can be derived from (1) the results of interrogation of a robotic autonomy stack combined with (2) the results of an interrogation of a robotic control stack. More particularly, the figure is being presented to explain how characteristics of an autonomy stack that forms a portion of a planning module can be interpreted for purposes of generating or modifying planning signals prior to sending such signals to a robotic control stack.

[0115] The example robotic safety constraint generation technique includes a processing flow that can be initiated at any moment in time and / or beginning from any point in the flow. As such, the designation START is merely an example. In fact, in some embodiments, each of the steps of the flow (e.g., step 402, step 412, step 420, and step 426) can operate autonomously and continuouslyPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 during operation of the robot. Regardless of whether the steps of the flow operate in a fully sequential manner or in a partially sequential manner, or in a fully concurrent manner, or in a partially concurrent manner, the results of execution of the steps results in storage of various instances of robotic safety constraints.

[0116] Step 402, as shown, interrogates an autonomy stack to determine how commands are represented. More specifically, step 402 interrogates an autonomy stack to determine planning signal representation and meaning. This step is carried out because each individual robot might have variations in the way the autonomy stack and / or variations in the way that any planning modules are implemented. In some cases, the autonomy stack and / or any planning modules are provided by a third-party. In some cases, the autonomy stack and / or any planning modules implement and / or comport with an interfacing standard. In some cases, the autonomy stack and / or any planning modules comport partially with an interfacing standard and partially with the aforementioned third- party’s proprietary interfacing mechanisms.

[0117] As shown, the results of execution of step 402 include a series of signal specifications (e.g., signal specification1414, signal specification2416, …, signal specificationN418). Such signal specifications are codified in a manner such that a robotic control stack can be configured to comport with the determined representation and meaning of the signals from the autonomy stack.

[0118] Step 412, as shown, represents merely one technique for interrogating a robotic control stack to determine operational limitations. In some cases, interrogation includes sending signals that correspond to the foregoing signal specifications to a robotic control stack. In some cases, interrogation includes sending calibration signals to the robotic control stack, and then measuring the robot’s actual response to the calibration signals. In some cases the robot’s actual response will bePATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 different from a calibration command. Such differences can be determined by comparing sensor data (e.g., received from or derived from the shown sensors module 1823) with actuator data (e.g., received from or derived from the shown actuator subsystem 1892). The configuration of actuator subsystem 1892of FIG. 1C may differ from the configuration of actuator subsystem 1891of FIG. 1B, at least in that the configuration of actuator subsystem 1892of FIG. 1C interfaces with a system parameter gathering module (as shown). Such gathered system parameters may be used to inform, directly or indirectly, the safe behavior guarantee module.

[0119] To further explain, consider the case where a series of calibration signals such as (a) “Move 5 feet forward” and (b) “Move 5 feet backward” are sent in a non-overlapping sequence to the robot. The actual sensor data and / or the actual actuator data might indicate that the robot only actually moved 4.95 feet in response to the “Move 5 feet forward” command signals. Continuing, consider the case where, in response to the command, “Move 5 feet backward” the actual sensor data and / or the actual actuator data indicates that the robot actually moved 5.05 feet backward. Repeated calibration commands and comparison with actual measurements serve to establish dynamically- determined limits (e.g., limit1406, limit2408 …, limitN410). In this case, the dynamically- determined limit is a dynamically-determined accuracy limit (e.g., ±1%) that the planning system and control system can use. In this specific example, the planning system can use the determined limit on accuracy to be sure that the robot avoids an obstacle with the knowledge that the “Move” command, once executed, is only accurate within plus or minus one percent.

[0120] It should be noted that a particular limit value at one moment in time might be superseded by a different limit value at a later moment in time. More particularly, it can happen that mechanical components of a robotic control system can wear over time, and as a consequence of such wear, accuracy in carrying out a robotic command may vary with the extent of the wear.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0121] Now, recalling the discussions pertaining to normalization (e.g., from FIG. 3A), a means for dynamically normalizing parameters (e.g., based on a particular implementation and state of the autonomy stack) is to be provided. Step 420 is one example of a means for dynamically normalizing parameters. In the embodiment depicted in FIG. 4A, the signal specifications as well as their corresponding limits are analyzed. The results of such analysis includes normalized parameter representation 422 as well as normalized constraints 424. Strictly as an example, consider a robotic command, “Move 5 feet forward.” This might be expressed in computer code as “Move(param1=5, param2=“+”),” where param1 is an integer expressing a distance in units of feet and param2 is a string or character value of either “+” (for forward) or “–” for backward. Now consider that a preferred representation is to express the distance asinteger number of inches. In this example, the normalized parameter representation is in inches, so a given instruction (e.g., from an autonomy stack) in the form as “Move(param1=5, param2=“+”),” is recoded into its normalized form, as in “Move(param1N=60, param2=“+”),” where param1N is a normalized parameter in the form of an integer expressing a distance in units of inches.

[0122] Strictly as nonlimiting examples, parameters, including normalized parameters might include a measured instantaneous forward acceleration value, a measured instantaneous rearward acceleration value, a measured instantaneous vertical acceleration value, a measured instantaneous lateral acceleration value, or a motor torque, or a mass centroid.

[0123] Step 420 can be informed from safety data that corresponds to one or more particular safety regimes (e.g., safety regime specification 421). Such a regime can be codified into rules that pertain to safe ranges (e.g., safe range rules 423), rules that specify or otherwise pertain to preferred normalization techniques (e.g., normalization rules 425), and rules that specify or otherwise pertain to preferred representation techniques (e.g., representation rules 427).PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0124] By applying rules from the foregoing safety regime specification, corresponding constraints that are codified to comport with rules from the foregoing safety regime specification can be output as normalized constraints 424. Any number of normalized constraints can be stored (e.g., at step 426) into a repository of robotic safety constraints 199.

[0125] Rules of any complexity or hierarchy can be included in the foregoing safety regime specification. In some cases a particular rule has semantics that pertain to multiple parameters or limits. A rulebase containing examples of such multi-parameter rules is shown and described as pertains to FIG. 4B.

[0126] FIG. 4B is an example rulebase as used in systems that enforce safety limits to guarantee asset protection. As an option, one or more variations of rulebase 4B00 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0127] The figure is being presented as a table to illustrate one example of how particular rules can include semantics that are derived from operational parameters and their corresponding safety parameters. In the example shown, three operational parameters that are commonly found in robotic systems are considered with respect to safe operation. The three example operational parameters are now briefly discussed. Rotational Angle

[0128] A component of a robot might be operationally capable of excursion through a wide range of angles (e.g., 0 degrees through 360 degrees) however, it might be deemed that excursion through a narrower range of angles (e.g., to a maximum of only 270 degrees) is safe. Accordingly, aPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 rule that has the semantics of, “limit rotational angle to no more than 270 degrees” might be defined. In operation, and in accordance with the embodiments disclosed herein, excursion beyond the limit of the narrower range of angles is guaranteed, regardless of whether or not a robotic command specifies a rotational angle of greater than 270 degrees. Some implementations provide particularly configured feedback signals from a supervisory layer back to an autonomy software stack. Strictly as examples, such feedback signals can correspond to override signaling back to an autonomy software stack, or such feedback signals can correspond to override signaling back in the form of a haptic stimulation that is intended to be felt by and interpreted by a human operator.

[0129] In exemplary cases, a particular safety parameter and / or its corresponding rule(s) consider multiple input parameters. In some cases, a particular safety parameter and / or its corresponding rule(s) consider combinations of (1) static input parameters, and (2) dynamically- changing input parameters. Strictly as one example a maximum safe rotational angle might be derived from consideration of a then-current (e.g., dynamically-changing) coefficient of friction (e.g., as a robot moves across a nonuniform surface). Continuing to explain this example, a safety parameter in the form of a maximum safe rotational angle might actually be a series of maximum safe rotational angle specifications that change in response to changes in the coefficient of friction between the robot and a surface. A dynamically-changing safety parameter, and more particularly, a time-oriented series of dynamically-changing safety parameters, can be represented as a time- varying signal. Such a time-varying signal can be represented as a series of discrete samples, or such a time-varying signal can be represented as a continuous wave (e.g., via a mathematical formula such as “sin(x)”), such a time-varying signal can be represented as or one or more segments of differing continuous wave portions.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 Acceleration

[0130] A robot might be capable of acceleration in any direction. In some cases, an acceleration is caused by operation of a robot’s actuators. In other cases, an acceleration is caused by operation of the robot in its environment such as when the robot traverses a path while subject to gravitational forces. In still other cases, acceleration is caused by combining a speed with an externally forced change in direction, such as when a robot executes a maneuver into the wind, or when a robot’s path is constrained by a stationary physical feature (e.g., a roadway, or a guideway, or a slot, or some other feature that causes the robot to follow a predefined trajectory).

[0131] Safety parameters pertaining to acceleration can be defined in any dimension. Moreover, safety parameters pertaining to acceleration can be defined in whatever dimensions are applicable for a particular payload (if any). Strictly as an example, consider a payload of crates of pineapples that are packaged to withstand twice the force of gravity during carriage. Further consider that the pineapples are not packaged to withstand significant forces in lateral directions. In this situation, the meaning of “safe” may encompass “non-damaging” transport of the payload. As such, acceleration in each dimension {x, y, and z} may have its own corresponding limit. Moreover, each acceleration in each dimension may be determined based on characteristics of a payload. Certain characteristics of a payload can be specified, for example, based on characteristics of a payload, or such characteristics can be determined empirically. Additionally or alternatively, certain characteristics of a payload can be determined by a human practitioner. For example, a human practitioner might indicate that humans can only comfortably withstand less than 32 feet / sec2of lateral acceleration.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 Torque

[0132] Many robotic systems include and / or are integrated with mechanical members that undergo rotation during robotic maneuvers. Such mechanical members have failure limits that correspond to characteristics of the mechanical members. In the specific case of mechanical members (e.g., axles, wheels, etc.) that are operated by or otherwise undergo rotational forces (e.g., torque), safe operation encompasses the meaning of “non-damaging” to the mechanical member. In some situations, safe operation encompasses the meaning of “within manufacturer’s specifications” for operation. As such, a safety parameter referring to torque may be defined or derived from any one or more of, a maximum change in rotational forces, a maximum moment, or a rotational safety factor. A rotational safety factor in turn may be a ratio or an absolute value or a mathematical and / or logical function.

[0133] As can be seen from the foregoing discussion, safe operation means that safety limits are observed so as to observe structural and / or operational limitations of a robotic system and / or its payload. What follows are illustrative use cases where, in accordance with the embodiments described herein, safe behavior is guaranteed by continually enforcing safety limits.

[0134] FIG. 5A1 depicts a first example use case that enforces safety limits to observe structural and / or operational limitations of an asset. As an option, one or more variations of use case 5A100 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0135] The figure is being presented to illustrate a case where a robotic control system is configured with a multi-variate projection module that produces a controllable safety parameter. Specifically, the figure is being presented to illustrate the case where a multi-variate projectionPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 module considers environmental variables, in this case the strength of tower member 510, when producing a controllable safety parameter. As is known in the art, a wind turbine produces nearly no lateral forces onto the tower when the turbine blades are freely-rotating. However, when the torque of the wind turbine is used to turn the armature of an electricity generator, a lateral force is asserted on the tower (e.g., the shown lateral force from torque 508). The moment M 502 arising from that lateral force is related to rotational torque 504 and the height 506 of the tower. In this example, the height of the tower is fixed by virtue of its structural / geometric design, however the electrical load placed on the generator is controllable by controlling the electrical load on the generator. As such, a there is a safe limit of the electrical load such that moment M never exceeds some calculable safe limit that is a function of (at least) the structure geometry and materials of the tower. The example of FIG. 5A1, shows a dynamically calculable safe limit that is a function of two dynamically changing signals, namely the then-current maximum dynamic moment (e.g., MDYNAMIC) and a then-current dynamically-changing safety factor 532 (e.g., SFDYNAMIC).

[0136] FIG. 5A2 depicts a first multivariate projection technique corresponding to the structural limitation use case shown in FIG. 5A1. As an option, one or more variations of first multivariate projection technique 5A200 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0137] As shown, the multivariate projection module 3362inputs a maximum value of a generated moment MGENERATED512 as well as a safe moment value MSAFE5141. These two input parameters are superimposed using the multivariate projection module. In this case, the output of the multivariate projection module is a maximum safe electrical load value (shown as controllable safety parameter 5181). It should be emphasized that exemplary implementations of a multivariate projection module are configured to be able to distinguish between controllable parameters (e.g., thatPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 can be controlled by operation of any one or more components of the robot) versus parameters that are either fixed or controlled by some entity other than the robot itself. In the example use case of FIG. 5A1, the height of the tower is dominant in calculations of forces and safety factors, however the height is not controllable by the robot.

[0138] Continuing this example, even though the manufacturer of the wind turbine specifies a maximum value of a generated moment at the axle of the turbine (e.g., generated moment MGENERATEDmax value = 80), a safer moment value (e.g., safe moment value MSAFEmax value= 40) has a lower value, which safer moment value can be observed by dynamically controlling the electrical load on the generator. As such, a there is a safe limit of the electrical load such that the total moment M never exceeds some calculable safe limit that is a function of (at least) the structure geometry and materials of the tower. The example of FIG. 5A2, shows a dynamically calculable safe limit that is a function of two dynamically changing signals, namely the then-current maximum dynamic moment (e.g., MDYNAMIC) and a then-current dynamically-changing safety factor 532 (e.g., SFDYNAMIC).

[0139] The foregoing is an example use case where operation of the system and observance of safety limitations is fully under control of the robot, however the are other cases where operation of the system is partially under control of a human operator and partially under control of the robot.

[0140] FIG. 5B1 depicts a second example use case that overrides a human operator to enforce safety limits of an asset. As an option, one or more variations of use case 5B100 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0141] The figure is being presented to illustrate a use case where a robotic system enforces limits to observe safe operation of a robotic asset. In this particular use case, a human operator 521 can at least potentially place the asset in jeopardy merely based on the operator’s choices (e.g., where to steer the asset, when to steer the asset, etc.). Protection of the asset from destruction and / or protection of the human operator from possible injury can be accomplished using the herein- disclosed techniques.

[0142] As shown, the human is operating the asset at an operating angle theta (e.g., operating angle 526). When operating at an angle, the force of gravity causes a moment at whatever is the then-current center of gravity 520. The center of gravity changes dynamically, therefore the torque on the asset (e.g., the instantaneous moment MDYNAMIC524) changes dynamically. In turn, changes of the torque on the asset is dominantly a function of the instantaneous height of the center of gravity (e.g., instantaneous height HDYNAMIC522). The height of the center of gravity changes partially as a function of the slope of the terrain and partially as a function of the irregularities in the terrain. Any / all of these dynamic variables can be considered in a multivariate projection, an example of which is shown and described as pertains to FIG. 5B2.

[0143] FIG. 5B2 depicts a second multivariate projection technique corresponding to a performance limitation of the use case shown in FIG. 5B1. As an option, one or more variations of second multivariate projection technique 5B200 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0144] The figure is being presented to illustrate how and why a particular multivariate projection technique might be configured to correspond to a performance limitation use case.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0145] As shown, the multivariate projection module 3363inputs an instantaneous moment 528 as well as a safe moment value MSAFE5142. These two input parameters are superimposed using the multivariate projection module. In this case, the output of the multivariate projection module is a maximum safe angle (shown as controllable safety parameter 5182). It should again be emphasized that exemplary implementations of a multivariate projection module are configured to be able to distinguish between controllable parameters (e.g., that can be controlled by operation of any one or more components of the robot) versus parameters that are either fixed or controlled by some entity other than the robot itself. In the example use case of FIG. 5B1, both the operating angle 526 (theta) and the speed of operation are controllable by the human operator, at least by manipulating steering controls (e.g., a steering wheel) and by manipulating speed controls (e.g., a throttle or accelerator pedal as well as a braking mechanism), which combination of human-provided inputs in turn controls the asset’s trajectory.

[0146] Continuing this example, there is a safe moment value MSAFE5142that is a fractional ratio (e.g., based on safety factor 532). In the event that the operator presents signals (e.g., steering and throttle controller output signals) that can be predicted to operate the asset in an unsafe manner (e.g., in a manner that exceeds safe moment value MSAFE5142) then the operator’s attempt can be overridden in favor of using safe signals, thereby guaranteeing safe operation.

[0147] The foregoing is an example use case where operation of the system’s observance of safe operation of an asset is partially under control of a human operator and partially under control of the robot. There are, however, other use cases where safe operation pertains particularly to characteristics of the robot’s payload. Such a use case is shown and described as pertains to FIG. 5C1 and FIG. 5C2.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0148] FIG. 5C1 depicts a third example use case that enforces safety limits to observe specified payload handling limitations. As an option, one or more variations of use case 5C100 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment.

[0149] The figure is being presented to illustrate how a use case might be configured so as to be able to observe specified payload handling limitations. As heretofore mentioned, safety parameters pertaining to acceleration can be defined in whatever dimensions are applicable for a particular payload. Given the situation presented in FIG. 5C1, acceleration that act on a payload can be characterized and limited in terms of Earth’s gravitation. This is shown by acceleration vector G, which is a constant or nearly constant acceleration of 32 ft / sec2. Calculation of limits of accelerations and / or limits of forces in any dimension (e.g., x, y, z) can take into account this acceleration vector G. It should be noted that many of the foregoing examples of limits include the semantic that a quantity is to be limited to some maximum.

[0150] However, embodiments of the present disclosure include semantics that refer to a limit as a minimum. To illustrate, consider the curvilinear path depicted in FIG. 5C1. Note that there are various points of greater or lesser curvature in the curvilinear path. Further note that there is a point of maximum curvature 531. It is at this point where a minimum speed along the path needs to be considered in order to subject the payload to an artificial gravity so as to prevent the payload from being subjected to out of bounds forces. For example, in some situations, it is necessary to subject the payload to an artificial gravitational force so as to prevent the payload from falling out or otherwise becoming separated from the robot. As such, the speed of the robot and its payload need to be sufficiently high to produce the needed artificial gravitational force. This leads to the need for being able to define a limit as a minimum. In the foregoing scenario, where the robot and its payloadPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 are at the point of maximum curvature 531, the robot’s speed must be at least high enough to produce (for example), 1G of acceleration in the z direction (e.g., upwards) so as to counteract the Earth’s gravitational force (downwards).

[0151] The foregoing leads to the need to generally be able to define a particular limit parameter in terms of a minimum. Further, the foregoing generalization leads to the need to be able to define limit parameters as a range that is bounded by both a minimum and a maximum.

[0152] The foregoing written description pertains to merely one possible embodiment and / or way to address use case 5C100; many variations are possible. One particular implementation of a multivariate projection technique that comprehends limit parameters as ranges is shown and described as pertains to FIG. 5C2.

[0153] FIG. 5C2 depicts a third multivariate projection technique corresponding to a payload handling use case as shown in FIG. 5C1. As an option, one or more variations of third multivariate projection technique 5C200 or any aspect thereof may be implemented in the context of the architecture and functionality of the embodiments described herein and / or in any environment. FIG. 5C1 is not necessarily to scale, but it nevertheless is presented here for illustrative purposes.

[0154] FIG. 5C2 shows several inputs into multivariate projection module 3363, where a first set of inputs pertain to accelerations (e.g., dx / dt, dy / dt, dz / dt) over segments (e.g., XSEGMENT, YSEGMENT, ZSEGMENT) that form a traversal path, and where a second set of inputs pertain to safe ranges (range dx / dt, range dy / dt, range dz / dt). These two sets of inputs can be recoded into an optimization problem that calculates a value (e.g., an optimized value or at least a feasible value) for one or more safety parameters subject to constraints or limits (e.g., either ranges of maximum orPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 minimum limits or ranges of both maximum and minimum limits). As shown, the multivariate projection module produces a controllable safety parameter 5183which, in the shown example, refers to a speed of traversal for a particular segment (e.g., speed SpeedSEGMENT).

[0155] More specifically, the multivariate projection module considers predicted accelerations (e.g., predicted dx / dt 534, predicted dy / dt 538, predicted dz / dt 536), in order to determine then- present risk profile (e.g., via any manner of risk value representations and semantics), as well as whether or not, and how, those predicted accelerations need to be modified (e.g., by corresponding dynamically-changing accelerations to dynamically-controllable accelerations or safety parameters) in order to stay within the given limits and / or in order to stay within a given risk profile. In this particular example, the given limits (e.g., range dx / dt, range dy / dt, range dz / dt) define a safe range minimum contour (e.g., safe range min contour 543) as well as a safe range maximum contour (e.g., safe range max contour 541).

[0156] Further details regarding general approaches to defining safe range contours are described in U.S. Application Ser. No. 18 / 297,525 titled “SYSTEMS AND METHODS FOR MODEL-FREE SAFETY CONTROL IN ROBOTICS PLATFORMS” filed on April 7, 2023, which is hereby incorporated by reference in its entirety.

[0157] The foregoing [x, y, z] designation of directions in 3-dimensional space relative to the surface of the earth is an arbitrary choice and designation, and is used in the descriptions above merely for illustrative purposes. Other representations of motion and other representations of semantics of motion are possible. For example, force vectors might be defined with respect to a vector that is normal to some particular surface of the robot body.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 ADDITIONAL EMBODIMENTS OF THE DISCLOSURE Instruction Code Examples

[0158] FIG. 6A depicts system components as an arrangement of computing modules that are interconnected so as to operate cooperatively to implement certain of the herein-disclosed embodiments. This and other embodiments present particular arrangements of elements that, individually or as combined, serve to form improved technological processes that address real-time consideration of dynamically-changing boundary conditions. The partitioning of system 6A00 is merely illustrative and other partitions are possible.

[0159] FIG. 6A depicts a block diagram of a system to perform certain functions of a robot. As an option, the system 6A00 may be implemented in the context of the architecture and functionality of the embodiments described herein. Of course, however, system 6A00 or any operation therein may be carried out in any desired environment.

[0160] As shown, system 6A00 comprises at least one processor and at least one memory (not shown), the memory serving to store program instructions corresponding to the operations of the system. An operation (e.g. implemented in whole or in part using program instructions) is connected to a communication link 6A05, and any module can communicate with any other modules over communication link 6A05. The modules of the system can, individually or in combination, perform method steps within system 6A00. Any method steps performed within system 6A00 may be performed in any order unless as may be specified in the claims.

[0161] As shown, FIG. 6A implements a system 6A00, comprising one or more program instructions that implement: a robotic control module being interfaced with at least one of, one or more actuators, one or more motors, and one or more robotic control sensors, wherein the roboticPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 control module is configured (1) to receive robotic control sensor data from the one or more robotic control sensors, and (2) to send control signals to the one or more actuators of the robotic control module (module 6A10); a planning module configured to send planning signals, the planning module configured to receive operational instructions from a user or from an autonomy agent, wherein the planning module is configured to generate at least one candidate planning signal based on the operational instructions, and wherein the planning module receives environmental data from environmental sensors and wherein the planning module creates the at least one candidate planning signal to fulfill the operational instructions, and wherein the at least one candidate planning signal is based at least in part on the environmental data from the environmental sensors (module 6A20); and a safety module that processes the at least one candidate planning signal by applying safety constraints of an interstitial supervisory layer to generate at least one modified planning signal, wherein, in operation, the at least one modified planning signal, rather than the at least one candidate planning signal, informs the robotic control module to activate or deactivate individual physical control system components in accordance with the safety constraints (module 6A30).

[0162] 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. Some embodiments include variations in the operations performed, and some embodiments include variations of aspects of the data elements used in the operations. Still further, some embodiments correspond to computer-aided configurations of the deployed system(s). One possible example of pre-deployment and / or in situ deployment is shown and described as pertains to FIG. 6B.

[0163] FIG. 6B depicts system components as an arrangement of computing modules that are interconnected so as to operate cooperatively to implement certain of the herein-disclosedPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 embodiments. The partitioning of system 6B00 is merely illustrative and other partitions are possible. As an option, system 6B00 may be implemented in the context of the architecture and functionality of the embodiments described herein. Of course, however, system 6B00 or any operation therein may be carried out in any desired environment, including in pre-deployment environments and / or in situ deployment environments.

[0164] As shown, the depicted system comprises a plurality of modules, a module comprising at least one processor and a memory, each connected to a communication link 6B05, and any module can communicate with other modules over communication link 6B05. The modules of the system can, individually or in combination, perform method steps within system 6B00. Any method steps performed within system 6B00 may be performed in any order unless as may be specified in the claims.

[0165] As shown, system 6B00 implements a method for configuring a movable mechanical device, the system 6B00 comprising modules for: configuring a diverter module with first interfaces to a robotic control module that operates at least one of, one or more actuators, and one or more robotic control sensors, wherein the robotic control module is configured (1) to receive robotic control sensor data from the one or more robotic control sensors, and (2) to send control signals to the one or more actuators of the robotic control module (module 6B10); configuring the diverter module with second interfaces to a configured to receive operational instructions from a user or from an autonomy agent, wherein the planning module is configured to generate at least one candidate planning signal based at least in part on the operational instructions, wherein the planning module receives environmental data from environmental sensors, and wherein the at least one candidate planning signal is generated based at least in part on the environmental data from the environmental sensors (module 6B20); and configuring the diverter module to receive at least one of, (1) thePATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 operational instructions from a user or from an autonomy agent, or (2) the at least one candidate planning signal, wherein the diverter module comprises a safety module that processes the at least one candidate planning signal by applying safety constraints over the at least one candidate planning signal to generate at least one modified planning signal, wherein, the diverter module operates to output the at least one modified planning signal, rather than the at least one candidate planning signal (module 6B30). ADDITIONAL SYSTEM ARCHITECTURE EXAMPLES

[0166] FIG. 7A depicts a block diagram of an instance of a computer system suitable for implementing embodiments of the present disclosure. Computer system 7A00 includes a bus 706 or other communication mechanism for communicating information. The bus interconnects subsystems and devices such as a central processing unit (CPU) or a multi-core CPU (e.g., data processor 707), a system memory (e.g., main memory 708 or an area of random access memory (RAM)), a non- volatile storage device or non-volatile storage area (e.g., read-only memory 709), a storage device that uses semiconductor memory or magnetic or optical technologies (e.g., internal storage device 710), a data interface 733, and a communications interface 714 (e.g., PHY, MAC, Ethernet interface, modem, etc.). The aforementioned components are shown within processing element partition 701, however other partitions are possible. Computer system 7A00 further comprises a display 711 (e.g., CRT or LCD), various input devices 712 (e.g., keyboard, cursor control, etc.), and an external data repository 704.

[0167] According to some embodiments of the disclosure, computer system 7A00 performs specific operations by data processor 707 executing one or more sequences of one or more program instructions contained in a memory. Such instructions (e.g., program instructions 7021, programPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 instructions 7022, program instructions 7023, 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.

[0168] According to an embodiment of the disclosure, computer system 7A00 performs specific networking operations using one or more instances of communications interface 714. Instances of communications interface 714 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 714 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 714, and data (e.g., packets, data structures, bit fields, etc.) can be positioned in storage locations within communications interface 714 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 707.

[0169] Communications link 715 can be configured to transmit (e.g., send, receive, signal, etc.) any type of communications packets (e.g., communication packet 7381, …, communication packet 738N) comprising any organization of data items. The data items can comprise a payload data areaPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 737, a destination address field 736 (e.g., a destination IP address), a source address field 735 (e.g., a source IP address), and can include various encodings or formatting of bit fields to populate packet characteristics 734. 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 737 can comprise a data structure that is encoded and / or formatted to fit into byte or word boundaries of the packet.

[0170] 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.

[0171] The terms “computer readable medium” or “computer usable medium” as used herein refer to any medium that participates in providing instructions to data processor 707 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.

[0172] 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 713, and / or in any form of an external data repository 704, either of which can be formatted into any one or morePATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 storage areas. Certain forms of computer readable media comprise parameterized storage 739 accessible by a key (e.g., filename, table name, block address, offset address, etc.).

[0173] Execution of the sequences of instructions to practice certain embodiments of the disclosure are performed by a single instance of a computer system 7A00. According to certain embodiments of the disclosure, two or more instances of computer system 7A00 coupled by a communications link 715 (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 7A00.

[0174] Computer system 7A00 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 703) communicated through communications link 715 and communications interface 714. Received program instructions may be executed by data processor 707 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 7A00 may communicate through a data interface 733 to a database 732. 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.

[0175] Processing element partition 701 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 directlyPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 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.

[0176] 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 707, 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.

[0177] Various implementations of database 732 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. ThePATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 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.

[0178] FIG. 7B depicts an environment in which a behavior guarantee module can be implemented. As shown, environment 7B00 includes an example software library 716. Such a library can be situated in a development environment or such a library, either in whole or in part, can be deployed to the field for dynamic linking and loading. Strictly as one example, various components from such a software library can be interfaced together to form variations of a behavior guarantee module. Strictly as an illustration, a behavior guarantee module (e.g., example behavior guarantee module implementation 741) can be constructed of one or more environment interface modules 717, one or more component interface modules 721, one or more signal processing modules 725, and / or any one or more value processing modules 729. The foregoing environment interface modules, component interface modules, signal processing modules, and value processing modules are discussed in further detail hereunder.

[0179] As shown, environment interface modules 717 include a selectable set of environment sensor interface modules (e.g., environment sensor interface module 7181, environment sensor interface module 7182, …, environment sensor interface module 718N; human I / O module 7191, human I / O module 7192, …, human I / O module 719N; and artificial intelligence I / O module 7201, artificial intelligence I / O module 7202, …, artificial intelligence I / O module 720N). Any of the foregoing constituents of the environment interface modules can be configured for any particularPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 application. Any combination of environment interface modules can be juxtaposed in any topology and / or in any order or organization.

[0180] As shown, component interface modules 721 include a selectable set of component sensor modules (e.g., autonomy stack interface module 7221, autonomy stack interface module interface module 7222, …, autonomy stack interface module 722N; and robotic control stack module 7231, robotic control stack module 7232, …, robotic control stack module 723N). 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.

[0181] As shown, signal processing modules 725 include a selectable set of various signal processing modules (e.g., signal conditioning module 7261, signal conditioning module 7262, …, signal conditioning module 726N; signal translation module 7271, signal translation module 7272, …, signal translation module 727N; and signal prioritization module 7281, signal prioritization module 7282, …, signal prioritization module 728N). 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.

[0182] As shown, value processing modules 729 include a selectable set of various value processing modules (e.g., constraint processing module 7301, constraint processing module 7302, …, constraint processing module 730N; component health processing module 7311, component health processing module 7312, …, component health processing module 731N; and system characterization module 7401, system characterization module 7402, …, system characterization module 740N). AnyPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 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.

[0183] The particular deployment shown includes an example supervisory layer implementation 772. 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 7431, and optimization problem solver implementation 7432). 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 742. Those updated real-time condition signals can be combined with an ongoing stream of real-time constraint signals 755 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.

[0184] The ongoing stream of real-time constraint signals 755 can derive from any combination of environmental safety constraints 750 and / or any combination of controllable condition safety constraints 749. In some cases, the ongoing stream of real-time constraint signals is output from a constraint calculation module 751. Such a constraint calculation module can be configured to process any combination of environmental condition signals 745 and / or any combination of robotic control system condition signals 746.

[0185] 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., aPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 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 749 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.

[0186] 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.

[0187] 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 FORPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 HIGH-SPEED GEOFENCING” filed on May 25, 2023, which is hereby incorporated by reference in its entirety.

[0188] There may be many other scenarios and many other types of environmental safety constraints 750 as well as many other types of controllable condition safety constraints 749. 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.

[0189] The supervisory layer implementation of FIG. 7B is merely one example as is applicable to the shown example environment. A supervisory layer can be implemented in many alternative environments, some of which such alternative environments are shown and described as pertains to FIG. 7C1 and FIG. 7C2.

[0190] FIG. 7C1 depicts a block diagram of an interstitially situated supervisory layer. More specifically, FIG. 7C1 depicts block diagram 7C100 that includes a safety module 777 (e.g., comprising example supervisory layer implementation 772) that is situated between a planning module 773 (e.g., comprising example autonomy stack implementation 770) and a kinetic control module 775 (e.g., comprising example robotic control stack implementation 774).

[0191] In this juxtaposition, the example supervisory layer implementation can be configured to (1) intercept signals from the example autonomy stack implementation, (2) process such interceptedPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 signals, and (3) provide modified versions of the intercepted signals to downstream processing. Additionally or alternatively, the example supervisory layer implementation 772 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 7781and / or from environmental condition sensors 7782).

[0192] In this illustrative example, downstream processing includes processing of the modified versions of the intercepted signals (e.g., by robotic control module 7661, robotic control module 7662, …, robotic control module 766N) so as to provide signals to any of a plurality of motors 769 and / or actuators 768.

[0193] In this manner, the interstitially situated supervisory layer 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, and / or anthropomorphic robot control, etc.). In this particular architecture, example supervisory layer implementation 772 includes a signal intercept module 760, a signal modification module 762, and a signal data publisher module 756SAFETY. The signal data publisher module 756SAFETYis 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 759. 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 thePATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 communication protocol between shown signal subscriber module 764 and signal data publisher module 756SAFETY, where such a communication protocol serves to securely communicate information (e.g., authentication credentials 757) between the modules.

[0194] The shown example robotic control stack implementation 774 includes a signal subscriber module, shown as signal subscriber module 764, 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 759. 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.

[0195] Variations of the shown supervisory layer can be deployed in any environment that corresponds to any particular mission. Merely to illustrate one possible implementation, the environment of FIG. 7C1 includes a repository of mission-defining data structures 776. 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 7521, information collection and processing module 7522, …, information collection and processing module 752N). These information collection and processing modules take in information from the environment (e.g., via environmental condition sensors 7781) 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 754, which processed information is made available for publication to and access by any types ofPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 subscribers. As shown, a signal data publisher module 756AUTONOMYis interfaced with signal data queue array 758 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 758 are accessible by signal intercept module 760. For security purposes, signal intercept module 760 may interact with signal data publisher module 756AUTONOMYso as to establish authenticated and secure access to the content of the signal data queue array.

[0196] The foregoing example of FIG. 7C1 exemplifies an embodiment where the autonomy stack or its constituent autonomy agents publish signal data in a manner that the supervisory layer 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 layer 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. 7C2.

[0197] FIG. 7C2 depicts a block diagram involving a human operator’s safe manipulation of a robotic control system. More specifically, FIG. 7C2 depicts block diagram 7C200 that includes an example supervisory layer implementation 772 that is situated between an example human operators’ environment 753 and an example robotic control stack implementation 774.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0198] This figure is being presented to illustrate how a supervisory layer can produce safe robotic control system signals based on signals received from a human operator. In this particular example, operator 765 uses his or her senses to process any of a variety of environmental signals 767. 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 771 can accept any manner of real-time inputs (e.g., human-derived inputs 763) as well as any manner of settings 761 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).

[0199] 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 layer 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 layer can generate safe signals that govern speed of a manipulation and / or a supervisory layer 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 FIG. 7D.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0200] FIG. 7D depicts a safe signal generation technique. The safe signal generation technique 7D00 is shown as a progression through several phases. In a first phase (e.g., the shown environmental situation prediction phase 781), an environmental situation prediction signal 782 is generated. In this example, the environmental situation prediction signal ranges from time=T0to time=TN. The ordinate corresponds to the distance D that a robot is, or is predicted to be, from the nearest environmental features (e.g., the ground or obstacles that might be in the robot’s path). In this particular scenario, the robot is initially at rest on the ground, traverses through a path, and comes again to a resting point on the ground.

[0201] In a second phase (e.g., the shown candidate robotic planning signal generation phase 783), a candidate planning signal 784 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 784 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 781. 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 784 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=T1and another local maximum at time=T2.

[0202] 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 785) in which phase various safety constraints are gathered (e.g., from the shown controllable condition safety constraints 749). The specific constraints that arePATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 gathered (e.g., applicable safety constraints 789) 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 787.

[0203] 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.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10

[0204] After gathering applicable safety constraints in the safety constraint gathering phase 785, those gathered constraints can be applied. This is shown in FIG. 7D as a fourth phase, namely safety constraint application phase 787. In this phase, wrong or dangerous or practicably impossible robotic control signals are modified so as to operate within a safe robotic control regime. As can be seen, the transformation of the candidate planning signal 784 into the shown constrained candidate planning signal 788 serves to address any portions of the candidate planning signal 784 that were wrong or dangerous or practicably impossible, or otherwise unsafe. In the example signal transformation of FIG. 7D, the safe robotic control signal has some portions (e.g., within the impossible region) where the values in those portions correspond to lesser values than respective portions of the corresponding candidate planning signal (e.g., the portions as shown in the range of time=T0to time=T1). Further, in the example signal transformation of FIG. 7D, the safe robotic control signal has some portions where the values in those portions correspond to higher values than respective points of the corresponding candidate planning signal (e.g., as shown in the range time=T1to time=TN). In the example signal transformation of FIG. 7D, the safe robotic control signal has some portions where the values in those portions correspond to values that correct errors in respective points of the corresponding candidate planning signal (e.g., as shown in the range from time=T3to time=TN).

[0205] 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 784, shown here as modified robotic planning signal range 786, are modified so as to send a rampedPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 control signal (e.g., ramped during the time period from time=T0and time=T1) to the robotic control system, rather than to apply an impulse signal to the robotic control system.

[0206] 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.

[0207] 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 modulesPATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 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.

[0208] 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.

[0209] 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, certain of the above-described processing 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.

Claims

PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 CLAIMS What is claimed is:

1. A method for configuring a movable mechanical device, the method comprising: configuring a diverter module with first interfaces to a robotic control module that operates at least one of, one or more actuators, and one or more robotic control sensors, wherein the robotic control module is configured (1) to receive robotic control sensor data from the one or more robotic control sensors, and (2) to send control signals to the one or more actuators of the robotic control module; configuring the diverter module with second interfaces to a planning module configured to receive operational instructions from a user or from an autonomy agent, wherein the planning module is configured to generate at least one candidate planning signal based at least in part on the operational instructions, wherein the planning module receives environmental data from environmental sensors, and wherein the at least one candidate planning signal is generated based at least in part on the environmental data from the environmental sensors; and configuring the diverter module to receive at least one of, (i) the operational instructions from a user or from an autonomy agent, or (ii) the at least one candidate planning signal, wherein the diverter module is interfaced with a safety module that processes the at least one candidate planning signal by applying safety constraints over the at least one candidate planning signal to generate at least one modified planning signal, and wherein, the diverter module operates to output the at least one modified planning signal, rather than the at least one candidate planning signal.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 2. The method of claim 1, wherein the safety module further comprises analyzing the at least one candidate planning signal, and wherein the analyzing comprises consideration of at least one of, a temperature, a wear level, one or more faults, or one or more alerts.

3. The method of claim 1, wherein the safety module further comprises analyzing the at least one candidate planning signal, wherein the analyzing comprises consideration of at least one of, a coefficient of friction, structure geometry, or a structure center of gravity.

4. The method of claim 1, wherein the safety module further comprises analyzing the at least one candidate planning signal, wherein the analyzing comprises consideration of at least one of, motor torque, instantaneous forward acceleration, instantaneous rearward acceleration, instantaneous vertical acceleration, instantaneous lateral acceleration, or mass centroid.

5. The method of claim 1, wherein the operational instructions from a user or from an autonomy agent comprise at least one of, move to a final position, move to an intermediate position, stop, reverse, accelerate, elevate, dive, or rotate.

6. The method of claim 1, wherein the safety module provides a feedback signal to the planning module.

7. The method of claim 6, wherein the feedback signal refers to an override to all or a portion of the operational instructions.

8. The method of claim 6, wherein the feedback signal causes actuation of a haptic stimulation.

9. The method of claim 1, wherein the safety module further comprises movement tracking by comparing then-current environmental measurement data or then-current trajectory data with respect to an estimate.

10. The method of claim 9, wherein the comparing is performed at a determined sample rate.

11. The method of claim 10 wherein the determined sample rate is varied dynamically based at least in part on changing conditions.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 12. The method of claim 11, wherein the determined sample rate is increased during a maneuver, and wherein the determined sample rate is decreased when the movable mechanical device is dormant or stationary.

13. The method of claim 1, wherein the safety module further receives sensor data from the robotic control module.

14. A system for operating a movable mechanical device, the system comprising: a robotic control module, being interfaced with at least one of, one or more actuators, and one or more robotic control sensors, wherein the robotic control module is configured (1) to receive robotic control sensor data from the one or more robotic control sensors, and (2) to send control signals to the one or more actuators of the robotic control module; a planning module configured to receive operational instructions from a user or from an autonomy agent, wherein the planning module is configured to generate at least one candidate planning signal based at least in part on the operational instructions, wherein the planning module receives environmental data from environmental sensors, and wherein the at least one candidate planning signal is generated based at least in part on the environmental data from the environmental sensors; and a diverter module receiving at least one of, (i) the operational instructions from a user or from an autonomy agent, or (ii) the at least one candidate planning signal, wherein the diverter module is interfaced with a safety module that processes the at least one candidate planning signal by applying safety constraints over the at least one candidate planning signal to generate at least one modified planning signal, wherein, the diverter module operates to provide the at least one modified planning signal, rather than the at least one candidate planning signal, to the robotic control module.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 15. The system of claim 14, wherein the safety module further comprises analyzing the at least one candidate planning signal, and wherein the analyzing comprises consideration of at least one of, a temperature, a wear level, one or more faults, or one or more alerts.

16. The system of claim 14, wherein the safety module further comprises analyzing the at least one candidate planning signal, wherein the analyzing comprises consideration of at least one of, a coefficient of friction, structure geometry, or a structure center of gravity.

17. The system of claim 14, wherein the safety module further comprises analyzing the at least one candidate planning signal, wherein the analyzing comprises consideration of at least one of, motor torque, instantaneous forward acceleration, instantaneous rearward acceleration, instantaneous vertical acceleration, instantaneous lateral acceleration, or mass centroid.

18. The system of claim 14, wherein the operational instructions from a user or from an autonomy agent comprise at least one of, move to a final position, move to an intermediate position, stop, reverse, accelerate, elevate, dive, or rotate.

19. The system of claim 14, wherein the safety module provides a feedback signal to the planning module.

20. The system of claim 19, wherein the feedback signal refers to an override to all or a portion of the operational instructions.

21. The system of claim 19, wherein the feedback signal causes actuation of a haptic stimulation.

22. The system of claim 14, wherein the safety module further comprises movement tracking by comparing then-current environmental measurement data or then-current trajectory data with respect to an estimate.

23. The system of claim 22, wherein the comparing is performed at a determined sample rate.

24. The system of claim 23 wherein the determined sample rate is varied dynamically based at least in part on changing conditions.PATENT Attorney Docket No.: 3LAWS-P0001-WO10 Client Docket No.: 3LAWS-P0001-WO10 25. The system of claim 24, wherein the determined sample rate is increased during a maneuver, and wherein the determined sample rate is decreased when the movable mechanical device is dormant or stationary.

26. The system of claim 14, wherein the safety module further receives sensor data from the robotic control module.

Images