Fake wheel physics vs modelling every roller - which camp are you in?

Honestly, I always lean toward modeling the junk as accurately as possable, even if it makes the initial setup take forever. When I was working on a simple differential drive chassis last year, I tried the shortcut approach, modeling the tires just as high-friction circles. It looked perfect in the simulator, but when we moved to the bench, the real motors had gear train slip that we hadn't accounted for. The whole odometry stack started drifting after just a few meters of travel, and debugging that mismatch between the ideal model and the physical reality was way more painful than the original modeling effort would have been.

It felt like we spent two weeks fixing a simulation abstraction that should have been fixed in the CAD model. The friction coefficients on the real rubber tires versus the simulated contact patch were totally off, and we had to stop and rebuild the wheel assembly model to incorporate the real material properties. If I had taken the time to model the wheel profile and the load distribution accurately, I prolly coud have spotted that early on. I agree that focusing on planning is a huge benefit, but I think that getting the basic kinematic model solid first just buys you sanity down the line. It forces you to understand exactly how the hardware fails or deviates before the software even tries to command it. It's tedious, but it saves massive headaches when you're trying to find out why the robot moved a centimeter when the control system told it to move five.

I went through almost the same thing with an omni base I built for a warehouse shelf demo, three balls on top of regular casters, and I skipped roller geometry entirely. Cylinders with split friction in Gazebo. Strafed fine, spun fine, and I slept well because I stopped treating the simulator as a truth machine and started treating it as a stress test for my code.

Here's the thing I'd push back on from the reply above: the failure mode they hit, gear train slip, was never going to show up in a physics engine no matter how pretty the wheels looked. Sim fidelity has a ceiling, and pushing your wheel model closer to that ceiling mostly buys you more solver jitter, not more honesty. What actually saved me on hardware was doing the mecanum math by hand in a spreadsheet first, so I knew what wheel speeds the controller should be commanding, then checking the real bot against that instead of against the sim. My take is that the shortcut is fine as long as you know exactly which lie you're telling. The sphere wheels lie about contact, fine. Just don't let the sim lie about your controller gains too. Tune your velocity loops in sim assuming they're wrong, and expect the first carpet run to be a retune, not a betrayal. That's true even if you spend a month modeling rollers, so spend the month on mapping and planning instead, like you alredy did.

I did the sphere trick on my own mecanum build and never looked back, beacuse here's the dirty secret: real mecanum rollers slide sideways all the time anyway. Half the rollers are just rolling free at an angle at any given moment, so the anisotropic friction hack is honestly closer to reality than modeling the rollers would be. What actually bit me was motor response, the cheap gearmotors I used had way more lag than the sim. So I'd say spend an afternoon pushing the bare chassis around on your actual floor with a tape measure before trusting any model. Curious what floor surface you're planning for it, since that changed my tuning more than anything in CAD did.

I land somewhere in the middle on this. Ran a tracked rover project where I spent two full weekends building a proper contact model, and the honest sim-to-real gap was still about 4cm of drift over a 3m straight run. All that modeling precision got eaten by carpet compression and battery sag anyway. What actually closed the gap was throwing noise into the sim, small random velocity offsets on every command. My take: your sphere hack is fine for the geometry question, but go uglify your perfect world with noise and delays before you trust any of it.

I stopped stressing about wheel fidelity once I got a proper reference floor. My sim-vs-real comparisons were garbage til I put down a big sheet of hardboard in the garage, because carpet and tile were giving me completly diffrent slip behavior and I had no idea which one to trust. On the hardboard the mismatch was small enough that the sphere hack held up fine, and anything left over I just chalked up to motor slop. My take is the shortcut is fine if you control the test surface. What floor are you planning to run on when the real bot shows up? That answer matters more than the roller geometry imo.

Not sure I buy the claim that a more accurate wheel model would have caught your problem. Gear train slip lives in the motor and gearbox, nowhere near the tire contact patch, so no amount of roller geometry or load distribution detail would have flagged it. Sounds like what you actually needed was a drivetrain model with some backlash and inefficiency thrown in. I had a similar miss once where I pol-ished the wheel contact and then got burned by my controller assuming instant velocity changes, which is also a modeling choice nobody warns you about. Curious wheather your odometry drift got better once you fixed the slip, or if the friction values were eating you too.

Update: decided to stick with the sphere shortcut after reading the point about real rollers slipping sideways constantly. That honestly settled it for me, the anisotropic friction hack is closer to how the thing actually moves than a pretty model would be. Gonna keep the detailed wheel geometry in the CAD for when I print the real wheels though, so the build side stays honest even if the sim side doesn't.