**Guilhem Saurel**
(12fd87c0)
*
at
27 Jul 09:58
*

[Tests] workaround another Boost unittest issue

**Guilhem Saurel**
(dd39e3f7)
*
at
27 Jul 09:58
*

[Tests] workaround another Boost unittest issue

*
... and
6 more commits
*

**Guilhem Saurel**
(dd39e3f7)
*
at
27 Jul 09:58
*

[Tests] workaround another Boost unittest issue

*
... and
6 more commits
*

**Guilhem Saurel**
(696e6f15)
*
at
25 Jul 08:38
*

[Tests] workaround Boost 1.72 unittest issue

**Guilhem Saurel**
(65315995)
*
at
25 Jul 08:38
*

[Tests] workaround Boost 1.72 unittest issue

*
... and
49 more commits
*

**Guilhem Saurel**
(65315995)
*
at
25 Jul 08:38
*

[Tests] workaround Boost 1.72 unittest issue

*
... and
2 more commits
*

**Pierre Fernbach**
(e7494ff1)
*
at
06 Jul 12:53
*

Merge remote-tracking branch 'jchemin/Topic/EditDoc' into devel

*
... and
7 more commits
*

The current parametric-curves implementation InfiniteSinusoid 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

`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 parameters

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:

`\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.

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.

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, 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!

- 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 - 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
- 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 - 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
- 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
- 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 easier

**Pierre Fernbach**
(00c41527)
*
at
06 Jul 12:43
*

Merge pull request #41 from pFernbach/topic/fix_10

*
... and
24 more commits
*

**Pierre Fernbach**
(2fcf1903)
*
at
12 May 13:27
*

Merge pull request #43 from pFernbach/topic/hermite_as_bezier

*
... and
8 more commits
*

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.

@gbuondon Could you check that the PR solve this issue ?

@gbuondon Could you check that the PR solve this issue ?

@gbuondon Could you check that the PR solve this issue ?

When we know that the derivative of a curve will be used a lot, it may be a lot less computationally expensive to compute a new curve representing the derivative of a curve instead of calling derivate() several times. Ideally, once this curve is computed one can store it and simply call it's operator () when calling the derivate() method.

It was done in hpp-spline for bezier curves already, it will be really easy to implement it for polynomial too.

See https://github.com/loco-3d/curves/pull/43

The last two points have not been addressed, it seems that the correct definition of cubic_hermite_**spline** is to have a piecewise curve of third-degree polynomial. So I propose to leave this as it is.

See definition: https://en.wikipedia.org/wiki/Cubic_Hermite_spline

I think that a misunderstanding come from the french translation (https://fr.wikipedia.org/wiki/Spline_cubique_d%27Hermite) where by definition it connect exactly one pair of points.

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-128