ndcurves issueshttps://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues2020-02-11T12:00:50Zhttps://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/32Issue in binding of Piecewise.curve_at_index2020-02-11T12:00:50ZPierre FernbachIssue in binding of Piecewise.curve_at_indexSee https://gepgitlab.laas.fr/pfernbac/curves/-/jobs/60305 with new python test-case highlighting the issue. (line https://gepgitlab.laas.fr/pfernbac/curves/blob/9c579a27de430d77541a2d9d0d994cfc63e5c4fc/python/test/test.py#L422 fail).
I...See https://gepgitlab.laas.fr/pfernbac/curves/-/jobs/60305 with new python test-case highlighting the issue. (line https://gepgitlab.laas.fr/pfernbac/curves/blob/9c579a27de430d77541a2d9d0d994cfc63e5c4fc/python/test/test.py#L422 fail).
In the current implementation, `piecewise::curve_at_index` return a `shared_pointer<curve_abc>`, then it can be binded directly with boost::python because the shared_pointers for each python class are defined.
This implementation work only if the curve returned by `piecewise::curve_at_index` have been created in python before the call of the method, as it was the case in all the previous unit-test (eg in https://gepgitlab.laas.fr/pfernbac/curves/blob/9c579a27de430d77541a2d9d0d994cfc63e5c4fc/python/test/test.py#L367).
In the case where the curve have been created in C++, when the shared_pointer is returned and wrapped by boost::python, it is wrapped in the parent abstract class (`curve_abc`) instead of the real class. Which lead to the error in the failed job linked above.
This issue may be solved by returning a raw pointer in C++ instead of a shared pointer and then bind the method with `boost::python::return_internal_reference`. But I did not test this deeply and I do not know if it's the best way to solve this.https://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/31Require non const accessor to curves inside piecewise2020-02-11T10:15:12ZPierre FernbachRequire non const accessor to curves inside piecewiseI have several use cases where I have a piecewise curve and I need to replace one of the curve inside the piecewise with another curve (defined on the same time interval). This is not possible with the current API without creating anothe...I have several use cases where I have a piecewise curve and I need to replace one of the curve inside the piecewise with another curve (defined on the same time interval). This is not possible with the current API without creating another piecewise curve.
I see two way to do that : make the accessors `curve_at_time` and `curve_at_index` return non const reference or add new method to do that.
The first method is dangerous as the user could completely screw the time intervals of the curves (but this is the behaviour of my current code based on hpp_spline).
Which implementation do you prefer ?Steve TonneauSteve Tonneauhttps://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/29Issue with Vector6d declaration2020-02-11T11:51:07ZGuilhem SaurelIssue with Vector6d declarationJob [#55085](https://gepgitlab.laas.fr/gsaurel/curves/-/jobs/55085) failed for gsaurel/curves@a1ed4698c4a6377a1b2910ce7c4ace66a10cb2e7:
```
======================================================================
ERROR: test_piecewise_se3...Job [#55085](https://gepgitlab.laas.fr/gsaurel/curves/-/jobs/55085) failed for gsaurel/curves@a1ed4698c4a6377a1b2910ce7c4ace66a10cb2e7:
```
======================================================================
ERROR: test_piecewise_se3_curve (__main__.TestCurves)
----------------------------------------------------------------------
Traceback (most recent call last):
File "…/curves-0.2.0/python/test/test.py", line 621, in test_piecewise_se3_curve
self.compareCurves(pc,pc_txt)
File "…/curves-0.2.0/python/test/test.py", line 33, in compareCurves
self.assertTrue(norm(c1.derivate(t_min, 1) - c2.derivate(t_min, 1)) < 1e-10)
TypeError: No to_python (by-value) converter found for C++ type: Eigen::Matrix<double, 6, 1, 0, 6, 1>
```https://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/28Require operator == between curve2020-02-11T11:51:07ZPierre FernbachRequire operator == between curveA basic operator `==` should check if two curves of the same class are equal.
We could also check if two curves of different class represent the same curve but with a different formulation (eg with curve conversion). Maybe this last one...A basic operator `==` should check if two curves of the same class are equal.
We could also check if two curves of different class represent the same curve but with a different formulation (eg with curve conversion). Maybe this last one should not be done in a `==` operator but in a method like `isApprox()`.Pierre FernbachPierre Fernbachhttps://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/27Low doc coverage on optimization files2020-05-05T10:31:53ZPierre FernbachLow doc coverage on optimization filesSee https://gepgitlab.laas.fr/loco-3d/curves/-/jobs/54043
The lowest scores comes from the following files :
`include/curves/linear_variable.h ` 52%
39,43-47,49-52,57-58,65-68,82-85,96,100-103,112-114,130-132,136-138
`inclu...See https://gepgitlab.laas.fr/loco-3d/curves/-/jobs/54043
The lowest scores comes from the following files :
`include/curves/linear_variable.h ` 52%
39,43-47,49-52,57-58,65-68,82-85,96,100-103,112-114,130-132,136-138
`include/curves/optimization/definitions.h` 50%
62,65-66,70
`include/curves/optimization/details.h` 57%
97,114-115,117-120,123-126,136-138,140-141,144-147,149-155,157-163,165-172,199,204,210-213,215-223,247-267
`include/curves/optimization/quadratic_problem.h` 50%
22,24-28
`python/optimization_python.cpp` 58%
24-41,51-56,58,60-81,89-90
`python/python_variables.cpp ` 2%
7-28,32-37,39-53,56-66
`python/python_variables.h` 26%
36,38,41-42,51,53-56,110,115,119-123,126-128https://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/26add compute_derivate method in cubic_hermite_spline2020-05-11T14:15:58ZPierre Fernbachadd compute_derivate method in cubic_hermite_splineRelated to https://gepgitlab.laas.fr/loco-3d/curves/issues/23, if we decide to rework the class as suggested in this issue, the `compute_derivate` method will be implemented by the `bezier` class.
Otherwise we need to add this implement...Related to https://gepgitlab.laas.fr/loco-3d/curves/issues/23, if we decide to rework the class as suggested in this issue, the `compute_derivate` method will be implemented by the `bezier` class.
Otherwise we need to add this implementation. https://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/25Curves conversion to Bezier and cubic_hermite are limited to degree 32020-05-05T08:42:06ZPierre FernbachCurves conversion to Bezier and cubic_hermite are limited to degree 3`bezier_from_curve` and `hermite_from_curve` only work with curves of degree <= 3 as input. Otherwise, it correctly run but output a wrong result without any warning.
How hard would it be to extend this methods to any degree ? @stonnea...`bezier_from_curve` and `hermite_from_curve` only work with curves of degree <= 3 as input. Otherwise, it correctly run but output a wrong result without any warning.
How hard would it be to extend this methods to any degree ? @stonneau I did not take a look at the maths yet, do you know a link to an algo that do that ?
In the meantime we should at least test if the input is of degree <= 3 and throw an error if not, what do you think ?Pierre FernbachPierre Fernbachhttps://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/22[Tests] hardcoded path makes CI fail2019-12-17T13:54:34ZGuilhem Saurel[Tests] hardcoded path makes CI failhttps://gepgitlab.laas.fr/loco-3d/curves/blob/devel/tests/Main.cpp#L2192https://gepgitlab.laas.fr/loco-3d/curves/blob/devel/tests/Main.cpp#L2192Guilhem SaurelGuilhem Saurelhttps://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/21Build with CURVES_WITH_PINOCCHIO_SUPPORT by default when pinocchio is installed2020-01-10T15:26:06ZPierre FernbachBuild with CURVES_WITH_PINOCCHIO_SUPPORT by default when pinocchio is installedhttps://gepgitlab.laas.fr/loco-3d/curves/blob/devel/CMakeLists.txt#L21-24
Should be changed to have CURVES_WITH_PINOCCHIO_SUPPORT = ON by default when pinocchio is detected.https://gepgitlab.laas.fr/loco-3d/curves/blob/devel/CMakeLists.txt#L21-24
Should be changed to have CURVES_WITH_PINOCCHIO_SUPPORT = ON by default when pinocchio is detected.Guilhem SaurelGuilhem Saurelhttps://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/20Failing tests2020-01-10T15:26:06ZGuilhem SaurelFailing testsHi,
As shown in 96243337, some things that should raise exceptions are not. This was not clear before, as the test was written in a way that it couldn't fail.Hi,
As shown in 96243337, some things that should raise exceptions are not. This was not clear before, as the test was written in a way that it couldn't fail.https://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/19Consistency in polynomial init / eval types2020-01-10T15:26:06ZGuilhem SaurelConsistency in polynomial init / eval typesHi,
If I create a polynomial, I have to give it an init point and an end point as `pointX_t`s:
https://gepgitlab.laas.fr/loco-3d/curves/blob/devel/python/curves_python.cpp#L151
Then, if I evaluate it, I get a `point_t`:
https://gepgitl...Hi,
If I create a polynomial, I have to give it an init point and an end point as `pointX_t`s:
https://gepgitlab.laas.fr/loco-3d/curves/blob/devel/python/curves_python.cpp#L151
Then, if I evaluate it, I get a `point_t`:
https://gepgitlab.laas.fr/loco-3d/curves/blob/devel/include/curves/polynomial.h#L242
So in this test, we are basically checking that a `pointX_t` object is equal to a `point_t` object:
https://gepgitlab.laas.fr/loco-3d/curves/blob/devel/python/test/test.py#L248
This can work for X = 3, but shouldn't it always work ?https://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/17correctly check compilation option in python unit test2020-01-10T15:26:06ZPierre Fernbachcorrectly check compilation option in python unit testPython unit test should correctly check if the library curves was compiled with pinocchio or not. Current implementation only check if pinocchio python lib exist at runtime of the python tests.
See https://gepgitlab.laas.fr/loco-3d/cur...Python unit test should correctly check if the library curves was compiled with pinocchio or not. Current implementation only check if pinocchio python lib exist at runtime of the python tests.
See https://gepgitlab.laas.fr/loco-3d/curves/merge_requests/32
And https://gepgitlab.laas.fr/loco-3d/curves/merge_requests/32/diffs#b52310cdb49130ed3bbd929e8f6136d78cad949d_16_18Guilhem SaurelGuilhem Saurelhttps://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/16Remove template from piecewise curve ?2020-01-09T12:11:42ZPierre FernbachRemove template from piecewise curve ?Ideally, a piecewise curve could contains and mix any kind of curves, as long as the intervals of definition matches.
The only specific methods that I see in the current implementation between the different type of piecewise curves are...Ideally, a piecewise curve could contains and mix any kind of curves, as long as the intervals of definition matches.
The only specific methods that I see in the current implementation between the different type of piecewise curves are :
* piecewise polynomial : the append method is an helper to add polynomial curves created from boundary condition at the end of the piecewise curve.
* piecewise_cubic_hermite do not have a 'compute_derivate' method (because cubic_hermite do not have this method)https://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/15add polynomial fitting methods (and other)2019-10-10T08:23:55ZPierre Fernbachadd polynomial fitting methods (and other)This package should have an "optimization" folder, where we factorize all the methods spread over other packages (hpp-bezier-com-traj for instance).
One of the needed method is a polynomial fitting method from a set of points (and an or...This package should have an "optimization" folder, where we factorize all the methods spread over other packages (hpp-bezier-com-traj for instance).
One of the needed method is a polynomial fitting method from a set of points (and an order).https://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/14Linking error in Curves. Seems to use wrong boost.2019-12-17T19:28:13ZAmit ParagLinking error in Curves. Seems to use wrong boost.ldd /opt/openrobots/lib/python2.7/site-packages/curves.so
linux-vdso.so.1 (0x00007ffc5c1f9000)
libeigenpy.so => /opt/openrobots/lib/libeigenpy.so (0x00007f91107b6000)
libboost_python3-py36.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libbo...ldd /opt/openrobots/lib/python2.7/site-packages/curves.so
linux-vdso.so.1 (0x00007ffc5c1f9000)
libeigenpy.so => /opt/openrobots/lib/libeigenpy.so (0x00007f91107b6000)
libboost_python3-py36.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_python3-py36.so.1.65.1 (0x00007f9110577000)
libboost_serialization.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_serialization.so.1.65.1 (0x00007f9110339000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f910ffb0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f910fc12000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f910f9fa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f910f609000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f910f3ea000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9110ecf000)https://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/10Reading from text files2020-07-06T12:44:19ZPierre FernbachReading from text filesReading from text files. For this, I do not need fancy serialization of curves in parametric form. This can come later. All I need is the ability to read from data stored in plain text format, one row per time instant, each row correspon...Reading from text files. For this, I do not need fancy serialization of curves in parametric form. This can come later. All I need is the ability to read from data stored in plain text format, one row per time instant, each row corresponding to a vector of predetermined length and possibly its derivatives, each element being separated by spaces. So, for instance, the CoM is a three-element vector, and it should stored together with its velocity and acceleration like this:
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0\
1.1 2.1 3.1 4.1 5.1 6.1 7.1 8.1 9.1
where [1.0 2.0 3.0] is the position, [4.0 5.0 6.0] is the velocity, and [7.0 8.0 9.0] is the acceleration at instant 0, [1.1 2.1 3.1], [4.1 5.1 6.1] and [7.1 8.1 9.1] are position, velocity and acceleration at instant 1, ecc. No time specification is needed in the file, it is assumed that the object reading it knows the frequency. When the file is over, the trajectory should steadily keep issuing its final value.
Notice there are *several issues* in the current parametric-curves implementation in [TextFile](https://github.com/stack-of-tasks/parametric-curves/blob/master/include/parametric-curves/text-file.hpp), which are the main reason why I am pushing for change. Therefore, I would really appreciate to see this issues addressed in curves, if they are not already solved. Here I list them, from most to least important (in my opinion). Unfortunately, I think the most important ones are also the most difficult to address, so good work!
1. Size. This is possibly the most limiting one. Currently, `TextFile` reads the file by storing its values into a buffer, but the size of this buffer is limited to 1,000,000 `double`. If the file is bigger that that, an error message is issued and unwanted behavior is produced (I think an empty matrix is returned). This is severely limiting and should be addressed. This might be trickier than it seems. A buffer is certainly necessary, because we cannot afford to do a disk access each time we need a new value, i.e. at each time instant. But simply increasing the buffer will just push the limit forward, not remove it. On the other hand we should avoid having huge buffers in order not to fill the memory. Maybe some work with threads will be needed
2. File loading. Strictly related to the previous point. The current file loading process is blocking and can generate failure on the robot with RT constrains. We could use a separate thread to read the data. See [this issue comment](
https://gepgitlab.laas.fr/loco-3d/sot-talos-balance/issues/47#note_4984)
3. The current implementation *expects* the file to contain position, velocity and acceleration. If velocity and acceleration are not needed, one is obliged to provide them anyways, filling the file with dummy values, thereby greatly increasing the size of the file for nothing. It should be possible to specify we only care about values up to a certain time derivative. This might help alleviate the first point, because less values will be stored. What happens if, for instance, velocity is asked but the file only contains derivatives, do as you want, it can cause a crash, or return zero, or again try a numerical differentiation, I don't care
4. The current implementation is buggy when it comes to the final instant: the buffer is read out of bounds and it returns garbage. In sot-talos-balance, I had to implement the workaround of asking the time instant just before the last one in order to avoid this bug
5. The current implementation expects the position, velocity and acceleration vector to be all of the same size. This means that, for instance, we cannot include a quaternion for the orientation followed by a 3D vector for the angular velocity: we are stuck to Euler angles. It would be nice to allow for different sizes, at least between position and higher derivatives
6. The current implementation seems not to be robust to slight variations of the format. For instance, if a line ends with a trailing white space, it will crash. Some flexibility will probably make out life easiersot-talos-balance requirementshttps://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/9Implement sinusoid class2020-07-06T12:44:48ZPierre FernbachImplement sinusoid classThe current parametric-curves implementation [InfiniteSinusoid](https://github.com/stack-of-tasks/parametric-curves/blob/ecf02f21c25a15119830273fb2b7081552ef24a3/include/parametric-curves/infinite-sinusoid.hpp) allows to specify an "init...The current parametric-curves implementation [InfiniteSinusoid](https://github.com/stack-of-tasks/parametric-curves/blob/ecf02f21c25a15119830273fb2b7081552ef24a3/include/parametric-curves/infinite-sinusoid.hpp) allows to specify an "initial point" (which is take to correspond to a stationary point, either minimum or maximum indifferently) a "final point" (the other stationary point, maximum or minimum), and a "trajectory time" (the time it takes to go from the initial point to the final point, i.e. half the period). Then the trajectory with start from the initial point, go to the initial point, and continues indefinitely. In other words it implements
```math
x(t) = x_0 + \frac{x_f-x_0}{2}\left(1-\cos\left(\frac{\pi}{T}t\right)\right)
```
This is equivalent to allowing to specify amplitude, period, and offset with respect to zero, but not phase, because the trajectory always starts at a stationary point.
If you want to parameterize the trajectory in a different way (i.e. amplitude, period, phase, offset) that is fine with me because the calculations from one to the other are straightforward, just make sure that the current trajectories are still achievable by some proper selection of the parameterssot-talos-balance requirementshttps://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/8Implement MinimumJerk class2020-07-06T12:44:43ZPierre FernbachImplement MinimumJerk classSee https://gepgitlab.laas.fr/loco-3d/curves/issues/1
this trajectory allows to execute a rest-to-rest trajectory (0 initial and final velocity and acceleration) from point A to point B in a given amonut of time $`T`$ by minimizing the ...See https://gepgitlab.laas.fr/loco-3d/curves/issues/1
this trajectory allows to execute a rest-to-rest trajectory (0 initial and final velocity and acceleration) from point A to point B in a given amonut of time $`T`$ by minimizing the time integral of the squared jerk, i.e:
```math
\min\int_0^T \left(\frac{{\mathrm d}^3 x}{{\mathrm d}t^3}\right)^2 {\mathrm d}t
```
This amounts to a fifth-order polynomial with appropriate coefficients. So, normally, if generic polynomials are already implemented, then a separate class may not be strictly needed, but this is a common use case and it might be nice to have it (not to mention that a dedicated implementation might behave better numerically). Details on the implementation can be found in class [MinimumJerk](https://github.com/stack-of-tasks/parametric-curves/blob/ecf02f21c25a15119830273fb2b7081552ef24a3/include/parametric-curves/minimum-jerk.hpp#L47).
Implementation should either inherit from polynomial or simply be a static method that create a polynomial with the right coefficients from the given 2 points and time interval.sot-talos-balance requirementshttps://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/6issue related to already registered class from eigenpy2020-05-04T13:45:33ZPierre Fernbachissue related to already registered class from eigenpySee https://github.com/stack-of-tasks/eigenpy/issues/83 and https://github.com/stack-of-tasks/pinocchio/pull/817
The same changes as in https://github.com/stack-of-tasks/pinocchio/pull/817 need to be applied in curves.See https://github.com/stack-of-tasks/eigenpy/issues/83 and https://github.com/stack-of-tasks/pinocchio/pull/817
The same changes as in https://github.com/stack-of-tasks/pinocchio/pull/817 need to be applied in curves.V1.0Pierre FernbachPierre Fernbachhttps://gepgitlab.laas.fr/loco-3d/ndcurves/-/issues/5remove cubic_spline and quintic_spline ?2020-05-04T16:20:49ZPierre Fernbachremove cubic_spline and quintic_spline ?I don't get the point of this classes now that we have the generic Polynomial class.I don't get the point of this classes now that we have the generic Polynomial class.V1.0