1. 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
Winter 2016
© 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
Winter 2016
© 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
Winter 2016
© Ian Davis

4. Mobile robot architectures
Closed loop control architecture
Layered architecture
Implicit invocation
Blackboard architecture
Incremental architecture
Winter 2016
© 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).
Winter 2016
© 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.
Winter 2016
© 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.
Winter 2016
© 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
Winter 2016
© 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.
Winter 2016
© 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.
Winter 2016
© 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
Winter 2016
© 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.
Winter 2016
© Ian Davis

13. Implicit invocation Task control architecture (TCA).
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.
Winter 2016
© 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.
Winter 2016
© 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.
Winter 2016
© 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
Winter 2016
© 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.
Winter 2016
© 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.
Winter 2016
© 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.
Winter 2016
© 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.
Winter 2016
© 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.
Winter 2016
© 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?
Winter 2016
© 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?
Winter 2016
© 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?
Winter 2016
© Ian Davis

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