search

andreadelprete / consim

GNU General Public License v3.0
14 stars 1 forks source link

bhammoud_cpp_exp_integrator #6

Closed hammoudbilal closed 4 years ago

hammoudbilal commented 4 years ago

friction cone and unilateral constraints are implemented in ExponentialSimulator::checkFrictionCone()

I only compute the second integral in case cone constraints are not violated, else there is no need to compute it. I only tested it with one contact ball drop. If I run both simulations at same sub_dt step size (1.e-4 ms) then euler simulator is faster

point_mass_profile

hammoudbilal commented 4 years ago

for memory allocation, the only time I allow it is when resizing https://github.com/andreadelprete/consim/blob/bhammoud_cpp_exp_integrator/src/simulator.cpp#L326

however, in CMakeLists.txt you have some eigen flags, https://github.com/andreadelprete/consim/blob/bhammoud_cpp_exp_integrator/CMakeLists.txt#L55 I am not sure if these flags override anything I have in the code

olimexsmart commented 4 years ago

Hi @hammoudbilal If the preprocessor directive EIGEN_RUNTIME_NO_MALLOC is defined, the function set_is_malloc_allowed becomes available (at the very end of the page)

Basically if you don't have this flag set the code would not even compile because that function would not be defined

andreadelprete commented 4 years ago

for memory allocation, the only time I allow it is when resizing https://github.com/andreadelprete/consim/blob/bhammoud_cpp_exp_integrator/src/simulator.cpp#L326

however, in CMakeLists.txt you have some eigen flags, https://github.com/andreadelprete/consim/blob/bhammoud_cpp_exp_integrator/CMakeLists.txt#L55 I am not sure if these flags override anything I have in the code

The flag is ON by default, which is what we want. However, consider that set_is_malloc_allowed only works in DEBUG.

hammoudbilal commented 4 years ago

thanks for all the tips, i didn't know it only works in debug mode. I managed to resolve most of the issues except the memory allocation part, it is taking me a bit of time, is there an efficient way of tracking down where exactly dynamic memory allocation is happening besides enable/disable memory allocation ?

andreadelprete commented 4 years ago

thanks for all the tips, i didn't know it only works in debug mode. I managed to resolve most of the issues except the memory allocation part, it is taking me a bit of time, is there an efficient way of tracking down where exactly dynamic memory allocation is happening besides enable/disable memory allocation ?

The only way I know is to use set_is_malloc_allowed and then debug you code, either with gdb (if you're hard-core) or with an IDE (if you're like me).

hammoudbilal commented 4 years ago

I managed to reduce memory allocation that was taking place significantly, however, there were still 8 lines that I couldn't avoid, these lines end with the comment "// malloc happens here"

hammoudbilal commented 4 years ago

prof

yes, we seem to have gained 10usec for the same number of integration steps, it is extremely close to the values of euler integration, even though we still carry out memory allocation in resizing matrices later !

andreadelprete commented 4 years ago

This looks reasonable. As I said above, the time taken by Exponential should be roughly the same time taken by Euler plus the time to compute the matrix exponential, which depends on the number of contacts. For 1 contact it should be about 6 us, while for 4 contacts it goes to about 100 us. In your test the difference between Euler and Exponential is only 3 us, so I guess you have only 1 contact point, and for some reasons the matrix exponential computation takes only 3 us.

I think there's still room for improvement in the Euler integrator though, because I've read that RAI, for a quadruped without contacts, can compute 1 integration step in about 5/6 us, so we should be able to get the same computation time with Euler.

hammoudbilal commented 4 years ago

you are right, this is still the same ball drop example with one possible contact. I do agree that we can optimize the euler simulator performance, there might be memory allocation happening some where, I just haven't had the time to look into it. I think I will try to setup solo12 example with tsid first with switching contact to validate further switching contacts for higher number of contacts and friction cone violations before going back to optimizing further. I will do more systematic profiling too.

andreadelprete commented 4 years ago

Sounds good to me.

On a different subject, when trying to compile your branch I get the following error

In file included from /home/student/devel/src/consim/src/simulator.cpp:12:0:
/home/student/devel/src/consim/include/consim/simulator.hpp:13:39: fatal error: consim/dynamic_algebra.hpp: No such file or directory
compilation terminated.
hammoudbilal commented 4 years ago

I am sure I renamed this to real_time_tools.hpp, anyways we can remove it for now, this is a way that Brahayam provided me with to avoid resizing matrices, I wanted to test it later, the easiest way is to remove it from CMakeLists.txt not clean I know, just did't want to lose track of this file