An Emergency-Stop Circuit for a Mobile Robot

Introduction: An Emergency-Stop Circuit for a Mobile Robot

About: Have enjoyed a mostly fun ride in an electronics and software career. Also enjoy latin dancing.

So you've built a robot. Let's say that it's your second one. Typically, we buy a complete one as a kit, for instance, maybe a Smart Video Car from Sunfounder. We had fun building it, rolling it around.

But our developing dreams are growing and we soon realize that most of these type kits are really not much more than toys.

So we want to move up. And we did; we spent some real money and we bought something, maybe from Servo City, or maybe we spent yet even more money and we got a monster from Super Droid Robots.

Regardless, from where, as we move up in the level of robot, they tend to get bigger, heavier, faster, and stronger.

And that can quickly lead to problem. Disaster. Danger. Damage. The Three "D"s. :-)

(Sorry, I got carried away)

Trust me when I say that there will come a moment in your robotics tinkering and developing when you will wish you had built and added in some "robot insurance" to your wheeled menace.

I am making my own robot named Wallace, and it definitely needs this feature.

And that scenario or situation is the motivation for this Instructable.

Most of the higher-end motor-controller boards that can handle the bigger motors that draw upwards of 15A, come with a feature called an emergency-stop. An E-Stop.

It can be as simple as two pins on the board that you short together and that causes all motion to cease.

The concept or main idea in enabling such a feature to your robot implies that you'll want a "watchdog". A watchdog - well , it watches. Sort of. Actually, the watchdog is always ready and yearning to do its thing, however it is being constantly held back from doing it.

If we were talking about a real dog, imagine one straining against the leash, and as long as you hold on to the leash, nothing happens. The second you let go of the leash, the "watchdog" takes off to do its thing.

I have seen a few (very good) examples of roboticists creating some emergency-stop circuits, but a lot of times it involves the use of something like an Arduino or some small controller board that acts as the smart watchdog.

I propose to not use anything "smart". To keep it as simple and as reliable as possible.

Step 1: Begin Circuit Design

I did do some researching on how to handle emergency-stops for a mobile robot. Most of what I saw had to do with industrial robots. It seemed most hobbyists aren't doing this. I did see some that explained how they tackled the problem, and most of what I saw involved another smart component, such as an Arduino or some other microcontroller to serve as the circuit that activates the E-stop.

I didn't want to do that. As a software developer, and from everything I see in the news, I tend not to trust software when it has to do with something fail-safe.

So I wanted to go with something simple. Use some passive components, maybe some active components.

Yes, there would be a watchdog, but it would be doing the reverse. That is, I wanted the circuit's natural tendency to be that it closes the Roboclaw motor-controller's E-stop contacts without any effort, and that in order to prevent it from doing so (keeping it on a leash) would require some smarts. "Smart" would mean that everything is well. Lack of "smarts" means something is wrong, and the circuit fires on it's own.

I did come across a youtube that demonstrated a very simple circuit, with a relay, one transistor, one capacitor, and a momentary push-button switch. You close the switch, and that charges the capacitor very quickly. Then it's just the RC time-constant that takes over as the capacitor discharges.

However, that is the opposite of what I need. In that example, the relay is shorted or energized as long as the capacitor has enough charge remaining to keep the transistor conducting.

In my case, I want the transistor to NOT conduct. I need the capacitor to NOT charge.

Anyway, so I chose to go my own way. Besides, it's a learning experience.

One tool that can be very useful in modeling electrical circuits is LtSpice. Spice, I believe, is the the original electrical modeling tool, and there are many programs that have that as the underlying engine, if you will.

LtSpice is one of those.

For those who use Windows, I think the download and install is easy enough. For Linux users, not so much.

You'll have to first install Wine. There are many instructional videos and how-tos, so I won't bore you with that, but here's just one.

I was able to download and run two different versions: LTspiceIV, and LTspiceXVII.

In my experience, I was unable to get the later version to save any of my work to disk. However, the earlier version worked very well for me.

Please check the videos for this section that goes over the design and how I arrived at the circuit.

The starting point of the design meant getting very familiar with the relay that I would be using to close the E-stop contacts. What is it's operating voltage, how much current is needed, what's the coil resistance, and so forth.

These bits of information would be necessary and helpful in what components to choose for the circuit.

Step 2: It Is Time to Breadboard the Design Model

This is just a model. Actual results may differ. Hopefully not by too much. At least the model-diagram gives us a good starting point.

From the previous Step, and from the previous videos, I did choose to increase the capacitance of the first capacitor, even though I was a bit leery of too much current flowing through the Raspberry GPIO pin that provides the circuit with the "watchdog" feature.

