Has anyone else used the characterization tool sysid since updating to 2022.2.1?
I put in a bug report at Github, but since I updated the two laptops I have access to (macos and windows 10) the code that deploys and runs for the characterization tests results in invalid CAN IDs and firmware stale messages on the TalonFX motor controllers.
Yes, we are also experiencing this EXACT same error. When we run the tests the robot literally sits and does nothing and we get talonfx errors.
We updated to wpi 2022.3.1 and it still doesn’t work.
For some reason I need to “deploy” from sysId to the RoboRIO twice. After the first deploy, I get simular error messages about CAN IDs. After the second deploy, it tends to work 
We deploy it multiple times, doesn’t work.
This has not been true across all our laptops, but some of them. My Mac never worked for example, but we have since run it from different Windows machines on 2022.3.1.
Interesting. We tried two different windows machines to test sysid and neither work.
I’ve had sysid most recent release version freeze on startup a couple time. Some sort of window or imgui issue as the text appears really small and the whole window freezes up. Then I restart and it works normally.
I have had sysid work multiple times using Neos as the drivetrain motor; is the issue specific to falcons?
We are also having this issue. Our RIO is fully updated, as is our wpi library (and sysid tool). We are also getting can frame / too stale errors (and as a result, failures in GetSelectedSensorPosition and GetSelectedSensorVelocity) in our ds log. We have double and triple checked our configurations, and we don’t see anything wrong with any settings. We’re using Falcons for our drivetrain (with the builtin encoders) with an 8.33 reduction gear ratio and 4 inch wheels. If it’s relevant, we’re using an og roboRIO (not 2.0).
We tried to fix our sysid problems (to no avail) for around a week before we decided to figure out our motor constants ourselves experimentally (setting voltages directly to our drivetrain and making observations based on the meaning of each constant), but to no avail. We tried using the linear mechanism calculator on recalc to find our Ka constant (or at least a close-ish estimate), but the values it gave us led to our drive train very quickly changing directions at the end of trajectories, making an awful gear-grinding sound and scaring us into reflexively e-stopping every time haha. As a side note, does anyone know what the spool-diameter input is referencing on recalc?
Is there any alternative to the frc system identification tool? If we did come up with our values experimentally, what should a proper procedure look like for each constant? If anyone has a solution to any of the million questions I asked in this post, I will love you forever. Even if you don’t have one, share your problems in this thread too so it can gain some more traction. Thanks everyone!
We could look into limiting status frames for all instantiated motor controllers, but I’ve also heard this happen to test robots with only four motor controllers. It’s hard to tell if it’s a CAN issue, a “NetworkTables not delivering the enable or voltage commands” issue, or some kind of OS thread starving. In any case, this is a widespread issue.
There’s not much we can do about it because none of the SysId devs have access to test hardware; we’ve relied exclusively on simulation for development. Almost no one tested the tool during beta either because working 2022 beta vendordep releases came super late in some cases. Given how may combinations of possible hardware there are we have to support, it’s surprising things work as well as they do, to be honest.
Someone who actually has CTRE hardware would have to look into this problem. Until then, consider CTRE support unstable/broken. I’ve also heard occasional issues like this for REV, but they are rarer.
SysId runs a TimedRobot instance at a 5ms loop period with the main thread set to an RT priority of 15. If it overruns, that could prevent a background CAN thread CTRE has from running. There’s a lot of possible causes for an overrun.
The dynamical model is an affine one of the form \frac{dx}{dt} = -\frac{K_v}{K_a} x + \frac{1}{K_a} u - \frac{K_s}{K_a} sgn(x). We use ordinary least-squares (OLS) with (acceleration, velocity, voltage, sign(velocity)) tuples to find the coefficients, then divide things as appropriate to get the individual feedforward gains.
The robot program doing the sampling is running on an RT thread for consistent sample timing, and the data itself gets filtered a lot to make the fit not suck. We also display simulations of the given dynamical model to demonstrate goodness of fit.
You’d have to replicate the OLS part at least for a separate tool. frc-characterization did some of it, but we replaced it for a bunch of reasons including maintainability and quality of the gains produced.
Another option is implementing the logging in your own robot program by likely translating the logging part of https://github.com/wpilibsuite/sysid/tree/main/sysid-library/src/main to Java. Beware of bad sample timing from the GC getting in the way (pauses can be from 1ms to 100ms, which is a serious problem for things that accelerate quickly).
4061’s released pre-season code has logging classes compatible with SysID’s logger and analyzer. Find it here: git clone https://bitbucket.org/sciborgs4061/java-robot-2022-beta-public.git
You can then ignore the Generator part of the SysId and just use the Logger and Analyzer portions.
I should add that we designed our encoder-reading functions so that they all return in units of meters (i.e. all gearing, counts per revolution information, etc. is accounted for in the robot code so the units to choose in SysId are Unit Type=Meters and UnitsPerRotation=1.0 for the way we do things. If your conventions are different you can adjust parameters in the Logger and Analyzer to accomodate.)
The classes you need are SysIdDrivetrainLogger, SysIdGeneralMechanismLogger, and SysIdLogger. Also the Command classes Characterize for the drivebase and CharacterizeShooter for a flywheel.
An advantage of building the logging into normal robot code is that it can be used in the simulator and the Romi, for training purposes. As @calcmogul said, you give up consistent timing and very short robot cycles leading to potentially less-accurate gains. But we find that it gets us in the ballpark.
Thank you for the detailed response. It looks like we’ll be making or adapting an existing logger to find our feedforward gains.
Without knowing much about how sysid actually works, how much work is the RT thread actually doing? If it’s filtering and sending networktables and etc etc… that’s probably too much work. Why not just have the main RT thread just put the sensor data on a queue (since that’s the only part that needs to be RT), and then have a waiting non-RT thread actually process the queued data and send it onwards.
An efficient queue could use a statically sized ring buffer to avoid allocations.
It also looks like your networktables usage could be a lot more efficient too: sysid/sysid-projects/drive/src/main/cpp/Robot.cpp at 215a45b06f937e9e23542a29bfc6a6fc273e0839 · wpilibsuite/sysid · GitHub is using frc::SmartDashboard, which is going to be doing key/value lookups each time. The original RobotPy version of this code also used SmartDashboard, but I wasn’t shooting for super accurate RT performance at that time. It should be changed to use NetworkTableEntry directly – and probably not in the RT thread to avoid per-call lock contention (at least 6 locks at that location).
Looks like a bunch of low-hanging fruit that could yield some efficiency gains. A profiler might help find some of this too.
[Edit: made this comment into a github issue at sysid robot program performance suggestions · Issue #371 · wpilibsuite/sysid · GitHub]
This is how the tool works now; NT is not able to keep up with a 5ms loop.
Except for the piece in RobotPeriodic? And also LiveWindow isn’t disabled – nope, apparently it is.
Do you do anything before (e.g. load a file to the analyzer) or is that an issue on startup?
A PR was just merged that removes those six NT data pushes in autonomous. The only other thing happening in autonomous now are calls to position and rate getters, and pushing that data into a preallocated vector.
Here’s a link to the builds. Let us know if it’s still broken so we can narrow down the problem further.
frc-characterization … we replaced it for a bunch of reasons
The one nice thing about frc-characterization was that calling it with “drive new” created the source code for what’s running on the robot during characterization. With sysId, I can’t see what’s pushed onto the robot and then fails.
That custom Java robot program had a lot of scheduling jitter, which introduced a lot of measurement noise and made the acceleration feedforward gain fit useless. C++ got rid of that issue, but we bundled the precompiled robot program in SysId so the user wouldn’t have to have a C++ compiler installed.
frc-characterization used to generate just the necessary code for a robot project, but that was a template/code generation nightmare, and also had its share of bugs. The JSON-driven approach SysId uses is a lot more maintainable.
Issue on startup, I’d suppose.