Hello
We are trying to reset our relative encoder from the absolute encoder and it doesn’t work. The code used to test it is attached.
Before initialization, we have :
relative encoder 1436.28 rotations
absolute encoder 0.245672 rotations
The input value for setPosition is :
turningRelativeEncoder.setPosition(absoluteEncoder.getPosition() * 12.8) ;
where absoluteEncoder.getPosition = 0.245672 and 12.8 is the gear ratio ( Our swerves MK4 Swerve Module – Swerve Drive Specialties // MK4 Swerve module / Motor type Neo / gear ratio L2)
Note that we don’t define any conversion factor.
The result should be 3.14 rotations for our relative, but unfortunately we get the same value as before the setPosition (see attached values).
Do you know what could explain this?
Thanks!
I looked at the code, and it seems like the “resetEncoders” step happens in the constructor, which means that the initial value for the relative encoder should be zero, not 1436.28. where is this value coming from?
Hello, thank you for your reply. We have indeed made several deployments without restarting the robot. Can we assume that the relative encoder retains its value from one deployment to the next? We also disabled/enabled from the driver station. I’ve checked my shuffleboard screenshot which I have kept for analysis, and I can see that values increase from one try to the other… do you think my assumption is wrong?
by the way, “avant” means “before” /in french , so avant reset rel4 is the value of the relative encoder before the relative.setPosition/left square+ avant reset abs4 is the value of the absolute encoder before the relative.setPosition
Are you sure that you’re using 2 separate encoders? If one of those is the motor encoder, you may be going about this the wrong way. Absolute encoder + motor encoder is different from absolute encoder + incremental encoder.
EDIT: actually, looking at the code, I’m not entirely sure what I said is true. Still, it would be good to get a picture of the hardware.
Hi
So we are using a SRX Mag Encoder – CTR Electronics](SRX Mag Encoder – CTR Electronics) that we connect to the top of the Sparkmax (with an intermediate breakout board)/ see the only picture I have with me so far…
My understanding is that the relative encoder is the Neo built in encoder that we get through the turningMotor.getEncoder() method and through the wiring between the Neo and the sparkmax, when the absolute is returned by turningMotor.getAbsoluteEncoder() through the gadgeteer cable plugged into the top of the sparkmax; Am I wrong?
so my understanding is that we have 2 different encoders, is it right?
so in that case, are we still concerned by the limitation described by rev and forced to plug our CTR to the roborio? Is so could you please about the wiring (pictures appreciated )
Thanks
Christelle
Well, I think what you’re trying to do here is to run the steering motor in “closed loop” on position, which is a good idea. To do that, you can just use the absolute encoder directly, you don’t need to think about the incremental encoder at all. You’d configure it like this:
to keep my current wiring against the sparkmax
and
to switch to a fully absolute based implementation as I started to do (see attachment) but go for another pid controller ( SparkClosedLoopController rather than SparkPIDController).
Still, I am a little bit afraid by the output of my absolute : see attachment) . Is there a way to improve its sampling rate?
yeah. I think “Closed loop controller” is just the 2025 name for the same thing.
re: coarseness of the absolute encoder, that’s definitely wrong… I’d suggest creating a tiny project that just does one thing in robot periodic: print the raw value of the encoder.
Both absolute and relative values used for the graph were collected every 20ms so with such encoder’s frequency I should get something looking better or at least closer to the relative’s output/curve, shouldn’t I?
Could it be that the sparkmax itself gives a prio to the relative encoder, leading to a deterioration in the quality of the absolute’s outcomes? could it be related to the REV limitation mentioned in the first reply?
As suggested, I will try to make some more tests from a basic project focusing only on the absolute encoder…
@asid61 is talking about the encoder reporting period in the CAN bus, which is configurable. in your code I think you’re saying “factory reset” somewhere, so I think maybe this isn’t the problem? in any case, you can experiment with it, see the bottom of this page:
The Spark MAX will only publish new data over the CAN bus every so often. Especially data like absolute encoder position probably defaults to a very infrequent rate. So even if your robot loop is at 20ms, it just won’t be getting new data until the Spark decides to send it out. You’ll need to use
max.setPeriodicFramePeriod(PeriodicFrame.xxxxx)
Where xxxxx is the absolute encoder frame or equivalent. Check the docs like Joel posted above.
First of all, let me wish you all a Happy New Year :-)!
So I’m going to add this setPeriodicFramePeriod; it’s actually what I was looking for when I mentioned earlier how to improve the sampling rate. obviously It was not the right terminology… I couldn’t find the right translation for the French term that came to my mind… and finally I didn’t fully get the point of the previous answers. It seems clearer now, thank you!
Can’t wait to see the result …
We did few tests today using the setPeriodicFramePeriod and indeed it looks better… For some reasons, we didn’t get proper results right after the deployment of the new code…can’t explain why it came up right afterwards…let’s hope we will keep it right now…
We’ve moved to a fully absolute-based implementation and our first unit tests are promising.
Thanks !
, so avant reset rel4 is the value of the relative encoder before the relative.setPosition/left square+ avant reset abs4 is the value of the absolute encoder before the relative.setPosition
