case study 3

16
CASE STUDY #3 MOBILE ROBOTICS Dr Reeja S R Professor CSE Dept. SJEC, Vamanjoor, Mang

Upload: dr-reeja-s-r

Post on 08-Jan-2017

125 views

Category:

Mobile


0 download

TRANSCRIPT

Page 1: Case study 3

CASE STUDY #3

MOBILE ROBOTICS

Dr Reeja S RProfessorCSE Dept.SJEC, Vamanjoor, Mangalore

Page 2: Case study 3

Mobile Robotics

A mobile robotics system is a system that controls a manned or partially manned vehicle such as car, submarine or a space shuttle.

Such systems are finding many new uses in areas such as • space exploration, • hazardous waste disposal • underwater exploration

Page 3: Case study 3

Typical software functions:1. Acquiring and interpreting input provided by

sensors.

2. Controlling the motion of wheels and other movable parts.

3. Planning future paths.

Page 4: Case study 3

Challenges

Obstacles may block path. Sensor input may be imperfect. Robot may run out of power. Mechanical limitations may restrict accuracy

of movement. Robot may manipulate hazardous materials. Unpredictable events may demand a rapid

(autonomous) response

Page 5: Case study 3

Desired features of the mobile robotics architecture

Supports deliberate and reactive behavior.

Page 6: Case study 3

Desired features of the mobile robotics architecture

Supports deliberate and reactive behavior. (ex: collect a rock sample) (ex: avoid an obstacle)

Allows uncertainty and unpredictability of environment. (such as contradictory sensor readings).

System must consider possible dangerous operations by Robot and in its environment (Ex: reduced power supply, dangerous vapors, unexpectedly opening doors of hazardous materials, etc)

The system must give the designer flexibility of experimentation and reconfiguration (mission’s change/requirement changes)

Page 7: Case study 3

Desired features of the mobile robotics architecture

Supports deliberate and reactive behavior. (ex: collect a rock sample) (ex: avoid an obstacle)

Allows uncertainty and unpredictability of environment. (such as contradictory sensor readings).

System must consider possible dangerous operations by Robot and in its environment (Ex: reduced power supply, dangerous vapors, unexpectedly opening doors of hazardous materials, etc)

The system must give the designer flexibility of experimentation and reconfiguration (mission’s change/requirement changes)

Page 8: Case study 3

Solution #1: CONTROL LOOP

The controller initiates robot actions and monitors their consequences, adjusting the future plans based on this

return information.

Page 9: Case study 3

REQ #1:Deliberate and reactive behavior

Control loop ensures deliberate and reactive behavior

REQ #2:Should operate with incomplete and unreliable info

Uses trial and error method

REQ #3:Account for danger

Continuous monitoring of actions ==> safety and fault tolerance

REQ #4:Design for flexibility (experimentation and reconfiguration)

The major components of are separated from each other and can be replaced independently

Page 10: Case study 3

Solution #2: Layers

Control routines – motors, joints, etc

Analyze readings from one sensorIntegrate analysis from various sensors

Maintains real world model for the robot

Manages robot navigation

Schedule and plan robot actions (including exception handling and re-planning)

User interface and overall supervisory functions

Page 11: Case study 3

REQ #1:Deliberate and reactive behavior

Tasks to be performed are assigned to separate layersReactive behavior is not achieved

REQ #2:Should operate with incomplete and unreliable info

What is uncertain at the lowest level may become clear with the added knowledge available in the higher layers

REQ #3:Account for danger Fault tolerance and passive safety

are achieved by abstraction mechanismActive safety may require communication pathways to be short-circuited

REQ #4:Design for flexibility (experimentation and reconfiguration)

Interlayer dependencies does not facilitate easy reconfiguration

Page 12: Case study 3

Solution #3: Implicit Invocation

Task Control Architecture

Page 13: Case study 3

Solution #3: Implicit Invocation

Implicit invocation using exception handler, wiretapping and monitors

Page 14: Case study 3

REQ #1:Deliberate and reactive behavior

Deliberate : Task trees Reactive: exceptions, wiretapping and monitors

REQ #2:Should operate with incomplete and unreliable info

TCA addresses uncertainty by creating tentative task trees when exceptional event occurs.

REQ #3:Account for danger Exception, wiretapping and

monitoring features address needs for performance, safety and fault tolerance

REQ #4:Design for flexibility (experimentation and reconfiguration)

For dynamic Reconfiguration, It is often sufficient to register new handlers, exceptions, wiretaps, or monitors with central server; no existing components are affected.

Page 15: Case study 3

Solution #4: Blackboard

•The “captain”, the overall supervisor.

•The “map navigator”, the high level path planner.

•The “lookout”, a module that monitors the environment for landmarks.

•The “pilot”, the low level path planner and motor controller.

•The perception subsystem, the modules that accept the raw input from multiple sensors and integrate it into a coherent interpretation.

Page 16: Case study 3

REQ #1:Deliberate and reactive behavior

components interact via the shared repository control flow must be coerced to fit the database mechanism

REQ #2:Should operate with incomplete and unreliable info

The blackboard acts as a means of resolving uncertainties.

REQ #3:Account for danger communication via a central

service, the database Exception handling, wiretapping, monitors can be used for certain signs of problematic situations

REQ #4:Design for flexibility (experimentation and reconfiguration)

Supports concurrencySeparates senders from receivers