Designing a Home Service Robot (Pt 2)
This is a continuation of a previous article on Home Service Robot Design, if you haven’t read that one already, I highly suggest you read it first.
If you’ve already read my previous article on the subject, then I’d just like to quickly recap from where I left off. In the first article I outlined the basic principles that I use to design home robotics systems:
Usefulness — it should provide a useful service to the user in either a physical or emotional capacity.
Modularity — any part should be easily replaceable, and when appropriate easily swapped out for an equivalent component.
Controllability — while ideally the robot should be able to behave autonomously, it should be under the users control at all times. This means it only performs tasks it is sure the user has requested or authorized in advance and provide a mechanism to stop its current action.
Transparency — it must be clear via design, behavior, or both that this device is a machine. That is, there should no attempt by the designer to make the robot appear to be anything other than a robot.
I then proceeded to apply the first two principles to start start designing a simple home robotics platform. In this article I will continue the excercise by applying the second two principles “Controllability” and “Transparency” to get a fully fleshed out design for a home robotics prototype.
Let’s get started!
Controllability
It may help to clarify this a bit for some readers. I do not mean controllability in the standard mathematical or engineering sense. Here I mean that the robot is as completely under the control of its owner as possible without compromising the intended functionality. (Making the robot 100% remote control would provide perfect controllabililty from the users point of view, but it would reduce its utility to near zero).
So what does this mean for MARVIN? Recall from the previous article (or learn for the first time) that MARVIN provides two primary services:
- As a smart table for transporting goods from place to place in the users home.
- As a tele-presence device.
To perform these tasks, the robot needs to provide both an interface telling it when to perform the task, and an interface for interrupting the tasks. None of these tasks require the robot to take its own initiative, so we should avoid any behaviors that result in the robot making movements without the explicit command of the user.
(A possible exception for this would be for the robot to return to some storage or recharge area in the users house when its been idle for too long or low on power. It should always be possible for the user to easily override such a behavior however).
Furthermore, we have to look at the other side of this coin. Users can, and will change their minds — controllability requires that we grant the user the ability to tell the robot to stop, or supersede a previously given command. A key command then, indeed a key feature of any robot, is the STOP command. Put more directly:
Any robot must provide a fast and easy way for the user to safely stop its current behavior.
In MARVIN’s case, this will be handled with a literal STOP command. If the user either provides voice or direct command to the robot to “STOP” the current set of behaviors will be interrupted and the robot will become idle waiting for a new command.
Transparency
This guideline can be seen as avoiding the so called “uncanny valley”. We do not want the user to casually assume that the system has more intelligence than it actually does. This may seem counter intuitive, but what when a user thinks the system is smarter than it is, they’ll expect it to do things it is simply incapable of and paradoxically consider it less useful than if the limitations are clearly defined.
So for a home service robot, we must be careful about the illusion of intelligence that we provide. Too little of this “illusion” and the machine will feel clunky to work with, leading to user frustration. Too much of the illusion, and the system will fail to perform that users expectations, again, leading to frustration. Our goal here should be to indicate just the right amount of “intelligent” behaviour by making sure our robot looks suited to the task at hand and never hints at being more than its capable of.
Not following this guideline can lead to issues seen by the likes of Amazon Alexa, where users, not realizing the limitations of the device, have constantly found themselves accidentally giving it commands without realizing they had done so. Since the device doesn’t always make it clear that its not human (i.e. its not transparent) this can lead to situations with undesirable consequences.
So that’s my philosophy on robots design. I think, at least for consumer and home robotics, its important to make sure that these devices are designed with the users well being in mind. We need to build devices that extend and help the population, not frustrate them, or completely replace them. I think these guidelines provide a good start in that direction, but like any guide they’ll need to updated from time to time.
What do you think?
