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:
- The resampling manager would need to live outside the command term and inside the environment. This means that we would need to check for resampling inside the step() function
- Commands would need to be computed twice, because an environment reset will also trigger a resampling
- Since the resampling terms might need to know whether a command was resampled, but it cannot know whether the command was resampled through some other means (reset or other term), that information would need to be piped back to the resampling term, which would add a lot of complexity.
- The resampling manager would either need a reference to all relevant command terms, which adds code complexity or
- The environment would need to take care of routing the resampling ids to the correct command term.
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
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