[chbot] Behaviour based robotics vs state machines and NXT-G

[Richard Jones]

Totally agree. Having a team of motivated testers discovered more bugs than
I knew about. Especially two cans near together, the robot tries to lift
the gap! Now you come to mention it I recall that some complex animal team
behaviours can be simulated from quite simple behaviours. I suspect that if
you black box a behaviour implementation and a state machine implementation
you could not tell the difference. If that is true I wonder whether one is
simpler to design and implement than the other? Probably depends on the
problem being solved. In which case its very handy having the extra tools
in the toolbox so that the most appropriate can be chosen.

The undesirable actions were due to a deviation from the state machine
design to a 'quick hack' sequential half angle joggle function that I threw
in when I discovered that the ultrasonic beam is wider than the can lifter
jaws. The thoughtful solution that I would adopt from where the program is
just now would be to adapt the Moore machine to transition from any state
to edge of table state when a new edge is detected, and integrate half
angle calculator into the state machine. Maybe I'll have a play with the
behaviour model for the speed line following challenge. A worked example
from one who knows would be good too.

What I set out to discover on this journey was how hard is a Robocup like
challenge using NXT-G. The answer for me is that the NXT-G environment is
OK but frustrating. The way that comments don't move with block edits
discourages comments, but comments are essential when looking back over a
program to understand its intent. I had to recreate one myblock because it
had unexplainable behaviour. However I did discover that state machines are
reasonable to construct in NXT-G. Debugging using the display and sound was
really useful. Some lighting conditions seem to confuse the light sensors
even when carefully calibrated. So we may have to control competition
lighting carefully, design more lighting immune robots or both. When close
range ultrasonic readings were hopeless I took a longer range reading and
used dead reckoning to close the remaining distance.

Altogether quite a worthwhile journey. I think I prefer programming 'C' for
my micromouse and C++ when I have the space and mips.

All this leaves me wondering if behaviour based programming might sometimes
have something in common with fuzzy logic.

Richard

On Wed, 16 Dec 2009 10:15:22 +1300, Charles Manning
<manningc2 at actrix.gen.nz> wrote:
> Hi All
> 
> I'm hope Richard won't mind me using his "crash" as a learning
exercise...
> 
> Richard's state machine can picker operated very well until just at the
end
> 
> where (I'm assuming here) the edge of the table was reached when the
state 
> machine was not handling the condition so it drove off the edge of the
> table 
> while trying to pick up a can that was off the edge of the table.
> 
> While state machines are great, this does underline one of the problems
> with 
> trying to do many behaviours in one state machine: the state machine gets

> quite complex and it is easy to forget a transition.
> 
> One great way to address this is to use what is termed behaviour-based 
> robotics (see: http://en.wikipedia.org/wiki/Behavior-based_robotics for a

> launch off point). The approach taken here is to build modular blocks of 
> behaviour, then tier the behaviours in priorities.
> 
> Behaviors are tiered in a prioritised way so that a more important
> behaviour 
> would suppress a less important behaviour. ie. the "Don't fall off the
> table" 
> behaviour would be the most important and would override others. That
way,
> if 
> you're halfway through picking up a can and you detect that you might
fall 
> off, then picking up the can is aborted and the robot takes immediate
> action 
> to prevent falling off the edge.
> 
> Each behaviour has three logical functions:
> * Trigger: The detecting function to say whether this behaviour should be

> entered.
> * Action: The action for this behavior.
> * Exit: The action to cancel this behavior if suppressed by another
> behaviour.
> 
> Some real benefits of this are:
> * The behaviors are modular meaning that they focus just on one thing,
> making 
> them each a lot simpler. The can-lifting behaviour does not have to worry

> about falling off the edge.
> * The behaviours can be tested independently.
> * The behaviours are easier to reuse in different robots.
> 
> I have not thought about how you would try to do behaviour based programs
> in 
> NXT graphical programming, but it is probably no more complex than state 
> machine programming. Lejos has a set of libraries that provides behavior 
> based robotics.
> 
> For a very interesting read, I strongly recommend the book: "Robot 
> programming: A practical guide to behaviour-based robotics" by Joe Jones
> and 
> Daniel Roth. These guys consulted on the design of the Roomba and some of
> the 
> Mars explorers.
> 
> I suppose I should put my money where my mouth is and build a behavior
> based 
> can-picker for the next meeting...
> 
> -- Charles
> 
> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/chchrobotics
> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> Web site: http://kiwibots.org
> Meeting Dates:
> Tue 15 December 2009 6.30pm
> Wed 17 February 2010 6.30pm
> When replying, please edit your Subject line to reflect new content.