Offseason Competition: RiverRage
RiverRage 27 was our only offseason competition this year due to shifts around the leadership of the team, but we made the most of it. We are using it as an opportunity for new student drivers and media members. Overall, we had a blast!
Results
- 8th in qualifications out of 29 teams
- Competed in the playoffs as the 7th seed alliance with 2876 (DevilBotz) and 138 (Entropy).
- 9th in teleop Amp notes
- 14th in teleop Speaker notes
- 1.2 notes dropped per match
- 45 second cycles on average
Data taken from public viperscout data EVENT Stats
Technical Changes
New student Drivers
With the graduation of our seniors and the arrival of new freshmen, we have been training students to drive our bots. In this competition, we decided to rotate between two new drivers to ensure sustainability.
New Vision System
Our inseason vision system was consistently not working, resulting in us not being able to properly use our auto aim functionality for real matches, as it would most likely result in a missed shot.
The above image demonstrates the “steady state error.” Green robot is the final robot pose, and the blue is the vision calculated pose. Each of the axes are the locations that the cameras on the bot are at, and the blue cone is the exact pose returned from the camera. During an entire match, the blue calculated cone and the axis never coincided with each other, meaning that the gains on our vision were not adequate. Due to an inseason issue called low number of people being stretched thin, this error was not resolved.
A rewrite in python was done based on this post by 6328. The resulting code can be found here. Being able to prioritize vision estimates for shooting instead of manual shooting dramatically increased our effectiveness on the field, especially for new drivers who are not as used to the distances programmed into the fixed shots.
Falcon Signal System
An ongoing issue with our robot code discovered pre-WPI district event was our incredibly long update times.
Pre-testing update rate debug, note that SmartDashboard.UpdateValues is taking longer than the standard 0.02 seconds.
An unacceptable 6-7hz updating resulted in really, really, really, unresponsive control from driving. A further analysis showed that this effect was because of the quantity of logging we did, all the way down to the motor. The solution was to remove all noncritical logging, which reduced our ability to debug each motor to the core.
Recent debugging was done to determine and fix the true source of this error.
Entire call time for each function, done with python 3.12 cProfile module, in simulation
A glaringly large percentage of this timing was coming from our falcon wrapper classes set function, and more so in the refreshes for each signal. A view at which functions are called, specifically updateDashboard, reveals the following:
A couple notable changes can be done to this, which were implemented at this competition:
- Instead of SmartDashboard.putXYZ and using format strings, having proper Nettables Tabling to reduce the amount of potential time spent doing string related parsing
- Instead of the implicit
.refresh() call done every time a self.motor.get_xyz() is called, cache the signal and then use BaseSignalStatus.refresh_all() to asynchronously update all the signals on a canbus without having to wait for each of them
Both of these changes were implemented for this offseason. You can see the exact commit changes here. Initial testing in lab showed promising results
During RiverRage, drivers reported swerve being finicky, with the steering motors acting chaotically at times. This was eventually reverted in order to prioritize functional drive as opposed to faster update rates, since a non-driving robot contributes no points to a match.
Qualifications
We had many issues throughout qualification matches, such as poor controller connectivity and poor attachment of our bumpers. This was due to some new code that was yet to be stress tested (as shown above with technical updates), which we thankfully resolved by fixing the code. Regarding the bumper issues, we strengthened the connections between the bumpers and the bot by screwing in the nut tighter into the bumper screws, something we will keep in mind for future competitions. As qualifications progressed, our drivers got better at cycling: in match 3, our drivers only scored 3 teleop points, while in match 21 they scored 17 teleop points. This major improvement allowed us to win all but one game in qualifications, and we are proud of their progress.
Playoffs
After team 2876 DevilBotz graciously selected us, we became part of the 7th alliance along with team 138 Entropy. We were able to pull off a victory in the first round of the upper bracket in the playoffs, but a contested foul resulted in the replaying of the game, where one of our alliance teammates died, losing us the match. Unfortunately, we continued to lose in the lower brackets the game after. Something that impacted us throughout those games was our auto aim, which stopped working when the playoffs started. This was due to our cameras not being calibrated, causing our auto-aim system to malfunction slightly (thankfully, they started working again during our last playoff game). Another major issue was us not effectively utilizing the standard match strategy, where we would shoot speakers without amplification or fully go for amp or speaker without switching between the two strategically.
Scouting
This year at RiverRage, our team designed a new scouting system based on viper scout with updated UI, as shown below. The new system utilized a better UI, making students more eager to scout and leading to more efficient and consistent scouting. The format is much more intuitive, with big buttons as opposed to check boxes on Google forms like our previous scouting programs.
The UI of our current scouting program
The UI of our previous scouting program using Google forms
It is similar to the format of viperscout, and it is a restylized version of google forms, meaning it is linked to a google sheet, making it easier to keep track of and analyze the data for us. We also used Svelte, which allows us to easily take our declarative components and convert them into efficient JavaScript that surgically updates the DOM. However, because we don’t have a .env environment file, anyone can read the source code and see the form and then modify it, since it’s not a git-ignore element. This is something we can work on in the future.
The team also devised an assignment spreadsheet which allotted everyone a specific bot on the field to spot, (ie Red 1, Red 2, etc). Scouters were placed in groups and two groups were made and rotated scouting every 3 matches.
Missing data from the scouting assignment
Even after all these preparations, we still had minor inconsistencies due to human error. Some scouters would forget their matches, or had to leave without telling other scouters to fill in, resulting in missing data. Overall, it was good practice for our new scouts, and we are confident going forward, especially in regular season events, they will feel better prepared.
A lot of our scouting data ended up unreliable due to a lack of data for the teams
Media
This year, we were able to get very decent media coverage! There were specific people focusing on videoing the robot while others were dedicated to photograph the drive team and the robot. Check out the video we made! RiverRage Recap Video
The team is also considering switching to shooting in RAW, which is a file type where we can edit the photos to yield greater effects, creating some advantages for pushing colors due to the color depth and dynamic range that’s captured by a camera. However, there are also some downsides, as RAW files are much bigger than the standard JPG that we used to use, and the media team has not yet been fully trained on image editing.
This is the same image shot in raw and in jpeg. The raw image can be pushed on exposure in post due to higher image depth compared to the jpeg while still retaining colors and image quality. This is an obtuse example, but being able to fix images in post allows for a lot more flexibility after the fact for editing an image to the exact desired aesthetic.
Furthermore, some images taken at RiverRage had a noticeable blur, so going forward we will ensure new media students fully understand camera settings like shutter speed, aperture, and ISO to improve footage quality.
Example of a photo where the settings were not correctly set
Final Thoughts
Overall, we performed decently and were grateful for this opportunity to practice. Next time, we will focus on getting in more driving, media, scouting practice for our team members. More time will definitely be spent on the adjustment of our new vision system, as less than ideal testing was completed with this new system. Thanks again to teams 2876 and 138–it was awesome to be alliance partners with both of you!
Best wishes,
Team 1757
Post written by Yuhan, Duanmu, and Julian. Edited by Claire, Anya, Landon, and Luke.
