Quote:
|
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