lobot::Behavior Class Reference

An ABC defining the common interface for all of lobot's behaviours. More...

#include <Robots/LoBot/control/LoBehavior.H>

Inheritance diagram for lobot::Behavior:
Inheritance graph
[legend]
Collaboration diagram for lobot::Behavior:
Collaboration graph
[legend]

List of all members.

Public Member Functions

virtual ~Behavior ()
 Clean-up.

Public Attributes

std::string name

Protected Member Functions

 Behavior (int update_delay, const std::string &drawable_name="", const Drawable::Geometry &=Drawable::Geometry())
void run ()
virtual void action ()=0

virtual void pre_run ()
virtual void post_run ()

Protected Attributes

int m_update_delay

Detailed Description

An ABC defining the common interface for all of lobot's behaviours.

This class implements an abstract base class for all the behaviours that make up the multithreaded Robolocust behaviour-based control system. Each behaviour is a goal-directed action that ties together a sensorimotor loop of some sort and runs in a separate thread. Behaviours are instantiated by the main thread during Robolocust's start-up sequence via an object factory. Which behaviours the robot controller should run are specified in the config file.

Each behaviour's main loop should take care to coordinate accesses to various shared sensors and other resources using the Robolocust UpdateLock.

Also, since a behaviour runs in its own thread, all subclasses *must* call Thread::start() in their constructors.

Definition at line 80 of file LoBehavior.H.


Constructor & Destructor Documentation

lobot::Behavior::Behavior ( int  update_delay,
const std::string drawable_name = "",
const Drawable::Geometry g = Drawable::Geometry() 
) [protected]

A protected constructor because behaviours are instantiated with an object factory and not directly by clients.

Derived classes must specify an appropriate update delay to use when they invoke this constructor. It is up to each individual behaviour to guard against possibly catastrophic update delay settings in the config file and provide reasonable defaults and boundaries.

Optionally, behaviours interested in visualization may provide the names and geometries for their respective drawables.

Definition at line 70 of file LoBehavior.C.

lobot::Behavior::~Behavior (  )  [virtual]

Clean-up.

Definition at line 105 of file LoBehavior.C.


Member Function Documentation

virtual void lobot::Behavior::action (  )  [protected, pure virtual]

This method implements the behaviour's action. Each behaviour must provide its own custom implementation of this function.

NOTE: This function is called by run() and is already ensconced within a loop. Derived classes should *not* run their own infinite or main-loop type loops in this method. Instead, they have to provide only the *body* of the main loop. That is, the Behavior::run() method implements the actual main loop of the behaviour while the derived class merely provides the individual steps that go into that main loop.

Also: Behavior subclasses should use UpdateLock as required in their definitions of the action() method to ensure proper access to shared sensor objects and other resources.

Referenced by run().

void lobot::Behavior::pre_run (  )  [protected, virtual]

These methods provides derived classes hooks for implementing any pre- and post-run operations. pre_run() is called right before the main loop is entered and post_run() right after it is exited.

Derived classes are not required to define these functions. The default versions implemented in the Behavior base class do nothing.

Definition at line 75 of file LoBehavior.C.

Referenced by run().

void lobot::Behavior::run (  )  [protected, virtual]

This method implements the behaviour's main loop, taking care of checking with the lobot::Shutdown object whether or not it's time to quit.

NOTE: Derived classes may but generally should not provide their own implementations of the Thread::run() method. If, for some reason, a subclass of lobot::Behavior needs to define its own version of run(), it should be sure to check the status of the lobot::Shutdown object.

Implements lobot::Thread.

Definition at line 79 of file LoBehavior.C.

References action(), lobot::Pause::is_clear(), m_update_delay, lobot::Thread::name(), pre_run(), lobot::Shutdown::signaled(), and lobot::App::wait_for_init().


Member Data Documentation

Every behaviour must wait a bit after its action method is executed before the next iteration. This update delay is a user setting specified in the config file. The delay is expected to be in milliseconds.

CAUTION: Since the update delay for each behaviour is customizable, it is possible for users to completely ruin the lobot controller by providing bizarre values. Therefore, each behaviour is expected to guard itself against such weirdness.

Definition at line 105 of file LoBehavior.H.

Referenced by run().

Each behaviour has a name that must be set by the client module.

NOTE: Being a public data member, this field is rife with possibilities for abuse. But, hopefully, clients will refrain from doing so (after all, what's the point in making life harder for yourself?). The intent here is to set this field when the behaviour is instantiated and leave it the hell alone thereafter.

Definition at line 93 of file LoBehavior.H.


The documentation for this class was generated from the following files:
Generated on Sun May 8 08:30:21 2011 for iLab Neuromorphic Vision Toolkit by  doxygen 1.6.3