EmStar Features and Architecture

1
EmStar Features and Architecture

• Lewis Girod
• 17 October 2003

EmStar is joint work by a number of contributors
including Alberto Cerpa, Jeremy Elson, Lewis
Girod, Nithya Ramanthan, Thanos Stathoupolous,
and many others.
2
The EmStar Story

• Run-time environment for networked, wireless
  embedded systems
• Designed for
• Fault tolerance both within node and between
  nodes
• Robust, autonomous, remote operation
• Reactivity to dynamics in environment and task
• High visibility into system interactive access
  to all services
• Modular, but not strictly layered architecture
• NOT designed for network transparency (e.g.
  sockets)
• Wireless is too costly and flaky
• Connectivity to services on remote nodes is
  fundamentally different than to local services
  (reliability, latency, etc)

3
EmStar Transparently Trades-off Scale vs. Reality

• EmStar code runs transparently at many degrees of
  reality high visibility debugging before
  low-visibility deployment

4
EmStar Modularity

• Dependency DAG
• Each module (service)
• Manages a resource and resolves contention
• Well defined interface
• Well scoped task
• Encapsulate mechanism
• Expose control of policy
• Minimize work done by client library
• Application has same structure as services

5
EmStar Features
EmStar

• EmRun
• Logging
• Dependency graph
• Respawn, Shutdown
• FUSD IPC
• Transparency, interactivity
• Device Patterns
• Packet Device
• Status Device
• Sensor Device
• Command Device
• Directory Device

6
EmRun Manages Services

• Designed to start, stop, and monitor services
• Increases robustness, resilience, autonomy
• EmRun config file specifies service dependencies
• Starting and stopping the system
• Starts up services in correct order
• Respawns services that die
• Can detect and restart unresponsive services
• Notifies services before shutdown, enabling
  graceful shutdown and persistent state
• Error/Debug Logging
• Per-process logging to in-memory ring buffers
• Configurable log levels

7
FUSD IPC

• Inter-module IPC FUSD
• Creates device file interfaces
• Text/Binary on same file
• Standard interface
• Language independent
• No client library required
• Requires Linux devfs
• (Until kernel 2.6)

User
Kernel
8
Device Patterns

• FUSD can support virtually any semantics
• What happens when client calls read()? etc..
• But many interfaces fall into certain patterns
• Device Patterns
• Encapsulate specific semantics
• Take the form of a library
• Objects, with method calls and callback functions
• 1 priority ease of use
• Integrates with the GLib event loop

9
Status Device

• Designed to report current state
• No queuing clients not guaranteed to see every
  intermediate state
• Supports multiple clients
• Interactive and programmatic interface
• ASCII output via cat
• Binary output to programs
• Supports client notification
• Notification via select()
• Client configurable
• Client can write command string
• Server parses it to enable per-client behavior

10
Packet Device

• Designed for message streams
• Supports multiple clients
• Supports queuing
• Round-robin service of output queues
• Delivery of messages to all, or specific clients
• Client-configurable
• Input and output queue lengths
• Input filters
• Optional loopback of outputs to other clients
  (for snooping)

11
Sensor Device

• Driver submits timestamped blocks of sensor data
• Internal ring buffer
• Enables extraction of past data
• Integrates with TimeSync service for time series
  data
• Supports multiple clients
• Streaming or queried modes
• Notification when new samples arrive
• Supports configuration interface
• Driver can parse client config requests

Sensor Driver
Sensor Device
TimeSync Service
I
C
R
R
R
C
C
C
Client1
Client2
Client3
Currently under development
12
Device Files vs. Regular Files

• Regular files
• Require locking semantics to prevent race
  conditions between readers and writers
• Support status semantics but not queuing
• No support for notification, polling only
• Device files
• Leverage kernel for serialization no locking
  needed
• Arbitrary control of semantics
• Queuing, text/binary, per client configuration
• Immediate action, like an function call
• System call on device triggers immediate response
  from service, rather than setting a request and
  waiting for service to poll.

13
EmStar Service Lifecycle

