Emergency Stop Final Project

Jeremy Cook and Jessie Chen

May 2017

1 Abstract

Autonomous robots are not fully autonomous yet, and it should be expectedthat they could fail at any moment. Given the validity of this statement,there must be a fail safe measure to stop a robot in an easy and fast manner.To solve this issue, we created a wireless emergency stop button for theversion 2 and version 3 segbots.

2 Introduction

We propose to introduce a new method to halt the robot with an emergencyescape in the form of a big red button. When my partner and I were firstlearning about the segbots, we weren’t fully aware as to how they functioned,and if they could cause damage to themselves or something else or evensomeone else if their code went awry. In many autonomous systems, thereis an easy and understandable escape from the autonomous control back tomanual control. This is the feature my partner and I wish to introduce tothe segbots. Our prime objectives are to increase the safety of the robotand to simplify the user interface. As of now, if a user wishes to stop therobot, she/he has to position themselves behind the laptop and command anew 2D Vector pose to the Rviz window, or to kill the program responsiblefor actuating the motors of the segbot. Either of these two tasks can bevery difficult while the robot is spinning and moving away from the user.My partner and I propose to create a wireless large red button, which iscommonly known for halting a robotic operation thanks to television culture,which will be able to stop the robot at any instant.

1

3 Related Works

What happens when a robot’s sensors stop functioning? It becomes uncertainof many quantities, and either gives up on its assigned task, or continues tofunction as if nothing wrong went at all, because it broke in the exact locationthat tells it when something goes wrong. In the paper by Stolt Andreas et al.[1], the project aims at identifying the loss of sensorimotor data and suggestsa method of automatic detection that will prevent the robot from harmingitself or other people/objects. The robot used in the paper is an arm thathits an emergency stop button when it extends past its local boundaries. Thearm does not stop immediately however, but slowly ramps its speed downto give it a minimal jerk. This paper has also brought up the idea where inaccordance with the remote button, we could have an automatic detectionalgorithm that will stop the robot when a dangerous situation is detected.

It’s clear from Dhillon, Balbir S., and A. R. M. Fashandi. [2] that themost dangerous robots in today’s world are industrial robots. In 1982, theworld robot population was estimated to be at 30,000, and increased rapidlyto 520,000 in 1992. However, as we progress to a more automated society,it’s not hard to imagine more robots interacting with us in our daily lives,and in ever increasing risk. For example, it’s safe to say that most humanstrust an auto piloted airplane will carry us to our desired destination with alow risk of failure. We are however not at the point where we can remove thepilots from the cabin and fully trust an autopilot. Another interesting area ofautomation comes with driverless cars, or self driving cars. Many people aremore wary of the failure rates of these systems, and will continue to be waryuntil death do them part. Besides the health hazard that artificial intelligenceand automated systems bring into our lives, there is also an economic factorto be considered. When one test robot costs half a million dollars, it would beunwise to program it willy nilly without considering any potential damage tothe individual parts of the robot. According to published literature in 1997[2], the mean failure time was only 500 - 2500 hours. This means that if youhad an industrial robot (in 1997) running 23 hours out of 24 hours in theday, it had a very high chance of failing within the first 4 months. At theend of the day, we have still not reached a point where we can rely on robotswith human free interaction 100% of the time. However, I never think wewill reach this point either. Robots will always start to fail at some point,and humans will need to intervene to fix them. “Generally speaking, a robotis blind, deaf, mute, dumb, and unconscious. The sum of these elements

2

render robots dangerous and unforgiving.“ [2]. The root cause lies in thelack of intelligence of the robot. Once (or if) we succeed in creating trulyintelligent robots, we can program them to be aware of the humans in theirsurroundings and take caution in ways that we might not have imagined.I predict this date is long into the future, and until then we need a safetyescape for every robot. This is our purpose of our project at its base, butcan also be used as a blueprint for other button triggered events.

Work on creating a wireless emergency stop button may also lead tofurther research into implementing a more complex wireless remote. Thisremote may have more options in terms of controlling different functions ofthe segbots. For example, implementing a joystick may make tele-operationssafer and easier to control. Since the remote is wireless, human operatorscan maintain a safe distance away from the robot, preventing human-robotcrashes and injuries. A wireless remote may also be used to move the robotwhile the robot is not in reach in the case of dangerous situations and events.This also extends into a concept very similar to Amazon’s dash buttons. Theuser could create a button whose only purpose is to fetch the user coffee, ormaybe remind other coworkers of an upcoming meeting. Our project laysthe groundwork for these implementations on the segbots, that have beendeveloped elsewhere in the world already.

4 Mechanical Design

There are two sides to this project, the mechanical side and the software side-we will first dive into the mechanical aspect of this project. We ordered asimple Single Pole Single Throw (SPST) switch from Amazon in the shape ofa typical emergency stop button. We then wired a 2S 7.4V Lipo, NodeMCUv1.0, and on/off switch to the button in order to make a button press bereceived wirelessly. Below is an image of the simple wiring schematic.

3

Figure 1: Wiring schematic of emergency stop button.

The button is wired to pin D0 with a pull down resistor attached toground. Whenever the button is pressed the D0 pin is pulled high, and whenthe button is released the D0 pin is pulled low.

