How should 10 Hz GR00T relative actions be aligned with a 30 Hz robot controller?

Robotics & Edge Computing Robotics - Isaac Isaac ROS
,
1

Hi, I’m working on deploying GR00T / Isaac GR00T with a policy inference rate around 10 Hz, while my downstream robot controller runs at 30 Hz.

I would like to confirm the correct way to align policy actions with the controller frequency.

Questions:

  1. Are GR00T actions represented as absolute target poses, relative deltas, or velocity-like commands?

  2. If they are relative deltas, does one action correspond to one policy step? For example, at 10 Hz, does one action represent the displacement over 0.1 seconds?

  3. For a 10 Hz policy and a 30 Hz controller, what is the recommended deployment approach?

    • Hold the same action for 3 controller ticks?
    • Interpolate target poses?
    • Split the relative delta into 3 smaller deltas?
    • Or use an action chunk / horizon output directly?

  4. Is it valid to increase an action gain / bias multiplier to compensate for the 10 Hz → 30 Hz mismatch?
    Or should gain calibration only be applied after timestamp alignment, latency compensation, and action resampling are handled?

Currently, the predicted motion direction is roughly correct, but the predicted points do not perfectly align with the 30 Hz observed robot trajectory.

My main concern is to avoid using a gain multiplier to hide an incorrect interpretation of the action semantics under a different control frequency.

Any guidance on the recommended alignment / debugging procedure would be appreciated.

Thank you.

2

Hello @chenjason7026,

Welcome to the Isaac ROS forum and thanks for the post!

I would address your questions below.

  1. Absolute, relative, or velocity-like?
    It depends on the action_configsfor the embodiment.
    GR00T supports ABSOLUTE/RELATIVE actions. They are not velocity commands by default. If you call Gr00tPolicy.get_action(), the returned actions are decoded back to physical units and relative internal predictions are converted using the current state, so the API output should usually be treated as target actions.
  2. If relative, is one action one policy step?
    Yes, one horizon index corresponds to one dataset/control timestep from action.delta_indices. If the policy was trained/deployed at 10 Hz, one index is typically 0.1 s. But for RELATIVE, each horizon entry is usually relative to the current/reference state, not necessarily an incremental delta from the previous horizon entry.
  3. 10 Hz policy with 30 Hz controller?
    Recommended order:
    • Use the action chunk/horizon output as the source trajectory.
    • Treat chunk entries as targets at the policy timestep, e.g. 10 Hz.
    • For a 30 Hz controller, either hold each target for 3 controller ticks or interpolate between consecutive targets. Interpolation is usually smoother than holding.
      You could use the action chunk directly as timestamped targets, then let the controller or your adapter resample it to 30 Hz. If your controller only accepts per-tick setpoints, interpolate targets to 30 Hz. Holding for 3 ticks is acceptable as a simpler
      baseline. Splitting relative deltas is not recommended for normal GR00T policy output unless you are absolutely sure you are consuming raw incremental deltas.
  4. Can gain/bias compensate for 10 Hz to 30 Hz mismatch?
    No, you should apply gain calibration only after you have verified that the direction is correct but points do not align. Normally, the likely causes are timestamp/latency offset, frame convention mismatch, or controller dynamics, not simply missing a factor of 3.
3

Thank you for the detailed clarification.

I understand now that the GR00T action output should be treated as a target trajectory at the policy timestep, and that for a 10 Hz policy with a 30 Hz controller, holding each target for 3 controller ticks or interpolating between consecutive targets are the recommended approaches.

I also understand that applying an arbitrary gain or bias is not recommended, and that if the direction is correct but the points are misaligned, I should first check timestamp alignment, latency, frame conventions, and controller dynamics.

Thanks again for the guidance.

4

If there are no further questions, we’ll close this topic for now. Feel free to open a new thread if you have any other issues.