Minimal viable booster framework

[alexschmander]

Why? What?

We are moving robot platforms to the Booster Robotics K1. To facilitate this change, we have decided to fully move our codebase to this new platform and discontinue our development on the NAO Platform.

This PR removes the hulk_nao binary crate, the hulk_webots crate as well as some related ones. In exchange it adds a hulk_mujoco binary crate. This is a binary that executes the framework and robotics code while providing a hardware interface to a mujoco simulator and is comparable in use case to the hulk_webots crate, which it replaces. The mujoco simulator is currently being developed here.

The CI has also been changed to not build the hulk_nao and hulk_webots crate and instead build the hulk_mujoco crate.

Additionally the test job was temporarily disabled, since the execution of the bevyhavior simulator scenarios depend on parameters which were NAO specific. The bevyhavior simulator is definitely still useful for the new platform, but extensive rework is required there and that is out of scope for this PR, since the behavior simulation is not as crucial for now.

ToDo / Known Issues

If this is a WIP describe which problems are to be fixed.

Ideas for Next Iterations (Not This PR)

How to Test

• In a separate worktree pull the above mentioned mujoco simulator branch.
  • On that branch, in mujoco-simulator run uv run main.py to start the simulator.
  • Additionally, in tools/mujoco-rust-server/frontend/ run npm i and then npm run dev to start the simulator visualizer.
• Then run ./pepsi run mujoco

[oleflb]

lol, casually deletes default.json 😮

[alexschmander]

lol, casually deletes default.json 😮

I mean, those were all NAO related parameters, right? In the spirit of starting of clean, doing this seems right imo. Every parameter we still need we can simply bring it back, when we implement something that does need it.

[schluis]

lol, casually deletes default.json 😮

I mean, those were all NAO related parameters, right? In the spirit of starting of clean, doing this seems right imo. Every parameter we still need we can simply bring it back, when we implement something that does need it.

In my experience, restoring lost functionality can sometimes be more difficult than expected. Our old walking engine had fairly good catching steps. It took us two? years to restore them.
This example might not be a perfect fit, but please don't take the decision lightly to get rid of this...

[alexschmander]

lol, casually deletes default.json 😮

I mean, those were all NAO related parameters, right? In the spirit of starting of clean, doing this seems right imo. Every parameter we still need we can simply bring it back, when we implement something that does need it.

In my experience, restoring lost functionality can sometimes be more difficult than expected. Our old walking engine had fairly good catching steps. It took us two? years to restore them. This example might not be a perfect fit, but please don't take the decision lightly to get rid of this...

I understand your hesitance to simply get rid of the result of years of tuning trial and error. I would really like to stress, that the information in the default.json is not supposed to simply be tossed out. We made the decision to make a clean start and only bring NAO code back, when specifically adapted to the booster to avoid dead, unused or even false information.
But we should definitely consult the old parameters, when introducing new booster related ones. I'm not sure what the best workflow would be to make sure that actually happens.

Those are my two cents, but this is absolutely still up for discussion. Any other opinions/arguments from the team?

[oleflb]

lol, casually deletes default.json 😮

I mean, those were all NAO related parameters, right? In the spirit of starting of clean, doing this seems right imo. Every parameter we still need we can simply bring it back, when we implement something that does need it.

In my experience, restoring lost functionality can sometimes be more difficult than expected. Our old walking engine had fairly good catching steps. It took us two? years to restore them. This example might not be a perfect fit, but please don't take the decision lightly to get rid of this...

We talked extensively about how to handle the transition to K1 last wednesday and came to the conclusion that deleting stuff is better than keeping things where we don't know if it still works.
This is because getting back deleted stuff is relatively easy with git, whereas finding broken behavior can be quite time-consuming.
Therefore, we definitely do not want to introduce any silent bugs and I agree with @alexschmander.

[alexschmander]

Someone with the correct permission has to change the required CI jobs for this to be able to merge.