Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Mecanum Drive control (http://www.chiefdelphi.com/forums/showthread.php?t=153842)

AriMindell 17-01-2017 21:28

Mecanum Drive control
 
We're getting ready to use a octocanum drive on our robot this year for the first time ever (very exciting!) We have a lot of past knowledge about the tank drive side, and I have thought pretty carefully through shifting, but I am inexperienced with controlling a mecanum drive.
We built a prototype mecanum bot and programmed it using some of Ether's control algorithms supplied here. We were able to get this working with regular and field-centric control, but found that due to the imperfect speed-voltage relationship, the robot does not always move in exactly the intended direction.
My first thought to fix this was to speed-control the wheels. Instead of mapping the joystick values to percent voltage of the wheels, I want to map them to percent of max speed of the wheels, using PIDF to control the speed.
Is this a viable solution to the problem? is this a common problem? what are some other solutions/implementations to improve the reliability of the robot's motion?

SamCarlberg 17-01-2017 21:43

Re: Mecanum Drive control
 
Mecanum drive is already built into WPILib

You could do PIDF velocity control for each wheel if you really wanted. But the library code works quite well and it might not be worth the time a custom PIDF control setup would take to implement correctly.

David Lame 17-01-2017 22:28

Re: Mecanum Drive control
 
In the past, we've had good success with using a gyroscope to correct the tendency to drift on mecanum drives.

I would think there would be a problem trying to use encoders to correct the wheel speeds, although I've never tried it. The problem I would anticipate is wheel slip. When using encoders for other purposes, I found there was a fair amount of wheel slip with mecanum wheels. To keep the thing driving straight, you would have to have an accurate measure of wheel speed on the ground, and slip would get in the way.

Back when I first joined as a mentor in 2014, I found a good article online about how to use the gyroscope for correction, and we implemented it that year. It involves a PID loop with the gyroscope measurement versus the desired angle for the error input. That article pointed out a few "gotchas", such as the unfortunate tendency for gyroscope chips to drift, and the interesting "kick" that can happen at the end of a turn, but it gave solutions. Unfortunately, I don't have the link to the article, but some googling should find something similar.

We had a very good programming lead that year who understood the concepts, but he was a bit sloppy. Be very, very, careful to avoid sign errors in your PID constants. If you get it wrong, you could go into what was affectionately known as the "death spiral".

slibert 17-01-2017 22:44

Re: Mecanum Drive control
 
Quote:

Originally Posted by AriMindell (Post 1632709)
We're getting ready to use a octocanum drive on our robot this year for the first time ever (very exciting!) We have a lot of past knowledge about the tank drive side, and I have thought pretty carefully through shifting, but I am inexperienced with controlling a mecanum drive.
We built a prototype mecanum bot and programmed it using some of Ether's control algorithms supplied here. We were able to get this working with regular and field-centric control, but found that due to the imperfect speed-voltage relationship, the robot does not always move in exactly the intended direction.
My first thought to fix this was to speed-control the wheels. Instead of mapping the joystick values to percent voltage of the wheels, I want to map them to percent of max speed of the wheels, using PIDF to control the speed.
Is this a viable solution to the problem? is this a common problem? what are some other solutions/implementations to improve the reliability of the robot's motion?

We've found there are several levels of improvement that can be achieved to get mecanum running smoothly:

1) First and foremost, your mechanical design should strive to maintain equal weight distribution across each of the four wheels. A few years ago we purchased four digital scales just for that purpose.

2) We use the navX-MXP to provide some very cool "drive in a straight line in a given direction" and "automatically rotate to a specified angel" features. There's a robot-level "rotate-to-angle" PID rotate controller that drives this.

In teleop, the rotate PID controller can take over the Z axis of the joystick, while the driver continues to manipulate X/Y direction/magnitude via the joystick.

3) We also use velocity PIDs on each wheel, as you suggest. We found these need a feed-forward component to work at low speeds. We tune them so that we are sure the robot will move at our minimum required speed (e.g., 1"/second) for small rotations.

We found that once the velocity PIDs are tuned well, it becomes very easy to tune the rotate-to-angle PID.

These require encoders on each wheel, and we use the Greyhill 63R encoders as they are very reliable.

And we moved to the Talon SRX motor controllers last year to implement "drive a known distance" commands in autonomous.

If you're new to this, I'd focus first on 1) and then add 2) before tackling 3).

If 1) is ignored, 2) doesn't work very well (we call it the "drunken sailor" effect). And if you do 3), it makes 2) even better.

Our 2017 "Drive Mule" code that implements this is here: https://github.com/Kauaibots/FRC/blo...ems/Drive.java

There's also code in this project we developed to help w/the PID tuning in the commands directory.