We initially intended for the NodeMCU, which is a WiFi based chip,to communicate directly with the segbots. However because the robots areconnected to the network ”utexas” which is a WPA2 Enterprise network,our design didn’t work because the NodeMCU chip is not able to connectto WPA2 networks. After some thought, we decided to pivot our project towireless communication between two NodeMCU chips. One would be insidethe casing of the emergency stop button, and the other would be connectedvia USB with the segbot. The NodeMCU which is connected directly to therobot, which we will now refer to as the base station, would communicate withthe robot via serial commands. In order for the two chips to communicatewith each other, we programmed the base station to broadcast an accesspoint with the name ”emergency stop” and a password. The NodeMCUin the emergency button, which we will now refer to as the client station,connects to this access point on a specific port and sends commands via UDP.A packet ”stop” is sent out when the emergency button is pressed.

Average current consumption of the NodeMCU has been recorded to be83 mA, so given our battery capacity of 800 mAh, we can get a crude estimateof how long our emergency stop button will last on a full charge with:

4

800 mAh

83 mA= 9.64 hours (1)

As was described above, the button cannot function without the serverto handle the button signals. Below is an image of both the server and thebutton.

Figure 2: NodeMCU server on the left, and the stop button on the right.

5 Software Design

The robot has two main methods of operation: autonomous and manual.Here is the list of different modes of operation that we need to stop:

• Single navigational goal

• Teleoperation

• KR execution Task

• Custom node

5

• Nodes publishing to /cmd vel

Let’s begin with a single navigation goal. These type of actions arisewhen a 2D navigational goal is requested in rViz after having localized therobot. Cancelling the goal is fairly straight forward as shown in the sampleimage below.

Figure 3: Cancel request policy courtesy of wiki.ros.org

To be safe, we want to cancel all goals, which corresponds to publishingan empty set in a string (”{}”) to the topic ”/move base/cancel” of the formactionlib msgs/GoalID.

Next we want to look into cancelling teleoperation commands, which re-quires a little more functionality. We simply can’t publish a cancel goalmessage because teleoperation doesn’t operate using goals but instead it op-erates by directly sending velocities to the wheels. In order to stop the modeof operation we have to kill the node responsible for publishing velocity com-mands and send a new velocity command of 0. To kill the proper node,we can use system command calls in C++ to directly execute commandsin the terminal. First we run ”rosnode list”, to check which nodes are ac-tive. This returns a string of all running nodes, and if we find the string”/teleop twist keyboard”, then we can kill it with another system call of theform ”rosnode kill teleop twist keyboard”. Once the node is killed however

6

the robot will continue to move in the direction of its last velocity command,so we publish a new velocity command of 0.

Next on the list of programs to stop are bwi kr execution tasks. Thesetasks include visiting a door list or message delivery or looking for a person.It is likely that on one of these tasks a student could open the door for therobot to the landing which contains the stairs in the GDC, in which casethe robot would need to be stopped immediately. Similar to stopping therobot during the teleoperation mode, we search the list of running nodes for”/action executor” and ”/bwi kr”. These nodes are responsible for issuingthe robot new goals and velocities, and must be killed without mercy. Oncethey are killed, we send the robot a new goal of its current position to haltany motion leftover from the task.

Second to last on our list of operational modes of the robot is a customnode. Without having to edit the code, a user can pass the name of theirnode they want to kill as a parameter into our main stop base node. Oncethe stop button is pressed, the program looks to see if the custom nodeis running, and if it is, it kills it. As a safety measure the program thenpublishes a new velocity of 0 and sends a goal of the current position of therobot. We must do both because the program does not know a priori whetherthe custom node publishes velocity commands like the teleoperation mode,or if the custom node sends goals to the robot, like a 2D navigational goal,or if it does both. In any case, the robot will stop on the spot.

Finally, in order to kill any nodes which are publishing to the topic/cmd vel, we run a system call in the terminal to see which nodes are pub-lishing to the topic. Then we parse the string result to kill any nodes whichare listed as publishers.

6 Evaluation

Initially there was concern as to whether setting the velocity of the robot tozero would cause the robot to tip over, but after extensive testing on boththe version 2 and version 3 robots, we found that there was no cause forconcern of the stability of the robots.

We evaluated the emergency stop button in all the test cases described,and found the button to work correctly. The scenarios where the buttonwould not work is when the button is out of range of the robot, there isa connectivity issue, or the robot’s control computer is frozen and is not

7

subscribing to new ROS messages. We did not choose to stop the robotwhen the button became out of range or was not connected because of theinconvenience it would bring to day to day operations. Rather, we wantedthe stop button to be an optional addition to the robot, which could be usedon demos or when testing new code.

7 Conclusion

After many weeks of work, we have created a successful emergency stop but-ton for the version 2 and version 3 segbots at the University of Texas atAustin. Although this project was not cutting edge technology, it is impor-tant to not trade in safety for the shiny and expensive new features. A robotmust be built on a solid and robust foundation to operate smoothly and tobe easily built on in the future.

References

[1] Stolt, Andreas, et al. ”Force controlled assembly of emergency stop but-ton.” Robotics and Automation (ICRA), 2011 IEEE International Con-ference on. IEEE, 2011.

[2] Dhillon, Balbir S., and A. R. M. Fashandi. ”Safety and reliability assess-ment techniques in robotics.” Robotica 15.06 (1997): 701-708.

8