Numerical creep on Spline interpolation

[Michel Hidalgo]

As noted by @agalbachicar, during iteration over GeoPositions using the arc length parameterized Spline-based Malitput RNDF implementation, there's a discrepancy between the last arc length iteration point s[n] and the maximum arc length the interpolator claims, to a 1e-06 order.

We have to figure why this numerical creep arises and fix it.

[Agustin Alba Chicar]

@hidmic after updating ignition::math to cfb40810aaac I must say that the smoothness of the interpolation was improved but the original problem still exists.

In the InverseArcLengthInterpolator class, when calling InterpolateMthDerivative (after removing the _s value truncation) I got:

Failure at drake/automotive/maliput/rndf/spline_helpers.cc:49 in InterpolateMthDerivative(): condition 'this->s_t_.back() >= __s' failed.

I have added a log, and argument values are:

mth: 0
_s:                6.9682892072463484823
this->s_t_.back(): 6.9682892072463475941

Here is the issue --------------------------------^

[Michel Hidalgo]

It fails at the 15th decimal, good lord... I'll take look at the rndf implementation to see where is it getting the bad _s from.

[Michel Hidalgo]

@agalbachicar at first glance I thought it could be an issue with our arc length numerical integration, but after trying with more points the order of the error remains unchanged. Now, Drake Simulator system performs state integration on its own, and looking at MaliputCar implementation, it looks like s is being integrated as well. And I think it's more likely for error to add up integrating differentials like they do than with the method we use. So we could add a tolerance to those assertions, which is better I think than to clamp values. What do you think?

[Agustin Alba Chicar]

I agree with you @hidmic. What do you think to control from the class constructor the tolerance?

[Agustin Alba Chicar]

@hidmic can we close this one?