Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CANcoder configurator refresh has chance to fail the first time it is called #76

Open
mjansen4857 opened this issue Mar 11, 2024 · 5 comments

Comments

@mjansen4857
Copy link

For the first call to CANcoder.getConfigurator().refresh() (maybe TalonFX too, we don't use that however so unsure) there is a small chance that the refresh method will fail, regardless of how long the timeout is.

In our code, we are loading the current configuration using the refresh method to keep its magnet offset, then changing the sensor direction and sensor range before reapplying the configuration. However, sometimes this refresh can fail leading to an encoder losing its offset after starting code.

This only happens for the first call to refresh, every other call after always works. We have tried using a large timeout (2 seconds) and that does not prevent it from happening. We have worked around this for now by also storing the magnet offset on the RIO, and using that if refreshing the config fails.

@CoryNessCTR
Copy link
Contributor

Can you take a hoot log of the problem occurring and send it to us?

@mjansen4857
Copy link
Author

I’ll try to get one, but the problem is very rare. It’s only happened 2-3 times in the past few weeks.

We don’t record hoot logs by default so we don’t currently have one.

The refresh call that fails is the first configuration related call whatsoever in our code, if that helps.

@CoryNessCTR
Copy link
Contributor

I can try to reproduce it, but the hoot log would be a great help for debugging the issue. Just make sure you start logging before the refresh call.

Do you have a github link of where it's happening? I want to get as close as possible to your scenario to try to reproduce the issue.

@mjansen4857
Copy link
Author

Our repo is private, but I sent you an invite. The current code is in the pre-flr branch. The line where the refresh is happening is in frc/robot/subsystems/swerve_module/SwerveModuleIOPhoenix.java.

This first gets called when the FL module gets created at line 141 in RobotContainer.java

@mjansen4857
Copy link
Author

The refresh call that fails is the first configuration related call whatsoever in our code, if that helps.

Correction on this, we configure a Pigeon 2 first, so its not the overall first config call, but is the first refresh call.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants