My team is having a similar issue to issue #8 , after restarting we have to re-align the wheels. But it seems to have a different cause, as we're using the new code with the fix, and binding the "resetModulesToAbsolute" to a button causes the wheels to do a 360, and not turn to where they should be. We are using the Mk4i L2's, and a NavX 2 (We made changes to the code to make it work with the navX, so maybe that messed something up?) Here's our code: (https://github.com/BlueCrewRobotics/FrenchToast) help would be appreciated!

Description of the Issue
When the robot is enabled, it only moves for approximately 5 to 20 and then stops. Additionally, an error is reported: "internal issue with print and error tags." on the FRC Driver Station.

Steps to Reproduce
After uploading the code, press [Enable].

• Code Link: https://drive.google.com/file/d/1FnMK5D-NExMq3QSRd2-rVercRD_zdk9D/view?usp=sharing

Desktop Environment:

• OS: Windows 10

• Project Information:

  plugins {
      id "java"
      id "edu.wpi.first.GradleRIO" version "2024.1.1"
  }
  
  java {
      sourceCompatibility = JavaVersion.VERSION_17
      targetCompatibility = JavaVersion.VERSION_17
  }

  {
      "fileName": "Phoenix6.json",
      "name": "CTRE-Phoenix (v6)",
      "version": "24.0.0-beta-7",
      "frcYear": 2024,
      "uuid": "e995de00-2c64-4df5-8831-c1441420ff19",
      "mavenUrls": [
          "https://maven.ctr-electronics.com/release/"
      ],
      "jsonUrl": "https://maven.ctr-electronics.com/release/com/ctre/phoenix6/latest/Phoenix6-frc2024-beta-latest.json"...
  }
  
  {
    "fileName": "WPILibNewCommands.json",
    "name": "WPILib-New-Commands",
    "version": "1.0.0",
    "uuid": "111e20f7-815e-48f8-9dd6-e675ce75b266",
    "frcYear": "2024",
    "mavenUrls": [],
    "jsonUrl": ""...
  }

My team and I were wondering if there's a base code coming to 2024. I've seen the branch but we want to be ready before the season starts.

Hi! How would I implement the new pathplanner API? It requires methods that don't exist and I'm not sure how to get the relative speeds and set the relative speeds.

This line:
swerveOdometry = new SwerveDriveOdometry(Constants.Swerve.swerveKinematics, getYaw());

I am getting a error that SwerveDriveOdometry is undefined. How can I fix this?

I just wanted to let other teams know to change the team number in the WPILib settings to their own team number because we were having issues uploading it to our RoboRio since we have our team number set on the RoboRio, which is different than Team 364. This might not happen to everyone else but just wanted to put it out there in case people were having issues during deployment.

Also, thanks to Team 364 for creating this amazing repository that saved us so much time from continuing to try to make the swerve-lib code from swerve drive specialties work.

We are preparing for 2024 swerve and we imported this project and made the necessary changes (team number, motor IDs, etc). we keep getting errors when trying to get the CANCoder positions

CTR: CAN frame not received/too-stale.
from: Talon FX 3 (cani) GetSelectedSensorPosition
at: Stack Trace not received for performance reasons.

we keep getting zero for our position readouts even when purposefully moving the robot.

we aren't sure if this is a problem with the code for 2024 or not, but we wanted to let yall know in case it is an issue with changing WPIlib versions

During testing of our swerve modules, I noticed that a swerve module would sometimes do multiple rotations in the "wrong" direction rather than a short rotation in the "correct" direction. After debugging, the values returned from the CTREModuleState.placeInAppropriate0To360Scope function are sometimes outside of the -360 to +360 range (or -180 to +180? Not sure of the intended return range). This may be caused by the scopeReference parameter being somehow set to a value outside of the -360 to +360 range. This is causing the behavior described above. Is this a known issue and is there a known fix?

What would I have to change it in the code to use the FOC features? For example what would you change the position/velocity voltage methods in SwerveModule.java to? And would you be able to use a fusedcancoder object?

With todays release of CTRE Phoenix 6 officially will you be updating the code base accordingly?

https://www.chiefdelphi.com/t/ctre-2024-phoenix-software-now-available/449023/3

When using the code base and modifying for the NavX gyro instead of the Pigeon and using Mk3 Modules the left thumb stick operates correctly and robot moves as desired. When using the right thumb stick to spin the robot the swerve modules form an X on the bottom of the robot where all the modules point towards the center of the robot. The modules should form an O to spin the robot. Code base is here and any help would be appreciated: https://github.com/github3658/BaseFalconServe

Thanks for making this code base available!

There is something wrong with the turning motor because it can't turn . We use a CTRE Mag Encoder as our encoder and TalonSRX as turning motor, TalonFX as drive motor. Our code is below:

https://github.com/mendax1234/BaseFalconSwerve

After Switching off the robot and restarting it the wheels don't realign to the zero position we need to use a metal 1X1 pipe again to reset it and start the robot Please Do Help Us.

I was wondering how I could limit the speed of the drive motors for testing. Is there a preexisting line of code that can alter the speed or do we need to add a new line? If we need to add a line what would the syntax be?

It should just be another gear ratio, most people are calling this a ".5" upgrade.

I included my desmos with the drive ratio math

https://www.desmos.com/calculator/d7fkjnkfj6

Does 364 have support for wrapping the gyro angle so it fits within the range of [-180, 180)? If not, any recommendations on how to implement this? Would using something from the IEEE library work? @dirtbikerxz

In swerve.java,
the lines
positions[mod.moduleNumber] = mod.getPosition();
&
SmartDashboard.putNumber("Mod " + mod.moduleNumber + " Integrated", mod.getPosition().angle.getDegrees());
throw an error "The method getPosition() is undefined for the type SwerveModule"

sorry, my bad

How would i make a single steer motor on my swerve chassis un inverted while keeping the rest inverted on mk4i imodules

We are having a problem with the offsets or the angles of the modules.We set up the code and changed the constants to suit our robot, and then we tried moving the robot at first everything runs smoothly, the angles are close to perfect and the directions are correct . After a bit of time the modules have a slight change in their angle which builds up slowly overtime , but the bigger problem happens when we reupload the code, the angles become WAY off.
The same thing happened with us last year, and the solution was to make a delay for one sec in the swerve subsystem and then reset the modules to absolute, and that didn't work either.
We checked the constants; trackwidth,type of module,offsets ...etc. But nothing works.
Btw we are using MK4i L2 falcon modules.
Does anyone experience the same thing?
And how can we solve this?

Is anyone else having the issue where if they turn it won’t turn in place? With driving it doesn’t really go forward or sideways but it also starts turning

Thanks in Advance!

Thanks for publishing this code! Very helpful. One problem we're having - when we attempt to move the robot right or left, the wheels only turn 45 degrees. The encoders think the wheels are at 90 degrees. When we attempt the move the robot forward or backward, the wheels align to 0 as expected. We're using the Mk4 modules. Thoughts on what might be causing this?

We had a problem where module 3 would sometimes get initialized to the wrong angle. This started happening more frequently at our first competition. Our drive system was based on the latest BaseFalconSwerve with the 1 second delay added before "resetModulesToAbsolute" in the Swerve constructor. Grasping at straws and thinking it to be an initialization issue we added another 1 second delay prior to the creation of the swerve module objects to allow all devices time to come up. We have not had the problem since. Could the delay have been less? Probably, but why rock the boat during competition. I wanted to record this in case someone else was having a similar issue.

Configuration: Original Roborio, Pigeon 2 and Canivore with Falcons, Cancoders and Pigeon 2. All other CAN devices are running on the Roborio CAN interface.

I'm hoping someone can help us.

We have a brand new setup. MK4is, KrakenX60, cancoders, and a NavX.

We have it all wired up and coded with this base code, configured for our can ids, our dimensions, etc.

When we drive, 3 modules behave as we would expect, but one of the drive motors runs at a much slower pace (less than half the speed, if that).

We have swapped hardware (we have another 4 mk4is for our other chassis), power wires, can wires, and even assigned the can ids to a different module to eliminate hardware. The problem is always with the module assigned to #2 (back left). The problem must be in our code or configuration.

Any suggestions on how else to debug this?

Something odd we're experiencing, it appears our motor offsets are changing every time we reset the robot or deploy code. It's only off by a few degrees each time, but it affects wheel positioning. Does anyone have any thoughts on how to troubleshoot what might be happening?

We have confirmed that the Kraken X60 on the MK4i in L2 Configuration is correct!

--
Stay Cool,
Jimmy McCosker
Lynk 9496 Programmer / Omegabytes 5727 Alumni
CD: Jimmyy
GitHub: witherslayer67
"Words have power, but only when people will listen. When they won't, actions speak loud enough for anyone." -Ryosuke Takahashi

had to change the Kp value in "src/main/java/frc/lib/util/COTSTalonFXSwerveConstants.java" line 289 to 30.0