Fluctuating readings from ThriftyBot Absolute Encoders

We are using ThriftyBot Absolute encoders on our MK4i swerve drive. We’re seeing considerable fluctuation in the readings from them, sometimes as much as 10 degrees from the high and low value. This is while the robot is disabled and nothing is moving. This seems unusual to me, but I’m also not sure what I should expect.

We’re using the YAGSL code, and we’re seeing the issue there. But I also created a very simple program using AnalogEncoder.getAbsolutePosition() and outputting the values to SmartDashboard, and we see the same thing there. All 4 encoders are doing the same thing, although some might be fluctuating more than others.

Assuming that this is not normal, what might we be doing wrong?

Thanks!

10 degrees should be >0.1 v on the analog output, and thus should be able to be seen on a DMM. That would help understand if it’s the sensor that’s doing it, or the ADC in the roboRIO.

Since these are analog sensors, you should also carefully consider wire routing. You probably don’t want them next to motor power wires, as you could get induced voltage from that.

3 Likes

We tried a multimeter on the encoders, and did not see any fluctuation there. I’m not the electrical expert, but I was told that the fluctuations might be too fast for the multimeter to really register?

The wires might be too close to the motor power wires - I’ll check that next time.

Thank you for the suggestions!

I have had some really slow to update multimeters, so this is a possibility. A scope would be great, but teams having those is the exception.

The power wire induction case doesn’t really make sense to me (although it is an important thing to check) because the robot is disabled there shouldn’t be any meaningful current flowing through motor controller circuits ( although the physics are more involved than that simplistic explanation )

How are the encoders being powered? (I would imagine off the RIO…) I have a limited grasp on the magic pixies flowing through wires, but I suspect an unstable input voltage is more of an issue on most of the analog sensors. It seems unlikely to me that TTB abs encoder stabilizes the input voltage.

They are just connected to the 4 “analog in” ports on the roborio.

1 Like

When hooked up to a DMM, you should be able to see the voltage change when connected to the Signal and ground as the module rotates. This voltage is proportional to the 5V analog reference, so if the power dips, the signal will dip correspondingly.

As for the fluctuating, I could see this being the case if the cable is routed near motors, motor wires, or can bus, but we have seen very few issues with that. Feel free to DM me and we will make sure to take care of you. If you received duds, we will make sure to get some good ones over to you ASAP.

5 Likes

Yes, we definitely saw the voltage change smoothly with the DMM when we manually rotated the the module. And we saw the values change in code as well, but while fluctuating ± 5 degrees on top of the expected values.

We’ll be checking wire routing next time we can get at the robot (probably this weekend).

Thanks!

2 Likes

In addition to possible issues around the routing of your wiring, you will want to check carefully for any bad/lose connections. With low-current analog signals, this can be a bigger issue than it might otherwise be. A 'scope would be ideal, if you can get access to one. Try wiggling your connections to see if that makes the reading move.

If you wind up redoing your wiring and have some of the twisted PWM cable handy, this might be a good time to use it. Also, try to use cables that aren’t much longer than they need to be, and if you have to bundle up extra wire, do this neatly and away from other wiring if you can.

The point about the motors not drawing much current when they are disabled is valid, which makes checking for not-great connections seem worth doing.

EDIT: You can also measure the 5V coming from the roboRIO, but it should be pretty stable. If not, check what all your RIO is powering @5V. The electrical specs for the RIO are here: Product Documentation - NI.

4 Likes

Thank you so much. All 4 encoders are behaving alike, so I’d be surprised if all 4 have lose connections, but I will pass this along as well and hopefully we can figure it out!

This is what we’re seeing: Encoder Test - YouTube

  • Encoder0-3 Abs are AnalogEncoder.getAbsolutePosition().
  • Encoder0-3 Min and Max are the minimum and maximum values since we started the robot.
  • Tests is just a counter.
  • Based on a comment in another recent thread, I added RobotController.getVoltage5V() (labeled as ‘Robot 5V’). Is this indicative of a power issue with the roborio?

The robot is disabled and stationary.

It seems like the robot 5v is varying by around 0.2v and the encoder readings around 0.01 - 0.05. I’m not an expert by any means, so I don’t know what that signifies or how to solve it. However, I’m also using the thriftybot analog encoders and they do vary by a bit like in the video, but on our robot the variance is about the same for all the encoders, usually around 0.02 in the past. Idk if thats just normal or if we have the same problem.

I will note that I think I’ve seen less variance after changing the housings to the latest versions that Thriftybot sent us after I made a cd post.
Screenshot 2024-01-19 at 7.52.24 PM
(old housings that I saw around 0.02 variance on)

The new ones you can see on the thriftybot website and I think they are varying by about 0.01 or less for us.

Your roboRIO 5v swings seem very high, its possible the encoder reading variance can be attributed to that and the latency with the value polling.

If you look at what getAbsolutePosition() does

15  public double getAbsolutePosition() {
116    if (m_simAbsolutePosition != null) {
117      return m_simAbsolutePosition.get();
118    }
119
120    return m_analogInput.getVoltage() / RobotController.getVoltage5V();
121  }

You can see that the output would be based on a combination of the sensor and the roboRIO 5v bus. Any fluctuations may not be immediate to the encoder pcb and could cause some of this discrepancy. The roboRIO 5v bus i would expect to be much more stable than this typically. If you have another RIO i would test with it to compare.

1 Like

What color is the power LED on the roborio?

1 Like

@mkoopman double check that your case matches the new version, it should look like this -

If it doesn’t let me know and we’ll get you some of the new ones heading your way.

1 Like

sounds to me like a short elsewhere.

an oscilloscope is money well spent. :slight_smile:

1 Like

A scope probably wouldn’t catch a short on the 5V rail. Maybe sure to clean out the RoboRIO too in case there’s swarf in there.

Definitely a problem with the 5V rail.

1 Like

Thank you to everyone who has replied. We have the week off because the students are writing exams this week. But first thing Saturday, we will be checking the power LED on the roboRIO, making sure the RIO is clean, and swapping in our other RIO to see if that makes any difference.

We do have the correct encoder case, so thank you for checking with us on that also.

Hopefully we’ll figure this out on Saturday!

1 Like

Today we opened up and cleaned out both roboRIOs. We reinstalled the original roboRIO, but the issue persisted. We swapped in our second roboRIO, and the problem stopped!
One of our other mentors took the first RIO home for a more thorough inspection this week.

Thank you so much for your help!

3 Likes

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