This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
[Proposal] Generalize command resampling beyond fixed-time sampling #223
Labels
enhancement
New feature or request
Proposal
At the moment, the command term base class has a fixed resampling behavior which always triggers after a certain time.
More ways of triggering command resampling should be supported.
Motivation
Fixed time sampling severely limits the flexibility for how commands might be resampled.
Some tasks might not work well with a fixed pre-defined resampling time (e.g. goal point navigation over variable distance).
Some tasks might require access to the environment/scene to determine whether goals should be resampled (e.g. an object appears/disappears).
Pitch
Each command term receives a number of resampling terms which it calls at every update step to determine whether commands need to be resampled.
Alternatives
The alternative would be to create a resampling manager which lives outside of a command term and receives a reference to the command terms it needs to update.
This would have the advantage that multiple command terms could be reliably resampled at the same time, which is not possible with my proposal (but is also not currently possible).
However, there are several drawbacks to this which lead to my proposal:
Since this alternative would add a lot of complexity compared to my proposal for fringe cases which could also be achieved by other means (e.g. a multi-command wrapper class) I propose that the command term owns a resampling manager.
Checklist
The text was updated successfully, but these errors were encountered: