I have noticed an issue combining the Lamprey Encoder with a SparkMax for certain usages - of which the orientation of a swerve module would be one of them. From what I can tell, the only way to connect a Lamprey Encoder to a SparkMax is to run the 10-pin ribbon cable from the encoder to the SparkMax, remove the necessary lines as described above, and then wire the analog output of the encoder to the analog input on the alternate encoder input on the SparkMax (using the breakout board or directly). This generally works fine and you can read the analog values from the encoder on the SparkMax. However, the problem occurs on the transition between 0V and 3.3V. From what I can tell, the SparkMax is taking a rolling average of voltages and then reporting that back. When the encoder is position very close to 0, though, you could get consecutive readings from the encoder of 0V and 3.3V, and then the SparkMax averages them together and tells you 1.6V - i.e., the complete wrong direction!
I couldn’t find anywhere in the SparkMax API to change this behavior. I did see a couple of methods in the JNI interface that looked like they would let you set the number of samples in the average to be 1. The methods were protected but I was able to call them via some sneaky Java coding, but they didn’t seem to actually change the behavior. Would someone from Rev (@Greg_Needel ?) be able to comment on this?
Regarding your other question, one benefit to wiring the encoder directly to a SparkMax (as opposed to the roboRIO) is that you can then use the PID controller directly on the SparkMax, which generally leads to really nice results. Running the PID on the roboRIO would work as well, but is a bit more coding that you have to do and the response rate is probably a bit slower, given the loop timing of the roboRIO code.