Limiting acceleration in easyC

[Neurovirus]

today we let someone besides the drivers/programmers drive and they almost flipped the bot by switching from full forward to full reverse

so i was thinking about limiting the acceleration, namely not allowing switching back and forth between forward and back.

the question is how?
and
is this even a good idea?

[DonRotolo]

How?
Create 2 variables, "Out" and "Old_Out", default them to 127. Store the real final PWM output to Out, and subtract Old_Out, and if the difference is greater than some rate of change (say 50), reset the value to the rate of change (Out - 50). Then set Old_Out == Out, and repeat each loop. You'll have to manage the math a little bit, to prevent exceeding 255 or zero, and maybe elsewhere, but that basic idea is a simple PID loop with only D being used.

Good idea? Maybe not. Driver training is probably a better approach.

Don

[jskene]

We've been using code like that for several years. It not only helps the driver, but takes a big load off the drive train - chains, belts, gears, and reduces the chances of a tripped circuit breaker.

[Neurovirus]

@jskene

how did u do it? like how Don R. described it?

Thanks, Don

Neuro

[jskene]

Yes, in a similar fashion.

[billbo911]

We've been using code like that for several years. It not only helps the driver, but takes a big load off the drive train - chains, belts, gears, and reduces the chances of a tripped circuit breaker.

We've written a "Torque_Limit" function for this year. We can set the max delta for each loop to any value. Out of curiosity, what range have you found to be reasonable? 50, 75, 100 per loop?

[jskene]

We used different values for forward and reverse. We want to be able to stop faster than we can accelerate.

Our acceleration rate was limited to 3, deceleration to 8.

[billbo911]

We used different values for forward and reverse. We want to be able to stop faster than we can accelerate.

Our acceleration rate was limited to 3, deceleration to 8.

Ah, excellent. Thank you.
One more question. Our code works on a change in pwm value per loop. The values you gave seem lower than I would expect. Are your values for change in pwm/loop or loops for a full direction change?

[jskene]

Ah, excellent. Thank you.
One more question. Our code works on a change in pwm value per loop. The values you gave seem lower than I would expect. Are your values for change in pwm/loop or loops for a full direction change?

Change/Loop.

It also applies to directional change - forward<--->reverse

[billbo911]

Change/Loop.

It also applies to directional change - forward<--->reverse
Those numbers are tighter than I assumed they would need to be, but the math agrees.
You can go from STOP to FULL in 1.1 sec. and FULL to STOP in .4 seconds.
Very nice!
How do the drivers like the response?

[scottanderson]

We wrote some code for that this year, but then were given advice by a very experienced team that we shouldn't worry about the drive train and that putting a full reverse on the motors is a good way to brake.

The problem with the limiting code is that the robot really doesn't stop very quickly at all when the outputs are just set to 0.

Regards,
-scott

[jskene]

"How do the drivers like the response?"

They don't notice a big difference.




The problem with the limiting code is that the robot really doesn't stop very quickly at all when the outputs are just set to 0.

Regards,
-scott

You probably have the "BRAKE" jumper on the Victor set to "COAST".

[scottanderson]

You probably have the "BRAKE" jumper on the Victor set to "COAST".
You are correct. Thanks for the tip.

What do folks think about the advice we were given about thrashing the gearboxes, though? Was that sound advice, or do we need to worry about adding some sort of intelligent damping to avoid it?

Regards,
-scott

[paulcd2000]

one method we are attempting this year is to use the accelerometer, can actually limit the acceleration itself, instead of just pwm values