StabilityTest "demo" app

[GoogleCodeExporter]

The included demo app is a fairly powerful tool for analyzing object motion in 
a variety of test cases.

There are three tests so far:
1. Drop - an object is dropped, and its pose is monitored following some time 
to settle
2. Slide - an object is slid via setLinearVelocity(), and then monitored 
following time to settle
3. Constraint - a chain of links hangs to the side, the final link's pose is 
monitored

The Slide test actually produces two data sets: one while the object is 
sliding, and one after the object has been given time to rest.

Each data set has 8 columns, the first is a timestamp, the next 3 are x/y/z 
position, the last 4 are the x/y/z/w quaternion values.  Each of these columns 
is fitted as a linear function of time, yielding 3 analysis values for each 
data set
1. drift - the sum of the absolute values of the linear fits of each of the 
data columns, indicating overall object motion
2. jitter - the sum of amplitudes of the zero crossings of the derivative of 
the residual following the linear fit, indicating vibration (and representing 
the product of the vibration frequency and amplitude)
3. sink - the distance of the object from its ideal height

The config.txt file controls a variety of simulation parameters and test 
options.  Parameters can be set to cover a range of values, which will be 
iteratively sampled.  Test options can take a single value which control how 
the test is run.  This file contains further documentation for each parameter, 
and is generated by writeconfig.cpp from the original source Config.h.

Although default config files are for specific constant values, the ability to 
set a range for each parameter is very powerful, as it allows the program to 
search over a range of simulation configurations to evaluate robustness.

The default values illustrate current issues of concern for small-scale 
objects, on the order of 0.05.
1. drop and slide - significant drift and jitter when using a 
'btStaticPlaneShape', but set groundBoxXY to 3 or greater to use a btBoxShape 
instead and most of this goes away.  Still some jitter during sliding.
2. constraint - each link sags at the constraint causing "broken" joints.  
Increasing solverIterations into the hundreds addresses this.  Increasing 
conLength reduces the apparentness of the problem--the sink distance stays 
roughly constant, but due to the longer link length, the resulting angle of the 
sag is reduced.

Each of these issues is also addressed by reducing gravity or increasing 
updateHertz to several hundred.  However you may wish to investigate the 
btStaticPlaneShape stability problems and/or how to reduce solver iteration 
requirements for chained constraints.

I provide two patches: the first is a set of modifications to the 
DemoApplication infrastructure:
1. add a parameter to control zoom step size (hardcoded step was too large when 
zoomed in on small objects)
2. add leaveMainLoop() and associated code to do this portably (OS X polls a 
flag with glutCheckLoop, whereas freeGLUT provides glutLeaveMainLoop() and 
retains glutMainLoop.  Theoretically other platforms could throw an exception 
(untested). 
3. add a virtual main(int,char**) so that subclasses can get in on the initial 
setup and command line parameters

The second patch contains StabilityTest itself, and requires the above 
modifications to work.  (Each parameter test case execution is one call to 
DemoApplication::main(), so it uses the ability to leave the glut loop to 
reinitialize for the next test case).

Note the showGUI option to run in headless mode.  Also, all of the raw data 
values for each case are saved to data.txt (can be controlled by dataDump 
option) so you can directly plot object motion for further analysis.

Phew!  Hope that's helpful... short story: just run it and you'll see the 
issues at hand.

Original issue reported on code.google.com by ejtt...@gmail.com on 13 Sep 2011 at 4:22

• Merged into: #541

Attachments:

• demo-app-modifications.diff
• stability-test.diff

[GoogleCodeExporter]

can you please use svn diff?

Thanks,
Erwin

Original comment by erwin.coumans on 13 Sep 2011 at 4:35

[GoogleCodeExporter]

1) btBoxShape against btBoxShape is a special case, and it will generate 
multiple contacts. So it is likely that btStaticPlaneShape is not the special 
case.

2) It will help if you modify an existing demo, without requiring any other 
modifications (similar with the quaternion patch, don't bundle multiple changes 
in a single patch)

3) always use Subversion's svn diff command to create a patch

Thanks a lot,
Erwin

Original comment by erwin.coumans on 13 Sep 2011 at 7:31

[GoogleCodeExporter]

I guess I consider this contribution the basis for a unit test system than a 
single bug report.  I'll see about making a one-off for the box/plane thing 
though.  But if you like this I can clean it up to make it easy for you or 
others to jump in and add new test cases.  My rationale is that the existing 
demos are great for playing and interactive experiments, but they don't really 
allow automated testing/quantification of regressions.  (So maybe this should 
be filed under 'Extras' instead of 'Demos', I dunno, give feedback if you're 
interested in any of this.)

FYI, the trick with doing diffs with SVN (3) is that it conflicts with (2)... 
either I get all my local changes (e.g. all of the bugs I've filed recently) or 
I select on file/directory basis, which still isn't going to give separation of 
unrelated patches when they touch the same file, and doesn't ensure I remember 
to include all of the relevant files and none of the irrelevant ones... DVCS 
makes this much easier/robust ;)

I guess I could apply each of my patches to a clean svn checkout and then 
regenerate a patch from there with svn... but this is kind of roundabout.  So 
for my reference, is there something special about svn's diffs vs. the ones 
from hg?  Maybe there's an easier way to give you what you're looking for?

Original comment by ejtt...@gmail.com on 13 Sep 2011 at 8:29

[GoogleCodeExporter]

svn diff'd version of the patches...

Original comment by ejtt...@gmail.com on 13 Sep 2011 at 8:40

Attachments:

• demo-app-modifications2.diff
• stability-test2.diff

[GoogleCodeExporter]

Let's merge the issue with the newer one

THanks for the repro cases!

Original comment by erwin.coumans on 13 Sep 2011 at 11:41

• Changed state: Duplicate

[GoogleCodeExporter]

Umm, well they're not really the same thing.  This is a tool for running a set 
of test cases over a set of simulation parameters.  In particular, the third 
test case regards constraints 'breaking' between relatively small objects which 
is otherwise still unaddressed.

I could make a version of BasicDemo for that too, but I'd still appreciate it 
if you took this for a spin as well...

Original comment by ejtt...@gmail.com on 14 Sep 2011 at 12:29

[GoogleCodeExporter]

Thanks!

I'll give it a try, but if you can create a BasicDemo version that would be 
appreciated as well.

Original comment by erwin.coumans on 14 Sep 2011 at 2:02