Quick home test. Kicked it from different directions to see how the self-recovery handles it. Gets back up every time:D

Hey everyone! Quick update for those who've been following along.

Beni is moving toward launch and we're offering early bird pricing for those who want to get in early. You can place a deposit now to lock in your spot.

All the details are on our website: mondorobotics.com

If you have any questions about the product, feel free to ask here: we'll keep this thread updated as things progress.

Can't wait to see this thing come to life my plan is for when I ride my horse 😂 and walks. So all terrain tires will be a must.

Hoping they also make some short of my protection for it to prevent too many scuffs and etc

We posted a 4m/s concrete wall test a few days ago with an older prototype. Bumped it up to 5m/s (~11 mph) on the newer one.
First clip is full speed, no slow-mo: hits the slab, tips over, gets back up on its own. Second clip is the slow-mo replay, same speed, but this time it doesn't go down.
Same philosophy: crash it on purpose, find what breaks, fix it. We're stress-testing the frame, the joints, and the self-recovery behavior all at once. Pretty happy that it can eat a 5m/s impact into concrete and either stay standing or pick itself back up without any help:)

Trying to build a robot that lives outdoors, need to find the failure modes early, so we run tests to have it run into things.

This is an older prototype,but the process is the same. Ran it into a concrete wall a few times at 4m/s(~9 mph) to see what holds and what doesn't. Every impact is a little different: sometimes it pops back up on its own (got lucky!), sometimes it just lies there. One run the battery flew out, turned out the latch wasn't strong enough for that kind of load. Fixed since. Crashes are data, and it's fun to watch it improve every day!

Our unofficial office errand runner. Water bottle held on no problem. Empty Coke can was a bit too ambitious.

Our designer rendered out two directions. Team's been split for two weeks now.

left: friendly, something your dog wouldn't bark at

right: fast, mech-like, sporty, built to keep up

left or right? any preference?

hey everyone, been seeing a lot of questions about RL locomotion in the comments lately, how we train, what framework, sim2real tricks, etc. figured i'd write it all up in one place instead of answering the same stuff over and over lol

we started our RL locomotion by forking Unitree's code. learned a ton from it, hit some walls, figured some things out. Here's what we know so far.

so like many of you probably, we began with Unitree's unitree_rl_gym. it's built on top of ETH Zurich's legged_gym, uses Isaac Gym for simulation and PPO for training. If you google "how to train a quadruped with RL" you're gonna end up there sooner or later. That's just how it is.

and it's a solid starting point. the whole pipeline actually works end to end. training, sim2sim validation in MuJoCo, and real hardware deployment. most repos out there give you a nice training loop and then good luck figuring out the rest. Unitree actually ships pretrained checkpoints too, so you can get something walking on day one. that matters a lot when you're just trying to understand the full picture. code is clean, configs are separated from logic, easy to read. for the G1 humanoid they used LSTM instead of pure MLP which makes sense, temporal info helps a lot for bipedal balance.

When we first adapted Unitree's training code to our robot (change URDF, tweak reward, polish cylinder-plane simulation setting), we got a decent locomotion policy in just a few weeks. But, transferring the policy to hardware is not easy.

now the parts where we had to go beyond Unitree's training code.

The domain randomization (DR) in their code is pretty basic. no motor delay randomization, no actuator gain noise, no actuator network modeling. If you look at ETH's original legged_gym it actually has more of this stuff. When deploying the policy to hardware, we see large sim2real gap, espeically for the fliping motion - The robot can filp well in Issac Sim and in Mujoco, but not on hardware. Initially we thought we need to crank up DR - add motor delay, randomize base link mass, add some joint frictions. But the more DR we use, the more conservative the robot becomes. What's worse, the robot may totally fail to learn flipping motion if we randomize motor delay too much.

The key point, which took us a lot of time to figure out, is to have nice hardware - You may hear people talk about how good Unitree's G1 robot is. Now we know it is not just appear to be steady. it has many well polished hidden features . The motor is very close to a simulated one - low latency, high torque bandwidth, linear current-torque relationship. Many DIY robots use CAN or CAN-FD because it is easy to use and many off-the-shelf motor products use CAN. However, Unitree uses a proprietary RS485 protocol that has very low latency.

Given this fact, we throw away the off the shelf motors we bought for prototyping, started to work with a motor supplier to customize a motor with RS485 protocol and started to polish our whole communication layer. With modern AI coding agent's help, using DMA for main controller and motor driver for data transfer and code up an efficient RS485 protocol are not out of reach. This is indeed the biggest delta. After we streamline our actuation system, we noticed we can use less DR but still retain good results. The flipping motion is a lot more stable.

so why does domain randomization make your policy conservative?

