Robotic watchdog

Abstract

Robot watchdog software is responsible for monitoring the system's state and the resulting motion, and for re-adapting commands as tasks change and dynamic conditions evolve. However, if the robot watchdog software slows down or stalls, the motion control panel remains unsupervised, and robot movement can become dangerous. The addition of a hardware watchdog mitigates the likelihood of this danger. This paper describes a hybrid software-hardware robot watchdog. Fail-safe robot systems are implemented using a two-layer software-hardware inspection system: the software inspects the robot hardware, and conversely, the hardware watchdog inspects the software's activity.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 090,464, filed on October 12, 2020, which is incorporated herein by reference in its entirety. Invention Field

[0003] This invention generally relates to robotics. More specifically, it relates to a fail-safe robotic system with integrated checks on functionality. Background of the Invention

[0005] Computer-controlled actuated mechanical systems (such as robot manipulators) execute movements under digital commands. If motion control malfunctions, the resulting movements will not follow their intended path or target, posing a risk of danger to humans and damage to materials. Special applications (such as robots for medical applications) or advanced weapon systems require specialized watchdog systems to mitigate this risk as much as possible.

[0006] Robotic watchdogs are typically implemented in software. These software-based watchdogs monitor the system's status and correct for fault conditions and / or interruptions in movement. However, software-based watchdogs are susceptible to software errors or crashes, and their performance may not be deterministic.

[0007] Therefore, it would be advantageous to provide fail-safe robotic systems with integrated checks on functions.

[0008] Overview

[0009] According to a first aspect of the invention, a system for providing robot control includes a hardware watchdog configured to provide control over a robotic manipulator. The system also includes a software watchdog configured to run on a processing device and programmed to provide a thread-safe architecture for both the hardware watchdog and the real-time and non-real-time processes of the robotic manipulator.

[0010] According to one aspect of the invention, the system further includes an emergency switching system. The system includes a momentary single-pole switch. The system includes a redundant system configured to prevent safety failures. The system includes a watchdog circuit with fail-up and fail-down checks. The system includes electronics configured to facilitate fail-down checks, fail-up checks, fail-down and fail-up checks, latches, relays, and status visualization.

[0011] According to another aspect of the invention, a hybrid hardware-software watchdog with a thread-safe architecture for both real-time and non-real-time processes is provided. The hybrid device also includes an emergency switching system. The hybrid device includes a momentary single-pole switch. The hybrid device includes a redundant system configured to prevent safety failures. The hybrid device includes a watchdog circuit with fault rise and fault fall checks. The hybrid device includes electronics configured to facilitate fault fall checks, fault rise checks, fault fall and fault rise checks, latches, relays, and status visualization. Brief description of the attached diagram

[0013] The accompanying drawings provide a visual representation 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, similar reference numerals identify corresponding elements, and:

[0014] Figure 1 A flowchart of a hybrid software-hardware, real-time watchdog architecture is shown.

[0015] Figure 2 A schematic diagram of a circuit block according to an embodiment of the present invention is shown.

[0016] Figure 3 A schematic diagram of a hardware watchdog electronic circuit according to an embodiment of the present invention is shown.

[0017] Detailed Description of Preferred Embodiments

[0018] The subject matter of this disclosure will now be described more fully below with reference to the accompanying drawings, which illustrate some, but not all, embodiments of the invention. Similar numerals refer to similar elements throughout the text. The subject matter of this disclosure may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. In fact, those skilled in the art to which the subject matter of this disclosure pertains will conceive of many modifications and other embodiments of the subject matter of this disclosure set forth herein, taking advantage of the teachings given in the foregoing description and the associated drawings. Therefore, it should be understood that the subject matter of this disclosure is not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims.

[0019] The robotic manipulator is actuated by motors and monitored by sensors (typically including joint position encoders and limit switches). Motion is usually controlled by a dedicated motion control board (MC) via motor drivers. Because motion is time-dependent, it must be controlled in real-time. Therefore, the MC typically uses an onboard digital signal processor (DSP) that controls the motion of each axis in real time. This allows the upper layers of the robot software (e.g., main command definitions and user interface (UI)) to run on a non-real-time operating system (i.e., Microsoft Windows) (typically on a PC). In other application-specific tasks, the PC software reads data and passes commands to the MC, which is responsible for executing the commands in real-time within a closed-loop feedback control system. In turn, the software monitors the system's state and the resulting motion (software watchdog) and re-formulates commands as the task changes and dynamic conditions occur. However, if the software slows down or stalls, the MC remains unsupervised, and motion can become dangerous. The addition of a hardware watchdog mitigates the likelihood of this danger. This paper describes a hybrid software-hardware watchdog. A fail-safe robotic system is implemented using a two-layer software-hardware watchdog system. The software checks the robot's hardware, and in turn, the hardware watchdog checks the software's activity.

