Software Stability: Analysis and Design Patterns for Mobile Robotics

1
Software StabilityAnalysis and Design Patterns
for Mobile Robotics
Part I

• Dr. Davide Brugali, Assistant Professor
• Department of Computer Science Business
  Management
• University of Bergamo, Italy
• http//robotics.unibg.it

2
The Current State of Software in Robotics

• Common practice
• proprietary design architectures invented from
  scratch each time
• monolithic systems that solve a specific class of
  problems
• Software Development Principles
• To promote the construction of new systems as
  composition of reusable building blocks
• System modularity and interoperability

3
Current Trends software components

• CoolBOT Specifying a component internal behavior
• ROCI Specifying a component external interface
• SmartSoft Enforcing components interoperability
• MARIE Supporting components integration
• ORCA Managing a component repository
• Player/Stage Device access and control
• MIRO Component middleware
• Microsoft Robotic Studio Runtime infrastructure,
  Authoring tools
• CLARAty middleware and application framework

4
System decomposition

• What is a component? ? David Garlan
• Unit of system composition/decomposition
• Unit of implementation
• Unit of computation
• Underlying assumption the properties of a
  robotic system may be confined to specific
  components
• Some concerns relate to the robotic software
  system as a whole hence crosscutting its
  functional structure.

5
Toward Stable Robotic Software Systems

• Which software abstraction can support the
  development of different components?
• Domain Engineering ? commonality/variability
  analysis
• Stability analysis ? identify stable concepts and
  entities
• Software stability can be defined as a software
  system's resilience to changes in the original
  requirements specification.
• Clien M. Girou M. (2000) Enduring Business
  Themes. CACM, Vol 43(5), May 2000
• Fayad M.E. (2002) Accomplishing Software
  Stability. CACM 45(1), 2002
• Brugali, D. Reggiani, M. (2005) Software
  Stability in the Robotics Domain Issues and
  Challenges. In Proceedings of the IEEE IRI, Las
  Vegas, Nevada, August 2005.

6
Software Stability Classify objects

• Enduring Business Themes (EBT) are abstractions
  of an application domain that are unlikely to
  change since they are part of the essence of the
  domain.

• Business objects (BO) are abstractions which
  offer specific functionality and have stable
  interfaces and relationships.

• Industrial objects (IO) are abstractions that
  may be replaced as times change.

7
Example Factory Automation

• Enduring Business Themes (EBT) are abstractions
  of an application domain that are unlikely to
  change since they are part of the essence of the
  domain.
• Automating processes, managing resources,
  producing value,

• Business objects (BO) are abstractions which
  offer specific functionality and have stable
  interfaces and relationships.
• Bill of Material, Job, Schedule, Lot, etc.

• Industrial objects (IO) are abstractions that
  may be replaced as times change.
• Field device, Lathe machine, Storage, etc.

8
Example Electronic Commerce

• Enduring Business Themes (EBT) are abstractions
  of an application domain that are unlikely to
  change since they are part of the essence of the
  domain.
• Selling, buying, negotiating,

• Business objects (BO) are abstractions which
  offer specific functionality and have stable
  interfaces and relationships.
• Buyer, Account, Receipt, ...

• Industrial objects (IO) are abstractions that
  may be replaced as times change.
• Credit Card, ATM, ...

9
Identification criteria for stable entities
10
Identification strategies

• Top-Down Identification
• Break off conceptual pieces of the problem.
• Recursively break these concepts down.
• Stop when a layer of industrial objects is
  reached.
• Bottom-Up Identification
• Start with a classical model.
• Group the industrial objects under a conceptual
  heading.
• Continue this grouping until further grouping is
  impractical or nonsensical.

11
Case Study

• A control and dispatching system for material
  transport
• Ore waste go to different destinations
• Need scheduling

M. Fayad, S. Wu, Merging Multiple Conventional
Models in One Stable Model, CACM Vol. 45, No. 9,
Sept. 2002
12
Traditional OO Model Works Well
13
Stable Model
14
First Change New Transport Technology
15
Stable Model
16
Second Change Different Material
17
Stable Model
18
Software Stability benefits

• In stable modeling
• Abstract classes designed to explain the core
  purpose of the system
• Modeling does not conclude to the solution of
  present problem
• System is adaptable and extensible
• Investing in analysis and design can well pay off
  in time of change, by reducing maintenance and
  upgrade efforts
• Stable Software Patterns for Self-Organizing
  Sensor Networks (NSF 04-522)

19
Software StabilityAnalysis and Design Patterns
for Mobile Robotics
Part II

• Dr. Davide Brugali, Assistant Professor
• Department of Computer Science Business
  Management
• University of Bergamo, Italy
• http//robotics.unibg.it

20
Simon's "ant on the beach"

• An ant's behavior control mechanism is very
  simple obstacle right, turn left obstacle left,
  turn right.

Intelligence.

• On a beach with rocks and pebbles, an ant's
  trajectory will be a zigzag line.

Situatedness.

• But if the size of an ant were to be increased by
  a factor of 1000, then its trajectory would be
  much straighter.

Embodiment.
21
Three EBTs for Robot Mobility

• Embodiment
• The consciousness of having a body that allows a
  robot to experience the world directly.
• Robots substantially differ from one other in
  their mechanical structure.
• Robot control applications strongly depend on the
  type of robot used to carry out a task
• Mobility is related to Embodiment, as it applies
  to both a robot and its constituent components,
  which move with respect to each other

22
Embodiment Analysis Patterns

• Class Embodiment.
• Global properties such as the mobility
  characteristics (walking, climbing, flying, )

23
Embodiment Analysis Patterns

• Class AnyRobot.
• The actor that expresses robot behaviors embodied
  in the mechanical structure.

24
Embodiment Analysis Patterns

• Class AnyBody.
• Characteristics of the electro-mechanical body of
  any robotic mechanism (power autonomy, )

25
Embodiment Analysis Patterns

• Class AnyMorphology.
• The shape of a robot's body and of its components
  and their structural relationships.

26
Embodiment Analysis Patterns

• Class AnyKinoDynamics.
• The constraints that limit the relative movement
  of mechanical components

27
Embodiment Analysis Patterns

• Class AnyDevice.
• The interface to the physical components

28
Embodiment Analysis Patterns

• Class AnyMorphology.
• The shape of a robot's body and of its components
  and their structural relationships.

29
Three EBTs for Robot Mobility

• Situatedness
• The property of existing in a complex, dynamic
  and unstructured environment, which strongly
  affects the robots behavior.
• The robot is aware of its own posture in one
  place at a given time
• Mobility is a form of robot-environment
  interaction

30
Situatedness Analysis Patterns

• Class Situatedness.
• Global properties related to situation
  awareness(multi-robot team, HRI, )

31
Situatedness Analysis Patterns

• Class AnyEnvironment.
• The surrounding physical conditions that affect a
  robot, while it is performing a task
  (illumination, dynamic, )

32
Situatedness Analysis Patterns

• Class AnyInteraction.
• The type of interaction that occurs between a
  robot and environment (physical, behavioral, )

33
Situatedness Analysis Patterns

• Class AnyPlace.
• Where an interaction takes place the portion of
  an environment affected by an interaction

34
Situatedness Analysis Patterns

• Class AnyTime.
• The time at which an interaction takes place
  discrete events, or continuous intervals

35
Three EBTs for Robot Mobility

• Intelligence
• The ability to express adequate and useful
  behaviors while interacting with a dynamic
  environment.
• Intelligence is perceived as "what humans do,
  pretty much all the time"
• Mobility is considered at the basis of every
  ordinary human behavior.

36
Intelligence Analysis Patterns

• Class Intelligence.
• Global properties such as the Level of Shared
  Autonomy, Task Criticality,

37
Intelligence Analysis Patterns

• Class AnyAction.
• This represents a generic action that a robot can
  execute (read sensors, activate motors, execute
  a procedure)

38
Intelligence Analysis Patterns

• Class AnyBehavior.
• It represents a generic schema of actions

39
Intelligence Analysis Patterns

• Class AnyControl.
• It represents generic control modality, such as
  reactive, deliberative, hybrid,

40
(No Transcript)
41
Software StabilityAnalysis and Design Patterns
for Mobile Robotics
Part III

• Dr. Davide Brugali, Assistant Professor
• Department of Computer Science Business
  Management
• University of Bergamo, Italy
• http//robotics.unibg.it

42
(No Transcript)
43
BO-Pattern AnyMorphology

• The Mechanism model should enable the description
  of the structural and behavioral properties of
  each mechanism part or subsystem, the
  relationships and constraints among the parts,
  and the topology of the system.
• From a software development perspective, the
  mechanism model should be described in terms of
  software abstractions that have the following
  software quality factors
• Expressiveness. The model enables the description
  of different mechanism types, such as open loop
  and closed loop chains.
• Stability. The model representation is resilient
  to changes in the application requirements
  specification.
• Scalability. The model allows the seamless
  composition of simple mechanisms into more
  complex mechanisms.
• Efficiency. The model supports the implementation
  of efficient query and update operations.

44
BO-Pattern AnyMorphology

• OROCOS www.orocos.org
• Object-Port-Connector Pattern
• CLARAty
• Unified Mechanism Model
• SRMS
• AnyMorphology Pattern

45
OROCOS Object-Port-Connector Pattern
46
OROCOS Object-Port-Connector Pattern

• Objects are the blocks to build Composite
  Objects rigid bodies, revolute joints, a linear
  spring,
• A Composite Object, such as a robot, can by
  itself again act as an elementary Object.
• Object can internally consist of the
  interconnection of other Objects.

47
OROCOS Object-Port-Connector Pattern

• Each Object has several Ports where it can
  engage in an interaction of one specific type
  with one or more other Objects.
• Ports are often symbolically represented by
  joint axis connectors, mathematically by
  reference frames on a rigid body, and by a
  pointer to a Connector objects.

48
OROCOS Object-Port-Connector Pattern

• The Connector encodes all the information of the
  constraints that the interconnection imposes on
  the connected Objects
• A set of algebraic constraints on the physical
  values that are accessible at the Port objects

49
OROCOS Object-Port-Connector Pattern

• Two rigid bodies connected by a spring.
• The dynamic behaviour of the joint is determined
  by the attributes of all three objects.
• The state of the dynamic interaction is stored in
  the Connector

50
OROCOS Object-Port-Connector Pattern

• The strength of the OPC pattern is the
  expressiveness of the proposed model. Ports and
  Connectors can represent different types of
  interactions (relative position, exchanged
  energy, etc.). An existing model can be extended
  by adding new types of ports and connectors.
• The pattern is well-suited for modelling
  classical robot mechanisms, but it seems
  inadequate to represent the dynamically changing
  structure of reconfigurable robots as the
  interactions among physical bodies are encoded in
  highly specialized Connectors. Thus, stability
  and scalability of the design are weaker aspects
  of the pattern.
• The evaluation of the model efficiency is
  somewhat difficult, as it is currently documented
  only in a technical report available at the
  OROCOS web site 22, which lacks of design and
  implementation details. For example, the document
  does not specify how complex mechanisms build on
  more elemental one.

51
CLARAty

• The Mechanism model represents the mechanism as a
  tree topology with rigid bodies connected to one
  another via joints.
• The model builds on four main software
  abstractions the ME_Body, the ME_Joint, the
  Mechanism Model, and the Mechanism Interface.

52
CLARAty
53
CLARAty

• One unique aspect of CLARAty is that it
  represents the relative transformations between
  two bodies as a property of one of the two.
• This means that a ME_Body encapsulates data
  structures (ME_Joint) that record information
  related not only to properties of an individual
  mechanical element, but also to properties
  related to its interconnection with other
  mechanical elements.
• This design solution might impact on the
  stability of the ME_Body design. If the nature of
  this interconnections changes (e.g. a graph
  instead of a tree topology), the description of
  ME_Body needs to change as well.

54
CLARAty

• The current value (the state) of the articulation
  between two rigid bodies (position, velocity, and
  acceleration information) is not stored in the
  ME_Joint, but it is passed into the mechanism
  model by the application that uses the model.
• Thus the model is stateless.
• This design solution represents the strength of
  the CLARAty mechanism model. It is highly
  efficient as it enables various system states to
  be updated at different rates and for different
  purposes (state recording from sensor inputs,
  state prediction for planning, etc.)

55
CLARAty

• The Claraty approach is highly scalable butt it
  trades expressiveness for the efficient
  implementation of data structures and algorithms.
  
• In a tree topology, closed-loop parallel
  structures have to be represented as open-loop
  chains with external constraints.
