Embedded Files
Define
The primary question that drove this project was: How can we improve our 2025 in-season robot, so that we can achieve better performance at our offseason competitions CCC and MTTD?
With this, the code team decided on 4 different aspects to work on:
Improve odometry of swerve module wheels
Improve vision tracking of AprilTags on the game field
Improve/redesign the Auto Align strategy for more accurate and consistent alignment
Improve our autos so that we can score more game pieces during the first 15 second period
Concept
To improve any of these aspects, research was done into existing solutions that have been developed by other teams. Research was done primarily through public forums such as ChiefDelphi or the FRC Discord. A great example of this is improving our vision, with messages from other mentors and teams guiding our process.
Here are some Discord messages that led our investigations:
Yaw is an important consideration when using WPILib's pose estimator, as the estimate may spiral away with inaccuracies.
A higher decimate value results in faster vision processing with minimal accuracy impact
Additionally, our auto align strategies were heavily influenced by various tech binders posted on ChiefDelphi. Here are some the primary threads that led our investigations:
This was our first implementation of Auto Align, and matches our in-season strategy. However, we identified a few flaws such as lack of initial velocity compensation.
This is what primarily led our off-season auto-align strategy.
Team 2056 has a very unique PID approach where they only use a proportional controller to align.
Implementation
To do this, we used our new tech stack, WPILib Java Command Based, and created commands for each of the strategies we wanted to test. One of these was using a library called Autopilot, and the other was a pure PID approach.
This was our initial in-season approach. It used PathPlanner's pathing library, which generated a optimal path considering the robot dimensions and measurements inputted. However, it was inconsistent and provided bad results during the season.
This is our pure PID approach. The way it works is by taking the error in pose, in the x, y and theta (rotation) direction. Then, it uses 3 separate PID controllers on each component in order to oriente the robot to the pose. This was very reliable, but the most inconsistant part of it was its ending condition.
Within the .until clause, there is some validation of what is considered an "ending" pose. We had to constantly adjust the error to ensure that the robot does not stop prematurely and also does not take too long to align.
This was particularly prominent in one of our autos at Madtown Throwdown, where the end conditions were too strict and the robot did not function properly during auto.
Final Product
Here's our final project, the robot auto-aligning at our matches at Capital City classic. This was extremely successful, with us scoring the most that we ever have throughout the season.
Google Sites
Report abuse