The GetAbsoluteValue method is what actually gets the encoder values. The reason I ask is the AbsoluteOffset variable ends up being completely wrong for one of the instances of SwerveModule a lot of the time. Some times when we push code it is exactly what it should be and sometimes it’s not.
We checked the raw output of our absolute encoders and they are always what they should be so there is a disconnect somewhere in the way we are getting the encoder output in our code.
I also don’t see where AngleOffset1 is getting initialized? Am I just missing it? In this case Java will assign it 0 as the default. Is that what is messing you up? You have AngleOffset (no number 1) passed into your constructor but it is not being used.
On the code I downloaded on line 29 it is private double AngleOffset1; which means it will always be zero. AngleOffset (line 34) in your constructor is a parameter that is not being used. If there is updated code, something like GitHub would be useful.
Without the rest of your code it is hard to see if either are problems, but I don’t think you need/intend to have an unused parameter in your constructor, and a class member that is always 0.
Edited to add AbsoluteEncoderReversed(line 34) also is an unused parameter to your constructor.
You didn’t indicate any of these good suggestions led to solving the problem so we get to the next phase of troubleshooting - the problem is not where you thought it was. I’ll guess (since we can’t see code) COPY/PASTE error.
COPY instantiation statement
and you missed changing the (last) PASTE4 for its unique parameters.
Sorry for the unresponsiveness to some of your questions. I have been away for a bit. Tonight we will just look through all of our variables to better understand what is used where, and what isn’t used and also look at some other suggestions. I will try to update this with the full code too if I get some time later today. Thanks
Update: we were able to get everything to work. We ended up needing to just wait a small period of time before grabbing the absolute encoder values. Getting them immediately as the robot is being booted caused error in the values. Not sure I fully understand why this is but adding a wait period of like 500 milliseconds solved our issue.
It’s good that it is working. But a few of us pointed out some issues in the code that you might want to consider anyway.
Also, I would consult the documentation for your encoder, or post some more info here and I’m sure someone can help. I don’t think waiting 500ms should be necessary to read encoder values. You may be covering up a problem for now that will be a bigger issue down the line. So I think a better understanding of why the 500ms is needed (if it really is) might be good.
Assuming everything is working perfectly I can see how the value would take up to 20ms to update after instantiation (the driver station value update period). So my conjecture is wait 20ms - one robot iteration - to assure synchronization or maybe better described as co-ordination with the DS. [It’s a guess; I have no special knowledge of robot internals.)
Yes we cleaned up most of our code using some of the suggestions from here. We were in a bit of a rush to finish up before this weekend’s offseason event we are going to so that is why things were a bit hectic throughout our code. 20ms could work we just never tried going that low. 500ms delay works and I think we will just keep running like that but keep it on our radar if something goofy starts to occur since that could be why.