JohnGilb 18-01-2017 15:39

Re: Mecanum Drive control
 
Our team took a fairly simple approach with regards to controlled mecanum drive.
  1. Measure our angle relative to the field
  2. Measure our instantaneous velocity

For (1), We used a highly accurate gyro. Today, the navX-MXP is a great choice.

For (2), we put three "follow wheels" on the robot to measure our velocity relative to the floor. These were small omniwheels sprung to press against the carpet with encoders on them.

We then broke mecanum drive into two components - rotation and translation.

The rotational PID attempted to keep robot heading constant unless the driver indicated a change via joysticks.

The translational PID compared the ideal velocity (from the driver's joysticks) to the actual robot X/Y velocity.

Between these two, we had a "rotational intent" and "translational intent" that were fed into the WPILib mecanum library.

This ended up being a good approach for us, since we didn't need to worry about wheel slip - the follow wheels were very accurate throughout the match. (This approach doesn't work as well when the playing field isn't level).

By applying PID on the total output of the system (i.e. how exactly is the robot moving) we were able to account for drift, slip, X/Y friction asymmetry, weight distribution, etc... with this one solution.

slibert 18-01-2017 17:26

Re: Mecanum Drive control
 
Quote:

Originally Posted by JohnGilb (Post 1633097)
Our team took a fairly simple approach with regards to controlled mecanum drive.
  1. Measure our angle relative to the field
  2. Measure our instantaneous velocity

For (1), We used a highly accurate gyro. Today, the navX-MXP is a great choice.

For (2), we put three "follow wheels" on the robot to measure our velocity relative to the floor. These were small omniwheels sprung to press against the carpet with encoders on them.

We then broke mecanum drive into two components - rotation and translation.

The rotational PID attempted to keep robot heading constant unless the driver indicated a change via joysticks.

The translational PID compared the ideal velocity (from the driver's joysticks) to the actual robot X/Y velocity.

Between these two, we had a "rotational intent" and "translational intent" that were fed into the WPILib mecanum library.

This ended up being a good approach for us, since we didn't need to worry about wheel slip - the follow wheels were very accurate throughout the match. (This approach doesn't work as well when the playing field isn't level).

By applying PID on the total output of the system (i.e. how exactly is the robot moving) we were able to account for drift, slip, X/Y friction asymmetry, weight distribution, etc... with this one solution.

This is a really sweet solution.

Is there any mechanical design info or pictures you can post of the spring-loaded omniwheels you're using?

JohnGilb 19-01-2017 14:26

Re: Mecanum Drive control
 
1 Attachment(s)
Sadly, right now the only image I can find is pretty bad (attached). You can barely see 2 of the 3 follow wheels near the center of the chassis. All the spring attachment points and encoder mounts are occluded.

I'll have to poke some of the people who have CAD access to see if they can share anything. =]

TylerHarmon 20-01-2017 09:59

Re: Mecanum Drive control
 
Do not use encoders on mecanums. It will not work. Mecanum wheels slip, which completely destroys the value/quality of the ticks that your encoder returns. How many times a mecanum wheel turns cannot directly be translated into distance. Again, don't try to use encoders it will not work.

If you put a gyroscope on your robot, and you know the direction that you want to be going, you could use a PID loop to keep the robot on the heading. All you would need to do is set the PID's setpoint to the angle that the robot should be at, and that should compensate for a lot of drift.

Good luck,

-Tyler

AriMindell 20-01-2017 10:07

Re: Mecanum Drive control
 
Quote:

Originally Posted by TylerHarmon (Post 1633872)
Mecanum wheels slip, which completely destroys the value/quality of the ticks that your encoder returns. How many times a mecanum wheel turns cannot directly be translated into distance. Again, don't try to use encoders it will not work.

So I agree with this assertion for trying to determine the position of the robot using encoders, but what I meant was using encoders to ensure that all of the motors are actually spinning the same speed (rather than just recieving the same voltage) for this, I think encoders can be adequate, since slipping does not come into play between the motor and the wheel, only later.

In other words, there is very little error in the encoder reading of the wheel angle relative to the robot (maybe some backlash in the gearbox) however I agree that there is a large amount of error in the encoder reading of the robot position relative to the field. Correct me if I'm wrong, but I think that since we are looking to use the first one, encoders are acceptable.

Ether 20-01-2017 15:57

Re: Mecanum Drive control
 
Quote:

Originally Posted by TylerHarmon (Post 1633872)
Mecanum wheels slip, which completely destroys the value/quality of the ticks that your encoder returns. How many times a mecanum wheel turns cannot directly be translated into distance.

Whenever I see someone post "Mecanum wheels slip" I always wonder what they think that means.



Oblarg 20-01-2017 16:33

Re: Mecanum Drive control
 
Quote:

Originally Posted by Ether (Post 1634107)
Whenever I see someone post "Mecanum wheels slip" I always wonder what they think that means.

Well, their effective COF is decreased by a factor of 1/sqrt(2), so I suppose they are more prone to actually slipping.

Ether 20-01-2017 17:28

Re: Mecanum Drive control
 
Quote:

Originally Posted by Oblarg (Post 1634121)
Well, their effective COF is decreased by a factor of 1/sqrt(2), so I suppose they are more prone to actually slipping.

Is that what you meant, Tyler? They're more prone to slipping in a pushing match or hard acceleration? But most of the time, if you're careful, they won't slip?

Or did you mean they slip all the time, which completely destroys the value/quality of the ticks that your encoder returns, and therefore how many times a mecanum wheel turns cannot directly be translated into distance?




TylerHarmon 21-01-2017 13:26

Re: Mecanum Drive control
 
Quote:

Originally Posted by AriMindell (Post 1633873)
So I agree with this assertion for trying to determine the position of the robot using encoders, but what I meant was using encoders to ensure that all of the motors are actually spinning the same speed (rather than just recieving the same voltage) for this, I think encoders can be adequate, since slipping does not come into play between the motor and the wheel, only later.

In other words, there is very little error in the encoder reading of the wheel angle relative to the robot (maybe some backlash in the gearbox) however I agree that there is a large amount of error in the encoder reading of the robot position relative to the field. Correct me if I'm wrong, but I think that since we are looking to use the first one, encoders are acceptable.

Ah, I see what you mean. I think that could work; if you are only looking at the rotations per wheel and not necessarily how far the wheel drives on the floor, you could get more useful data.

However, if your goal is to drive straight, I would suggest using a gyroscope, because even if you drive all 4 (or 8?) mecanums at the same RPM, they still will likely not operate identically to each other because of various conditions like the consistency of the floor that could cause the rollers to spin more/less.

All that said, the main use of encoders is to see how far a spinning motor or axel has moved (and at what speed), so I still can't recommend using encoders with mecanums because they simply, by design, do not give very useful data. Even if you just looked at how far they wheels turned, that data, while perhaps being accurate, would not be very useful.

TylerHarmon 21-01-2017 13:30

Re: Mecanum Drive control
 
Quote:

Originally Posted by Ether (Post 1634157)
Is that what you meant, Tyler? They're more prone to slipping in a pushing match or hard acceleration? But most of the time, if you're careful, they won't slip?

Or did you mean they slip all the time, which completely destroys the value/quality of the ticks that your encoder returns, and therefore how many times a mecanum wheel turns cannot directly be translated into distance?




Hi Ether,

When I say that mecanums slip, what I mean is that the rollers on mecanums do not consistently spin. While you can control how far a mecanum wheel spins, the free-spinning rollers that make up the wheel do not regularly spin.

In both pushing matches and hard acceleration, the rollers on mecanum wheels tend to spin in irregular ways, which essentially results in an inconsistent measure of speed and position.

I think that mecanums can be very useful for strafing and maneuverability, but trying to precisely control their motion can be very difficult if not impossible because of the free-spinning rollers.

Ether 21-01-2017 16:22

Re: Mecanum Drive control
 

Hi Tyler,

Thank you for taking the time to respond to my question.

Some of the things you wrote are still a bit ambiguous to me. I think it would be enlightening to discuss it further. Would you be interested in doing that? I don't want to pester you if you don't want to do that.



berkleyfanatic 21-01-2017 20:40

Re: Mecanum Drive control
 
In 2015 my team used encoders and a gyro for mecnuam and I'm pretty sure it worked out good for us

AriMindell 21-01-2017 21:01

Re: Mecanum Drive control
 
Quote:

Originally Posted by Ether (Post 1634521)

Tyler,
Some of the things you wrote are still a bit ambiguous to me. I think it would be enlightening to discuss it further. Would you be interested in doing that? I don't want to pester you if you don't want to do that.


I, for one, would love to see that discussion

Ether 22-01-2017 00:26

Re: Mecanum Drive control
 
Quote:

Originally Posted by AriMindell (Post 1634639)
I, for one, would love to see that discussion

OK, I'll kick it off with this.

If you make certain simplifying assumptions (which under certain adverse conditions may not be too realistic; more on this if there is interest), mecanum wheels do not "slip" unless they are torqued so hard that they lose traction. And yes, they lose traction more easily than normal wheels because of the nature of the reaction forces between the floor and the rollers.

Under these assumptions, the rollers are rolling, not slipping. The rolling of the rollers is what makes mecanum do what it does.

The computation to turn a driver command of a simultaneous combination of forward/reverse plus strafe_right/left plus rotate_CW/CCW into four wheel speeds is called inverse kinematics. The four wheel speeds resulting from this computation will cause the desired robot motion, if the resulting reaction forces between the roller and floor are less than the available traction so that the rollers roll without slipping.

On the other hand, taking 4 instantaneous measured wheel speeds (one for each wheel) and turning them into the corresponding instantaneous robot motion (forward/reverse plus strafe_right/left plus rotate_CW/CCW) is called forward kinematics.

If the rollers are not slipping, it is possible to do the forward kinematic computation. And in theory, you could integrate the resulting instantaneous robot motion over time to find the robot position and heading. I do not know if any teams have done this with a fruitful degree of success.



Oblarg 22-01-2017 01:06

Re: Mecanum Drive control
 
I could be wrong, but I believe he's suggesting that mecanum rollers are prone to "sticking" and not rolling freely (this would be consistent with my experience of certain brands/models of mecanum wheel). Under these conditions, the wheels of a strafing mecanum robot could be said to "slip," and throw off the correspondence between encoder readings and movement.

TylerHarmon 22-01-2017 01:16

Re: Mecanum Drive control
 
Quote:

Originally Posted by Ether (Post 1634521)

Hi Tyler,

Thank you for taking the time to respond to my question.

Some of the things you wrote are still a bit ambiguous to me. I think it would be enlightening to discuss it further. Would you be interested in doing that? I don't want to pester you if you don't want to do that.



Sure, if you want to discuss it further we can. My main point is that the rollers on mecanum wheels...
... freely spin, which allows a robot to strafe, but results in inconsistent data when used with an encoder.

AriMindell 22-01-2017 11:01

Re: Mecanum Drive control
 
Quote:

Originally Posted by TylerHarmon (Post 1634708)
Sure, if you want to discuss it further we can. My main point is that the rollers on mecanum wheels...
... freely spin, which allows a robot to strafe, but results in inconsistent data when used with an encoder.

Ether posted the following code for determining robot position based on the wheel velocities of mecanum wheels in another thread:
Code:

FWD = r*(w1+w2+w3+w4)/4

STR = r*(w1-w2+w3-w4)/4

Wv  = (1/k)*(w1+w2-w3-w4)/4

r is wheel radius
k is |trackwidth/2| + |wheelbase/2|
w1,w2,w3,w4 are FL,BL,BR,&FR wheel speeds in rads/sec
Wv is robot clockwise rotation rate in radians per second

The implicit assumption is that the velocity vector applied to the robot by a mecanum wheel spinning at constant velocity is constant.

are you arguing that the velocity vector created by a mecanum wheel spinning at a constant velocity is not constant or predictable, therefore that equation provides an unreliable estimate of robot position?

TylerHarmon 22-01-2017 21:32

Re: Mecanum Drive control
 
Quote:

Originally Posted by AriMindell (Post 1634748)
Ether posted the following code for determining robot position based on the wheel velocities of mecanum wheels in another thread:
Code:

FWD = r*(w1+w2+w3+w4)/4

STR = r*(w1-w2+w3-w4)/4

Wv  = (1/k)*(w1+w2-w3-w4)/4

r is wheel radius
k is |trackwidth/2| + |wheelbase/2|
w1,w2,w3,w4 are FL,BL,BR,&FR wheel speeds in rads/sec
Wv is robot clockwise rotation rate in radians per second

The implicit assumption is that the velocity vector applied to the robot by a mecanum wheel spinning at constant velocity is constant.

are you arguing that the velocity vector created by a mecanum wheel spinning at a constant velocity is not constant or predictable, therefore that equation provides an unreliable estimate of robot position?

I understand all of this logic, but it just doesn't work in practice. You simply cannot achieve the precision of tank drive with mecanum wheels because the rollers on mecanum wheels sometimes spin and sometimes do not. In other words, there is a large amount of slop in the system that cannot be removed with programming.

If you show me an example of you consistently driving a set distance and/or turning a certain amount without a gyroscope, only with encoders then I will accept that mecanums can be well controlled with encoders. However, based on the mechanical nature of mecanum wheels, such motion cannot practically be controlled.

TylerHarmon 22-01-2017 21:36

Re: Mecanum Drive control
 
Yes, that is what I'm saying. The force vectors are not reliable in practice, only in theory. The variable "rolling" of the rollers causes this effect. Because those force vectors change (not only in magnitude, but also in direction) you simply cannot achieve precise motion control of a robot running on mecanums.


All times are GMT -5. The time now is 07:08.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi