On May 25, 2011, at 2:18 PM, Ruben Smits wrote:

> On Wednesday 25 May 2011 16:05:47 CARIGNAN, GSFC-442.0, Inc.] wrote:
>> Does anybody know why the wdls and pinv versions of chainiksolvervel use
>> different algorithms to compute the singular values of the Jacobian? The
>> chainiksolvervel_wdls uses svd_eigen_HH whereas chainiksolvervel_pinv uses
>> svd_HH which appears to be from numerical recipes in C (NRC).
>
> AFAIK both implementations should be similar, they should only use a different
> matrix library (Eigen vs boost::ublas) underneed. They are both based on NRC.
> Did you try to compare the source files of both solvers???
>
>> We have
>> found that the eigen version produces lots of assertion errors when running
>> on a Mac platform but not on a linux box.
>
> Normally the assertions are to check the correct behavior of the algorithm. If
> the algorithm functions correctly even without the assertion, the assertion is
> a bug.
>

The assertion "assert(z!=0)" on Line 219 of svd_eigen_HH.cpp is a bug and should be removed. The conditional statement in the next line "if (fabs(z)>epsilon)" will prevent a divide by zero in the next line "z=1.0/z" in the event that z=0. Since z can equal zero, the assertion will stop the algorithm when it is not supposed to.

>> This has prompted us to replace
>> all of the assertions in svd_eigen_HH with return error codes so that we
>> can monitor IK failures and continue the simulation without updating the
>> joint positions. We conjecture that this might be due to differences in
>> the boost libraries for the two platforms, but we have not verified that.
>
> I hope you mean Eigen libraries since it is the svd_eigen_HH which is giving
> you problems and this one should be independant from boost.
>
>>
>> Note that we have not experienced any such problems with the NRC version
>> used by chainiksolvervel_pinv on any of our platforms. So why doesn't
>> chainiksolvervel_wdls also use this more stable version?
>
> As said before, both are based on NRC and only differ in the underlying matrix
> library used. If you can give more info on the actual assertion issues, please
> do not hesitate to file a bug on bugs.orocos.org
>
>> Thanks!
>> Craig
>
> -- Ruben

On May 25, 2011, at 2:18 PM, Ruben Smits wrote:

> On Wednesday 25 May 2011 16:05:47 CARIGNAN, GSFC-442.0, Inc.] wrote:
>> Does anybody know why the wdls and pinv versions of chainiksolvervel use
>> different algorithms to compute the singular values of the Jacobian? The
>> chainiksolvervel_wdls uses svd_eigen_HH whereas chainiksolvervel_pinv uses
>> svd_HH which appears to be from numerical recipes in C (NRC).
>
> AFAIK both implementations should be similar, they should only use a different
> matrix library (Eigen vs boost::ublas) underneed. They are both based on NRC.
> Did you try to compare the source files of both solvers???

The source code in svd_HH.cpp and and svd_eigen_HH.cpp do look very similar except for some differences in variable names and inclusion of the insertion tests. So perhaps they are essentially the same and it is an underlying library issue.

>
>> We have
>> found that the eigen version produces lots of assertion errors when running
>> on a Mac platform but not on a linux box.
>
> Normally the assertions are to check the correct behavior of the algorithm. If
> the algorithm functions correctly even without the assertion, the assertion is
> a bug.

I do not know enough about singular value decomposition algorithms to know whether the assertion should halt the algorithm or not. Maybe the assertions should fail when a singular value is zero (which will always be the case for a 7-dof robot arm), but the precision is different on the two platforms? The code in svd_HH.cpp does not use any assertions, but perhaps it would also fail if the comparable assertions were inserted. So even boost::ublas may exhibit differences across platforms.

>
>> This has prompted us to replace
>> all of the assertions in svd_eigen_HH with return error codes so that we
>> can monitor IK failures and continue the simulation without updating the
>> joint positions. We conjecture that this might be due to differences in
>> the boost libraries for the two platforms, but we have not verified that.
>
> I hope you mean Eigen libraries since it is the svd_eigen_HH which is giving
> you problems and this one should be independant from boost.

You are correct.

>>
>> Note that we have not experienced any such problems with the NRC version
>> used by chainiksolvervel_pinv on any of our platforms. So why doesn't
>> chainiksolvervel_wdls also use this more stable version?
>
> As said before, both are based on NRC and only differ in the underlying matrix
> library used. If you can give more info on the actual assertion issues, please
> do not hesitate to file a bug on bugs.orocos.org

If I am able to gain some insight into why the assertion is failing on the Mac, but not the linux box, I will report it accordingly.

>> Thanks!
>> Craig
>
> -- Ruben

-Craig

On May 25, 2011, at 14:18 , Ruben Smits wrote:

> On Wednesday 25 May 2011 16:05:47 CARIGNAN, GSFC-442.0, Inc.] wrote:
>> Does anybody know why the wdls and pinv versions of chainiksolvervel use
>> different algorithms to compute the singular values of the Jacobian? The
>> chainiksolvervel_wdls uses svd_eigen_HH whereas chainiksolvervel_pinv uses
>> svd_HH which appears to be from numerical recipes in C (NRC).
>
> AFAIK both implementations should be similar, they should only use a different
> matrix library (Eigen vs boost::ublas) underneed. They are both based on NRC.
> Did you try to compare the source files of both solvers???
>
>> We have
>> found that the eigen version produces lots of assertion errors when running
>> on a Mac platform but not on a linux box.
>
> Normally the assertions are to check the correct behavior of the algorithm. If
> the algorithm functions correctly even without the assertion, the assertion is
> a bug.
>
>> This has prompted us to replace
>> all of the assertions in svd_eigen_HH with return error codes so that we
>> can monitor IK failures and continue the simulation without updating the
>> joint positions. We conjecture that this might be due to differences in
>> the boost libraries for the two platforms, but we have not verified that.
>
> I hope you mean Eigen libraries since it is the svd_eigen_HH which is giving
> you problems and this one should be independant from boost.
>
>>
>> Note that we have not experienced any such problems with the NRC version
>> used by chainiksolvervel_pinv on any of our platforms. So why doesn't
>> chainiksolvervel_wdls also use this more stable version?
>
> As said before, both are based on NRC and only differ in the underlying matrix
> library used. If you can give more info on the actual assertion issues, please
> do not hesitate to file a bug on bugs.orocos.org

I did, a while back, and IIRC I sent in a patch (that Craig mentioned) that changed the asserts to returning error codes.
S