Hey guys, my team is doing characterization using SysId, and our results are showing quite noisy acceleration values which we feel like could be messing our Ka constant. Even though our acceleration graphs look noisy, our velocity graphs look quite accurate. Does anyone know what we could do to possibly fix this? Attached below are our analyzation constants, and graphs.
Thanks in advance!
The acceleration plots are always going to be noisy, because acceleration is an extremely noisy variable. Look at your sim R^2 and RMSE figures.
The plots you have look pretty normal; the big “clump” in the middle is all noise from the quasistatic test.
Ok, thank you. Our R squared is 0.99991, and our RSME is 0.044899 which both seem good. Do you know of any other factors that could affect the acceleration of the robot?
Gearbox/transmission friction and wheel-to-ground interactions are both quite noisy, even if their time averages are well-approximated by simple functions.
If you want to see a relatively “clean” acceleration plot, use the characterizer on an underpowered mechanism with a lot of inertia. That’ll lengthen the characteristic timescales of the system response so that the acceleration from the driving signal is more easily distinguished from the noise.
In either case, the green line in the position plots shows the path of a simulated ideal motor with the determined coefficients. If that fits your data well, that is generally what matters.
So it looks like our data is reasonable, but our paths are still not close to being correct. What do you think we should do about this?
Check your unit conversions scrupulously.
We have, and we have gotten the robot to move in straight lines now correctly, however when we try to get the robot to follow paths that have curves in them it just doesn’t work.
Have you run a trackwidth characterization?
No, is that something we should be doing? We are currently just using a measured empirical track width.
Yes; wheel scrub has a substantial effect.
We are trying to characterize our Track Width, but now our Gyro is giving very weird values showing that it moves 100+ degrees each time even though the robot is moving straight. It is weird because when we tried printing out what the Gyro read to the console in Tele-op it is accurate. Thank you for all the help so far!
I don’t think I can help without more data, but I suspect the gyro is configured incorrectly in the tool.
It’s not hard to characterize the trackwidth yourself with dashboard readouts, though; turn in place, measure angular displacement with your gyro and wheel displacement with your encoders. Divide to obtain the trackwidth.
Hi; programmer on the same team as @Amehta here.
I really think it’s an issue somehow with our PigeonIMU, which is really odd considering:
It has worked when not in SysId (gives accurate results with very minimal drift)
We have swapped to a different Pigeon and received the same results, so it’s not the gyro… also see point 1
We have tried connecting the Pigeon to a TalonSRX instead of through the CAN bus to see if it would change anything (it didn’t; not that we expected it to but might as well try everything?)
The only two parameters / ways to configure the gyro in SysId are changing the CAN id and changing a boolean for whether or not the gyro is connected via a TalonSRX… so we know that the way we are configuring it has to be correct, at least in this regard
It’s honestly just frustrating us at this point because despite it working just fine outside of SysId, it still gives wild values for how much the gyro supposedly changed during the tests it runs (again, it should be close to 0, but gives seemingly random results after every run). I’m honestly not sure what else to throw at it at this point… we’re really not sure what else would make the gyro readings so off like that.
I realize it’s hard to troubleshoot with minimal information/data; is there anything we can maybe clarify to potentially get to the bottom of this? Again, we really appreciate any and all suggestions and help… it seems that SysId has really stumped us.
Thanks. 
SysId deploys precompiled binaries to run the test program. It’s possible the vendor support for the Pigeon in those binaries is currently bugged; I’d file an issue report on the github page (or poke one of the devs about it in #programming on the FRC discord).
In the mean-time, I’d suggest doing the trackwidth characterization manually using the procedure I suggested above. It’s not difficult!
Will do on both fronts.
I’d like to think this is the most likely explanation; I think we’ll try it out on another gyro that isn’t a Pigeon as well. We’ll be sure to let you know how it goes!
Did you end up figuring out what happened? My team is currently running into a similar issue.
Short answer is “not really”, however we still have hope for getting it working.
These issues gave us reason to believe the Pigeon was having trouble interfacing with SysId, so we’ve accepted that they probably won’t work until SysId receives an update (waiting on this PR before attempting it again-- planning on trying to compile and run it ourselves from the source code if no new version gets released).
Since this we have expected this to take a while, we have shifted to start looking at other gyros. We first tried the ADIS16448, only to realize that it’s not compatible with the 2022 RIO image… in fact, none of the gyros we have in our shop are compatible anymore. So we’re also on the lookout for that, in which case one of these gyros might do the trick.
Given this, we have ordered a NavX-micro from AndyMark in hopes that it will solve our issues (the regular NavX’s are out of stock). That should come at some point this week (perhaps tonight? 
), so we are REALLY hoping that this will have no compatibility issues with SysId, the RIO image, or frankly anything else. I’ll definitely pop back into this thread after we have tried that or if we find any luck with something else.
Bottom line seems to be either wait for software fixes or get a fresh gyro that is supported by SysId, assuming the problem is what we think it is. If you find a fix for your issues at some point, we’d love to hear them!
This is now fixed. Upgrade to the v4.0 RoboRIO image and WPILib 2022.3.1.
Yes, we have done so, and so far it is working for us, and our acceleration data is less noisy in the new UI. A big thanks to you, and the other WPILib guys for fixing it.
Ok, thanks. We’d like to stick with the pigeon, so we’ll see if we can get it working.
