testFloatingBase test can fail (away from singularities and far beyond any reasonable tolerance)

[RussTedrake]

<matlab_test>strcmp(error_id,'Drake:ValueCheck') && strcmp(test_name,'systems/plants/test/testFloatingBaseDynamics')</matlab_test>

Site: drake002
Build Name: master-RobotLocomotion-master
Build Server Directory: /tmp/drake-master-19453/drake
CDash: http://kobol.csail.mit.edu/cd/index.php?project=Drake&date=20140819

Most recent commits to drake included in this build:

5e493a7 another known issue
7ad9401 fix typo
0a8887c Merge pull request #308 from
avalenzu/MultiCoordinateFrame-from-MultiCoordinateFrames
a3e6e21 Fix order of frames in MultiCoordinateFrame
e1eb1f9 Fix construction of a MCFrame from MCFrames

systems/plants/test/testFloatingBaseDynamics (unknown issue)

                           < M A T L A B (R) >
                 Copyright 1984-2014 The MathWorks, Inc.
                   R2014a (8.3.0.532) 64-bit (glnxa64)
                            February 11, 2014


To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit www.mathworks.com.

To reproduce this test use rng(1020455739,'twister')

Calling addpath_spotless
Added the lcm jar to your javaclasspath (found via cmake)
[Warning: Currently all of your LCM traffic will be broadcast to the
network,
because:
util/check_multicast_is_loopback.sh: line 3: ifconfig: command not found
util/check_multicast_is_loopback.sh: line 6: ifconfig: command not found
 Loopback interface is not set to multicast.
 Consider running: sudo
 /tmp/drake-master-19453/drake/util/setup_loopback_multicast.sh
] 
[> In checkDependency at 56
 In addpath_drake at 81
 In addpath_drake at 4] 
Calling addpath_snopt
Error using valuecheck (line 78)
Values don't match.
   Index       Value       Desired Value
  -------     --------    ---------------
   (38,1)    66.470220       66.470056
   (42,1)   670.737045      670.736909
   (43,1)    -0.920584       -0.920405
   (50,1)     9.182555        9.182702
   (51,1)   653.423164      653.423031
   (62,1)   -37.540801      -37.540651
   (63,1)  1002.338326     1002.338210
   (66,1)   -21.748861      -21.748707


Error in testFloatingBaseDynamics (line 95)
 valuecheck(xdn,xdn2([ind;nq+ind]),1e-4);


This issue is not listed as known.  Please seriously consider reporting it
on <a href="http://github.com/RobotLocomotion/drake/issues">GitHub</a>.
testname: systems/plants/test/testFloatingBaseDynamics
error ID: Drake:ValueCheck

[RussTedrake]

it's probably near the kinematic singularity. if the random state is sufficiently close to the rpy singularlity, then we should pick a different random state.

[RussTedrake]

This test is still failing pretty often. Even with relatively small numbers.

[RussTedrake]

have brought this down from "high priority" since the build servers now run deterministic test by default (note there is still a cmake option for randomizing the tests).
i suspect this is just a problem with problem with initial conditions not satisfying the unit circle constraint on the quaternion joints, and there are newer methods that we have written which should make that easier. but it would definitely be good to resolve it for sure.
@tkoolen -- please add any thoughts you have?

[tkoolen]

I just tried the test a couple of times locally, and it still fails fairly often (note: I'm a bit behind master right now, don't have the new LCP solver). The thing that fails is this:

  xdn = update(m_rpy,0,[q;qd],u);
  xdn2 = update(m_ypr_rel,0,[q(ind);qd(ind)],u);

  valuecheck(xdn,xdn2([ind;nq+ind]),1e-4);

so comparing what's returned by the update method for an rpy and ypr parameterized robot (I've seen it fail on the Atlas urdf). All of the terms in the equations of motion are already valuechecked before this point. So it might just be the LCP solution process in update magnifying small errors a lot, or it having some kind of minor dependence on the order of the state variables. I would check again with the new LCP solver.

[RussTedrake]

There is no new lcp solver for the matlab code yet, and it might take some time to get there.

[jwnimmer-tri]

Closing as won't-fix, because #6369 will be removing the relevant software.

If I'm confused and this should in fact stay open, please re-open an clarify the remaining unsolved problem(s) in a new comment here.