We have a Canivore bus that is working great with 23 CTRE devices (18 Falcons, 4 Cancoders, and a Pigeon) on the bus.
We want to use Sysid to characterize some of our systems. Sysid doesn’t recognize devices on the Canivore bus. Are we going to need to temporarily move our systems over to the RoboRio CAN bus to use Sysid or can we configure Sysid to use the Canivore bus?
Unfortunately, because SysId downloads its own program to your Rio to do characterization, I can’t think of a way that you would be able to do this without changing and recompiling SysId.
So moving back to the other bus is probably the easier solution.
Changing sysid should be fairly easy, correct? I mean, it just generates a robot file with the given CANID’s, correct? Therefore we should just be able to add CANid , "CANivore Name" to wherever it initializes the motor, right?
No, the build system compiles two C++ robot programs and embeds them in the SysId binary: one for drivetrains, and one for general mechanisms. (C++ is used for determinism when writing to motors and reading sensors; there’s no garbage collector to interrupt the robot program.) After one of them is deployed, the robot program loads a configuration JSON that tells the robot program which devices to initialize.
It would probably take you longer than you’d want to acclimate yourself to the codebase to make this change.
WPILib won’t be doing any more releases for the 2022 season to avoid unforeseen breakage, and we typically don’t do mid-summer releases either. With that said, the Continuous Integration pipeline does provide builds of main if we do happen to merge that feature later. I wouldn’t expect that happening any time soon though. One of the main devs is busy at the moment, and I’m working on 2023 controls stuff.
Oh, ok, thank you. I don’t necessarily need to change the gui for myself, I could potentially just change things so I have a version of Sysid that always assumes CANivore for pigeon and talonfx, right? However if that will still take too much time I probably won’t bother.
Ok, so I did that and it is not letting me build. I made the changes I think are necessary, and that section of sysid seems to build fine, but it will not build sysid-application for some reason. Have never worked with C++ before, so if this is something that’s going to take a lot of explaining I don’t want to waste your time. However, if its a quick change, I’d appreciate it.
Edit: This occurs even when I don’t change anything. Stacktrace:
What went wrong:
A problem occurred configuring project ‘:sysid-application’.
Exception thrown while executing model rule: publishing { … } @ sysid-application\config\publish.gradle line 7, column 3
Cannot convert a null value to an object of type MavenArtifact.
The following types/formats are supported:
- Instances of MavenArtifact.
- Instances of AbstractArchiveTask, for example jar.
- Instances of PublishArtifact
- Instances of Provider
- Maps containing a ‘source’ entry, for example [source: ‘/path/to/file’, extension: ‘zip’].
- Anything that can be converted to a file, as per Project.file()
Do you have a C++ compiler installed? If you’re on Windows, you need Visual Studio. The robot project built because you have the roboRIO cross compiler from the WPILib installer.
Yep, so we figured that out after banging our heads against a wall for about an hour (serves me right for not reading the documentation carefully)… Got it working great after a little bit of work! Thanks!
We now have a version of SysID that works for a TalonFX swerve drivetrain that has drive motors and a Pigeon2 on the CANivore. Very specific case, however it is not particularly hard to change for other cases, just change the files changed in the commits in the below branch:
Edit: Also, if you are characterizing a MK4i drivetrain I recommend the zip-tie method outlined here, worked extremely well for us: