Archive for February, 2012
It is a truism that the founders of a start-up business have to wear many hats. We are all familiar with the image of the owner/operator running by the office supply store on the way to work to pick up copier paper, cleaning the windows before the doors open, meeting with their banker, taking a client to lunch, taking the garbage out before going home to work on the ad copy for the new brochure. It is the essence of the start-up and small business lifestyle.
It is also true that as the business evolves, the tasks shift over time. A few years back, we were in the research phase of R&D. We focused on exploring the possibilities of a new way to design the brains for intelligent robots. Our white-boards were covered with models of human cognition and neuro-anatomy. We were breaking new ground in software development methodologies to build the brains for our yet-to-be robots. This is the academic hat, our mortar board, and gave us our first technical book Robots, Reasoning, and Reification. You can tell it is an academic book, we used an Oxford Comma in the title!
A little over a year ago, our business changed hats – we spent less time on the ‘R’ part, and far more on the ‘D’ of development. Putting together tens of thousands of lines of code that would implement the intelligent behavior; designing and prototyping new robot bodies that would enable us to prove out the research. And, as is always the case, returning to the white-boards to refine the designs, open new areas of research, and loop back to developing functional prototypes. This was less of a hat, and more of a face shield and lab coat phase.
Then we switched hats again: the white-boards were just as often filled with analyses of the potential markets, and we spent much of our time talking with potential customers to refine the benefits that our robots would provide. We focused more on the hunt for funding to keep the operations going, and designing the ‘look and feel’ of our new robots. We started relying more on project plans and Gantt charts – tracking the progress of our development. And always returning to the white-boards to refine solutions, analyze new problems as we learned more about the domains. We focused not on enabling the robots just to do the tasks they are assigned, but to do those tasks well. Check out Projects versus Products. This is our construction hard-hat – we’re out in the rain pounding nails to put up walls and a roof that have to hold up under the snow and rain.
Once again we are switching hats. Now we are moving into the product design and production set-up phase. It is all well and good to have a robust prototype robot that can do a full days work, but we need to design and build a business process that can turn out robots on demand to meet the needs of our customers. Sure, there is still software development going on as we fine tune the performance of the robots, and learn more about what our customers need. I’m not sure what the best hat description for this phase would be – I kind of picture the 1950’s drafting tables, and guys (it’s the fifties, there were mostly guys) wearing suits and white button down shirts, perhaps donning a fedora to walk down to the local bar for a Manhattan after work. In any event this will be a focus for a big part of the team for the next six months.
The rest of the team will switch yet again as we move into the marketing and sales phase for our first product off the line – the Mobile Camera System security robot. So that means we focus on building a clear, simple message about how we can make our customer’s lives better, reducing costs, increasing security and safety. That message needs to be consistently presented across a variety of media, to a variety of different customers; each with their own needs. We need to be on target, and get geared up for our impending product launch in August – less than seven months away. Every time I look at our internal website I see a countdown timer, reminding me that we have (as of today, less than 170 days to go!) Did I mention – I’m a software engineer, not an MBA? Oh well, just one more learning curve to try to catch up with the real experts on the team.
Where is your robot? Ours are being built at Gamma Two Robotics, here in Colorado.
The snow is still falling, the walk isn’t cleared, and the robot is dripping melting snow onto the garage floor. I have a fresh pot of tea (Nilgiri black, from Mark T. Wendell teas) steaming on the drawing table, along with a home-made English muffin with honey and butter.
What was I doing again? Oh yeah, the Snow Shovelling Robot.
So, previously we tried the snow-blower, and the plow. Now it is time to get serious. A snow shovelling robot should shovel snow. How hard can it be? 10 year old kids can do this. Take a shovel, stick it in the snow, toss it away, repeat. Easy. We can take a shovel, and cut down the handle. Attach it to the robot, and add a mechanism to stick it horizontally into the snow. Add another mechanism to lift the shovel blade, and another one to fling the snow off to the side. The robot moves forward, and the process repeats. Where’s my pencil?
I’m sure you can envision the Snow Shovelling Robot: tank treads, front mounted arm, with a shovel blade, electronics, servo-motors, pneumatic cylinders driving the tossing mechanism, possibly even a steam tank to keep the blade from freezing up. A total steam-punk fantasy. Now we are ready to roll! Except for the hard part, the brains.
Don’t get me wrong, the mechanical system is complex, and requires serious engineering. I’m sure any number of mechatronics engineers were having a chuckle at the obvious mechanical errors expounded in the previous post. But that is my point – they were obvious errors. If you look at the hundreds of existing robotics systems in the world today, you will see mechanical, electrical, pneumo-hydrolic marvels doing work in bomb disposal, deep sea exploration, flight systems, everything! But the vast majority of them require a person to drive them around; a person to make sense of the environment by looking through the sensors; a person to decide what to do; and a person to execute the plan using the joysticks, game controllers, and switches on the console. In fact in systems like the Predator drones, it literally can require three or four people to fly the mission.
Right now, it is a person making the hundreds of judgement calls needed to actually do something useful, like shovelling the sidewalk. “What?” you say, “Judgement calls about shovelling?” Actually, yes.
A judgement call is a decision that is made dependent on the situation, and frequently without complete knowledge. Think about the types of decisions:
- How big a ‘bite’ of snow to take,
- Where to toss it,
- How best to get the snow off the shovel blade,
- What to do when the snow sticks,
- How best to get the shovel blade down to the concrete, without jamming it into a crack, and so on.
And all of these decisions, are being made in real time, you’ve got maybe 3 seconds per ‘shovel operation’. And, these decisions are being made without complete information. You don’t know the ‘stickiness’ of the snow, as you move down the sidewalk, when is the snow you are tossing getting too close to the neighbor’s car? Do you break your rhythm to clean the blade, or risk having the shovel fly out of your grip when the snow doesn’t let go?
And our mission, should we choose to accept it, is to get a computer to do all this, while controlling the robot.
And, perhaps the most daunting aspect of all, is we don’t really understand how ‘we’ as humans make these decisions. If you asked people how they decide how big a ‘bite’ of snow to shovel, you’ll get answers like “the feel is right”, or “I just kind of eyeball it”, or (my favorite) “When you’ve been shovelling snow as long as I have, you just know.” Program that into your robot. The odd thing is, according to a number of current cognitive science theories each of these answers is exactly right.
There are two competing truisms: 1) if you can’t explain how to do something, you can’t program a computer to do it, 2) the act of explaining how you do something frequently changes the process that you are trying to explain. Sure, there are exceptions to both of these ‘rules’, but they hold most of the time. This is why you don’t have a snow shovelling robot. It’s not the hardware, the mechatronics engineers are giving us great hardware, we are still working on how to ‘tell’ the hardware what to do. For a more detailed analysis you can check out our book “Robots, Reasoning, and Reification”
The short form is that the robot needs to map the current situation into a model of the world (the reification part), and then have behaviors it can execute (the robot part), and it has to select the appropriate behaviors (the reasoning part) as the situation changes.
It becomes a dance of a sort. A three step figure:
- Figure out what aspects of the shovelling process can be reduced to pre-programmed ‘muscle memory’ – behaviors that can be re-played in specific situations.
- Figure out when to ‘re-play’ those behaviors – what are the circumstances in which those behaviors are the appropriate behaviors
- Figure out how to stitch those together into a pattern that ends up with the snow off the sidewalk, and not on the neighbors car.
To do that we need data – Well, the snow is picking up again, so I need to get up, grab the shovel, and start shovelling. Looks like, for this storm anyway, I am the Snow Shovelling Robot.
Where’s your Robot? Ours are being built by Gamma Two Robotics, here in (snowy) Colorado.
They are calling it Snowpocalypse. It’s not really that bad for Colorado, a steady 24 hour snowstorm that will pile up 18 to 24 inches of snow. O.K., it is a little more than normal for Denver in February. Since the storm is a long one, we can look forward to shovelling the sidewalk two or three times today. Did the first one just now, and thought about the snow shovelling robot.
At first glance, how hard can it be to move snow from one place to another? Just need some device to transport snow. So let’s get started. First we’ll grab a snow blower, that solves the transport snow issue. We’ll need to make sure it is one of those self-propelled ones. Then all we need to do it provide sensors and steering, and we are done. This is easy, should have done this years ago.
What? You have a question? How does it know where to take the snow from? Um, okay, we want the sidewalk cleared, so it just has to know where the sidewalk is. Well, we could use a vision system, but the sidewalk is buried under a foot of snow, so that’s out. Heck, I sometimes find myself missing the walk if the snow is deep enough. Okay, let’s add a marker of some sort – perhaps one of those ‘invisible fence’ wires down each side of the walk, then the robot just has to stay between the lines. Oh, yeah, and a marker for the property lines, so that we know when to stop. Sure, sure, we’ll go a little over so the neighbors know that we care. Now that we know where we are, we will need to steer. Where is the steering control? What? WHAT? You have to man-handle this thing around by jerking on the handles? That means applying force from an external anchor point, like the person standing securely on the cleared sidewalk. The whole point was that we don’t have a person standing behind the snowblower. Well, maybe we can just use dead reckoning, and blindly go down the middle of the sidewalk. Oooops, that won’t work, we still need a person to line the snowblower up, and turn it around at the other end. Besides, I’m pretty sure my home-owner’s insurance would have something to say about a blind, robotic snowblower charging down the sidewalk chopping up everything in its path. Oh, well, back to the drawing board.
Let’s go out to the garage and grab that squat little tank-treaded prototype that was designed to weed the garden. Shoot, that means I need to shovel the 13″ of snow off of the path out to the garage. I really need a snow shovelling robot.
The tank chassis steers itself around, so that is covered. It is pretty heavy so it can transport even heavy wet snow. It knows (roughly) where it is using GPS. And it has mounting points for manipulators. Let’s start by adding a simple plow blade on the front, and we’ll use the guide wires from version one, so that it can follow the walk. Piece of cake! Okay, let’s run it over the sidewalk between the house and the garage. The storm has only put down another 2″ while I was working, so let’s hit the on switch.
Sweet! Works like a charm, it is pushing the snow to either side of the walk, and left a beautiful clear path between the garage and the house. Now out to the front of the house to clear the walk.
We’ll wrestle the robot through the house, out onto the porch, and place it on the walk. The robot drops through the snow and settles in. Hit the on switch and watch those treads spin. And spin, and spin. The treads can’t get any purchase on the snow. Shoot. Pick the robot up, and put it back on the porch, track snow back through the house to grab the shovel, and clear just a small space on the walk to let the treads hit concrete. Pick the robot off the porch (I need a robot to haul robots) and put it on the walk, and hit the go button. The robot takes off and slams into the (now 14″) wall of snow. It struggles on for about a foot, and then stops. It can’t push the snow out of the way, even when it has good traction. I guess that is why we humans use shovels to lift the snow out of the way, rather than just trying to push it aside. Back inside, pour some more tea, and back to the drawing board.