Team 4099, based in Poolesville Maryland, is proud to open our #openalliance 2023 build blog!
Our team is excited for the 2023 season after an incredible performance last season! Some info about us: we have over 40 active members, six mentors (mostly online for now), and operate from the Poolesville Baptist Church! Special thanks to NASA, MITRE, MSBR, Gene Haas Foundation, Lotmaxx, and Octo Corps for making this season possible!
Over the past few months, we’ve held workshops for our new members per this schedule, but near the end of the offseason, we decided to adopt a longer, less frequent meeting schedule consisting of meeting on Tuesdays and Fridays from 3:30 to 7. Going into build season, we plan on meeting from 3:30 to 7 PM on weekdays and Saturdays from 12:00 to 6 PM (with Sundays being a break day).
Older resources can be found on the 2022 build blog
For the 2023 season and onwards, Team 4099 will avoid buying products from VEX product in places we can. We’ve been invested in the ecosystem for a while now, so it will take us some time to phase the VEX ecosystem out entirely, but in the meantime, we’ve been buying new parts from other places and reusing old VEX motors/parts where we can. Here’s an excellent resource compiled on the FRC discord that has helped us find alternative parts in our effort to boycott Vex.
Now onto what we’ve been doing in our offseason.
Every year, our leadership and veteran members create comprehensive presentations and engaging projects for the students we onboard at the beginning of the school year. As our workshops close, here’s a link to all of our 2022-2023 season workshops across all of our subteams. Previous years’ workshops and recordings can be found on our 2022 build blog.
Over the summer, we developed a QR-code-based attendance system called FalconTrack. Due to our team’s build space situation, we decided to make a custom-attendance solution. Although we have one consolidated build space, we often relocate to buildings in our local high school, some of our members’ garages, etc. This led us to create a QR-code-based attendance tracking system: members scanned QR-codes that were made specific to locations. All of that data would be stored in the cloud and could be accessed by other team members in case they needed something from a particular location. We made a lot of iterations but ultimately shut it down because it was hosted on Heroku, and we couldn’t justify the cost of what we got out of it.
Regardless, it was a great learning experience for our programmers and helped spark conversations about standardizing web designs for all of our web applications. It was also a good medium for experimentation for more critical apps we developed later on in the season. Although it’s no longer up, here are some pictures of what FalconTrack looked like.
Here’s our own login page that was connected to our team’s slack! It allowed us to do 2FA to make sure students weren’t signing in for each other.
Here’s the home page of FalconTrack. I’m running this locally but the idea is different meeting locations would show up with the corresponding checked in members displaying below the locations.
We also made a few things for leadership. A place to generate QRcodes which could be displayed on slides or displayed physically.
Upon scanning a QRcode, students could check themselves in or out using a button.
And an admin dashboard that allowed admins to add students, add locations, and even manage checkins.
For the third year in a row, our team participated in the F4 CADathon to act as a culmination of the skills we learned during workshops in the offseason and to prepare both new and old design members for the actual season. From the last two times we have done this, we realized that actually diving in and designing a full robot is one of the most valuable ways to practice, and this year was no exception!
We were able to simulate a kickoff where both new strategy and design members could get a sense of what the actual kickoff will be like in January by calculating the most optimal and valuable actions in the game, as well as evaluating different mechanisms that fit our needs. We modified our old time based analysis template to simplify the process and give us a lot more information such as Points Scoring Efficiency (a measure of how many points a task would give us per second), all with the power of spreadsheets! One problem we found was that there was not a defined set of constants, leading to groups having different constants for actions but we’ve improved this for kickoff.
Overall, the CADathon was a great learning experience and members were able to design and integrate different subsystems together. Even though we did not have enough time to fully flesh out the intake, we were able to design a really cool robot in a week and are ready to take what we learned to the actual season! Here are our Onshape CAD submission with renders and our kickoff time based analysis + mechanism analysis.
In the past few months since we started our initiative to get further support from our county (Montgomery County, MD), we have seen tremendous progress. We are collaborating with most of the FRC teams here (449, 1389, 5115) and some of the local FTC and VEX teams. Before the school year started, we submitted a white paper going in-depth about the benefits of robotics and including different support areas needed to increase the number of teams (stipends, space, etc.). When the school year started, we established a firm connection with the county officials in charge of extracurriculars and STEM education by hosting bimonthly meetings with them. In these meetings, we have received verbal confirmation of a centralized grant system for local teams (amount TBD), elimination of build space charges, potential for a centralized build location/practice field, and official stipends for our mentors. In the next few months, we plan to continue our collaboration with the county and set up an easily-accessible collaboration network to get help for anyone trying to make a robotics team in the county.
We loved 4414’s super pit at Worlds and decided to hop on the super pit train for competitions and our own build space. The setup still needs to be finished- more details to come in a separate post later- but it’s been beneficial in helping us be more organized and have a consolidated workplace.
For the past few years, we’ve been using our own units library that allows for inline unit conversions. This means we store all of our measurements as custom base unit classes such as
Time and allow for simple, inline conversions between different measurements systems (meters to inches, seconds to minutes, meters per second to inches per second, etc.). This has saved us from debugging countless issues, eliminating the need to store unit types in variable names, and has abstracted the process of dealing with sensor units. This means we sometimes have to maintain our own versions of WPILIB classes: namely the 3D geometry classes and unit tests we wrote in accordance with our own units library.
We’ve also worked on replacing our legacy swerve math with faster WPILIB implementations. In this process, we’ve also implemented swerve simulation–something we hope to be incredibly useful down the line when testing autos, vision simulation to test pose estimators with AprilTags, etc. More to follow on that topic in later posts.
Prototyping is a lot more useful when you can do it with real motors, which is why we stripped parts off of our old mule chassis this offseason and made an electronic testing board. It includes a roboRIO 1.0, RSL, VRM, radio, main breaker, and a PDP. We hope it helps with making quick prototypes and testing them using REV Hardware Client/Phoenix Tuner or even uploading some code, configuring CAN IDs, and testing more complicated mechanisms.
This offseason, we began mentoring a startup VEX Team from Clarksburg, Maryland, providing them with technical advice, financial sponsorship, and robot parts so they can compete in their upcoming season. Our team members continue to meet with them every week and handle competition logistics, meeting dates, payments, etc. Current plans include teaching the team CAD, switching to Python programming, and improving their engineering process.
- Neo Motors. Beyond our drive base, we are opting for a complete NEO motor ecosystem. We eventually hope to switch to using NEOs for our drive base next season, but for now, we’ll stick to running them for all of our other significant mechanisms until we can get a little more off-season practice with NEOs on swerves.
- Spray Painting Max Tubes. We’ve spent a lot of time milling Versaframe Tubes, but we’ve planned to switch over to Max Tubes, so we aren’t spending more time than necessary. We’re also abandoning powdercoating as it takes too much time out of our iteration process. Instead, we’re using our newly bought spraybike to paint our stock. Since we don’t need to mill hole patterns, we hope that this process results in the same all-black look while making our iteration process more effective.
- Protopiping. In previous seasons, our team’s prototypes weren’t effective in collecting the data we wanted, testing rigidity, and helping our iteration process. This year, we’ve decided to utilize Team 5254’s HYPEBlocks and similar systems, as well as continue to use Team 3847’s PVC prototyping system. With the testing we’ve done so far, our prototypes have been much more robust, and we were able to modify/iterate them. Here’s a video of showing some of the protopiping progress we’ve made.
- Offline scouting apps. Our 2022 in-season scouting app relied on an AWS EC2 instance, a successful database connection, and TBA event being up. There wasn’t a single competition where all of these things worked at once, ultimately leading us to switch to a backup Google-Form-based system. We did some experimentation in the offseason with Chief2, which was a combination of PWA-based web form and Python-based admin panel. Offseason testing found that it ended up being incredibly robust at IRI and BoB. The most important lesson we learned from Chief2 was that QRcodes are the way to go. They make it really easy to transfer data to a computer that we are sure we can ensure a tethered connection on. Additionally, they can be generated without the need of a cellular or wifi connection which makes it accessible to any student with a device. Thus, for 2023, we want to continue a pipeline that generates QRcodes, which store all of our scouting data and scan it using a laptop designated to a scouting admin who then transfers it to a database from which visualizations can be generated. This led to the construction of our 2023 scouting app about which we’ll write a much more detailed post in the next few days.
- Switching to 2 AWG. After learning a lot about batteries this offseason and experimenting with 2 gauge this offseason, we’re sticking with our switch to using 2 awg in season. Everything we’ve learned about batteries has been documented on our previous build blog: you can find what we learned along with a comprehensive list of tools that we’ve used to switch to using 2 awg battery cables.
Feel free to ask any questions about anything and hope everyone has a great season (no cap)!