Generate railroad and navigate using heightmap

[azazdeaz]

Main changes compared to main:

• Uses the HeightMap and the UWB data to implement navigating on the railroad while following a target
• Procedurally generated railroad environment
• Uses pyproject.toml to organize dependencies

mujoco_follow_rail_rsl_rl.mp4

(Using the RSL-RL policy trained in Isaac Lab. Probably some extra training on similar obstacles would help with the occasional stumbling on the sleepers)

rerun_follow_rail_rsl_rl.mp4

[azazdeaz]

@fabid @tomonorman @2lian
For the easier setup, this PR migrates the project from requrements.txt to pyproject.toml, so everything should be able to run with uv run ... without any other installation steps.
(This is possible do to this beautiful PR that fixes up the unitree_sdk2py package to use prebuildt CycloneDDS binaries on all platforms (including MacOS))
The only difficulty left with the deployment, is that we have to clone the right branch of unitree_mujoco into the right place. Since unitree_mujoco is not a package, just a collection of example scripts, it would make more sense to me to move the part we use into the go2-mujoco-artefacts repo. With the current setup, we have the source split between two repos, which complicates both, the development and the deployment.

So my question is: would it be okay if I put the code we use from unitree_mujoco into this repo? In that case, i could close the DDS API PR and have all the rail-following demo implementation in this PR.

[2lian]

if you have issues with deps, on my branch I used pixi, and I have a fix that will fix the problems with the (quite terrible) unitree repo. you can see how I do it

[azazdeaz]

@2lian
Thank you, i did check your PR 🚀
TLDR for the above: this fork fixes all the packaging issues (i know of) with the unitree sdk package: unitreerobotics/unitree_sdk2_python#107

[2lian]

Yeah I am not working on this branch anymore, better not lose more time on this for now and work on SSF instead.

So just take what you find usefull from it. Like the rerun stuff that takes all the meshes from Mujoco, TF, controller, pixi, other fixes

[fabid]

the only difficulty left with the deployment, is that we have to clone the right branch of unitree_mujoco into the right place. Since unitree_mujoco is not a package, just a collection of example scripts, it would make more sense to me to move the part we use into the go2-mujoco-artefacts repo. With the current setup, we have the source split between two repos, which complicates both, the development and the deployment.

On this part, I would rather keep those separate, as go2-mujoco-artefacts is a specific example using artefacts, while unitree_mujoco would be what you import in any project that needs to use the unitree sdk with mujoco

[tomonorman]

Here I would agree with Fabian, I think we should keep it separate, between the example, and whatever additions/fixes we have made to the unitree_mujoco project to have things available (the different apis and what not).

Ultimately, its not so much making it "easier" for us, but showing folks what is required to get simulations working using robotic companies sdks, including any improvements required to other packages (such as unitree_mujoco)

[azazdeaz]

Thank you for the answers!

To keep the unitree_mujoco and our demo project separate, i added a pyproject.toml  to unitree_mujoco so we can install it from github like a python package. That is a minimal change, and removes the burden from the user to keep the two sources in sync.

[tomonorman]

Approving in current state.

We can bundle some of the Dockerfile stuff into a new base image on public ecr,

If you're doing tests I guess can be a continuation of this PR, or a new one