Basic Rover Robot Reasoning
As we finish the mechanical and electrical assembly of our rover we must begin to think about the software that will run in out microprocessors to evaluate the sensors and determine the motion we wish to impart. It makes sense to first assemble the rover with the “cannedâ€
Advancing in the theme of writing a good program, I note Steve Norris’ excellent work with a rover. (Thanks Steve for allowing me to showcase your work) You may download his software for a rover at:
norrislabs.com/Projects/Rome … index.html
roam.bas is the software he wrote to run the A4WD1 rover (named Romey) and illustrateds some really good practices that I would like to highlight. It is a good idea to see the two pages on Steve’s site so as to see what he did. The main difference between the rover flowchart as shown in figure two and this one is that he used a ping sensor as well as the GPD2 sensors on the original A4WD1. It really doesn’t matter for the illustration I’m making, but keep that in mind. I suggest going to his website and opening the roam.bas application to follow along. Examining his photos of Romey make a lot of sense in order to see how he set up the ping sensor as well as to observe the GPD2 sensors below it.
The first thing I would like to point out is that his program roam.bas is very well commented). This seems to be a dying art now a days, but one which we should all strive to master. If you observe the following flowcharts note these highlights:
-The main event loop is very small. All it does is call a few subroutines and runs a short delay.
-The program begins with a great header commenting what it does, who made it and when.
-The variable names are chosen with great care so as to be very easy to interpret and follow along.
Observe the following flowcharts and note how a clean execution should be. There are flowcharts for the main program (Figure 3) and for the three other subroutines that the main event loop calls: Navigation in Figure 4, Danger in Figure 5, and Avoid in Figure 6.
It is evident that documenting someone else’s code is next to impossible if it is not clearly written. The fact that roam.bas is so clear made this flowcharting actually easy to do. Your projects will benefit from writing such flowcharts before coding. An added benefit is that debugging for errors will be much easier.
A small caveat: There may be a few minor errors or omissions in my flowcharts as it relates to roam.bas, but for the sake of illustrating flowcharting they are fairly meaningless and probably do not detract from a structure that you yourself could adapt to your rover project.
The graphic application I used to create the flowcharts is OmniGraffle Pro running on Mac OS X, though any drawing application will suffice for your own flowchart art.
its best to develop a flowchart before implementing a actual scenario using a flowchart software for mac
