From a578b48fdfa7ec6bfe946f331d8a6629ba78eb12 Mon Sep 17 00:00:00 2001 From: Gold856 <117957790+Gold856@users.noreply.github.com> Date: Sun, 28 May 2023 18:00:14 -0400 Subject: [PATCH 1/7] Copy from Chief Delphi --- .../roborio-info/roborio-safety-controls.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 source/docs/software/roborio-info/roborio-safety-controls.rst diff --git a/source/docs/software/roborio-info/roborio-safety-controls.rst b/source/docs/software/roborio-info/roborio-safety-controls.rst new file mode 100644 index 0000000000..f3c3bf1338 --- /dev/null +++ b/source/docs/software/roborio-info/roborio-safety-controls.rst @@ -0,0 +1,16 @@ +Robot side: there are multiple hardware and software components involved. Outputs of the RoboRIO (e.g. PWMs) are controlled by the FPGA hardware. NetComm is a software daemon that talks to the DS, the FPGA, and the user program. Inside of the user process (the team’s robot program), there’s a NetComm DLL component that talks to the FPGA, CAN, and the NetComm daemon. And of course there are CAN motor controllers on the CAN bus. + +The FPGA has a system watchdog. This watchdog will time out and force a “disable” of PWM motor outputs if NetComm hasn’t told it it’s received an enable packet in the last 125 ms. +The PWM disable works by sending a single idle pulse to the motor controller at the start of the next 20 ms PWM cycle after the disable condition is set, and following that, stopping output on the PWM signal line. +The NetComm DLL in the user process will send a disable broadcast message on the CAN network and then stop sending keep-alive CAN messages after the disabled system watchdog signal is read back from the FPGA (this is checked on a 20 ms loop). REV pneumatics and motor controllers will stop immediately upon receipt of the disable broadcast. They also stop if no keep-alive is received for 100 ms (pneumatics) or 220 ms (motor controllers). +CTRE uses a custom approach that reads the disable indicator on NetComm and stops motors within 100 ms of a disable. +When NetComm receives a control packet from the DS with enable set to true, it will immediately enable motors (and restart the FPGA watchdog timer). +A count of watchdog expiration events is sent by NetComm to the DS, so this data is in the DS log. +NetComm (and the control protocol) does not currently have a mechanism to detect delayed control packets. (If it gets a control packet with enable set to true, it will enable the robot and feed the watchdog, even if that packet was sent seconds ago and delayed that much by the network). +The DS sends a control packet to the robot every 20 ms. This is on a high-priority timed loop. Other loops in the DS, including the joystick and GUI loops, run at lower priority. What this means is that under poor CPU conditions or rendering delays (e.g. large amounts of console output), it’s possible for the DS to have internal delay between disable being clicked, a key being hit, or joystick inputs being read to those changes being reflected in the control packets being sent to the robot. +Control (DS->Robot) and status (Robot->DS) packets have an embedded sequence number. The DS uses these to compute round-trip-time and packet loss. A status packet that’s returned is marked as “lost” if the RTT is greater than ~250 ms. This does not mean it was actually missing (no response received). The DS does keep a separate count of truly missing (e.g. no response) packets and disables (starts sending control packets with enable=false) after ~10 drops occur (so I think this works out to ~450 ms, assuming it’s 250+10*20). +From the above, I see several potential ways robots could continue moving even after spacebar or the disable GUI button is pressed on the DS: + +High CPU / GUI delays result in the DS continuing to send packets with enable=true for a period of time until that loop is notified a disable occurs +There is no upper limit to control lag. As long as packets keep arriving, they may be several seconds delayed from the DS, so a disable command from the DS would take the same amount of time to be reflected in robot operation. Once it’s delayed, all controls, including disable/estop, will be delayed. We’ve all seen delays increase either slowly or quickly–the robot was controllable until it’s suddenly much more laggy, or even been laggy from the start. +Packet buffering / wifi retransmits of control packets result in sporadic enable packets making it to the robot after some delay. The watchdog would disable after 125 ms, but a single enable packet would re-enable motors for another 125 ms at a time. \ No newline at end of file From 456dd4661dc2d1ec5170239cf0f70e8e5bd9bbcc Mon Sep 17 00:00:00 2001 From: Gold856 <117957790+Gold856@users.noreply.github.com> Date: Sun, 28 May 2023 18:01:24 -0400 Subject: [PATCH 2/7] Formatting --- .../roborio-info/roborio-safety-controls.rst | 27 ++++++++++--------- 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/source/docs/software/roborio-info/roborio-safety-controls.rst b/source/docs/software/roborio-info/roborio-safety-controls.rst index f3c3bf1338..277d45cda6 100644 --- a/source/docs/software/roborio-info/roborio-safety-controls.rst +++ b/source/docs/software/roborio-info/roborio-safety-controls.rst @@ -1,16 +1,19 @@ +roboRIO Safety Control System +============================= Robot side: there are multiple hardware and software components involved. Outputs of the RoboRIO (e.g. PWMs) are controlled by the FPGA hardware. NetComm is a software daemon that talks to the DS, the FPGA, and the user program. Inside of the user process (the team’s robot program), there’s a NetComm DLL component that talks to the FPGA, CAN, and the NetComm daemon. And of course there are CAN motor controllers on the CAN bus. -The FPGA has a system watchdog. This watchdog will time out and force a “disable” of PWM motor outputs if NetComm hasn’t told it it’s received an enable packet in the last 125 ms. -The PWM disable works by sending a single idle pulse to the motor controller at the start of the next 20 ms PWM cycle after the disable condition is set, and following that, stopping output on the PWM signal line. -The NetComm DLL in the user process will send a disable broadcast message on the CAN network and then stop sending keep-alive CAN messages after the disabled system watchdog signal is read back from the FPGA (this is checked on a 20 ms loop). REV pneumatics and motor controllers will stop immediately upon receipt of the disable broadcast. They also stop if no keep-alive is received for 100 ms (pneumatics) or 220 ms (motor controllers). -CTRE uses a custom approach that reads the disable indicator on NetComm and stops motors within 100 ms of a disable. -When NetComm receives a control packet from the DS with enable set to true, it will immediately enable motors (and restart the FPGA watchdog timer). -A count of watchdog expiration events is sent by NetComm to the DS, so this data is in the DS log. -NetComm (and the control protocol) does not currently have a mechanism to detect delayed control packets. (If it gets a control packet with enable set to true, it will enable the robot and feed the watchdog, even if that packet was sent seconds ago and delayed that much by the network). -The DS sends a control packet to the robot every 20 ms. This is on a high-priority timed loop. Other loops in the DS, including the joystick and GUI loops, run at lower priority. What this means is that under poor CPU conditions or rendering delays (e.g. large amounts of console output), it’s possible for the DS to have internal delay between disable being clicked, a key being hit, or joystick inputs being read to those changes being reflected in the control packets being sent to the robot. -Control (DS->Robot) and status (Robot->DS) packets have an embedded sequence number. The DS uses these to compute round-trip-time and packet loss. A status packet that’s returned is marked as “lost” if the RTT is greater than ~250 ms. This does not mean it was actually missing (no response received). The DS does keep a separate count of truly missing (e.g. no response) packets and disables (starts sending control packets with enable=false) after ~10 drops occur (so I think this works out to ~450 ms, assuming it’s 250+10*20). +* The FPGA has a system watchdog. This watchdog will time out and force a “disable” of PWM motor outputs if NetComm hasn’t told it it’s received an enable packet in the last 125 ms. +* The PWM disable works by sending a single idle pulse to the motor controller at the start of the next 20 ms PWM cycle after the disable condition is set, and following that, stopping output on the PWM signal line. +* The NetComm DLL in the user process will send a disable broadcast message on the CAN network and then stop sending keep-alive CAN messages after the disabled system watchdog signal is read back from the FPGA (this is checked on a 20 ms loop). REV pneumatics and motor controllers will stop immediately upon receipt of the disable broadcast. They also stop if no keep-alive is received for 100 ms (pneumatics) or 220 ms (motor controllers). +* CTRE uses a custom approach that reads the disable indicator on NetComm and stops motors within 100 ms of a disable. +* When NetComm receives a control packet from the DS with enable set to true, it will immediately enable motors (and restart the FPGA watchdog timer). +* A count of watchdog expiration events is sent by NetComm to the DS, so this data is in the DS log. +* NetComm (and the control protocol) does not currently have a mechanism to detect delayed control packets. (If it gets a control packet with enable set to true, it will enable the robot and feed the watchdog, even if that packet was sent seconds ago and delayed that much by the network). +* The DS sends a control packet to the robot every 20 ms. This is on a high-priority timed loop. Other loops in the DS, including the joystick and GUI loops, run at lower priority. What this means is that under poor CPU conditions or rendering delays (e.g. large amounts of console output), it’s possible for the DS to have internal delay between disable being clicked, a key being hit, or joystick inputs being read to those changes being reflected in the control packets being sent to the robot. +* Control (DS->Robot) and status (Robot->DS) packets have an embedded sequence number. The DS uses these to compute round-trip-time and packet loss. A status packet that’s returned is marked as “lost” if the RTT is greater than ~250 ms. This does not mean it was actually missing (no response received). The DS does keep a separate count of truly missing (e.g. no response) packets and disables (starts sending control packets with enable=false) after ~10 drops occur (so I think this works out to ~450 ms, assuming it’s 250+10*20). + From the above, I see several potential ways robots could continue moving even after spacebar or the disable GUI button is pressed on the DS: -High CPU / GUI delays result in the DS continuing to send packets with enable=true for a period of time until that loop is notified a disable occurs -There is no upper limit to control lag. As long as packets keep arriving, they may be several seconds delayed from the DS, so a disable command from the DS would take the same amount of time to be reflected in robot operation. Once it’s delayed, all controls, including disable/estop, will be delayed. We’ve all seen delays increase either slowly or quickly–the robot was controllable until it’s suddenly much more laggy, or even been laggy from the start. -Packet buffering / wifi retransmits of control packets result in sporadic enable packets making it to the robot after some delay. The watchdog would disable after 125 ms, but a single enable packet would re-enable motors for another 125 ms at a time. \ No newline at end of file +* High CPU / GUI delays result in the DS continuing to send packets with enable=true for a period of time until that loop is notified a disable occurs +* There is no upper limit to control lag. As long as packets keep arriving, they may be several seconds delayed from the DS, so a disable command from the DS would take the same amount of time to be reflected in robot operation. Once it’s delayed, all controls, including disable/estop, will be delayed. We’ve all seen delays increase either slowly or quickly–the robot was controllable until it’s suddenly much more laggy, or even been laggy from the start. +* Packet buffering / wifi retransmits of control packets result in sporadic enable packets making it to the robot after some delay. The watchdog would disable after 125 ms, but a single enable packet would re-enable motors for another 125 ms at a time. \ No newline at end of file From b66e5baf46a09f285af152028edd22697990fe0e Mon Sep 17 00:00:00 2001 From: Gold856 <117957790+Gold856@users.noreply.github.com> Date: Sun, 28 May 2023 18:02:37 -0400 Subject: [PATCH 3/7] Remove all non-ASCII characters --- .../software/roborio-info/roborio-safety-controls.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/source/docs/software/roborio-info/roborio-safety-controls.rst b/source/docs/software/roborio-info/roborio-safety-controls.rst index 277d45cda6..3df7c0046e 100644 --- a/source/docs/software/roborio-info/roborio-safety-controls.rst +++ b/source/docs/software/roborio-info/roborio-safety-controls.rst @@ -1,19 +1,19 @@ roboRIO Safety Control System ============================= -Robot side: there are multiple hardware and software components involved. Outputs of the RoboRIO (e.g. PWMs) are controlled by the FPGA hardware. NetComm is a software daemon that talks to the DS, the FPGA, and the user program. Inside of the user process (the team’s robot program), there’s a NetComm DLL component that talks to the FPGA, CAN, and the NetComm daemon. And of course there are CAN motor controllers on the CAN bus. +Robot side: there are multiple hardware and software components involved. Outputs of the RoboRIO (e.g. PWMs) are controlled by the FPGA hardware. NetComm is a software daemon that talks to the DS, the FPGA, and the user program. Inside of the user process (the teams robot program), theres a NetComm DLL component that talks to the FPGA, CAN, and the NetComm daemon. And of course there are CAN motor controllers on the CAN bus. -* The FPGA has a system watchdog. This watchdog will time out and force a “disable” of PWM motor outputs if NetComm hasn’t told it it’s received an enable packet in the last 125 ms. +* The FPGA has a system watchdog. This watchdog will time out and force a “disable” of PWM motor outputs if NetComm hasnt told it it's received an enable packet in the last 125 ms. * The PWM disable works by sending a single idle pulse to the motor controller at the start of the next 20 ms PWM cycle after the disable condition is set, and following that, stopping output on the PWM signal line. * The NetComm DLL in the user process will send a disable broadcast message on the CAN network and then stop sending keep-alive CAN messages after the disabled system watchdog signal is read back from the FPGA (this is checked on a 20 ms loop). REV pneumatics and motor controllers will stop immediately upon receipt of the disable broadcast. They also stop if no keep-alive is received for 100 ms (pneumatics) or 220 ms (motor controllers). * CTRE uses a custom approach that reads the disable indicator on NetComm and stops motors within 100 ms of a disable. * When NetComm receives a control packet from the DS with enable set to true, it will immediately enable motors (and restart the FPGA watchdog timer). * A count of watchdog expiration events is sent by NetComm to the DS, so this data is in the DS log. * NetComm (and the control protocol) does not currently have a mechanism to detect delayed control packets. (If it gets a control packet with enable set to true, it will enable the robot and feed the watchdog, even if that packet was sent seconds ago and delayed that much by the network). -* The DS sends a control packet to the robot every 20 ms. This is on a high-priority timed loop. Other loops in the DS, including the joystick and GUI loops, run at lower priority. What this means is that under poor CPU conditions or rendering delays (e.g. large amounts of console output), it’s possible for the DS to have internal delay between disable being clicked, a key being hit, or joystick inputs being read to those changes being reflected in the control packets being sent to the robot. -* Control (DS->Robot) and status (Robot->DS) packets have an embedded sequence number. The DS uses these to compute round-trip-time and packet loss. A status packet that’s returned is marked as “lost” if the RTT is greater than ~250 ms. This does not mean it was actually missing (no response received). The DS does keep a separate count of truly missing (e.g. no response) packets and disables (starts sending control packets with enable=false) after ~10 drops occur (so I think this works out to ~450 ms, assuming it’s 250+10*20). +* The DS sends a control packet to the robot every 20 ms. This is on a high-priority timed loop. Other loops in the DS, including the joystick and GUI loops, run at lower priority. What this means is that under poor CPU conditions or rendering delays (e.g. large amounts of console output), its possible for the DS to have internal delay between disable being clicked, a key being hit, or joystick inputs being read to those changes being reflected in the control packets being sent to the robot. +* Control (DS->Robot) and status (Robot->DS) packets have an embedded sequence number. The DS uses these to compute round-trip-time and packet loss. A status packet thats returned is marked as “lost” if the RTT is greater than ~250 ms. This does not mean it was actually missing (no response received). The DS does keep a separate count of truly missing (e.g. no response) packets and disables (starts sending control packets with enable=false) after ~10 drops occur (so I think this works out to ~450 ms, assuming its 250+10*20). From the above, I see several potential ways robots could continue moving even after spacebar or the disable GUI button is pressed on the DS: * High CPU / GUI delays result in the DS continuing to send packets with enable=true for a period of time until that loop is notified a disable occurs -* There is no upper limit to control lag. As long as packets keep arriving, they may be several seconds delayed from the DS, so a disable command from the DS would take the same amount of time to be reflected in robot operation. Once it’s delayed, all controls, including disable/estop, will be delayed. We’ve all seen delays increase either slowly or quickly–the robot was controllable until it’s suddenly much more laggy, or even been laggy from the start. +* There is no upper limit to control lag. As long as packets keep arriving, they may be several seconds delayed from the DS, so a disable command from the DS would take the same amount of time to be reflected in robot operation. Once its delayed, all controls, including disable/estop, will be delayed. Weve all seen delays increase either slowly or quickly-the robot was controllable until its suddenly much more laggy, or even been laggy from the start. * Packet buffering / wifi retransmits of control packets result in sporadic enable packets making it to the robot after some delay. The watchdog would disable after 125 ms, but a single enable packet would re-enable motors for another 125 ms at a time. \ No newline at end of file From e21356a8cdc24da6ed2c1a43d89893958d19ad8b Mon Sep 17 00:00:00 2001 From: Gold856 <117957790+Gold856@users.noreply.github.com> Date: Sun, 28 May 2023 18:06:43 -0400 Subject: [PATCH 4/7] Add punctuation and remove 1st person phrasing --- .../roborio-info/roborio-safety-controls.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/source/docs/software/roborio-info/roborio-safety-controls.rst b/source/docs/software/roborio-info/roborio-safety-controls.rst index 3df7c0046e..2733c22f45 100644 --- a/source/docs/software/roborio-info/roborio-safety-controls.rst +++ b/source/docs/software/roborio-info/roborio-safety-controls.rst @@ -1,19 +1,19 @@ roboRIO Safety Control System ============================= -Robot side: there are multiple hardware and software components involved. Outputs of the RoboRIO (e.g. PWMs) are controlled by the FPGA hardware. NetComm is a software daemon that talks to the DS, the FPGA, and the user program. Inside of the user process (the teams robot program), theres a NetComm DLL component that talks to the FPGA, CAN, and the NetComm daemon. And of course there are CAN motor controllers on the CAN bus. +There are multiple hardware and software components involved with safety on the RoboRIO. Outputs of the RoboRIO (e.g. PWMs) are controlled by the FPGA hardware. NetComm is a software daemon that talks to the DS, the FPGA, and the user program. Inside of the user process (the team's robot program), there's a NetComm DLL component that talks to the FPGA, CAN, and the NetComm daemon. And of course there are CAN motor controllers on the CAN bus. -* The FPGA has a system watchdog. This watchdog will time out and force a “disable” of PWM motor outputs if NetComm hasnt told it it's received an enable packet in the last 125 ms. +* The FPGA has a system watchdog. This watchdog will time out and force a “disable” of PWM motor outputs if NetComm hasn't told it it's received an enable packet in the last 125 ms. * The PWM disable works by sending a single idle pulse to the motor controller at the start of the next 20 ms PWM cycle after the disable condition is set, and following that, stopping output on the PWM signal line. * The NetComm DLL in the user process will send a disable broadcast message on the CAN network and then stop sending keep-alive CAN messages after the disabled system watchdog signal is read back from the FPGA (this is checked on a 20 ms loop). REV pneumatics and motor controllers will stop immediately upon receipt of the disable broadcast. They also stop if no keep-alive is received for 100 ms (pneumatics) or 220 ms (motor controllers). * CTRE uses a custom approach that reads the disable indicator on NetComm and stops motors within 100 ms of a disable. * When NetComm receives a control packet from the DS with enable set to true, it will immediately enable motors (and restart the FPGA watchdog timer). * A count of watchdog expiration events is sent by NetComm to the DS, so this data is in the DS log. * NetComm (and the control protocol) does not currently have a mechanism to detect delayed control packets. (If it gets a control packet with enable set to true, it will enable the robot and feed the watchdog, even if that packet was sent seconds ago and delayed that much by the network). -* The DS sends a control packet to the robot every 20 ms. This is on a high-priority timed loop. Other loops in the DS, including the joystick and GUI loops, run at lower priority. What this means is that under poor CPU conditions or rendering delays (e.g. large amounts of console output), its possible for the DS to have internal delay between disable being clicked, a key being hit, or joystick inputs being read to those changes being reflected in the control packets being sent to the robot. -* Control (DS->Robot) and status (Robot->DS) packets have an embedded sequence number. The DS uses these to compute round-trip-time and packet loss. A status packet thats returned is marked as “lost” if the RTT is greater than ~250 ms. This does not mean it was actually missing (no response received). The DS does keep a separate count of truly missing (e.g. no response) packets and disables (starts sending control packets with enable=false) after ~10 drops occur (so I think this works out to ~450 ms, assuming its 250+10*20). +* The DS sends a control packet to the robot every 20 ms. This is on a high-priority timed loop. Other loops in the DS, including the joystick and GUI loops, run at lower priority. What this means is that under poor CPU conditions or rendering delays (e.g. large amounts of console output), it's possible for the DS to have internal delay between disable being clicked, a key being hit, or joystick inputs being read to those changes being reflected in the control packets being sent to the robot. +* Control (DS->Robot) and status (Robot->DS) packets have an embedded sequence number. The DS uses these to compute round-trip-time and packet loss. A status packet that's returned is marked as “lost” if the RTT is greater than ~250 ms. This does not mean it was actually missing (no response received). The DS does keep a separate count of truly missing (e.g. no response) packets and disables (starts sending control packets with enable=false) after ~10 drops occur (this works out to ~450 ms, assuming it's 250+10*20). -From the above, I see several potential ways robots could continue moving even after spacebar or the disable GUI button is pressed on the DS: +There are several potential ways robots could continue moving even after spacebar or the disable GUI button is pressed on the DS: * High CPU / GUI delays result in the DS continuing to send packets with enable=true for a period of time until that loop is notified a disable occurs -* There is no upper limit to control lag. As long as packets keep arriving, they may be several seconds delayed from the DS, so a disable command from the DS would take the same amount of time to be reflected in robot operation. Once its delayed, all controls, including disable/estop, will be delayed. Weve all seen delays increase either slowly or quickly-the robot was controllable until its suddenly much more laggy, or even been laggy from the start. -* Packet buffering / wifi retransmits of control packets result in sporadic enable packets making it to the robot after some delay. The watchdog would disable after 125 ms, but a single enable packet would re-enable motors for another 125 ms at a time. \ No newline at end of file +* There is no upper limit to control lag. As long as packets keep arriving, they may be several seconds delayed from the DS, so a disable command from the DS would take the same amount of time to be reflected in robot operation. Once it's delayed, all controls, including disable/estop, will be delayed. We've all seen delays increase either slowly or quickly-the robot was controllable until it's suddenly much more laggy, or even been laggy from the start. +* Packet buffering / Wi-Fi retransmits of control packets result in sporadic enable packets making it to the robot after some delay. The watchdog would disable after 125 ms, but a single enable packet would re-enable motors for another 125 ms at a time. \ No newline at end of file From 1e1d7b270d9d7a90d514a4c614cdea59f57962aa Mon Sep 17 00:00:00 2001 From: Gold856 <117957790+Gold856@users.noreply.github.com> Date: Sun, 28 May 2023 18:07:44 -0400 Subject: [PATCH 5/7] Remove more non-ASCII characters --- source/docs/software/roborio-info/roborio-safety-controls.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/docs/software/roborio-info/roborio-safety-controls.rst b/source/docs/software/roborio-info/roborio-safety-controls.rst index 2733c22f45..ef115f6c23 100644 --- a/source/docs/software/roborio-info/roborio-safety-controls.rst +++ b/source/docs/software/roborio-info/roborio-safety-controls.rst @@ -2,7 +2,7 @@ roboRIO Safety Control System ============================= There are multiple hardware and software components involved with safety on the RoboRIO. Outputs of the RoboRIO (e.g. PWMs) are controlled by the FPGA hardware. NetComm is a software daemon that talks to the DS, the FPGA, and the user program. Inside of the user process (the team's robot program), there's a NetComm DLL component that talks to the FPGA, CAN, and the NetComm daemon. And of course there are CAN motor controllers on the CAN bus. -* The FPGA has a system watchdog. This watchdog will time out and force a “disable” of PWM motor outputs if NetComm hasn't told it it's received an enable packet in the last 125 ms. +* The FPGA has a system watchdog. This watchdog will time out and force a "disable" of PWM motor outputs if NetComm hasn't told it it's received an enable packet in the last 125 ms. * The PWM disable works by sending a single idle pulse to the motor controller at the start of the next 20 ms PWM cycle after the disable condition is set, and following that, stopping output on the PWM signal line. * The NetComm DLL in the user process will send a disable broadcast message on the CAN network and then stop sending keep-alive CAN messages after the disabled system watchdog signal is read back from the FPGA (this is checked on a 20 ms loop). REV pneumatics and motor controllers will stop immediately upon receipt of the disable broadcast. They also stop if no keep-alive is received for 100 ms (pneumatics) or 220 ms (motor controllers). * CTRE uses a custom approach that reads the disable indicator on NetComm and stops motors within 100 ms of a disable. @@ -10,7 +10,7 @@ There are multiple hardware and software components involved with safety on the * A count of watchdog expiration events is sent by NetComm to the DS, so this data is in the DS log. * NetComm (and the control protocol) does not currently have a mechanism to detect delayed control packets. (If it gets a control packet with enable set to true, it will enable the robot and feed the watchdog, even if that packet was sent seconds ago and delayed that much by the network). * The DS sends a control packet to the robot every 20 ms. This is on a high-priority timed loop. Other loops in the DS, including the joystick and GUI loops, run at lower priority. What this means is that under poor CPU conditions or rendering delays (e.g. large amounts of console output), it's possible for the DS to have internal delay between disable being clicked, a key being hit, or joystick inputs being read to those changes being reflected in the control packets being sent to the robot. -* Control (DS->Robot) and status (Robot->DS) packets have an embedded sequence number. The DS uses these to compute round-trip-time and packet loss. A status packet that's returned is marked as “lost” if the RTT is greater than ~250 ms. This does not mean it was actually missing (no response received). The DS does keep a separate count of truly missing (e.g. no response) packets and disables (starts sending control packets with enable=false) after ~10 drops occur (this works out to ~450 ms, assuming it's 250+10*20). +* Control (DS->Robot) and status (Robot->DS) packets have an embedded sequence number. The DS uses these to compute round-trip-time and packet loss. A status packet that's returned is marked as "lost" if the RTT is greater than ~250 ms. This does not mean it was actually missing (no response received). The DS does keep a separate count of truly missing (e.g. no response) packets and disables (starts sending control packets with enable=false) after ~10 drops occur (this works out to ~450 ms, assuming it's 250+10*20). There are several potential ways robots could continue moving even after spacebar or the disable GUI button is pressed on the DS: From 079ae94ec62e2db91cf40b6f09a5b859756faf9f Mon Sep 17 00:00:00 2001 From: Gold856 <117957790+Gold856@users.noreply.github.com> Date: Sun, 28 May 2023 18:12:59 -0400 Subject: [PATCH 6/7] Add doc to index --- source/docs/software/roborio-info/index.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/source/docs/software/roborio-info/index.rst b/source/docs/software/roborio-info/index.rst index 903c7c831f..357b50e708 100644 --- a/source/docs/software/roborio-info/index.rst +++ b/source/docs/software/roborio-info/index.rst @@ -12,4 +12,5 @@ roboRIO roborio-ssh roborio-brownouts recovering-a-roborio-using-safe-mode + roborio-safety-controls Additional Help From 5d477d2e891cf20f5a58241321b0a308abc85cb0 Mon Sep 17 00:00:00 2001 From: Gold856 <117957790+Gold856@users.noreply.github.com> Date: Sun, 28 May 2023 18:20:30 -0400 Subject: [PATCH 7/7] Make the linter happy --- source/docs/software/roborio-info/roborio-safety-controls.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/docs/software/roborio-info/roborio-safety-controls.rst b/source/docs/software/roborio-info/roborio-safety-controls.rst index ef115f6c23..8e55fa76fa 100644 --- a/source/docs/software/roborio-info/roborio-safety-controls.rst +++ b/source/docs/software/roborio-info/roborio-safety-controls.rst @@ -16,4 +16,4 @@ There are several potential ways robots could continue moving even after spaceba * High CPU / GUI delays result in the DS continuing to send packets with enable=true for a period of time until that loop is notified a disable occurs * There is no upper limit to control lag. As long as packets keep arriving, they may be several seconds delayed from the DS, so a disable command from the DS would take the same amount of time to be reflected in robot operation. Once it's delayed, all controls, including disable/estop, will be delayed. We've all seen delays increase either slowly or quickly-the robot was controllable until it's suddenly much more laggy, or even been laggy from the start. -* Packet buffering / Wi-Fi retransmits of control packets result in sporadic enable packets making it to the robot after some delay. The watchdog would disable after 125 ms, but a single enable packet would re-enable motors for another 125 ms at a time. \ No newline at end of file +* Packet buffering / Wi-Fi retransmits of control packets result in sporadic enable packets making it to the robot after some delay. The watchdog would disable after 125 ms, but a single enable packet would re-enable motors for another 125 ms at a time.