Team 31 Task Reports

[zeroClearAmerican]

• Task 0 - Background and Preparation
• Task 1 - Install Software (Targeted Completion 10/28/2024)
• Task 2 - Basic Benchtop Test (Targeted Completion 11/4/2024)
• Task 3 - Port Previous Robot Code (Targeted Completion 11/18/2024)
• Task 4 - New Code and Advanced Feature Testing (Targeted Completion 12/6/2024)

[zeroClearAmerican]

TODO for Task 0:

• Run your robot with current (2024) software and note the Free RAM on the DS diagnostics tab (for later comparison in task 3).

[zeroClearAmerican]

Mem: 280444K used, 229496K free, 900K shrd, 11236K buff, 156832K cached

[zeroClearAmerican]

Task 1 Report:

• What problems or difficulties did you encounter?
  • After installing 2025 WPILib VSCode, I logged into my personal VSCode settings sync, then proceeded to open up a copy of our 2024 robot code, intending to upgrade it to 2025. I was given an error message that an extension was not supported from the VS marketplace and to please use the WPILib installer, which I had. I clicked away the error and tried to manually run the import, and I got the same error. Unfortunately I didn't grab a screenshot of this, apologies.
  • To get past this, I re-installed 2025 WPILib VSCode, then when enabling Settings Sync, I chose not to sync extensions and then I started the import tool without opening an existing project folder. This did the trick. It's possible there was something in my synced extension list that caused the problem, but not sure what.
• If there were issues - What was the configuration of the computer(s) on which you installed the software? (System memory, operating system version)
  • Windows 10, i7-9700K, 16G ram.
• What questions did you have during the process?
  • None.
• Any specific suggestions on improving the documentation? (Were any instructions unclear?)
  • Nothing unclear from my end.
• Is there anything else you want to tell us related to this task?
  • Nope.

[zeroClearAmerican]

Task 3 Report

• Note any required changes to your robot program not detailed in the documentation for porting robot code.
  • Did not find any
• What problems or difficulties did you encounter?
  • No major problems encountered.
• What questions did you have during the process?
  • No major questions. Breaking changes and deprecated classes were well-documented.
• Any specific suggestions on improving the documentation? (Were any instructions unclear?)
  • No suggestions pertaining to the process of porting our existing code to 2025.
• Compare the Free RAM on the DS diagnostics tab to similar code running on the 2024 image.
  • TODO once we get back in the lab
• Is there anything else you want to tell us related to this task?
  • Not at this time.

[zeroClearAmerican]

Task 4 Report pt1 - Simulation

NOTE: I realize we're skipping steps a bit here, but since we do not have constant access to our lab, we're working on what we can in the meantime, which is using a new branch of our code to add/implement the new 2025 features. So here is our feedback for that:

• Describe what features you tested and how you tested them.

  • Added Epilogue annotation logging to the robot code
  • Rewrote our LED subsystem to use the new LED Pattern API
    • This involved using the new units library, and it was relatively seamless.
  • Added a persistent alert to indicate an LED loop failure without crashing the robot program.

• Describe any bugs you encountered.

  • After fixing all build errors and starting a simulation, Epilogue encounters an error due to a missing reference to a custom logger. This bug was initially recorded here but if this should be posted somewhere else, please let me know.
    • Currently, this is a blocker to testing the new features as it causes a crash at the beginning of program execution.

• What problems or difficulties did you encounter?

  • Epilogue sometimes reports an error regarding the Epilogue.bind(this) function not existing. This generally is resolved after a rebuild, but can sometimes become "sticky" to the point that you would need to run Clean Java Language Server Workspace in the VSCode commands to get it to go away, even though the code builds with no issues.
  • Had to dig into javadoc comments and existing code examples to understand the new LED Pattern API and implementing StructSerializable. Potential candidates for improving documentation.

