Considering positioning strategies for autonomous mechanum-wheeled robots
Considering positioning strategies for autonomous mechanum-wheeled robots
Disclaimer: this is not specifically for a commercial product, but various things I design sometimes get commercialized. I mention this so that you may decide whether you want to weigh in. If it's commercialized, I will probably make very little money but a bunch of university students may get a neat STEM program in the countryside :D
That out of the way, I've designed some boards for a Wi-Fi controlled robot with mechanum wheels. So 4 independent motor drivers, one for each wheel, allow omnidirectional motion. It's built around a Pi Pico W, 4 SOIC-8 9110S motor drivers, and some buck/boost converters to give the system a 5V and 12V line. It's very basic, mostly made to be cheap. Here's a photo:
Right now it just receives UDP communications (a little app written in Godot) and activates the motors in different combinations -- very "hello world". I'm planning to add some autonomy to move around pre-generated maps, solve mazes, and so on.
I have foolishly used 2-pin JST connectors for the motors, so using motors with rotary encoders would be a pain without ordering new boards. I'll probably fix that in a later board revision or just hack it in. Also the routing is sloppy and there's no ground plane. It works well enough for development and testing though :D
What I'm thinking about right now, is how to let the robot position itself in a room effectively and cheaply. I was thinking of adding either a full LiDAR or building a limited LiDAR out of a servo motor and two cheap laser ToF sensors -- e.g. one pointed forward, the other back, and I can sweep it 90 degrees. Since the LiDAR does not need to be fast or continuously sweep, I am leaning toward the latter approach.
Then the processing is handled remotely -- a server requests that the robot do a LiDAR sweep, the robot sends a minimal point cloud back to the server, which estimates the robot's current location and sends back some instructions to move in a direction for some distance -- probably this is where the lack of rotary encoders is going to hurt, but for now I'm planning on just pointing the forward laser ToF sensor towards a target and give the instruction "turn or move forward at static speed X until the sensor reads Y", which should be pretty easy for the MCU To handle.
I'm planning to control multiple robots from the same server. The robots don't need to be super fast.
What I'm currently wondering is whether my approach really needs rotary encoders in practice -- I've heard that mechanum wheels have high enough mechanical slippage that they end up inaccurate, and designers often add another set of unpowered wheels for position tracking anyway. I don't want to add more wheels in this way though.
On the other hand, it would probably be easier to tell the MCU to "move forward X rotary encoder pulses at a velocity defined by Y pulses per second, and then check position and correct at a lower speed" than to use a pure LiDAR approach (e.g. even if rotary encoders don't give me accurate position, on small time scales, they give me good feedback to control speed). I could possibly even send a fairly complex series of instructions in one go, making the communications efficient enough to eliminate a local server and control a ton of robots from a cloud VPS or whatever.
Anyone have some experience with encoders + mechanum wheels that can offer a few tips my way? At this stage the project doesn't have clear engineering goals and this is mostly an academic exercise. I've read that using a rigid chassis and minimizing the need for lateral motion can reduce slippage, reading through a few papers didn't get me any numerical indication of what to expect.
I think mecanum wheels slip quite a bit. So I'm not sure how effective those encoders are. But I've only ever tried 3d-printed ones. So I'm not super sure.
You're sure your STEM students are ready to handle the LiDAR? Manage point clouds, do the arithmetic, path planning etc? We had a practical course with little robots. But they had 3 of those sharp distance sensors at the front and a bumper with a switch. This was enough to teach many concepts and also enough to implement for the students for something that was just a project and not a full time job. But I'm sure that depends on what exactly you want to teach...
And our robots hat the motor drivers (h-bridges) replaceable on socket terminals because every so often someone wasn't very clever or didn't listen in the lectures.
They're university software engineering students, probably a year or two into their degrees. I'm hoping to provide the robots as completed units that are controlled via API, because we're not likely to get many students with electrical, mechanical, or embedded backgrounds. You're right about the complexity though, and that's something I've been thinking about -- I guess I'll start out with a bit of optimism regarding their talents, and scale back if needed :D
I don't really have a scope, budget, timeline, or audience properly defined for this project -- in short my client has a STEM program for building and interacting with digital maps, but it's way too boring and I'm determined to breathe some life into it. So I'm going to have to play a lot of things by ear.
Well, kids / young people / students will surprise you anyways. No matter what you planned ahead. I think teaching this way just requires you to stay flexible and try things with the students and see what works. University students will benefit from a little challenge, but it shouldn't be impossible and get them frustrated. I've never taught myself, but I bet it's difficult to hit that balance.
Programming little robots is awesome, though. I think it's on a whole other level to see robots move and do tasks, than to look at your screen and program something that changes a few pixels there. My university course was more related to embedded devices and closer to the electronics. It teaches you valuable lessons when forced to interact with some electronics, real-world physics, constrained resources and you need to get your maths right. Usually students are concerned with something like Java, learning object-oriented programming or handling some big frameworks. Or learning maths. And robotics teaches you to really pay attention, combine different skill-sets and do things without an easy route available.
Maybe it's just me who likes electronics too much. But I'm sure the kind of motivation you get by watching a real robot move and it runs your code, is unique. And kind of universal. You can do this in pre-school or in university to spark their imagination and motivation.
Your task is a bit different. If you're teaching something like simultaneous localization and mapping and the students also have to deal with all the robotics, sensors and real-word problems, this might be more of an ordeal for them than fun. Even dealing with noisy sensor values is a hassle until you get to grasp the bigger picture.
If you're giving them access to an API, you can choose and adjust what kind of abstraction you're providing them. Give them something high-level or have them do more work. You could prepare most of the implementation and adjust the level of detail while teaching. Maybe skip something and give them working code via your API so they can focus on the problem they're actually supposed to learn. You can also do it the other way round. Let them start with all low level stuff handled for them and learn the big concepts. Then let them dig down and see what your API functions have abstracted away until then. This way around you won't run out of time.
I'm sure including actual robotics is going to get them more motivated in contrast to running a simulation.
Assuming that there is at least some amount of slippage between the wheel and ground, it seems to me that you'll need to regularly check the ToF sensors anyway. I've found that encoders are fantastic for a lot of things, but not so much for measuring distance because of the problems you've described. Perhaps a recurring local check on a reduced set of points to verify location then forward the full cloud less often for further remote processing? It really sounds like you have a tradeoff depending on whether you value accuracy of location or accuracy of wheel rpm (analogous to speed). Using both would give you a nice way to calculate the ideal motor rpm to minimize slippage in a surface agnostic way.
Ok yeah -- I'm leaning toward relying more on the laser ToF than the rotary encoders.
A simple algorithm of 'pick a lidar point and drive toward it' does sound simplest. Thanks for weighing in!
Even though you add encoders on the wheels it’s still an open loop locomotion method, you need the room to have a feedback of the position on the plane/in the space
Yup. Agree. Probably going to go with a LiDAR-first approach.