- To gain a deeper understanding about how to configure the RoboGen simulation engine.
Once again, you should click on the “Advanced” tab to be able to modify files and start custom evolutionary experiments or visualize your robots.
Tip: if the software is having some problem, try refreshing the page.
Important: Remember, all data is being saved to a virtual filesystem within your web browser. If you want to save anything for later use, be sure to download it to your home directory!
Perhaps you modified the simulator configuration in the Intro Exercise, but now we will look at it in a bit more depth.
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
- 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 a simulation in terms of 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
examples/simpleRobot.txt as the Robot description file, and
myConf.txt as the Configuration file
Do you notice differences in the robots 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!