• What questions did you have during the process?

  • How do we properly implement StructSerializable for a custom class that we want to log?
  • How do we use the new LED Patterns API to build LED patterns?
  • Our 2024 code uses a ScheduledExecutorService to update LED strips at a faster rate for smoother animations. Is it possible to take a similar approach with the new LED Pattern API instead of using the periodic() function for updates, which limits LED strip updates to 50HZ?

• Any specific suggestions on improving the documentation? (Were any instructions unclear?)

  • The docs seem to be lacking guidance for using the new LED Pattern API. Only through reading javadoc comments were we able to determine how it should be used. Official documentation would be very much appreciated to make this learning easier.
    • The API is astoundingly intuitive and very well-done, kudos!
  • LEDPattern examples sometimes refer to calling a function using the units library like this: scrollAtRelativeSpeed(Percent.per(Second).of(25)). To a new user, this could be misleading because VSCode would report that an import for Percent would be missing when typed this way.
    • According to our testing, the example should include the Units reference before Percent, like this: scrollAtRelativeSpeed(Units.Percent.per(Second).of(25)). This way, intellisense understands and can suggest the correct import for the user, and the under understands that Percent is part of the Units library.
  • We have a custom type that we wanted to automatically log with Epilogue. The documentation says "Any type that inherits from StructSerializable, such as WPILib math types or custom user-defined types" is supported with annotation logging, however it was not clear exactly how to implement this.
    • We figured this out by looking at examples from the WPILib code (specifically Rotation2d and Pose3d) were we able to determine how a struct for a custom type should be implemented and written.
    • If you're going to suggest that teams can implement struct or protobuf serialization to log custom types, please also provide documentation guiding students through the process of implementing these interfaces properly for annotation logging.

• Is there anything else you want to tell us related to this task?

  • Overall, we're enjoying the new features and believe you guys have done a great job! Documentation gaps are expected this early in the process. We hope our feedback helps shed some light on the gaps we encountered.

[zeroClearAmerican]

Thanks for the replies! Will post into those accordingly.

[SamCarlberg]

Epilogue sometimes reports an error regarding the Epilogue.bind(this) function not existing. This generally is resolved after a rebuild, but can sometimes become "sticky" to the point that you would need to run Clean Java Language Server Workspace in the VSCode commands to get it to go away, even though the code builds with no issues.

This is actually an issue with the VSCode Java extensions: wpilibsuite/allwpilib#7103. Basically, the language server bundles its own compiler, which tends to not regenerate the epilogue files and break intellisense

[zeroClearAmerican]

Thanks. I followed your recommendation on that thread to use ./gradlew simulateJava and was able to run the simulation without issue. This unblocks us from moving forward.

Any advice on this question? If not, no worries; we'll test it out and report back at a later date.

Our 2024 code uses a ScheduledExecutorService to update LED strips at a faster rate for smoother animations. Is it possible to take a similar approach with the new LED Pattern API instead of using the periodic() function for updates, which limits LED strip updates to 50Hz?

[SamCarlberg]

Our 2024 code uses a ScheduledExecutorService to update LED strips at a faster rate for smoother animations. Is it possible to take a similar approach with the new LED Pattern API instead of using the periodic() function for updates, which limits LED strip updates to 50HZ?

Yes, you can use TimedRobot.addPeriodic to run a function at an arbitrary rate. Using this will mean slight tweaks to the normal command-based pattern where the commands update the animations (and are synced with the 50Hz main loop)

class LEDs extends Subsystem {
  LEDPattern currentPattern;
  AddressableLED led;
  AddressableLEDBuffer buffer;

  public Command runPattern(LEDPattern pattern) {
    return runOnce(() -> currentPattern = pattern).ignoringDisable(true);
  }

  void updateAnimation() {
    currentPattern.applyTo(buffer);
    led.setData(buffer);
  }
}

// Robot.java
class Robot {
  LEDs leds;
  
  Robot() {
    super(0.020); // 20ms/50Hz

    leds = new LEDs();
    addPeriodic(leds::updateAnimation, 0.010); // 10ms/100Hz
  }
}

[zeroClearAmerican]

Awesome, thanks!