2 types of mobile robots

1. © 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

2. © 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

3. © 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

4. © Ian Davis 4
Mobile robot architectures
• Closed loop control architecture
• Layered architecture
• Implicit invocation
• Blackboard architecture
• Incremental architecture

5. © 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).

6. © 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.

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

8. © 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

9. © 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.

10. © 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.

11. © 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

12. © 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.

13. © 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.

14. © 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.

15. © 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.

16. © 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

17. © 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.

18. © 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.

19. © 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.

20. © 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.

21. © 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.

22. © 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?

23. © 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?

24. © 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?

25. © Ian Davis 25
Architectural checklist
• IS THE GROUP OF PROGRAMMERS WHO WILL
IMPLEMENT THE SYSTEM, COMFORTABLE WITH
THE ARCHITECTURE?
• (From Code Complete - McConnell)