Introduction: Wallace the Autonomous Talking Robot Valet

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

The lofty goal (for me, anyway) was to make a mobile autonomous robot that could sense its surroundings, learn the layout of the home, respond to verbal instructions, and recognize/identify images. And more as time goes on.

Also included would be the usual - a remote-controlled robot with a camera.

There are many different directions one can take with this project, but it all begins with either building a platform from scratch, where you have to decide the materials, the structure, the motors, and so on,

- or -

selecting a robot platform where a lot of that work and thought has already been done successfully.

There are various mobile robot designs. For example, I could have chosen more of a Mars-rover type with the six motorized wheels and independent movement. I chose instead the low-lying, wide base because I want to add to it. I want to add very tall attachments, such as sensors, that can interact with the environment and "see" over items such as furniture. All that without tipping over.

Some observations:

First, there are some truths to robot projects, and they can tend to be trade-offs: time, money, ability, personal inclination, circumstances.

In my case, I do not have the time, nor the space, nor the inclination, to go scrounging and hunting for parts that I can tear off some other equipment and hope that it might be useful at some point. I also do not want to have days, and weeks (months?) pass and not make progress on this robotics project. So given those constraints, this project will cost me some money. The time be spent researching what I need, where's the best place to get it, and then just buy it. Hats off to those who do really do robots from scratch.

If you are serious about getting into robotics, my guess is that you will not stop at a single robot. And a key reason for this is that as soon as you decide what parts or what kit, and as you begin your assembly, you will be reading and researching a lot. And you will soon realize that you could have done this or that better, or chosen a different part.

For example, my first attempt at a robot was a video-camera car from It is controlled via your wifi, and the main board is a Raspberry Pi. It was a fun first project but the first thing I noticed was the whole setup (motors, motor controller, etc) were too weak to really be of any use on my apartment's carpet, and it was too low to the ground to be of much use for my end-goals.

However, if we constantly search for that "better" gizmo or way of doing something, then we'll never make anything.

Step 1: Make Sure You Have a Technical Assistant

You'll need someone to double-check and inspect your work.

Step 2: Choose Your Platform

Since life is too short, I chose to go with a kit from, the Agent 390 tracked robot. One strong point about Servocity is their many almost lego-like, plug-n-play hardware pieces. As you gain more experience with building (any type project, really), you may get to appreciate pieces such as brackets, plates, channels and more.

If later, you wish to transform the Agent 390 into a wheeled robot, or if you wish to add power to all the wheels, they have the parts and it's not much more effort than fitting them together.

I originally wanted to get a kit from SuperDroidRobots, however, my budget just couldn't reach that far. As of this writing, their smallest tracked model is the SST2, and it is almost twice as much as the one from Servocity.

If you take a closer look at the photo, you'll notice that the one from SuperDroidRobots (the SST2), has notches on the inside of the tracks that correspond to protrusions on the wheels.

In hindsight, that's a much better design. There's very little chance of the track moving side to side and rubbing and causing friction.

The downside for my application - indoors with carpeting - is that the track treads seem a bit rough.

Another factor to consider will be whether you get the standard motor offered with the product, or choose others. Also, should those motors include encoders. Mind you, this all increases the cost.

Depending on your intended use, the standard motors may rotate too fast on the high end, and draw too much current on the low end (as in my case where I want Wallace the robot to move around very carefully in the apartment without wrecking something)

SuperDroidRobots has excellent resources on robot-building, including gear calculations.

Step 3: Begin Assembly

Back to the Agent 390. Of course, when the kit arrives, you have to assemble it. There are a few videos available on Youtube, and you can link to them from the Servocity site.

Advice: take some time and research for a set of (or at least the 7/64) hex key wrenches. (Allen wrenches). You'll want to get a long version. And preferably with some sort of handle (like a T-handle). Also, make sure you don't use ones with rounded tips. The bolts provided in the kit can easily strip.

