Trying to Debug Some Java Code

Technical Java
1

Is it fine to get absolute encoder values in this part of our subsystem where we create our swerve module class?

image
image2070×1228 281 KB

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.

Here is the whole file.
SwerveModule.java (4.1 KB)

Any insight would be greatly appreciated.

2

It looks like the encoder should be initialized, so it should work. I would recommend logging the value of the encoder at that point and seeing if it matches what you expect.

3

Do you have all of your code uploaded somewhere (ie GitHub)? Is it the same instance of the SwerveModule that is wrong every time and which instance?

4

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.

5

What was your intention for this statement that does nothing at this time?
AbsoluteOffset = GetAbsoluteValue() - AngleOffset1;

What does reset do? Set encoder to 0 or to the absolute position?
turningEncoder.reset();

There are several places that angles are used or computed and no comments of the range expected at each location and no proof values are in range.

For example, are the units of ((angle/1024)*2*Math.PI) the same as AbsoluteOffset so you can subtract the two?

1 Like
6

We don’t have anything on github at the moment. It is always BackRight which is the last instance we create.

7

AngleOffset1 is initialized on line 29, can’t see it in the image, we should however change some variable names. Things are getting a bit confusing.

1 Like
8

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.

9

From your variable naming it is unclear to me – did you mean to use edu.wpi.first.wpilibj.DutyCycleEncoder or edu.wpi.first.wpilibj.DutyCycle ?

1 Like
10

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
PASTE1
PASTE2
PASTE3
PASTE4
and you missed changing the (last) PASTE4 for its unique parameters.

1 Like
11

We think DutyCycleEncoder is what we want

12

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

2 Likes
13

OK, because you called it DutyCycleEncoder, but it is a DutyCycle:

private DutyCycle m_DutyCycleEncoder;

14

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.

15

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.

16

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.)

1 Like
17

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.

1 Like
18

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.