Simulation Crashes when Objects Collide

[Hannah]

Hi,

I am working on creating a simulation of a small tracked vehicle that I designed in SolidWorks. 

I followed this example (https://github.com/projectchrono/chrono/blob/develop/src/demos/irrlicht/demo_IRR_tracks.cpp) but instead of creating the parts of the vehicle (truss, wheels, etc) from .obj files and assigning properties and links, I just loaded the vehicle (without the tracks) from the Solidworks Chrono::Engine Add-On output files and then assigned materials and attached motor links. I then assembled the track from .obj files of my shoe and shoe collision shape just as in the example.

The issue that I am running into is whenever my track comes in contact with another object, the simulation crashes. When I comment out the track portion, however, my bare vehicle is able to move around and properly collides with the floor and obstacles.

I saw on a previous post that certain parameters should be scaled with the size of the vehicle (my vehicle is less than 1 cubic meter and weighs 20 kg).

I have tried simulation time steps between 0.005 and 0.03. I am currently using the PSOR solver. (I tried the BARZILAIBORWEIN solver, but then none of my collisions seemed to work.)

I have tried collision safe margins between 0.00001 and 0.001.

I have tried collision envelopes between 0.0001 and 0.005.

I should also say that when I run the demo_IRR_tracks.exe from my chrono_build directory, this simulation also crashes right away.

I have a Windows laptop. I uninstalled and reinstalled Chrono about three weeks ago, so I believe my versions are up to date (Chrono version 5.0.0, Irrlicht version 1.8.4). I built the PyChrono model using SWIG and these instructions (http://api.projectchrono.org/development/module_python_installation.html). I do not have any other versions of Bullet on my computer.

Please let me know if you need more information and thank you for your help.

Hannah

[Hannah]

I will post my workaround here in case anyone else has a similar experience.

I was not able to get importing from .obj files working, so I added the complete vehicle, including the full tracks, from SolidWorks at once. I tried a few different strategies before this to more closely emulate the IRR Tracks demo, but as noted here <http://api.projectchrono.org/tutorial_demo_pyparser.html>, "currently no multiple ChPythonEngine objects can be used simultaneously".

I had to change the SolidWorks file a bit to ensure that I only had fixed, coincident, or concentric mates (as mentioned here: https://projectchrono.org/forum/?place=msg%2Fprojectchrono%2F5jwSW8R_BJ0%2F98IbANCBCAAJ) and that the track shoes could still move around the sprockets. I also got rid of all intersections between parts or subsystems. SolidWorks has a nice Interference Detection tool that helped with this.

One issue that I ran into was an error "Cannot perform runtime binding on a null reference" when I tried to create the .py file from SolidWorks. I was not able to triage exactly why I was getting this error. I think it went away after I cleaned up some constraints.

I am still having an issue where my concentric mates between the shoes seem to be violated when the sprocket moves. I tried to add collisions with the pins but I wasn't able to create a collision shape that was a cylinder with a hole in the middle. I will update this post again if I figure out this last issue.

[Radu Serban]

Hi Hannah,

Sorry for the delay in getting back to you.

I personally do not use the SolidWorks plugin, but it seems to me that the first thing to do is figure out the issue you say you are having simply running demo_IRR_tracks.  It sounds like that points to an underlying issue that may explain other problems you could have down the line.

You mention you are building the C++ code from sources.  Could you please rebuild it in Debug mode, run that demo through the debugger and provide us with more information on the crash (start with a call trace at a minimum).   Also, unless you have a strong reason not to, could you maybe switch to using the development version of Chrono (checkout the git branch 'develop')?  The code is continuously evolving and there were already some significant changes since the 5.0 release back in February.  It is much easier for us to help with the current code.

Finally, just for completeness, could you please indicate the compiler you use (I assume Visual Studio, but what version) as well as the version of Eigen you are using?

Best,
--Radu

--
You received this message because you are subscribed to the Google Groups "ProjectChrono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to projectchron...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/4632a1c2-4384-4de9-87ec-ddadb7007f1a%40googlegroups.com.

[Hannah]

Hi Radu,

Thanks for the response. Sorry for my delay, this is my first time using the Debug Configuration of Visual Studio.

I am using Visual Studio 2017-Version 15.8.22. (If I remember correctly I ran into some trouble building Chrono the first time with Visual Studio 2019, so I have been using 2017 ever since.) I am using Eigen 3.3.7.

Just an update on the method that I mentioned in the follow-up post (importing everything from SolidWorks and using PSOR): if I use a high enough number of max solver iterations (1000+), the revolute joints between track shoes are not broken. However, the simulation is extremely slow and still has some unexpected behavior that I am trying to figure out. I mentioned that I was trying to create collision objects so that the track links could be physically linked together, but I ended up removing this and suppressing all collisions between track shoes using a collision family to reduce the necessary computations. I also mentioned not being able to create a collision object that was a hollow cylinder so that a pin could fit in it. I ended up being able to do this by creating a cylinder, assigning it as a collision shape, and then adding the hole after the fact. I doubt that this is a recommended strategy and like I said, I deleted all of these anyways to speed things up.

Per your suggestion, I downloaded and built Chrono from the Develop branch. I didn't see a difference in performance for my code so I went about just trying to figure out why demo_IRR_tracks wasn't working using Debug Configuration as you recommended.

For anyone else new to Visual Studio Debugging, here are some of the things I learned:

The first issue I ran into using Debug config was an error message that said "Unable to start program 'path\ALL_BUILD'. Access is denied" when I tried to run the debugger. This was an easy fix, I just had to right click on myexe and click Set as StartUp Project. The next issue I ran into was that the symbols weren't being loaded for ChronoEngine, ChronoEngine_irrlicht, and Irrlicht. This manifested itself in the form of a "Unhandled exception at location :Microsoft C++ exception: std::length_error at memory location" early in the code (i.e. I knew this line wasn't an actual issue because the code had run past this point in Release config). The issue was that the variable "my_system" wasn't being created correctly (because the Chrono symbols weren't loaded) so when the code tried to use "my_system", it raised this error. Even though the.dlls files I needed seem to be copied into my Debug folder, these files did not work as is, even if I manually selected the corresponding .pdb files from the module window. I saw here (http://api.projectchrono.org/tutorial_install_project.html) and elsewhere that I have to copy the .dll files myself. I copied the .dlls for these three from chrono_build/bin/Debug and replaced the ones that had been created in this project's Debug folder. It took me a while to realize that these .dll files were being overwritten whenever I rebuilt my solution. So I had to copy them over after rebuilding but before running the debugger.

Here are the last warning and error that I got running demo_IRR_tracks in Debug configuration with the develop branch version of Chrono: 

warning btCollisionDispatcher::needsCollision: static-static collision!
Assertion failed: ptIndex >= 0, file mypath\chrono\src\chrono\collision\bullet\BulletCollision\CollisionShapes\btConvexShape.cpp, line 108

Please let me know if you need more info than this.

Hannah

To unsubscribe from this group and stop receiving emails from it, send an email to projec...@googlegroups.com.

[Radu Serban]

Hi Hannah,

See my responses interspersed below in blue.

--Radu

On 6/5/2020 2:54 AM, h3279...@gmail.com wrote:

Hi Radu,

Thanks for the response. Sorry for my delay, this is my first time using the Debug Configuration of Visual Studio.

I am using Visual Studio 2017-Version 15.8.22. (If I remember correctly I ran into some trouble building Chrono the first time with Visual Studio 2019, so I have been using 2017 ever since.) I am using Eigen 3.3.7.

This is quite odd.  I have been using VS 2019 for quite a while now without any problems.  Could you please investigate this further and let me know what kind of trouble you have with using VS 2019?

Just an update on the method that I mentioned in the follow-up post (importing everything from SolidWorks and using PSOR): if I use a high enough number of max solver iterations (1000+), the revolute joints between track shoes are not broken. However, the simulation is extremely slow and still has some unexpected behavior that I am trying to figure out. I mentioned that I was trying to create collision objects so that the track links could be physically linked together, but I ended up removing this and suppressing all collisions between track shoes using a collision family to reduce the necessary computations. I also mentioned not being able to create a collision object that was a hollow cylinder so that a pin could fit in it. I ended up being able to do this by creating a cylinder, assigning it as a collision shape, and then adding the hole after the fact. I doubt that this is a recommended strategy and like I said, I deleted all of these anyways to speed things up.

Depending on how your collision shapes are defined (size and location) it is indeed important to ignore collisions between adjacent track shoes.  Using collision families is one way of doing that.  But you may want to revisit this and make sure that collision shapes from adjacent track show do not in fact overlap.   You can look at how that is done in Chrono::Vehicle (but be warned that this is going down in the guts of the code and is a bit more complicated to understand).

I am not quite sure I understand what you mean by "adding the hole after the fact".  Could you please elaborate?  Also, where/why do you need this type of interaction?  There may be simpler ways to deal with this (e.g. performing your own custom collision detection)

Per your suggestion, I downloaded and built Chrono from the Develop branch. I didn't see a difference in performance for my code so I went about just trying to figure out why demo_IRR_tracks wasn't working using Debug Configuration as you recommended.

I finally figured out what the issue was with this particular demo:  a low-level issue with the convex decomposition algorithm used when a non-convex mesh is set as collision shape.  I introduced this bug a while ago when I had to obsolete one of the options we had for convex decomposition.  For some reason, I missed the ensuing problem with demo_IRR_tracks.

I pushed a fix; please pull the latest code in the develop branch.

Having said that, I recommend you consider simpler collision shapes (as much as possible) in your own models.  In particular, collision models for track shoes can easily be constructed from primitive shapes (boxes, cylinders, maybe convex hulls is really needed).  That will give you more robust and performant code.

For anyone else new to Visual Studio Debugging, here are some of the things I learned:

The first issue I ran into using Debug config was an error message that said "Unable to start program 'path\ALL_BUILD'. Access is denied" when I tried to run the debugger. This was an easy fix, I just had to right click on myexe and click Set as StartUp Project. The next issue I ran into was that the symbols weren't being loaded for ChronoEngine, ChronoEngine_irrlicht, and Irrlicht. This manifested itself in the form of a "Unhandled exception at location :Microsoft C++ exception: std::length_error at memory location" early in the code (i.e. I knew this line wasn't an actual issue because the code had run past this point in Release config). The issue was that the variable "my_system" wasn't being created correctly (because the Chrono symbols weren't loaded) so when the code tried to use "my_system", it raised this error. Even though the.dlls files I needed seem to be copied into my Debug folder, these files did not work as is, even if I manually selected the corresponding .pdb files from the module window. I saw here (http://api.projectchrono.org/tutorial_install_project.html) and elsewhere that I have to copy the .dll files myself. I copied the .dlls for these three from chrono_build/bin/Debug and replaced the ones that had been created in this project's Debug folder. It took me a while to realize that these .dll files were being overwritten whenever I rebuilt my solution. So I had to copy them over after rebuilding but before running the debugger.

This is indeed what needs to be done in order to debug an external project that depends on Chrono (and be able to step through the Chrono code).  Unfortunately, we couldn't come up with a simpler workflow for this.

Having said that, for this particular case (where you wanted to debug one of the Chrono demos, and not your own project), you could have used the debugger on the Chrono solution.  No need for copying DLLs in that case.

Thanks,
Radu

To unsubscribe from this group and stop receiving emails from it, send an email to projectchron...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/2ac3712b-4a16-45b7-9de2-e530233044a6o%40googlegroups.com.