szabo@sequent.com (Nick Szabo) (02/28/91)
In article <1991Feb26.192615.19617@zoo.toronto.edu> kcarroll@zoo.toronto.edu (Kieran A. Carroll) writes: [a very informative article on teleoperation, with which I only have a few nits to pick :-] >For the type of teleoperation that was planned for FTS (force-reflecting >master-slave set-up), it has been shown that closed-loop time-delay of greater >than about 10 milliseconds cannot be tolerated. Research done several years >ago at JPL, in support of FTS design, showed that the closed-loop system >starts to go unstable for larger time delays. * FTS was funded as part of Fred, was it not? Would a study funded with the _goal_ of operating FTS from a space station tell us what, in fact, is the most _economical_ way to perform FTS's tasks? * "tolerated" is a rather fuzzy word. Exactly what loss of functionality is generated by going over 10 milliseconds? * Is the "force-reflecting master-slave setup" in fact the most economical technology for performing FTS's tasks? >I imagine that this could be >ameliorated by increasing the time-constant of the joint controllers >of the robot, but this would make the manipulators more "sluggish", >which causes operator fatigue to increase significantly. Does operator fatigue cost even a significant fraction of the space station astronaut time required for on-site teleoperation? Training several operators for working short shifts on Earth would seem more economical by several orders of magnitude: labor cost on Earth: $30/hour (the best video-game players on the planet :-) WAG for labor cost on Fred: $30e9/(4*8*5*50*20) = $187,500/hour Even assuming 2 earth shifts for every space shift due to fatigue, we get costs on Fred over 3,000 times greater than costs of teleoperating from Earth. >...[Shuttle arm] The feedback loop is closed not by force-reflection, >but by the operator observing the motion of the end-effector (or payload), >either directly or via TV cameras. > >This method has the advantage of allowing much longer closed-loop delay times >without instability. While FTS could not be operated from the ground >(where the closed-loop delay could approach 250 milliseconds), a properly- >designed commanded-rate controller with TV-camera feedback could >do the job (as long as a reliable communications link existed). What tasks require FTS to have force-feedback? Can these tasks be dropped and still have a signficant subset of FTS tasks economically accomplished from Earth via video feedback? >Work >in Canada is proceeding to generalize this concept in ways that would >allow it to be used to perform Earth-based teleoperation of devices on the >Moon; one step in accomplishing this is to build some autonomy into the >lower-level control loops, with periodic (time-delayed) "supervision" >coming from the Earth. 3 seconds is quite long in teleoperation terms. Even more "semi- teleoperation", what I call "long-RTLT teleoperation", is being designed for the Mars rover. It relies on much more autonomy than a 3 second or millisecond teleperated device, but there are still ways to generate feedback (including mapping of future terrain and ground "pre-teleoperation" to perfect moves that are then uploaded to the rover). -- Nick Szabo szabo@sequent.com "What are the _facts_, and to how many decimal places?" -- RAH
brucec%phoebus.labs.tek.com@RELAY.CS.NET (Bruce Cohen;;50-662;LP=A;) (03/05/91)
In article <17372@milton.u.washington.edu> szabo@sequent.com (Nick Szabo) writes: > > Does operator fatigue cost even a significant fraction of the space station > astronaut time required for on-site teleoperation? It certainly might if it increased the incidence of accidents caused by operator error due to fatigue. I suspect that shifts would have to be very short to prevent the level of fatigue which can cause those kinds of slip. The problem is that when using very "laggy" control systems the operator is kept at a high mental tension / concentration level, with a high level of muscular tension as well, constantly overcontrolling muscles so as not to oversteer the controlled system. I'm not saying that this is an overriding reason to use the more expensive system, just that it's not as trivial objection as it looks at first blush. -- ------------------------------------------------------------------------ Speaker-to-managers, aka Bruce Cohen, Computer Research Lab email: brucec@tekchips.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077