Overview

The following article was originally posted by me on the Phoenix Area Robotics eXperimenters web site.  I moved the article here on my blog as I no longer belong to the Robotics group.  You can find the original article on the PAReX site.

Building a Maze Robot

My maze robot DR X took first place in BotBash’s 2000 Autonomous Maze competition. The competition consisted of three mazes with different configurations. The robot that completed all three mazes in the shortest time wins the event. Each robot had five chances to complete all three mazes. The shortest three times where summed up for the final score. DR X was the only robot able to complete all three mazes in the allotted time frame. This article was written as an attempt to explain the techniques used to allow DR X to accomplish first place.

There are several techniques that can be used in solving mazes:

• Random
• Wall Following
• Mapping

Random navigation does not seem like a very elegant way to master a maze so my choices were mapping or wall following algorithms. Mapping a maze can be very difficult to do and this competition did not really reward such a task. So that leaves wall following as the best bet to complete the maze.

Wall following can be best explained by imagining yourself in a maze with your eyes closed. If you could place one hand on a wall and never let the hand leave the wall you will eventually find the end of the maze as long as the finish is not an island in the middle of the maze. It is very important to follow only one wall until you reach the end.

The following drawings show right and left wall following paths for a given maze.

Notice that in some cases it is better to choose one wall to follow over another. Here the shortest path from start (S) to finish (F) is via the right wall. So it is good practice to be able to command your robot to follow one wall over another before it is set in the start box. This can be accomplished by using the left and right bumper switches. Tapping the left or right switch before the start commands the robot to follow the left or right wall.

So I set out to build and program a maze robot to follow one wall. I choose to use a differential drive system on a round body. This would allow me to control the robot rather easily and prevent it from getting hung up on maze walls. I mounted two GP2D02 IR Sensors on a single shaft on top of a servomotor. The sensors were positioned 90 degrees apart. The servomotor allowed the robot to look straight ahead and the left or right wall at the same time.

DR X First Prototype

In order to tell if the robot was getting closer or further away from a wall a minimum of two sensor readings would have to be taken over a period of time while the robot was moving. I had some difficulty in fine-tuning the reactions needed to prevent the robot from touching the walls. I quickly realized that this sensor arrangement had some shortcomings. I needed to be able to look at a wall and determine if the robot was parallel to it without moving forward. If I could achieve this, the robot would always start off parallel to a given wall. So I made some sensor placement changes that would not require the robot to be moving in order to determine if it was parallel or not.

DR X Second Prototype

I found out some other advantages of this sensor arrangement. While the robot was following a wall and it approached a doorway of the maze the first sensor would detect the opening (doorway) very easily. Once the second sensor detected the doorway I knew the robot was directly in front of the entranceway. A 90 degree turn towards the entranceway would position the robot perfectly for passage through the door. Passage through the door would also be easily detected. As the robot moved forward, the door jam could be detected by both sensors. The robot could successfully determine when a door was found and navigate through the door rather easily.

The following drawings show the robot navigating through a doorway.

The robot approaches the doorway

The robot passes the doorway

The robot turns left 90 degrees

The robot moves forward into the doorway

The robot is almost through the doorway.

The robot is through the doorway.

DR X Front View

DR X Side View

Improvements

Well this solution certainly has room for improvement and it is not the only way to solve a maze. One major enhancement that I saw was DR X needed a sensor that could look in front of the robot while it was attempting to follow a wall. This would have prevented the robot from having to collide with a wall before it realized it needed to stop and turn.

Conclusions

Well this project sure was a gratifying experience. To watch my little creation navigate the maze was a great thrill. A lot of last minute hard work went into this robot but come event day it all paid off.

I have been doing some BX24 development again lately.  I have also been reading a lot about the new shell support that Microsoft has pre-released called PowerShell (formerly known as Monad).  Well since I have been using the same batch files and VBScript files to manage my build process for BasicX source since 2001 I thought it might be time to look at another alternative. 

I need to be able to do the following:

• Perform command line compiles of the BX24 project
• Allow for the source to reside anywhere on the hard drive and still be able to compile.
• Initiate a compile of all BX24 projects so I do not have to do them one at a time
• Parse the BasicX.err file to determine if the compiler found errors
• Launch an editor that shows the BasicX.err file only when an error exists
• Be able to manage some registry entries specific to the BasicX IDE
• Have a limited set of scripts that do not require any changes to support the build process
• Allow for multiple project files to co-exist in the same folder. This means I need to save off the BasicX.err file into another file if I want to preserve what the results where from the compile.

After reading some about PowerShell it was very apparent that it would support anything I needed to do.  The main huddle I needed to over come was learning the syntax that revolved around PowerShell.  Fortunately it is based on the .Net framework so the majority of it was fairly easy to adjust to. 

Since I already had a VBScript file that did most of the above tasks I started dissecting what it did first.  The last time I touched this script was in 2001.  The script did the pieces around changing the registry entries and launching the compiler but it had no support for parsing the error file and managing many project files.  Here is the script that I ended up with:

param ([string]$WorkingDirectory)

# Define some script variables$chip_type="BX24"

# Save the current dirrectory so we can return to it

Push-Location

# If a working directory was passed in lets change to it

If ($WorkingDirectory){Set-Location $WorkingDirectory}

# Get the project files to process

$projectFiles = Get-ChildItem *.bxp 

foreach ($project in $projectFiles){$project_file = $project.name.split(".")[0]

# Use the current directory as the working directory

$work_dir = $project.DirectoryName

# Set some registry entries for the basicx IDE

$configEntry = "hkcu:\software\vb and vba Program Settings\basicx\config"

Set-ItemProperty ($configEntry) -Name Chip_Type -value 

$chip_typeSet-ItemProperty ($configEntry) -Name Work_Dir -value 

$work_dir

# determine from the registry where the basicx executable is installed

$program_dir = Get-ItemProperty ($configEntry) -Name Install_Directory

# Map the P drive to the basicx install directory for convieniance

if (Test-Path p:) {}else {subst P: $program_dir.Install_Directory}

# Remove the error file if it exists

if (Test-Path basicx.err){del basicx.err}

if (Test-Path ($project_file + ".err")){del ($project_file + ".err")}

# Launch the compiler

P:\basicx.exe $project_file /c

# Wait for the compiler to finish

$processToWatch = Get-Process basicx$processToWatch.WaitForExit()

# Unmap P: drive

if (Test-Path p:){subst P: /d}

# Check for errors and launch the error file if some do exist

$CompileResult = get-content basicx.err

If (($CompileResult -match "Error in module").Length -gt 0){notepad basicx.err}

# Copy the error file off so it does not get overwritten when multiple

# projects are being compiled in a single directory

copy-item basicx.err -destination ($project_file + ".err")} 

# Restore the original location

Pop-Location

Well that was pretty painless.  I basically had a script that managed processing all BasicX project files in a given folder.  Next I needed to have another script that found all the project folders for a given folder.  This also meant processing projects in sub folders.  This higher level script would launch the script above to do the compile.  I ended up with the following script:

# Save the current dirrectory so we can return to it

Push-LocationSet-Location ..\

# Get a list of all projects

$project_Files = Get-ChildItem -recurse -include *.bxp | sort $_.DirectoryName$lastDir=""

foreach($project in $project_Files)

{

# Since we can have multiple projects in a folder and we send the

# working folder to the build script we want to skip folders we already

# processed

if ($lastdir -ne $project.DirectoryName)

{./tools/build $project.DirectoryName  $lastDir = $project.DirectoryName}}

Pop-Location

Well that too was pretty easy.  I am beginning to really respect the power of PowerShell.  I can do so much more than what I was able to do with VBScript and do it easier.  Later I will but together a sample BX24 project showing how I use these scripts and the folder structure I place them in.

Although the BasicX Integrated Development Environment works for writing, compiling and downloading source code for small quick projects once you start using it a lot for writing source code it tends to be lacking features.  However the folks at Netmedia were nice enough to allow for command line execution of their IDE to compile and download code.  This opens up the opportunity to use your favorite editor to write source code and launch the IDE via command line to compile the source.  I have been using these command line options since 2001 to make my development environment a little more to my liking.  In this blog post I will talk about how I manage the process and the tools I use.

First a couple notes about some things that might trip you up in using the command line options.  The BasicX IDE wants to know the base directory where your projects live.  This is ok if you want to manage this directory in the IDE every time you switch to another folder or if you only have one project.  However if you are like me you have many projects and you don't want to have to load up the IDE to change this base directory every time you work on one of them.  Next the chip setting for BX24 or BX01 is also set from the IDE and is needed for the command line compile.  I bounce back and fourth between projects that use one or the other chip so my IDE could be set for either one at any given time. 

Neither the base directory or the chip setting is offered as an option in the command line.  Although Netmedia does store these items in the Windows Registry so an external program can modify them before launching the command line compile.

So I created a vbscript that sets the IDE options and then calls the compiler.  The script accepts 3 parameters:
 1 (Required) - Project file
 2 (Optional) - /c
 3 (Optional) - /d

The script supports drag and drop capabilities so you can use it 1 of 2 ways. 
1 - Drag the project file onto the script
2 - Call the script from your editor or a batch file

I usually create a build.bat file that I just call from the text editor.  The build batch file is specific to the project that I am working on so I generally keep it in the main folder of my project.

I have included the script files along with a sample BX24 project so you can look at what I did and maybe make use of it for your own BasicX projects.

I also use a shareware text editor called TextPad.  This editor supports syntax highlighting and multiple documents.  The nice thing about it is that I can pass TextPad the project file and it can load up all the source modules that are associated with the project.  I often use a batch file to launch the textpad editor and open all the source code for the project.  I have also included this batch file in the bx24.zip so you can see how it is done.