Computer "Cooperation"
by Tom Temple
7 February 2008
The following story is from Missy Cummings, my superstar human factors prof and former fighter pilot.
The “guns kill” is where you get to show how good of a pilot you are. Missiles… eh. The guns kill is what you are really going for. Not only that, the system is recording video so if you can hold the guns on the other guy’s helmet for 8 seconds, you can show him later. The problem is that the bullets are supersonic and you can’t see them. So to help aim, you’ve got these tracers on your HUD and it’s just like in a video game.
The guy in the back was going in for a guns kill and was focused on his tracer display rather than his instruments. It being the critical moment in the gun fight and both of them being very talented, they were maneuvering pretty aggressively. Specifically the chasing plane was pulling a “cross brake” maneuver which tips the nose of the plane up and to the side causing a dramatic turn and deceleration.
It was also a move that the flight control system was not familiar with. The pilot had learned it on a “real plane” where the pilot is actually in command of the control surfaces. On this plane he was just telling the control system what he would like to have happen. The control system essentially refused and stripped the pilot of control authority right as he was closing in.
She shows two pictures of planes, one with the nose off, the other with a tail fin half of and about a third of a wing too. It’s pretty obvious who was in the front and who was in the back.
It turns out that losing the nose isn’t that big of a deal. The chase pilot just followed roads back to the base. The front plane lost a lot of important pieces. In the past, the goal of it’s pilot would be to eject while still conscious. But instead, he just flew it back and landed it like normal. The computer with it’s lightning reflexes and amazing system identification was able to still do everything that the pilot asked. It just corresponded to completely different controls.
———————————————————-
Point of the story: Human—computer cooperation is more complicated than delegation of tasks.
One facet of what I’m working on right now is the control of systems that include humans. That could mean a lot of things varying from the computer telling people what to do or modifying robot behavior to allow for better cooperation. Example: Lets say two computers and two humans are playing 5 chess games and 5 go games against some opponents. I’d be interested in determining who should play what and whether any of them should collaborate.
Some of this falls squarely in the field of “Human Factors.” To this point, human factors has largely focused on how to design a good interface, and how much work you can get out of a single air traffic controller. A lot of theory guys pooh-pooh this while the engineers view it as a tedious necessity. But then there are people like Gary Kasparov, who sees some room for real collaboration. As of right now, I’m not sure how much he’s deluding himself.
What do you guys think?
Feb 8, 04:14 PM
I’m curious Tom where you draw the line (if one exists) between a human using a tool and a human collaborating with a tool.
Advanced chess seems to me like its simply a human using a tool.
Collaboration to me suggests the possibility for debate and dialogue between the human and the tool. Indeed, collaboration (as a human activity) strikes me as requiring a fairly even balance of power. To collaborate, two actors would require the ability and autonomy to argue the merits of a particular course of action, including the potential for a stalemate, and indecision.
I’d guess that in most instances of human/computer “collaboration”, such an even balance of power would be considered unwise, as in your dogfighting example: specifically, I’d think that the human should always be given the power to override the computer, not vice versa. The propensity for monolithic computers in the movies to be difficult for humans to override has always struck me as a bug, not a feature.
But maybe that was your point? Collaboration is hard because sometimes the person with the “wrong” idea (in this case the on board computer) wins the argument?
Feb 13, 03:07 PM
I don’t think that the distinction is a meaningful one.
We are talking about “control” and in the end there must be some way of resolving conflicts and presumably the humans should have the upper hand. That said, the human cannot be presumed a priori, to be well informed. In chess there are certainly things that the human has not considered and if the computer disagrees with a move, it should probably point some of them out. On the other hand, suppose further that the human could tell the computer how to re-evaluate the position (e.g. by modifying a heuristic) so as the computer sees the rationale. At this point, the computer still might have valuable “insights” as to the progression of the game. I think the word “collaborate” is applicable.
At some point it might become necessary for someone to over-ride someone else, but it need not be immediate. In the case of the cross-brake there might or might not have been time for the computer to warn about leaving the flight envelope (which is a justifiable reason for refusing the input) and for the human to inform the computer about the other plane. I don’t want to get bogged down talking about interfaces and defaults although that is obviously central in this example.
My point is that it is not always the point at which who should be deferring to whom.
Anyway, I think my research is taking the direction of Decision Support. It really excites me that people can play backgammon against computers despite being demonstrably terrible at computing explicit odds. I suspect that a computational tool could be created that would allow humans to beat the best computer backgammon players. I think it might be possible to develop a problem formulation that generalize this tool. That’s what I’m thinking today at least.