Hi,
I have been searching how to implement an acceleration ramp in Easy C. Unfortunately, I have not been able to find any answers. Does any one know?
Thanks
That’s not a term I’m familiar with. Can you explain what you want to be able to do? I’ve got a bit of experience and I’ll help if I can.
EDIT: Still don’t know what it is, but these came up when I searched.
https://vexforum.com/t/acceleration-ramping-or-linear-filters-in-easyc/22485/1
https://vexforum.com/t/acceleration-linear-flitering/20277/1
https://vexforum.com/t/acceleration-linear-flitering/20277/1
I want the motors to accelerate from 0 to 127 over the span of one second or so.
Thanks.
Do you wish to accelerate linearly, exponentially, or what?
Make it so that if you push a button, the motors run at 127?
I don’t see what’s hard about this. Can someone explain, please?
Basically, what he means is that during autonomous, instead accelerating motors from 0 to 127 almost instantaneously, it slowly “ramps” the power up. This way the wheels don’t slip on the ground when starting, and your robot won’t continue to drift due to inertia when stopping. Kinda like the difference between flooring the gas pedal and slamming on the brakes vs slowly accelerating and decelerating.
Oh. Okay.
You could do it manually. It would be painful, but you could put values for motor power that scale however you want with time delays between them. I know that will work. I don’t think that’s the best way of doing it, though.
I’ll go play around with some code we have in EasyC, and see what I can turn up.
Here is a concept you could use
Note: this is a concept, not real code
for(int i=0; i<=127; i++)
{
motorspeed=i;
wait(some time);
}motor is now at full speed
That’s the program I just wrote, with the correct time value added in. This will increase your motor power to 127 linearly over the course of a second. Just go and put the value i in for any motor that you want to do this for.
It’s attached below.
Acceleration Ramp.zip (1.78 KB)
Another way is to use a repeating timer to ramp speeds. Here is an old post that implemented that, probably could be improved upon now.
https://vexforum.com/showpost.php?p=259162&postcount=9
The code compares the current speed of the motor to a requested speed, if they don’t match then the motor speed is slowly adjusted. As EasyC didn’t (and still doesn’t as far as I remember) have a get motor speed function the current motor speed has to be stored in a variable.
EasyC has a motor speed function that uses an IME to get the value. It’s an option.
Pearman, have you used this code before? I love the idea, but I’m curious how the time delay you have (375 ms) affects driving from full forward to full reverse. We’re going to be changing the direction of motors a lot this year because of the X-Drive, and I would really like to not burn them out.
That is the logic that most teams used in robotc.
if(joystick>motor)
motor=motor+1;
wait
Obviously not the most elegant way but it got the job done and never caused any noticable lag due to inefficiency. The wait time just needs tweaking every time a lot more code is added to the driver control code.
(My team through together a different system using a seperate task that didn’t require changing constantly but really that isn’t necessary)
I use the ROBOTC version of this in every robot we build (unless an over confident freshmen programer is working on it, then we let them crash and burn 
). The 375mS was just the number that “felt” about right when the code was first used during the gateway season. Sometimes we slow that down, for example, for last years programming skills robot which started with 5 sacks balanced on its intake, we had to accelerate slower to stop it doing a wheelie and tipping backwards.
“Elegance is an attitude”
Wouldn’t you need to do this in a couple of parts? Something like;
if(joystick>motor)
motor=motor+1;
wait
else if(joystick<motor)
motor=motor-1
waitOtherwise, how would you get the power to go down?
And what do you mean about needing to adjust the wait time based on the length of the code, though? It shouldn’t matter until you’re hitting thousands and thousands of lines, right?
We’re actually trying to figure out the best way to teach a bunch of new programmers how to code. Have you found it’s best to let them try things and have them crash and burn, or to help them fix their code before it happens so that they don’t build bad habits? We were going to go with the second option, but we’ve literally never taught anyone but ourselves before. So we aren’t sure what the best way is.
Do you know what the minimum “safe” amount of time is for this to work? I mean, faster is better, right?
If you’re still wondering how to do this, this is how I did it last year (after many bouts with motors tripping PTC’s):
if(Y1<vexRT[Ch3]){
Y1 += COAST;
}
if(X2<vexRT[Ch1]){
X2 += COAST;
}
if(Y1>vexRT[Ch3]){
Y1 -= COAST;
}
if(X2>vexRT[Ch1]){
X2 -= COAST;
}
Rdrive(Y1-X2);
Ldrive(Y1+X2);
Rdrive and Ldrive are drive functions for right and left drive sections, Y1 and X2 are variables influenced by joystick inputs. COAST is a constant (mine is set to 0.7) which is added or subtracted to the Y1 or X2 variables until they reach the joystick inputs, effectively ramping them to the joystick input. This particular configuration is arcade mode, but it can easily be adapted to tank mode by changing the variables to reach different joystick inputs.
Ya I only typed half lol.
I noticed a difference in acceleration time from the drive when i had full operator control code and only drive code. It depends on how complicated your code gets and how many driver aids you put in.
Some EasyC statement, things like PrintToScreen, have built in delays. As you add these the loop time can increase a lot.
You’re confusing me for a teacher here, I just do what I can, it really depends on the student. If they want to tackle the programming on their own I let them do that at the beginning of the season. As things progress I occasionally jump in with “have you tried the code in this way” and then try and show them how it can be improved (or at least changed).
You want to be able to accelerate as fast as possible for the most responsive control when driver operated. You also want to try and limit wheel spin. There is some natural acceleration built in because of joystick movement but that’s usually not enough. The robots weight and top speed also play a part. Using the smart motor library also makes some of this irrelevant as it also throttles back the power to limit current.
So, we’ll have to do some testing to fine-tune this, if we decide to use it? Alright.
Thanks for the help.
I can’t find the exact post but jpearman did an excellent shot from an oscilliscope of the motor current spiking when you jam it right to 127 without his slew rate control and then a more leveled out profile with the slew rate code.
The slew rate screen shots shows how it smooths out the current spikes and makes the PTC less likely to trip. When I see PTC trips in our club, I want them to implement the slew rate code ahead of buying a power expander (more like it is thrust upon them). “Don’t do that” only goes so far.
Any chance someone else can find these scope shots or can James re-post them? They’re a keeper!
Not sure exactly which charts you’re looking for but it’s likely from one of these threads: