Muscle NP (contact cable) integration test is failing

[brtietz]

[==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [----------] 1 test from MuscleNPTest [ RUN ] MuscleNPTest.MuscleNPMomentum btTransform: origin = btVector3( 3.53553, 6, 3.53553 ); rotation = btQuaternion( -0.5, 0, -0.5, 0.707107 ) SimView::run(10000) /home/brian/src/NTRTmaster/test_integration/MuscleNP/MuscleNP_test.cpp:108: Failure Value of: momentumEnd[0] Actual: 0.86466503 Expected: momentumStart[0] Which is: 1 /home/brian/src/NTRTmaster/test_integration/MuscleNP/MuscleNP_test.cpp:109: Failure The difference between momentumStart[1] and momentumEnd[1] is 0.041891045606052391, which exceeds 1E-10, where momentumStart[1] evaluates to 0, momentumEnd[1] evaluates to -0.041891045606052391, and 1E-10 evaluates to 1e-10. /home/brian/src/NTRTmaster/test_integration/MuscleNP/MuscleNP_test.cpp:110: Failure Value of: momentumEnd[2] Actual: 0.83705044 Expected: momentumStart[2] Which is: 1 [ FAILED ] MuscleNPTest.MuscleNPMomentum (505 ms) [----------] 1 test from MuscleNPTest (505 ms total)

[----------] Global test environment tear-down [==========] 1 test from 1 test case ran. (505 ms total) [ PASSED ] 0 tests. [ FAILED ] 1 test, listed below: [ FAILED ] MuscleNPTest.MuscleNPMomentum

1 FAILED TEST

[brtietz]

Related: dev/btietz/muscleNPTests now falls off the rigid cylinder, as opposed to being draggable as in prior demo videos: https://www.youtube.com/watch?v=EQ9w5lJLh8Y

[brtietz]

The change in mass of tgBox means the two boxes collide before 10 seconds is up. This violates conservation of momentum (since the default restitution for boxes is 0.2), and thus fails the test.

There are a couple of solutions that preserve the integrity of test while changing it to a pass, including reducing the time, reducing the initial velocity, and reducing the mass. Preferences?

[apsabelhaus]

Brian - thanks for looking into this.

I'm not sure what's up with muscleNPTests. I do see how the cables seem to clip through the bar though. The only things I can think of is that this would relate to are either (a) our refactoring of the spring cable actuators, like how we use tgBasicActuator in the YAML files, or (b) if any of my new code in tgBulletRenderer.cpp (https://github.com/NASA-Tensegrity-Robotics-Toolkit/NTRTsim/blob/master/src/core/tgBulletRenderer.cpp) is somehow being called instead of your original code. I put some new stuff in there for the compression spring actuators I built for the ForcePlateModel, which is a whole different function and shouldn't be called unless your cables are now erroneously inheriting from the compression spring actuator instead of the spring cable actuator. That seems unlikely, but it's worth mentioning.

About the tgBox test - by "reducing the time", do you mean making it so that the boxes no longer collide? Did they collide in an earlier test? If not, then let's make it so they won't collide in the future. Maybe reducing the initial velocity? Any of those ideas seem like they'll work.

[brtietz]

I did some more digging, and the youtube video actually pre-dates this test (and may violate it). So I won't worry about restoring that behavior.

Thanks for the input - I've reduced the momentum to avoid the collision.

[brtietz]

Closed with MR 208