Distant assistants: real-time collaboration

Yes, and one system/framework can already be exploited to do this for almost any (simple) task you can think of: The Amazon Mechanical Turk. As long as the task can be done by almost anyone, you can cheaply hire anonymous hordes to perform it.

I don’t think it could be used 100% for the autopilot system described in the article, but you could set up an HIT to view a radar graphic and perform a task if a certain color exists in a certain area (i.e. warn you if a storm is moving in a certain direction). Likewise HITs could be set up to alert you if an airport closes, or if delays exist above a certain threshold.

The system can be used to distribute information and get controlled responses for many other types of live collaboration.

“Full information” is perhaps stretching it a bit, and I would argue, almost exactly what we have learned is *not* wanted. What Philip discusses in his article is transmitting life-or-death flight telemetry data, literally the transmission of measurements to a qualified colleague who can act in an advisory capacity. Air speed as measured by the Pitot tube, pitch and yaw as measured by the gyros, etc. And, in the case of flight, the issue is monitoring a potentially overwhelming amount of live, critical information. In the F/A-18 Hornet series of jets, telemetry is analyzed in software and the voice of “Bitching Betty” alerts the pilot to abnormal patterns.

There is also live, monitored telemetry, in hospitals, for patients with cardiac conditions. Just walk to one of the medicine wards of any US hospital and ask for the telemetry room. In the ICUs the telemetry will include ventilation information as well and is often displayed in the room, at the nurses’s station, and it is accessible to the docs from various other computers or networks at all times. In hospital telemetry, technicians are assigned to monitor that data full time while the doctors and nurses attend to all issues, only spending some of their consciousness on “telly”. And even the technicians are backed up by alarms that sound when software detects well understood wave form abnormalities.

Then there’s military telemetry like GCCS and cooperative engagement capability which provide enough resolution that a “silent shooter” can engage a target based on fire-control data from a third source. As an officer of the deck, ship’s weapons coordinator, combat direction center watch officer or tactical action officer on ships, I was often overwhelmed by the amount of real-time collaboration with various colleagues (fifteen screens and six audio circuits would not be unexpected). Like Bitching Betty and the alarms in hospital telemetry rooms, the navigation and fire control software has been designed to monitor for threat profiles and can even be programmed for ‘full auto’ or ‘semi-auto’ engagement with fire control radar, missiles and guns. I’m not aware of any system being set to ‘full auto’ outside of controlled test range scenarios. Just thinking about that gives me the hebbie-jebbies.

On aircraft carriers, flight telemetry is passed between aircraft and aircraft carriers via a system commonly called “needles”. A qualified pilot, nick named “Paddles” is on deck and in constant radio contact with the pilot during final approach. Before I left the fleet the aircraft carriers and jets had advanced to a fully automated collaborative system that allowed the ship to land the plane while the pilot literally kept her hands off the controls.

These most-obvious/well-funded applications were some of the first collaborative communications, which funded the development of many of the protocols we now use regularly. Now that we have protocols, we use them more. For example, it’s almost certainly not necessary to have operating robots, remotely controlled by surgeons over the internet, but they’re here. One thing I haven’t heard of yet is an operative robot that monitors telemetry and is programmed to sound alarms or respond automatically to a developing threat to patient safety.

Where standing radio circuits aren’t required, there are plenty of available synchronous and asynchronous tools for communication. So many that few people bother to learn more than a few. I admin a server which currently has 11 different ports open; each port allows access to a different application-layer communication protocol, eg, port 80 for web traffic. In addition to irc chat, regular chat, wikis, email, command line tools like write, SMS “text” messaging, and phones, there are VNC and RDP, which are well understood protocols for distribution and remote control of a graphical desktop over networks, similar to what Jason Catena describes above (VNC is the basis of Apple’s Desktop Sharing feature). Software developers have potentially-but-not-necessarily-live version control systems like subversion and git that allow loose collaboration by providing a wiki-like ability to fork any number of separate versions. Adobe Creative Suite offers a similar graphical version control tool they call Version Cue.

On the much lower-end, I recently phoned a friend from the store while shopping for luggage. He started pricing items on ebay while I examined the physical specimens. I suppose that could be automated too, but the potential variety of these low-end collaborations, which mix real-time, near real-time, and static collaborative protocols rapidly becomes endless. I think the challenge is to choose which information sources you want and manage the opportunity costs.