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

[Charles Manning]

Behaviour based is very different from fuzzy logic, but there are some 
connections with BEAM (http://en.wikipedia.org/wiki/BEAM_robotics) and many 
of the behaviour-based concepts are inspired by BEAM and the early workers in 
both fields come from the same labs.

Both result in what is called "emergent behaviour". That is, complex behaviour 
emerges for simple behaviour patterns working together.

Behaviour based robots don't tend to have overall plans. ie instead of having 
a "big plan" called pick up cans and drop them over the side you instead have 
4 or more independent behaviours that come together and the complex behaviour 
emerges.

For example, a can picker might have the following independent behaviours in 
low to high priority order.

* Wander around
* If you see a can and don't have one, approach it.
* If you're touching a can and don't have one pick it up.
* If you have a can and find the edge, drop the can.
* If you are too close to the edge, back up so you don't fall.

Each of those can be individually programmed and tested. It would be 
interesting to consider how this could be done in NXT-G. Because you're 
making much simpler behaviour blocks, perhaps programming are actually easier 
like this.



On Wednesday 16 December 2009 11:54:34 Richard Jones wrote:
> 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.
>
> _______________________________________________
> 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.