Changes for Sumo

[bhung-bdai]

Refactor task registration and backend selection to enable support for Sumo and other C++ backend rollouts.

Task Registry

Replaces the previous (task_cls, task_config_cls) tuple registry with a TaskRegistration frozen dataclass that carries rollout_backend, simulation_backend, and locomotion_policy_path alongside the task and config types. Adds get_task_registration() for direct lookup. Spot tasks are now registered with rollout_backend="mujoco_hierarchical" and simulation_backend="mujoco_hierarchical" along with their policy paths, removing the need for tasks to expose locomotion_policy_path as a property.

Rollout & Simulation Backend Renaming

Renames PolicyMJRolloutBackend → HierarchicalMJRolloutBackend and PolicyMJSimulation → HierarchicalMJSimulation to better reflect their general-purpose hierarchical policy layer rather than a Spot-specific locomotion policy. Updates DEFAULT_ROLLOUT_BACKEND_REGISTRY and DEFAULT_SIMULATION_BACKEND_REGISTRY accordingly, replacing "mujoco_policy" with "mujoco_hierarchical".

Backend Resolution via Registry

ControllerNode and SimulationNode now resolve their backends by looking up the task's registered rollout_backend / simulation_backend name at construction time, removing the previous auto-upgrade logic (uses_locomotion_policy checks and simulation_backend config key). Both nodes accept injectable registries and factory functions for extensibility.

RenderPose Separation

Splits xpos and xquat out of MujocoState into a new RenderPose dataclass. The simulation node publishes a dedicated render_pose output topic, and the visualization node subscribes to render_pose instead of states.

Dora Node File Renames

Renames controller.py → controller_node.py, simulation.py → simulation_node.py, and visualization.py → visualization_node.py with updated target paths in judo_dora_default.yaml.

mujoco_extensions Import Guard

Adds _require_mujoco_extensions() to fail fast at CLI entry points (app() and benchmark()) if the native extension is unavailable, surfacing a clear build instruction rather than a deferred import error.

[slecleach]

Thanks for the Sumo backend work — I walked through the diff in detail and found two behavioral regressions to fix before merge:

1. SimulationNode._init_sim can now fail for cfg-registered custom tasks

• In judo/app/dora/simulation.py, _init_sim() calls get_registered_tasks().get(task_name) before any backend instance is constructed.
• Custom tasks are registered in Simulation.__init__ via register_tasks_from_cfg(task_registration_cfg), which only runs when sim_backend_cls(...) is instantiated.
• That means init_task values supplied only through task_registration_cfg now raise ValueError during node startup.

2. Switching task resets controller state/config unexpectedly

• In judo/app/dora/controller.py, update_task() now rebuilds the controller via self._make_controller_fn(init_task=..., init_optimizer=...).
• This path does not preserve runtime state/config that previously survived task switches (notably controller config overrides like horizon/control_freq), since make_controller() creates a fresh ControllerConfig.
• It also omits the node's original registration/customization args (task_registration_cfg, optimizer_registration_cfg, and any custom kwargs), so behavior can drift after a task change.

Please preserve existing controller/task/optimizer config where intended and ensure task registration from cfg occurs before task lookup in simulation init.

[bhung-bdai]

1. SimulationNode._init_sim

I see the concern in point 1, but we never supply the init_task in the task_registration_cfg by itself (especially during a task switch).

For part 2, we don't mind the overrides being overwritten due selecting a new task. We also only ever reference the optimizer as one source of truth due to a change I made in the API, meaning that any new controller automatically references its optimizer config as the sole source of truth. The behaviour can drift if the configs are changed, but the configs aren't meant to change in between runs. This could be an issue for run_mpc in the future but this will be fixed by registering the config first.

[bhung-bdai]

Slight comments