Talon SRX issue with Rising Edge encoder

Technical Sensors
1

Hello, the team I mentor is trying to use the Talon SRX Java support to read a hall effect sensor plugged into an SRX breakout on QuadA.
They’ve installed the latest libs and firmware, and do see values when calling getspeed()

The ultimate goal is to PID control the input to a traget velocity. However, as we ramp up speed, the velocity returned send to be in increments of 600. 50 percent throttle is giving 1200, same does 55 percent. At 60 percent it steps to 1800 (1799.999). The next step is seen at 2400. It feels like a sampling rate or rounding issue but we haven’t identified it yet.

The sensor is a 1 square wave/rising edge per rotation (2 opposing magnets).

The motor is a minicim under a small load, with no reduction so it could generate upwards of 5 or 6 thousand ticks per minute, 100 revs (ticks) per sec, 10 tics per 100ms sample loop, etc.

We’ve done something similar before with the wpi libs right on the roborio without issues, this is our first try on the talon SRX interface.

Any ideas? Thanks!

2

You’ve discovered the limitation in the Talon STX speed measurement algorithm. 10 ticks per second at 6000 rpm, means you can only differentiate speed in 600 rpm increments. The Talon SRX algorithm works much better with high count encoders, while wpilibs works best with low count encoders.

3

Thank you Joe - I emailed CTRE support last night after posting this and their responses got me to the same answer. You can’t get more data out of it in the 1 tick per revolution implementation and 100 ms sample period, that’s how many ticks there are at my RPMs…

So now we just have to decide if we should put more magnets on the sensor disk to get more ticks per rev (thus more accuracy in the RPM data), or if we should change to a different, more rising edges per rotation sensor.

I vote for more magnets, magnets are always fun :slight_smile:

By they way, CTRE support once again was AWESOME, with immediate and thorough responses. Thanks guys!

4