Member does not belong to island Error

[Syntax]

I have the following error: Member does not belong to island; cannot remove.

I have two robots that are each made up of a compound body driven by 6 wheels that are constrained to the compound body with revolute joints. Any time the robots start applying any sizable amount of force and then stop, the error appears. The compound bodies and the wheels are set to always active. All of the objects have been added to the same space. I tried placing the space.Update(); in a try/catch but the physics seems to just get more and more unstable as the error generates itself over and over again.

Any help with this would be very much appreciated. Thanks!

[Norbo]

I'll probably need a repro case to figure this one out. Also, what version is this happening in?

[Syntax]

I'm using BEPU version 0.15.2.0.

I tried recreating the results in a simplified solution with no luck. After doing some digging I did find some interesting information that causes the error. Perhaps this will help. The error gets thrown in SimulationIsland.Remove at line 137 in SimulationIsland.cs. It is called by DeactivationManager.TryToSplit at line 437 in DeactivationManager.cs. searchedMembers1 has 7 items at the time when it enters the for loop in DeactivationManager. One for the compound body of the robot and 6 for the wheels (and the wheels are all from the same robot). When it reaches the 5th item (i=4) it passes the 4th wheel (whose parameters are set up exactly like the other wheels) into the Remove() function and it crashes. Hope this helps.

[Norbo]

What is triggering the simulation island split? Is a collision pair being removed, or are the wheel joints being removed? If it's a collision pair, is the collision pair between a wheel and the body, or is it touching something else?

I've run into these sorts of bugs before, though I thought I squished them all before v0.15.2. Tracking them down is usually a fairly horrible experience

You may want to try upgrading to the latest development version (http://bepuphysics.codeplex.com/SourceC ... evelopment). It's gone through some significant refactoring in the collision handling system which may have fixed it, though it may have also introduced other unknown bugs.

[Syntax]

Ok, the newest code download did not work.

I've tracked it down to Solver.Remove at line 166 in Solver.cs. the "item" has two connected members and they are both the compound bodies of the robot bases. Is this what you were asking about? I didn't mention this before, but the wheels and the robot base are in collision groups that have a no broad phase rule on them. So the wheels can only collide with the floor and cannot collide with the robot bases.

Here is the stack flow once from when i call Space.Update() to when it crashes:

at BEPUphysics.DeactivationManagement.SimulationIsland.Remove(ISimulationIslandMember member) in C:\Users\DBS\Downloads\bepuphysics-1f8059199527\forks_rossnordby_development_1f8059199527\BEPUphysics\DeactivationManagement\SimulationIsland.cs:line 160
at BEPUphysics.DeactivationManagement.DeactivationManager.TryToSplit(ISimulationIslandMember member1, ISimulationIslandMember member2) in C:\Users\DBS\Downloads\bepuphysics-1f8059199527\forks_rossnordby_development_1f8059199527\BEPUphysics\DeactivationManagement\DeactivationManager.cs:line 437
at BEPUphysics.DeactivationManagement.DeactivationManager.Remove(ISimulationIslandConnection connection) in C:\Users\DBS\Downloads\bepuphysics-1f8059199527\forks_rossnordby_development_1f8059199527\BEPUphysics\DeactivationManagement\DeactivationManager.cs:line 330
at BEPUphysics.SolverSystems.Solver.Remove(SolverUpdateable item) in C:\Users\DBS\Downloads\bepuphysics-1f8059199527\forks_rossnordby_development_1f8059199527\BEPUphysics\SolverSystems\Solver.cs:line 105
at BEPUphysics.NarrowPhaseSystems.NarrowPhase.FlushGeneratedSolverUpdateables(Solver solver) in C:\Users\DBS\Downloads\bepuphysics-1f8059199527\forks_rossnordby_development_1f8059199527\BEPUphysics\NarrowPhaseSystems\NarrowPhase.cs:line 351
at BEPUphysics.Space.DoTimeStep() in C:\Users\DBS\Downloads\bepuphysics-1f8059199527\forks_rossnordby_development_1f8059199527\BEPUphysics\Space.cs:line 399
at BEPUphysics.Space.Update() in C:\Users\DBS\Downloads\bepuphysics-1f8059199527\forks_rossnordby_development_1f8059199527\BEPUphysics\Space.cs:line 414

[Norbo]

Unfortunately, I haven't been able to replicate the problem. It's difficult to know what exact conditions are needed to trigger it since that simulation island error is sort of a catch-all for when bookkeeping gets messed up somewhere else in the engine.

I'll try a few more things, but it's very likely that I won't be able to fix it unless I can reproduce it and catch it in the act. Any additional information or context could help.

[Syntax]

Finally had time to come back to this issue and I think I found what it was that I did wrong. I think that I messed up in my sequence of making the robot. I created the compound body for the structure of the robot but didn't add it to the space immediately afterward. Instead, I went ahead and set up the wheels and their joints to the compound body. Then I added the wheels to the space, then the revolute joints (the joints constrained the wheels to the robot structure), and last I added the robot structure. The result of this was that some of the wheels, while constrained to the robot structure, were sitting as their own simulation islands. The strange thing is that depending on the number of other members in the space or the number of other simulations islands, each wheel may or may not be added to the same simulation island as it's robot. For example, I could create 3 exact copies of a robot that had 4 wheels and on the first robot, all the wheels would be in the same simulation island as the robot. On the second robot, the front two wheels would share a simulation island with the robot and the other two wheels would have their own individual simulation islands. Each robot would have a different combination of wheels sharing the simulation island with their robot. Then if I add one random sphere to the world, it would be its own simulation island, which is fine, but the combinations of wheels sharing simulation islands with the robot would have changed so that, for example, the first robot now had only one wheel sharing a simulation island as it's robot and the other three had their own individual islands.

I say all of that to maybe help you find the bug. If you need any more information, just let me know. The way that I ended up fixing it from my end was by adding the robot structure to the space, then adding the revolute joint, then adding the wheel itself. Now all of the robots that I drop into the space have all their wheels in the same simulation island as their robot structure.

When I fixed it, I was using the May 18th build found here: http://bepuphysics.codeplex.com/SourceC ... c088faecf9

[Norbo]

Thanks for the information, I am now able to reproduce it. I'll try to fix it for the next version.

[Norbo]

It should be fixed now: http://bepuphysics.codeplex.com/SourceC ... evelopment