Welcome to Team 340’s 2024 Open Alliance build thread!
Team 340 is thrilled to be part of a first-ever experience for our team: The Open Alliance!
In this thread, we’ll be sharing the intricacies of our build season, covering everything from beginning to end! We will be posting weekly updates on Saturday evenings.
This season we will be competing at,
The Greater Pittsburgh Regional and The Finger Lakes Regional!
If anyone has questions, please don’t hesitate to ask! #TeamRev
Great to see you guys enter Open Alliance, excited to see whats coming up!
This offseason started off quicker then we are normally used to. To recap the season we competed at the Finger Lakes Regional (FLR) and the Tech Valley Regional (TVR).
At FLR we ranked 18th with a record of 8-7-1 and were picked by the 7th seed and were partnered with 1507 and 250. We worked our way through the lower bracket to become finalists.
At TVR we ranked 7th with a record of 9-4-0 and captained the 5th seed where we fell short of qualifying for championship.
Since we found an abundance of offseason time this year we opted to implement some improvements in some areas across our team. These areas include, our scouting app, programming (See next reply) and the design and fabrication of an offseason robot.
Scout 340 is our tablet-based match data collection system with *near* real-time web server-based analytics to assist in alliance selection planning. The system consists of our in-house custom-built mobile app running on inexpensive tablets and custom analytics software running on our team’s web server.
The system was developed to replace paper-based scouting for faster, easier, more accurate match data collection. This is accomplished through “gamifying” data collection via an intuitive, and fun user interface, resulting in better data and more engaged team members (see picture below). This past season our team members successfully collected more accurate data, affording us the opportunity to start seeing team performance trends earlier in competition.
Moving into the 2024 season, we’re already busy working on upgrades and additions to the base system, including improved data collection and transfer, better hardware power management, and expand analytics data visualization.
A special shout-out goes to Team 1678 Citrus Circuits for the inspiration!
After the season concluded we came back as a team and decided that it would be a good opportunity to take the new students on the team and teach them how to prototype, design, build, wire and program a robot from start to finish. Our goal was to keep it simple, build it fast and fail even faster. This goal led us into the direction of building a cube only bot.
We spent some time looking at the best of the best cube bots, 1923 The MidKnight Inventors and 1493 The Falcons. We decided what we wanted to go towards and off we went.
The next couple of weeks were spent prototyping intakes using our new laser cutter and learning what worked and what didn’t. We also decided we wanted our drive train to be fast! The quicker we could traverse the field the better. We went with Swerve X tube mount modules because we have used them previously. One thing we found is that we hated that we had to press pinions onto the Neos. For this problem we decided to change the pinon to the rotation of the azimuths to a 10 tooth pinon from a 9 tooth, this made assembly much easier (See picture below). Our decision to go fast was made knowing the flexibility of the gear ratios that the Swerve X module could handle. We ended up gearing our modules to go 18ft/s.
On top of the new speed we also decided that we didn’t like treaded wheels. They take to long to meticulously tread the wheels consistently. To solve this issue we did some research and found that BuySwerveWheels.com was testing out hubs for Swerve X to be able to use Colson Wheels (See picture below).
We found these wheels worked extremely well and will hopefully keep using them in the seasons to come!
Time went on and before we knew it the robot took shape and we ended with this!
This robot went on to compete at Ra Cha Cha Ruckus! It didn’t perform the way we had hoped but it was definitely a learning experience and got a lot of our rookies exposed to a mini season and what can be expect for our upcoming season (especially since we are a week 1 regional).
Some other side projects we have started are upgrades to our robot cart, battery cart and pit cart, more updates to come in the next couple months.
We look forward to posting about our 2024 regular season! #TeamREV
Before the 2024 kickoff, our goal is to create a general purpose library to minimize the time spent in build season rewriting and iterating on effectively season-independent code. Additionally, we are experimenting with and migrating to using inline commands, and have performed feasibility tests to get familiar with the new paradigm.
Dubbed “GRRBase”, we have created a template repository (available on our GitHub here) that contains boilerplate and utilities to easily spin up a robot. Here’s a few of its many features:
An easy to use swerve library, configured via builders, that includes features such as closed loop per-module heading and velocity control, additional steps to enforce kinematic constraints to reduce scrub, and simulation support. Simply define a config in Constants.java and extend the SwerveBase subsystem to expose desired methods and variables.
During the 2023 season, we created a dashboard to select the scoring location of game pieces. Seeing the success of our (arguably rudimentary) solution, a new general purpose dashboard was written from the ground up using Svelte. It can be easily modified to provide season specific functionality, with its base features including a GUI for selecting autonomous modes, and utilities for interacting with and analyzing functions of the robot. It utilizes a custom Network Tables implementation written with bindings for Svelte, and is served via Tauri.
Using Network Tables for debugging is incredibly useful and powerful, however it can be tedious to report all of the necessary information. To solve this issue, we expanded the functionality of Subsystems to provide factories for instantiating hardware that automatically pushes their state to Network Tables with very little boilerplate cost. Additionally, hardware is automatically polled for faults, and its power usage is also tracked.
There’s still plenty of other projects ahead of us, on top of refining our current work. Currently, we are investigating the irregular profile of the joysticks on our controllers, exploring alternative methods for improving the accuracy and ease of control for swerve drive, developing a more robust vision system, and more! Our progress is public on our GitHub (linked above), and we will continue to post updates as our projects reach completion. We hope our work is helpful to others, let us know if you have any questions!
Do you have this NT implementation code somewhere? I just wrote a similar one using AdvantageScope’s implementation, having previously used ntcore-ts-client.
Source is here, I think it was derived from gerth2’s JavaScript client which upon inspection somewhat resembles the implementation in AdvantageScope. I’m not super happy with our implementation, it currently subscribes to all topics by default and its internals are quite messy, it was more or less just a temporary solution that was hastily written to get the dashboard functional enough to work on the more UX side of things. A rewrite is currently in the works that also follows the slightly modified NT 4.1 spec.
Here’s the one I made based on 2024 beta AScope, so it (I think) follows 4.1. I’ve also been trying to create a generic Svelte+Tauri dashboard template, with some components built based on FRC Web Components and independently. This NT setup subscribes only to the topics that have stores created for them, but doesn’t handle unsubscribing if the store goes out of scope before the entire page is unloaded.
In our current implementation, a subscribed topic has a single NTTopic instance, which contains an array that is populated with callbacks for each Svelte store. These callbacks are invoked when a new value is received by the client (very similar to EventEmitters in Node.js). The idea is that multiple stores could access the same topic without making redundant NT subscriptions, and can be easily removed from the callback list when they are unsubscribed from to prevent memory leaks. When the implementation is rewritten, the main change here will be making the NT client actually subscribe/unsubscribe when the callback array is populated/empty, instead of relying on every topic being subscribed to by default.
Additionally, I needed support for retaining past values of a topic, so a timestamped history of values is also saved. This also needs to be rewritten as currently a topic’s history has no TTL and will be stored indefinitely.
Outside of topics, there’s also a bunch of extra stores for the connection status, a list of all topics, and a few more things.
I’ve considered making this an npm dependency once it’s in a more complete state, however I also want to ensure its reliability first, which would involve running it for extended periods of time during practice and testing its reliability at an actual competition.
You can likely cut down on some of the boilerplate within your SwerveModuleConfig with Lombok. We have something similar, but it admittedly holds much less info and has less behavior than yours.
// https://github.com/FRC2713/Robot2023/blob/9c3afcb173141d6d85c83b49ddad71a4b11eded1/src/main/java/frc/robot/subsystems/swerveIO/module/ModuleInfo.java
@Builder
public class ModuleInfo {
@Getter private SwerveModuleName name;
@Getter private PIDFFGains driveGains;
@Getter private PIDFFGains azimuthGains;
@Getter private int driveCANId;
@Getter private int aziCANId;
@Getter private int aziEncoderCANId;
@Getter private double offset;
@Getter private Translation2d location;
}
// https://github.com/FRC2713/Robot2023/blob/9c3afcb173141d6d85c83b49ddad71a4b11eded1/src/main/java/frc/robot/Constants.java#L278-L288
public static final ModuleInfo FRONT_LEFT =
ModuleInfo.builder()
.name(SwerveModuleName.FRONT_LEFT)
.driveGains(Constants.DriveConstants.Gains.K_DEFAULT_DRIVING_GAINS)
.azimuthGains(Constants.DriveConstants.Gains.K_DEFAULT_AZIMUTH_GAINS)
.driveCANId(1)
.aziCANId(2)
.aziEncoderCANId(0)
.offset(0.312)
.location(FRONT_LEFT_LOCATION)
.build();
Lombok also might scare the freshmen, so, maybe not.
Thanks for posting the Svelte NT4 bindings! I’ve always kept an eye on 340s build season through the public code repo, figured it was only a matter of time before you guys joined OA. Looking forward to seeing what comes for 2024!
Kickoff 2024
The minds of the students were turning as we sat and watched the kickoff stream!
After the stream was over we started right away. One of our main priorities is to read over the rules as a team so everyone understands what the game is about. We break down how to score points, what fouls are important to know.
Once everyone understands the rules we come up with basic things that can happen during each segment of the match(Auto, Tele and endgame).
This sheet is then printed out and the students are split into groups to go through and rank what they feel is most important to be able to do in each part of the match.
We then come back together and the kids present what their groups have come up with and we average out everyone’s findings and come up with a common game strategy from there.
By the time this is all done we were close to the end of our meeting for the day! The rest of the time was spent just sketching out basic mechanism ideas and also completing the CAD of our drive base!
This year we decided to make a switch to the MK4i modules. Many factors came down to our decision but the main one was availability. We decided that the size of the drive base will be 28 x 28, giving us some room on the chain along with the room for our mechanisms
The Day After Kickoff
Usually the day after is a resting day for 340, spending some time reading over the rules looking at what Ri3d teams are coming up with and more. Except we partner with two other teams in our area (3015 and 6868) to rent out a warehouse to house a full size field for the season!
We spent most of our day cutting and screwing together game elements so that we have the ability to practice on a full field!
More updates to come later in the week!
#teamREV
Cant wait to see you guys in Pittsburgh!
We are excited to make our way back to Pittsburgh after a 8 year hiatus! Excited to see teams we haven’t seen in a while!
Our motto for the first week of build season is “Fail Fast and Fail hard”. Our main focus this week was to get prototypes to a point that we felt were ready for the next stage of the process, which was CAD and integration.
We had two different prototypes that we were trying out. The first was a dustpan and roller mechanism that would rotate off the front edge of the robot. We found this to be successful at picking up notes! The groups next focus was to integrate it into the shooter prototype (See The shooter section).
The second prototype was more of an instant conveyor to the shooter type intake. At first they worked on acquiring the game piece making sure they follow the touch it and own it mentality. This developed into more of a conveyor type system with potential integration into our shooter prototype!
You can see test videos at the link here!
This week we started with two different prototypes. The first was a side wheel shooter, this shooter had two 4" fairlane wheels with a compression of 5". We found even though it shot the notes well we didn’t see the speed and distance we would have liked. We also were worried that as competition went on that the notes would see some differences in diameter causing the shots to be different.
This led us to prototype a different type of shooter we saw from Team 95 The Grasshoppers! See here! After some quick fabrication we found that this was the better option! It showed that it had the speed and distance that we were looking for and it took care of the concern of odd shaped notes. We are using a 4" wheel on one end and a 3" wheel on the other, keeping 1.5" of compression throughout the shooter.
Shooter test videos can be found here!
After we had our prototypes finalized Saturday after lunch it was time to integrate the two together. One intake group was able to add their intake to the shooter prototype we had made while the other did a bunch of 2D CAD to try to find the best way to fit everything within the robot frame and to stay with in the 12" extending rule.
On top of working on prototypes we set our ways on a drive base. Like mentioned earlier in this thread we have made the switch to the MK4i modules on a 28" x 28" size frame. This week we added our support frame members and belly pans.
Something we try to implement every year is to make certain parts of the robot modular. This helps if a major mechanism fails, we would have the ability to unscrew it from the frame and replace it with a spare. To make sure this is feasible we added these cross members to mount to. We think that these will be a great mounting point for our shooter and climbing mechanisms.
One of our mentors purchased a Bambu Lab X1C 3D printer. We were finally able to test out its ability by 3D printing custom swerve covers! We really like the way this printer preforms and can’t wait to keep using it this season.
You can see a cool time lapse of one of our module covers printing here!
This next week is a major CAD week for us. We will be getting prototypes into CAD and finalizing locations on the bot for those mechanisms and electronics. We compete at a week 1 competition so lots of work to do in a little bit of time!
#TeamREV
Awesome build thread!!
Do you guys have any insights into the Colson wheels vs Alu treaded wheels on the swerve?
The Bambu timelapse is really cool! It that the .4 nozzle you are running?
So we decided to switch to the colsons on our Swerve X modules during the offseason to give us time to test them out. One of our main gripes with treaded wheels was actually treading them. We could never get the tread to be the perfect size or have the holes in the correct spots giving us some inconsistencies in our tread leading to inconsistencies auto and driving in general.
With the colsons we were worried about two things, wear and slippage. After hours of drive practice and an off-seasons competition worth of driving we saw max .100" of wear. This was a little concerning, but we figured that with how fast and how light we made our robot we saw more wear then we normally would due to slipping while accelerating.
The slipping aspect can also come down to the weight and speed of the robot we built. Something we wanted to push during the offseason was the speed at which we moved. Lets just say we moved a little to fast. This season we dialed back the speed and expect to be around 110 lbs.
We also feel that with tread the COF and surface speed changes as it wears more, while the only thing that changes with the colson is the surface speed.
As for the bambu we are using the .4 nozzle.
Are there any concerns with odometry when the colsons wear? Will there be issues with autos now not completing or are you counteracting it with an IMU/tracking other than wheel rotations?
Could part of the slipping be too quick of acceleration from 0 and breaking traction?
Most importantly what are the must-haves for a good garbage plate?
While we did have concerns over wear affecting odometry, even after numerous hours of driver practice and an offseason competition we didn’t observe any noticeable degradation of our performance in autonomous even though we weren’t tweaking our paths as the wheels wore. This is despite our autonomous paths being quite aggressive. Additionally, any wear we experience this season that could affect the accuracy of our odometry should be mitigated as we are using vision to help update our pose as our odometry drifts. As for your second question, we definitely observed some minor slippage, however that is more related to our offseason robot only weighing ~65lbs without bumpers or a battery. We did apply a ratelimiter in teleop that would ramp our commanded module speeds with respect to the physical limitations of the robot, which certainly helped mitigate (but not eliminate) slippage, however we didn’t use a very aggressive profile as we wanted to maintain responsiveness.
Week 2 consisted of a lot of CAD and prototype iteration. The main focus was to find the direction that we wanted to go in.
At the beginning of the week we thought we found our direction which was a long lever arm for our intake that would feed into the shooter. Concerns were brought up with control of the arm, geometry for the intake to be able to work grabbing notes off the ground and scoring in the amp/trap when needed. We did 2D CAD to figure out our geometry concerns and nothing was working.
This lead to a switch in our intake design. We started to look into an uneven four bar. The idea for this was to just be a fast and simple handoff between the intake and shooter and our amp/trap mechanism would be separate from our intake. Doing the 2D CAD led to us finding out that we would not be able to have the geometry we needed while staying under the 2 foot height mark we set for ourselves last week.
This brought us back to the long lever arm type intake. Low and behold last week the 2D CAD was done to find the correct pivot location so that we had the sweet spot to intake off the ground and then score on the amp/trap when needed. This 2D CAD was lost in an infamous autodesk inventor crash and we didn’t know this had happened. The 2D CAD was redone and we found out that the long lever arm will work.
After the 2D CAD we moved into making it in 3D to get ready for manufacturing. While the 3D CAD (see photos here) was in progress the prototype team was working on adding the intake prototype to arms and getting them moving and intaking on an old frame. This was accomplished by the end of the night and we were so excited to get it working and moving that we had a little hiccup! Overall it worked well but a future note to ourselves don’t attach mechanisms with only drywall screws into small pieces of 2x4 Whoops!
So last week we had two different shooter prototypes we were looking into using. The first was the side wheel shooter and the angled axle shooter. We went with the angled axle design but as we prototyped it we found manufacturing it would have been more of a hassle then we wanted to deal with. We really wanted to keep our axles straight and we were trying to find a way to do this and happened to come upon 3255’s build blog here! We really liked the controllability of each side of the shooter which would give us the spin we wanted to see like the angle axle shooter gave us.
We started to prototype this shooter and found that our prototype was generating a lot of friction while running and we also didn’t like how much was going into running 4 sets of wheels per side. We ended up cutting it down to wheels per side shortening the shooter a bunch. You can see a couple CAD screen shots here we are in the midst of rebuilding the prototype and will post pictures and videos in next weeks recap.
The climber is starting to gain some traction. We have looked into modifying climber in the box to what we need. The only thing we need to work on is how we will stay up on the chain once climbed.
A small update on the drive base. We received our new 8mm Vortex shafts from REV and were able to get our motors mounted to our modules. The electrical team will be able to start to wire the drive base this week!
Something we like doing is 3D printing a miniature version of our robot to get a feel of what our robot looks like. Enjoy the following pictures with a sharpie cap as reference.
As of right now we are on track to hand off the robot to the programmers by week 4-5. We feel we have found the direction we want to move in and are ready to go!
#TeamRev #GoBills
Has this led to discussing more backups or moving to Onshape to help mitigate files getting lost/corrupted?
Did the wood snap from too much force on it or were there possibly other issues? Did the prototype answer some of the questions or issues with the design?
What wheels are you looking at using for the shooter?
Have you thought about using a disc brake or a ratchet-type system for the climber?
Does pineapple belong on pizza? (we all know @waialua359’s answer)
#TeamOnshape
