CASE STUDY #3

MOBILE ROBOTICS

Dr Reeja S RProfessorCSE Dept.SJEC, Vamanjoor, Mangalore

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

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.

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

Desired features of the mobile robotics architecture

Supports deliberate and reactive behavior.

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)

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)

Solution #1: CONTROL LOOP

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

return information.

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

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

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

Solution #3: Implicit Invocation

Task Control Architecture

Solution #3: Implicit Invocation

Implicit invocation using exception handler, wiretapping and monitors

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.

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.

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