(Update: Hindsight being 20-20 I would have done assembly differently. I would have placed the flat surfaces on top. So, instead of looking at a cavity wherein the components are placed, it would be "upside-down". I would of-course place the motors underneath, as well as the Roboclaw motor-controller. I would also consider placing the large 12V SLA AGM battery underneath, in a horizontal position, and bring some heavy wire and terminals top-side for ease of re-charging. So this new configuration yields more room for components and also ease of access, because once you've assembled and tested, you really don't have to bother anymore with the the motors, the controller, or the main battery, but you will most likely be regularly tweaking everything else that is top-side (the Raspberry / Arduino, power-distribution, logic circuitry/ breakout boards, etc ..etc).

Note: there are a few different versions of the video - be sure to watch them all. Some are better than others.

The Agent 390 is a quality product. However, there is a bit of a design flaw in it. And this goes back to learning-as-you-go and even when doing research, you many times do not know what questions to ask or what is important. In hindsight, this one seems rather obvious.

The Agent 390's track is smooth and flat. It has ribs on the inner surface for traction with the wheels. The smoothness is a plus for inner surfaces like an apartment's carpet.

However, because it is flat, and due to the design of the wheels, there's no way to insure that the track doesn't move from side to side on its wheels. That means it can and will rub on either the main frame, or on the outside flat brackets that provide stability (and a load bearing).

Had the wheels each had an outer lip that rotates with the wheel, those lips could guide and keep the track perfectly in line.

That one is not readily solvable as-is, however there is another related issue that does have a simple solution.

The spaces and tolerances where the wheels fit between the frame and the outer brackets are extremely tight and it becomes a matter of trial-and-error to get even just the wheels not to rub against anything but to turn freely.

The good people at Servocity did recognize the issue of a tight space for the wheels, and they began adding a packet of "dogbone" plastic spacers in the Agent 390 kit. (see pictures).

As of this writing, it's not possible to order another, separate, additional package of those dogbones online at Servocity. You have to contact them and they manually add it to your order.

However, that wasn't enough. I went to Home Depot and got some spacers(flat washers) and lock washers.

Just by playing with it, it turns out that three of the 1/4 inch washers are just the right thing to put on the inner side of the wheel, between it and the frame. That means no guess-work; just slide the wheel onto the axle until it bumps against the spacers. (see video)

And then on the outer side go one or two lock washers. I chose lock washers instead of spacers simply because they happen to be the same diameter as the metal posts that join the outer bracket to the main frame.

Even the smallest spacer is larger in diameter, and that means the track will rub against it, even if it does not rub against the bracket.

The Agent 390 is not a toy, and it's not cheap. If you want to avoid the track issues, you can spend about twice as much and go with the tracked robots from Those have curved/fitted tracks over rounded wheels. Or, you can switch from a track to individual wheels.

Step 4: Be CAREFUL! This Is Not a Toy

You will notice in the videos that I have mounted the robot chassis on top of a box, and the tracks are not touching anything.

Don't be in such a hurry to get it on the ground and moving that you make a serious mistake.

This robot, as it stands now, is pretty heavy. It is currently weighing in at 17 pounds.

Those motors are quite powerful, and the robot can cause property damage, or hurt someone, or you can easily burn up some circuitry.

Please proceed with caution, think through every step, double-check your work, test at every step, and make incremental changes and improvements.

This robot will not be ready to roll around the ground for some time.

Once it is completely wired, and I have written a simple program (mostly likely in Python for starters) that can start it forward, stop it, backwards, and turn it, and I have tested all those functions very thoroughly while it is still mounted on it's box, only then will I attempt to place it on the ground.

I will add some protections in the software.

For example: I plan to control it initially via another computer on my local WiFi, using an SSH connection into the robot's Raspberry Pi, and just use my computer's keys as movement commands. So one protection could be either a separate shell script on the Raspberry that monitors that the Wifi is still up, and that it can ping back to my desktop linux box (the one doing the keyboard commands), and if within a few milliseconds it can not communicate back, it shuts down the Roboclaw.

You have to think of things like the above.

Step 5: Initial Motor Testing

Once you have assembled the kit including the motors, try it out and see how well the tracks turn.

Although the video of this section shows a mostly-wired robot, the more correct method for this Step is to not have done any wiring yet, and directly connect (see next) to the each motor terminal.

Almost a year ago, after some research, I settled on an Eventek variable power-supply (30V 5A). It has some nice features and protections, such as current-limiting.

You could also just use some batteries.

There's no polarity to the motors to be cautious of. Reversing the connection just makes them rotate in the other direction.

The nice thing about having this power-supply is that I could get a feel for the real-time current-draw of each track under no-load. No-load meaning that the entire robot frame is raised up and the tracks are not touching anything.

It was during this test that I noticed that one track had more friction than the other. It didn't sound the same, it seemed to struggle more, and the the current-reading on the power-supply was higher for it than the other track.

From research, this test should give between 0.5A and 1A+, but not much more.

You will notice that it actually draws more during very slow speeds as opposed to when you apply the full 12V to the motor.

And that is yet another lesson or key point: you will want to really study about the motors. How much torque vs how much speed for what you want to do with your robot.

Hindsight: I might have bought other motors or chosen a different set from Servocity, instead of the ones offered with the kit. (And let's not forget the missing encoders).

Step 6: Initial Design & Layout

At this step, it's time to do some more research and thinking. The previous steps covered everything that you get with the Agent 390, or just about any robot platform. From now on, it's up to you.

From my own experience, and from a lot of research and reading of forums, it's clear things can get a bit hard here. I have somewhat of a background in electronics, and this phase still proved hard for me.

Do not despair. Keep at it. Stay with it.

Since I bought the kit from Servocity, I emailed them and they suggested a Roboclaw 2x15 Motor Controller. This controller comes from BASICMICRO (formerly something else and more recently Ion Motion Control). The Roboclaw, like some other quality controllers, has multiple ways of interfacing to it. The easy way is to just hook up an RC receiver / transmitter to it.

But we want to do more than just drive it around, don't we? For the main "brains" of this robot, I chose the Raspberry Pi 3 B over something else (like an Arduino) because, let's be real - an Arduino is not a full-fledged computer.

Just like everything else in this or any complex project, you will very likely go through iterations. I posted the initial wiring diagram, even though it's not complete.

Drawing out and really trying to understand what goes into a robot and how it all goes together will be invaluable to you as you proceed with making your robot.

Just from going through the above steps, I have made some firm decisions.


1) the motors that came with the Agent 390 - the recommended operating voltages are 6V to 12V. They have a stall current of 20A each.

2) Servocity recommended the Roboclaw 2x15A controller. It has the ability to run all its functions off of the "main battery" (MB), or alternatively it can also be provided with a separate battery for the logic circuits (+ / -). The logic batteries should be no lower than 6V, and 9V to 30V+ is recommended. (Not to exceed 34V).

