DPRG mailing list archives: [DPRG] Will Kuhnle's speculations on Can Can

Wed Jan 3 23:09:06 CST 2007

> Will's comments
> ------------------------------------------------------------
>
> Why is Can Can so hard?
>
> I believe a successful Can Can Robot needs the following (or equivalent)
> capabilites/behaviors:
>
> 1> Execute Search maneuver.
> 2> Detect object.
> 3> Locate object.
> 4> Identify/reconize object as a can.

I know this is optimistic - in a few months the computer vision code will 
be good enough to do these four reliably for the DPRG warehouse course 
area. That means it will segment the drivable surface (know where the 
walls are) and recognize cans on that surface.

> 5> Approach/drive_toward can.
> 6> Determine when can is within griper's gripping zone.
> 7> Grip can.
> 8> Know and take actions necesary to get home.

This mechatronic and control/behavior stuff is harder than it looks. I've 
learned that the hard way.

> 9> Recognize home.

This may become very easy with vision. At worst, a sign with something 
like a big checkerboard pattern could be placed in the starting corner. 
This is pretty hard to miss for a vision system. (Even easier - put a 
saturated flourescent orange traffic cone in the starting corner.)

> 10> Maneuver can to desired location (old multi-can Can Can only)
> 11> Release can.

Vision can help. But mostly I agree with David Anderson's thesis that 
knowing what to do is not the same as mechatronic and control capability 
necessary to actually do it. The robot needs a good "body".

>  And only for the old multi-can Can Can.
> 12> Recalibrate robot's location and/or orientation with respect to
> playpen.

Vision might be able to help here too. Besides projecting the view to a 
ground plane and finding the edges of the contest area (which will be 
approximate due to low resolution of camera and fairly large Hough 
transform bins for speed), reference objects in the environment allow 
triangulating position. A robot that can turn in place could figure out 
position based on reference landmarks around it.

> 13> Ability to repeat 1 through 11.
> 14> Know when to quit.
>
> Robots to compete in our other events, line following, wall following,
> quick trip, etc, need only one or two capabilites/behaviors. My robots,
> Rube and E. Spiral have no brains
> (electronics) at all!  Based on the number of behaviors, Can Can is five
> to ten times harder than our other events.
>
> And I believe that, at least initially, difficulty goes up faster than
> the number of behaviors. With one or two behaviors the program can be a
> simple loop. But for a large number of behaviors, a more complex program
> structure is required. Also hardware and behaviors must be more
> reliable. A robot with two behaviors, each working properly 85% of the
> time, can be expected to work about 72% of the time. With ten behaviors
> this drops to about 20%. The robot can not win if it does not work.
>
> I have observed that some (most ??) of our members start building their
> robot a week or less before the contest. Even if they complete the robot
> in time for the contest they do not have time to properly test and
> refine it. I believe a Can Can robot can not be built that way. It
> requires a lot of persistance and/or methodical effort. Each behavior
> should be implemented, thoroughly tested and refined before moving on to
> the next behavior. Too much like work for a hobby? Perhaps.  I expect to
> build a Can Can Robot, but it will not be any time soon. I am still in
> the learning mode.

One thing I've concluded is that the process of developing a robot is 
necessarily interactive. Instead of an IDE that fits on your desktop 
workstation, now the IDE is the contest course, robot, electronics bench 
and firmware/software development environment in combination. You can't 
test without the physical course.

So my thought now is to move all high-level intelligence off of the robot. 
Now the robot becomes a teleoperated automaton with a nearby computer 
actually driving it. The big advantage is that software development and 
testing is much easier. By running the robot from a fixed computer, we can 
watch and instrument what it is doing in real-time. And changes can 
similarly be made very quickly. Also, much higher computer performance 
levels become practical (e.g. use a dual-core laptop to drive a small 
robot over WiFi link). The limitation of this is of course radio range. 
But for now, I think most of us have huge problems just getting our stuff 
to even work let alone operate autonomously away from us.

> Will Kuhnle
> 01/02/07
>
>
>
> ------------------------------------------------------------
> End of Will's comments.
>
> Again, please don't reply to me. Post your replies to the list if you
> want Will to see 'em.
>
> -Steve
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://list.dprg.org/mailman/listinfo/dprglist
>