case study 3
TRANSCRIPT
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