RU2846823C1 - Robot safety means - Google Patents

Abstract

FIELD: physics.

SUBSTANCE: group of inventions relates to robotics and can be used in systems for providing control of robot-manipulator. System comprises safety hardware configured to monitor the robot arm, wherein it has a timer circuit including a relay configured to remain closed as long as a sequence of pulses is supplied thereto, period of which is shorter than the longest time interval considered safe for unattended operation of the robot arm, and safety software tool, made with possibility of operation on processing device and programmed with possibility to provide flow-oriented control architecture with respect to real-time or non-real-time processes for the safety hardware and the robotic arm, wherein said software means is configured to supply said hardware with each pulse of said pulse sequence in response to execution of one or more checks of the robot arm, carried out by safety software. Software tool is responsible for monitoring the state of the system and the resultant movement and regenerates commands in response to changes in the task and dynamic conditions. Thus, a fault-tolerant robotic system is realized using the two-level software-hardware verification system.

EFFECT: use of inventions improves reliability and safety of system operation.

20 cl, 3 dwg, 1 tbl

Description

Cross-references to related applications

[0001] This application claims priority to U.S. Provisional Patent Application No. 63/090,464, filed October 12, 2020, which is incorporated herein by this reference in its entirety.

Field of technology to which the invention relates

[0002] The present invention relates generally to robotics. More specifically, the present invention relates to a fault-tolerant robotic system with integrated functionality checks.

State of the art

Computer-controlled, actuated mechanical systems, such as robotic arms, perform movements based on digital commands. If the motion control is incorrect, the resulting movement does not follow its intended path or target, and there is a risk that it will be dangerous to people and materially damaging. Specialized applications, such as medical robots or advanced weapons systems, require specialized safety systems to mitigate this risk as much as possible.

[0004] Robot safety features are typically implemented in software. These software-based robot safety features monitor the state of the system and correct error conditions and/or interrupt motion. However, software-based safety features are vulnerable to software errors or crashes, which may not be deterministic.

[0005] Therefore, it would be useful to provide a fault-tolerant robotic system with integrated functionality checks.

The essence of the invention

[0006] According to a first aspect of the present invention, a system for providing robotic control includes safety hardware configured to provide control over a robotic manipulator. The system also includes safety software configured to operate on a processing device and programmed to provide a thread-oriented architecture with respect to real-time and non-real-time processes for the safety hardware and the robotic manipulator.

[0007] According to an aspect of the present invention, the system further includes a system of emergency switches. The system includes instantaneous single-pole switches. The system includes a redundancy system configured to prevent safety failures. The system includes a safety circuit with tests for failure in the on state and failure in the off state. The system includes electronic equipment configured to provide a test for failure in the off state, a test for failure in the on state, a test for failure in the off state and a failure in the on state, a state latching circuit, a relay and a visual state.

[0008] According to another aspect of the present invention, a hybrid hardware-software safety device with a thread-oriented architecture is provided with respect to real-time and non-real-time processes. The hybrid device further includes a system of emergency switches. The hybrid device includes instantaneous single-pole switches. The hybrid device includes a redundancy system configured to prevent safety failures. The system includes a safety circuit with checks for a failure in the on state and a failure in the off state. The hybrid device includes electronic equipment configured to provide a check for a failure in the off state, a check for a failure in the on state, a check for a failure in the off state and a failure in the on state, a state latching circuit, a relay and a visual state.

Brief description of the drawings

[0009] The accompanying drawings provide visual representations that will be used to more fully describe the representative embodiments disclosed herein and can be used by those skilled in the art to better understand them and their inherent advantages. In these drawings, like reference numerals identify corresponding elements, and:

[0010] Fig. 1 illustrates a flow chart of operations for a hybrid hardware-software architecture of a real-time security tool.

[0011] Fig. 2 illustrates a schematic view of circuit blocks according to an embodiment of the present invention.

[0012] Fig. 3 illustrates a schematic view of an electronic circuit diagram of a security hardware device according to an embodiment of the present invention.

Detailed description of preferred embodiments

[0013] The presently disclosed invention will now be described in more detail hereinafter with reference to the accompanying drawings, which show some, but not all, embodiments of the invention. Like numerals refer to like elements throughout the description. The presently disclosed invention can be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided in such a way that this disclosure will satisfy the applicable allowable requirements. Indeed, many modifications and other embodiments of the presently disclosed invention set forth herein will occur to one skilled in the art to which the presently disclosed invention pertains, having the benefit of the teachings presented in the above descriptions and the associated drawings. Therefore, it is to be understood that the presently disclosed invention should not be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims.

[0014] Robotic arms are driven by motors and monitored by sensors, typically including joint encoders and limit switches. Motion is typically controlled by dedicated motion control boards (MCBs) via electric motor drives. Because motion is time-dependent, it must be controlled in real time. As such, many MCBs typically utilize embedded digital signal processors (DSPs) that control motion at the axis level in real time. This enables higher-level robot software, such as the Master Command Definition (MCD) and User Interface (UI), to run on a non-real-time operating system (i.e., Microsoft Windows), typically on a PC. Among other specialized tasks, the PC software reads data and transmits commands to the MCB, which is responsible for executing the commands in real time in a closed-loop feedback control system. In turn, the software is responsible for monitoring the system state and the resulting motion (safety software) and reprogramming commands as the task and dynamic conditions change. However, if the software slows down or freezes, the robot is left unattended, and motion can become dangerous. Adding safety hardware reduces the likelihood of this hazard. A hybrid hardware-software safety system is described in this paper. A fault-tolerant robotic system is implemented using a two-tiered hardware-software verification system. The software verifies the robotic hardware, and the safety hardware, in turn, verifies the software's operation.

[0015] A hybrid hardware and software safety device according to the present invention reduces the errors inherent in software by combining a software component with a hardware component. The hybrid software plus hardware structure allows for full human control of both the software and the robotic components. Robotic manipulators are driven by motors and monitored by sensors, typically including joint encoders and limit switches. Motion is typically controlled by dedicated motion control boards (MC) via electric motor drives, as illustrated in Fig. 1. Fig. 1 illustrates a flow chart for a hybrid hardware and software architecture of a real-time safety device. Since motion is time-dependent, it must be controlled in real time. As such, multiple MCs typically use embedded digital signal processors (DSPs) that control motion at the level of each axis in real time. This enables higher-level robot software, such as the Master Command Definition (MCD) and User Interface (UI), to run on a non-real-time operating system (i.e., Microsoft Windows), typically on a PC. Among other specialized tasks, the PC software reads data and transmits commands to the UI, which is responsible for executing the commands in real time within a closed-loop feedback control system. In turn, the software is responsible for monitoring the system state and resulting motion (safety software) and reprogramming commands based on changing task and dynamic conditions. However, if the software slows down or freezes, the UI is left unsupervised, and motion can become hazardous. The addition of safety hardware reduces the likelihood of this hazard.

[0016] More specifically, as illustrated in Fig. 1, the fault-tolerant robotic system 100 is implemented using a two-level software and hardware verification system: the safety software verifies the robotic hardware, and, in turn, the safety hardware verifies the software's activity. A real-time, thread-oriented workflow is used to coordinate the verifications, command inputs, and motion control. A flow chart that illustrates the architecture and relationship between the components of the robotic system, the user interface, and the safety software is shown in Fig. 1.

[0017] The fault-tolerant robotic system 100 includes a software component 102 and a hardware component 104. The software component 102 includes a main class 106, a user interface 108, and a robot class 110. The hardware component 104 includes a robotic manipulator 112 or another robotic actuator known or understood by a person skilled in the art. The hardware component 104 also includes a motion control board 114, drives, and a safety hardware 116.

[0018] The main class 106 implements specific, application-dependent robot tasks, as illustrated in Fig. 1. In a general representation, it defines the tasks and makes them available for processing. Commands are transmitted to the user interface 108, which supplements human control and communicates with the hardware via the robot class 110.