3) I chose to use a Raspberry Pi 3 B as the robot's main controller, just because I'm familiar with them, I have three of them ready to go, it's a lot easier to do most complex projects with a Raspberry than with an Arduino, and finally I was concerned over writing too many code changes into the Arduino memory chip(s). With a Raspberry I can always get another micro SD card. The Raspberry needs a pretty strict 5V operating voltage, it's a good idea that the batteries provide at least 3A (especially with the newer Pi 3B+).

4) I want this robot to run all day if possible. I want the Raspberry Pi (since it's the brains) to be the last device to risk losing power. I will want it to monitor the other circuits and power them / shut them down. I want to isolate and protect it from the high-current, possibly high-EMF spikes and noise that can be generated by the drive-portion of the robot (the motors, the wiring to the motors, etc)

So , with those givens, here are some questions that could be important to find answers for:

Q: What batteries?

For the main battery that will drive the motors, I chose to go with a 12V lead-acid battery (similar to a car battery). These can give a lot of juice, they're easy to charge, they don't require a lot caution like Li-Po, or Li-Ions do, and they don't cost that much.

To power the Roboclaw's logic circuits, and to power the Raspberry Pi, I chose to group in some Li-Ion 18650 batteries, just because I happen to have bought them some time ago. But also, neither device requires 12V to operate. In fact, the Raspberry needs 5V, so I will need a stepdown regulator. The efficiencies of the regulator decrease the more the difference between Vin and Vout. So with the 18650 cells, I can play with how many to put in series. Or perhaps I may also want to put some in parallel for more current (and longer operating time).

Q: What circuit protection?

Based on Ion Motion's (BASICMICRO) advice, plus my propensity to be overly cautious, I chose to have separate switches and fuses, one set each. A set for the 12V main battery to the motors, one set for the Li-Ions to the Roboclaw logic, and a third set to power the Raspberry. (More on this later, such as fuse and switch current ratings). I added a diode jumpered across the main switch and fuse combination, for bleeding of any back-EMF. I used shielded cable, and ferrite beads. I tried to physically separate the higher-current circuits and wiring, from the logic circuits and wiring. I added a capacitor across the motor terminals. I added yet another switch and resistor as a pre-charge circuit.

Q: How to layout all the major components?

Once you have enough answers and a good mental image of what you need, and you have obtained some / all of the major components, it's probably a good idea to start playing with the actual device and circuit layout of the robot. And you'll probably go through several iterations of this, both initially, and during the ongoing life of the robot, even after you have it working and roaming around.

For the initial layout, I placed the main battery as centrally as possible. I wanted the side-to-side to load to be even on both tracks. The thinking for front-to-back loading was that if the battery is too close to the motors, it makes it harder to add in all the required wiring. Also, a central location meant I can further separate the logic components from the high-current areas.

I chose to invert the Agent 390 chassis and use the recessed cavity for all the components. I felt this gave a little bit more lower center-of-gravity, and better protected the various components and circuits.

One alternative that I thought of would be to place the main battery, the Roboclaw, and all of the high-current wiring in the cavity, but have it facing downward. Mount the main battery flat instead of vertically.

The reasoning behind this idea was that I would get more area for the Raspberry and future circuits and devices, and also perhaps the chassis metal would help isolate noise, spikes, etc generated by the underside from the logic on top.

However, I thought of it a bit late, and one disadvantage is during initial testing and development, how to gain access to the underside without crushing the components on the topside.

But it might still be worth looking into further.

Step 7: The Wiring and Electronics

Ok, so we have an initial list of devices, a design and wiring diagram, and a layout. Now it's time to do some work, even as we question and continue to iterate over our previous steps.

The more we repeatedly rehash in our minds what we've done, or a planning to do, the better first-choices we'll make and the less money we'll spend.

I'm not going to give out a detail list of parts, but just some tips / gotchas / experiences gained.

I order a lot from Amazon, however, I have learned that one can get a lot of very low-quality items, or the items that are not as advertised. I am slowly looking a other sources, such as Servocity, Adafruit, SuperDroidRobots, Robotshop, and Basicmicro.

We begin our work, ongoing research, other parts-selections by reviewing our original list from previous steps. Doing so will bring to mind other needed parts.

  • The 12V main battery to drive the motors
  • The Roboclaw motor controller
  • The Raspberry Pi to be the robot brains
  • A 5V regulator for the Raspberry Pi
  • Switches , fuses, cables
  • capacitors, ferrite beads for the motors

The 12V Lead-Acid battery. I found what seems to be a good company (Chrome Battery) that seems to stand behind their products. They have many choices of batteries. And I got lucky - the exact one I wanted happened to be sold on Amazon as well. I went with a 10Ah only because I wanted to stop at a $20 USD expense. More money means more amp hours. From researching, for this level of robot, it seems that a minimum of 4Ah (4000mAh) is strongly recommended. The batteries from Chrome Battery are sealed (SLA) and AGM ("absorbed glass mat technology, which allows for completely 'maintenance-free' operation.")

The Roboclaw 2x15 motor controller. This device can run each motor at 15A continuous, 30A peak each. Since the motors' stall current is 20A, it's the stall current that concerns us the most. That means we need to have circuits and cabling handle a possible (if only certain moments) 40A current.

One of the photos is a table of various copper wire diameters (gauge) and their current-carrying capacity. I highlighted the four main / most available sizes.

Wire gauges 14, 16, and 18 would be for the high-current circuits, and 22, 24, 28 would work for the logic and sensor wiring.

I did find some 14 AWG at Home Depot, but it is not shielded. You could buy separate shielding and either feed the wire through it or just wrap the shielding around it. If you look closely at some of the photos of the wiring, you'll notice some shielding-wrapped wire.

Later, I found three different sizes of shielded cable, sold by the foot, from SuperDroidRobots. Their largest gauge (18 AWG) would be limited to only 16A, however, since the cable is two-conductor, just use both together as a single wire. In effect, it becomes around 9AWG. Plenty of wire for the 20A stall current to the motors.

Next, the Raspberry needs 5V. I got a 5V switching step-down regulator from Servocity, that has high efficieny conversion from the higher to lower voltage. Depending on the Vin, the efficiencies are in the 80-90% range.

The power to the Raspberry and the Roboclaw logic comes from some EBL 18650 Li-Ion cells that I happened to have bought about a year ago. I recently saw some youtube reviews, and for the prices of these cells, they're not bad. Mine are rated 3000mAh, but the tests show somewhere around 2600mAh.

The Raspberry 3 B+ doesn't really draw much but one should still allow for up to 3A current capacity, especially during brief moments. I would have gone with beefer batteries if I didn't have these 18650s already.

With the 5V stepdown regulator, that means we would need at least two cells (2S configuration) in series, for a supply voltage between 7.4V and 8.4V. That being closest to the 5V, gives us the highest efficiency of the regulator.

The Roboclaw needs more than two cells because the minimum operating voltage at the logic supply pins should be 6V. That being the lowest end, a 2S setup doesn't give us much breathing room for operating time. So I went with three cells (3S) for the Roboclaw.

I read a lot about configuring series-parallel circuits using the 18650, and it's doable. There are caveats and precautions one should take. So I went the safer route and decided on three separate power sources. 1) the 12V main battery for motors. 2) a three-cell (18650) series arrangement (~ 11 - 12V) for the Roboclaw. 3) a two-cell series configuration for the Raspberry.

One of the photos in this section is courtesy of, and the main points are: a) use shielded cable , b) place/solder a capacitor across the motor terminals (and even two more, one each from a terminal to the motor metal body), and c) use ferrite beads.
The motor-wiring will be easier sooner rather than later when you have too many other cables and parts wired. You'll have to make a choice of whether to use terminal connectors, or directly solder the shielded cable to the motor terminals.

