We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byCarli Milhouse
Modified over 2 years ago
© Ian Davis1 Mobile robot requirements Requirements –(1) Must behave in a deliberate manner –(2) Must react appropriately to its environment –(3) Must anticipate uncertain information –(4) Must be both robust and fault tolerant –(5) Architecture must be incrementally flexible
© Ian Davis2 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 Davis3 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 Davis4 Mobile robot architectures Closed loop control architecture Layered architecture Implicit invocation Blackboard architecture Incremental architecture
© Ian Davis5 Closed loop architecture Simple interconnection between sensors and actuators. Appropriate for rigid requirements. Eg. follow black line. Doesnt scale well. Inflexible, hard to change or refine. Conflicts between multiple feedback loops. (eg. getting dark, near water, low battery).
© Ian Davis6 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 Davis7 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 Davis8 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 Davis9 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 Davis10 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 Davis11 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 Davis12 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 Davis13 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 Davis14 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 Davis15 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 Davis16 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 Davis17 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 Davis18 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 Davis19 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 Davis20 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 Davis21 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 Davis22 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 Davis23 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 Davis24 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 Davis25 Architectural checklist IS THE GROUP OF PROGRAMMERS WHO WILL IMPLEMENT THE SYSTEM, COMFORTABLE WITH THE ARCHITECTURE? (From Code Complete - McConnell)
What is it? A mobile robotics system controls a manned or partially manned vehicle-car, submarine, space vehicle | Website for Students.
University of Windsor School of Computer Science Topics in Artificial Intelligence Fall 2008 Sept 11, 2008.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Lecturer: Dr. AJ Bieszczad Chapter 55-1 Designing the system Conceptual design and technical design Design styles, techniques and tools Characteristics.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Chapter 6 CASE Tools 1Chapter 6-- CASE TOOLS. Overview CASE Tools Flowcharts Decision tables Project management tools Prototyping Types & examples of.
Architectural Design portions ©Ian Sommerville 1995 Establishing the overall structure of a software system.
1 Chapter 2 SW Process Models. 2 Objectives Understand various process models Understand the pros and cons of each model Evaluate the applicability.
1 Prescriptive Process Models. 2 Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering Prescriptive process.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
1 Design Creative Process of transferring the problem into a solution the process is two way and iterative: –Conceptual/System Design –Technical Design.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Software Engineering General architecture. Architectural components: Program organisation overview Major building blocks in a system Definition of each.
CSE 303 – Software Design and Architecture LECTURE 03.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
1 Objectives To introduces the concept of software Design. To introduce the concept of Object- Oriented Design (OOD). To Define various aspects about object.
Software Architecture Design Instructor: Dr. Jerry Gao.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
An Introduction to Software Engineering. What is a software process? A set of activities whose goal is the development or evolution of software. Generic.
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 13Slide 1 Architectural Design u Establishing the overall structure of a software system.
Global Analysis and Distributed Systems Software Architecture Lecture # 5-6.
Course Instructor: Aisha Azeem Architectural Design.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
1 Software Design Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13, 5 th edition and Ch. 10, 6 th edition.
Chapter 1 Principles of Programming and Software Engineering.
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
IMA 2.5: Software Architecture and Development Environment Roberto Olivares M.S. Electrical Engineering Vanderbilt University, Spring 2003.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Computer Science CS425/CS6258/23/20011 Architectural Design Establishing the overall structure of a software system.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
Software Engineering and Object-Oriented Design Topics: Solutions Modules Key Programming Issues Development Methods Object-Oriented Principles.
Distributed Robot Agent Brent Dingle Marco A. Morales.
CS 360 Lecture 3. The software process is a structured set of activities required to develop a software system. Fundamental Assumption: Good software.
©Ian Sommerville, Robin Abraham 2004CS 361, Summer 2004 Slide 1 Architectural Design.
Advanced Computer Networks Topic 2: Characterization of Distributed Systems.
Chapter 7: Architecture Design Omar Meqdadi SE 273 Lecture 7 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
© 2017 SlidePlayer.com Inc. All rights reserved.