An Architectural Approach to Robotics Software Design,

Implementation, and Deployment

Brian D’SouzaJoshua Garcia

Ivo KrkaNatachart Laotheppitak

Hossein Tajalli

Outline

• Motivation• Initial Stage• Suggested Architecture• Manager• Primary Connector• Component• Example• Admin• Conclusion

Motivation

• Provide a more disciplined approach to building embedded systems– Applying software architectural principles to robotics

systems

• Merging of heterogeneous types of applications in an embedded systems environment

• Abstract away lower-level software development details

Design using software architectural abstractions and implement using architectural middlewarePrism-MW

Motivation

• Desirable properties– Distribution– Mobility– Scalability– Maintainability– Evolvability– Concurrency

Initial Stage – Course Project

• 589 – Software Engineering for Embedded Systems taught by Prof. Nenad Medvidovic

• Video: http://video.google.com/videoplay?docid=-1355003473678326666&q=cs589&total=5&start=0&num=10&so=0&type=search&plindex=1

Next stage

• Class project showed that students with very limited robotics experience were able to create a new interesting application

• Current objectives– Creating a more general and adaptable

architecture– Variety of possible new applications

Deployment System

Suggested Architecture

PrimaryConnector

Admin Manager

Component 1

Component 2

Component n

Ph

ysical D

evice

Manager

• Parameters– List of Machine Interfaces (e.g. iRobot, Display, User Input

Device, Motion Sensor, Temperature Sensor, camera ,etc.)– List of Components

• Discovers other hosts around and communicate with them

• Host Rendezvous• Request Admin to download new components from other

hosts• Decides whether to connect one of its components to

peer components in other entities• Decides to start and stop components (Planning)

Primary Connector

• Communicating the events between components in the same physical entity or between different entities

• Routing, filtering, broadcasting the packages to desired sockets

• Connector types may vary

Component

• Components can use device drivers to communicate with the physical devices– E.g., for a sensor, a component can read the sensor

values– E.g., for a robot, one component can control the robot

to follow a line, turn a corner, etc.

• Cooperation with local and remote components– E.g., they can share positions of discovered obstacles

• Components carry information about their supported interfaces and services

Example

Wall Follower Connector

Admin ManagerC

onnectorAdmin Manager

Line Follower

User Interface

Connector

Admin Manager

Admin

• Supports dynamic adaptation and component mobility

• Ability to (re)deploy components onto a different host– Specify connector to attach component to– Dependent files– Requester or replier

Admin

Admin

Connector

Connector

Component

Admin

ConnectorAdminUI

ByteArray

Component

Connector

Manager

redeploy

redeploy

redeploy

Conclusion

• Non-functional qualities of robotics applications need to be better addressed

• Raising the level of abstraction of robotics systems development

• Encouraging initial results of application of our architectural approach

• Future work on realizing details of the approach and introducing new facilities