My team was wanting to have our flywheel start at a speed of 5, and slowly go up to 127 across a span of about 20 secs. I have never done anything like this and wanted to know if there is a better way than my current method on EasyC.
Right now our builder gave me a list of 24 increments which breaks down to a change of speed every 1.2 sec. We are using 4 motors that are "Y"ed off of 2 motor ports. So to do this I am using the Smart Task “MultiMotor Time Control” for every increment and will end with a constant output of 127.
Is there a easier, more condenced way I could do this build up in speed on EasyC?
I did something similar to this at the beginning of Skyrise. Everyone was heavily focused on the prospects of tipping, so I decided using controlled snap acceleration was our best bet at a fast drive for auton without risking tipping.
All this to say…
Graphing a square root where x is equal to time and y is equal to your power gives a nice fast, controlled speed up. However, you could also use a linear equation.
Math example:
y=mx + b
y=m(sqrt(x)) + b
‘b’ is your minimum starting power. You mentioned a speed of 5, so here is another example, except this time in pseudo-code (sorry, I do not use EasyC).
Example:
integer time = 0;
while(time < 21)
{
motorPower=6.1(time) + 5;
time = time+1;
wait1second;
}
You can then increase the resolution of the change in motor speed by changing the frequency of the code cycling up to something more like 50ms and adjusting ‘m’ accordingly.
Hope this helped!
Luke Rohler
323Z Aftershock Coach
I have never used the math blocks for EasyC before but I’m sure I can figure it out tomorrow when I have access to the code. If not I’ll try the user code option or wait until we get our RobotC order approved by school.
I’d just like to point out that you shouldn’t do this. If you electronically limit the time it takes for your flywheel to spin up to be 20 seconds, you won’t be able to shoot any balls in autonomous (it’s only 15 seconds long), and you won’t be able to start shooting until 20 seconds into driver control. And, it’s unnecessary. Applying a motor power setting of 127, for example, immediately will not damage your flywheel mechanism. The gears will be able to handle the stress and so will the motors (it’s not very much stress). Here’s a good video of a team that applies a power setting immediately with good results.
Notice the big spike of current in the top one and not so much in the lower picture. It can be a PTC saver but if you push the motor too hard, the PTC will still trip and cause intense unhappiness.
We have had many teams in our club use this exact code for a few seasons now.
Adjust the specific motor step size down per time slice to what you want. You can adjust the step size and find the best step to time to ramp up. I am not sure you need a full 20 seconds though to ramp up. These run at 20ms increments to match the PWM signal.
A heavier flywheel may need a smaller step to limit the current spike up front. You could get fancy and adjust it further based upon if you are already moving or not too.
You can also get a current sensor and test the motor actual current as well to see what the real limits are. But try the slew rate code first and play with some numbers before you completely optimize the heck out of it.
I figured as much, but since it was an area of programming I haven’t played with and the robot is still kinda a prototype, I was going to go along with it and tell him its unnecessary later.
The point about autonomous is a good one, I hadn’t thought of that and wouldn’t have until we start fully programing an autonomous.
I’ll look into this, I’ve never heard of this or anything like it before and it may prove helpful, even not in our current situation. Thank You.
A sigmoid is a good function for accel/decel, you can use a lookup table for easy real time calculation.
Just a nit-pik, in your original question, 5 and 127 are not speeds, they are power, and may have nothing to do with actual speed without closed loop control.