I chose to get the protection diodes from Amazon, since it was easier, and had to settle for a certain assortment. One of the photos for this section is a table comparing the diodes. I went with one of the top two on the list. Again, from the wiring diagram, the diode (reversed polarity) goes across both the main switch and the main fuse.

A couple of comments here. Some of the cabling and connections are messy. However, I tested each connection for proper conductivity and no shorting to ground or adjacent cabling. Some of it is because time is short, or I didn't have the proper brackets to place circuits. All of that can be improved later. The other comment is that I absolutely love using tiewraps. They can be almost as strong as using hardware such as nuts and bolts, and they can be a lot easier and quicker to work with.

I go into more detail in the video for this section.

Step 8: More Motor & Circuit Testing

Every time you make a new connection to the robot, you really should think of how to test it.

I don't want to wire everything and then later it doesn't work, and feel a bit overwhelmed trying to troubleshoot the cause. Also, if there is a unintended short somewhere, the more that was wired and connected, the increased chances of causing lots of damage.

You want to make sure that you indeed have a connection between the intended two points, AND you do NOT want any connection (read: a short) to other, unintended points. That means at minimum, a volt-ohm-amp meter is indispensable.

So by this step, we have wired most of the required circuits to make our robot move.

We can now run our first test to see if the high-current side of things (main battery, switches, Roboclaw, motors) will function together and correctly.

