[bharrison6]

Hey guys thanks for your replies. First off, I thank you all for your concern about us pulling this off, however we have a working prototype from last year. It is crude, using team 226's pods and a 1 turn pot to get position, but it works. We are simply refining the design... a lot.

As I said we have already got the mechanical drawings done, we just have to be careful not to actually make a final version yet due to rules. If I am reading the rules right, unless you make significant changes to your drive system you can not make this an off season project and be FRC legal.

I can get an analog input version of the sensor or I can use a low pass filter to make the PWM an analog signal so that's no problem. As it is mentioned earlier there is a risk that the signal having noise at the top and bottom which will cause a problem. This could probably be fixed by using two encoders per pod being offset by 180 degrees. A more elegant solution would be just to figure out how to get a duty cycle of a PWM input in Labview to get the position. Or better yet use the Jag's CAN closed loop to hold a position with PWM (If it was supported).

At this point we have enough data from last year to know that our mechanical systems work well enough. They were heavy and geared wrong, but our updated design should fix those problems. We think our code should be very close to what we need since it did work decently last year. The 2 problems we had with code that we need to fix was. 1. The robot lagged. It was about ~100ms late responding to changes. 2. We had noise around the top and bottom of our pot signal.

Our solutions are. 1. Use close loop CAN instead of analog input to PWM output in order to reduce lag in system. (Maybe the RoboRIO will be powerful enough to fix this on its own). 2. Use PWM input on an absolute encoder instead of a $3 single turn pot to eliminate noise around the top/bottom of the pot signal.

We also added slip rings in addition to the encoder to enable continuous rotation of our pods which gets rid of the last issue of unwinding.

I thought you could use PWM to control a closed loop CAN but it turns out to be just quadrature that is supported. (Which is just 2 PWM signals plus an index signal)

So what I have gathered so far from the responses is 1. Switching from lab view to anything else will not likely fix or help our lag issue from last year. 2. PWM input from an absolute encoder will not work in a closed loop. 3. Analog input for an absolute encoder will not work in a closed loop. So my questions are. 1. Can you use quadrature input which is supported by a closed loop to get position of the pod? (I assume it would required a quick 360 at the beginning of the match to get the index and then just keep up with position from there) 2. If quadrature input to closed loop CAN will not work to control position, then what do swerve teams use? (If it isn't closed loop how do they deal with lag in the system?)

Again thanks for your responses and I look forward to hearing more from you guys.

-Bryant