Add before end markers

[kevinthegreat1]

Adds the beforeEndTime and beforeEndDisp markers, which executes the given action a given dt or ds before the end of the current / next trajectory segment. I believe this is more correct and functional compared to #123, but I did have to change the signature of MarkerFactory#make. This code has been tested in production on my team's auto.

[rbrott]

Is there a reason that afterTime()/afterDisp() with negative values don't suit your needs?

[kevinthegreat1]

Is there a reason that afterTime()/afterDisp() with negative values don't suit your needs?

They don’t allow negative values. Also it would work since it would involve sleep actions with negative times.

[rbrott]

They don’t allow negative values.

Ah I forgot I disallowed that after all. I'd rather open that up in the API though than add another method.

Also it would work since it would involve sleep actions with negative times.

I would propose clamping the sleep duration to zero / eliding the sleep if the duration would be negative.

[kevinthegreat1]

I think you're misunderstanding the point of these methods. The point is that the new methods offset from the end of the current / next trajectory segment. It is not the same as the start of the current / next trajectory segment. It is useful for when you're not sure how long a trajectory segment will take.

[rbrott]

I think you're misunderstanding the point of these methods. The point is that the new methods offset from the end of the current / next trajectory segment. It is not the same as the start of the current / next trajectory segment. It is useful for when you're not sure how long a trajectory segment will take.

Understood. Concretely, my counterproposal is to replace

.beforeEndTime(2.0) { ... }
.forward(20.0)

with

.forward(20.0)
.afterTime(-2.0) { ... }

[kevinthegreat1]

I misunderstood you the first time because negative values would need extra processing. All done now. The new code is not tested on a real robot, but unit tests show that it produces identical trajectory actions to the old implementation.

One question: negative values get treated as 0 in SleepAction. Should it fail hard?