• The mechanism model infrastructure in CLARAty
  enables both the use of generalized forward and
  inverse kinematics as well as inverse dynamics
  and different collision detection algorithms.

56
AnyMorphology Pattern
57
AnyMorphology Pattern
p2
p1
58
AnyMorphology Pattern

• AnyElement differs from OROCOS Objects as it
  represents elemental components only and not
  composite mechanical systems, and from CLARAty
  Mechanism Bodies as it does not record
  information on how an element is connected to
  other elements to form complex systems.

59
AnyMorphology Pattern

• AnyPort differs from OROCOS Ports as it does not
  records symbolic attributes only but specifies
  the geometric relation with the elements
  reference frame. It also differs from the CLARAty
  ME_Joint as AnyPort stores kinematic information
  that characterizes a mechanical element, not the
  relationship between two elements.

60
AnyMorphology Pattern
e2.p1 e1.p2
61
AnyMorphology Pattern

• AnyPair differs from OROCOS Connectors as it
  links two elements only and it stores very
  limited information about the state of the
  interconnection. It also differs from CLARAty
  Joints as it represents the state of the
  articulated joint explicitly

62
AnyMorphology Pattern
63
AnyMorphology Pattern

• AnyMechanism differs from OROCOS Object and
  CLARAty Mechanism Model as it is a generic
  software abstraction, which is completely
  independent from the specific mechanism topology
  (tree, graph, etc.).

64
AnyMorphology Pattern

• AnyMechanism supports the hierarchical
  composition of mechanisms to build more complex
  mechanisms. For example, a mobile manipulator is
  the composition of a mobile rover and an
  articulated arm. In order to allow the definition
  of algorithms that uniformly iterate the
  mechanism hierarchical structure, we have applied
  the Composite Design Pattern.

65
AnyMorphology Pattern
66
AnyMorphology Pattern

• The resulting structure can be observed from two
  distinct perspectives.
• First, it represents a flat interconnection of
  AnyElement objects. This structure directly maps
  the physical chains of mechanical components,
  which link for example the end-effector of a
  manipulator arm to the wheels of the mobile rover
  carrying it. This representation is useful to
  analyze physical properties of complex
  mechanisms an algorithm can iterate through
  AnyPort and AnyPair objects in order to compute
  collision-free relative positions between
  AnyElement objects.

67
AnyMorphology Pattern

• Second, it represents a hierarchical composition
  of AnyBody objects. This structure directly maps
  the logical encapsulation of partial views on the
  complete graph, e.g. the Manipulator, the Rover,
  and the Robot.
• This representation is useful to allow a client
  control application to access mechanical
  information related to individual mechanisms,
  e.g. the path planner is concerned only in the
  rover kinematics.

68
AnyMorphology Pattern

• The AnyMorphology Pattern has the following pros
  and cons.
• Expressiveness. The proposed model supports the
  representation of different mechanism topologies,
  such as the chain of links that make up a serial
  manipulator, or the tree of devices that make up
  a mobile rover (transforming chassis, wheel
  bogies, suspension systems, etc.) or even the
  graph of serial kinematics chains (legs) that
  make up a parallel robot.
• An interesting consequence of representing the
  relative positions of AnyPort objects explicitly
  is the possibility to model elastic properties of
  mechanical elements seamlessly. For example, it
  is possible to attach a dynamic behaviour to
  AnyPort transformations in order to represent an
  element deformation due to external or internal
  forces (e.g thermal dilatation).

69
AnyMorphology Pattern

• Stability. The proposed model clearly separates
  the invariant properties of a mechanical element
  from the variable attributes that define how the
  element is interconnected with other elements to
  form composite mechanisms.
• OROCOS has a similar approach, but the
  AnyMorphology model keeps the representation of
  the element interconnections as simple as
  possible. This makes the model resilient to
  changes in the application requirements
  specifications, as it supports the representation
  of new mechanism topologies seamlessly, such as
  in the case of reconfigurable robots.

70
AnyMorphology Pattern

• Scalability. The model is highly scalable thanks
  to its modular structure. Every mechanism is
  modelled as a separate entity, whose properties
  are defined within an individual module.
• AnyMecahnism objects encapsulate the constituent
  elements, their interconnections, and the
  algorithms that manage them.
• Complex AnyMechanism objects are assembled from
  building-blocks mechanisms that completely hide
  their internal structure.

