It was asked earlier and I’m wondering if it has been updated to use the big red quadrature encoders. I’d like to show some students the feature if it has been.
Yes it will work with the red quad encoder, however, you are going to have to change the default setting to make it work successfully.
In this earlier post I described what all the numbers in the PID setting dialog mean.
https://vexforum.com/index.php/conversation/post/143522
One very important number is the “maximum encoder counts per second”, this is set at 1000 for a 393 motor. We know an IME on a 393 motors has 392 counts/rev for a motor geared for speed. We also know that with this gearing the motor will have a maximum speed of around 160rpm, so about 2.6 revolutions/second. 2.6 x 392 is 1019, that’s how the 1000 number is calculated. It will not change if the motor is geared for torque or turbo, the actual encoder will be counting the same number. Now consider the red encoder on the output shaft of that same motor. Red encoder has 360 counts/rev so, with motor geared for speed, max encoder counts/sec would be 2.6 x 360 = 936, perhaps set the max counts number to 900 rather than 1000. With 393 geared for torque, output shaft runs at about 1.6 revs/second so set the max counts number at 1.6 x 360 = 576. If the red encoder was placed after other external gears then modify as necessary.
Hi
I’m a bit confused about the values, I don’t really get what they’re doing. I’ve got the code working and noticed a difference (I think). I have a double flywheel with a 1:8 gear ratio using turbo gears (theoretical 2000 RPM for each set of 2 wheels, 2 wheels on each axle).
What should I be using as the values, or how should I be going about tuning the values? I read your post above about values but still have no clue!
Thanks
@jpearman “Yes it will work with the red quad encoder”, is that correct? I’ve been looking through the forums and others say that you can’t. I’m brand new to using a PID loop but want to experiment with it ASAP. I have IMEs but the 4 wire cables are too short. I do have quad encoders that I can extend with wire I already have. I’m already reading and following your PID posts. Any other tips to get started?
How do I set the RegIdle and RegSpeed for the motor encoders on my flywheel?
I’m not quite sure the question. Regspeed and RegIdle are settings to set your motors to.
Exactly. So How do I set the Pid Control to have a certain value of speed that is specific to our flywheel design? Where is the box or value that I place it in? I know there is a pid value set somehwere but the problem I have with TBH is that I don’t know how to set it to the value that our flywheel needs.
So you just control the motor the same way.
Motor[flywheel] =50;
Find what value stabilizes to be the correct speed for each distance. The motor power sent to the motor will fluctuate as the motors reach the target speed.
I’m not quite sure if you mean you don’t know how to set the target speed or how to tune the constants. For TBH the one value is called the gain. For PID they are kP, kI and kD in general with a few other things like slew rate control to also keep in mind.
So is the slaveMotor command a built in method call or did you put that in yourself? I’m gonna test this with our four wheel flywheel at the next meeting.
Built in.
So i am testing PID and nondepandent of the kp,ki,or kd values I input the flywheel always ends up spinning at max speed. When I use a lower ki value the flywheel takes longer to get to 127 but it still ends up there no matter what. Does anyone else have this problem or any ideas as to how to fix it.
What is the motor debugger showing as the live values of velocity? Something like an inverted wire could cause this because the motor would keep trying harder to get to positive velocity by trying harder in the wrong direction.
We have been using the integrated PID control for a while on our flywheel with some good success. We have recently removed flywheel friction such that the required power at the bar needs to be around 30-34% of full power. The motor ramps up to the desired speed quickly and seems to stabilize. If balls are launched during this period they work fine. If the speed is held for 3-4 seconds without any load on the flywheel then the speed becomes a bit erratic, like the PID suddenly is struggling to find its target. I have found that this only happens at these low speeds and goes away when the power is increased above around 35%. We have played a lot with the coefficients and nothing seems to make this any better. Anyone have any thoughts as to what might be happening and how to fix?
I found PID to be too hard to use and took too long to tune because we strip down the robot and rebuild every 2-3 weeks so I use this code. It keeps the shooter at a near constant speed. Obviously there is a little tweaking for desiredLeftDifference each time, but that is a very quick fix.
task adjustMotorSpeed() {
while(1==1) {
resetMotorEncoder(SL);
sleep(350);
actualEncoderCount = nMotorEncoder[SL];
if (actualEncoderCount > 10) {
powerLevel *= (2+desiredLeftDifference*currentMotorSpeedPercentage/actualEncoderCount*.01)/3;
}
else if (currentMotorSpeedPercentage != 0) {
powerLevel += 1;
}
if (powerLevel-floor(powerLevel)<.5) {
powerLevelInt = floor(powerLevel);
}
else {
powerLevelInt = floor(powerLevel+1);
}
motor[SL] = powerLevelInt;
}
}
@brennanRavan Thanks for the help and suggestions.
Can you say more about the tweaking necessary for this code. Could you help me understand the “powerLevel *=…” line of code? Is desiredLeftDifference a build-in RobotC function? How is this code referenced in the main task?
Sorry for the lack of understanding and basic questions, but we are fairly new to programming. Thanks for your help and patience.
Uhh where did you come up with this. For starters you only adjust your speed every 350 ms so this could never even shoot more than like 1 bps.
At first I thought it was some sort of hacked together I loop but this line threw me.
powerLevel = (2+desiredLeftDifferencecurrentMotorSpeedPercentage/actualEncoderCount*.01)/3;
Can you explain what you think it is doing. Also the "desiredLeftDistance variable is pretty strangely named. I’m guessing you have flywheel on one side of the robot and just left that variable named for the side of the robot it is on.
I have a dual flywheel shooter that has the motors slaved together because I figure both sides will run at about the same speed. desiredLeftDifference is an integer variable that has to be tweaked depending on different shooters. The 350 ms time control is because until the time reached 350 ms, the standard deviations of power levels supplied in the pc-based emulator dropped drastically while they slowly dropped after then. The (2+desired…) bit is also because of more standard deviation testing and averaging the difference caused the speed to adjust rapidly enough while still maintaining a fairly consistent speed level. The speed that the speed adjustment can handle is as fast as the motors will handle with rev up times taking a little longer. The speed gets within 1/27 of the initial error after 1 second, so I find the speed changing to be fast enough.
@jpearman I thank you for pointing out the internal ROBOTC Master/Slave option. It has worked well for our teams flywheel all year. Per my earlier post in this thread, do you have any insight into our recent instability in the PID we are seeing in the lower speed range (<35%)? This started when we significantly reduced the friction in our flywheel drive.
@jpearman I am using the super user menu but still am unable to find the PID tab…I updated to the newest version of RobotC and enabled motors for PID with IME… how do I get it to show up?
Go to Help -> About ROBOTC. What does it say in the lower left corner.
If Window ->Menu level is set to super user the motor sensor setup should have a PID tab.