|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: Finding RPMs with encoder
OK, doing the calculations for 1X decoding: rpm=3000; CPR=250; X=1; secondsPerControlLoop=0.020; So 250 edges fly by every 20ms, which should be plenty enough to get a nice accurate and clean speed signal at 1X decoding. I recommend setting the FPGA sample size to something greater than the default value of "1"... say maybe 64. If you like your code to be super efficient you can compute the edge period time once outside your control loop: secondsPerEdge: float((1/rpm) * 60 * 1/(X*CPR)) = 80e-6 ... and use that as the setpoint in your PID to compare to the getPeriod() process variable which returns the edge period in seconds. When using PID to control shooter wheel speed there are some additional considerations to be aware of in order to be successful. Things like do you want to apply dynamic braking or reverse motor commands when wheel speed exceeds setpoint. I will leave it to shooter-wheel-PID gurus to fill in the details and recommendations. You may be able to get better speed regulation at 10ms. Last edited by Ether : 04-02-2016 at 21:45. Reason: typo |
|
#2
|
|||
|
|||
|
Re: Finding RPMs with encoder
alright, thanks for the help. I don't have means for testing anything right now but all of this was very helpful.
|
|
#3
|
|||
|
|||
|
Re: Finding RPMs with encoder
Update: everything is working perfectly, thanks again for the help.
|
|
#4
|
||||
|
||||
|
Re: Finding RPMs with encoder
Not to be too pedantic, but what do you mean by "working perfectly"?
Could I talk you into posting a trace of your wheel speed vs time? Others can maybe learn from it. Thanks. |
|
#5
|
|||
|
|||
|
Re: Finding RPMs with encoder
Quote:
I managed to get the encoder to show me values in RPM as well as allow inputs to be in RPMs, my big issue was not getting values I wanted as well as not knowing what stood for what in the code. so my result was this... Code:
RPM = 5000.0;
eShooter = new Encoder(1, 2, true, EncodingType.k1X);
eShooter.setDistancePerPulse(3);
eShooter.setPIDSourceType(PIDSourceType.kRate);
pidShooter = new PIDController(0, 0, 0, eShooter, mShooter);
pidShooter.setSetpoint(((RPM/60)*360)/3);
SmartDashboard.putNumber("Motor RPM ", ((eShooter.getRate()*3)/360)*60);
Code:
RPM = 5000.0;
eShooter = new Encoder(1, 2, true, EncodingType.k1X);
eShooter.setDistancePerPulse(3);
eShooter.setPIDSourceType(PIDSourceType.kRate);
pidShooter = new PIDController(0, 0, 0, eShooter, mShooter);
That might have been lengthy and possibly unimportant for those who might look to this for learning about the RPM calculations but the 'setDistancePerPulse' was a big trouble of mine when trying to find what to put in there and is important to the code. 3 would not be the distance per pulse if this was not 1x decoding. Code:
pidShooter.setSetpoint(((RPM/60)*360)/3);
SmartDashboard.putNumber("Motor RPM ", ((eShooter.getRate()*3)/360)*60);
now for what the encoder tells you. getRate() in also in counts per second so it's the exact opposite. the rate in counts per second multiplied by 3 to turn it into degrees, then divide by 360 to turn it into RPS(revolutions per second), and finally multiply by 60 to get RPMs. This might have been a bad explanation or included too much rambling and not enough detail, especially with be just putting in the exact code, if that is the case I'm sorry I'm not much of a teacher, so if you want me to include more specific details let me know and I will say what I did, how I did it, and what value everything (related to this thread) intakes and outtakes. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|