fine control of robot with mecanum wheels

[Ether]

I am advising a team that built a robot with mecanum wheels, and they are very unhappy with the lack of fine control of robot movements, especially at low speeds.

Each 8" mecanum wheel is powered via a chain connected to an AM toughbox gearbox with a CIM motor.

There are no encoders, so the wheels are being commanded open-loop (i.e. they are being given voltage commands).

My analysis is that the design has too much friction in the drive train, and the gear ratio is too high, to obtain fine control at low speeds with an open-loop command.

The solution I proposed is to use a lower gear ratio (sacrificing top speed for better fine control at low speeds), or to add encoders and CAN bus so the Jags can do closed-loop speed control of the wheels. Neither of these solutions can be accomplished before their next competition.

I see no other viable options. Comments or suggestions?


~

[Boommaster713]

My Team this year has also run a system identical to this setup and have not had any issues regarding the control of the robot(Once setup properly). So the basic premise of too much friction and high gear ratio is not the culprit.

So a simple question would be what kind of control issues is your team experiencing?

[StevenB]

This may be something you've already tried, but you might want to consider a nonlinear joystick mapping. That is, when you push the joystick halfway, you only move at 1/4 speed instead of 1/2. This gives you finer control of slower movements, while allowing you to still use the full speed range. Very rarely do you care if you move at 3/4 speed vs full speed, but you definitely care about 0 vs 1/4 - thus, you can stretch the axes accordingly.
All you have to do is square the input, making sure to preserve the sign.

A second note - if this is a first or second year team, my suggestion is, "get used to it." Fast robots are almost always hard to control, and the best fix is simply driver practice. I remember during my rookie year feeling that our robot was uncontrollable, but we eventually learned to drive it, and it wasn't as bad as we thought.

[Ether]

Originally Posted by StevenB

This may be something you've already tried, but you might want to consider a nonlinear joystick mapping. That is, when you push the joystick halfway, you only move at 1/4 speed instead of 1/2. This gives you finer control of slower movements, while allowing you to still use the full speed range. Very rarely do you care if you move at 3/4 speed vs full speed, but you definitely care about 0 vs 1/4 - thus, you can stretch the axes accordingly.
All you have to do is square the input, making sure to preserve the sign.

Yes, it's already been tried:
http://www.chiefdelphi.com/forums/sh...d.php?p=921992

A second note - if this is a first or second year team, my suggestion is, "get used to it."

I'd like to hear from any teams that have implemented closed-loop wheel speed control via encoders connected directly to Jags, on a bot with mecanum wheels.

Also, are any teams using shiftable transmissions (high and low gears) ?



~

[DavidGitz]

Originally Posted by StevenB

square the input

Actually, if you want to increase the sensitivity at low values and decrease it at larger values, you would square root the input values, or another function with a downward concavity. If you square a value between zero and 1, it becomes even smaller.

[ajd]

Originally Posted by DavidGitz

Actually, if you want to increase the sensitivity at low values and decrease it at larger values, you would square root the input values, or another function with a downward concavity. If you square a value between zero and 1, it becomes even smaller.

Most likely, you would want to decrease the sensitivity, which would give you more control, since the same change of the joystick position would give you a smaller change in motor speed. So squaring it seems like a better bet for more control.

[Ether]

Originally Posted by ajd

Most likely, you would want to decrease the sensitivity, which would give you more control, since the same change of the joystick position would give you a smaller change in motor speed. So squaring it seems like a better bet for more control.

Correct.

I'd like to hear from any teams that have implemented closed-loop wheel speed control via encoders connected directly to Jags, on a bot with mecanum wheels.

Also, are any teams using shiftable transmissions (high and low gears) ?


~

[JamJam263]

Originally Posted by Ether

Correct.

I'd like to hear from any teams that have implemented closed-loop wheel speed control via encoders connected directly to Jags, on a bot with mecanum wheels.

~

Team 263 is using exactly that. We found that the voltage control in an open loop was way too unreliable. Each wheel is directly hooked to a AM tougbox, with an encoder directly connected to the Jaguar that controls it. Using CAN speed control made everything more reliable, no drifting and a lot better traction control. The 1kHZ PID loop in the Jags helped use tremendously. Out of 60 Teams in NYC we where the only ones using CAN, and had quite a few comments from other teams using mecanum on how much better it preformed. The only issue that was not directly fixed with CAN and the built in PID was control at lower speeds. To fix this we simply used the throttle on the joystick to make an adjustable scale where setRPM=joystick*throttle*maxRPM. With adding the throttle everything worked without any issues. Using the throttle to make an adjustable scale works for voltage control, and a PID loop can easily be set up with the encoders hooked to the cRio in a short period of time. Actually switching our C++ code from an open system using pwm to CAN didn't take us more then an hour, neither did setting up the CAN network itself if you have the cables to do it.

