Final acceleration phase to allow target states outside of limits

[Fubini2]

Dear Pantor,

another feature that would be useful in the environment of real-time control of laser scanners is the deliberate violation of the permissible range at the end. This is essentially a symmetric problem to the initial braking phase when the start conditions are outside the allowed range only that you want to accelerate out of it.

We are mainly testing your code as a time-optimal transistion trajectory with the laser off between two process sections where the laser processing takes place. Here it is common to assume that at the beginning of the programmed process trajectory you are already at laser process speed. It is sometimes the case that additional external kinematics, which are very slow compared to the laser, place the workpiece in the laser scanner image field. If the laser process states would be immediately commanded as the limit for the connection trajectory, the scanner runs away from the external feed kinematics and leaves the image field. In this respect, you actually want to run at the maximum speed of the external kinematics for a long time during the transistion motion and only accelerate the scanner to the process states at the end. I hope this is understandable.

Technically, this would be easiest to solve if one had an (optional) final acceleration phase in addition to the initial braking phase. Mathematically, this is a symmetrical problem to the initial braking phase and could actually be calculated in exactly the same way with subsequent time inversion.

Best wishes Fubini

[pantor]

Am I understanding correctly that this only applies (and will support) target states outside of the kinematic limits?

I haven't thought about that possibility yet, so thanks for your input! I think this could be a very good default setting so Ruckig would really support arbitrary target states.

[Fubini2]

Hi @pantor,

exactly. We want to bring the target state outside of the kinematic limits.

I already started a prototypical implementation based on your brake phase of this feature inside my local copy of your repository. If interested I could provide it for you as a start off. Not thoroughly tested by now and I am sure I missed a few things in your code ...

Fubini

[Fubini2]

Dear @Pantor,

you can find my current implementation for this feature in my fork of your repo:

https://github.com/Fubini2/ruckig/tree/accel_phase

Feel free to reuse or discard anything from it. Comments welcome!

Fubini

[ahoarau]

@pantor This is indeed a nice feature. Are you planning to integrate it upstream ?

[pantor]

@ahoarau Nothing concrete planned yet, but in the following months, yes.

[ahoarau]

@Fubini2 maybe a PR then ?

[Fubini2]

@ahoarau Whats a PR? Sorry I only started working with GitHub quite recently.

Also I have to admit my prototype here https://github.com/Fubini2/ruckig/tree/accel_phase is not complete and still has bugs. It was just a quick proof of concept.

For example I know there is still an issue with the check when to add an profile to the list of potentially optimal profiles at the end of

template<JerkSigns jerk_signs, Limits limits, bool set_limits = false>
bool check(double jf, double vMax, double vMin, double aMax, double aMin) {

As the comment of @pantor already states

    // Velocity limit can be broken in the beginning if both initial velocity and acceleration are too high

the check of the initial values is left out here because the initial brake phase algorithms does not always find a solution precisely on the kinematic limit. Of course the same is true for the start of the acceleration phase. What I am currently not sure about is whether leaving out the checks on the target state will not lead to unexpected behavior when adding profiles violating the kinematic constraints unconditionally to the set of possible time optimal profiles.

Fubini