Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Generalize command resampling beyond fixed-time sampling #223

Open
1 task done
lorenwel opened this issue Jan 30, 2024 · 0 comments · May be fixed by #224
Open
1 task done

[Proposal] Generalize command resampling beyond fixed-time sampling #223

lorenwel opened this issue Jan 30, 2024 · 0 comments · May be fixed by #224
Labels
enhancement New feature or request

Comments

@lorenwel
Copy link
Contributor

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

  • I have checked that there is no similar issue in the repo (required)
@lorenwel lorenwel linked a pull request Jan 30, 2024 that will close this issue
7 tasks
@Mayankm96 Mayankm96 added the enhancement New feature or request label Feb 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants