-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swerve-lib Start Up Fail #20
Comments
Don't use this version of swerve-lib, it's buggy and definitely not actively maintained- might I redirect you to my fork? To address your question though, have you updated the firmware of the CANcoders? |
Thanks, we are looking at your fork, will try it. Yes, CANCoders are on 2022 firmware. Question: why would that matter? Problem appears to be the swerve library is looking for a 2020 library on the Rio, which we don't have as the Rio image is 2022? |
I'm not sure where you see that it's 2020, unless you believe that the |
I did look on the Rio and there is a file called libFRC_NetworkCommunication.so.22 and that file is not downloaded with robot code (as far as I can tell), so I assume it was put on the Rio as part of the Rio image. There are a number of files ending in .22 and none ending in .20, so I assumed a year mismatch. CTRE version is 5.19.4. |
Oh that's why then, you need to update your CTRE vendordep to 5.21.* through the Phoenix Framework installer. I think the 5.19.* version is probably from 2020. |
You are correct about that. Silly me, I did the manage vendor libraries command in VSCode and nothing came up, so I assumed the vendor deps were all up to date. And the rest of the vendor deps were up to date. Will update and try deploy again tomorrow. |
So we tested with your library fork and had problems. One in particular, when enabled the wheels turned outward a bit from zero (straight ahead) without any input. Swerve performed poorly. Switched back to SDS library and things work much more like you would expect, though there are still significant problems. Will be trying your library again, but I wanted to run what is happening by you. With SDS library, when we provide input that is exactly along the X or Y axis (straight fwd/back, straight left/right) the modules turn in correct direction and rotate correctly for the desired motion. However, if there is any input where there is mixed fwd/back & left/right, to make the bot move at an angle, the modules jitter/jerk/twitch (not sure what is best term to describe it) violently. It is as if the modules are being commanded to rapidly turn back and forth around the desired angle. Don't know what is causing this. We have greatly reduced the max speed and rotation values to try to calm the behavior but it remains pretty violent when it happens. Additional question: When translating left or right, the wheels always turn left but the direction of rotation of the wheels themselves changes to give correct left/right movement. Is this turning of the wheel direction always left expected? Thanks for any help you can provide. |
We are trying the template project and when we deploy it fails thusly:
********** Robot program starting **********
NT: server: client CONNECTED: 10.44.50.167 port 57531
navX-Sensor Java library for FRC
java.lang.UnsatisfiedLinkError: /usr/local/frc/third-party/lib/libCTRE_PhoenixCCI.so: libFRC_NetworkCommunication.so.20: cannot open shared object file: No such file or directory
at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
at java.base/java.lang.ClassLoader$NativeLibrary.load(Unknown Source)
at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(Unknown Source)
at java.base/java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.base/java.lang.Runtime.loadLibrary0(Unknown Source)
at java.base/java.lang.System.loadLibrary(Unknown Source)
at com.ctre.phoenix.CTREJNIWrapper.(CTREJNIWrapper.java:10)
at com.ctre.phoenix.sensors.CANCoder.(CANCoder.java:68)
at com.ctre.phoenix.sensors.CANCoder.(CANCoder.java:78)
at com.swervedrivespecialties.swervelib.ctre.CanCoderFactoryBuilder.lambda$build$0(CanCoderFactoryBuilder.java:31)
at com.swervedrivespecialties.swervelib.rev.NeoSteerControllerFactoryBuilder$FactoryImplementation.create(NeoSteerControllerFactoryBuilder.java:66)
at com.swervedrivespecialties.swervelib.rev.NeoSteerControllerFactoryBuilder$FactoryImplementation.create(NeoSteerControllerFactoryBuilder.java:51)
at com.swervedrivespecialties.swervelib.SteerControllerFactory.create(SteerControllerFactory.java:20)
at com.swervedrivespecialties.swervelib.SwerveModuleFactory.create(SwerveModuleFactory.java:32)
at com.swervedrivespecialties.swervelib.Mk4SwerveModuleHelper.createNeo(Mk4SwerveModuleHelper.java:184)
at com.swervedrivespecialties.swervelib.Mk4SwerveModuleHelper.createNeo(Mk4SwerveModuleHelper.java:214)
at frc.robot.subsystems.DrivetrainSubsystem.(DrivetrainSubsystem.java:113)
at frc.robot.RobotContainer.(RobotContainer.java:25)
at frc.robot.Robot.robotInit(Robot.java:30)
at edu.wpi.first.wpilibj.TimedRobot.startCompetition(TimedRobot.java:107)
at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:373)
at edu.wpi.first.wpilibj.RobotBase.startRobot(RobotBase.java:463)
at frc.robot.Main.main(Main.java:23)
This suggests that the swerve-lib was compiled under 2020 WPILib. But the library comments and build.gradle seem to say that the library was updated to 2022. We are using swerve-lib 1.1 (master) and the Rio is imaged for 2022.
Also, it is not clear which branch we should be using, master or develop.
The text was updated successfully, but these errors were encountered: