Mobile robot requirements

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) © Ian Davis