Robot Simulation Markup Language (RoSiML) is the XSD grammar used by YARS.

YARS is fully configured by a RoSiML XML file, which contains all the information required to set-up a simulation (excluding the robot controller). This posts discusses the different sections of a RoSiML and how to read the documentation that can be generated from YARS yars --export=png/pdf.






The simulator section contains the parameters to control the physics and other simulator parameters. The parameters are explained in the following paragraphs. The following figure shows all parameters and their respective types. The frequency attribute controls the number of physics iterations that are visible. This needs some explanation. There are two different frequencies, that can be configured in YARS. The controller frequency (see below), which determines, how often the controller is executed, i.e., how often sensor values are provided to the controller and motor commands are handed from the controller to the physics engine. The second frequency (which is controlled here), determines how often the physics is iterated per simulated second. Naturally, the simulator frequency must be larger than the controller frequency and the controller frequency must be a integer divider of the simulator frequency. The simulator frequency also determines how often the logging (see below) takes place per simulated second. Each step of the physics engine leads to new states of the sensors, actuators, segments, etc. which can be logged.




The solver subsection of the simulator configuration determines how many iterations are performed between two updates of the physics state. This must be clarified. The frequency attribute, described above, determines how many times the physics is updated per simulated second. All of these updates are visible, which means that they are visualised (see below) and can be logged. The solver iterations determine the precision between two physics updates. For more complex morphologies, more iterations are needed for the solver to converge to the correct distribution of forces. This is the number of iterations that is controlled by the solver iteration tag. Is is the number of calculations that bullet performs between to physics updates (see above).


The control subsection contains parameters which determine the number of simulator updates, the number of iterations until an automatic reset is performed, and finally, a seed for the random number generator.


Previous versions of YARS supported several views on the same scene. Future versions of YARS will again support several cameras on the same scene, each with their own configuration and possibility of recording. This is the reason why the screens section of RoSiML still allows to configure multiple screens, although this is not supported in the current version of YARS (0.8.41).
Any number of screens may be configured. Any number of these screens may be opened at runtime (see show attribute) or on keyboard command. If more windows are opened than specified in the screens section, a default window will be opened. The default window can be configured by the default tag (see below).




This tag defines the initial position of the camera in this window. It is defined by two 3D vectors, position and lookAt. The tag position defines the origin of the camera, whereas lookAt defines the position in YARS world coordinate system, towards which the camera is directed at.



orbit, centre

Both cameras have the same set of parameter, which is why they are discussed together in this paragraph. The lookAtX/Y/Z tags define the PID-controller parameters for the position of the followed object. The fromX/Y/Z tags define the PID-controller parameter for the position of the camera. Assume that the PID parameters of the lookAt tags are all set to zero, than the camera would not follow the object. Assume that the P-parameter of the lookAt tags are set to 1.0, than the camera would perfectly follow the position of the object. For the from tags, the initial distance from the followed object is try to kept constant (offset) or defines the radius with which the camera rotates around the object (orbit). The orbit has an additional attribute, which defines the rotational velocity in degree per second.


centre / orbit camera


The sky tag allows to define the texture that is used for the sky. For a description how to includes textures in YARS, please see Sec. SECREF TEXTURES


The followables tag is a list of objects (see robot tag below) which can be followed by the camera. The objects are given by followable tags, which require nothing more but the unique object name.




The recording tags contains a list of interval tags, which define at which iteration of the physics (see simulator frequency above) automatic recording is stated and terminated. This intention of this tag is to e.g. record the initial phase of a learning experiment as well as the converged state, without the need of constant monitoring of the experiment by the experimenter.




At the current version of YARS, the visualise tag allows to configure if and how the joint coordinate systems are visualised. The joints tag allows to define the height and with of the axes visualisations as well as a possible offset in x,y,z coordinates.



screen, default

The screen section (as the default section) defines the appearance of window which displays the experiment. The first thing to notice is that every window must have a name, which is displayed in the titlebar of the window. There are a few optional attributes that determine if the window is shown as soon as YARS is running (show), if capturing the window’s content is also initiated immediately after the window is shown (capture), and finally, if the window’s camera should immediately follow the first object specified in the followables section (follow, followables is discussed below).


screen / default


This tag has two attributes, x and y, which determine the monitor coordinates (centre of the window with respect to the upper left corner of the monitor).
The tags resolution and size mutually exclusive. Standard resolutions are defined and can are specified by the name attribute of the resolution tag, whereas the size tag allows to define the window size freely through the weight and height attributes.


This section defines the fonts (type, size, colour) for the fonts used in the on-screen-display of YARS. This includes the font for the display of the simulated time (time, upper left corner) as well as the information that can be generated by the RobotController (robot, lower left corner, RobotController is discussed below).




A macro is identified by a unique name and contains a set of objects (please see below). The macros can be referenced in the environments and body (see robot) as many times as desired. The position and textures defined in the macro can be modified, when the macro is referenced (see below).
The objects are described below.




The robots tag contains all actively controlled entities. Any number of robots may be configured in YARS.


A robot has a unique name and consists of five subsections, which must be given in the following order: body, actuators, sensors, pose, controller.




The body section contains the definition of the physical objects. This section determines the shape, the weight distribution and friction of the robots morphology. The objects are specified below.




























There are four different actuators available in YARS, which are; hinge, slider, fixed, and generic. They can be added in any order and in any number.




The hinge joint connects two bodies with a rotational/revolute joint.




The slider joint connects two bodies with a prismatic joint.




The fixed joint connects two body and constraints their relative position and rotation to the original relative pose. In other words, the two bodies are connected and no rotation or translation is allowed. Because this is a joint, large forces may induces some change in the relative pose.

if the destination object’s name is omitted, the actuators is attached to ,,to environment”. This means that in this example, it main body is fixed at its initial position.


This joint allows to configure the constraints in all six dimensions, i.e. translation in x,y,z and rotation around x,y,z independently.


YARS provides a number of sensors.




This is a generic proximity sensor that is simulated by five rays.


proximity sensor
Example from braitenberg.xml:



This is a generic ambient light sensor.


ambient light sensor


This is a generic orientation sensor.


orientation sensor


This is a generic position sensor.


position sensor


This is a light dependent resistor position sensor.


ldr sensor


This is a sharpDM2Y3A003K0F proximity sensor.


sharpDM2Y3A003K0F sensor


This is a sharpGP2D12_37 proximity sensor.


sharpGP2D12_37 sensor


This is a velocity sensor.


velocity sensor


This is a deflection sensor.


deflection sensor


This is a binaryContact sensor.


binaryContact sensor


This is a generic joint sensor.


generic sensor


This is a generic object velocity sensor.


ov sensor


This is a generic object angular velocity sensor.


oav sensor




actuator logging



sensor logging



object logging



gnuplot logging



console logging



controller logging

csv (logging)


csv logging



blender logging




Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.