[0019] The primary safety component in the robot class is a thread called Watchdog() 118. The hardware component 104 includes a safety hardware 116. The safety hardware 116 takes the form of an electronic circuit. The safety hardware 116 is a timer circuit that maintains its relay closed as long as it is supplied with a pulse train with a period of n _h or faster. The software watchdog thread 118 is a non-real-time thread that operates with a period of approximately n _s . In operation that is considered normal, the period of the watchdog thread 118 does not increase above n _h . The electronic circuit of the safety hardware 116 is converted into a daisy chain of power supplies for the motor drives, together with an emergency stop switch 119, so that failure of the watchdog thread 118 to provide sufficiently fast pulses will stop the motors by interrupting the power supply. Watchdog thread 118 sends pulse commands via the MS or other digital interface. Additionally, security hardware 116 monitors the connection to the computer running the software (Connection) and cuts power if it is disconnected.

[0020] The security hardware 116 will not be started from the Watchdog thread 118, so that if the pulses pass instantly, they cannot be restarted by the following thread cycles. This eliminates potential short-term power surges. Essentially, an additional signal is required to start the security hardware 116, and is sent via the WatchdogStart() method 120 through the hardware movement control board 114.

[0021] Multiple non-real-time and real-time processes are active at the same time:

1) Class 108 User Interface (user interface) includes a non-real-time thread Display 122 (display), which is responsible for continuously updating the data display and operates with a period of approximately n _d ;

2) The 118 Watchdog stream has a period of approximately p _s ;

3) The security hardware 116 has a period of n _h ;

4) The DSP of the MC-board 114 executes the stream in real time with a period depending on the model used, but usually very fast.

[0022] The actual values of these periods are set depending on the specific robotic application, with faster checks required for fast movements and critical tasks. In particular, n _h is set based on the longest time interval considered safe for unsupervised operation of the robot. The other two periods are set such that:

p _s < p _h constantly

and p _s < p _d for efficiency.

[0023] With multiple concurrent processes, it is possible that commands may overlap, be inconsistent, and possibly cause a software crash. For example, the Display thread 122 may request data at the same time that it is being downloaded by the Watchdog thread 118 from the MS-board 114. As such, a thread-safe code structure is required. This is implemented using a thread-safe semaphore for the Robot class (sema) 128. During each n _s cycle, the Watchdog thread 118 keeps the sema 128 locked until it accesses the MS-board 114 and processes the data, and unlocks the sema 128 when it has waited for a period of n _s to complete. The wait, f n _s , is a fraction of n _s that is adjusted or counted such that the Watchdog period averages n _s . User Interface 108 methods are allowed to interact with Robot 110 only when SEMA 128 is unlocked. Furthermore, all thread-sensitive methods wait for SEMA 128 to unlock, then acquire control over SEMA 128 by locking it, perform their tasks, and finally release SEMA 128 when complete. Essentially, SEMA 128 sequences all thread-sensitive actions, thereby avoiding potentially concurrent and potentially conflicting actions. The primary thread is Watchdog 118. Other methods execute when Watchdog 118 is idle, i.e., when:

sema→is released; waiting (f p _s );

Waiting for sema, then sema→blocked;

[0024] To avoid thread conflicts with the MS 114, there is only a Watchdog thread 118 that communicates with it. Essentially, commands that the user places at random times (robot→postCommand) are passed to the Robot 110, which places them in a queue (cmd), which is processed by the Watchdog 118.

[0025] Watchdog Stream:

1) Reads all necessary data from MS 114;

2) Performs necessary calculations such as kinematic and dynamic characteristics;

3) Runs a number of system checks including errors reported by the MS 114, robot sensors, emergency stop 119 condition, if the safety hardware 116 is enabled (wdOK, from the MS), and that other software components are working (e.g., softOK);

4) Based on these checks, the security solution can automatically issue commands to the cmd gue to implement security measures. For example, it issues a Power Off command when the security hardware has entered the off state to synchronize the states between the hardware and software;

5) Updates the Visual Status alarm, which is included in the hardware to signal major system states to the user;

6) Processes cmd gue depending on priorities and sends commands to MS 119;

7) If all checks are passed (allOK), the security engine 118 sends a pulse to the security hardware 116 to keep it on. Otherwise, the power supply can be cut off.

8) Finally, the security tool 118 waits, allowing other actions to continue if necessary.

[0026] Essentially, the safety hardware 116 interrupts the drive power in the event of an accident or excessive (>n _h ) delay of the Watchdog flow 118, so that the robot 100 cannot operate without supervision. Disconnecting the drive power will stop the movement in the case where the robot 100 is not reverse driven. Otherwise, if the unpowered robot 100 can move under the influence of gravity or other loads, the robot manipulator must be equipped with normally closed brakes that are released by the drive power to block the robot if power is lost.

[0027] Other software components may also be safety-critical, such as the user interface 108. As such, among other checks, the Watchdog thread 118 also verifies that the Display thread 122 is running (softOK). Robot maintains track of the Display thread 122 running at the rate at which it requests data (robot→get(state)). Display 122 typically runs at a lower rate (1/n _d < 1/n _s ), since it is inefficient to display data faster than it is received. Display thread 122 is therefore considered running if and only if it requests data for several safety cycles (n n _s ):

If (ui requests data for n p _s ), then softOK.

[0028] Other software components may be observed in a similar manner, by their direct or indirect (similarly distributed) interaction with the Robot class.

[0029] In general, the safety hardware 116 ensures that the computer running the safety software is connected and that the safety software is running. In turn, the safety software performs exhaustive system checks, including the safety hardware and other software components. The driving power of the robot is suspended if a serious fault condition exists.

[0030] The security scheme was designed according to the requirements of a hybrid hardware-software security system:

R1) Produce an output signal if and only if the computer with software and hardware are connected.

R2) Output an output signal if and only if the pulses and trigger signal are present;

R3) Maintain the output signal if and only if the input pulses are shorter than a predetermined hardware value, n _s < n _h .

1) Software pulses may not pass through in the on or off states. Essentially, performing a fault check in the off state and stopping the output if the INPUT (input signal) does not rise within n _h .

2) Perform a fail-safe check in the on state and stop output if INPUT does not fall within n _h .

3) Combining points 1 and 2 above to stop output in the event of a failure in the on state AND a failure in the off state.

4) The output for step 3 is restored as soon as the pulse train restarts. To prevent this, the state of the START signal is latched to obtain the OUTPUT signal. Essentially:

a. Off-state failure test: OUTPUT rises with pulses and the START signal, falls on off-state failure, and does not restart when pulses are restored.

b. On-state failure test: OUTPUT rises with pulses and START signal, falls on on-state failure, and does not restart when pulses are restored.

[0031] In essence, tests 4a and 4b satisfy requirements R2 and R3 of the security hardware.

[0032] The circuit was designed according to steps 1-4 described above and as shown in Fig. 2, combining digital logic circuits in a manner that fulfills the design requirements. Fig. 2 illustrates a schematic view of the circuit blocks according to an embodiment of the present invention. Components were also included according to the requirements of the security firmware described in section 2.2 (Fig. 1) and additional security checks. A possible implementation is shown in Fig. 3. Fig. 3 illustrates a schematic view of the electronic circuit of the security hardware according to an embodiment of the present invention.

[0033] Here, the blocks of the circuit are identified numerically, and blocks 1-4 correspond to the blocks in Fig. 2 as follows:

0) Software-Hardware Connection: The safety software runs on a computer that is connected to the MS on the hardware side (connection, Fig. 1). This is often accomplished via a USB connection. This connection must first be verified by the safety hardware, as shown in Fig. 3. This circuit is powered by an external source. Here, it is shown as a 24 V DC power supply, but other sources can be similarly used depending on the robot's requirements.

The circuit is powered by the 5V DC voltage of the USB connection. A timer implemented using an AND gate (U1) is used to ensure the USB connection is established before power is applied. In this setup, the delay is approximately 3 seconds. At the same time, power is interrupted if the USB connection is disconnected, preventing the microcontroller from being left unattended.

