After weeks of programming MegunoLink, I thought it was about time I built something. So I ordered a RedBot chassis and an Ardumotor driver from SparkFun. They have a neat demo that drives the thing back and forwards, but I want to drive it around. Maybe it can go fetch tasty treats while I’m busy debugging.

RedBot with MegunoLink interface

Choosing Commands to Control the RedBot

I figured the easiest place to start would be to make an Arduino program that let me control the robot using serial commands that I can send from MegunoLink. I used our serial command decoder to process the commands and started off with rather a long command list:

When I started implementing all these, I realized they are all just a variation on setting the speed and direction for each of the two motors on the RedBot. Is going to use up a bunch of memory on the RedBot’s Arduino to have all these separate commands, not to mention take time to implement. So I dropped the command set to two: Move and Stop.

The Move command takes two integer arguments, which provide the speed and direction for each motor. So !Move 128 -128\r\n would rotate the left motor forwards and the right motor backwards at half-speed (maximum speed corresponds to 255). That will have the little RedBot spin on a spot — handy for getting around tight corners.

The Stop command stops both motors. Strictly speaking I don’t need this one (we could just send !Move 0 0\r\n), but when writing new programs and things are running amok, its handy to have a simple command that stops the chaos. I tested the stop command first.

Arduino code to Control the RedBot using Serial Commands

With just two serial commands to implement gives us a pretty simple Arduino program to control the RedBot. The serial command decoder does most of the work. I just register the commands it needs to process in the Arduino setup function and call its SerialCommandHandler.Process(); in the main loop. The handler will call the registered function whenever it sees a command that it knows about.

The Cmd_Move function gets called for a move command. It retrieves the speed values from the command parameter using p.NextParameterAsInteger(0) function. This function takes one argument: the default value to return if the parameter can’t be found on the command line. That would normally mean the user didn’t send a complete command. In that case we’d probably want the robot to stop, so I made the default value 0. Once it has the parameter values, Cmd_Move updates the motor speed.

Cmd_Stop is pretty simple. It just stops both motors by setting their speed to zero.

Here’s the RedBot Serial Controller listing:

Building a RedBot UI with MegunoLink

I used MegunoLink’s interface panel visualizer to build a simple user interface to talk to the RedBot controller program. I could have just typed the commands into the Arduino serial monitor, or MegunoLink’s serial monitor window. But building an interface panel means I can have nice big buttons to click on and don’t have to remember the commands.

The interface is pretty simple. A number slider to control the speed and 7 big buttons to send the movement commands. You can download the MegunoLink project from GitHub.

RedBot MegunoLink interface

Control your RedBot from a MegunoLink interface panel

I created the button images using CorelDraw, though I don’t recommend Corel anymore. Many people are having good success with Inkscape so I’ve included an SVG file, which Inkscape will open, in the repository.

Check out our guide to building an Arduino interface if you haven’t built an interface panel with MegunoLink before. Here are the commands that I assigned to each of the buttons:

TurnLeft!Move [(int)Speed.Value/2] [Speed.Value]\r\n
Forward!Move [Speed.Value] [Speed.Value]\r\n
TurnRight!Move [Speed.Value] [(int)Speed.Value/2]\r\n
SpinLeft!Move [-Speed.Value] [Speed.Value]\r\n
SpinRight!Move [Speed.Value] [-Speed.Value]\r\n
Reverse!Move [-Speed.Value] [-Speed.Value]\r\n

[Speed.Value] picks up the value from the number slider (which is named Speed) when the command is sent, letting me change the speed that the RedBot moves around.

It Moves!

But not at first.

The first problem I struck is that the RedBot wouldn’t run very well on carpet. Once I started running it on a piece of card it worked better, but was still quite sluggish.

After reading through the SparkFun site, I discovered they supply a 6V battery pack for good reason. The 5V you get from a USB port isn’t quite enough to excite the motors. Once I plugged in a 6V pack the little RedBot started zipping around.

Cool Trick

Click buttons on the interface panel worked well, but the bot was behind me. So I was watching the robot over my shoulder and trying to click on the buttons. Not super easy.

Windows supports accelerator keys for most interface elements, including buttons. They are the underlined characters on menus, buttons etc. The current design trend is to hide these things (presumably to make the interface less cluttered, but harder to use?!!), but they are still there.

And the way you setup accelerator keys is by putting a & character in the control text.

I didn’t really want text on my buttons (’cause they had pictures). But running the RedBot UI from the keyboard is pretty neat. So I setup the following accelerator keys on my buttons just by editing the button’s text in the interface panel designer:

ButtonButton TextKeyboard Shortcut

In other-words, the keys used in some first-person shooter games. And now I can drive the little RedBot around using the W, A, S, D, X keys. Neat!


Making just one command to control the RedBot motors worked well when it came to debugging. Once I got all the buttons doing something I realized the robot was moving in the wrong direction when I told it to turn left or right. Probably I had the motors around the wrong way. I didn’t make buttons to turn just one motor on but I can just send a command to turn one motor on using MegunoLink’s serial monitor visualizer:

Testing the RedBot pin assignments

I used the serial monitor to test if the pin assignments for the motors was correct by telling the left motor to spin. Then I fixed the pin assignments.

And the wrong motor turned. Since the pin assignments are just constants at the top of the program, it was an easy matter to flip them around. Navigation is much easier when the motors are around the right way!

Recent Posts

Leave a Comment

Start typing and press Enter to search