PAReX Weblog Entries

Single-Stepping Your MazeRunner

Single-Stepping Your MazeRunner

A major part of the MazeRunner development is debugging your code. Without any special tools this simply involves starting the robot and seeing what happens. Having a display onboard or even a serial link can help, but when the robot tears down a corridor and misses 2 turns and run into a wall, you'd like to know why that happened.

Concept

In the software world you would use a debugger and single-step through your code, examining register and memory location to see what's going on. Well why not do something similar with your robot? What I did was develop a single- stepping routine where the robot would stop every time a new room (or cell) was detected. Once the robot stopped, a debug page was sent to the LCD display, showing information about the current cell, sensor readings, current heading, and running mode. After examining this information I pressed the run button and the robot continued until the next cell was detected. In this manner I could single-step an entire maze, making sure the mapping routines were working, and that the sensors were behaving as well.

Breakpoints

One of the first things you need to develop is a breakpoint to stop the robot. This could be different for each robot, depending on how you navigate the maze. Some robots move a specific distance and then scan, move, scan etc. For this approach I would break right after the room scan was done so you can see how the sensors readings look, and how your mapping algorithms work. My mapping routine is a little different in that once it's moved, it continuously scans and will continue moving until a change in the cell walls has occurred. Once that change occurs, the robot stops and displays all current information (the breakpoint).

Debug Display

Once the breakpoint occurs, you need to display some data so you see what's going on. The display I used was 4x20 so I had lot's of room for information. Here's a typical screen shot of what my display looked like.

The top line has the current heading (North), the header for the map info ( N E S W ) and the current mode E (Exploring). The 2nd and 3rd line have the current and previous cell information that indicates if a wall if present or if the path has been traveled. The 4th line has the value of 4 of the wall sensors that were used to create the mapping information. Naturally you can put whatever you want on your display, my example is just to give you ideas. In fact that display may change over time. I originally had line 4 showing another cell reading, but changed it to sensors to work on some sensor problems. My new robot will have a 2x16 display on it, so rather then having a single debug display, I may go to multiple displays that you can scroll through to get all the needed info.

Remote Operation

If your robot has some kind of remote link like an RS-232 port or an RF link you don't need to rely on the LCD display, since you can display the debug display on a laptop or PC. This also allows you to display a lot more information then what you could fit on the LCD, plus you're not squinting and leaning over the maze walls trying to read that little display. My current robot used an RS-232 link, but it was output only. On the next robot I'll make sure it has a bi-directional port so I can also send commands to the robot. No more leaning over the maze to read the display AND press the run button, now it can all be done from a remote terminal application.

Summary

Building a robot can be very rewarding. It can also be head-banging frustrating, so any tools or methods we can use to help that development will save on aspirin. The ability to single-step my robot through the maze has been one of those methods that helped my developments. Hopefully it can help yours as well.

API Command Line Interface

Well the ER1 is very functional from the robotic command center but there are a number of things that just need to be done via an external program. I found this out when I was unable to command the ER1 to rotate away from an object that the IR Sensor detected. I wanted to rotate until the sensor's reflection dropped below a thresh hold value. All of the "If" "Then" conditions of the Command Center are geared to trigger when the thresh hold is exceeded. This is the opposite of what I wanted to do.

Fortunately the folks at Evolution Robotics have added an API Command line interface that allows an external program to talk to the Command Center. I already used this API in an earlier post to do some simple remote control, so this seemed like a good opportunity to extend the remote control functionality I already coded. One thing I need to do is to process events that came back from ER1 to notify the external program when commands have finished. This was not part of the original remote control program.

Here is the pseudo code of the task I want to accomplish:

RotateAwayFromObject
  loop
    rotate 15 degrees away from the object
    if irSensor<50 exit loop
  end loop

Looks pretty simple doesn't it! Well submitting the commands to the command center is very easy but processing the events that come back from the command center is a little more difficult. Basically there are two events I had to process in the above pseudo code: When the rotate 15 degrees finishes and the IR sensor values. The ER1 documentation on the API is somewhat lacking but some documentation is a whole lot better than no documentation. I would like to see a complete description of all the possable events the ER1 can post for every command. Including error events. This would make the external program a little more robust if it could act on all events when needed. So for now I settled for the documentation on the "ir" and "move" command.

There is a command that turns on events and it is called "events" :) The interesting thing about ER1 events is that some only work when the command "events" is issued and some do not need the "events" command to send back information. In this case the "ir" command sends back the ir information without issuing "events". But the move commands do require an "events" command after the "move" command has been issued. Otherwise you will never see the "move done" event.

So I ended up with some code that looked a little ugly but it worked. I can always clean it up later. So here are some snippets of code that show a little about what I got working.

The IRSensor Class is used to parse the IR Sensor values and hold the results i an object.

public class IRSensor
{
    int reflection=0;
    int threshold=0;
    int flashRate=0;
    string command="";
    public IRSensor()
    {
    }
    public string Command
    {
        get{return this.command;}
        set
        {
            this.command = value;
            string[] temp = command.Split(' ');
            if (temp.Length==4)
            {
                reflection = int.Parse(temp[1]);
                threshold = int.Parse(temp[2]);
                flashRate = int.Parse(temp[3]);
            }
        }
    }
    public int Reflection
    {
        get{return this.reflection;}
    }
    public int ThreshHold
    {
        get{return this.threshold;}
    }
    public int FlashRate
    {
        get{return this.flashRate;}
    }
}

The RotateAwayFromObject method is the main method that tests for the object and issues the move command and repeats untill the object is clear

private void RotateAwayFromObject()
{
    int lines=this.listBoxReceived.Items.Count;
    this.listBoxReceived.Items.Clear();
    command = CommandEnumerations.GetRightIRSensor;
    this.telnet.SendMessage("ir 1");
    // Wait for the command to complete
    while(command!=0)
    {
        Application.DoEvents();
    }
    // Is the object cleared
    if (this.ir1.Reflection<70)
    {

    }
    else
    {
        // Move 15 degrees more away from the object
        this.listBoxReceived.Items.Clear();
        this.telnet.SendMessage("move 15 degrees");
        command = CommandEnumerations.MotorDone;
        this.telnet.SendMessage("events");
        // Wait for the command to complete
        while(command!=0)
        {
            Application.DoEvents();
        }
        // Recursive call to test for the object again
        RotateAwayFromObject();
    }
}

Well thats about it. The ability to extend the ER1 with the command line API is very nice and not too hard to do. I could easily convert this to be a stand alone console program and then call it from a behavior on the ER1 control center. Very cool!

Well here is the Code if you want to see how I did it.

New Category added to Weblog

PAReX This is a new category for PAReX authors to post links to other robot building articles on the web.

Dead Reckoning with R/C Servo

Implementing Dead Reckoning by Odometry on R/C Servo Robot

Servo Positioning

Improving Servo Positioning Accuracy Article on improving servo positioning with an external potentiometer

Servo Hack Variable Speed

Variable Speed Control Modification to the Futaba S3003 RC Servo

Servo Hack

How to modify a servo Another servo hack

Servo Hack Article

Servo modification for PWM control This looks like a cool article on hacking servos.