Power is then supplied through a relay (REL1) fitted with Darlington transistor arrays (U2).

This power, which will not be interrupted by the safety system, is made available to the robot's power sensors and the MC (MC Sensors PWR). This power is also used to generate 5V DC power via DC-DC conversion (DC1) for all other components of the safety circuit. The chassis fan, the MC, and typically the motor drives are powered directly from the power source. All power lines are protected by fuses (F1-F5). Finally, three LEDs are contained and connected using connectors so that they can be placed in a visible location on the chassis. Their signals are described in Table 1.

1) Off-state failure test: It is similar to the missing clock or pulse detection circuit. The circuit, which is based on the 555 timer (U5), is used as shown in Fig. 3. It receives a pulse train from the safety software (Fig. 1) as input, and its output signal corresponds to the off-state failure test in Fig. 2. An LED is used to display the pulses (Table 1).

2) On-state failure test: It is similar to the circuit above, but works on an inverted pulse signal.

3) Off-state failure and on-state failure test: It combines the output of the two tests above.

4) Latching Circuit: The first part of the circuit is used to latch the output signal of checks 2 and 3 above using a reset signal so that power can only be started with pulses and the Start signal (WatchdogStart(), Fig. 1). In addition, the second latching circuit is used for the second emergency stop (ES2) using a momentary switch, which should be located on the robotic arm. A momentary, single-pole switch is preferred.

Both state latching circuits are reset by the same Start signal. Their states are reported independently to the software (wdOK, esOK, Fig. 1) and displayed via LEDs 5 and 6 (Table 1). Their output signals are combined (U3-3 and 4) into an output signal redundancy system. Redundancy was used to mitigate the effects of relay failure in the next block.

5) Relay: The above tests are used to supply drive power through relay Rel2, which is also located in series with the main emergency stop switch (ES1). A redundant branch of the tests is used to power a second relay (Rel3), which sends an emergency stop message to the MS. The two systems are redundant, reducing the likelihood of the robot being powered due to a relay failure.

6) Visual Status: The drive power and an additional signal from the MS (Fig. 1), typically indicating whether the robot is in motion (travel), are combined to display the system status via LED7 ().

[0034] The novelty of the presented approach is the general framework that brings together the infrastructure for monitoring real-time and non-real-time processes together with human control and the features of the preferred embodiment.

[0035] The preferred embodiment clearly details the software processes and circuits of the hybrid safety device. It details how to safely integrate software flows with real-time processes, safety hardware, and safety switches, along with the MS. While the individual electronic circuits and components are commonplace, the hardware and software embodiment described herein is novel. The integration of on-off failure tests and state latching circuits and the overall logic described herein (FIG. 2) is novel and improves safety-relevant potential transient failures.

[0036] The use of a system of emergency switches, including simpler momentary single-pole switches, is also new in this embodiment of the hardware. These simpler and smaller switches can be placed in various locations, including on the manipulator, to provide the operator with immediate access for increased safety.

[0037] The consequences of a failure of the safety system are mitigated by using system redundancy, which controls various mechanisms for preventing unintended robot movement, drive power, and the emergency stop of the robot. Here, redundancy is built into the same system and activates various mechanisms to prevent failures of the safety system.

[0038] It should be noted that the software associated with the present invention is programmed on a non-transitory computer-readable medium that can be read and executed by any of the computing devices mentioned in this application. The non-transitory computer-readable medium may take any suitable form known to one skilled in the art. A non-transitory computer-readable medium should be understood as any article of manufacture that is readable by a computer. Such non-transitory computer-readable media include, but are not limited to, magnetic media such as a floppy disk, diskette, hard disk, reel-to-reel tape, cartridge tape, cassette tapes or cards, optical media such as CD-ROM, DVD, Blu-ray, recordable compact discs, magneto-optical media in the form of a disk, tape or card, and paper media such as punched cards or paper tape. Alternatively, the program for executing the method and algorithms of the present invention may be located on a remote server or other network-connected device. Any databases associated with the present invention may be located on a central computing device, server(s), cloud storage, or any other suitable means known or readily conceivable to those skilled in the art. All information associated with the application is transmitted either wired or wirelessly over a network, via the Internet, a cellular telephone network, RFID, or any other suitable data transmission means known or readily conceivable to those skilled in the art.

