View Single Post
  #4   Spotlight this post!  
Unread 17-01-2017, 22:44
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 359
slibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud of
Re: Mecanum Drive control

Quote:
Originally Posted by AriMindell View Post
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.
Reply With Quote