Hello, I am trying to remove the CANcoders from this program: GitHub - Team364/BaseFalconSwerve
but every time I try to the output log says “CAN Frame not received/too-stale. CANcoder 3 GetAbsolutePosition” So I am removing it wrong but I am not sure how. This is the first time I am attempting to program a swerve.
Unfortunately I do not have the answer for you, but just so we don’t talk in circles can we get a touch more context as to why you are pulling out the CANcoders? (Just to avoid an X Y problem situation)
Do you intend to replace the CANcoders with another form of absolute encoder? “CAN Frame not received/too-stale. CANcoder 3 GetAbsolutePosition” simply means that the code is calling for an input from the CANcoder but it is not able to receive it. The solution to this would be to change every reference to the CANcoder within the program to whatever new encoder you intend to use, so that the code is not calling a non-existent encoder anymore.
I am removing the CANcoders because one of the CANcoders I am using is not working properly. There is no continuity between the green wire on the male and female ends. I also do not have any replacements on hand right now. I want to make the swerve drive run so CANcoders are not a necessity for me right now.
I do not intend to replace them, I just want the swerve to run for testing purposes. I will replace the bad CANcoder when I get a new one.
In that case, you have 2 options to operate your robot without making meaningful changes to the code-
-
you may be able to rewrite a small portion of the code to utilize the integrated encoder on the rotation motor instead of the CANcoder for the module with the broken CANcoder. I would have to look at the code to be able to tell you specifically how to do this, so take this option with a grain of salt.
-
You could set the module with the broken CANcoder to listen to another module’s CANcoder instead, basically making it into a follower for the other module. This would significantly impact the operation of your drive train and if you’re driving it on the ground, it (might) potentially damage either the floor or the wheel/tread of the module that you are using, so run this option at your own risk as well.
If you are doing some sort of simple testing/calibration with the swerve and it is not operating on the ground, you should be good to attempt these temporary fixes, but I would recommend against driving your base until you have repaired the CANcoder.
Absolute encoders on the 364 Falcon Base are constantly utilized to individually track the position of each module, so they are pretty essential to the normal operation of a drivetrain, so I cannot imagine a solution that would allow you to fully circumvent using an absolute encoder without making changes to the code.
I will try to do both options, I’ll start with the second option though, and see what happens.
Let me know how it goes and if you need any more help!
So I was able to connect the CANcoders but I now have the issue of the swerve modules driving in the wrong direction. The front right drives forward while the back right drives backward.
Was this a pre-existing issue as well or did it only come up now that you’ve changed the CANcoders? If this is a new issue you could temporarily invert the drive motors for the dysfunctional wheels and just change it back once you restore the broken CANcoder.
I may be able to help you more explicitly if I could take a look at the code and see how your modules are set up.
The code I am using is based on this repository:
I think the wheel direction is probably inverted because it is now posed in an opposite position than it would have been if it was using it’s native CANcoder. I would recommend just inverting the motor input on the drive wheel of the module with the non-functional CANcoder, which should fix your issue for now. Just remember to remove the inversion once you fix the CANcoder.
Actually, changing the angle offset seemed to do the trick. -180 degrees.
Great! let me know if theres anything else you may need. I’m not an expert but I’m around to help with any questions you may have.
So I’ve run into a new issue. The three modules that do work don’t reset themselves upon teleop enabling. If they do reset then the controls become messed up. Right strafe is forwards and forwards is right strafe.
Edit: This occurs whenever I turn off the robot without the wheels facing forward. If they face forward then it works fine after I turn it back on.
How does the robot behave when you use the zero gyro command on your controller? If it properly zeros the robot in reference to you, it will help to find where the problem may be.
Edit: the reason I ask is because as far as I’m aware, the modules are not support to re-zero at teleopinit, and instead use the last zero called. By default, the robot can be zeroed by pressing the Y button on your controller (or its equivalent if you’re not using an Xbox gamepad).
On our robot, we always reset the robot code before testing, which will also result in a zero, since it runs the robotinit function.
I was looking into the issues page on the repository above and I may have found the issue. The magnets are not loctited in with green loctite nor are they superglued.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.