[0039] Although the present invention has been described in connection with preferred embodiments thereof, it will be recognized by those skilled in the art that additions, deletions, modifications and substitutions not specifically described may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims (24)

1. A system for providing control over a robotic manipulator, comprising a safety hardware device configured to provide control over a robotic manipulator, wherein it has a timer circuit including a relay configured to remain closed until a pulse train is applied to it, the period of which is shorter than the longest time interval considered safe for the unattended operation of the robotic manipulator, and a safety software tool configured to operate on a processing device and programmed to provide a thread-oriented control architecture with respect to real-time or non-real-time processes for the safety hardware tool and the robotic arm, wherein said software tool is configured to supply to said hardware tool each pulse from said pulse sequence in response to the execution of one or more robotic arm checks performed by the safety software tool. 2. The system of claim 1, further comprising an emergency switch system. 3. The system of claim 2, further comprising instantaneous single-pole switches. 4. The system of claim 2, wherein the emergency switch system is located in various locations throughout the robotic arm. 5. The system of claim 4, wherein the emergency switches located in the robotic arm are configured to provide immediate access for the operator to ensure safety. 6. The system of claim 1, further comprising a redundancy system configured to prevent safety failures. 7. The system of claim 1, further comprising a safety circuit with checks for failure in the on state and failure in the off state. 8. The system of claim 1, further comprising electronic equipment configured to provide a failure test in the off state, a failure test in the on state, a failure test in the off state and a failure test in the on state, a state latching circuit, a relay and a visual state. 9. A hybrid hardware-software safety device having a thread-oriented architecture for monitoring processes in real time or not in real time and containing a timer circuit having a relay configured to remain closed as long as a pulse sequence is supplied to it, the period of which is shorter than the longest time interval that is considered safe for the operation of a robotic manipulator without supervision, while it is configured to supply to the timer circuit each pulse of said pulse sequence in response to the execution of one or more tests carried out by the robotic manipulator. 10. The means according to claim 9, further comprising a system of emergency switches including instantaneous single-pole switches. 11. The means of claim 10, wherein the emergency switch system is located in various locations throughout the robotic arm. 12. The means according to claim 11, in which the emergency switches located in the robotic manipulator are designed to provide the operator with immediate access to ensure safety. 13. The means of claim 9, further comprising a redundancy system that uses mechanisms to prevent security failures. 14. The means according to item 9, further comprising a safety circuit with checks for failure in the on state and failure in the off state. 15. The means according to claim 9, further comprising electronic equipment configured to provide a failure test in the off state, a failure test in the on state, a failure test in the off state and a failure test in the on state, a state recording circuit, a relay and a visual state. 16. A method for providing control over a robotic manipulator, including the steps of use safety hardware configured to provide control over a robotic manipulator, wherein the safety hardware comprises a timer circuit that has a relay, and the relay remains closed as long as it is supplied with a pulse train whose period is shorter than the longest time interval that is considered safe for the unattended operation of the robotic manipulator, and use a safety software tool, configured to operate on a processing device and programmed to provide a thread-oriented architecture for monitoring processes in real time or not in real time for the safety hardware tool and the robotic manipulator, wherein by means of said software tool each pulse from said pulse sequence is sent to said hardware tool in response to the execution of one or more checks of the robotic manipulator, carried out by the safety software tool. 17. The method of claim 16, further comprising the step of using a redundancy system configured to prevent safety failures. 18. The method of claim 16, further comprising the step of using a safety circuit with checks for failure in the on state and failure in the off state. 19. The method of claim 16, further comprising the step of using electronic equipment configured to provide an off-state failure test, an on-state failure test, an off-state failure test and an on-state failure test, a state latching circuit, a relay, and a visual state. 20. The method of claim 16, further comprising the step of using an emergency switch system.