Title: Mobile Robot Programming
1Mobile Robot Programming
- Deryck Morales
- 24-700 / 16-735 Sensor Based Robotic Motion
Planning - Fall 2001
2Outline
- Logistics
- Iterative Programming Tips
- Robot Programming
3Logistics
- In order to make class demos run more smoothly, a
few rules are to be established - As mentioned in class, use the sample code
provided by Ercan that allows for one line
switching between robots (n200 and scout). This
includes using generic_x() functions throughout
your code. - In your Make files, add a rule to use Ndirect
instead of Nclient - (Note the trailing lm, please add this to all
rules if absent) -
- MR_OFILES2 Ndirect.o YourProgramName.o
-
- robot (MR_OFILES2) Makefile
- (CC) -g -O2 (MR_OFILES2) -L. -o (TARGET)
(LIB_PATH) -lm
4Logistics
- Please collect all of your program files in one
subdirectory, for example - username/hw8/
- Then tar the directory using the following name
convention - ../username/gt tar cvf usernameHW8.tar
hw8 - This is the file to be submitted to your
directory on irashaimase.sbp.ri.cmu.edu.
5Iterative Programming Tips
Write a manageable section of new code, then
compile and test. When and if errors occur this
allows the programmer to know within the scope of
a few lines where the error must reside. This may
seem tedious, but in the long run is much more
efficient than hunting down an unknown problem
source. This is exponentially true when several
bugs are written into the code. Judicious use of
printf() expedites the debugging process. I
recommend the use of global debugging flags such
that debugging details can be toggled on and
off. The Nomad 200 has speech capability, which
may be used in a similar manner to debug your
programs. See the N200 manual for details.
6Initialization
With this code in your header file you can
readily change the port for the
simulator define PORT xxxx Then in your
initialization, remember to initialize the
sonars, reset the encoders and set the
port conf_sn(FIRERATE, SN_ORDER) SERV_TCP_POR
T PORT zr()
7Local Mins
Detecting local minima is fundamental to GVG
mapping. This is the method that I use to
process the sonar data into meaningful obstacle
location data Make an array that tracks the
sign of change between adjacent sonar
values. Using these signs, decide where local
minima occur a local minima is the median sonar
between a change from decreasing value to
increasing value. You may find that sorting
these minima according to proximity is a useful
post-process.
8Safety Checks
Every time the robot is in motion, there is a
chance that it is proceeding towards an obstacle
in the environment. It is imperative that a
safety check is included in the process such that
the robot will not run into obstacles. This is
very easy to write and there are no excuses for
allowing the robot to move into an obstacle
simply define a threshold value for sonar reads
(I recommend 10 inches) and use it as
follows int proximity() int
i gs() for(i0ilt16i) if(StateSTATE_SONAR_
0 i lt THRESHOLD) return(1) return(0)
9Halting Sonars
Every time the robot is in motion, there is a
chance that it is proceeding towards an obstacle
in the environment. It is imperative that a
safety check is included in the process such that
the robot will not run into obstacles. Halting
the sonars as a clean up step is also no longer
recommended it is required. int STOP_ORDER16
255,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 void
haltSonars() conf_sn(255,STOP_ORDER)
return Simply calling haltSonars() before
disconnecting the robot does the job.
10No Jerky Motions
Use reasonable step sizes for any pr() calls.
This means an absolute minimum of 1 inch
steps. Consider controlled vm() calls,
especially for edge tracing with a control
law. By controlled I mean not exceeding speeds of
3 inches per second. All pr() commands must be
followed by the appropriate ws() command. If this
is not done then the pr() will never be
physically executed by the robot, and the
resulting jerky motion will be interpreted as a
failure in your algorithm. I will not tolerate a
program that may cause permanent damage to a
valuable robot.
11Meetpoint Homing
When the edge tracing subroutine of your program
detects a meetpoint condition, it is not
sufficient to halt and mark your current location
as the meetpoint. You must use some method of
homing to consistently find the
meetpoints. Recall that to do this involves
calculating the coordinates of the three local
minima a,b,c and the lines that connect them ab,
bc. Using the midpoints of these chords and the
lines orthogonal, their point of intersection p
lies on the line between the current robot
position and the actual meetpoint in the
environment. Taking a step in the direction of
p and then repeating these calculations is a
sound homing method, and I use a satisfaction
range of 2 inches.
12Summary
In the end, learning to program the mobile robot
should be an enjoyable task, and a rewarding one
as well. To that end, do no hesitate to ask for
help. A good rule of thumb when proceeding is
if your program behaves strangely at any point,
and anyone were to ask you why is the robot
doing this? your response should never be a
simple I dont know. Know your program make
useful outputs, consider writing to a file as
well for post examination, et cetera. CONTACTS
Deryck Morales deryck_at_andrew.cmu.edu Al
Costa acosta_at_andrew.cmu.edu Ercan Acar
eua_at_andrew.cmu.edu Ji Yeong jiyeongl_at_andrew.cmu
.edu Howie Choset choset_at_cs.cmu.edu