Title: Integrated%20Play-Back,%20Sensing,%20and%20Networked%20Control
1Integrated Play-Back, Sensing, andNetworked
Control
- Vincenzo Liberatore
- Division of Computer Science
Research supported in part by NSF CCR-0329910,
Department of Commerce TOP 39-60-04003, NASA
NNC04AA12A, and an OhioICE training grant.
2Networked Control
- Computing in the physical world
- Components
- Sensors, actuators
- Controllers
- Networks
3Networked Control
- Enables
- Industrial automation BL04
- Distributed instrumentation ACRKNL03
- Unmanned vehicles LNB03
- Home robotics NNL02
- Distributed virtual environments LCCK05
- Power distribution P05
- Building structure control SLT05
- Merge cyber- and physical- worlds
- Networked control and tele-epistemology G01
- Sensor networks
- Not necessarily wireless or energy constrained
- One component of sense-actuator networks
4Information Flow
- Flow
- Sensor data
- Remote controller
- Control packets
- Timely delivery
- Stability
- Safety
- Performance
5Autonomy
- SR and real-time
- Autonomy
- Hide networked RT
- Hard to build a fully reliable system
- Tele-operation
- Network non-determinism is serious problem
- SR
- Reduce time constants
- Especially important for unexpected occurrences
NLN02
6Networked Evaluation EESR 2005
7Metrics
- Disturbance cancellation
- Objective
- The SR system should do what it is supposed to
do - In spite of network non-determinism and
uncertainty in the environment - Way out
- Use simple tasks
- Scalability L04
- Number of nodes
- Space networks?
- Geographic
- Administrative
- Functional
- Conclusion
- RT SR benchmarks needed!
- Stability (and safety)
- Objective
- Remote controller makes unstable system stable
- Extensive research
- Z01 and references therein
- Problem
- Errors, network partitions, failures make
stability impossible - Tracking
- Objective
- The SR system should do what it is supposed to
- In spite of network non-determinism (failures,
security, etc.) - Problem
- Benchmarks (NIST?)
8Methodology (I) Co-Simulation
BLP03, HLB05
9A Modest Proposal
- Application benchmark
- National Lambda Rail
- NLR is planned to be capable of supporting both
production and experimental networks. - Not a single network or a single test bed but
facilities to build multiple networks and
multiple test beds at all of layers 1-3 including
optical, switched, and routed. - Goal is to have both persistent and flexible
infrastructure(s) - Foster network research
- Support QoS
- Real-Time Overlay
- Support end-to-end RT SR
10Playback Buffers Infocom 2006
11Playback Buffers
- Play-back buffers
- Main objective
- Smooths out network non-determinism
- Multimedia buffers
- Important source of inspiration
- Physics versus multimedia quality
- Playback delay computed in advance
- Affects control signal computation
- Round-Trip Times
- TCP RTO
- Another source of inspiration
- Large time-out cost
12Algorithm
13Main Ideas
- Predictable application time
- If control applied early, plant is not in the
state for which the control was meant - If control applied for too long, plant no longer
in desired state - Keep plant simple
- Low space requirements
- Integrate Playback, Sampling, and Control
14Algorithm
- Send regular control
- Playback time
- Late playback okay
- Expiration
- Piggyback contingency control
15Deadwood packets
- Old
- Received after the expiration time
- Out-of-order
- Later control more appropriate for current plant
state - Would get us into a deadlock
- New packet resets the playback timer
- Keep resetting until no signal applied
- Quashed packet
- Discard!
controller
plant
Playback delay
16Countermand control
- Scenario
- Packet i1 overtakes packet I
- ti1 ltlt ti
- Likely caused by delay spike
- New signal countermands previous one
controller
plant
ti
Playback delay
ti1
17Playback delays
- Modular component
- Compute playback delay t and sampling period T
- Use short term peak-hopper EL04
- Original peak-hopper for TCP RTO
- Too conservative for networked control
- Aggressively attempt to decrease t
- Aggressively attempt to decrease T
- Add upper bound on playback delay t
- Avoid dropping deadlock packets
- Bound t TRTT
- Caps t and T
- Must estimate lower-bound on RTT
- Use symmetric of peak-hopper
- Add negative variability estimate to compensate
for short-term memory
18Playback Delays (I)
Calculate current RTT variability
Positive variability coefficient
Negative variability coefficient
if
then
Update min RTT estimate
Age min RTT estimate
Calculate ?
19Playback Delays (II)
if
then
Attempt to avoid quashed packets
else
Increase sampling period
20Control Pipes
- Bandwidth and delays
- t is playback delay
- T is sampling period
- 1/T proportional to bandwidth
- Control pipe
- Tt
- Multiple in-flight packets
- Pipe depth
- Bound by constraint t TRTT
- Keep pipe predictable
21Observer
- Estimate future plant state
- Plant sample current state, including local
variables - Keep log of outstanding control packets
- Assumption on packet delivery
- Future packet delivery is uncertain
- Purge from log
- Old packets
- Packet that should be overtaken by new control
- Countermands signals generated when delay spike
is transient - Out-of-order packets
22Evaluation
23Network Model
- Simulated network
- Losses Gilbert model
- Delays
- Shifted Gamma distribution
- Heavy tail
- Low probability of out-of-order delivery
- Correlate delays to introduce delay spikes
- Wide-area implementation
- Use RT scheduling whenever possible
- Use otherwise unloaded machines
- RT made little difference
- Host worldwide, heterogeneous conditions
24Plant
- Scalar linear plant
- Plant state x(t)
- Input u(t) (control)
- Output y(t)
- Disturbances v(t), w(t)
- Akin to white noise
- Deadbeat controller
- Aggressive
25Metrics
- Metrics
- Root-mean square output
- Output 99-percentile
- Comparison
- Open-loop plant u(t)0
- Proportional controller (no buffer)
- Proportional controller with constant delays
26Plant output
Open Loop
Play-back
27Packet losses
Figure 8
28Sampling period
Imperfection of the control pipe
Root-mean-square error
29Agent-Oriented SR Software WORDS 2003
30Agent-oriented SR software
- Progress
- Agent-oriented platform
- Compliant control
- Future work
- Application-oriented middleware
- E.g., Scheduling of mobility
- AI (knowledge, planning, learning)
- Security
31Approach Outline
- Local robot control virtual attractors
- Interface for higher-level distributed sw
components - Reason about robot behavior
- Encapsulate intelligence needed to
- Cope with
- Long delays
- Imprecise modeling and unstructured environments
- Establish predictable robot behavior and safety
- Distributed control
- Agent-based
32Compliant Control
33What happens if flawed instructions are issued?
34Agent types
35Hierarchical organization
Chain of command
36Virtual Containment
- Analogy
- A robotic platoon contains individual robot
- Not necessarily in terms of ontology
- Application
- Task-oriented teams
- Layering
37Experience
38Acknowledgments
- Students
- Ahmad al-Hammouri
- David Rosas
- Zakaria Al-Qudah
- Huthaifa Al-Omari
- Nathan Wedge
- Qingbo Cai
- Prayas Arora
- Colleagues
- Michael S. Branicky
39Conclusions (I)
- Sense-and-Respond
- Merge cyber-world and physical world
- Critically depends on physical time
- Playback buffers integrated with
- Sampling (adaptive T)
- Control (expiration times, performance metrics)
- Packet losses
- Reverts to open loop plant (contingency control)
40Conclusions (II)
- Playback delay t
- Adapts to network conditions
- Sampling period T
- Avoids imperfection of control pipe
- Simulations and emulations
- Low variability around set point
- Robust
41Conclusions (III)
- Remote supervision of robotic manipulation
- Compliant control
- Local encapsulation
- Gentle, compliant, tolerant to network vagaries
- Agent-based software
- Hierarchical
- Demonstration
- Future work middleware, AI, security
http//home.case.edu/vxl11/NetBots/