Try Microduck routines in the simulator using the robot's API?

#8
by ramzi-abbyad - opened

I've been experimenting with an optional adapter that lets a script drive the browser simulator using the physical duck's JSON-RPC API.

The idea is to try routines with a virtual duck first - choreography, demos, or teaching exercises - and reuse the supported commands when working with hardware. You can develop the simulator side without a physical duck connected.

The prototype currently supports robot.move, robot.stop, and robot.do for ground pick, left/right kicks, sit/stand, and roulade. Commands pass through a local gateway into the simulator's existing input controller, so its trained policies and MuJoCo physics handle the movement. API movement expires after 500 ms without an update, and robot.stop releases API control immediately.

There's also a simulator-only robot.get_state method for checking readiness, locomotion mode, and active skills. This is still a partial implementation of the robot API, and transferring a routine to hardware needs separate testing.

The implementation is on the adapter-v2 branch, including the latest forward-movement fix. These links show the code, the changes from the upstream revision it started from, and how to run it locally:

The current checks include 31 passing automated tests and a headless-browser run that verified forward displacement, stop handling, and launching a kick through the gateway. The gateway binds to localhost by default and currently has no authentication, so it's for local use.

Would this be useful in the official simulator? I'd appreciate your thoughts on:

  1. Whether you'd prefer an optional integration here in the Space or a separate adapter package.
  2. Whether simulator state should follow robot.subscribe / robot.state, and any other API or safety details to align.
  3. What license applies to downstream use of the simulator source.

If there's interest, I'd be happy to prepare a focused PR.

Sign up or log in to comment