YAGSL - module control help needed, modules won't change angle

I don’t want to spam the YAGSL megathread, so I figured I’d create a new topic in the off chance that this helps others and is more easily searched.

We’re attempting to use the Bronc Botz YAGSL example as a base set of code since we’re very new to swerve. At this point we’re just trying to get it to drive properly.

I’ve used a simple swerve example to test out the modules and all are functioning properly (Note: we’re using SDS MK4i modules, SparkMax motors). We’ve used the YAGSL tuning page to set everything up.

If we have all 4 modules pointing straight forward, driving straight forward/backward works perfectly. If we try to turn/change direction, the angle of the motors does not change. If we try to drive straight left or right (ie. perpendicular to the alignment of the modules) then the motors stop entirely. This happens when using both left and right joy.

If we manually rotate the angle of a module and try driving again, we have a slightly different but predictable behaviour. When trying to turn, the module that has been rotated now will move in a way that makes sense (ie. if we try to drive left, that module will “drive” in the correct direction while the other 3 modules do nothing since they’re perpendicular to the direction attempted).

Basically, it looks like the angle of the modules is being read correctly and power is being sent to the modules correctly to try to drive in the correct direction, but it’s unable to rotate the angle of the modules to make it work.

I’m sure this is probably a ridiculously simple fix, but I can’t seem to figure it out. Any help would be greatly appreciated. I’ve included a link to the code below, but it’s basically almost identical to the example code.

Your conversion factors in physicalproperties.json don’t match the ones on the YAGSL Standard Conversion Factors page. Our team also uses YAGSL and we also had an issue with rotation; changing the drive/angle conversion factors fixed the problem. Hope this helps!

2 Likes

This should be done for sure, you may also want to do the 8 steps afterwards if fixing the standard conversion factors don’t fix your problem. (USE THE STANDARD CONVERSION FACTORS FOR THE 8 STEPS)

1 Like

No immediate help from it, but I’m certain it will make a difference down the line. Thanks!

I’ve changed the conversion factors in phyiscalproperties.json and gone through the 8 steps, no improvement unfortunately. The direction of the motors changed as I went through the 8 steps, but at no time did any of the angle motors engage.

These conversion factors are all wrong still. You need to delete these lines. You are using a cancoder which means your conversion factor IS NOT 360. canandcoder use a conversion factor of 360.

These values are still incorrect too. Change these to the correct values or else no test will be accurate and we wont be able to debug it.

The standard conversion factors state you should use these for MK4i L2!

"conversionFactor": {
	"angle": 16.8,
	"drive": 0.047286787200699704
}

Another issue is your PID’s are 0 which means none of your angle motors should move and even the drive motors shouldn’t move…

Start by setting every inversion to false ESPECIALLY the absolute encoder inversions which you may have mistakenly inverted.

Also delete this folder…

1 Like

Thank you for this, I appreciate all of the help.

For future reference - on the tuning page it asks for the conversionFactor values (I have no idea how I have these values so wrong, but I’m wondering if when I first completed it I thought we were using SwerveMax and didn’t think to change it) for both the physicalproperties.json file and the individual module .json files. Should those be left blank in the module .json files? Or will putting in the same values in all of the .json files still work fine?

I had the values in physicalproperties.json changed locally, but after going through the 8 steps I didn’t sync changes.

As for the PID values - I had recently zeroed them when trying to troubleshoot and completely forgot about it. Thanks for picking up on that.

I’ll update tomorrow when I’m back in contact with the bot. Again, thank you for the help.

Parameter conversion factors override module conversion factors override physical property json conversion factors

1 Like

Isn’t it amazing how things work out when you actually follow the directions properly?

Full, proper control with the left joy now. Next step is tackling the right joy. Thanks for all of your help!

Remember that the right joystick control the angle, NOT angular velocity.

Yep, thanks!

Looking through some of the comments/questions on the megathread, there has been discussion of changing the default drive command. I don’t know if there’s more to it than this, but does that just mean to change the following :

drivebase.setDefaultCommand(
!RobotBase.isSimulation() ? driveFieldOrientedDirectAngle : driveFieldOrientedDirectAngleSim);
}

to:

drivebase.setDefaultCommand(
!RobotBase.isSimulation() ? driveFieldOrientedAngularVelocity : driveFieldOrientedDirectAngleSim);
}

?

And if so, should that be all that’s necessary to get orientation to work? I’ve tried the above change and haven’t seen any effect. I’ve also tried fiddling with the PID values in controllerproperties.json and have not seen an effect.

1 Like

controllerproperties.json has little effect on angularVelocity control if heading correction isnt enabled.

You are correct though that is the change you’d need to make if you wanted to control the robot via angular velocity, however this is not conducive to debugging many issues and would require your drive to get adjusted much more than controlling the heading via a joystick

1 Like

Okay, I think I may be misunderstanding how to make this work then. Or I just may not be using the terminology correctly. Let’s see if I can get this right.

Left joystick controls the motion of the bot - ie forward, back, left, right. - regardless of which direction the front of the bot is pointed in Field Oriented, correct? I can spin the bot in place to any angle and the direction in relation to the field would not change for the left joystick - forward would still be in the same direction regardless of the angle.

Right joystick is supposed to control the angle that the robot is rotated to. It has no effect on the direction of motion. Am I right that the angle the robot is rotated to is its heading? Or have I been misunderstanding this the entire time I’ve been trying to understand swerve?

I was under the impression from reading through the megathread that in order to get the bot to rotate, but still maintain field oriented direction, I had to change driveFieldOrientedDirectAngle to driveFieldOrientedAngularVelocity in that line. But I’m getting the feeling that I’m entirely wrong on this.

So, assuming I’m not understanding this, what am I supposed to be changing to get the result I described above? Because as of right now, we have been entirely unable to make anything happen with the right joystick regardless of what we’ve done to the code.

You are, driveFieldOrientedDirectAngle is what you want, you may have incorrect axis and have to use getRawAxis instead of getRightX and getRightY.

Okay, thanks.

Is there a reason that getRightX and getRightY would work for the left joystick but not the right? Because motion works perfectly using the left joystick, it’s only the right joystick that doesn’t seem to do anything.

Completely controller dependent

Huh, had no idea. Logically I would think that they would both work or neither would work. Thanks, I’ll try that out tomorrow and hopefully the final update will be to thank you for helping to get it working.

1 Like

Success! I have a lot of tweaking to do, but the main issues have been resolved.

Thanks again for all of your help - and for YAGSL in general. Much appreciated!

1 Like

No problem, good luck this season!!

1 Like