DPRG List  

[DPRG] Right tool for the job

Subject: [DPRG] Right tool for the job
From: dpa dpa at io.isem.smu.edu
Date: Tue Aug 28 14:22:10 CDT 2007


Sluggy (via Dave Grubb) wrote:
> Essentially, I think my and Jeffs answers can be summed up 
> as right tool for the job. :)

and the corollary to the "right tool for the job" is that "it's
a poor workman that blames his tools."

Randy wrote:

> I was trying with Travis Trotman to do his red octbot, and we
> were using a SRF04 ranger, and found, much to my surprize, it
> was thoroughly lost in one of our table top arenas. We did a
> circular scan hoping to find the corners of the arena, and the
> bounces and discontinuities were so awful, we really couldn't
> use them for navigation. 

I've found it more useful for the DPRG CanCan competition to use
a pair of sonar sensors in combination as an edge detector, rather
than attempting to use the sonar information for mapping, which is
always prone to error.  Google "Intelligence Without Representation"
for a good starting place as to why this is so.

The SR04 robot's use of sonars as edge detectors for robust soda
can identification and collection might be a modest example of using 
the right tool for the job. 

Joe Jones explains this better than I can, so take it away Joe...


Quote from Joseph Jones "Robot Programming" Chapter 4, pp 88-89:

(note that Jones uses the phrase "behavior-based robotics" to refer to his
particular flavor of subsumption --- dpa):

A team wants to build a robot able to navigate to a particular point while
avoiding obstacles.  The designers observe that sonar sensors are usually
able to detect obstacles while the obstacles are a good distance away from
the robot; therefore, a navigation sensor and an inexpensive sonar ranger
are the only sensors the robot really needs.  The team feels that this
choice will minimize the robot cost and design time.  The robot is built
and a program is written that avoids objects based on sonar range information.
The team makes a few test runs with the robot and it becomes clear that the
reasoning is correct --- usually the sonar system does detect obstacles.  But
it is also clear that "usually" isn't good enough.  Whenever the robot happens
to encounter an undetectable object, it becomes hung up, unable to complete its
task --- and the robot seems especially adept at locating obstacles the sonar
can't see.

What to do?  Clearly the program works when it gets good data from the sonar
system.  So the problem can't be the software; it must be that the sonar system
just isn't up to snuff.  The team makes a decision to switch to a more expensive
obstacle-detecting system that uses multiple, higher-frequency sonar sensors.
Higher frequency means shorter wavelength;  shorter wavelength means that
smaller objects can scatter the ultrasonic waves and therefore fewer obstacles
go undetected.

The refitted robot does work better.  It can handle more marginal obstacles
and can detect those obstacles from a larger set of approach angles.  But
there are still too many situations that trap the robot; the robot cannot
reliably complete its task in the environments where it is required to
operate.  Again, the program and strategy appear sound --- the problem, the
team concludes, is the quality of the data.

Maybe the robot's difficulty stems from choosing a sonar system in the first
place.  Perhaps a much more capable scanning laser ranging system would be
more appropriate.  Such systems are available at the cost of a few thousand
dollars.  The robot may have to be redesigned and made larger to accommodate
the laser device and the laser scanner's data processing requirements now
exceed the abilities of the robot's original 8-bit microprocessor --- that
will have to be changed too.  Rebuilding the robot with a larger processor
will add even more to the cost.  At some point, the project becomes so
expensive that the team is forced to make a painful decision --- either
abandon the project altogether or go forward with the existing equipment.
The latter choice means that to use the robot, an operator must cleanse the
environment of any obstacles the robot can't see before starting a run.

At this point, an honest assessment of the project would conclude that the
team has not built a practical robot...

The notion of graceful degradation facilitated by a behavior-based approach
to robot design allows us to dodge such woeful tales.  In behavior-based
robotics, we do not employ a single expensive sensor from which we must
demand unattainable levels of precision and reliability.  Rather, we achieve
superior results using a combination of relatively unreliable systems that
work together to deliver robust performance.



If we just had better sensors, better quality data... yeah, that's the
ticket!  It can't be our designs or our software.  We just need to wait
for better sensors to come along.  Then we'll make progress!  <grin>


More information about the DPRG mailing list