Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Closed
1 task done
lorenwel opened this issue Jan 30, 2024 · 0 comments · May be fixed by #224
Closed
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)
@Mayankm96 Mayankm96 added the enhancement New feature or request label Feb 10, 2024
@isaac-sim isaac-sim locked and limited conversation to collaborators Oct 2, 2024
@Dhoeller19 Dhoeller19 converted this issue into discussion #1103 Oct 2, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants