Hello everyone! I am Adan, the software lead to Team 3512 Spartatroniks. I am a senior, meaning this will be my 4th and final year with the team as a student. Hopefully, I am able to come back as a mentor after high school. This post will go into the different projects 3512’s software team has been working on during the 2022 offseason.
What’s new for 2023?
A lot of different changes have been going on with 3512, with software being no exception.
The 2023 season will feature our first robot programmed exclusively in Java. For many years, we have used C++ as the main programming language. However, we are now fully transitioning into Java. There are multiple factors that lead us to this decision, which I will list below:
- Teachability: C++ is quite a difficult language to teach new students. With no similar programming classes available at our host school, we are left to self teach each other how to program.
- No software mentor: We’ve had no real software mentor since 2022, so more responsibility has been placed onto the leads to do more, and C++ was not giving us that flexibility we needed.
- Support: It’s clear to us: A lot more teams are using Java, so we are more likely to get support for Java questions than C++.
Java isn’t the only change we are doing. For the longest time as well, we also used base TimedRobot with our own custom subsystem class implementation. For the 2023 season as well, it’s also going to be our first robot written in the command-based format. We found it easier to write and maintain code, along with new students able to grasp concepts easier.
Another big change for us is the switch to using Xbox controllers instead of our old, bulky Logitech joysticks. That’s a big win to me, as I have to be the one to carry the driver station as technician. At least my life will get easier in that aspect.
With the decision to move to Java, a good portion of the offseason was spent building a curriculum for teaching Java to new students and practicing writing Java code with our 2022 offseason robot. Our current curriculum setup is using Exercism, where we would give a list of exercises for students to complete. This worked moderately well, but we found that new students were easily confused with the wording of many of these exercises. To solve this, thanks to a connection with a parent who works at Amazon, we are currently working towards getting donated access towards their training platform to use to train new students in the future.
We also took advantage of our Romi robots that we purchased some time ago. My software students were able to get a taste of robot programming on these robots, from getting it driving in teleop to a basic autonomous routine!
For the 2022 offseason, we decided to focus on getting our swerve drive up and running. We obtained and built a chassis with SDS MK4 L4 modules in the 2021 offseason, where our previous software lead attempted to get them working in C++. However, he was unfortunately unable to get it functional in time for it to be viable for use in 2022. Our goal for this offseason was to attempt swerve again, but in Java this time. With our protobot still left over from the competition season, we installed a Pigeon 2 and the swerve modules onto it. The plan was to work on it throughout the offseason and take it along with our comp bot to Tidal Tumble. I would then start practicing porting over our 2022 code.
For swerve, we found the current SDS swerve template to be ineffective for us and found it tedious to work it. Therefore, we decided to use the BaseFalconSwerve template from Team 364, but adapt it over to using NEOs. We found trouble getting our code to work, running into an issue with one of our modules being out of sync with the others. However, with the help of @jjsessa, we were able to isolate our issue and get our swerve drive running before Tidal Tumble. I am grateful for your help and thank you once again for your advice. After successfully getting it running, I was able to do a bit of autonomous work and got a successful 3 ball auton before leaving for Tidal Tumble.
Tidal Tumble was a blast for 3512! I also saw it as a huge success for the software team as well. 3512 was able to test its swerve code in a competition to see how it holds up, and glad to say it never had any issues! We ran with our C++ competition robot and our Java swerve bot, and I found the Java bot to have its software run more reliably than its counterpart, which I can say our team is not too used to. All the issues we did run into with the swerve bot were hardware based, but those were able to get ironed out before matches. We are proud of both of our drive teams, with the experienced on swerve and newer ones on our diff drive. Also, took time to finally feed our driver’s camera through the Pi instead of the RIO. To no one’s surprise, the results were far vastly superior.
Programming a Diff Drive
Speaking of diff drive, I had our other software student get practice on writing Java by deploying code to our comp bot after Tidal Tumble. While he was unable to get far, he was able to successfully get our diff drive driving around on Xbox controllers.
Winter Break Projects
For winter break, I decided to take home our 2019 robot and 2023 protoswerve to continue familiarizing myself with robot programming in Java, practice programming an elevator, and continue work on the swerve drive.
I haven’t really had practice programming an elevator, so I took the 2019 robot home, which is equipped with one to get some practice on. I was able to get open loop control using a Xbox controller to control it working right off the bat.
For closed loop control, I wanted to use the external encoder it was equipped with. However, I discovered the wiring for that encoder plug was cut, rendering it useless.
So, I came up with a solution using the NEO integrated encoder and onboard PID, and just fed a Trapezoid Profile state into it to allow for smooth motion. It did work, but the performance wasn’t what I wanted.
However, I did discover that the encoder plug wiring for our back jack (which helped it climb) was still in tact, so after some cut zip ties and managing the cables, I was able to read the external encoder on the elevator and get a state-space solution working on it instead. This allowed for a snappier responding elevator to different position setpoints. In the event 2023 requires an elevator, this is the solution we will go with.
I continued more development on my swerve code, creating a separate repo for it. I was able to switch the gearing to the more comfortable L2 and clean up some of the code as well. Originally, the 2022 protobot had its two front modules inverted 90 degrees to serve as a makeshift funnel. However, the protoswerve was built with the standard module positions, so I was no longer able to factor this, which caused some confusion with teams trying to use our NEO swerve code. Other than that, I was still able to get it up and running with our NEO code.
Unfortunately, I haven’t been able to get super far into AprilTags as I would like. However, I have been able to get the camera calibrated and tags printed out. I do have a few more days until kickoff, so I plan on using those days on getting the robot to read and process AprilTags.
Logging is something 3512 considers greatly important. With a lot of our mechanisms from 2020-2022 using state-space controllers, logging was crucial to use for debugging them when issues arrived. We originally used our own CSV backend with Python scripts to read in the data and plot them with matplotlib. However, it only meant more code to maintain for us. This year, we decided to stop using our own backend and switch over WPILib’s DataLog framework for next season, as our solution started running into problems with freezing up our robots. Using the DataLog framework allows us to continue to have high speed logging with one less thing for our own programmers to maintain. In the offseason, we also caught interest in the AdvantageKit logging framework as well, writing our swerve bot code with it, using AdvantageScope to view the data. While I loved the AdvantageScope application with its different widgets, I wasn’t a big fan of AdvantageKit as newer students ran into issues when porting their code over to it and just having to relearn how to structure your code. With the announcement of AdvantageScope supporting NT4 as well, I decided to write our own wrapper classes around NT4/DataLog instead for the 2023 season. Thanks to the hard work of everyone at 6328, we will still be able to use AdvantageScope, which I’m looking forward to using as it’s an excellent piece of software (That 3D field looking fine though).
A lot has changed since my time on the team as a freshmen in 2020. These changes are going to greatly benefit our team in the future. However, despite that, one thing stays the same: we’ll continue to contribute our part! All of our code since 2011 is readily available to the public. I’m also aware some previous features from our codebases have also been contributed to WPILib, allowing for other teams to benefit from our findings. With time, I might be able to keep that going. Last, but not least, is our involvement with Open Alliance. @Ry3512 and I have been big factors in pushing our continued involvement with it. I’m super excited to be a Featured Team this year and excited to share what we are doing during the 2023 season!
Thank you for reading my post. If you have any questions, I would gladly answer them. Good luck to everyone in 2023 and let’s get ready to get Charged Up this weekend!