Different SVD algorithms used by Chainiksolvervel

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). We have found that the eigen version produces lots of assertion errors when running on a Mac platform but not on a linux box. 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. 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?

Thanks!
Craig

Ruben Smits's picture

Different SVD algorithms used by Chainiksolvervel

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

> Thanks!
> Craig

-- Ruben

Different SVD algorithms used by Chainiksolvervel

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

Different SVD algorithms used by Chainiksolvervel

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

Different SVD algorithms used by Chainiksolvervel

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

Ruben Smits's picture

Different SVD algorithms used by Chainiksolvervel

On Wednesday 25 May 2011 20:55:09 S Roderick wrote:
> 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.

Perfect, I completely lost track of that one. Thanks for reminding me.

> S

-- Ruben

Different SVD algorithms used by Chainiksolvervel

On Wed, 25 May 2011, CARIGNAN, CRAIG R. (GSFC-442.0)[Bastion Technologies, 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). We
> have found that the eigen version produces lots of assertion errors when
> running on a Mac platform but not on a linux box. 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. 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?
>

First of all, "stability" is not an absolute concept :-) NRC is indeed
"stable", in the sense that it is not being developed or maintained any
further. So, one of the reasons for using Eigen numerical algortihms in
more recent implementations is the large critical mass behind this project.
If Eigen produces problems for your hardware/software configuration, it
might make sense to (i) check why the assertion violations come from, so
maybe KDL can do something about it, and/or (ii) provide the Eigen and/or
boost developers with similar information about the "bad" workings on Mac.

As a sidenote: linear algebra remains a pragmatic problem, although it is
very mature from an algorithmic point of view. So, we would like to go to a
"standard" interface for linear algebra algorithms, which is a strategic
choice for Eigen... Boost is a similar 'dependency': very useful to have,
but people expect perfection from it, on all possible hardware/software
combinations...

Herman