[0020] The hybrid hardware and software watchdog according to the present invention mitigates inherent software errors through the integration of software and hardware components. The hybrid software plus hardware architecture allows for comprehensive human oversight of both the software and the robotic components. The robotic manipulator is actuated by motors and monitored by sensors (typically including joint position encoders and limit switches). Motion is typically controlled by a dedicated motion control board (MC) via motor drivers, such as… Figure 1 As shown. Figure 1 A flowchart of a hybrid software-hardware, real-time watchdog architecture is shown. Because motion is time-dependent, it must be controlled in real time. Therefore, the robot control module (MC) typically uses an onboard digital signal processor (DSP) that controls the motion of each axis in real time. This allows the upper layers of the robot software (such as the main command definition and user interface (UI)) to run under a non-real-time operating system (i.e., Microsoft Windows) (typically running on a PC). In other application-specific tasks, the PC software reads data and passes commands to the MC, which is responsible for executing the commands in real time within a closed-loop feedback control system. In turn, the software monitors the state of the system and the resulting motion (software watchdog) and re-formulates commands as the task changes and dynamic conditions change. However, if the software slows down or stalls, the MC remains unsupervised, and the motion can become dangerous. The addition of a hardware watchdog mitigates the likelihood of this danger occurring.

[0021] More specifically, such as Figure 1 As shown, a fail-safe robot system 100 is implemented using a two-layer software-hardware inspection system: a software watchdog inspects the robot hardware, and conversely, a hardware watchdog inspects the software activity. A thread-safe real-time workflow is used to coordinate inspections, command input, and motion control. Figure 1 The document provides a flowchart illustrating the architecture and relationships between the components of the robot system, user interface, and watchdog.

[0022] The fail-safe robot system 100 includes software components 102 and hardware components 104. Software component 102 includes a main class 106, a user interface 108, and a robot class 110. Hardware component 104 includes a robot manipulator 112 or other robot actuators known or conceivable to those skilled in the art. Hardware component 104 also includes a motion control board 114, drivers, and a hardware watchdog timer 116.

[0023] Main class 106 implements the robot's specific, application-related tasks, such as... Figure 1 As shown. In the general representation, it defines tasks and makes them available for processing. Commands are passed to user interface 108, which enhances human control and maintains communication with the hardware through robot class 110.

[0024] The main safety component in the robot class is a thread named Watchdog()118. Hardware component 104 includes a hardware watchdog 116. The hardware watchdog 116 is in the form of electronic circuitry. The hardware watchdog 116 is a timer circuit that operates whenever a period of π is provided. h Or a faster pulse train, it keeps its relay closed. The software watchdog thread 118 operates at approximately π... s A non-real-time thread that runs periodically. During what is considered normal operation, the watchdog thread 118's cycle time does not increase above π. h The electronic circuitry of the hardware watchdog 116, along with the emergency stop switch 119, is connected in series in the power supply chain of the motor driver, such that a failure of the watchdog thread 118, which provides sufficiently fast pulses, will stop the motor by interrupting power. The watchdog thread 118 sends pulse commands via an MC or another digital interface. Furthermore, the hardware watchdog 116 monitors the connection (Connect) of the software computer and disconnects power if the connection is lost.

[0025] The hardware watchdog 116 should not be started from watchdog thread 118, so that if the pulses are temporarily stopped, they cannot be restarted by the next loop of the thread. This eliminates potential transient power failures. Therefore, an additional signal is required to start the hardware watchdog 116, and the additional signal is sent by the WatchdogStart() method 120 via the hardware motion control panel 114.

[0026] Several non-real-time and real-time processes are active simultaneously:

[0027] 1) User interface class 108 includes a non-real-time thread for display 122, which is responsible for continuously updating the display of data at approximately π. d cyclical operation;

[0028] 2) Watchdog thread 118 has approximately π s The cycle;

[0029] 3) The hardware watchdog 116 has π h The cycle;

[0030] 4) The DSP of the MC board 114 runs a real-time thread, the cycle of which depends on the model used, but is usually very fast.

[0031] The actual values ​​for these cycles are set based on the specific robotic application, where faster inspections are needed for rapid movement and mission-critical tasks. Specifically, π h This is based on the maximum time interval, which is considered safe for the robot to operate in an unsupervised manner. Two other periods are set such that:

[0032] π s Always < π h ,

[0033] And for efficiency, π s <π d .

[0034] With several concurrent processes running, the following issues may arise: commands may overlap, become incompatible, and potentially cause software crashes. For example, while watchdog thread 118 loads data from MC board 114, display thread 122 may simultaneously request the same data. Therefore, a thread-safe code structure is required. This is achieved using a thread-safe semaphore (sema) 128. In each π... s During the cycle, as long as watchdog thread 118 communicates with MC board 114 and processes data, watchdog thread 118 keeps sema 128 locked, and watchdog thread 118 sleeps while waiting for cycle π. s Upon completion, sema 128 will be unlocked. Waiting for fπ. s It is πs A small portion of it, which is adjusted or timed, makes the watchdog cycle average π s User interface 108 is only allowed to interact with robot 110 when sema 128 is unlocked. Furthermore, all thread-sensitive methods wait for sema 128 to unlock, then control the locked sema 128, execute their tasks, and finally release sema 128 upon completion. Therefore, sema 128 serializes all thread-sensitive activities, thus avoiding possible parallel and conflicting activities. The main thread is watchdog 118. Other methods run while watchdog 118 is asleep, i.e., when:

[0035] sema → release; hibernation (fπ) s );

[0036] Wait for sema, then sema → lock.

[0037] To avoid thread conflicts with MC 114, only the watchdog thread 118 communicates with it. In this way, commands placed by the user at any time (robot → postCommand) are passed to robot 110, which publishes them in the que(cmd) processed by watchdog 118.

[0038] Watchdog thread:

[0039] 1) Read all necessary data from MC 114;

[0040] 2) Perform necessary calculations, such as kinematics and dynamics;

[0041] 3) Run multiple system checks, including the errors reported by MC 114, the status of robot sensors, emergency stop 119, whether the hardware watchdog 116 is activated (wdOK, from MC), and whether other software components are running (e.g., softOK).

[0042] 4) Based on checks, the watchdog can automatically issue commands to the cmd queue for security purposes. For example, it can issue a power-off command while the hardware watchdog continues to synchronize the state between the hardware and software.

[0043] 5) Update the status of visual status alerts included in the hardware to signal the main status of the system to the user;

[0044] 6) Process the cmd queuing according to its priority and send the command to MC 114;

[0045] 7) If all checks pass (all OK), watchdog 118 sends a pulse to hardware watchdog 116 to keep it on. Otherwise, power interruption is allowed.

[0046] 8) Finally, the watchdog 118 goes into hibernation, allowing other activities to proceed as needed.

[0047] Therefore, if watchdog thread 118 crashes or becomes excessive (>π) h If there is a delay, the hardware watchdog 116 will interrupt the drive power supply, allowing robot 110 to operate without supervision. Disconnecting the drive power supply will stop robot 110 if it cannot be reverse-driven. Otherwise, if the unpowered robot 110 can move under gravity or other loads, the robot arm should be equipped with a normally closed brake that is unlocked by the drive power supply to lock the robot in the event of power loss.

[0048] Other software components (such as user interface 108) may also be critical to security. Therefore, in other checks, watchdog thread 118 also verifies that display thread 122 is running (softOK). The robot tracks the operation of display 122 by the frequency with which it requests data (robot → get(state)). Display 122 typically operates at a lower frequency (1 / π). d <1 / π s The display thread 122 is considered operational if and only if it operates within a few watchdog cycles (nπ). This is because displaying data faster than acquiring it is inefficient. s When requesting data within )

[0049] If (ui is in nπ) s If the data is requested internally, then softOK.

[0050] Other software components can similarly monitor through their direct or indirect (or similarly propagated) interactions with human robots.

[0051] In summary, the hardware watchdog 116 ensures that the computer running the software watchdog is connected and that the software watchdog is operational. In turn, the software watchdog performs a comprehensive system check (including the hardware watchdog and other software components). If a critical fault condition is detected, the robot's drive power is suspended.

[0052] A watchdog circuit was designed based on the requirements of a hybrid software-hardware watchdog:

[0053] R1) Output is brought up only when the software computer and hardware are connected.

[0054] R2) The output is called up only when the pulse and start signal are present;

[0055] R3) if and only if the input pulse is shorter than the hardware preset value π s <πh At the same time, maintain output.

