Non-deterministic outputs based on scope of Ruckig data structure

[pantor]

Non-deterministic outputs based on scope of Ruckig data structure

[gavanderhoorn]

@pantor: what about initialising all fields to something like a quiet NaN, and then checking they have been properly initialised by the user when they are about to be used?

Using a sentinel value could help distinguish between uninitialised and "some random large value".

[pantor]

Hi @pbeeson!

When creating the InputParameter instance, not all its members are initialized. In particular, current_position, target_position, and the max_<...> limits need be set explicitly. I mean otherwise the whole position-controlled trajectory generation wouldn't make sense, but I'm also open to initialize them all to zero. Those uninitialized values might explain the non-deterministic output. Can you check that this is not the case here? Otherwise, Ruckig should definitely be deterministic.

[pantor]

That seems to be a good idea, thanks for your input @gavanderhoorn!

[pbeeson]

I definitely am setting all (known) required values. All current, target, and maxes. So my thought last night was that there is something else (maybe in the output Trajectory) that isn’t getting reset properly.

…

On Fri, Jul 16, 2021 at 2:03 AM pantor ***@***.***> wrote: That seems to be a good idea, thanks for your input @gavanderhoorn <https://github.com/gavanderhoorn>! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5N7RU6E3UFKOZ6FBJZAXTTX7DS7ANCNFSM5AOY6FYA> .

[pantor]

I just played around with the code and your hints, but couldn't reproduce something along the lines of your issue. It would be great if you could share a complete example!

Moreover, what output exactly is non-deterministic? Only the OutputParameter or also the trajectory, e.g. its duration?

[pantor]

Oh, and just to make sure that it's not as simple as that: If you would apply your code snippet to the example.cpp, this would change the trajectory between the first and second execution because the input parameter is updated while stepping through the trajectory. This is done in those lines:

input.current_position = output.new_position;
input.current_velocity = output.new_velocity;
input.current_acceleration = output.new_acceleration;

[pbeeson]

I tracked this down to an indexing bug in my own code that was generating the data. Weirdly it got past all CI tests, but the tiny randomness in a bad memory lookup was magnified by the Ruckig process. Thanks.