Varrojo's Atrium::YaksServer



YaksServer is a custom API developed to provide networking capabilities to the Yaks Khepera Robot Simulator. 

It is written entirely in C/C++ and uses Berkeley Sockets to comunicate with local or remote clients.

The concept behind YaksServer is to encapsulate the Yaks simulator from the developer's point of view, so they do not have to concern with the simulator's source code quirks in order to develop meaningful agents.

The API is very simplistic. Being completely encapsulated in the YaksServer class, it provides just 3 main primitives to the Yaks Simulator: wait for clients, send sensor data and receive motor speeds.

The Yaks Simulator may handle any number of clients just by using a single instance of the YaksServer class.

The API was designed having in mind that every client would be assigned a robot, however, it does not impose any restrictions as how the clients are to be handled by the simulator. What's more, the API doesn't impose any limits on the types of agents which can be developed for the simulator. By unsing the API, intrested developers can focus on what really matters: their agent's logic.


The API will be released under a LGPL license, which allows interested developers to study and modify it's source code and include it in their own projects.


Although the API was built on Linux, the source code is being ported to Windows by means of the Winsock 2 API. 

We are trying to make the API the more "out-of-the-box" possible, so users just need to extract the API files inside the Yaks folder and recompile, no matter which environment they are in.

Additionally, since the API is completely encapsulated, it can be easily edited as to modify the protocol's messages so it can be ported to other simulators.


Since we are focusing on developing a really simple API, we are working to make it easy to install and set up.

The most recent version includes the API files (yaksserver.h and yaksserver.cpp), a modified Makefile and a new sim.cpp which handles the API. A new version of the MS Visual C++ project is to be included as well.

Current State of the API

By the time of writing, the current version of the API is 0.95, which has been tested exclusively on Linux.

Comparing with its (unreleased) previous version, 0.90, the API includes some changes that make it more robust and fully resilient to client crashes and disconnections, plus, an error checking subsystem, which notifies when an error has occured in the trasmission, has been added.

Should you decide to use the provided sim.cpp file, the default behaviour compells the following stages: when starting the simulator,  after pressing the "run" button, the server waits for as many clients as robots specified in the options file. After all the clients have been found, the server assigns a robot to each of them.

Once the robots have been assigned, the server starts an infinite loop in which it sends the current sensor data of each robot to the corresponding client, then it blocks, awaiting for the client's response. Each client answer must specify two motor speeds: left and right. After the server executes the action, it sends the new sensor data to the client.

Client Development

API clients can be developed in virtually any programming language, the only restriction is that the language must be able to access the TCP networking capabilities of the machine where it's executing.

Client APIs need only define 3 operations: 

  • connect: which connects to the server and thus needs it's location (IP address and port).
  • receive sensor data: which reads the sensor data corresponding to the assigned robot's state from the net.
  • send speed: sends the left and right motors speed to the server through the net.

The message formats are very simple, the speeds must be transmitted in a string of the form:


where L and R are floating point numbers, for instance speed:1.0:1.0 orders the robot to move one step ahead at full speed.

In a similar way, the server reports the sensor data in a string, which format is:


in this string the numbers are replaced by each sensor's actual reading, for instance, a sample state would be:


which would mean that an object is right next to the left wheel and no other objects are close.

Plans for the Next Version

I'm planning to add some additional controls as well as new features to the next version. In particular, i've been considering the following:

  • Client message validation: report when a client sends unrecognized messages, which can help the client API development and debug process.
  • Reconnection support: allow the simulator to reconnect a client after it has been disconected. In the actual version if a client closes its connection, in order to reconnect, the server must be restarted.


The Road Ahead 

After the Server API advances to the next version, I'm planning to develop prepared Client APIs for the C++, Java and C# programming languajes.

File Download

  • No files have been uploaded to this proyect yet.