Emergency stop state: Difference between revisions

From RoboPad Wiki
Jump to navigation Jump to search
(Added emergency stop page and simple guidance on testing emergency stop behaviour.)
 
(Added info on disarming)
Line 1: Line 1:
Whenever the RoboPad looses signal from the phone that is connected to it, or the user is not in the "Control Robot" screen, the RoboPad will enter it's '''emergency stop state'''. In this state The RoboPad attempts to be as safe as possible by reverting all active [[IO Config Editor|IO Units]] to their emergency stop state behaviour, which will change depending on how the user has configured each IO Unit. In particular, H-Bridge motors and Brushless motors should revert to stopped states.
Whenever the RoboPad looses signal from the phone that is connected to it, or the user is not in the "Control Robot" screen, the RoboPad will enter it's '''emergency stop state'''. In this state The RoboPad attempts to be as safe as possible by reverting all active [[IO Config Editor|IO Units]] to their emergency stop state behaviour, which will change depending on how the user has configured each IO Unit. In particular, H-Bridge motors and Brushless motors should revert to stopped states. This will also '''disarm''' all IO Units, meaning that a control signal will have to be sent that '''passes through their safe values in order for them to move again'''.


=== Testing Emergency Stop State Behaviour ===
=== Testing Emergency Stop State Behaviour ===
If you are running an event in which RoboPads are being used, you may want to make sure that all RoboPad-based robots behave in a safe and expected manner when they enter this state. While simply getting the user to navigate to the homepage ''will'' get the RoboPad into the emergency stop state, the most sure fire way to test a RoboPad's behaviour when phone-RoboPad communication is broken is to physically break it. The recommended way to do this is to get the user to place the connected phone into a tin-foil (or other Faraday-cage equivalent that works for the 2.4Ghz radio range) lined box and close the lid, forcibly terminally disrupting the signal between the phone and the RoboPad, and then observing that the RoboPad-based robot responds in an appropriate and safe value.
If you are running an event in which RoboPads are being used, you may want to make sure that all RoboPad-based robots behave in a safe and expected manner when they enter this state. While simply getting the user to navigate to the homepage ''will'' get the RoboPad into the emergency stop state, the most sure fire way to test a RoboPad's behaviour when phone-RoboPad communication is broken is to physically break it. The recommended way to do this is to get the user to place the connected phone into a tin-foil (or other Faraday-cage equivalent that works for the 2.4Ghz radio range) lined box and close the lid, forcibly terminally disrupting the signal between the phone and the RoboPad, and then observing that the RoboPad-based robot responds in an appropriate and safe value.

Revision as of 17:42, 25 February 2023

Whenever the RoboPad looses signal from the phone that is connected to it, or the user is not in the "Control Robot" screen, the RoboPad will enter it's emergency stop state. In this state The RoboPad attempts to be as safe as possible by reverting all active IO Units to their emergency stop state behaviour, which will change depending on how the user has configured each IO Unit. In particular, H-Bridge motors and Brushless motors should revert to stopped states. This will also disarm all IO Units, meaning that a control signal will have to be sent that passes through their safe values in order for them to move again.

Testing Emergency Stop State Behaviour

If you are running an event in which RoboPads are being used, you may want to make sure that all RoboPad-based robots behave in a safe and expected manner when they enter this state. While simply getting the user to navigate to the homepage will get the RoboPad into the emergency stop state, the most sure fire way to test a RoboPad's behaviour when phone-RoboPad communication is broken is to physically break it. The recommended way to do this is to get the user to place the connected phone into a tin-foil (or other Faraday-cage equivalent that works for the 2.4Ghz radio range) lined box and close the lid, forcibly terminally disrupting the signal between the phone and the RoboPad, and then observing that the RoboPad-based robot responds in an appropriate and safe value.