Mobile robot requirements

superbshelfΚινητά – Ασύρματες Τεχνολογίες

12 Νοε 2013 (πριν από 4 χρόνια)

82 εμφανίσεις

© Ian Davis

1

Mobile robot requirements


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

2

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

3

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

4

Mobile robot architectures


Closed loop control architecture


Layered architecture


Implicit invocation


Blackboard architecture


Incremental architecture

© Ian Davis

5

Closed loop architecture


Simple interconnection between sensors and
actuators.


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

6

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

7

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

8

Layered architecture


User input and supervisory functions


Global planning


Control logic


Navigation


Real
-
world modelling via data structures


Collective sensor integration


Individual sensor interpretation


Robots hardware control

© Ian Davis

9

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

10

Layered architecture pros


Comfortable organization of development
responsibilities.


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
interpretation.

© Ian Davis

11

Layered evaluation cons


No clear division between data hierarchy
(real
-
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

12

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

13

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

14

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

15

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

16

Blackboard architecture


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


Operated on by:


Captain


Navigator


Lookout


Pilot


The perception subsystem

© Ian Davis

17

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

18

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

19

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

20

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

21

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

22

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 buy.v.build decisions included?


Does the architecture describe how reuse code will be
retrofitted?


© Ian Davis

23

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

24

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

25

Architectural checklist


IS THE GROUP OF PROGRAMMERS WHO WILL
IMPLEMENT THE SYSTEM, COMFORTABLE WITH
THE ARCHITECTURE?



(From Code Complete
-

McConnell)