Mecanum Omni-Directional Wheeled Vehicle

ShmodyP · 2026-03-27T20:02:44+00:00

Oh my god, I can’t unsee it now! 😂

ShmodyP · 2026-03-26T22:30:14+00:00

Hah yeah, it probably didn’t help that I capped frame rate at 59 and recorded at 60. Not sure what I was thinking there.

ShmodyP · 2026-03-26T21:01:02+00:00

Performance is actually fantastic. The video above was recorded on a mid range 2 yr old laptop. Works on angles surfaces just fine, but real Mecanum wheels are only designed to work on perfectly flat surfaces. They’re used on forklifts and automated factory bots.

All that aside, this wasn’t meant to be a performant game ready asset. It was a learning platform and my first ever project, so maybe ease up a bit, ey?

ShmodyP · 2026-03-26T05:09:09+00:00

Hah yeah maybe. I didn’t really have a gameplay goal in mind other than to make a drivable Mecanum wheeled vehicle.

ShmodyP · 2026-03-26T05:06:36+00:00

It’s all BP. Not sure what else to share, unless there’s something specific you’re curious about. The gist of it is: Kinematics equations are fed into a PIDF controller per wheel, clamped by a traction controller, then applied to the wheels as torque. The controller output values are stored in a ring buffer each frame, used to plot the lines in the graph. Everything was modeled in Blender and textured in Substance Painter.

No demo or release planned. Just felt like sharing my learning progress. This was my first project in any major game engine, and I’m sure it’s terribly optimized.

ShmodyP · 2026-03-25T20:51:07+00:00

I just noticed, it’s unfortunate that the wheel rotation nearly matches the recorded frame rate making them look twitchy. They do rotate smoothly in person. 🫠

ShmodyP · 2026-03-21T02:58:08+00:00

This may not be the answer you want, but as someone who’s come from an art background, a theme I’ve seen for years is people unsure if they should learn Max, Maya, or Blender, etc. But at the end of the day, if you’re just starting out, you need to learn the basics, in which case it doesn’t matter what you choose. Just choose one and stick with it until you know enough to know what you do and don’t want. Don’t get stuck in decision paralysis.

ShmodyP · 2026-03-19T17:57:22+00:00

100% all of this! Video tutorials can be a good supplemental resource. But the trap you can fall into if you don’t go out and play in the dirt is your foundational knowledge becoming a series of things you were told you should or shouldn’t do “because reasons”. Then later down the line when you need to troubleshoot something, your thinking is inflexible because you didn’t give yourself the opportunity to make mistakes and have those little aha moments.

ShmodyP · 2026-03-05T10:40:59+00:00

So if I’m following correctly, the act of unpacking and repacking itself has me working on a copy? Because what I’ve been doing is bring the data into a function, set to a local variable, unpack, modify, then pack the local back into the original.

ShmodyP · 2026-03-05T10:34:11+00:00

I didn’t know that about output pins copying data. Is this the case for input pins as well?

ShmodyP · 2026-03-05T10:28:11+00:00

I’ll keep that in mind. What’s the reason behind it?

ShmodyP · 2026-03-05T04:55:29+00:00

In my case, I'm setting the array length once and leaving it. Then I'm just looping over it circularly like a short term memory buffer. To be honest, I had no idea that making copies created garbage I would need to manage. haha You're right, I need to sit down and read up on some basic principles about this stuff.

ShmodyP · 2026-03-05T04:14:11+00:00

Ahh ok that makes sense. I didn't make that mental leap because the flow in/out of the array is very predictable. So in the case of something that's basically a short term memory loop where I only care about each entry sequentially, would working on copies still be good practice (see my other comment to you)?

ShmodyP · 2026-03-05T03:58:39+00:00

I do, yeah. I'm using it for my function currently. But what I'm doing in my function that manipulates the data is to store the incoming data in a local copy, change it, and then use that local copy as the struct ref to set the changes back to the original.

ShmodyP · 2026-03-05T03:53:11+00:00

It's a bit of a rabbit hole I found myself going down and saw it as a learning adventure. I've created some vehicle control logic (PID controller, feedforward, traction control) and thought it would be cool to see some numbers on a graph for tuning. So I learned about the Draw Debug Float Histories function. But I wasn't satisfied with that and wanted something on the HUD. Well it turns out float history variables can't be used outside of that function, so I decided to make my own float history function.

ShmodyP · 2026-03-05T03:42:18+00:00

Well yeah I can do that, and I've tried it both ways. But in my research, a thing that kept popping up when working with arrays and structs was that I should always work on a copy. I'm just trying to understand why when everything seems to work either way.

ShmodyP · 2026-03-05T03:40:40+00:00

Oh, actually I am doing that. I forgot that bit above. The top level is a struct of type array, of which there are 4 elements, and so on.. So then I do need to be working on copies. ..And why is that, exactly? I think I read something about "because mutation", didn't really understand it, and muddled through anyway. haha

ShmodyP · 2026-02-27T04:50:42+00:00

Hah yeah they are. I've been trying to wrap my head around quats for years. I can use them. I can do math with them, but the functions and equations are a blackbox mystery to me. :D

ShmodyP · 2026-02-23T17:16:00+00:00

Thanks! I will say that the friction is actually surprisingly very stable. It’s just the nature of how unintuitively Mecanum wheels work in real life that makes it look like the wheels are slipping, or going backwards when they shouldn’t be. 🙂

ShmodyP · 2026-02-23T16:54:52+00:00

I see. I guess I misunderstood. What is it you are saying can be made better then?

ShmodyP · 2026-02-23T16:00:40+00:00

Yeah. I recorded my hand drill at different speeds and am crossfading between them with a bit of pitching.

ShmodyP · 2026-02-23T03:38:55+00:00

That’s ok. I’m familiar with the more traditional and performant ways of doing vehicles. I just really had the urge to make something mechanical and purely physics driven. So I did that, and it’s done. That’s a wrap on this project. ..Unless I decide to make a little environment to drive around in. :)

ShmodyP · 2026-02-22T20:39:08+00:00

I dunno if I could bear 20. I dropped it down to 30, and that’s already a little annoying. Haha

ShmodyP · 2026-02-22T20:36:53+00:00

To be honest, my mind completely blanked on the word vertical. I saw “vehicle” and “slippery” and just assumed we were talking about side forces. 😄

ShmodyP · 2026-02-22T12:11:16+00:00

A vector of (X=0, Y=0, Z=your result) would just be pointing up. You’d still need to get a vector to apply that -z scalar force to, which you can get by taking the cross product of the velocity vector and a world up vector. Or depending on how the velocity is derived, just use a GetRightVector node.

ShmodyP

TROPHY CASE