Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change to Double Precision? #100

Closed
brtietz opened this issue Nov 18, 2014 · 3 comments
Closed

Change to Double Precision? #100

brtietz opened this issue Nov 18, 2014 · 3 comments
Assignees

Comments

@brtietz
Copy link
Contributor

brtietz commented Nov 18, 2014

Prior to merging in #99, we need to determine if double precision breaks any of the validation results we have previously published. MuscleNP functions better with it (more stable) and the results from 6WCSCM I have tested move slightly further. A comparison to the ICRA 2015 results, as well as other validation results as available is required before making the change.

@brtietz brtietz self-assigned this Nov 18, 2014
@brtietz
Copy link
Contributor Author

brtietz commented Nov 18, 2014

First data point, memory. A four segment tetraspine (18 strings) requires:
Single precision: 13.7 MB
Double precision: 17.2 MB

Runtime is unchanged, both simulate 10 seconds of time at 500 Hz in ~5.2 real seconds (without graphics).

@brtietz
Copy link
Contributor Author

brtietz commented Nov 19, 2014

I re-ran the ICRA 2015 paper trials on the MuscleNP branch and observed the following:

  1. The changes to tgCreator in the MuscleNP branch are the most significant - Errors change by between 3 and 11 percentage points in both directions. The key "maximum tension error" numbers we reported increased to 14.4% (from 11.5%). Length data is the same, some worse, some much better. These could probably be tuned again with changes in control and merit further examination. That said, I can't visually see differences in the graphs, so this doesn't alter the conclusions of the paper.

  2. By comparison, changes due to double precision are negligible, but mostly decrease error by ~0.1 percentage points.

Given (2), I favor moving to double precision as the simulator's default configuration. I'll leave this issue open for a little while longer just in case others have tests they can think of or comments.

@brtietz brtietz mentioned this issue Nov 19, 2014
@brtietz
Copy link
Contributor Author

brtietz commented Nov 20, 2014

Closing based on previous post

@brtietz brtietz closed this as completed Nov 20, 2014
brtietz added a commit that referenced this issue Nov 26, 2014
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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant