Easing into top speed

[smcmahon]

Looking for some LabVIEW ideas on having more control over drive speed.

We have a Mecanum drive bot this year. Each wheel is directly driven by an AndyMark ToughBox with the standard gear ratio (12.75:1). The bot is probably in the 100 pound ballpark.

When we press "up" on the control stick, the bot really tries to take off. So much so that it sometimes lurches forward and almost lays some rubber.

Is there a way to slow it down? Or ease into the speed the same way a car does? Are the drivers simply pushing too hard too fast? When I drive, I try to really ease into the speed control stick, but some of the students just gun it. It almost looks like it's bad for the robot.

Is it common for teams to sorta ease into top speed? Is it not as bad for the bot as it seems in the shop? Thanks!

[vhcook]

We basically divide all the Holonomic - Cartesian speed inputs by 2 under normal operation to slow us down a little, then have a turbo button assigned which, when depressed, allows the full range. This gives us a little more fine control, but we can go to full speed when we need it.

[WizenedEE]

Lots of teams made programs that would give their robot a lower acceleration, especially for Lunacy. Basically what you do is have a PID loop control the speed, and have the joystick as the setpoint.

If you're using the CAN bus, there should be an automatic voltage ramp built in to the jaguars, but I haven't really looked at it.

However, this late in the season, it's probably best to just tell the drivers to be more careful, IF you think it's bad for the robot.

[Ether]

Originally Posted by smcmahon

When we press "up" on the control stick, the bot really tries to take off. So much so that it sometimes lurches forward and almost lays some rubber.

Is there a way to ... ease into the speed the same way a car does? Are the drivers simply pushing too hard too fast?

You could try putting a low-pass filter or a rate limit on the joystick commands before passing them to the mecanum vi.

[smcmahon]

Always love how quickly I can get honest and knowledgeable input on C/D!

vhcook- We'll give that a try today, thanks. We tried something like that last year. Can't remember the results though...

WizenedEE- Our programmers haven't jumped into PID lopps yet. That's something we're considering for some off-season learning. We are done competing for the season. Getting the bot more under control is for some public demos we have coming up in the next month.

Ether- Those two ideas sound interesting. Can you elaborate on them please?

[Joe Ross]

Originally Posted by smcmahon

Ether- Those two ideas sound interesting. Can you elaborate on them please?

http://thinktank.wpi.edu/article/140

[Kevin Sevcik]

Originally Posted by WizenedEE

Lots of teams made programs that would give their robot a lower acceleration, especially for Lunacy. Basically what you do is have a PID loop control the speed, and have the joystick as the setpoint.

A PID loop will do next to nothing to rate limit motor commands unless you tune it to be mushy as heck. A tightly tuned PID is going to be nearly as responsive as a straight joystick input. And you're going to want it tuned fairly tightly for mecanum unless you want your wheels to all come up to speed at different times. That'd give you some funny dynamics and wiggle when you changed directions.

Which brings me to my second point. If you're going to do this, and it's pretty easy to do, then rate limit your joystick signals before you put input them to the holonomic drive block. This will limit how fast you're changing directions, as opposed to how fast you're changing wheels speeds.

In case the distinction isn't obvious, think about what would happen if you made an instant change from full forward to full left strafe. Limiting the joystick means your direction vector would gradually swing from forward to left, and your bot would make a little controlled arc to the left. Limiting motor change would (I think) be somewhat different. Your front right and rear left wheels would stay at full forward, and your other wheels would shift to full reverse at the rate limited speed...

Thinking about this a bit more carefully, this might not actually change things since the mecanum kinematics are all linear. But I'm not able to work out the Jacobian of the kinematic equations and figure out what it means at the moment, so I don't know for sure....

On the gripping hand, rate limiting the joysticks in Labview is a lot easier to implement than limiting the motors anyways, so you should probably just stick with that.

[Ether]

Originally Posted by Kevin Sevcik

But I'm not able to work out the Jacobian of the kinematic equations and figure out what it means at the moment, so I don't know for sure....

If you filter the the outputs (wheel speed commands) from the inverse kinematics, you will likely obtain a set of non-holonomic wheel speed commands during the transition. The forward kinematics of mecanum are discussed here.

[MaxMax161]

I think that doing a PID or something more advanced like that would be the best solution to the problem long term however that requires time to write, robot time to debug, and all of that fun stuff.

I personally think that your best solution would be to proportionally decrees the sensitivity of the joysticks (just multiply the value that comes out by something less then 1) unless a button is pressed, in which case they have full sensitivity.

This is easy to program and gives your drivers something to help them drive the robot well. At this point in the season there isn't a lot of time to learn and implement anything complicated so I'd go with something simple and then put it on the drivers to learn how to drive better using any tools you can give them.

[RoboMaster]

I really like the divide by 2 and disable with a button method, it's simple, easy to tell your drivers, and works quite well. You can also pick any other number than 2 if you want, like 3.

Some teams, like us, have cubed the joystick values (that is, x^3). This allows you to have slow speeds the majority of the time (that still increase), but also allows you to have that last bit of full speed. Squaring works, too, but cubing seems to be better and more defined. Visualize it with this graph. Plus, you don't have to press a button to disable it for full speed. Sometimes, that's one more button to memorize and drivers get turned off by that and don't use it.
To program this in LabVIEW: squaring is as simple as inserting a Square node in the wire. Cubing is more tricky, I would suggest using a Compound Arithmetic Function set to multiplication and the same joystick value wired to 3 inputs. Or you can use a fancy expression node, but don't forget to use ** instead of ^

[Ether]

Originally Posted by RoboMaster

Some teams, like us, have cubed the joystick values (that is, x^3). This allows you to have slow speeds the majority of the time (that still increase), but also allows you to have that last bit of full speed.

This might be of interest:

http://www.chiefdelphi.com/media/papers/2421

[Clayton Yocom]

I have a VI we built this year that does exactly this, I'll post it Tuesday when I can get back at the latest build of our code. It makes a joystick value "trickle" up or down (two different VIs). If you haven't acquired anything better I hope this will work with as little tweaking as possible

[Clayton Yocom]

Here is that file I was talking about, its a day late sorry :/

Leme know if this looks like what you need.