Mecanum wheels can be erratic.

@jimgilliland Welcome to the forum Jim. I have a similar background but started at IBM in the late 60's only to leave for a competitor in the 80's.

I have the same kit but I have moved and my shop is a mess. That along with some health issues has slowed me down a lot but I should get the kit built this winter. I can't help yet, but I will follow this topic so Ican benefit from your experience. 

One thing I just thought of. Maybe take a slo-mo video of the car to see if you can observe what is happening. If one motor is going faster then you may be able to see and then take some steps to sync them.

Good luck.

Posted by: @zander

↑

One thing I just thought of. Maybe take a slo-mo video of the car to see if you can observe what is happening. If one motor is going faster then you may be able to see and then take some steps to sync them.

That's a great idea!  I think my phone is capable of that kind of video.  I'll look into it.  

My gut feeling (based mostly on experience with other cheap little robots from Amazon) is that these wheels are just not capable of providing the traction needed for proper Mecanum operation.  Effective and accurate strafing with Mecanum wheels requires a pretty firm grip on the "road" from the rollers on those wheels.

In fact, that thought gives me another idea.  I wonder what would happen if I added some additional weight to the load?  The batteries are pretty heavy already, but maybe a bit more weight would improve the traction.  

Another thought:  What if I lowered the speed when strafing?  Is it possible that these wheels would perform better if I didn't push them so hard?  My strafing speed is set at 150.  I'll cut that in half and see what happens.

It seems I have a few things to look into.  But don't let that stop anyone from chiming in.  I appreciate the help.

Off-topic:  IBM 360 Macro Assembler?  Wow, I don't think I've written any of that since college.  But it was a useful skill even when writing in high level languages.  You needed it to be able to figure out what was going on when something crashed.  

Even Intel Assembler I haven't written since the 80s.  Back in the day, I wrote some coding articles for Byte magazine.   Byte stopped publishing 25 years ago, so it's been a while.  🙂   Maybe there is a forum here where we can talk about this stuff.

Jim

First off... welcome to the forum and it sounds like you have done an impressive job already!  Congratulations.  

Posted by: @jimgilliland

↑

That's not what I had hoped to show my grandkids!    But I'm not sure how to fix it.  Do I need better wheels, and if so, how do I choose them?  Do I need to fine tune the motor speeds, and if so, how do I determine which motors need adjusting and by how much?  I've read that these wheels need the robot to be well balanced (both side to side and front to back), but mine is actually pretty well balanced, so I don't think that's the problem.

It would be very helpful if you provide a link to your exact model (or just include a picture).  I think you have to have about 10 posts before the forum will let you post pictures and maybe even links.  I don't recall.

I've never used the Mecanum just because of the inexact issues it can contribute like you mention.  Some have great success with them.  I know the children in our high-school went away from them in their early F.I.R.S.T. robot projects.  If you are talking about a 4 wheel bot with all 4 being driven, I think that will be part of the problem.  If it only has 2 wheels being driven, these should use regular wheels.  These will completely control the speed and direction and by differential, steer the bot.  The two other Mecanum wheels just go along for the ride and slide side-ways as needed.

The main take-away, only two wheels should provide all control.  Otherwise, they'll fight each other depending on which one has the best traction... as you have observed on different surfaces.  Here is a similar robot with only 2-wheel drive and WiFi, web-based interface.  Any shenanigans of the bot are purely psychotic driver error, not the bot doing something unexpected. 😆 

Posted by: @inq

↑

If you are talking about a 4 wheel bot with all 4 being driven, I think that will be part of the problem.  If it only has 2 wheels being driven, these should use regular wheels.  These will completely control the speed and direction and by differential, steer the bot.  The two other Mecanum wheels just go along for the ride and slide side-ways as needed.

Are you suggesting that the robot could use two regular wheels and two Mecanum wheels, where the undriven Mecanum wheels would be used like the training wheels on your robot?  

Mecanum wheels are intended to have each wheel driven independently.  Strafing is accomplished by driving the wheels with different speeds and usually in different directions.  That is inherent in the design of these wheels.  But I think you know that.  So I'm not entirely clear on what you are suggesting unless it is to give up on the Mecanum wheels and use a different method of driving the robot.  

I've built a number of small traditional 4-wheel robots and at least one that used two wheels and a roller ball.  I was trying something new with this one.

It appears that I'm not able to post links, but here is the ASIN for the Amazon product:  B093WDD9N5

If you search with that as your argument, you should find the right product.

@jimgilliland,

Unfortunately, the forum won't let anyone post Amazon links.  However, I found if you edit the link and take off the prefix, "https://www." portion, it will accept it and let us browse to it.  You should be able to re-edit your last post to fix it.

Edit:  You can also hit the Preview button below to see if you were successful.

@jimgilliland I love MASM. Since I was IBM mainframe hardware trained, then OS trained MASM was a high-level language compared to machine code, then I was trained on PL1/I WOW what power. After a few years of working with MASM, my personal macros made the source look like a high-level language. A few years after retiring, I thought I would never go back to programming, so I tossed every last bit of code I ever wrote. BIG MISTAKE!!! I could use some of that now, and I am working at the most important bit, the doubly linked named lists (stolen from the OS I last worked on)

@inq @jimgilliland I use a browser extension called 'Amazon URL Shortener' that avoids the forum glitch, no editing needed and easier to grab in the first place as well.