[0056] 1) The software pulse may malfunction in either a rising or falling state. Therefore, if the input (INPUT) is not in π... h If the internal rises, a fault descent check is performed and the output is discarded.

[0057] 2) If the input is not in π h If the internal value drops, a fault rise check is performed and the output is discarded.

[0058] 3) Combine 1 and 2 above to discard the output in the case of fault rise and fault fall.

[0059] 4) Once the pulse train restarts, the output of step 3 is restored. To prevent this, it is latched to the start signal to obtain the output. Therefore:

[0060] a. Fault Drop Test: The output rises with the pulse and START, drops during fault drop, and does not restart during pulse recovery.

[0061] b. Fault Rise Test: The output rises with the pulse and START, falls during fault rise, and does not restart during pulse recovery.

[0062] Therefore, tests 4a and 4b simultaneously meet both R2 and R3 requirements of the hardware watchdog.

[0063] Design the circuit according to steps 1-4 above, and as follows: Figure 2 As shown, digital logic circuits are combined in a way that fulfills the design requirements. Figure 2 A schematic diagram of a circuit block according to an embodiment of the present invention is shown. According to Section 2.2 ( Figure 1 The software-hardware watchdog requirements and additional security checks described in [the document] also include components. Figure 3 The document provides possible implementation methods. Figure 3 A schematic diagram of a hardware watchdog electronic circuit according to an embodiment of the present invention is shown.

[0064] Here, circuit blocks are identified by numbers, and blocks 1-4 correspond to... Figure 2 The circuit blocks in the diagram are shown below:

[0065] 0) Software-Hardware Connection The software watchdog runs on the computer connected to the MC on the hardware side (connection, Figure 1 This is typically done via a USB connection. This connection is first checked by the hardware watchdog, such as... Figure 3As shown. This circuit is supplied with power from an external source. Here, it is shown as a 24V DC power supply, but other power supplies can be used similarly depending on the robot's requirements.

[0066] The circuit is powered by 5V DC from the USB connection. A timer made of an AND gate (U1) is used to allow the USB connection to be established before power is supplied. In this setup, the delay is approximately 3 seconds. Meanwhile, if the USB is disconnected, the drive power is interrupted to prevent the MC from remaining unattended. Power is then supplied via a relay (REL 1) fed by a Darlington transistor array (U2).

[0067] This uninterrupted power supply, unaffected by the watchdog timer, powers the robot sensors and the MC (MC sensor PWR). Additionally, this power is used to generate 5V DC power for all other components of the watchdog circuitry via a DC-DC converter (DC 1). The fans for the circuitry, MC, and typical motor drives of the rack are powered by DC. All power lines are protected with fuses (F1-F5). Finally, three LEDs are included and attached via connectors, allowing them to be placed in a visible position on the rack. Their signals are described in Table 1.

[0068] 1) Fault descent check This is similar to a lost clock or pulse detection circuit. A circuit based on the 555 timer (U5), such as... Figure 3 As shown. This will come from the software watchdog ( Figure 1 The pulse train is taken as input, and its output corresponds to Figure 2 The fault deceleration check is performed. LEDs are used to display pulses (Table 1).

[0069] 2) Fault rise check This is similar to the circuit described above, but operates with an inverted pulse signal.

[0070] 3) Fault Degradation and Fault Rising Inspection This combines the outputs of the two checks above.

[0071] 4) latch The first part of the circuit is used to latch the outputs of checks 2 and 3 above using a reset signal, so that the power supply (WatchdogStart()) can only be started using either a pulse or a start signal. Figure 1 In addition, a second latch is used for a second emergency stop (ES2), in which a momentary switch will be placed on the robot's manipulator. A momentary single-pole switch is preferred.

[0072] Both latches are reset by the same start signal. Their status is reported independently to the software (wdOK, esOK, ...). Figure 1The outputs are displayed via LEDs 5 and 6 (Table 1). Their outputs are combined (U3-3 & 4) into a redundant output system. Redundancy is used to mitigate faults or relays in the next block.

[0073] 5) relay The above check is used to invoke drive power via relay Rel2, which is further connected in series with the main emergency switch (ES1). A redundant branch of the check is used to power a second relay (Rel3), which sends an emergency stop message to the MC. These two systems are redundant, reducing the likelihood of the robot being powered down due to relay failure.

