Swerve Steering Encoder's Drift

Hey, :slight_smile:
My team uses Swerve Specialties’s MK2 modules since the early season of 2020,
since then we’re experiencing the need to recalibrate and zero the steering wheels as often as ~20 minutes of practice; the robot has a growing drift and it doesn’t really go as straight as it should.

I was wondering if other teams have the same issue and how often?
Does the MK3 reduce the need to recalibrate and zero as often?

Thanks, Ofek Harel - BumbleB 3339

What kind of encoder are you using? I would check for slippage on the encoder-shaft linkage. Drift is very odd for absolute encoders.

1 Like

We’re using the MA3 Absolute Encoder for the initiation and from there the NEO CAN encoder takes the control of the module.
it’s probably in the gear I guess - maybe it wasn’t assembled properly.
So this kind of drift is not normal, right?

Definitely not. Try running your control loops using the MA3, or swapping the NEO for a fresh one. It could be a problem with either (more likely the NEO).

1 Like

Just to be clear on what you are calling drift. In your description, I can imagine that you are describing gyro drift, which is very common.

When you experience the drift do all the swerves drift the identical amount or does only one swerve experience the problem or do they all seem to have different drifts?

2 Likes

All the swerves have some kind of a drift but it changes,
I’m not talking about Gyro drift, it’s something else - because if it was a Gyro drift it would straighten up once i reset the Gyro, but it’s not.
I think it’s something in how our builders assembled the module, somehow, I think the gears slide and maybe skip teeth or two now and then.

When I’m talking about calibrating and zeroing I’m referring to the process where you align all the wheels to the robot’s forward direction and calibration the absolute Encoder’s angle to each module

I don’t think it’s there,
The odds that all the NEOs are damaged (8 steering NEOs 4 on each of our robots) is tiny.
As for the encoder, as i understood, most of the swerve powerhouses do their control loops on the inner motor encoder

2 Likes

Could it be a code issue? If you don’t have the right number of counts/rotation set on your Neo, that could appear as drift. Especially if it’s off by just a few counts.

Setting your absolute encoders to do the control loop would help rule things out. Its not nesisarily the final solution.

2 Likes

That’s a fair point, I will try to check this.
Though it doesn’t really rule out all the behaviors.
If it were the main thing a robot code reset will reinitiate the all thing, but it seems more like a physical error gain

Make sure that you are using the correct gear ratio to account for the pinion tooth count and the gear tooth count. Also make sure all the pinions are the same tooth count. If one got built with an incorrect pinion, that one would appear to drift.

A good test would be to lay the robot on the side and then command all the modules to rotate by slowly rotating the translate stick in a circle a number of times (say 10 or 20) and then see if a) all the modules are still in alignment with each other and b) still point straight forward when the control stick is pointing forward.

If you pass a) but fail b) then you have the wrong gear ratio in your code. If you fail a) but some of the modules pass b), then the ones that fail b) were made differently than what the code assumes.

Good luck.

2 Likes

I’m not sure I’m fully understanding what you are seeing. I know that you are doing steering control with the NEO integrated encoder, but let’s start with the absolute encoder because you mention having to re-do the physical, absolute calibration.

Here is what I think I’ve heard is happening:

  1. The wheels are all physically aligned to be pointing precisely forward with the bevel gears pointing the same direction (say right).
  2. Absolute encoder positions are recorded corresponding to these precisely forward wheel positions. Depending on your code, you might record these positions as degrees of rotation, encoder input percentage, or encoder voltage. Let’s just assume for clarity that it’s encoder voltage. For discussion here, let’s also assume these voltages were recorded and inserted into your code as FrontLeft = 0.5V, FrontLeft = 0.6V RearLeft = 0.95V and RearRight = 0.15V.
  3. You start the robot and robot code with this calibration and your code initializes steering controllers for each wheel with the current wheel position, whether each is oriented forward or any other position.
  4. When you command the robot to move straight forward, the controllers steer each wheel (using NEO encoder feedback) to its precisely straight forward position and the robot moves straight forward.
  5. You run the robot for a while using your steering controllers based on NEO encoder feedback and the steering slowly drifts such that eventually if you command the robot to move straight forward, each wheel is no longer steering to the precisely straight forward position.

Here is the part where I’m not sure I’m understanding what you are describing. You say that after this run time, you have to recalibrate and zero the wheels with the absolute encoder. What this sounds like is:

  1. You physically align the wheels to be pointing precisely forward with the bevel gears on the right side.
  2. You read the absolute encoder voltage for each wheel and these voltages no longer match the previous calibration of FL = 0.5V, FR = 0.6V, RL = 0.95V, RR = 0.15V.

Are you seeing this mismatch to absolute encoder calibration after running for the 20 minutes?

If so, are the voltages incorrect for all wheels, just one, or more than one?

If you are losing absolute encoder calibration, it would not affect things during a run since you aren’t using it for steering feedback. However, this problem would need to be cleaned up before worrying about the NEO encoder since the absolute encoder initialization of the relative NEO encoder steering feedback is essential.

If the absolute encoder is losing calibration, I can think of several things that might be happening:

  1. The absolute encoder is not attached tightly to the encoder mount and the entire encoder is rotating within the mount. Firm tightening of the mounting nut and use of the provided or better “lock” washer should fix this.
  2. The absolute encoder shaft is not attached tightly to the encoder gear hub and the shaft is slipping with respect to the gear. Firm tightening of the set screw in the aluminum gear hub should fix this. This set screw should not require loctite.
  3. It seems extremely unlikely, but maybe the plastic encoder gear was not attached to the encoder gear hub with the three small screws and the gear is slipping relative to the hub.
  4. It seems unlikely, but maybe there are teeth skipping between the encoder gear attached to the encoder and the encoder gear attached to the wheel assembly. This is a very low-load gear train, so there really should be no skipping or tooth damage on either gear. Are both plastic gears free of damage?
  5. It seems extremely unlikely, but maybe the plastic encoder gear was not attached to the wheel assembly with the three small screws. This would let the gear slip relative to the wheel assembly.
2 Likes

Yeah, so far so good - you understood me right :slight_smile:

The abs encoder can tell that after a run of 20 min the modules are not aligned (can get up to 3 degrees out),.
The voltage (or angles in our software) is incorrect for more than one wheel, most of the time it’s even most of the wheels.

About the gear’s teeth skipping - they are not in the best condition, it’s more likely than you think that a skip will happen, but I’m still not 100% sure about this.

I’ll hand over your suggestion to the hardware and mechanics teams and we will examine each module.

1 Like

Noted. :slight_smile:
Although it will probobly not completly fix this problem - but it’s woth the try.

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