YAGSL not steering while driving MK4i L2 Neo NavX

We are using swerve for the first time and attempting to use YAGSL, but seeing wheels not steering when we try to drive them, as well as twitching when they are not moving. We would appreciate guidance on whether we are testing properly (is placing the robot on blocks a valid configuration?), if we just need to tune PID (given the erratic behavior we are seeing, we aren’t sure we are to that step), or if there is something you can identify that we are doing wrong?

Our configuration is:

  • YAGSL
  • MK4i L2
  • NEOs
  • CANcoders
  • NavX MXP

Here are videos of the behavior:

Here is our source code (barber_yagsl_alt branch):
https://github.com/CommandoRobotics/FRC_Crescendo_2024/tree/barber_yagsl_alt

The wheels appear to just stop in whichever orientation they were already whenever we try to drive. Looking at Advantage Scope, we see the drive speeds are tracking desired values (including slow speeds for wheels that are perpendicular to the desired direction) but the steering directions are not tracking properly.

We’ve tried to follow the guides several times on knowing when to invert. It seems our absolute encoder value offsets are consistent.

Also, are there any suggested commands for simple testing operations? I tried to create simple drive forward/rotate/driveXfeet/etc type diagnostic in the barber_yagsl branch, but I do not know if I also need to make calls to update odometry or something. I have not seen a function that sets a desired state for a specific module, but if there is one, I’d appreciate if someone would point me towards it.

I know a lot of people are asking questions about swerve and YAGSL at this point, so I appreciate you taking the time. I’ve looked at similar threads and tried what solved their problems, but not found a solution to ours. We’ve really tried for several weeks to get it right and not have to ask for help, but we are to the point that we do not know much else to try.

I am thinking your conversion factors may be off or you’re not setting them right. Your code is private so i cant check this theory though.

@nstrike , I apologize, the repo should now be public. Thank you for taking a look.

Here was our logic on the angle conversion factor:
Angle Gear Ratio (according to Mk4i site) = 150/7:1 = 21.428:1
Encoder Resolution = 1.0
Angle Motor Conversion Factor = 360 / ( GR * CPR) = 360 / ( 1 * 21.428) = 16.800

1 Like

The video is private too. Can you be sure the video is of FRC Web Components too?

Our current videos were done with Advantage Scope, is that ok, or do we need to set up FRC Web Components?

I am now using direct links to the videos:

In the first one (robot on cart) the driver is commanding full front, then full right, and so on. When the camera zooms into Advantage Scope (blue is desired, red is measured), you will see that the front left wheel is completely perpendicular to the desired direction, but is not attempting to rotate to steer to the desired direction (none of the wheels are changing directions). The other wheels are closer to correct, but they are not changing to redirect to the correct direction. However, you can see that the drive motors are properly commanded: the measured speed of the wheels is matching the desired speed. Also the code seems to be properly calculating desired speeds: wheels that are more perpendicular to the desired direction are desired to go slower, while wheels more inline with the desired direction are commanded faster.

The second video shows the robot on the carpet and we are seeing a similar effect (as it drives toward the camera, you can see that one wheel is almost perpendicular to the motion the robot is going).

It really seems like when the robot is driven (joystick pressed in a direction), the steering motors just stop. Also, as far as the jitter when the robot is not being driven (joystick straight up, or in deadband) it seems the wheels are trying to correct for odometry: when we start up the robot and go to teleop the robot is perfectly still, but if the wheels turn (even hand pushing the tread to rotate them), the wheel reverses from the motion we gave it and then it oscillates and then we start to see the steering motors begin to get involved. Doing this (hand pushing a wheel as though it has driven a distance) with only one wheel results in just that one module doing this while the other three remain sitting still.

I have sen this where either you have misconfigured an ID of a motor or absolute encoder, you need to tune your PID’s, or you have incorrect configurations (offsets, and inversions). Can you try to use the right stick to rotate the robot to a heading while on blocks and characterize the wheel spins?

Reading more through it, this definitely sounds like a PID issue, you just need to tune it.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.