Using the LTSpice modeling software, I established some component limits, just by trying different results, constantly re-running the circuit analysis, and studying the resulting voltage and current waveforms at key points in the circuit.

Some key restrictions and parameters would be:

  • limit the current through the 5V signal source
  • try to make sure the output voltage (Vrelay) goes to its extremes as much as possible (0 to 5V) to give a solid on and off current to the relay
  • try to make the 5V input pulse to be as slow as possible, to hog as little of CPU time as possible, among other reasons

Step 3: We Test Our Breadboard Circuit

As it turns out, the circuit did follow closely with the model from LTSpice. That meant the modeling was a worthwhile exercise, as it helped us choose our components.

One minor point: I also designed and tweaked the circuit to include components that I already had on hand.

The C++ program is just a very basic loop to create a steady pulse according to the LTSpice model.

Please watch the video for this section for all the details.

* to build:
* gcc -o -lwiringPi
* to run:
* sudo ./ <gpio port>  <micros on> <micros off> <num loops>

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <limits.h>
#include <wiringPi.h>

int main(int argc, char** argv) {

	if (5>argc) {

		puts("<gpio> <pulsus> <inter-pulsus> <loops>");
		return 1;

	for (int i=0;i<argc;i++) { printf("%d:%s ",i,argv[i]); }

	int gpio  = atoi(argv[1]);

	int pulseMicros = atoi(argv[2]);

	int interPulseMicros = atoi(argv[3]);

	int loops = atoi(argv[4]);



	for (int i=0;i<loops;i++) {


	return 0;

Step 4: Build the Board and Test It

The built circuit board with components worked just as expected. I used a perfboard, some 3-point terminal blocks, and some jumper wires.

The jumper wires are just for testing now. The exact wiring will wait until the board is placed in its location on the robot.

The video has all the details.

Some next steps (another story for another day):

need a bi-directional 3V-to-5V bus breakout board

need a GPIO Port Extender breakout board

need an general-purpose LEDs/switches breakout board

The Raspberry Pi's ports would connect to the bi-directional level-shifted bus, the bus then connects to the GPIO extender, and this E-Stop circuit board would connect to the extender board. Adding the the LEDs/switches board would give us some feedback.

After all the above boards are mounted and wired into the robot, then begin the software that will be responsible for the pulse input to the circuit.

You can checkout the robot all this is being constructed for, at "Wallace The Autonomous Talking Robot Valet".

Thank you for reading / viewing. Any comments / questions are welcome.

Step 5: Time to Make This E-Stop Useful

We've tested the E-Stop circuit board, so now we're ready to mount it to the robot, and connect the relay contacts to the Roboclaw motor-controller's E-stop port (it can be S3, S4, or S5). The relay contacts closing would be the equivalent of shorting the two S5 pins together, and that will cause the motor-controller to go into emergency stop.

The videos in this section go through the various test steps and how to set up the Roboclaw for E-Stop.

The final step is to incorporate we we've learned with our test software, and apply that to the main robot program that has been moving the robot around and avoiding obstacles by reading acoustic sensors, infrared sensors, and reading motor-currents.

Currently, the main program is single-threaded. The only extra feature has been a CTRL-C signal handler. That is, there are no other interrupt-handling routines. Each sensor is polled.

If we chose to continue down the same path, then somehow, no matter where the program is any moment, it would have to keep pulsing the E-Stop circuit often enough so that it would prevent the relay from closing and causing an unnecessary emergency-stop.

Even if we could always make sure the timing would be just right - think about it -we would be sprinkling in some unrelated code everywhere, just for the purposes of preventing an E-Stop.

That sounds yucky, burdensome, error- and headache-prone to me.

So it looks like we've finally arrived at our first real need for a second thread.

This second thread's sole purpose would be to pulse the E-Stop circuit at sufficiently regular intervals.

I try to stay away from multi-threading for as long as possible.

Once we add a second thread, then we have worry about it. Remember, we do want to activate an E-Stop during a real emergency.

For example, let's say our serial communications between our software, and the Roboclaw motor-controller is lost - but the motor controller is still executing the last command (keep rolling forward). It's not a good thing.

We'd want to be able to exit our program, and automatically the E-Stop circuit would no longer be receiving the regular pulses, and it would do what it was designed to do - cause an emergency-stop.

But what if the main program exits, but the second thread does not? (it gets re-assigned to process "1").

And then there's the question of a CTRL-c or SIGINT. Which thread gets it, and does that matter?

And then there's the question of thread-priority and starvation, and on it goes.

These are the possible new headaches that we'll have to deal with.

Be the First to Share


    • Cold Challenge

      Cold Challenge
    • Organization Challenge

      Organization Challenge
    • Block Code Contest

      Block Code Contest