plannerXaibo

Motion Planning for Sony Aibo with smodels

Docente Prof. Alessandro Provetti

This project concerns robot motion planning, which is capable of move the Aibo ERS-7 in a known environment. We present a plan for SMODELS, a system for answer set programming. The output of SMODELS describes a set of actions that the robot can follow to move from a designed start point to a goal point.

Answer set programming is a programming paradigm different from traditional procedural programming. Instead of writing algorithms to solve a problem in hand, the programmer describes the problem using a formal language and an underlying engine that find a solution to the problem.

In this project we use smodels for a robot motion planning problem. The goal for our motion planning is move a Sony Aibo robot in a known graph.

For this experiment we suppose to have got a Sony Aibo; actions are generated by this planner that runs on a PC. They must be exctracted by the smodels output with a script, tipically using awk script language. The script creates a command file that had to be transfered to the robot, usually through the wireless card aibo has got, where there's a c++ program that use this for make the robot moving. For this last part we hope to use the Tekkotsu library from Carnegie Mellon University. Thanks also to Luca Padovani for his work.

The continuation of this project consists in realizing a feedback system that integrates vision functionality to the entire architecture. The complete work can be described as follows:

Give the initial situation and the goal;
Program the planner with this settings;
Begin to execute the plan on the robot only for few action;
Rebuild initial situation with the robot sensors input;
Restart from the planning with this loop until arriving at goal;

What next? Future develop will be realizing a system motion plannig where we work in an unknown graph. Surely this will increase the computational load. We also have to say that moving in a konwn graph with a high number of nodes can be easily implemented in traditional procedural language such as c. It is computationally heavy to do with smodels so you can hardly realize a realtime process. However if we will develop planner for moving on unknown graph we could not use traditional language. For this reason we decided to start from the beginning with answer set programming.

Let's look at the implementation now. The code is distributed in three files, improving manageability.

The first file describes the environment in which Aibo moves; it also describes initial and final states. This is the part of planning that changes often and that let you trying several configurations. In this example we describe a map (as shown in the map) where we can found 20 rooms connected to the same number of passage waypoint. Rooms and way points are both considered general waypoints.
Photo 1 Photo 2 Photo 3 Photo 4

Adjacent represents the connections between waypoints. We also defined two general rules describing simmetryc of adjacent in the second file.
The initial states that we use in our example define the robot aibo in room initial_position, with initial_orientation, the charger in room r11, all rooms and passage waypoints are accessible by default, but you can describe exception to rooms accessibility.

The second file describes the dynamics and the Aibo moving abilities. It can be considered as the most important part of the planner because it introduces the choice rules and how states pogress. It also describes fluents, represents the value and describes state, actions, executability of actions in a given time and than the causes of these actions on the fluents.

Fluents are definitions of the value of a state, so they don't have relationship with time. Here we have following: level of the robot battery, position of robot and charger, accessibility of waypoints and finally orientation of robot.
The actions represent Aibo's abilities. They currently are: moving from a waypoint to an other one, turn towards for change orientation, open doors (we suppose that door are not full closed) and than wait if robot arrived in the goal position before time expires.
Predicate executable tell us when action can be performed at any time; to make it work correctly we need to refer to holds condition that rergard information about temporal evolution of the domain. All actions need an executability rules, except the wait action which is handled by occurs statements.
Causes describes the effect of actions on fluents.

The last file describes how the domain progress by the holds statements. This file should not change for this and future application.