The document discusses various architectures for mobile robotics systems. It describes four solutions: 1) A control loop that initiates actions and monitors consequences to adjust plans. 2) A layered architecture with control routines, sensor analysis, world modeling, navigation, and planning layers. 3) An implicit invocation task control architecture using exceptions, wiretapping, and monitors. 4) A blackboard architecture with components interacting via a shared repository to resolve uncertainties.

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

2. 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

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.

4. 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

5. Desired features of the mobile
robotics architecture
 Supports deliberate and reactive behavior.

6. 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)

7. 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)

8. Solution #1: CONTROL LOOP
The controller initiates robot actions and monitors their consequences,
adjusting the future plans based on this return information.

9. 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

10. Solution #2: Layers
Control routines – motors, joints, etc
Analyze readings from one sensor
Integrate 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

11. REQ #1:
Deliberate and reactive behavior Tasks to be performed are assigned to
separate layers
Reactive 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 mechanism
Active safety may require communication
pathways to be short-circuited
REQ #4:
Design for flexibility
(experimentation and
reconfiguration)
Interlayer dependencies does not facilitate
easy reconfiguration

12. Solution #3: Implicit Invocation
Task Control Architecture

13. Solution #3: Implicit Invocation
Implicit invocation using exception handler,
wiretapping and monitors

14. 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.

15. 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.

16. 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 concurrency
Separates senders from receivers