Repeated small move about beagleg

[hzeller]

Thanks for the report.
Yes, I can imagine that this will change things as the planner attempts to make the best decision w.r.t. smoothing the overall flow, but of course, that goes counter with small increments.

It is on our list to actually have some smooth 'jogging' feature with input e.g. from a joystick, but sometimes other projects come into the way :)

@lromor do you think it would be possible to configure the queue length at runtime ? We could have an M-command that configures the planner queue length. This could immediately help in this case.

[lromor]

I have to think about it a little bit more, but it sounds indeed more straightforward than implementing the direct motors control on the PRU. I would probably just leave https://github.com/hzeller/beagleg/blob/main/src/planner.cc#L267
the size of the the RingDequeue the same, just enforcing a shortening of the buffer using indices.

[hzeller]

@lromor added a new command M181 to set the planner queue length. This allows to change the planner queue length which can help in this case.

• M181 S1 set the planner queue length to 1 so that each segment it receives will fully accelerate and decelerate. This might be more jerkey but should be fast to respond.
• M181 resets it back to the regular queue length.

Maybe a number a biit above one might be good, something like M181 S5 maybe ? Something to experiment with.