We are trying to use feedforward control on our shooter system. As of now, we have only been able to run a single fully successful test by power cycling the robot after deploying the testing code from SysId, because it just didn’t work right after deploying it.
We have saved the test output in json but opening it in SysId under “Analyze” crashes the application with no error message.
Here’s our configuration and output json file: sysid-data.zip (174.3 KB)
Is our single successful run corrupted or is something wrong with SysId itself? Can we somehow analyze the data outside the program and get our kV and kA values?
Edit: Now i tried to open the json file in my personal computer which runs linux, the terminal prints out “Segmentation fault (core dumped)” when the program crashes. Screenshot
Edit 2: Here’s the output from “./gradlew run --info” terminal output
Thanks for the help,
-Qubit Robotics #7439 Programming team
This may or may not be your problem, but I have found that sysid crashes when you try to load a JSON file for analysis if you didn’t run every one of the tests before saving.
I just had a quick look at the code, and I suspect the problem may be here.
This happens sometimes due to a network race condition in older versions. It’s theoretically fixed in an unreleased commit. You could try using that instead:
Your data also has numerical conditioning issues (8x10⁷ is way too high), but I think that’s a different issue related to your settings. Your counts per rotation is 0.03, which is unrealistically small. Normally, quadrature encoders have more than one pulse per revolution.
SysId used to be somewhat more tolerant of malformed input data than it is now, on account of the current display logic breaking each run into separate data chunks (and assuming that they are all present). This is probably why your data were previously usable, but now cause a crash.
Since your data are in fact malformed (they’re missing an entire test run), the best thing to do is re-run the test routine. It is possible to generate a fit (even a usable/good one!) on partial test data, but the diagnostics are way harder to interpret - it is better that the tool now fails to run the analysis, I think.
1 more question, we re-ran the tests and the values seem to be ok in the timeplots.py analysis. We entered the gearing values this time and i was wondering whether it calculates the position values from the output shaft or the motor shaft itself? Our unit type is “rotations”.
Our encoder is an am mag encoder installed right on the backshaft of a redline motor
That depends on the gearing and counts per revolution you choose. You can use any shaft you want as long as you’re consistent. Users typically use gearing to the output shaft because that corresponds directly to on-the-ground movement.
