Mobile Robot Programming - PowerPoint PPT Presentation

1 / 12
About This Presentation
Title:

Mobile Robot Programming

Description:

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 ... – PowerPoint PPT presentation

Number of Views:22
Avg rating:3.0/5.0
Slides: 13
Provided by: deryckaust
Category:

less

Transcript and Presenter's Notes

Title: Mobile Robot Programming


1
Mobile Robot Programming
  • Deryck Morales
  • 24-700 / 16-735 Sensor Based Robotic Motion
    Planning
  • Fall 2001

2
Outline
  • Logistics
  • Iterative Programming Tips
  • Robot Programming

3
Logistics
  • 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

4
Logistics
  • 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.

5
Iterative 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.
6
Initialization
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()
7
Local 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.
8
Safety 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)
9
Halting 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.
10
No 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.
11
Meetpoint 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.
12
Summary
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
Write a Comment
User Comments (0)
About PowerShow.com