71
AnyMorphology Pattern

• Efficiency. The proposed model supports efficient
  traversal of complex mechanical structures thanks
  to the hierarchical organization of views on the
  flat elements graph.
• Even if the graph size is very large, search and
  update algorithms can exploit the mechanism
  composition hierarchy to retrieve information on
  every element.

72
AnyMorphology Pattern

• How to use the AnyMorphology mechanism model
• Typical functionality such as motion control,
  path planning, and navigation are implemented on
  top of the mechanism model by using its
  algorithms to retrieve and compute kinematics
  information.
• If the mechanical structure changes, the
  mechanism model and its algorithms need to be
  update, but the implementation of the robot
  functionality is not affected.

73
AnyMorphology Pattern

• Four alternative usage scenarios demonstrate the
  flexibility of the proposed model.
• In the first scenario, a copy of the mechanism
  model is instantiated for each software
  functional component. The model records the
  current configuration state of the robotic
  mechanism (i.e. the values of the AnyPair
  articulations), while the functional component is
  in charge of keeping it up-to-date (e.g. by
  reading the robot sensor).
• This scenario allows the component to optimize
  the update rate and to have exclusive access to
  the model state. Components might even maintain
  only a partial view of the mechanism state (e.g.
  only the rover state).
• The main disadvantage is the waste of memory to
  load several copies of the same mechanism model
  and the difficulty of synchronizing different
  components.

74
AnyMorphology Pattern

• In the second scenario, a single instance of the
  mechanism model acts as a central repository of
  the mechanism state for all functional modules.
• It is in charge of managing the synchronized
  access to the state by different components.
• The main disadvantage is the limited performance
  due to the concurrent access to the central
  repository.

75
AnyMorphology Pattern

• In the third scenario (the CLARAty approach), a
  central repository maintains only information
  related to the invariant properties of a robot
  mechanism, i.e. the values of AnyElement and
  AnyPort attributes.
• Every functional component that uses the model is
  in charge of providing a the mechanism state
  information, i.e. the values of AnyPair
  attributes. The current state is passed to the
  methods of the mechanism model every time an
  algorithm has to be executed.
• The main advantage is that multiple clients can
  share the same mechanism model efficiently. This
  is also powerful for reconfigurable robots where
  a single copy of the robot topologies is
  maintained.
• The main disadvantage is that every client (i.e.
  functional component) has to manage and provide
  mechanism state information. Different components
  may share the mechanism state if they agree on a
  common representation.

76
AnyMorphology Pattern

• In the fourth scenario, not yet supported by the
  current implementation, the central repository
  instantiates as many copy of the mechanism state
  as needed.
• The idea is to extend the design of the
  AnyMorphology Pattern according to the Iterator
  Design Pattern, which allows a way to traverse
  the elements of a composite object without
  exposing its internal structure.
• Every functional component holds an instance of
  an Iterator object, which stores the current
  state of the robotic mechanism. The component is
  in charge of updating the Iterator image of the
  mechanism state.
• Iterator objects are returned by the mechanism
  model on demand and can be easily cloned in order
  to share the same mechanism state with other
  functional components.

77
AnyMorphology Pattern

• Another intriguing aspect related to how to use
  the AnyMorphology Pattern is the relationship
  between the model of a mechanism and the external
  inertial reference frame.
• It is clear that the model records the state of a
  mechanism only in configuration space, i.e. the
  values of the AnyPair articulations.
• Once the transformation between the reference
  frame of at least one mechanism element and the
  inertial frame is known, the state of any
  mechanism element in Cartesian space can be
  derived from the mechanism state by computing the
  direct kinematics.

78
AnyMorphology Pattern

• The AnyMorphology Pattern offers two alternative
  solutions to represent the relationship with the
  inertial frame.
• The first solution requires the client functional
  components (e.g. the navigator) to record the
  global positions of any of the mechanism elements
  and to compute the positions of the other ones
  using the mechanism model internal configuration
  state and the kinematics algorithms.

79
AnyMorphology Pattern

• The second solution, which actually does not
  adhere to the overall stability-oriented approach
  of the AnyMorphology Pattern, consists in adding
  a virtual AnyPort objects to every AnyElement
  object to represent the transformation between
  its reference frame and the global inertial
  frame.