Speed Ramping with Deadzone

[Dan894]

Does anyone have any successful code for ramping? We've been trying this for several years running, and have tried the following:

• A deadzone. The problem with this is it jumps in speed after the deadzone. We've tried several solutions, including modifying the code so it linearly starts at 128 immediately outside of the deadzone and finishes at 255.
  
• We've done the same thing with a parabola instead.
  
• We tried a one second delay in the response time, where it gradually ramps.
  
• One year our robot went waaay too fast. So in the end, the only successful approach was simply cutting the speed in half.

These have all given rise to bugs making steering more cumbersome. Has anyone had any more success?

[Greg Needel]

i am just curious if you have ever calibrated your speed controllers? This typically decreases the dead zone.

Instructions to calibrate victor 884: connect to your robot via tether turn your machine on. With a paper clip push in the inset cal button on the speed controller till the light blinks red. Then move your joystick back and forth (covering the full range of motion) until the light blinks green. Do this with all your speed controllers and it will help reduce the dead zone of the joysticks.

[Donut]

If I remember right, we've typically used a parabola approach, where the values closer to the center on the joystick are more precise and the values further out change speed much faster. Part of it depends on the year's robot, our robots have had very different speed abilities year to year.

As for ramping up the motors, we put a limit on how much a pwm value can change per loop, by comparing what we want to set the pwm value to and what the current value on the pwm is. If the difference is greater than the limit, it only changes by the limit for that loop.

[KenWittlief]

generally speaking, ramping or putting filters on your driver controls is not the best way to go

it only makes your bot act sluggish, as if it were very heavy and slow to respond to driver commands.

Why take a nice, light, powerfull remote control vehicle and make it act like a big, heavy underpowered sloth?

what you really need is driver training. There is no engineering fix for lack of practice time.

There are two things you can do that are a compromise.

1. Have a high power/low power switch on the driver controls. In low power all joystick commands are cut in half, or to 33% - to use for more precise manuvers.

2. have jog buttons on your driver controls for making very small movements with the robot. A jog button is a push button that causes a one-loop full power output to a motor, then power goes to zero. the effect is like tapping your robot with a hammer, to get it to nudge just a bit in one direction. If you want, have the jog button auto repeat if you hold it down, one jog per second. Try it. If a one-loop full power (254) pulse makes the bot move too much then back it down to 220, 200... till you get the fine-tuning effect you need. It should be very repeatable once you get it dialed in: one push of the jog button will move the bot 1 inch forward, or 1° left....

[Greg Needel]

Originally Posted by KenWittlief

generally speaking, ramping or putting filters on your driver controls is not the best way to go

it only makes your bot act sluggish, as if it were very heavy and slow to respond to driver commands.

Why take a nice, light, powerfull remote control vehicle and make it act like a big, heavy underpowered sloth?

what you really need is driver training. There is no engineering fix for lack of practice time.

There are two things you can do that are a compromise.

1. Have a high power/low power switch on the driver controls. In low power all joystick commands are cut in half, or to 33% - to use for more precise manuvers.

2. have jog buttons on your driver controls for making very small movements with the robot. A jog button is a push button that causes a one-loop full power output to a motor, then power goes to zero. the effect is like tapping your robot with a hammer, to get it to nudge just a bit in one direction. If you want, have the jog button auto repeat if you hold it down, one jog per second. Try it. If a one-loop full power (254) pulse makes the bot move too much then back it down to 220, 200... till you get the fine-tuning effect you need. It should be very repeatable once you get it dialed in: one push of the jog button will move the bot 1 inch forward, or 1° left....

instead of a jog button you could also make a switch that limits your pwm signal 1/2 or 1/4 power and just use your joystick...almost like a 2 speed tranny in software....almost

[KenWittlief]

the difference between a jog button and limiting the output values of the joystick to a lower range is: with a jog button you can hit your motors with a single full power pulse of energy, about 16mS long

its impossible to do that with a joystick, to push it full (or half) on, and get it back to zero in 1/60th of a second.

Hitting the motors with a short full power pulse overcomes all the friction in the system. Turning the motors just slightly on (with the joystick) doesnt.

[Rickertsen2]

Last year we did the following with great results:
1.)lift your robot on some blocks. Write some code that steps gradually through each pwm value and use some sort of wheel speed sensor to create a table of PWM vs. speed. Do this for each drivetrain module.

2.)write a lookup table that makes things linear
3.)The deadzone that is built into the speed controllers has now been eliminated so you will need to code your own. Do so.

This works well to smooth out the nonlinearity wherever it comes from, and make your drivetrain drive straighter. Short of closed loop feedback, i think this is the best approach

[Joe Hershberger]

Originally Posted by Rickertsen2

Last year we did the following with great results:
1.)lift your robot on some blocks. Write some code that steps gradually through each pwm value and use some sort of wheel speed sensor to create a table of PWM vs. speed. Do this for each drivetrain module.

2.)write a lookup table that makes things linear
3.)The deadzone that is built into the speed controllers has now been eliminated so you will need to code your own. Do so.

This works well to smooth out the nonlinearity wherever it comes from, and make your drivetrain drive straighter. Short of closed loop feedback, i think this is the best approach

Rick,

That's definitely a great way to make the robot feel more responsive. When we create out linearization map, we strapped a laptop on the robot and had the debug port read the wheel speed off of the encoders. We programmed it to, very similarly, output each pwm code in succession and report on the speed. However instead of using blocks, we did one wheel at a time and had it drive in a circle. It got pretty crazy at the highest speeds. Our drive system had only two drive wheels on the ground and 2 omni castors so we didn't have trouble with side load from turning. This allowed us to get the total system response when loaded as opposed to unloaded on blocks.

I think this year we'll use the BlueSMiRF and spare the risk to the spinning laptop!

It was incredible how non-linear the response was. The inverse table improved drivability and responsiveness dramatically. Attached is a plot to show just how bad it was.

Cheers!
-Joe

[Rickertsen2]

Originally Posted by Joe Hershberger

It was incredible how non-linear the response was. The inverse table improved drivability and responsiveness dramatically. Attached is a plot to show just how bad it was.
-Joe

Yea... Thats pretty typical for a FIRST robot. There is some debate where that nonlinearity comes from. See my thread: http://www.chiefdelphi.com/forums/sh...ad.php?t=31903 for some more charts.

Testing response with the wheels on the ground is probably more accurate, but we didn't have room at the time. The wheels off the ground method worked well enough.

[CJO]

First of all,

A closed loop feedback system is ver usually a good idea.

Secondly,

you can also try a jog wheel, almost like on an iPod where each "click" of the wheel results in a jog. Use an optical encoder with clicks and 8-12 resolution for this.

Alternatively, create a "throttle" type lever which you can use to change between overall power range on the sticks.

Just ideas

[Workaphobia]

All I did last year was add a small deadzone - I forget if I scaled down the other values outside of it to zero or not - and implement a parabolic or sinusoidal curve instead of a linear one. The drivers liked the sinusoidal one the best, but there was a lot of room for improvement.

Try experimenting with different curves, and adding joystick buttons to increase or decrease the speed by some factor is not a bad idea. Make sure your drivers know that this process is mostly trial and error, so it's up to them to communicate which system works best for them.

[Cuog]

i have written a code that allows the user to select between the different drive curves, the first is a parabolic curve that does not sacrafice top speed just allows for the driver to push a little and go slow, then there is the standard IFI default of linear then i added a 50% drop to the parabolic(the reasoning for this is that so often we over gear our robots)