SL Simulation
Introduction
SL is a dynamic simulator and the aim in using this simulation is to realize and test biped locomotion algorithms and analyze the corresponding results. SL is created by Stefan Schaal, University of Southern California/USA.
SL allows creating complex rigid-body dynamic simulations easily and in a short time so that the biped robot algorithms can be tested in simulation before trying them on the actual robot and then the algorithms can be used in a real-time robotics setup. Both in simulation and real-time robot setup, SL allows to collect related data into a file after simulating the robot in simulation or after testing the algorithms in real robot. SL can also be used just for creating graphics animations.
SL is divided into three software components such as the generic code that is shared by the actual robot and the simulation; the robot specific code and the simulation specific code. The simulation specific code has all the components for OpenGL graphics simulations and mimics the robot multi-processor environment in simple C code.
SL Simulation offers plenty of different development features to the user such as:
By these properties, SL can be used for applications in robot control research and education, almost arbitrary rigid body dynamics simulations, in particular humanoid or animal simulations, studies of motor control form the viewpoint of computational neuroscience, computer graphics with physical animations, studies of motor learning, and behavioural motor control studies from the viewpoint of experimental psychology, kinesiology, and motor rehabilitation.
SL has a modular software structure that helps keeping the programs more transparent. SL was programmed with a multiprocessor environment in mind, where inter-processor communication is accomplished through a shared memory structure. Fig. 1 shows the code structure of SL.

Figure 1: The SL code structure
The elements in Fig. 1 have the following meaning:
- Shared Memory: Certain variable structures that reside in physically shared memory are defined as shared memory structures. In simulation, the memory is simply allocated by normal memory allocation functions. Each processor can read/write from/to shared memory.
- Motor Servo: This processor or software module handles the low-level input/output with the robot or simulation, and implements the basic feedback control loops. The processor runs a servo at a user-specified frequency that does reading of desired position, velocity, and feedforward commands, computing of PD, PID, PDFF, or PIDFF1 motor commands from the desired quantities and the current state of the robot and sending the motor commands to the robot or simulation.
- Task Servo: This processor or software module allows switching between different motor tasks. The general goal of a motor task is to create appropriate desired position, velocity, and feedforward commands to accomplish a user specified motor behavior, and to send these quantities to the motor servo. From the view point of control theory, the task servo implements the control law, although the PD or PID part of the control law is usually taken over by the motor servo. Negative feedback control can be taken over by the Task Servo, too, by sending the current state of the robot as desired state to the motor servo, which effectively cancels the PD or PID contribution of the motor servo and only leaves the feedforward command to control the robot (Fig. 2).
- Vision Servo: The vision servo collects data from camera systems and makes the data available in shared memory. It’s assumed that all visual information comes in form of the centroids of color blobs. Thus, the vision servo converts two-dimensional image based coordinates of the centroids, to 3D information and provides these quantities at a rate of 60Hz to the shared memory. In simulation, the centroid information can be generated by user specific functions and sent to the Vision Servo as simulated camera.
Figure 2: Control solely using the Task Servo.
SL Simulation is used under Linux and Machintosh Computers. The visual appearance of the simulation is like in Fig. 3. The User Interface (UI) of SL has commands that allow you to control the simulation. There are some functions that can be used from UI command line. Also, user can define some functions and there are some more functions that are only available for the programmer.
To sum up, SL Simulation is a dynamic simulator that allows you to use a robot model that you can change the robot specific parameters and simulation conditions, implement gait trajectories and collect data from the simulation. After collecting the data from the simulation, it can be analyzed and be plotted using MATLAB or any other relevant programme.

Figure 3: SL Simulation
Simulation Results
Frontal Plane Video

Sagittal Plane Video

Simulation & Results
The aim of the simulation is to analyze the effects of low-level controller parameters and frontal plane desired gait trajectory parameters on the resultant GRF. Our aim is to tune the parameters so that we will analyze the landing impact and observe the effects of parameters to reach a smooth transition between two phases of bipedal locomotion, namely, single-support phase and double-support phase. So under different parameter constraints, the resultant GRF is analyzed and comparison is given.
SL is used to realize the dynamic simulation of biped locomotion. The robot model used in this simulator is 7-link, 10 DOFs robot. The link structure of the robot is given in Fig. 4. The simulation is done under the assumption that the movement of the robot is independent in frontal and sagittal planes. In frontal plane, the total DOFs is 4 and in sagittal plane, the total DOFs is 6. Total height of the robot is 1.325m. The walking cycle of the robot is 2 seconds and the reference input data frequency is 100 datas/second.

Figure 4: Link structure of the biped robot as used in the SL simulation.
After collecting data from simulation results, the analysis of smooth transition and landing impact is done and MATLAB is used as a graphical tool to plot the results of simulation.
The snapshots of walking simulation both in frontal and sagittal planes are given in Fig. 5.
The analysis of parametric change is done considering the effects of controller gain parameters on GRF and ZMP and the simulation results corresponding to different gain values (high gain-low gain) is analyzed. Also, the effects of frontal gait Inverted Pendulum Model parameters such as change in the lean angle and change in the double-support & single-support time ratio on GRF and ZMP is analyzed.
The simulation results showing GRF for default values used for controller gain parameters (Table 1) and Inverted Pendulum Model is given in Figs. 6, respectively.


a) Frontal Plane


b) Sagittal Plane
Figure 5: Experimental Results using SL Simulation

Figure 6: GRF Simulation Results for the default values of controller gain and Inverted Pendulum Model Parameters
Table 1:
|
Joint Angles |
P |
|
θlhs (Left Hip Sagittal Joint Angle) |
500 |
|
θlks (Left Knee Sagittal Joint Angle) |
500 |
|
θlas (Left Ankle Sagittal Joint Angle) |
200 |
|
θrhs (Right Hip Sagittal Joint Angle) |
500 |
|
θrks (Right Knee Sagittal Joint Angle) |
500 |
|
θras (Right Ankle Sagittal Joint Angle) |
200 |
|
θlhf (Left Hip Frontal Joint Angle) |
500 |
|
θlaf (Left Ankle Frontal Joint Angle) |
200 |
|
θrhf (Right Hip Frontal Joint Angle) |
500 |
|
θraf (Right Ankle Frontal Joint Angle) |
200 |