MuscleNP #99
MuscleNP #99
Conversation
…ssipation term further, it appears to add energy
… still need to be addressed
|
Brian, vytas On Nov 18, 2014, at 12:48 PM, Brian Mirletz notifications@github.com wrote:
Vytas SunSpiral Stinger Ghaffarian Technologies I will not tiptoe cautiously through life only to |
|
Brian, |
Alexander Xydes On Tue, Nov 18, 2014 at 5:27 PM, Perry Bhandal notifications@github.com
|
|
@PerryBhandal I think the most likely errors are covered in issues #100 and #101. The other big question I'd like input on is whether or not we include btQuickProfiler by default. The effects of that are pretty obvious if you run any app. Finally - to make my vague references to "special cases" more clear, I'd appreciate some help brainstorming a robust way to maintain and place contacts. Right now the method I'm using vigorously deletes existing anchors if the permanent anchors cross the string, limiting our ability to wrap around objects (see this situation, where I move the rod slightly to the left of the last video I sent around: http://youtu.be/Wyl2-cowmN0). I don't expect a typical tensegrity to encounter this situation, but we can do a lot more if the code can handle it. Integrating with Corde would also help handle this, but is more effort that I have time for right now. |
…eightSensor class in dev/atil
…, update controls
…raspine, change contact threshold to value for double precision
… integration tests, testing library for tgUtil (no real tests)
…n, use arbitrary when that one doesn't work
|
I'm ready to merge this in. If anyone has further review they would like to do, or would rather wait until we transition to double precision for a little while longer, let me know by the morning. |
…make it more robust
Merging in MuscleNP, new muscle constructors and examples. This closes #96 Note the following about this merge: 1) The simulator is now running at double precision by default. We recommend migrating, as it increases simulator accuracy for a minor increase in memory usage (see: #100). In order to migrate you need to do one of the following: a) delete your env and build directories and re-run setup.sh, followed by a clean build (bin/build.sh) b) Rebuild bullet at double precision (cd to the bullet directory: env/build/bullet, run "ccmake .", turn double precision on, generate new cmake files, run make install), then do the same thing to NTRT (ccmake build, toggle option on and generate, run bin/build.sh) 2) The order of the parameters in tgBaseString::config has changed. The third parameter is now pretension, in units of force, to allow pretension in cables without a controller. Rotation has been moved to the end, history is fourth, and everything else has been left unchanged. If your code was in master, I've updated it for you. If you were just specifying stiffness and damping you don't need to do anything, but otherwise check tgBaseString::config and make sure everything is as you expect. There's a new example of the 3 bar prism (3_prism_no_control) showing how to use this new pretension parameter. Finally - there's a new cable model in dev - MuscleNP, which includes contact dynamics. There's several examples of its use in my dev directory (btietz), the most interesting of which is TCContact, which demonstrates their use on hilly terrain. Changing your models to use contact dynamics is just a matter of using dev/tgMultiPointStringInfo instead of tgLinearStringInfo, so it should be easy to play with. Its still in beta, so let me know if you find bugs (or post them to github).
This is a big merge. Here's a summary:
Some important notes to start:
You'll need to rebuild bullet for this and do a clean build of your repository, as its much more stable with double precision. I'll make a separate thread where we can discuss that in more depth and I can post the results. Rebuilding also includes some additional modifications to tgDemoApplicaiton in the patching process that allow us to render the new strings properly and avoid a serious memory leak.
There have been some additional changes to the builder tools in tgUtil and tgSphereInfo that have global implications as well as some lower level changes that shouldn't be noticeable at a high level (btRigidBodies have been changed to btCollisionObjects). These need to be verified with unit tests (another forthcoming issue).
Now, what's all here?
Oops - I had some local merge issues and dragged along the Corde commits from before June. These are pretty harmless and boring (just a simple text printout at this point) so I'm not opposed to merging them. Actually merging in the full Corde branch will be more interesting.
I've gone through and dropped profiling information for btQuickProfiler in a few relevant places so I can see runtimes. We should consider adding the BT_NO_PROFILE flag to our cmake build so these can be turned off if that's desirable.
Within core:
a) muscleAnchor has become a much more fully featured class, as it has to store data for multiple types of anchors, yet still be the same object for rendering and other purposes. I'm open to making a base class and doing some casting if people prefer that to the booleans I'm using right now.
b) Muscle2P stores its data a little differently so that Muscle2P and MuscleNP can both be rendered by the same funcitons
c) Some fixes for the ground class
d) The world is equipped to handle bullet's ghost objects
For tgcreator:
a) Anything involving a rigid body has been changed slightly to accommodate storing a btCollisionObject instead and getting the rigid body with a cast in the getRigidBody() funciton
b) tgUtil's getQuaternionBetween function returns negative identity instead of the result of a random vector. @ryan1248 suggested this is insufficient for all cases, but I need to see the test it fails.
c) tgSphereInfo had a corrective sign change so the string actually appears on the outside of the sphere.
Finally MuscleNP and associated classes
a) MuscleNP is a child class of Muscle2P, since the controller interface is identical. The calculateAndApplyForce function is a lot beefier, since it also has to handle all of the bullet contact information. This is split between four private functions, which I can explain in detail if you have questions - hopefully the documentation suffices.
b) tgMultiPointStringInfo constructs a tgLinearString with a MuscleNP.
c) There are two ghost object construction classes here as well. They are no longer used in this branch, but I believe DuCTT uses them in the DuCTT branch
d) The demo classes are in my dev folder: muscleNPTests (two in one with conditional compiles), muscleNPEnergy (almost an integration test), sphereFeet (repurposed superball), and tetraCollisions)
There are still a few cases where MuscleNP blows up, which mostly have to do with figuring out the correct order for new contacts, but they're not common in tensegrity applications. The methods used here have the potential to improve Corde's contact dynamics with some additional work, but runtime may need to be addressed in that case.