Hi all. I am trying to figure out how to get encoders to read consistent values for speed. We have 250 count encoder (e4p) on there and using getRate() they read correctly at low RPMs but once it starts hitting 6000 rpm then we start seeing variations of around 15 revolutions per second. These are mounted on a mini cim. I don’t really know what to do at this point. I have tried varying them from k4X to k1X with no real difference. My other thought was doing some kind of
reset
wait
get elapsed ticks
get elapsed time
calculate rpms
as I am under the impression that the variation could be due to the miniscule time frame between ticks that WPIlib uses to calculate the rate? I couldn’t figure out how to spawn a new task to do this is and I do not want to block my code. Essentially I have run out of experience and I couldn’t find much in the way of code examples or a clear solution to my problem.
So here is my goal:
Get a clean rpm reading useable in PID or other algorithm to ramp up a frisbee shooter to the desired speed.
My problem:
Highly variable readings at higher wheel speeds.
Use a lower CPR encoder. We were running into resolution issues with the timer once the square wave’s period got extremely small. Less ticks = bigger period = more resolution.
We get fairly good results with a retro reflective optical sensor pointed at a piece of tape on the shooter wheel. We got terrible results with a 32 CPR encoder. We are calculating RPM with Counter::getPeriod().
So the problem is that the Crio is randomly dropping ticks or is it that the timer is trying to measure immensely small time periods and failing to do so accurately?
Well that is encouraging. In that case is there a way to start another thread as I have not been able to with startTask. Function pointers in classes are beyond me as of right now which made it impossible for me to use startTask properly. I then wanted to use
(tickGet() * 1000) / sysClkRateGet())
To calculate time however “tickLib.h” doesn’t want to compile either.
Ideally I do not want to impact responsiveness. I do not think we will be able to modify to a different encoder at this point. If you think it is worth switching encoders could you link to the one you have purchased. I am not familiar with retro-reflective encoders. Thanks.
EDIT: The idea is to create another thread, sleep in it for some time, then measure the rpm. That way I should allow the other thread to run while getting reasonably accurate speed. I think this is correct.
Oh oh. It is wired to use channel B. I will disconnect that then and try as you say. The encoders are mounted on a shaft extension coming out of a cim in one case and a mini cim in another. The wheels are on this same shaft. It is supported at two points. The encoder is right over the end of the shaft extension. I saw mention of bang-bang but never really delved too much into it as the readings were a little iffy.
So essentially wheels, encoder, motor all spin same speed. The encoder is mounted with screws and sits on the end of the shaft. We are using Victor 888 speed controllers.
I will post back shortly with results.
EDIT: Is it really necessary to disconnect the B channel or can it remain plugged in some arbitrary spot? The ground and power are wired to separate wires unfortunately so unplugging it entirely is not really an option without modifying the wires.
EDIT 2: I do not know how to set the FPGA sample ring buffer. I think that in order to set the rest up I need to make the counter and do the following
I asked in a second edit earlier. Not sure at all. Sorry I checked the docs and then I realized I have no idea how to do this stuff correctly without some experimentation.
Without recompiling, just setting everything up I am getting a spread of 1100 rpm at max speed. Between 5200 and 6300 rpm so the same issue as the encoder class with pretty much the same spread. I am unsure of how to handle the FPGA but I will keep digging around. Thanks to everyone who has helped out so far. You guys showed up quick!
