Possible additions to the TAB api

[Iris-TheRainbow]

I was working on writing my own auto builder (for something other than rr) and I modded it quite similarly to how the TAB writes autos. However, Ive found a couple more options for when to trigger commands that I think that the TAB could be improved with.
These additions would be adding a duringLast() method. (or you could do duringNext()) This is functionally identical to afterTime(0), however, I found it to be a lot nicer when writing autos. I also wrote an implementation of a untilDisp() function, which works like afterDisp() but it triggers the command X inches until the target.

I feel like these could be good additions for people who want to write more complex autos.

[rbrott]

These additions would be adding a duringLast() method. (or you could do duringNext()) This is functionally identical to afterTime(0), however, I found it to be a lot nicer when writing autos.

I'm a little confused about duringLast(...) being equivalent to afterTime(0, ...). The latter executes the action immediately after the previous trajectory segment, while I would expect the former to execute the action when the previous trajectory segment begins.

I also wrote an implementation of a untilDisp() function, which works like afterDisp() but it triggers the command X inches until the target.

I intended for users to use afterDisp() with a negative displacement to accomplish that effect. I find the word "until" to add some confusion -- should the action be forcibly terminated when the displacement is reached? The current behavior lets the action continue as long as it wants, though that isn't what "until" conveys to me.

[Iris-TheRainbow]

Oh for the duringLast implementation that is my bad. my auto builders run all the markers during the previous. an equivalent would be a duringNext()

I didnt realize that negative displacement worked, is that reflected in documentation? its entirely possible I missed that.

[rbrott]

I didnt realize that negative displacement worked, is that reflected in documentation? its entirely possible I missed that.

I don't think it's really mentioned in the docs. I've wanted to write a longer guide on builder subtleties but that hasn't happened yet.

[rbrott]

Okay I lied. The current code forces dt/ds to be non-negative. I would propose lifting that limitation as the right path forward. Related discussion in acmerobotics/road-runner#126.