Goal

  • To gain a deeper understanding about how to configure the RoboGen simulation engine.

Note: Download the folder Tutorial to get relevant files for this exercise.

Getting Started

Perhaps you modified the simulator configuration in the Intro Exercise, but now we will look at it in a bit more depth.

Open myConf.sim.txt in the Simulation Settings tab

You are now looking at a simulator configuration file. The full documentation for defining this file is available http://robogen.org/docs/evolution-configuration/#Simulator_settings

For now it is important to notice the following properties in this file

  • scenario – this specifies the scenario the robot should be evaluated in. There are two built-in scenarios: “racing” and “chasing”, or alternatively, as you saw last time, you can define your own scenario with a small amount of JavaScript and provide the name of the js file here.
  • obstaclesConfigFile – this optionally specifies the name of another file where environmental obstacles are defined. We will not use obstacles in today’s exercises, but you should refer to http://robogen.org/docs/evolution-configuration/#Obstacles_configuration_file to see how to create obstacles.
  • startPositionConfigFile – this specifies the name of another file where starting positions and orientations are defined. The starting position configuration file contains 1 or more lines each containing the x-position, y-position, and orientation of the robot (in degrees). Each robot will be simulated once for each starting position.
  • timeStep – this specifies the time step of the physics simulator (in s) or in other words, how much real time each iteration of the simulation represents. Larger time steps will allow running faster simulations but can lead to unstable simulations. Generally, you want to use as large of a time step as possible that maintains stability (this may depend on the complexity of the robot you are simulating).
  • actuationFrequency – this specifies the frequency (in Hz) that the controller operates at. Lower frequencies may lead to less jittery gaits, but may also be less reactive. 25 Hz is a reasonable value for the hardware that we have.
  • nTimeSteps or simulationTime – these options specify the length of simulation in terms of the number of time steps or number of seconds respectively (use one or the other).
  • terrainLength and terrainWidth – these specify the dimensions of the terrain that the robot operates on (in meters). Note: that the ground is simulated as an infinite plane, so these are just used for rendering purposes.
  • terrainFriction – this specifies the coefficient of friction between the robot and the terrain
  • sensorNoiseLevel – this specifies the sensor noise level. Where the sensor noise is a Gaussian with std dev of sensorNoiseLevel * actualValue. i.e. the value given to the controller Neural Network is 
    N(a, a * s)

    where a is actual, uncorrupted sensor value and s is sensorNoiseLevel

  • motorNoiseLevel – this specifies the motor noise level. Where the motor noise is uniform in range +/- (motorNoiseLevel * actualValue)
  • capAcceleration – this is a boolean flag that when true will return a very poor fitness for any individual whose acceleration exceeds caps (setable with maxLinearAcceleration and maxAngularAcceleration parameters). Setting this to true is useful for catching solutions that exploit flaws in the physics model and end up “flying” across the screen, mostly this arises when evolving morphologies, but may also be seen when just evolving controllers.

Try changing the value of terrainFriction and running a simulation using

simpleRobot.robot.txt as the Robot description file, and myConf.sim.txt as the Configuration file

Do you notice differences in the robot’s behavior?

Try using different timeSteps and see how you can speed up the simulation, but be careful not to destabilize the simulator. Note that you should either use a fixed value of simulationTime or modify nTimeSteps appropriately to keep a fixed overall simulation time. Also note that you cannot make the frequency of simulator updates faster than the actuation frequency, and in fact the period of actuation (inverse of frequency) must be a multiple of the timeStep!

 

Previous Exercise: Brains (Controllers)Next Exercise: Configureing the evolution