While numerous programming solutions exist, they fail to provide a clean high-level declarative programming solution for NXT. Programming robots, especially mobile ones, is a complex task, involving some typical AI problems, such as knowledge representation and processing, planning, etc. These areas are much more accessible with the use of a declarative programming solutions, compared to classic, low-level imperative languages.

The paper presents research developed within the HeKatE project http://hekate.ia.agh.du.pl aimed at providing a high-level rule-based programming solution for Mindstorms NXT, based on the Prolog language API for the NXT platform.

Basing on the review of existing solutions presented above, the requirements of a new Prolog API for NXT has been formulated. The main requirements are:

• support for all functions of the standard NXT components, that is sensors and motors,
• crossplatform solution, for both Windows and GNU/Linux environments,
• reuse some of the available solutions, and provide compatibility where possible,
• ultimately integrate with the higher XTT layer.

The whole platform based on this new Prolog API is planned as presented in the figure below. In the figure the highest visual rule-based logic design with XTT is also included. The focus of this paper is the design and prototype of the Prolog API layer, indicated in the figure by the dotted line.

In order to reuse and support some of the existing solutions, as well as provide implementation flexibility, it's been decided to provide in the first stage a Prolog library, with the following features: it is executed on a PC, controlling an NXT-based robot, the control is performed with the use of the Bluetooth or USB cable connection, the low-level communication is provided by some well-tested existing communications modules, at the functional level the API is coherent with other available solutions.

Considering the requirements the following API architecture has been designed. It is composed of three main layers as observed in the figure above.

• communication layer providing the low-level communication with the robot,
• sensomotoric layer allowing the exchange information with sensors and motors,
• behavioral layer providing a higher-level functions, e.g. drive.

The behavioral layer exposes to the programmer some high level functions and services. It provides abstract robot control functions, such as go, or turn. Ultimately a full navigation support for different robots is to be provided. (However, different robot configurations require different control logic)

The sensomotoric layer controls the components of the Mindstorms NXT set motors, all the sensors, as well as Brick functions. This layer can be used to directly read the sensors, as well as program the motors. This is a layer, that can be used by a programmer to enhance high-level behavioral functions.

The goal of the communication layer is to execute the actions of the sensomotoric layer and communicate with the NXT Brick. Currently in this layer several modules are present, providing different means of communication:

• a pure Prolog module, using a serial port communication, and the NXT protocol commands,
• a hybrid solution based on the Java-based iCommand library,
• a hybrid socket-based solution, using the NXT++ library, that communicates with the robot.

All of these actually wrap the Mindstorms NXT Communication Protocol.

The first solution is the most straight forward one. In this case standard ISO Prolog stream predicates can be used to control the serial port. Prolog terms that wrap the NXT protocol have to be provided. In the second case the Prolog communication module is integrated with iCommand with the use of the SWI Java to Prolog interface called JPL. Prolog calls are mapped to the iCommand methods. In the third case, a simple server written in C++ exposes NXT communication with a TCP socket. The Prolog communication module connects to the server and controls the robot through a TCP connection. This opens up a possibility of a remote control, where the controlling logic is run on another machine, or even machines.

Besides some basic send/receive functions the library has to provide certain services. These are event and time-based callback. For example, it should be possible to instruct the robot to e.g. “drive till you hit/approach an obstacle, then make a sound, wait for a response for some time, if you don't get one, turn and drive on”. So the library has to provide timers that trigger some callbacks, as well as event-driven callbacks. This requires parallel execution of certain threads.

For the implementation progress see: