<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.5730.11" name=GENERATOR></HEAD>
<BODY id=role_body style="FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Arial"
bottomMargin=7 leftMargin=7 topMargin=7 rightMargin=7>
<DIV dir=ltr align=left><SPAN class=545070521-07122006>If I remember correctly,
the rules to state something about the "entire" robot crossing the line to and
from point A. If the robot drops something, then the entire robot never crosses
the line.</SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=545070521-07122006></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=545070521-07122006>Rick</SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> dprglist-bounces@dprg.org
[mailto:dprglist-bounces@dprg.org] <B>On Behalf Of
</B>DeltaGraph@aol.com<BR><B>Sent:</B> Thursday, December 07, 2006 2:15
PM<BR><B>To:</B> swindle@compuserve.com; dprglist@dprg.org<BR><B>Subject:</B>
Re: [DPRG] Are representations what makes Can Can hard?<BR></FONT><BR></DIV>
<DIV></DIV><FONT id=role_document face=Arial size=2>
<DIV>I did not see anything in the rules excluding beacons.</DIV>
<DIV> </DIV>
<DIV>On the can end, the current rules mention substitution the white
course can with a can of another color or a "B-can" of your own design.</DIV>
<DIV> </DIV>
<DIV>If you would like to put a home base beacon up, who will stop you?</DIV>
<DIV> </DIV>
<DIV>If contest rules become overly restrictive on how you do a task. They
really should be examined.</DIV>
<DIV> </DIV>
<DIV>Also, if shorter walls in Can collection killed the opportunity
to use sonar, maybe that should be examined against visibility and
transportability of a contest course -- or hold contests at the warehouse
and invite use of either course.</DIV>
<DIV> </DIV>
<DIV>I should mention the goal in single can collection concept was to
speed the contest and reduce its complexity. I am sure David
Anderson spent some time adding the ability to do position
re-calibrate (odometry referencing robot) -- I know I did, when I attempted
to do that on a fire fighting robot using video analysis of a wall floor
border.</DIV>
<DIV> </DIV>
<DIV>Orange cans are easy to see if you are using video. If cost is prohibitive,
I would recommend going after beacon technology. Dale Wheat was pushing on
beacon design earlier this year -- cheap!</DIV>
<DIV> </DIV>
<DIV>At last months meeting, David Anderson proposed contests that would tend to
encourage development of odometry skills + big help for most everyone.</DIV>
<DIV> </DIV>
<DIV>I wonder how well David's SR04 would perform Can Can without use
of odometry?</DIV>
<DIV> </DIV>
<DIV>Odometry is a king, I caught on to that fact real quick when I joined the
club, never mind all the distractions off into 3D simulation land and
speech I/O that have overcomplicated my software..</DIV>
<DIV> </DIV>
<DIV>I guess too the dual benefits of motor encoders being useful
in controlling motor speed and measuring distance traveled with
little sensor lag and not much "noise" when on a smooth surface
& not slipping , make that technology important to master.</DIV>
<DIV> </DIV>
<DIV>IMHO, We really need to encourage learning and implementing that
skill in our robot builders. </DIV>
<DIV> </DIV>
<DIV>Also, beyond all other skills, teach the most important, DIVIDE
AND CONQUER. </DIV>
<DIV> </DIV>
<DIV>R o n</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV></FONT></BODY></HTML>