[dtengineering]

Can't say this will help, but we did encoder based closed-loop on our Rack'n'roll mecanum (8" AM mecanums off 12:1 direct drive banebots)... using interrupts on the IFI controller. It did help... at least once we got the PID coefficients tuned. Until then it was wild!

Hopefully it will be easier with the new hardware...

Jason

[Ether]

Originally Posted by JamJam263

To fix this we simply used the throttle on the joystick to make an adjustable scale where setRPM=joystick*throttle*maxRPM. With adding the throttle everything worked without any issues. Using the throttle to make an adjustable scale works for voltage control...

Yeah, we also tried using the throttle* to scale the joystick (with open-loop PWM control) but it wasn't good enough. The driver wants more fine control, and I don't blame him.


*We used the throttle to control the parameter "a" mentioned in this post:
http://www.chiefdelphi.com/forums/sh...d.php?p=921992


~

[efoote868]

My team is using mecanum wheels, I believe we are using the same setup or something similar.


One thing to keep in mind is that everything has a slight polarity, and a deadband. You can work to figure out where the motors start spinning, and then account for it in code.

Also, another thing my team has found useful is separating the rotation component from the XY joystick to another one - we found it was nearly impossible to spin without moving off axis until we did this.


After this season's competition I think I'll write a whitepaper on how I got the students to approach mecanum drive, our setup this year is very easy to control and I'd like them to be able to use it easily in future years (without having to worry about cheating).

[Ether]

Originally Posted by efoote868

My team is using mecanum wheels, I believe we are using the same setup or something similar.

Could I ask you to check with your lead programmer to find out if your bot using using closed-loop wheel speed control ?

Thank you.


~

[efoote868]

There is no wheel feedback.

[Ether]

Hi Team 868,

Thanks for your reply. I have a bunch of questions, I hope you don't mind. Any answers you are willing to provide would be much appreciated:

My team is using mecanum wheels, I believe we are using the same setup or something similar.

Are you using 8" AndyMark mecanums? Are the wheels direct-driven, or chain-driven? If chain, what are the sprocket teeth counts? Are you using the KoP AndyMark 12.75:1 toughbox? If not, what is your gear ratio? Are you using Victor or Jag motor controllers?

One thing to keep in mind is that everything has a slight polarity, and a deadband. You can work to figure out where the motors start spinning, and then account for it in code.

Yes, we are aware of this. Nothing we have tried so far is able to achieve fine control at low speeds, given our gear ratio and open-loop control.


Also, another thing my team has found useful is separating the rotation component from the XY joystick to another one - we found it was nearly impossible to spin without moving off axis until we did this.

We have no trouble spinning in-place, with the rotation command on the "twist" axis of a 3-axis joystick.


~

[Mr. Lim]

Ether,

It sounds like you're running a setup very similar to ours. I can't say we've "mastered" fine motor control with our mecanum wheels, but I'm happy to answer any questions you have. Here's a video of our practice robot, showing what we can/can't do:

http://www.youtube.com/watch?v=apcy5naz5TE

Are you using 8" AndyMark mecanums?

Yes.

Are the wheels direct-driven, or chain-driven? If chain, what are the sprocket teeth counts?

They are chain-driven. 19 tooth on the ToughBox output shaft, kit supplied 22 tooth on the Mecanum wheel hubs.

Are you using the KoP AndyMark 12.75:1 toughbox? If not, what is your gear ratio?

Yes we are using the KoP AndyMark ToughBoxes, unmodified.

Are you using Victor or Jag motor controllers?

We are using Jaguar motor controllers, using PWM control.

Our setup also uses the US Digital optical encoders, and the WPILib PIDController object. We are using closed loop I-only motor control, and we cube our joystick inputs before sending them to our control loop.

We also implemented a "slow-down" button, which scales both our translational and angular velocities to about 1/3 of max when held down. You can see it used in the video just prior to when our robot meets the ball - the robot seems to abruptly slow down.