• Interface design
• Encapsulate some useful mechanism
• Expose the application-specific policy decisions
• Choosing modularity
• Dont bite off too much at once
• Something that at first looks simple can grow
  more complex
• Dont worry about efficiency of more modules..
  Optimize later
• BUT.. avoid blue sky modularity designs..
  Instead, factor
• Factoring
• If a module is too complex, look for ways to
  break it down
• New problems sometimes suggest new patterns
• Factor new pattern libraries out of existing code

14
Example from NIMS A motor controller

• Assume
• Motor has serial connection to CPU
• Accepts commands N steps left or N steps
  right
• Reports value of an absolute position sensor
• Goals
• Enable different apps to share access to motor
• Enable apps to coordinate positioning of the
  robot
• Simplify coordination between apps
• Key point minimize interdependence among apps

15
Motor ControllerDesign Questions

• What resources are we managing?
• Access to motor control channel
• Position of robot
• Schedule of robot positions
• What kind of interface should we make?
• Raw left/right interface?
• Move to position X interface?
• Scheduler / Path Planning interface?

16
All of the above?

• Maybe we want it all!

Position Scheduling
Some motors implement servo internally. Their
driver might provide the servo interface directly.
Position Servo

• Layered or modular approach
• Dont bite off too much at once
• Always try to keep the work concrete and grounded
• Do this by factoring
• (In this talk I am doing a blue sky design, but
  this is only for illustrative purposes. Its
  always best when designs are motivated directly
  from experiences.)

Motor Steps/Position
17
Raw Controller Layer

• Interface pattern Status device
• Reports real-time position updates
• ASCII output for interactivity
• Binary structure for programmatic use
• Accepts commands to step motor
• ASCII format, e.g. steps-4 or steps25
• Reports EBUSY if motor is processing a command
• Reports other errors if the command is improper

struct motor_pos float s / meters /
float v / meters/sec / int busy1
cat /dev/actuator/motor_x/steps Motor BUSY,
position (m), velocity(m/s) 12.23 0.08
echo step23 gt /dev/actuator/motor_x/steps
18
Servo Layer

• Interface pattern Status device
• Reports real-time position updates
• ASCII output for interactivity
• Binary structure for programmatic use
• Accepts commands to position motor
• ASCII format specifies position in meters, e.g.
  pos2.57
• Reports EBUSY if motor is servoing on behalf of
  another client
• Reports other errors if the command is improper

struct motor_pos float s / meters /
float v / meters/sec / int busy1
cat /dev/actuator/motor_x/pos Motor BUSY,
position (m), velocity(m/s) 12.23 0.08
echo pos2.57 gt /dev/actuator/motor_x/pos
19
Scheduling / Path Planning Layer

• Goal
• Enable independent applications to schedule a
  stop at a particular place for a specified time
• Encapsulate path planning
• Control several motors to do X,Y,Z?
• path_plan is a client of one or more more basic
  motor controllers
• What motor interface is needed?
• What info does scheduling exchange with
  path_plan?
• This is why avoid blue sky design
• But the right breakdown can usually be discovered
  through a prototype implementation

scheduling
path_plan
depth map
motor_x
motor_y
camera
20
Scheduling Layer

• Clients submit requests to scheduler
• Location
• Desired time range
• Desired stop duration
• Request is accepted or denied
• If accepted, app notified when robot arrives at
  stop, so it can do its work
• If denied, app must pick a different time and
  place
• Current schedule is exposed to clients to help
  with this process
• Requests are resolved into a consistent schedule
• Does it need info from path planner?
• Is priority needed?

21
Conclusion

• EmStar has a lot of useful stuff
• Trying to create a run-time environment
• We can call build on and contribute to
• Build a community
• Emphasis on code re-use through
• Good interface design
• Factoring techniques
• (factoring guarantees at least one use!)

22
Future Work

• Work In Progress
• Device Interfaces, modules
• Sensor device interface
• Subject Server integration
• Documentation
• Sample code and skeletons
• Future work
• Sensor simulation, playback facilities
• World modeling, sensor modeling (integrate to
  stage?)
• Supporting libraries for persistent storage
• Embedded web server for configuration

23
The End!Thank you..