Point 1 is true up to a point (you need to either have a deterministic
model for the workload, traditionally periodic, and limited inter-stream
synchronization requirements, OR wildly excessive capacity). It also
depends on the latency requirements of a haptic UI and how far away you
need to operate (clearly, this is a place where speed of light through
fiber delays and router processing overhead could really matter).
Point 2 is clearly true.
Point 3 is going to depend again on what you're demanding of the switch.
Normal traffic plus one haptic channel? Multiple haptic channels?
Haptic channels with different response time granularities? Priorities
have extremely low semantic content, but if you know the workload you
can map most scheduling disciplines onto fixed priority (all static
work-conserving policies).
Point 4 is true, but its important to discriminate between the
scheduling mechanism and the interface provided to users. Its clearly
true that its insane to give user a numeric priority range and expect
anything intelligent to happen (everyone will pick priority 1 I expect
;-). But that doesn't mean that using priorities in the hardware is
necessarily the wrong thing.
Finally, I think the main thing you're getting at in point 5 is that
there is a potentially very useful interaction between network layer
feedback/adaptation and real-time data transfer. However, I'm unsure if
the time scale on which network layer feedback will work is compatible
with the demands of a haptic interface. What kind of response time to
haptic UI's really need? If its in the neighborhood of 50-100ms, then
there might be some value here, but if its more like 5ms, then I'd guess
that it'll be tough to adapt quickly enough.
I think to better provide input, the rest of us need to understand the
application demands a bit better. How far away is the control? How
much data is being sent (just haptic channel? haptic plus video? data
stream?) What are the response time demands of the various channels?
What kind of channel synchronization is necessary? How "soft" is the
real-time demand (operating on patient, can't miss any deadlines OR
investigating molecular structure of atoms with force electron
microscope probe, can afford to miss deadlines occasionally). What kind
of network technology is being employed (wireless for battlefield remote
control? satellite for remote fault diagnosis on oil drilling rigs?
dedicated fiber for outsourcing specialty heart surgery). Finally, what
kind of network topology are we talking about? What considerations make
this not a straight point-to-point link (ie why is the network being
shared).
- Stefan
-----Original Message-----
From: tom@emigrant [mailto:tom@emigrant]
Sent: Wednesday, December 02, 1998 1:59 AM
To: blake2@rcs.ee; djw@lcs.mit.edu; savage@cs
Cc: syn@cs
Subject: internetworking and haptic UI's
Stefan and David -- Blake is writing a proposal to DARPA
to fund a vertically integrated demonstration of haptic
(force feedback) interfaces, for the software
control BAA (08). There are technical issues with respect
to software control, but the part he'd like help with is
the real time interactive UI over the net.
Here's my take on the research issues, please add your views.
I'm no expert in QoS, but one of our target apps for Detour
is latency-sensitive games, and that's up Blake's alley.
1. with dedicated links and programmable routers, easy to
provide strict real time guarantees (in a previous life I published
some work a while back that you can do guarantees given static
schedules and loosely synchronized clocks at the routers).
2. internet today is hit and miss. If you're running over a wildly
underutilized link such as Internet2, easy. If you're running on
one of our prototypical lossy Internet links, no chance -- there's
too big a tail to latencies and drops.
3. it's not clear to me that the current approach that the Internet
router vendors will work. Is it enough in general to have priorities
for switch scheduling and buffer allocation? The ATM experience said
no.
But I don't know if this has been proven one way or the other.
It would be great to be able to claim that the industry approach won't
work.
4. One problem with priorities is that it confounds two issues --
how important something is with what kind of service it needs.
In general, I suspect it's like the old results about CPU scheduling --
you improve average performance by doing short jobs first. The short
jobs are simple web surfing; the long jobs are the real time ones.
There's been some interesting work in various places that look at
deferring real time work, to allow best effort to go first as long
as it doesn't interfere with meeting deadlines.
5. on a virtual network (layered on top of the physical Internet)
things become interesting
-- we can monitor performance of individual routes, and change
FEC to compensate for drop rates and delay variations.
this is equivalent to the issue where you have a wireless
device switch zones (e.g., by entering a building), thereby
getting better or worse performance
-- we can change the virtual route to avoid dynamic problem areas
(presumably reducing the tail, provided the variability in the
network occurs more slowly than the control loop -- eg., 1 RTT)
-- we can adapt at the application level. If the network reports
that the performance it can provide has changed, then the app
can potentially compensate by making the control stiffer (I'm
making this up, but it sounds plausible).
-- we can reduce loss rates and queuing variations by shaping
and/or rerouting other traffic (e.g., traffic produced by a Detour
congestion gateway will cause less variation in performance for
other traffic because its impact will be smoother)
tom
------
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Tue, 01 Dec 1998 10:05:27 -0800
To: wmcneely@espresso.rt.cs.boeing.com, pbuttolo@ford.com,
steve@isdl.ee.washington.edu, rjadams@u.washington.edu,
tom@cs.washington.edu, moreyra@cris.com
From: Blake Hannaford <blake2@rcs.ee.washington.edu>
Subject: DARPA Pre-Pro Draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status: RO
Please give me any comments you have on this next-to-final
draft by end of day Wed.
Thanks!
Blake
High Performance Networked-Control for Shared Haptic Interaction
and Telerobot Control
White Paper for DARPA BAA #99-08
University of Washington
Boeing Company
Ford Motor Company
Air Force Institute of Technology
Prof. Blake Hannaford
Department of Electrical Engineering
University of Washington
Seattle, WA 98195-2500
http://rcs.ee.washington.edu/BRL
1-206-543-2197(voice)
1-206-543-3842(fax)
1. Objective
This project proposes to create an internet-based distributed control
system for haptic interaction and telerobotic control. Haptic
interaction allows users to touch and physically interact with computer
models or remote objects. The proposed system will seamlessly interface
a variety of commercial and research haptic devices, telerobots, and
advanced CAD-based real-time simulations, into a distributed network
based on existing and newly created public standard prototcols.
2. Team
University of Washington.
Prof. Blake Hannaford, (PI)
Prof. Tom Anderson (Co-I)
Air Force Institute of Technology
Prof. Richard Adams (Co-I)
(position begins Sept 99)
Boeing Information Support Services
Dr. William McNeely
Dr. James Troy
Dr. Steven Venema (full time at Boeing 2/1/99)
Ford Corporate Research Labs
Dr. Pietro Buttolo
Dr. Paul Stewart
Haptic Technologies Inc (Seattle)
Manuel Moreyra, President
This team has worked together for the past several years on various
small projects funded primarily by the industry group. Together, we are
seeking a combination of resources necessary to create a shared vision
of better design and remote control capabilities through advanced
software enabled networked control systems.
The proposed vision cannot be realized without significant advances in
the state of the art of control, distributed software, networking, and
human-computer-interaction. We believe that the time is ripe for
a breakthrough in these areas through leveraging of commodity computing
power and open software protocols. We propose to coordinate our efforts
by focusing on the realization of a proptotype advanced networked CAD
system.
3. Technical Innovations
Our project would aim to create the following technical
innovations:
Open protocols for interconnection of haptic devices, real-time
dynamic simulations, and robots.
[Networking Innovations ... ANDERSON]
Stable and high performance distributed controllers for bi-directional
interaction between humans, dynamic virtual worlds, and telerobots
mediated by advanced haptic devices.
Advanced manipulator control laws which leverage minimal cost computing
power to intelligently and robustly control slave robots and haptic
devices in the region of kinematic singularities.
4. Testbed Implementation
The team would implement a testbed system over the internet supporting
seamless interaction between the following elements:
Advanced human operator control station (UW)
Telerobot Cell (UW)
Advanced Networking testbed (UW)
Realtime Airframe CAD model (Boeing)
Realtime Car interior CAD model (Ford)
CAVE Virtual Environment and Robot testbed (AFIT)
The advanced networking testbed would allow us to test new network
routing strategies which we cannot yet implement in the real
internet.
5. Technical Rationale
Haptic interaction is a key centerpiece of emerging human-centered
computing and control. Human reaction time to haptic stimuli (about
150ms) is about half of that of visual stimuli (about 300ms). Haptic
interaction provides better and more intutive human control of both
virtual worlds, and remote physical worlds (via telerobots). Intense
industrial interest is emerging in haptic technolgies for evalution of
designs and CAD models. The benefits of haptic human-computer-
interaction are expected to be even grater in distributed networked
interactions in which, for example, designers around the world
collaborated on a haptically and visually rendered CAD model. However
key technical barriers remain. Chief among these is stable and high
performance haptic control in a network characterized by stochasitcally
varying time delay.
The proposed project will develop low level software, network protocols,
and device control laws to break down this barrier and enable these new
applications. We will create a working prototype network in which a user
at each of the team locations will be able to physically interact with
models at all of the locations. Two of the locations (UW and AFIT) will
also have telerobots to which any user can connect.
All the sites will have advanced 6 degree of freedom haptic display
devices. Specific results expected from the project are:
5.1 New Control Capability: Stable, high performance bi-lateral control
over local and wide-area networks with large scale detailed CAD models.
5.2 Open Control Environment: Testbed implementation will be
demonstrated over internet. Socket level connection protocol will be
defined and made public.
5.3 Evaluation and Experimentation Strategies:
5.3.1 Collect Internet packet latency stats.
5.3.2 Test interaction between operator stations at all
locations with all "servers" (i.e. robots and models). Rate all
interactions in terms of stability and perceptual quality.
5.3.3 Formally evaluate
o stability/gain trade-offs.
o Human operator surface feature descrimination ability.
o Completion time of an assembly and maintenance task.
------------------------------------------------------------------------
Prof. Blake Hannaford, Dept. of Electrical Engineering
University of Washington, Seattle, Wa USA 98195-2500.
Ph: 1-206-543-2197 Fax: 1-206-543-3842
Faculty Openings: http://www.ee.washington.edu/jobs/chronfac.html
------------------------------------------------------------------------