Developing the First Law of Robotics

wabrandsma sends this article from New Scientist: In an experiment, Alan Winfield and his colleagues programmed a robot to prevent other automatons – acting as proxies for humans – from falling into a hole. This is a simplified version of Isaac Asimov's fictional First Law of Robotics – a robot must not allow a human being to come to harm. At first, the robot was successful in its task. As a human proxy moved towards the hole, the robot rushed in to push it out of the path of danger. But when the team added a second human proxy rolling toward the hole at the same time, the robot was forced to choose. Sometimes, it managed to save one human while letting the other perish; a few times it even managed to save both. But in 14 out of 33 trials, the robot wasted so much time fretting over its decision that both humans fell into the hole. Winfield describes his robot as an "ethical zombie" that has no choice but to behave as it does. Though it may save others according to a programmed code of conduct, it doesn't understand the reasoning behind its actions.

Comments

I, Robot from a programmers perspective

[wisnoskij]

Don't get me started on Asimov's work. He tried to write allot about how robots would function with these laws that he invented, but really just ended up writing about a bunch of horrendously programmed robots who underwent 0 testing and predictably and catastrophically failed at every single edge case. I do not think there is a single robot in any of his stories that would not not self destruct within 5 minutes of entering the real world.

50/50

[visionsofmcskill]

why would it waste any time fretting? i presume its decision is by the very nature of computing and evaluation a function of math... therefor the only decision to cause delay would be the one wherein the odds of success are 50/50... but it needs not be delayed there either... just roll a random and pick one to save first.

Sounds like a case of a unnecessary recursive loop to me (where the even odds of save/fail cause the robotic savior to keep reevaluating the same inevitable math in hopes of some sort of change). Maybe the halfway solution is the first tiome you hit a 50/50 you flip a coin and start acting on saving one party while continuing to re-evaluate the odds as you are in motion... this could cause a similar loop - but is more likely to have the odds begin to cascade further in the direction of your intended action.

Seems silly to me.

Re:Buridan's Principle

[neoritter]

Do you really think a donkey will starve to death because you place two bales of hay equidistant from the donkey?

Re:So, a design failure then.

[plover]

I would grant that "fretting" was poetic license. Consider that the life-saving robot must continually evaluate all factors.

Let's say I was closer to a lava flow than you, but your path was on a slightly more direct course into it than mine, and the robot is located at the lava's edge midway between both of us. I will hit the lava in 30 seconds, but you will hit it in 20. The robot needs two seconds to have a high probability of saving someone, but one second is enough for a moderate chance. Factoring in the motion required, the chances of saving us both is high. As you are in more immediate peril than I, it should intercede on your behalf first, so the robot starts to move in your direction. Now, I change my course slightly so I will hit it in 15 seconds. The robot still has time to save us both, but the chances are slightly lower. It moves on a path to intercept me first. You then change your path so you will hit it in 10 seconds. The chances of saving us both is now only moderate, but still possible. So the robot alters its path again to save you first. Now, we both steer directly toward the lava, with only one second to intercept for either of us. The robot's continual path changing introduced so much delay it was no longer in a position to save either of us. We both die.

To the outside observer, it fretted, but the algorithm made continually logical decisions.