Ideally, you'll need a Windows computer, and a USB-to-micro cable. You'll need to download the Ion Studio Setup App from Basicmicro. You'll also need to download the USB driver so your computer (and the setup app) will recognize the Roboclaw. See the Roboclaw Users Manual for more details.

The first video in this section uses Ion Motion Studio setup connected to the Roboclaw's micrro USB to perform the testing.

In case it wasn't very clear before - many complex endeavors, such as software development, or robotics, is not straight-forward, start-to-finish, top-down, "waterfall". There are iterations, and going back and revisiting steps.

In addition to moving forward to the next piece of your project, you may find yourself tweaking and improving a previous step.

The second video shows where I made a couple of changes; one very minor (just using a tie-wrap to move some cables) and the other not-so-trivial (I wasn't happy with where/how the precharge resistor was done).

And also, I improved on the shielding. When using shielded cable, you should ground at least one end of the shielding (and this grounding may NOT necessarily be connected to one of the inner wires of the cable). In my case, I found a close-by grounding point on the chassis.

The third video uses a scope to check the level of noise (EMI) from the motors and if I should be worried about that bleeding into the logic circuits.

In the fourth video, we take a closer look at the use of the Ion Motion studio to review the temperatures, voltages, currents, etc. We take a look at using an USB opto-isolator between the Raspberry and the Roboclaw.

Step 9: The Software - Exploring Technologies

Once you have everything added and wired for basic movement, it's time for some fun. (Or disaster).

I will be honest here - I was unable to get any Python code to work, either with 2.7 or 3.x. I think if I tried with a fresh Raspbian install, it might. My personal interest and direction is to write the code in C/C++ so the problem isn't a real concern for me.

Here are some resources for Python:

  • At Basic Micro, they provide Python code samples as a zip file, and they also include the essential Roboclaw class to handle the low-level communications and commands for the motor-controller. Note that it only works with 2.7, not 3.x.
  • Another resource is pyroboclaw and it was tested with Python 3.5 / 3.6. I had an import issue with it, but i think it's probably something I did wrong or failed to do, or it has to do with my Raspberry configuration.

If you want to go with C/C++:

  • Basic Micro provides C++ Arduino code, and you would have to port it.
  • There's also working code available from Ben Martin for a Mantis from Servocity. It was from his code that I used as a starting point for my own project. (see further down).

Step 10: The Software - Initial Communications

It is time to test if the Raspberry Pi will communicate with the Roboclaw. This might be no small feat because of the noise that can be generated by the all of the motor-drive portion of the robot. This seems to be a common problem.

You shouldn't have any problems if you followed these steps in the assembly of your robot, such as:

  • keeping the high-current wires and circuitry as far as possible from the Raspberry and logic
  • wiring in twisted-pair mode - that means running the positive voltage-rail wires together with the negative voltage-rail wires and twisting them together
  • and / or also using shielded cable, or shielding your own cables
  • using ferrite beads
  • adding capacitors at each motor, across the two terminals

Below is the most basic command and code that can be used to try a first communications between the Raspberry and the Roboclaw. One of the reasons this type project is a bit hard is that the communications with the Roboclaw require that each command sequence include a CRC check. At least it does for packet-serial mode.

The Roboclaw is quite versatile. It can be controlled by a standard RC transmitter / receiver without much more than just plugging them in. It can also communicate via simple-serial, and I believe that does not require any CRC check. However, simple-serial doesn't lend itself very well to doing real work with the robot.

In any case, for this project, I went with C/C++.

<p>#include <iostream></p><p>#include <boost/asio.hpp></p><p>using namespace std;</p><p>string serialDev = "/dev/ttyACM0";
boost::asio::io_service io;
boost::asio::serial_port serial(io, serialDev);</p><p>string getVersion()
    uint8_t commands[] = { 0x80, 0x15 };
    write( serial, boost::asio::buffer(commands, 2));</p><p>    // read the result
    string ver = "";
    char c = 0;
    bool reading = true;
    while( reading )
            case '\0':
                // also read the crc
                reading = false;
    }</p><p>    return ver;
}</p><p>int main( int argc, char** argv )
        cout << "version        : " << getVersion() << endl;</p><p>	return 0;

