Most of my daily journals have reported only indirectly on our work. Today I'll say a bit more about some specific work we did, and then as usual relate it to a more general theme.

Consider this puzzle: You want to work in an area that is behind some hills, so you need a communications repeater to relay radio and computer signals around the obstacles to you. You could put the repeater in many locations: On a hill further away than you from the base station (MDRS), on top of an intervening hill, or just nearby where it has a line of sight view of the base. But what if going to that location causes you to lose communications and you get stuck? Whether a robot or a person is deploying the relay, it's not a safe situation.

Wanting to work in the area behind what we call Pooh's Corner across the BLM road from MDRS, we knew that we'd need a relay beyond Pooh's Corner because much of that area is blocked by hills from the base station on top of the hab. We picked out a good spot for a relay near the saddle of the hill, at a place we call way point 31. Unfortunately, there is no way to get to way point 31 without losing communications with the hab. Having worked in that area before, we knew that a relay at way point 11 would allow Boudreaux to get to way point 31, where a second relay would be deployed. We could then retrieve the relay at way point 11 and use it further away—accomplishing a kind of leapfrogging.

Originally our plan was for the two robots to go out together, have Thibodeaux stay at way point 11 (serving as a relay) and have Boudreaux go to way point 31 (to deploy a relay). Then Thibodeaux could move up to join Boudreaux and they could progress further into the area to scout communications.

But Thibodeaux is not ready for operations. We chose instead to have Boudreaux deploy the relay at way point 11 on a separate run last week. But when Boudreaux wasn't ready, we had the astronauts just tow it out and put it in place.

So now Boudreaux could proceed to way point 31 and deploy a second relay. Except we thought maybe the terrain was too difficult and Boudreaux might stop to avoid hitting obstacles. We solved this by putting into the plan a pause, where we would take a panorama to view the area, and then possibly teleoperate to way point 31 (or perhaps to put the relay somewhere else). This made the operations somewhat like MER, with robotic movement to some prescribed location, then a photo, reconsideration by the engineers, and then possibly moving in closer to do something else.

Now if you look back at my April 6 journal, you'll see that we designed the scouting to fail, with the idea that we wanted to have Boudreaux move in a spiral until it failed:

"...what happens if Boudreaux fails during the scouting operation? The robot's control system sends a 'failure' to the HabCom Agent, which presents this information to HabCom (the crew member) in MDRS. At this point, HabCom can tell Boudreaux to go to the next activity, to repeat the current activity, or to come home. Knowing this, we realized we should design the scouting operation to fail..."

"Failing" here means being unable to continue the spiral because of obstacles. Today we were discussing the very same plan as April 6, to be carried out in a more distant area beyond Pooh's Corner. To my surprise, I was now told, "If scouting fails, Boudreaux can't reach Habcom if it's lost communications." Well, that's obvious, but why wasn't this made explicit last week? The very idea of scouting is to find out where you lose communications and map out those places. It is indeed very possible that an obstacle will be encountered when Boudreaux is out of communications. Last week, we somehow just assumed that communications would be good in Pooh's Corner, but nobody really spelled that out for the group.

So today we all learned that if Boudreaux fails to complete the spiral because of an obstacle and it is out of communications, everything will grind to a halt. The scouting operation in fact should have been designed to return to a good communications location (as by now Boudreaux will have a map of such locations to choose from). But there are many good ideas that we don't have time to program, and we just need to deal with the robot system as it is today. If Boudreaux quits when it has lost communications, the entire programmed operation will fail.

What would we do then? Easy, said the Boudreaux engineer, we'd just joystick it over to a good location. Having learned my lessons well the past week, I knew to ask, "How do you do that?" Oh, we have a control stick, I was told. Again, I knew not to be so easily satisfied, and becoming like an insistent child, I asked, "Isn't the agent program still running?" Finally, I learned the secret, I was told that plugging in the joystick controller into a socket on the robot disables the programmatic control. "I wrote the code that way," the engineer said with a big smile. And indeed I was happy, too, for I had learned something basic about how the robot is designed.

Now I turned my attention back to the agent programmer. I now understood that HabCom (the person) could not just tell Boudreaux to go to the next operation in the plan (because a scouting failure alert was not received, because the robot was out of communications). I asked what HabCom would do. "Oh, all you could do would be to reload the model [the plan]. There's no plan state [memory], so you must restart the EVA from scratch." (This part is not supposed to be funny.)

The real problem is that this kind of "autonomous" plan following was designed by the agent programmer to operate without people, so it can't be interrupted or readjusted once it gets started. Yikes, a robot totally out of control? I paused and looked at them, how interesting—a robotic engineer who provides easy ways of controlling his robot manually with a joystick (because he knows he needs this often in test situations), and an agent programmer (with all the flexibility in the world available to him), who designs clever ways for the robot to work without people. Of course, we need something in between, an "autonomous" robot that can be interrupted, redirected, and given new plans while it is out working. But again, we all have lots of great ideas like this, and maybe we'll have such a robot-agent next year, but it's not the system we had the time or money to build.

At about this point our communications engineer returned from setting up a new repeater for the mobile radios. We received his approval for the dual relay design (way points 11 and 31). Then he mentioned that we had a battery problem: The Mobile Agent computer running on Boudreaux would run out of power in something over three hours, and this whole plan could easily take that long. We then worked out a plan involving putting the laptop on Boudreaux's batteries and swapping in new batteries.

Like last week, this very interesting planning session took about two hours and we learned a lot about each other's systems. But I wondered, could we actually formalize all of these rules, limitations, constraints in a computer model, so that a computer system could reason through the relations and produce a plan as good as ours? That's the basic idea of "planning systems" developed over the past forty years of artificial intelligence programming (what I prefer to call "model-based programming"). The trick is that a modeler, a person, must write down all of the constraints in advance that the planning program would need. As our example shows, the modeler would have to be extremely lucky to know in advance all of the relevant constraints. In point of fact, our experience shows that one person is not likely to know all of the constraints. You'd need a kind of meeting, like our planning session, where you'd figure out the constraints by developing a plan. We discovered how line of sight and obstacles interacted with how the robot works and how the agent system works by going through a scenario, that is, by making a plan. The only way the automated planning method will work in the long run is by accumulating a lot of constraints found to relevant in many such planning sessions and being able to reuse them in new situations.

So maybe we could take what we learned today and put that in an automated planning system, and the program would have a chance of planning the next scouting reconnaissance without us. Yet, I would have made the same conclusion last week, and look how much we learned when trying to adopt last week's plan. We must hope for convergence on some set of constraints that work in many situations, and that's only possible if conditions are similar (such as the topography) and the systems haven't changed (because a programmer installed an improved control system, which is one of the reasons why Boudreaux failed today).

The ideal of autonomous operation with automated planning sounds great. But we will have a lot of days like today ahead of us—people planning for the robots, loading the models into the robot, and then trying to figure out what went wrong. The good news is that this is our work, and we enjoy it. The bad news is that sometimes we must call it quits for the day, get some dinner and rest, and then try again tomorrow.