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.

rosiml

 

 

simulator

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.

 

 

solver

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).

control

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.

screens

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).

 

 

cameras

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.

 

 

sky

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

followables

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.

 

 

recording

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.

 

 

visualise

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).

 

 

position

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).
resolution
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.

osd

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).

 

 

macros

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.

 

 

robots

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

robot

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

 

 

body

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.

 

 

sphere

 

 

box

 

 

cylinder

 

 

capsule

 

 

mesh

 

 

ply

 

 

visualisation

 

 

physics

 

 

actuators

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.

 

 

hinge

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

 

 

slider

The slider joint connects two bodies with a prismatic joint.

 

 

fixed

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.

generic

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.

sensors

YARS provides a number of sensors.

 

 

proximity

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

 

Example from braitenberg.xml:

 

ambientLight

This is a generic ambient light sensor.

 

 

orientation

This is a generic orientation sensor.

 

 

position

This is a generic position sensor.

 

 

ldr

This is a light dependent resistor position sensor.

 

 

sharpDM2Y3A003K0F

This is a sharpDM2Y3A003K0F proximity sensor.

 

 

sharpGP2D12_37

This is a sharpGP2D12_37 proximity sensor.

 

 

velocity

This is a velocity sensor.

 

 

deflection

This is a deflection sensor.

 

 

binaryContact

This is a binaryContact sensor.

 

 

generic

This is a generic joint sensor.

 

 

ov

This is a generic object velocity sensor.

 

 

oav

This is a generic object angular velocity sensor.

 

 

logging

actuator

 

 

sensor

 

 

object

 

 

gnuplot

 

 

console

 

 

controller

 

 

csv (logging)

 

 

blender

 

 

traces