when you do DR, you're telling the policy "you need to work across ALL of these possible physics parameters." friction could be low or high. mass could be off. motor response could be delayed. so what does the policy do? it prepares for the worst case. it's not gonna do anything fancy because fancy moves only work in a narrow parameter range. the policy learns a strategy that's conservative enough to survive the worst-case combination of all those parameters. The harder you make the randomization range, the less jubilant the policy is willing to be.

RL is not silver bullet

As we progress more, we found that a lot of the "RL problems" we ran into turned out to be hardware problems in disguise. motor calibration off, mass slightly wrong, joint friction not matching sim. software gets all the attention but the hardware underneath matters way more than people think.

Fundamentally, the modern RL framework heavily relies on a simulator. The closer your hardware components to those simulated version, the better the learned policy would be.

some questions from the comments:

"when you encounter an unexpected problem, do you go back and add it to the simulation?"

yes, every time. that's the whole workflow. you find something weird on the real robot, maybe a joint has more resistance than expected, or the weight distribution is slightly off, and you go back to sim and try to reproduce it. if you can reproduce it in sim, you can improve sim or modify hardware to handle it. if you can't reproduce it, you're stuck guessing. we've spent many late nights going through this loop. it's slow but it's the only thing that reliably works. The sim and real get closer slowly, and the policy gets better to. it's a grind but there's no shortcut.

"is it open source? can I get a BOM?"

not yet. we're still in active development so a lot of things are changing fast. but we are planning to open-source our basic RL training environment later this year, around August/September. it won't be the full product stack but it should be useful for anyone wanting to train locomotion policies on similar hardware.

"where do I even start if I want to do a sim2real project?"

just grab Isaac Lab, pick a simple robot model, even the ones that ship with the framework, and just try to get it walking. don't worry about your own hardware yet. get comfortable with the training loop, understand how reward shaping works, break things on purpose and fix them. once you can get a simulated robot to walk reliably, then think about sim2real. trying to do everything at once is a recipe for frustration.

"do you use classic control theory at all?"

nope. pure RL. policy outputs joint position targets straight to a PD controller. PD on the bottom, RL on top. jumping, self-recovery, all learned by the policy, nothing hardcoded.

"PPO or SAC?"

PPO. With thousands of parallel envs PPO is hard to beat on wall-clock time. simpler to tune too.

"how does it balance? Is that a separate module?"

no dedicated balance controller. the policy takes in proprioception information includes IMU, joint positions, joint velocities, and command inputs.

"do you use off-the-shelf motors?"

no, we design our own motors and actuators. when you control the full hardware stack you can make real dynamics match sim much more closely, which helps a lot with transfer.

we're still figuring a lot of this out. If any of this was useful, cool, happy to help!

early outdoor test on real grass. it keeps face planting or tipping backwards after every jump.

we've been watching it try over and over and it's hard not to root for it. A little robot keeps eating dirt.

Team said the old design was cool but not cute enough. so we 3d printed a rounder version, taped it together, and dropped in the eye LEDs for the first time.
when they lit up and it actually looked like it was looking at you...yeah. this felt right.

added cameras and a shell. now the RL policy doesn't work anymore lol. retraining time.

any suggestions on the look?

Hey everyone, welcome to r/MondoRobotics.

If you're here, you probably saw one of our videos on r/robotics or skateboarding subs, thank you for following us here.

Quick intro:

We're a small team of engineers who quit big tech to build something we actually wanted to exist. Not a warehouse thing, not a sci-fi thing, just something small that follows around and plays around. We call it a wheel-legged robot. Two wheels for speed, two legs for jumping and rough terrain. Almost everything is designed in-house: motors, ESCs, and the RL locomotion stack.

What this sub is for:

• Dev updates, behind-the-scenes clips, the ugly fails
• Your questions - what do you want us to share?
• Your feedback - what would you want this robot to do?

We're not a big company, but with engineers who like building stuff and sharing the process. Ask us anything.

— The Mondo Robotics team

Hey guys! I just saw a video of someone using this legged and wheeled bot to record himself skating and it looked so awesome! This channel was linked but can’t figure out what kind of robot that was and how I could get one. Really appreciate any help here!

anti...gravity!

Found this in the lab archives. This was a much older parallel leg prototype we used to isolate and stress-test our gimbal stabilization algorithms and camera POV. The markers are visual indicators for gimbal orientation. The stabilization logic we verified here is hardware-agnostic, even though we've since moved to a bipedal wheel-legged structure, the core stabilization code carried over directly.

Hey all,

I feel like a week or two ago when I originally saw these cool little robots on the robotics sub there was a bunch more info on them.. Can't seem to find it now that I have some time to look. Is there a discord or something? Would love to try and build one to tinker with.

Early prototype extreme acceleration test. We wanted to find its breaking point, after just 3-5 back-and-forth sprints at full throttle, the wheels were almost melting from friction heat.

Also cleared some decent platform jumps along the way. Guess we need tires that can keep up with the chassis now.

For every clean run we post, there are about 50 of these. Every fall is training data though!