[0074] 6) Visual status : Drive power supply and additional signals from MC ( Figure 1 (This usually indicates whether the robot is moving) combination to display the system status on LED 7.

[0075] Table 1: Circuit LEDs

[0076]

[0077] The novelty of the proposed method lies in its overall structure that combines the framework for monitoring real-time and non-real-time processes with the human supervision and details of the preferred embodiment.

[0078] The preferred embodiment clearly illustrates the software process and circuitry of the hybrid watchdog. It details how to safely combine software threads with a real-time process, hardware watchdog, emergency switch, and MC. While individual electronic circuits and components are common, the hardware and software embodiments described herein are novel. The combination of fault rise-fall tests and latches with the overall logic described herein (…) Figure 2 This is original and enhances safety regarding potential transient spikes.

[0079] The use of an emergency switching system, including a simpler instantaneous single-pole switch, is also novel in the given hardware embodiment. These simpler and smaller switches can be placed in various locations, including those with robotic arms, for immediate operator access, thereby improving safety.

[0080] Watchdog failure is mitigated through system redundancy, which controls different mechanisms to prevent unintentional robot movement, drive power supplies, and emergency stop mechanisms (MCs). Here, redundancy is built into the same system and activates different mechanisms to prevent safety failures.

[0081] It should be noted that the software associated with this invention is programmed onto a non-transitory computer-readable medium that can be read and executed by any computing device mentioned in this application. The non-transitory computer-readable medium can take any suitable form known to those skilled in the art. A non-transitory computer-readable medium is understood to be any computer-readable article of manufacture. Such a non-transitory computer-readable medium includes, but is not limited to, magnetic media (e.g., floppy disks, flexible disks, hard disks, roll-to-roll magnetic tapes, cassette tapes, or cards), optical media (e.g., CD-ROMs, DVDs, Blu-rays, writable optical discs, magneto-optical media in the form of discs, tapes, or cards), and paper media (e.g., punched cards or paper tapes). Alternatively, programs for performing the methods and algorithms of this invention can reside on a remote server or other networked device. Any database associated with this invention can be housed on a central computing device, server, cloud storage, or any other suitable device known or conceivable to those skilled in the art. All information associated with this application is transmitted over a network, either wired or wirelessly, via the Internet, cellular telephone networks, RFID, or any other suitable data transmission means known or conceivable to those skilled in the art.

[0082] Although the invention has been described in conjunction with preferred embodiments thereof, those skilled in the art will understand 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.

[0083] This application also relates to the following:

[0084] Item 1). A system for providing robot control, comprising:

[0085] A hardware watchdog, configured to provide control over a robotic arm; and

[0086] A software watchdog is configured to run on a processing device and is programmed to provide thread-safe architectural control over the hardware watchdog and the real-time and non-real-time processes of the robotic arm.

[0087] Item 2). The system according to Item 1) further includes an emergency switch system.

[0088] Item 3). The system according to Item 2) further includes a momentary single-pole switch.

[0089] Item 4). The system according to Item 2), wherein the emergency switch system is placed at multiple locations distributed on the robotic arm.

[0090] Item 5). The system according to Item 4), wherein the emergency switch located within the robot manipulator is configured to allow the operator to approach immediately for safety.

[0091] Item 6). The system according to Item 1) further includes a redundant system configured to prevent security failures.

[0092] Item 7). The system according to Item 1) further includes a watchdog circuit with fault rise and fault fall checks.

[0093] Item 8). The system according to Item 1) further includes electronic devices configured to facilitate fault decline detection, fault rise detection, fault decline and fault rise detection, latches, relays and visual status.

[0094] Item 9). A hybrid hardware-software watchdog with thread-safe architecture control over real-time and non-real-time processes.

[0095] Item 10). The hybrid hardware-software watchdog according to Item 9) further includes an emergency switching system, the emergency switching system comprising a momentary single-pole switch.

[0096] Item 11). The hybrid hardware-software watchdog as described in Item 10), wherein the emergency switch system is placed at multiple locations distributed across the robotic arm.

[0097] Item 12). The hybrid hardware-software watchdog according to Item 11) includes: an emergency switch located within the robotic arm configured to allow the operator to approach immediately for safety.

[0098] Item 13). The hybrid hardware-software watchdog as described in Item 9) also includes redundant systems that use different mechanisms to prevent security failures.

[0099] Item 14). The hybrid hardware-software watchdog as described in Item 9) further includes a watchdog circuit with fault rise and fault fall checks.

[0100] Item 15). The hybrid hardware-software watchdog according to Item 9) further includes electronic components configured to facilitate fault decline detection, fault rise detection, fault decline and fault rise detection, latches, relays and visual status.

[0101] Item 16). A method for robot control, comprising:

[0102] A hardware watchdog is used, the hardware watchdog being configured to provide control over the robotic arm; and

[0103] A software watchdog is used, which is configured to run on a processing device and programmed to provide thread-safe architectural control over the hardware watchdog and the real-time and non-real-time processes of the robotic arm.

[0104] Item 17). The method according to Item 16) further includes using a redundant system configured to prevent security failures.

[0105] Item 18). The method according to Item 16) further includes using a watchdog circuit with fault rise and fault fall checks.

[0106] Item 19). The method according to Item 16) further includes the use of electronic devices configured to facilitate fault decline detection, fault rise detection, fault decline and fault rise detection, latches, relays and visual status.

[0107] Item 20). The method according to Item 16) further includes the use of an emergency switch system.

Claims

1. A system for providing robot control, comprising: A hardware watchdog timer configured to provide control over a robotic arm includes a timer circuit comprising a relay, wherein the relay closes whenever a pulse train with a period shorter than a maximum time interval is provided, the maximum time interval being considered safe for unsupervised operation of the robotic arm; and A software watchdog, configured to run on a processing device and programmed to provide thread-safe architecture control over the real-time and non-real-time processes of the hardware watchdog and the robotic manipulator, wherein each pulse in the burst is provided to the hardware watchdog by the software watchdog in response to one or more checks performed by the software watchdog on the robotic manipulator.

2. The system according to claim 1 further includes an emergency switch system.

3. The system according to claim 2 further includes a momentary single-pole switch.

4. The system according to claim 2, wherein, The emergency switch system is placed at multiple locations on the robotic arm.

5. The system according to claim 4, wherein, An emergency switch located within the robot's manipulator is configured to allow the operator to approach immediately for safety.

6. The system of claim 1 further includes a redundant system configured to prevent security failures.

7. The system of claim 1 further includes a watchdog circuit with fault rise and fault fall checks.

8. The system of claim 1 further includes electronic components configured to facilitate fault decline detection, fault rise detection, fault decline and fault rise detection, latches, relays, and visual status.

9. A hybrid hardware-software watchdog having thread-safe architecture control over real-time and non-real-time processes, wherein, The hybrid hardware-software watchdog includes a timer circuit, wherein the timer circuit includes a relay, wherein the relay closes whenever it is provided with a pulse train whose period is shorter than a maximum time interval, the maximum time interval being considered safe for unsupervised operation of the robotic arm, and wherein each pulse in the pulse train is provided to the timer circuit in response to one or more checks performed by the hybrid hardware-software watchdog on the robotic arm.

10. The hybrid hardware-software watchdog according to claim 9 further includes an emergency switch system, the emergency switch system comprising a momentary single-pole switch.

11. The hybrid hardware-software watchdog according to claim 10, wherein, The emergency switch system is placed in multiple locations throughout the robotic arm.

12. The hybrid hardware-software watchdog according to claim 11, comprising: An emergency switch located within the robot's manipulator is configured to allow the operator to approach immediately for safety.

13. The hybrid hardware-software watchdog of claim 9 further includes a redundant system that uses different mechanisms to prevent security failures.

14. The hybrid hardware-software watchdog of claim 9 further includes a watchdog circuit with fault rise and fault fall checks.

15. The hybrid hardware-software watchdog of claim 9 further includes electronics configured to facilitate fault decline detection, fault rise detection, fault decline and fault rise detection, latches, relays, and status visualization.

16. A method for robot control, comprising: A hardware watchdog timer is used, configured to provide control over a robotic arm, wherein the hardware watchdog timer includes a timer circuit, wherein the timer circuit includes a relay, and wherein the relay closes whenever a pulse train with a period shorter than a maximum time interval is provided, the maximum time interval being considered safe for unsupervised operation of the robotic arm; and A software watchdog is used, which is configured to run on a processing device and is programmed to provide thread-safe architecture control over the real-time and non-real-time processes of the hardware watchdog and the robotic manipulator, wherein each pulse in the burst is provided to the hardware watchdog by the software watchdog in response to one or more checks performed by the software watchdog on the robotic manipulator.

17. The method of claim 16, further comprising using a redundant system configured to prevent security failures.

18. The method of claim 16, further comprising using a watchdog circuit with fault rise and fault fall checks.

19. The method of claim 16, further comprising using electronic devices configured to facilitate fault decline detection, fault rise detection, fault decline and fault rise detection, latches, relays, and visual status.

20. The method of claim 16, further comprising using an emergency switch system.

Images