Mobile robot requirements

superbshelfMobile - Wireless

Nov 12, 2013 (4 years and 8 months ago)


© Ian Davis


Mobile robot requirements


(1) Must behave in a deliberate manner

(2) Must react appropriately to it’s environment

(3) Must anticipate uncertain information

(4) Must be both robust and fault tolerant

(5) Architecture must be incrementally flexible

© Ian Davis


Mobile robot functions

Typical software functions

Acquiring and interpreting input from sensors

Controlling the motion of all moving parts

Planning future activities

Responding to current difficulties

© Ian Davis


Mobile robot complications

Possible complications

Obstacles may block chosen path

Sensor input may be imperfect or fail

Robot may run out of power

Movement may diverge from plans

Robot encounters hazardous materials (water)

Unpredictable events demand panic response

© Ian Davis


Mobile robot architectures

Closed loop control architecture

Layered architecture

Implicit invocation

Blackboard architecture

Incremental architecture

© Ian Davis


Closed loop architecture

Simple interconnection between sensors and

Appropriate for rigid requirements. Eg.
follow black line.

Doesn’t scale well. Inflexible, hard to
change or refine.

Conflicts between multiple feedback loops.
(eg. getting dark, near water, low battery).

© Ian Davis


Closed loop evaluation

(1) Behaves in very deliberate manner.

(2) Difficult to respond to the unexpected.

(3) Hard to structure logic into cooperating
components, or layer overall software.

(4) Simplicity improves robustness.

(5) Loose coordination between hardware
components simplifies replacement and/or
duplication of sub units.

© Ian Davis


Closed loop overall

Appropriate for simple robotic systems that
must respond to only a small number of
external events, and whose tasks do not
require complex decomposition.

Appropriate for simple components of a
larger systems (eg. Directional steering)

Might be improved by a learning module
responsible for adjusting the closed loop
parameters based on experience.

© Ian Davis


Layered architecture

User input and supervisory functions

Global planning

Control logic


world modelling via data structures

Collective sensor integration

Individual sensor interpretation

Robots hardware control

© Ian Davis


Layered architecture observations

Seems like we are getting serious about
building a sophisticated robot.

Much more detailed appreciation of the
software problem, if not its solution.

We are creating a lot of work for ourselves.

© Ian Davis


Layered architecture pros

Comfortable organization of development

Layers can be tested in isolation.

Layers of sophistication cleanly convert low
level sensory uncertainty into appropriate
high level decision making.

Real world data model improves flexibility
by separating role of data capture from data

© Ian Davis


Layered evaluation cons

No clear division between data hierarchy
world modelling) and control
hierarchy (real
world behaviour).

Poor tolerance for failure. Hard to continue
if layers of software fail or register faults.

Changes to low levels of software likely to
impact on all layers of software

© Ian Davis


Layered architecture overall

High level view of robotic control system
provides a good point of departure.

Layered evaluation useful in identifying
layers of interface which may simplify
design and testing of robot.

Layered approach ties our hands very early
on in the design process.

Architecture may not map cleanly to the
low level implementation.

© Ian Davis


Implicit invocation

Task control architecture.

Hierarchy of tasks called task trees.

Task trees are directed at one or more tasks
registered to handle them.

Task trees may be revised following
exceptions etc.

© Ian Davis


Implicit invocation evaluation

Clear separation of action and reaction.

Explicit support for concurrent agents.

Uncertainty may be addressed by
distributed software, diverse software
solutions etc.

Exception handling, wiretapping, and
monitoring features improve fault tolerance.

Good support for incremental development.

© Ian Davis


Implicit invocation overall

TCA offers a comprehensive set of features
for coordinating tasks of robot based on
both expected and unexpected events.

Appropriate for complex robotic projects.

Focuses on independent separate tasks.

Provides better support for autonomous
behaviour of parts than layered architecture.

© Ian Davis


Blackboard architecture

Central repository of data reflecting real
world view/knowledge base seen by robot.

Operated on by:





The perception subsystem

© Ian Davis


Blackboard evaluation

Data is passive

participants are active.

Stronger division into roles encourages
greater cohesion than implicit invocation.

Task control architecture can be usefully
layered as a subsystem of blackboard.

May suffer same implementation problems
as layered approach. Suggested roles are
somewhat arbitrary human concepts.

© Ian Davis


Iterative improvement approach

Build the robot in iterative stages.

Carefully progress the software from being
overly simple and restrictive, towards
showing intelligent behaviour.

Design the software based not on perceived
needs but on observed behaviour.

Limited knowledge about expected final
behavior of robot.

© Ian Davis


Iterative improvement pros

Gets something up and working fast,
improving moral.

Allows low level software to be tried and
tested before most development begins.

Allows more feedback earlier, resulting in
more flexible responses to problems.

Invites change and innovation throughout
project life cycle.

© Ian Davis


Iterative improvement cons

Hard/impossible to co
ordinate team.

Hard to manage constant software changes.

Software quality very vulnerable to change.

Resulting deliverable very unclear.

Huge problems with software maintenance.

© Ian Davis


Iterative improvement overall

Reasonable strategy for a small project, or
large project involving very few people.

Useful approach when prototyping.

Appropriate for small sections of code,
having well defined behaviour.

A large unmanaged project is unlikely to be
a successful project. Iterative improvement
invites disaster.

© Ian Davis


Architectural checklist

Is the overall organization clear, include a good overview
and justification?

Are the major goals clearly stated?

Are modules well defined, including their functionality and
interfaces to other modules?

Are all the requirements covered sensibly, using an
appropriate number of modules?

Will the architecture accommodate likely changes?

Are necessary decisions included?

Does the architecture describe how reuse code will be

© Ian Davis


Architectural checklist

All all major data structures described and justified?

Are data structures hidden behind access interfaces?

Is database organization and content specified?

Are key algorithms described and justified?

Are major objects described and justified?

Is strategy for handling user input described?

Is strategy for handling I/O described and justified?

Are key aspects of user interface defined?

Is the user interface modularized easing later change?

© Ian Davis


Architectural checklist

Are memory requirements estimated, and strategy for
memory management described?

Does the architecture impose space and speed budgets?

Is the strategy for handling strings described?

Is a coherent error handling strategy provided?

Are error messages managed cleanly?

Is a level of robustness specified?

Are parts of the architecture over or under architected?

Is the architecture independent of machine and language?

Are the motivations for all major decisions provided?

© Ian Davis


Architectural checklist


(From Code Complete