Anyway, I'd propose the following refinements for cer_kinematics_alt:
[x] The lib is fraught with tabs: it would be great to replace 1 tab with 4 spaces and make sure that any next editing will add up just spaces. (done via e5b275c22ac78f74e28f3444c64a5c77ee6be13a)
[x] The namespace is currently cer::kinematics2 but for consistency I'd rather go for cer::kinematics_alt. (done via fb05a955c2158b0e1a49c7b4d23623d7ae79a53b)
[x] The private headers are exposed from within Solver.h, which is public instead. They should be hidden and not directly included in Solver.h. This way we could also get rid of the ambiguity between yarp::sig::Matrix (our main implementation of Algebra) and cer::kinematics2::Matrix. By the way, why don't we use yarp::sig::Matrix straightaway?
[x] This line causes a compilation error, whereas we should be able to reference somehow the desired frame correctly (maybe still relying on the namespace too).
With https://github.com/robotology/cer/commit/f2004e3330e137861cad0acbe2dbf824b883b829 I've committed a small snippet with the idea of commencing a back-to-back comparison of our two kinematics libraries.
Anyway, I'd propose the following refinements for
cer_kinematics_alt:cer::kinematics2but for consistency I'd rather go forcer::kinematics_alt. (done via fb05a955c2158b0e1a49c7b4d23623d7ae79a53b)Solver.h, which is public instead. They should be hidden and not directly included inSolver.h. This way we could also get rid of the ambiguity betweenyarp::sig::Matrix(our main implementation of Algebra) andcer::kinematics2::Matrix. By the way, why don't we useyarp::sig::Matrixstraightaway?LeftSideSolver::fkin()method.