@jimgilliland I am thinking of using 4 wheel encoders and then using the feedback to adjust the motor revs so all wheels are identical. Might need low-level (asm? grin) ISR code for each sensor? Some calibration routines to lay down a base timing since wheel sizes are likely not equal. Save the data in EEPROM.

Posted by: @jimgilliland

↑

Are you suggesting that the robot could use two regular wheels and two Mecanum wheels, where the undriven Mecanum wheels would be used like the training wheels on your robot?  

Mecanum wheels are intended to have each wheel driven independently.  Strafing is accomplished by driving the wheels with different speeds and usually in different directions.  That is inherent in the design of these wheels.

Yes, those type of wheels do offer a lot of options to a builder.  If 4 are set up properly and motors commanded in a certain way, the thing will walk sideways in a nice strait line perpendicular to the normal motion. 

https://www.youtube.com/shorts/scNMzjRVRT0

Or something like this makes for a very interesting omni-directional bot, but requites a lot of trigonometry to handle controlled behavior. 😉 

But... as you have found out, it can give a more erratic bug-like behavior also.  If you were to drive it over something very irregular like outside on an undulating surface, you'd be hard pressed to keep a strait line.  However, their benefit in flexibility is derived from having more degrees of freedom (DoF) than a standard wheel tire.  You don't see those on cars (and never will) or things like tracked bull dozers or even on something like a 4 wheel skid-steer

... and it is simply because it is not entirely controllable which DoF is going to take precedence over uneven ground.  For a robot toy, it's fun.  

As you mention and already know, you obviously don't need these type of wheels to do a a strafing maneuver, but the wheels have to skid, these don't.  If you see robots that use these type of wheels they attempt to put most of the C.G. over the driving (non-mec) wheels and have the mec's on the perimeter.  It's not a very good picture, but this uses two driven wheels in the center that are standard and four outer wheels are Mecanum.  This bot is over 100 lbs and very fast and is for competition.  It needs to have well-defined control manners. 😊 (At least as well as high-school students can muster).

If you want controlled, normal behavior, it would be helpful to remove some DoF in the system.  As a simple test, put some of the big office rubber-bands around two of the wheels.  I've never tried this (again, I've never used these type of wheels), but this will remove their ability of the rollers to roll effectively.  It won't model exactly what I'm suggesting since the other two will still be driven, but you should see a different behavior.  If you put rubber bands on all 4, it should basically act like the 4-wheel model you've created before (if the rubber-bands can stay on). 

It might help you to confirm if its the mechanics of your system or your software implementation.  It could simply be you have a software issue.  If so, then you might want to post that and there are lots of people here that will be glad to help you.  If you do, make sure you use the "<>" button to place your code.  Some people here get cranky if you just paste it into the editor. 😎 

VBR,

Inq

@jimgilliland,

Posted by: @zander

↑

@jimgilliland I am thinking of using 4 wheel encoders and then using the feedback to adjust the motor revs so all wheels are identical. Might need low-level (asm? grin) ISR code for each sensor? Some calibration routines to lay down a base timing since wheel sizes are likely not equal. Save the data in EEPROM.

I didn't think of this.  Ron is also right.  If those motors are simple DC motors, they will always have slightly different torque, speed and even when they start rolling based on the PWM setting you send to them.  If you turn the bot upside down and up the PWM on all four very slowly, you'll see them start up at different times.  Motor variability alone will cause the bot to veer because you have too many DoF.  I don't use regular motors in my bots, but I'd think at higher speeds the motors might behave more like each other, so while moving slow, you might see erratic behavior, at a high speed setting, it might track straighter.  

@inq I probably could have if I'd been here at the time, but it's no longer an option.  Still, the SKU (ASIN, in Amazon's terms) is a definite identifier if someone wants to see what we're talking about.  It's just like a lot of other similar models anyway.

@jimgilliland, The last 2 replies I did were done having seen it by your ASIN.

Posted by: @zander

↑

@jimgilliland I love MASM. Since I was IBM mainframe hardware trained, then OS trained MASM was a high-level language compared to machine code, then I was trained on PL1/I WOW what power. After a few years of working with MASM, my personal macros made the source look like a high-level language. A few years after retiring, I thought I would never go back to programming, so I tossed every last bit of code I ever wrote. BIG MISTAKE!!! I could use some of that now, and I am working at the most important bit, the doubly linked named lists (stolen from the OS I last worked on)

That all sounds like fun to me.  😀 Is there a forum here for this kind of conversation?  I love the feeling of watching my code come to life, especially if I feel like my code is somewhat "elegant" (which usually means doing a lot with few lines of code).

I would definitely NOT call my code on this project "elegant".  Basically, I borrowed code from several different sources and strung it all together.  The only interesting part is putting the I/P address onto the LED matrix on the Arduino.  That's new enough that there are no libraries for displaying text on it.  I did some searching and found a guy who had built a library for displaying two digit decimal numbers on it.  I looked at his code, and could not for the life of me figure out why he stopped at 2 digits when the matrix easily had room for 3.  So I modified his code to handle 3-digit numbers, and then I could write my I/P address in four frames.  I even saved a spot for a "dot" at the end of each of the first 3 numbers.  😀 

@zander That sounds workable and interesting.  Keep us posted when you get into the project.  Don't use the Uno R4, though.  It has a completely different setup for interrupts, and I couldn't figure out how to make them work.  Maybe there will be a library for it someday, but for now it's pretty challenging.  I eventually found a way (not very elegant, either) to do what I needed without using interrupts.  That's what I get for being on the bleeding edge.