You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
I have checked that there is no similar issue in the repo (required)
This discussion was converted from issue #223 on October 02, 2024 08:40.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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
Beta Was this translation helpful? Give feedback.
All reactions