YAGSL working example

Does anyone have a working example of the YAGSL library? The example library isn’t working. All the best.

heres a working example for the old version of YAGSL: Ironclad / ironclad_thor · GitLab.
theres also a branch names “yagsl_update” which uses the next-gen version but that one hasn’t been tested yet.

How is it not working?

4 Likes

We used YAGSL at an off-season competition and it worked great. We plan on moving forward with it in 2024. Here’s the repo: GitHub - frc2357/FRC-2023-Cowtown-Robot: Off season robot for Cowtown Throwdown

What type of absolute encoder did you use? Also have you been able to try and convert this to the latest released version of YAGSL?

Thank You.

We used the new HELIUM Canancoders hooked up to a Spark MAX. We used Neos for all 8 motors.

I don’t think they’ve updated in the last few weeks, but they’re still using this to practice and learn autonomous so I bet they will probably update it again soon.

WE are in the process of getting our swerve drive working using YAGSL and are having issues (political correct term :slight_smile: ).

Basic Information:
SDS Mk4i modules using NEO+SparkMax and then with a CTRE Mag encoder as the absolute encoder and a NavX IMU.

  1. We figured out that part of the issue was version-itis and needed to update our version of the library (Question? Is there any version information in the library itself?). Now we need to deal with the changes to the JSON configuration.
  2. We are using a similar encoder to mentioned in 2357’s post: CTRE Mag Encoder connected by its duty-cycle output to the SparkMax. We know this is giving us data and the encoder show 0->1 output natively.
  3. The wheels are moving (rotating) but not stopping. It does not appear that they are finding their ‘0’ point regardless of the encoder zero offset setting. We know we still have some configuration wrong. We appreciate the examples from other teams that have been able to get a similar configuration working.

I hope this helps to identify any of our problems.

Thank You.

Maybe double-check that you’re specifying the correct spark maxes that the encoders are connected to? Our programmer made that mistake and the modules just kept spinning.

Thanks. I know that the encoders are working since we have the raw encoder value going to the smartdashboard and the values are being shown there.

This does bring up a question:
What should the minimum and maximum values be for the absolute encoders? 0->360, 0->1, 0->2pi, -pi <->pi? I have seen all of these as possible.

0 to 360, Have you tried looking at it with Advantage Scope, or FRC Web Components?

Back from Team 997:
Still not working… The steering motors keep twitching and don’t stop.

  • We tried to change the encoder offset and looking through the code it doesn’t appear to do anything.
  • It also appears that there is a ‘bug’ in the optimization function for the angle is not working properly. When we enable the robot it reaches the setpoint it will swap to 180degrees and then moves back and forth.
  • We can’t get it to move away from it’s 45 degree initial angle.
  • We have tried to tune the PID constants and it still is too twitchy.
  • It also does not appear that the ‘attached’ encoder method is not working. We were thinking about trying the CANANDENCODER method instead??

So question , what are you currently attempting to use as the absolute encoder?
The CTRE Mag encoder with duty cycle is “VERY” different then a cancoder or CanAndCoder. I would make sure your using the right absolute encoder definition and go from there.

What i am thinking is you have an SRX Mag Encoder . Can you confirm that? You would want to make sure you use the one that creates the uses PWMDutyCycleEncoderSwerve and not the aforementioned encoders.

Twitching How? A video would be great.

Yes unfortunately this is known. I’ve looked everywhere in the code and I don’t think I can find it. @nstrike has looked probably more than anyone and also can’t find the bug.

Specifically we are using a CTRE Mag Encoder that has its PWD Duty Cycle output connected to the SparkMax data port’s PWM input. From other code experiments we know that this is working and we are receiving feedback from the sensor (native resolution min=0, max=1.0).
We have configured YAGSL to use the ‘attached’ method and looking at the code, this appears correct. However, we are seeing a number of issues. The feedback on all dashboards (Glass, Shuffleboard and AdvantageScope) all show reasonable values for all the absolute angles (0-360). This is how we know that the PID is trying to set the angle to 45degrees.

I am going to post next Tuesday when we have another meeting and I can take a video of the movement.

For reference here is a link to our github repository we are using. Note that we are working on the ‘simulation’ branch. This is a drive base only has the drivetrain, nothing else.

Thanks for your help.

Enjoy!

you should take a look at how the YAGSL library reads the json file for the swerve module as located in the file from your repo :

Pay particular attention to the switch statement in SwerveAbsoluteEncoder method . If your using a CTRE Mag encoder which option would you want to put instead of attached? When you do attached in your config what does the code do/use for absolute encoders ?

If you can’t figure it out ill be happy to provide the answers to the above questions.

Did this solve your problems?

Not yet.

OK Tracing the code…

  1. ModuleJson first will try and create the absolute encoder (defined as ‘attached’ in the json configuration file) which is defined in DeviceJson.
  2. DeviceJson tries to configure the encoder, however since the encoder type is ‘attached’ it will just return null.
  3. Since it is null it goes into the ‘else’ clause in ModuleJson to the createIntegratedEncoder method in DeviceJson which will crate the encoder with a conversion factor of 1.0

Since the native value from the encoder will read 0-1. Then we are still at 0-1 after this (not change)

I know there is something in the code to convert to 0->360, but I am still looking.

We have been playing a lot with the code, but here is what I believe is the latest: httpYAGSL Code ](GitHub - Team997Coders/2023_YAGSL_swerve at refactor)

look closely at the type of encoder you’ve defined . It is not “attached” but an CTRE Mag Encoder that has its PWD Duty Cycle as you’ve stated above. there is a specific option for that . Can you find which one it is in the switch statement ? Once you do that change that in your config file.

According to all documentation a MK4i swerve module which is configured with NEO motors and using the SparkMax motor Controller and which uses an encoder attached to the PWM input of the SparkMax (via the accessory port) should be a type of ‘attached’. If this is incorrect then this is the crux of our problem. Where is this defined? I cannot seem to see it in the code; when I look at the code for an attached encoder it is read using the correct Rev api.

We do see data from these encoders. Native 0-1 as expected.

1 Like

The end goal of the attached encoder for the SparkMAX on the angle/steering/azimuth encoder is to get a native reading of 0 to 360 degrees. In the rev hardware client with the calculated conversion factor applied does it do this for the duty cycle “attached” encoder on the SparkMAX?

Just read through your issue, and it is intriguing, i think you have everything correct except something on my end that i never thought i would need to account for, REV avg depth Size. There is no way to configure those easily without fetching all of the SwerveModule’s from SwerveDrive fetching the absoluteEncoder (via whatever getter i have) then use the getAbsoluteEncoder function and cast it to AbsoluteEncoder then finally set the sample avg depth.

https://codedocs.revrobotics.com/java/com/revrobotics/absoluteencoder#setAverageDepth(int)