Architecture

The framework follows, in a not very strict sense, the REST architectural style. If you don’t know what REST is, Wikipedia has a good introductory entry. In few words, REST is a software architecture style for distributed hypermedia systems. The World Wide Web is an example. You might ask what a robot has to do with hypertexts and distributed systems. Hence, in what follows, I will try to explain how I applied a sort of RESTful philosophy to the design of NXTServer.

A NXT robot is a server waiting for connection. When a connection is established, the server processes any request sent by the client and gives back a response. Client-server communication is stateless, that is, servers do not track the state of clients. Finally, client-server communication happens through a uniform interface discussed below.

Each piece of hardware on NXT is identified and abstracted by a resource. For example, motors and sensors are resources as well as the whole NXT. Resources have a name.

resource full name	resource name	description
/	/	every resource on NXT
/motor	motor	every motor
/motor/A	A	the motor named A

A resource is addressable. In other words, each resource is identified by a URI of the form

[protocol]://[NXT name]/[resource full name]

In the current version of NXTServer, only usb is supported as protocol. However, we are going to add bluetooth as soon as possible. Note that, following the Layered System Principle of RESTful architecture, we could have intermediary servers (e.g. a traditional Web server) between the real robot and the client. Hence, it would be possible to control the robot also through http or other protocols.

Clients and servers exchange representation of resources in JSON. A representation is a description of the internal state of a resource. The following example shows a JSON representation for a resource of type motor,

{ "speed":720, "forward":true}

A client request specifies the action to perform on the resource identified by a URI. At the moment, NXTServer supports four kinds of actions (in honor of HTTP): GET, PUT, POST and DELETE. Some actions are not allowed on some resources. For example, you can’t overwrite the state of a sensor because it is a read-only resource or you can’t delete a motor resource because you cannot remove hardware via software. We decided to leave implicit which resources are read-only, non deletable or whatever else because the choice is often quite obvious. If the client tries to perform a forbidden action, it will get back an error message. In what follows we discuss the semantics of actions through examples.