The low-level serial-port communications is made a lot easier because the code employs the use of the C++ Boost libraries. That can be installed like any other package for Raspbian, using "sudo apt-get install".

The above code is taken from Ben Martin's RoboClaw.cpp.

If the above step works, then you are in business (maybe). I've seen many online posts that state it would stop working after some time, randomly. I think in most cases, it is because of the EMF / EMI noise.

Step 11: The Software & Hardware - Watch Dogs

Since these type robots with powerful motors and heavy metal bodies can be quite dangerous, and one can lose control of them, it is a good idea to add as many protections as possible.

One such protection is a software watchdog.

A software watchdog's sole purpose in life is to "attack". It is up to the main program (the one that handles movement and does everything you want it to do) to keep the watchdog from "attacking".

One such technique is to have a program that consists of two executing threads, one is the main program thread, and the other is the watchdog.

Both the main thread and the watchdog thread would consist of a loop.

They would share or have access to a variable (a flag). That flag determines if the entire program (both threads) should continue to run.

The goal of the watchdog thread is to set that flag to false - it means, "let's quit; let's stop this program".

The goal of the main thread is to set that flag to true - it means, "let's NOT stop this, let's keep going".

If the watchdog ever gets to keep that flag at false, it would then cause the entire program to exit.

How do we keep that flag from going to false? We make sure that the program loop runs faster than the watchdog loop. So that even if the watchdog thread set it to false, by the time it came to decide whether to quit or not, the main thread will have set it back to true.

When would the program not be able to set it back to true? When it has taken too long performing some other action. Perhaps it was hung trying to read or write to the motor-controller. Or perhaps it got hung (blocking) reading some sensor input (such as a distance sensor).

How does this software watchdog help us, anyway? What good does it do to quit the program? How does this add any protection to our robot?

Well, true, by itself, it may not. Although you'll see in a bit that it does.

However, this software watchdog can be assisted by a hardware, circuit-based watchdog.

Most motor-controllers of this cost, capability, and power, come with some sort of E-stop (emergency-stop) port. It's usually as simple as setting that pin to a logic low (zero volts).

A hardware watchdog circuit would then connect to that pin, and if the hardware watchdog is not prevented from doing so, it , too, will "attack". Its goal in life is to set that motor-controller's E-Stop pin to 0V.

The hardware watchdog would expect some sort of constant signal (from the main software), and a fraction of a second after that constant signal ceases (because there was a problem), then the hardware watchdog fires, probably closes some relay, and sets the motor-controller's E-Stop pin to 0V.

Checkout once such method in this Instructable, "An Emergency-Stop Circuit For A Mobil Robot".

What does any of that have to do with the software watchdog we were just discussing?

If it is up to the main thread to make sure it keeps sending that constant signal to the hardware circuit, and if the software watchdog thread were to gain control and exit the program, then the signal would cease, and the hardware circuit will fire and thus the motor-controller would be in emergency-stop mode - killing power to the motors.

