Lets design a useful robot

My visit to the RoboDevelopment Conference this past October got me to thinking about what a useful robot would consist of. So I decided to put down my thoughts.

Lets start with the functions we wish it to do.

I want a robot that will fetch and carry stuff around the house. A friend’s mother just had hip surgery and it is difficult for her to get around, and especially difficult for her to bend down and pick things up. So this robot will need to be able to move around the house, grab items and bring them to me. So the first function is the ability to fetch and carry.

In order for this robot to fetch and carry it will need to have an arm and gripper and be able to grasp items from the floor, from table tops or from dresser tops and deliver them to me.

To make sure that I don’t have to do anything to take care of this robot I want a certain amount of autonomy. Another function is the ability to watch its battery level and if they run low it should be able to go and recharge itself.

This functionality implies that the robot can navigate within the house, move from room to room, and locate objects within a room. Function number three for this robot is the ability to navigate. The final function is the ability to recognize objects.

This is our short list of functions we wish this robot to be able to accomplish. We also want to be able to expand its functionality in the future so we will design the robot to be expandable. And by expandable, I mean that the computing power and storage capacity should be sufficient for this and future functionality such as speech, hearing, vision, etc.

Now lets take a look at what is required to accomplish some of these functions on our robot.


Since the robot will be required to navigate within the home we have to come up with a complete navigation system. I know that lots of people would just suggest that we get ourselves a GPS receiver, but the problem with that is resolution. Even with differential GPS we can expect no better than 3 meter resolution which won’t even tell us which room the robot is located in.

So I plan to fall back on a navigation system that was designed for a robot I worked on called Gemini. This simple system uses a infra-red beacon situated in each room that not only identifies the room the robot is in, but gives a reference point to use for navigation both within the room and between rooms.

Using this reference point the robot can compute its position within the room by getting a relative angle to the beacon and measuring the distance to the beacon. It can also compute a path to its destination. And all of the math is going to be simple geometry and trigonometry.

Now lets specify the size of the robot.

To make it simple for the robot to see the beacons we need to make the robot about 48 inches tall. Most of the robots of today tend to be tiny things. The majority of them are only a couple inches tall. Put your nose two inches off the floor and take a look around. Can you see anything other than chair and table legs?

So making the robot at least 48 inches tall, gets it up to a point where it could “see” over the top of most furniture in a room.

The width of the robot is also pretty straight forward. It should be no more than 28 inches in diameter. Most doorways are 28 inches so this is cutting it pretty close. And if the door doesn’t swing completely out of the way and there is fancy molding around the door frame we may only have an opening of about 25 or 26 inches. I would recommend giving at least a couple inches of clearance on each side. So I will make this robot 20 inches in diameter. I say diameter because I plan to make the base round. This is so that when the robot rotates in place there are no edges to snag on things.

Rotating in place is an important design feature of this robot too. When we start having the robot move around by itself it will find the tightest corners to trap itself in. So it needs to be able to reverse direction easily. This means that designs based on tricycle steering or steerable wheels similar to a car won’t work very well. These usually require multipoint turns which are very difficult to program.

Based on my years of experimenting with robots, I prefer a four wheel system with skid steering, similar to a tank. It is easy to implement, is very stable and works pretty good. The four wheel drive configuration gives good traction on most surfaces in a house and skid steer allows the robot to turn in place by driving one side forward and the other side in reverse.

A great many current robot designs seem to be going toward two wheel systems but I prefer to avoid them since they are pretty unstable. If it uses casters to help it stay balanced, the casters can get hung up on things. If the drive wheels are offset from the center of rotation then it is essentially a tricycle system and cannot turn in place. And if we go with a self balancing system, then the power requirements, even to just stay in place, are pretty high.

In my opinion two legged robots are even worse. These require fairly complex software to move at all and in order to just remain standing in place they require lots of energy. One thing that we will find is that energy is always at a premium in robots.

How about battery capacity?

To make this robot useful we will want to be able have it “on call” the majority of the time. To me that means it should spend at least 8 hours off its battery charger. Ideally the robot should only require an hour or two to totally recharge and be ready for another 8 hour shift.

The robot should also be able to connect itself to its battery charger without human assistance.


For this initial design I don’t plan on developing a full blown voice recognition system. But I would like the robot to be able to hear sounds and respond. Something like 2 claps, means come here. Or a whistle means bring me a blanket. I do have some concepts for voice recognition but they are related to my ideas on artificial intelligence so they will have to wait for another time.

Arm and gripper.

An arm is required on this robot in order for it to fetch and carry. These are readily available from a number of sources. It should reach the ground so it can pick up objects on the floor. It should also reach high enough to place or get objects from a table.

Object recognition.

Finally we want to be able to identify things that are to be fetched and carried. Ideally we would want some kind of visual object recognition. But to simplify this design we will use RFID tags or optical bar codes to identify objects.

This gives us the basic features of a useful robot, but as they say, the devil is in the details. So we’ll look at each of these areas in future editions and sketch out those details.

Michael Fowler 2016