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) ?



~

[Ether]

Originally Posted by 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.

The basic premise was too much friction and high gear ratio to be controlled open-loop. Is your bot's wheel speed controlled open-loop or closed-loop?

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

"lack of fine control of robot movements, especially at low speeds"


~

[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.

[TD912]

The joysticks return values between -1 and +1 for both the X and Y axes, And these values are then used to generate a signal for the speed controller. You can "curve" the output however you want. Normally, moving the joystick 50% forward would send a 0.5 signal to the contoller. Squaring it should give you finer control at lower speeds (moving the joystick 50% forward would result in a 0.25 signal being sent), while getting the square root would do the opposite (50% forward would end up sending a 0.71 signal instead!). In either case, you could still achieve full speed by moving the joysticks all the way forward. You should experiment to see what works best for you, and be sure to program in a way to keep your positive values positive, and negative values negative when squaring.

Just remember that the motors will still need to be able to produce enough force to move the robot, Plus there are things like deadband to deal with, so very low values like .1 might not appear to do anything.

Edit: By the time I typed this up, all these people replied already! Sorry if I repeated what was already said.

[TubaMorg]

We are using an open loop this year and we have used it in the past for our mecanum drive, though we use direct drive and a higher gear ratio than the KOP transmissions. We aren't using encoders to control wheel speed, but we ARE using a gyro to make sure the robot stays pointed in the right direction.

We aren't experiencing control issues perhaps because of our differences. You could fairly easily increase your gear ratio (in a way) without too much trouble by changing your sprocket sizes. A smaller output sprocket and a larger wheel sprocket will slow your wheels down.

Hope this helps...

[Dad1279]

As a point of reference, we used the AndyMark 8", directly driven with 12:1 transmissions. For control we used Logitech 3d, using the 'twist' of the joystick for rotation.

They were driven by PWM, w/o feedback. Rotation/twist was scaled down.

This worked fine on both our test-bot and the final robot.

[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) ?


~

[Ether]

Originally Posted by Dad1279

As a point of reference, we used the AndyMark 8", directly driven with 12:1 transmissions. For control we used Logitech 3d, using the 'twist' of the joystick for rotation.

They were driven by PWM, w/o feedback. Rotation/twist was scaled down.

This worked fine on both our test-bot and the final robot.

AndyMark 8"... check
3-axis Joystick ... check
"twist" for rotation ... check
PWM ... check
no wheelspeed feedback ... check
rotation "scaled down" ... check

only difference is wheels are connected to toughbox (12.75:1) transmissions via sprocket and chain.

What kind of curve-shaping did you do on your joystick outputs before feeding them into your wheel-command-calculation algorithm ?


~

[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


~