Our team is programming a swerve drive. Each module contains a Falcon 500 (driving) and a Neo 775 (rotation). When we try to characterize it using Sysid, the error “Error -3 CTR: CAN frame not received/too-stale.” is displayed on Driver Station and nothing runs. We wrote and deployed our own drive code and it worked, so we believe that this is a Sysid problem.
If we can’t fix this problem soon, is there a way we can write our own characterization code from scratch?
Did you mix up the drive and turn motor CAN IDs?
Not that I know of, we’re only using drive motors for characterization right now.
You might’ve accidentally put in the turning motor IDs into SysID. I’d double-check that whenever you can.
I checked Phoenix Tuner and the Sysid config, and confirmed that the port IDs are correct.
Are you enabling in autonomous? Did you select the correct encoder ports? Gyro?
I’d also post a picture of what your driver station and logs look like. Lots of things it could be so it’s better to have more info.
I’m not sure if these will end up fixing the CAN frame issues but…
Generally with drivetrains, the right side motors should be inverted. Check your code and invert in SysID any motors that are inverted in code.
And second, I2C MXP doesn’t seem right… is that what it is in your code? I think normally it’s SPI MXP but maybe I’m dumb and something changed.
We’ll try those changes out and get back to you in a bit. Thanks
We tried those changes and it said that something was wrong with the configuration of the robot, so our original NavX config is correct.
It seems like the System Identification program is running, but the motors won’t. It said the left and right sides moved 0 units.
Interesting… At this point I’ve extended beyond my area of expertise so I’d defer to one of the WPILib experts (calcmogul and Oblarg are good guys to ask about SysId). My only suggestion is just to keep checking your code and making sure all the configuration is the same and that you enable in autonomous mode.
Thank you for the suggestions and help. How would I contact them?
They’re on Chief Delphi, actually. I’ll ping @calcmogul for you (apologies, calcmogul, if this was at a bad time). Cheers!
Thanks
This is a known issue:
You could implement custom logging similar to sysid/sysid-library/src/main/cpp/logging at main · wpilibsuite/sysid · GitHub and sysid/DriveRobot.cpp at main · wpilibsuite/sysid · GitHub that implement the JSON spec sysid/data-collection.md at main · wpilibsuite/sysid · GitHub.
Some teams on the FRC Discord have done this in Java, but the results have been mixed; Java isn’t a good language for deterministic data sampling due to garbage collection being uncontrollable.
WPILib is looking into using CAN streaming and DMA for 2024 to get more consistent data sampling in Java because it would let teams do system ID in their actual robot code and let us remove the buggy and error-prone project generation code from SysId.
Thank you for the quick reply. How effective and complicated do you think writing our own characterization code will be?
You could use this:
With Java data collection, Kᵥ tends to be fine, but nondeterministic sampling causes Kₐ to usually be off by a factor of two or more. frc-characterization’s Java data collection had the same issue, which is why SysId (frc-characterization’s replacement) used a C++ robot program with real-time thread priority for data collection instead.
That came with drawbacks though like not being able to sample data in teams’s actual robot code, and random connection issues and CAN timeouts that we’ve never been able to troubleshoot (none of the SysId devs have actual hardware to use for testing).
Alright thanks for your help, We’ll take a look at their logger code.
I’ve faced this same issue on CTRE in robot code, haven’t tried SysID recently. Opening up Phoenix Tuner and starting the diagnostic server manually seems to make the issue go away as a workaround.
So I should be able to take this code. Switch it to my encoder and motor types then get Ks, Kv
Ka, Kp, Kd.
