[Robotgroup] Divide and Conquer!

[Vern Graner]

Mark Hinkle wrote:

Heh. :) Glad to find a fellow fan of this bot! :)

>    Jon, there are a lot of questions that will need to be addressed
>    regarding the protocol with such distributed processing structure.
>    For example: you built Odex-1 and you want Odex to lift its leg. How
>    far? For how long? What do you do if it cannot lift or lower its leg?
>    How do you know it cannot? How will you synchronize the legs for
>    "walking"? How fast? What direction? How far? Standing? The legs also
>    have pivot angles. How will you specify that in relation to the
>    generic tasks you will assign?

I don't claim (at all!) to be an expert in this regard (talk to Glenn of 
The Robot Brain fame for real expertise), but it seems the example 
questions you posed above above are not really where sub processing 
comes into play.

For example, in most of the hex crawlers (crust crawler, lynx motion 
etc), the sub processor (serial servo controller) is *only* responsible 
for accepting instructions and sending (and maintaining) corresponding 
signals to the servo motor. This relieves the main processor of the 
burden of calculating and generating the servo signals on the correct 
intervals to maintain position.

A sub processor in a distributed computing robotic control system would 
shoulder the burden of low-level processes such as keeping track of the 
health of the system (POST/DIAGS), how many steps a stepper motor has 
gone, whether or not a limit switch has been struck, whether or not a 
current limit has been exceeded, whether the moving part is in its 
commanded position etc.

This would free the main processor to do high level functions i.e. 
computing the walking gait, determining orientation and direction of 
movement, making decisions on path/target. It then issues "higher" level 
commands such as "go to position <x>" and leaves the pulsing, 
monitoring, counting and sensing to the subprocess. The main processor 
could then poll the subprocess for status to see if the instructions 
have been carried out.

As a hypothetical, lets say the main process gives a "go to position 
<x>" command. It then waits for an "ACK" or a "NAK". -- If the main 
process gets an "ACK", then it knows all is well and continues to 
process high level routines. If, on the other hand, it gets a NAK it can 
take additional measures such as sending a "status" query to the sub 
processor (position, health, diags etc), and choosing to branch to an 
error handling routine where it could choose different paths such as 
resending the command to the sub-processor or chosing a different "walk" 
gait that skips that leg.

Based on the result from the sub-processor the main processor could even 
exit error handler routine routine with a "leg is failed" result and 
initiate a recover process when an emergency "fail" subroutine could 
instruct the sub processor to retract the leg or perform some type of 
"get out of the way" routine i.e. trigger a solenoid that releases a 
spring that forcibly retracts the leg so it doesn't "trip" the remaining 
good legs.

The neat thing is that the complexity I've outlined above would have 
been next to impossible for a hobbyist to afford using only 1980's 
processor technology but should well in reach using some off the shelf 
hobbyist microcontrollers available today. :)

Dang. I really want to build an odex1! :) It would be sooooo cool! :D

Vern


-- 
Vern Graner CNE/CNA/SSE    | "If the network is down, then you're
Senior Systems Engineer    | obviously incompetent so why are we
Texas Information Services | paying you? Of course, if the network
http://www.txis.com        | is up, then we obviously don't need
Austin Office 512 328-8947 | you, so why are we paying you?" ©VLG