Slowing Down Drive Motors

This is team 1611 “rookies” having a little trouble with the single joystick method of control.When a direction is used the motors “jump” to an almost to fast speed but still allows for a top speed with gradual acceleration, the problem is trying to get rid of this “jump” through programming.Iv’e allready lowered the speed_setting to its lowest of 127 any suggestions?

Our programmers used something they referred to as a “drivemap” to scale the accelleration gradually. I have no idea how to do such a thing, but from my understanding it was some sort of table of values that they came up with

Sounds like a lookup chart, rather than coming up with an equation to follow, and nasty FLOPS to do, you have a value for you x-axis that corresponds with a number that you add or subtract from the Y-axis value. Lets you change it to make it more or less linear. Basically you are substituting memory for processor time. Not sure how to implement this in a simple manner though.

Exactly!

Although it could theoretically do it, the PIC in the RC isn’t exactly up for exponential equations.

What we have done every year is a lookup table… it takes more effort then writing an equation; you need to come up with a chart with 127 (or 256, depending on how you write your code) like this made up example:


int speed] =  {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,5,5,5,5,5,6,6,6,6,6,7,8,9,10,11,12,13,14,15,17,19,21,24....

etc… i will try to find the exact code out of an old bot. the idea is that when you get the joystick value, you just take:


p1_y = speed[p1_y];

its that easy!

this also gives you a chance to tweak your robots response time and “aggressiveness”

best of luck – jsd

Instantiate two ints named temp15 and temp16. After the limit mixing functions have run, do this:

temp15=(int)pwm15-127;
temp16=(int)pwm16-127;
pwm15=(int)(.007874*pow(temp15,3)/fabs(temp15)+127);
pwm16=(int)(.007874*pow(temp16,3)/fabs(temp16)+127);

My real code is structured a little differently, but it works the same. 0 still outputs 0. 127 still outputs 127. 254 still outputs 254. Everything else in between is much less touchy, and it gives the driver a lot more control. It’s also much simpler than making a lookup table, and won’t eat up all your memory. (Yes, this is how I actually code. No, nobody else can ever figure out what I’m doing.)

That should answer it.