Consistent Encoder RPM Issues
 

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.

Thanks,
Team 4302

Re: Consistent Encoder RPM Issues
 

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().

Re: Consistent Encoder RPM Issues
 

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?

Re: Consistent Encoder RPM Issues
 

The second one. Once the period of the ticks gets sufficiently small, you may only be able to measure in buckets of 5-10% of your RPM.

Re: Consistent Encoder RPM Issues
 

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.

Re: Consistent Encoder RPM Issues
 

A 250 count encoder should work if you set it up properly.

- Physically disconnect Channel B. Don't use it. Use Channel A only

- Create an up/down Counter object (not encoder) on the Channel A signal, and set it to count rising edges only

- Set the FPGA sample ring buffer to 125 samples¹.

- Use Counter getPeriod() method. RPM = 60/(250*getPeriod())


Can you provide some more detail about your shooter design?

- what motor controller(s) are you using?

- what motor(s) are you using?

- how are those motor(s) connected to the wheel(s)?

- where and how is your encoder mounted?

Depending on the answers, you may be able to use the very simple bang-bang speed controller algorithm.


¹if you don't know what this means, ask

Re: Consistent Encoder RPM Issues
 

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

SetUpSource([channel A]);
SetUpSourceEdge(true, false);

Except then I don't know what channel I drop in when I am making the instance of the Counter class. Also channel A?

Re: Consistent Encoder RPM Issues
 

Could you post a picture? I'm concerned about vibration.

Re: Consistent Encoder RPM Issues
 

Can you post a simple hand-drawn sketch? I'm not sure I follow you.

Re: Consistent Encoder RPM Issues
 

What programming language are you using?

Re: Consistent Encoder RPM Issues
 

I am using c++

Here are the pictures.

Re: Consistent Encoder RPM Issues
 

Does your camera have a macro setting?

Re: Consistent Encoder RPM Issues
 

Using my phone. First time was me being too quick.

Re: Consistent Encoder RPM Issues
 

Since you didn't ask, I assume you already know what this means and how to do it:

Re: Consistent Encoder RPM Issues
 

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.