We are having an issue where upon enable, all modules begin rotating back and forth rapidly and the drive motors spin at a ~medium speed. After doing this for a bit, it will stop but if any control is inputted then it will start again. There is a constant stream of “CANCoder magnetic field is less than ideal.” and “CANCoder reading was faulty.” messages (The CANCoders themselves show that everything is fine). After a few minutes the robot code stops running, seemingly in a crash loop judging by the graphs, and a little while later we loose comms.
I would expect the modules to snap to random positions as the offset is not configured yet, however, back and forth rotation combined with running drive motors is not expected.
When the line setting the default command is commented out, the movement does stop, meaning that one of the commands there was causing it.
I have to assume that something is wrong in either config files because everything else is copied but am not sure what.
Given that they were oscillating, not just spinning in one direction, I am not sure if the inverted setting was correct or not.
I have not tuned the PID at all. Not sure if my memory is correct but the azimuth rotations did not seem in line with they typical untuned PID characteristic of going to approximately the correct position and making overcorrections. They were probably around 70 to 90 degrees.
First ensure your inversion is right. The CANCoder reading error is a response to a less than ideal CANBus utilization and it failed to read what position the CANCoder was at. The Magnetic strength means that your magnetic strength from the magnet to encoder isn’t ‘great’ or if it’s that bad it may be because the magnetic field strength is so bad it’s unusable. Here is the snippet for your issue. If your encoder reading is that bad YAGSL will fall back to the relative encoder’s (integrated into motor) reading.
We are getting the same issue with the CANCoders. All four of our CANcoders say “CANCoder magnetic field is less than ideal.” Wondering if anyone had any thoughts? Thanks.
Oh. Ok. Great thanks. Appreciate you letting us know. I will be in Wed. and check out the Phoenix we are using. Any thoughts on why our Rio Com light would be red, but the drive station Com is green. Drive station says “No Code”. Our code was running, but wheels were not aligning with each other. And we were getting “CANcoder magnetic field is less than ideal.” Now we are getting the red com rio/and no code driver. Thanks.
Reformat your rio, or just redoploy your code, the “No code” light appears when the program isn’t running on the roboRIO as if it crashed. The rio comms light is also tied to the user program if it is running. (I think i have to look the latter up)
From what happened to us, this is most likely a crash loop caused by the sheer number of error messages. You can check the driverstation graphs to be sure.
Purely out of curiosity, does it seem to start fine and get progressively slower/worse until you lose comms?
Ok. Thanks. Used the number setter. That worked. Same issue. This is the graph from the driver station: Cycles out at about 5 seconds. Then restarts at zero with the same graph.
Hello again. Just deployed BaseFalconSwerve as a trial, and it did run code/coms on the driver station. So would that indicate the issue is too many code errors?
O.K. Found that two encoder ids were beyond the 0-31 range. So changed them. Updated the CANcoders back to version 5. Now the 3512 code runs. The swerve unit wheels are not aligned and every 2-3 seconds they make a random adjustment. But never aligned. Wondering if anyone had any thoughts at this point?
