You are here: Foswiki>RoboticsWeb Web>ODE_profile (26 Jun 2013, wangj22@RPI.EDU)Edit Attach

Profiling of Gazebo and ODE

The computer system has become so complex which makes it difficult to determine what code consumes the processor time. What is most interesting for us is what code takes an excessive amount of processor time. The tool using to do profiling are very essential. They are able to evaluate how well programs performs on new architecture. They are able to find out how well the instruction scheduling algorithm performs and they can also analyze programs and identify critical sections of code. -- (ATOM, PLDI '94)

Gazebo is a 3D dynamics simulator that is designed to reproduce the dynamic environments a robot may encounter. ODE (Open Dynamics Engine) was created by Russel Smith, which is a widely used physics engine. Numerous joints, collision detection, mass and rotational functions and much geometry are included in this engine. Gazebo utilizes these features by providing a layer of abstraction situated between ODE and Gazebo models. Bullet physics engine is another physics engine Gazebo will be using. The rendering tool in Gazebo is Ogre. Gazebo has also incorporated some of ROS (Robot Operating System) stack. Our work focus on profiling of Gazebo using OProfile which is a system-side profiler for Linux systems to do profiling of four benchmark simulations in Gazebo environment. We have also added a timing library to ODE quickstep code from which we are able to know exactly how many cpu cycles each function in the solver costs. We then convert the cpu cycles to the time the functions consume. Same four benchmark simulation are used for analyzing timing of ODE solver.

Profiling of Gazebo and ODE
In our work, two ways were used to do profiling of gazebo: callgrind and OProfile.
  • Profiling of Gazebo using Callgrind
  • We can see the percentage of time that each function takes during a simulation on the box.
  • Profiling of Gazebo using OProfile
  • OProfile analyzes the frequency and duration of a function called. The following graph is plotted based on the result from OProfile.

    profiling of gazebo
  • Profiling result of Gazebo using OProfile
  • Profiling of Gazebo -- We used a benchmark simulation: Atlas picking up drill to do the profiling of gazebo. The pie graph shows the percentage of time ODE and rendering (OGRE) consumed during that simulation. From the profiling results, ODE and rendering took 20.7% and 8.8% of the total time, respectively. We know that for a dynamic simulator, the parts that should cost most of the computation time are the solver and rendering. However, we can see the solver and rendering together only cost 29.5% of total time which means there are still a lot of redundant parts in Gazebo we can take out to reduce the computation time. We have also noticed there is a program called malloc.c that cost more than 7% of the total time. It is used to allocate and free memory. This program worth considering optimization since allocating memory shouldn't cost so much time.

    To profile ODE, we added our own timing library using a standard counter: rdtsc (Real Time-Stamp Counter) to ODE quickstep code to analyze the timing information.
    profiling of ODE
  • Profiling of ODE using our own timing library
  • Profiling of ODE -- The same benchmark simulation: Atlas picking up drill is used to analyze the timing of the functions in ODE. The timer report on the left shows the timing result. The left column displays the main functions in ODE. The second collum shows the time each function costs during the current time step and the third, fourth and fifth columns are the maximum, minimum and standard deviation of the time each function cost during the whole simulation, respectively. CPU cycles is used to calculate the time cost. And the last column shows the CPU cycles each function cost for only one constraint on average. The "start pgs rows" is the function that is solving LCP problem and the result reveals it consumed 88.2% of the total time within this time step which is quite reasonable. And we have also noticed that even the maximum time of solving LCP problem within one time step is only 2.49 miliseconds which is quite a promising result.
    -- JieleiWang - 2013-05-26
    Topic attachments
    I Attachment Action Size Date Who Comment
    callgrind.pngpng callgrind.png manage 437 K 07 Jun 2013 - 15:03 UnknownUser  
    gazebo_new2.pngpng gazebo_new2.png manage 3 K 07 Jun 2013 - 17:17 UnknownUser  
    oprofile.pngpng oprofile.png manage 312 K 07 Jun 2013 - 16:48 UnknownUser  
    profiling_gazebo.pngpng profiling_gazebo.png manage 14 K 07 Jun 2013 - 17:46 UnknownUser  
    timer.pngpng timer.png manage 67 K 07 Jun 2013 - 19:50 UnknownUser  
    Topic revision: r13 - 26 Jun 2013, wangj22@RPI.EDU
    This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
    Ideas, requests, problems regarding Foswiki? Send feedback