We are using 2 motors on our shooter, controlled by 2 Talon SRX’s. They are 775’s running through a dual input to a 3:1 versa planetary, with a CTRE versa encoder handling sensor duties. One Talon is slaved to the other. Because of clearances we were forced to move the encoder from the output stage of the planetary stack to before the 3:1 stage.

As a result, selecting CTRE Mag Encoder in LabVIEW results in a RPM 3x what the actual output of the shaft is. We attempted to select just a standard quadrature encoder, then set the CPR to 3 x 4096 that should result in a correct output RPM, but we saw numbers out of the Sensor Position that did not make sense.

Edit: I see that one of my mistakes may have been that a CTRE counts at 1024 per rev, whereas I was using 4x that (4096). Shame on me for confusing counts with ticks. However, that wouldn’t affect the PID tuning problem we’re seeing below since we ended up just doing the math ourselves.

In addition, we had to reverse the closed-loop output because the motors were running backward. As a ‘dirty’ fix to the CPR issue, we did the math ourselves - we multiply by 3 when we set RPM and divide the sensor count by 3 to graph it.

So after the dirty math, we can get in the neighborhood (+/-10 or 20 rpm) with feed forward easily, but when we start increasing the P term to decrease the error, nothing happens. We start with a very very small value like .00001 and begin increasing it. Now here’s part of the weird behavior - the P term will end up slowing down the speed, regardless of the actual error. Then, if we continue increasing it the motor shuts down abruptly. In the PID’s I have written, continuing to increase the P term would result in increasing oscillations - but we aren’t ever seeing oscialltions that I would expect.

The problem is that obviously just using the feed forward term has a very slow ‘recovery’ time.

Any hints as to why we are seeing this? We actually have 2 shooters running and are seeing the exact same behavior. That tells me that this is expected and we must be doing something wrong.

Also keep in mind the CTRE Mag Encoder’s maximum angular velocity (15k RPM in quadrature mode, 6600 RPM in PWM mode). These are electrical/decoding limits, not mechanical. It is possible to exceed this on the input stage off a 775 Pro @ 12V.

Nope - never checked the phase. We just used the closed loop inverse to get the shooter to run in the ‘right’ direction for us, and the graph on the sensor velocity was positive so we were happy. I’ll verify the phase at states - but we didn’t see a runaway which is what I would expect if the phase were reversed. Hopefully it’s that simple - I’ll check Wednesday when we tear into it at States.

Jared - that was the first thing I confirmed during troubleshooting. We are running the first set of motors at 3:1 on the shooter (4000 RPM on the output shaft) and the second set 4:1 on our accelerator (3000 RPM on the output shaft). We should have more than enough headroom on both since the motors should be running around 12000 RPM.

The Talon lets you set limits on the output range (ex. for a flywheel, you may want to disallow negative voltages). This could help mask positive feedback if you have a sign reversed.

Per page 134 of https://content.vexrobotics.com/vexpro/pdf/Talon-SRX-Software-Reference-Manual-20170226.pdf (section 17.1.10-11), looks like there are two booleans - one to reverse the input sensor’s sign, and one to reverse the output direction’s sign. When you manually rotate the shooter wheel in the direction you want it to go, does the encoder return the correct sign speed? I agree with your assumption about P - the fact it decreases your motor speed would tend to tell me it’s pushing your speed in the wrong direction (if the sign is flipped, “any error” actually means a big number in the wrong direction).

Looking at the closed-loop error output from the SRX (17.1.12) might also be enlightening - With FF as you have it and P set to zero, does the closed-loop error go toward zero?

Edit: Just realized this might be the same recommendation as “checking the phase”. Apologies if repeat.

Our phase was, indeed, out. But we were also struggling with a couple other misunderstandings about the Talons (completely our fault). First, we did have ticks and counts confused. Secondly, you can’t over-ride the CPR if you select a CTRE Mag Encoder.

Finally, we found that we were self-destructing the mag encoders. When our ultrasonic sensor hit a wall that was angled at 45 degrees or more, it didn’t see it. That set the distance to 23+ feet, and maxed the speed out on the shooter. As a result, the dual 775 pro was driving the encoder at speeds approaching 16000 RPM, and the magnetic disk in the encoder was heating up and detaching from the plastic gear (melting).

Afterwards, we moved the encoders back to the output stage and solved a couple problems at once. No more melty encoders and no more worries about math. Then we fixed the phase and it all worked perfectly after that.

I might highjack this thread a little bit. We just started using the Talons speed control at Champs this year, and it was wonderful how easy it is to use.

That being said, what is the difference between counts and ticks? It might explain why the units on the speed and the units on the closed loop error were different. With all gains at 0 (so it wouldn’t spin), we put the setpoint to ~3200prm and observed a closed loop error of ~21,000-22,000.

When putting the feedforward on, the speed jumped up to about 3200 rpm, and the closed loop error fell to ~200-250.

So we were wondering what the units were on the closed loop error?

With regards to counts and ticks, a quadrature encoder will give you 4 ticks per count. So if it’s a 128 count per rev encoder, you’ll get 4x that many ticks.

In position mode with a CTRE encoder, a closed loop error of 4096 (ticks) is one full revolution. Because a CTRE mag is a 1024 count per revolution encoder.

From the manual - velocity is measured in change of native units per 100ms. Native units, in this case, are ticks. So your closed loop error is the native units per 100ms at 3200 rpm.

Math:
1 RPM = 4096 ticks.
3200 X 4096= 13107200 ticks per minute.

Divide by 60: 218453.33 ticks per second.
Divide by 10 to get to 100 ms: 21845.333 ticks per 100 ms.

Make sense?

Or to make life easier, take your closed loop error and do this:
Closed Loop Error / 4096 * 10 * 60 = RPM

If you’re referring to the CAN wires, then one green/yellow pair can go to the RIO, and the other pair to the PDP. If you do this and have more than just those three devices on the CAN bus, you will have to set the terminator jumper on the PDP to the “OFF” position and include your own 120 ohm resistor at the end of the chain.

You should start a new thread for these kinds of questions, but I digress.
Lots of places sell Talon breakout boards. CTRE themselves sell some breakouts and data cables.
My favorite breakout is the MVRT breakout board on ebay. It just looks the nicest to me and breaks out everything important. Most other boards are too large or don’t break everything out.

EDIT: The Sentinel board looks good too, although a tad large.

If you’re really desperate, such as it being Ship Day and you realize you never bought a breakout board, you can press the strands of an Ethernet cable into the ends of a Talon SRX data cable, and then solder / connect those wires to your sensor of choice.

Don’t do this if you can avoid it - buy a breakout and solder to that.