I had mentioned that in fact the software watchdog alone had some value. The following is an example of exploiting unknown, unexpected behavior to your advantage. As it turns out, several times I noticed that my C++ program would quit, however, the robot's tracks were still turning. Not a good thing at all. Dangerous. BUT - and I just stumbled upon this - I also noticed that if I re-ran the program, and hit the <SPACE> bar (in my program that means "STOP"), that in fact it would stop. Somehow the program re-gained control of the robot's motor-controller.

So I used that fact to add more protection and control. Please checkout the video which explains and demonstrates this.

Step 12: The Software - an Overview of the Code

If you review Ben Martin's Mantis code, it really boils down to four files or classes:

  • A InputTimeoutHandler class
  • A RoboClaw class
  • A Mantis class
  • The main program

I made a choice to try to keep things as simple as possible, so I chose not use use the Mantis class. That leaves us with three files.

The purpose of the InputTimeoutHandler is protection. It is used by the main program to keep track of how much time has passed since the previous command.

The concept or idea is that if too much time has passed, perhaps there's a problem. In that case, the main program will attempt to get the motor-controller to stop movement.

The purpose of the RoboClaw class is to handle the essential low-level commands to the motor-controller.

The main program handles the interaction between the user and the robot.

I started with his simpledrive code, and made some modifications. His version uses the Mantis class, mine does not. His version uses the ncurses library, mine does not. The use of the curses library is a good one; it allows a really nice screen-based UI in text mode via SSH. I didn't really care about that so I removed it.

My contributions to his code is that I enhanced the protection for possible error-conditions, and that I set up the keyboard input to be non-blocking. The program continues on whether or not the user does anything.

It may be that his did so as well - that does come with the curses library. I had to do my own version since I didn't have curses.

Take a look at the image for this section - it outlines the concepts.

I used Boost threads (it wraps pthreads) to implement the software watchdog.

The screenshot in this section shows the output of the "tree" command that I did for my working directory. I first removed any files not required or that are generated, so you could get a good idea. As you can see, you just need two directories (src/ and include/) and "CMakeLists.txt".

The other two files ("" and "") really required to start.

All you do is make sure you have "cmake" (and ofcourse g++ compiler) in your system, and then run:

cmake .

And you should end up with a "roboclaw" executable.

And here are all the files at github.

The code might be a bit of a hosh-posh, as I started with someone else's code, also grew it organically. Hopefully you can gain something from it.

Step 13: Initial Live Test

Start slowly, pick an open space, be ready to step in if things go badly. The video doesn't show it, but on my first try (before recording), there were some failures.

  • Somehow the USB serial connection dropped between the Raspberry Pi and the Roboclaw motor controller, and the robot kept rolling
  • At another point, somehow an instruction was not received correctly by the Roboclaw, and again it kept rolling
  • At another point, the program developed a fault

I had to move quickly and pick up the robot to place it on a box with the tracks spinning, in order to properly shut everything down.

So I experienced first-hand the real need to add an emergency-stop circuit (a watchdog) that will kick in automatically in case of a problem without any dependence on software.

The idea is that if that circuit does not receive a regular pings or "everything is ok" signal, then it shuts down the Roboclaw.

Some things that can be done in software at the Raspberry end are:

  • monitor the motor currents - if they jump to some high level and stay there, send a stop command to the Roboclaw. If things continue, stop pinging the watchdog circuit.
  • there are settings on the Roboclaw that can be configured via the Ion Studio manager that can provide some protection or limits.

Step 14: Next Steps ....

If you made it to here, my humble thanks. Hopefully you will have gleaned some morsels that you can use in your own projects.

The next phase for Wallace the Robot is:

add the bi-directional 3V-to-5V level-shifter (16 bits)

add the GPIO port-expander circuit board

add the hardware watchdog circuit board

add the first set of acoustic distance sensors

See Part 2.