FRC 1699 Robocats | 2024 Build Thread | Open Alliance


Greetings Chief Delphi! Welcome to Team 1699’s inaugural OA thread!

Background

Team 1699, the Robocats was founded in 2005 in Colchester, CT, under Bacon Academy. Last year was our most successful season yet, and we won the NE District Championship alongside 1757 and 176, taking home our first two blue banners since 2014. This year, we hope to continue to establish ourselves as consistently competitive while offering the best experience possible to each of our students. We attended the Bash at the Beach offseason event and are registered for the Hartford and Western New England district events. Hopefully, we will attend the NEDCMP again too!

By joining the OA, we hope to form mutually beneficial relationships with teams on Chief Delphi and encourage quality CAD/code standards internally. This blog will be maintained by students, with mentor supervision. We plan to post at least weekly, hopefully more.

What’s new?

This year we have made several major changes to our team which we hope will lead us to success; new team organization, Onshape, and swerve!

Team Structure

After years of debate, we have changed our team’s structure. Previously our team has been led by two captains, and then divided by robot component, like drivetrain. This year, below the two captains, our teams will be divided into discipline; design, manufacturing, strategy, programming, and scouting. We hope that this will allow students to focus on their passions, and learn to collaborate with other students, who have different passions.

Onshape

1699 has traditionally used Solidworks for CAD. This year we will be using Onshape to take advantage of its collaboration capabilities, making it easy to share and collaborate on designs. We have spent a good portion of the preseason training students on the new software, and encourage every team member, design team or not, to learn Onshape so that they can effectively communicate their ideas.

Swerve!

In the past two years 1699 has observed that swerve, while not necessary, has been incredibly advantageous. Therefore, we purchased 4 MK4i modules with NEOs and ThriftyBot encoders and got to work in September! A more elaborate post about our swerve journey will be posted at a later date, but to put it simply, after much struggle, it works! Shout out to 176 for helping us attempt to implement their swerve structure, as well as YAGSL devs @nstrike and @Technologyman00 for their excellent library and support.

What’s next?

We have high hopes for this season, but for now we are taking a break to recharge after an incredibly productive preseason. Stay tuned for a couple preseason posts, and then we’ll see you at kickoff!

Github

Instagram

Team Website

YouTube

10 Likes

Looking forward to following your posts this season. It’s been great seeing the quality of 1699 robots improve over the past few years.

Best of luck and we’ll see you on the field!

5 Likes

1757 had a great time with you guys last year at District Champs, really looking forward to what you guys can do this year

4 Likes

Offseason Post 1: Swerve

The team decided at the end of last year to pursue swerve, and our lead mentors secretly purchased MAXSwerve and MK4i modules over the summer. At our first leadership meeting, we decided to go with the MK4i modules.

Decisions

MK4i vs MAXSwerve

Both the SDS and Rev modules are very well designed and proven to work, so we had a careful decision to make, and decided to weigh the pros and cons to make a data-driven decision.

MK4i

  • 4.0” diameter by 1.5” width wheels
  • Nearly twice-as-strong aluminum alloy
  • Flipped motors

MAXSwerve

  • 3.0” diameter by 1.0” width wheels
  • Smaller module
  • NEO 550 and NEO instead of 2 NEOs
  • Comes with through bore encoder
  • Lower price

This is a simplified list, but contains some of our biggest takeaways. In the end, we decided that we were willing to purchase the slightly more expensive MK4i modules, as we valued their advantages more than the MAXSwerve advantages. We also had two more decisions to make, motors and encoders.

NEOs

We chose NEOs due to their lower price point and higher availability, as well as due to our positive experiences with them in 2023.

TTB Encoder

We chose the Thrifty Absolute Magnetic Encoders for their low price and availability. We have experienced no issues with them once we figured out that they plug into analog channels, not PWM, and fortunately running them through PWM did not damage them. However, we did run into some issues in software.

Preseason Work

Construction

Our offseason drive base, Swervy, is 22 inches by 22 inches, with 2x1 aluminum on the border and a wooden bellypan. During the season, we will likely end up going with a metal bellypan, but it was more convenient to reuse some wood from last year’s temp field than to find some metal. We sourced and enhanced the design of some 3d printed snap-on guards for our modules, and we plan to route some plexi to go on top of the modules once we construct the in-season chassis.

Wiring

We experienced several CAN issues, and had a good time teaching our members how to use the Rev hardware client and a multimeter. This year we have switched to WAGO connectors after issues with our previous connectors - thanks to 1757 for giving us our first WAGO in the DCMP pit - and needing to swap them out.

Software

We knew software wasn’t easy for swerve, but we didn’t expect as many challenges as we faced. To put it briefly, we started by writing several versions of code which typically worked except for turning. We would never be able to rotate the bot, it would only strafe. After a while we met with a 176 programming mentor, who was very helpful with the rest of our code, but we still faced this issue. Still, thank you so much for your time! It was very informational and motivational. Then, we tried out YAGSL, which we still struggled with. Finally, after at least a month of struggling, we found the absoluteEncoderInverted property in YAGSL - thanks @nstrike - and it all clicked. With a little help from @Technologyman00 we got YAGSL working on my living room floor, and then in the shop. We plan to continue to enhance our YAGSL build, while hopefully re-writing our own swerve library with the encoders inverted. Seemingly, thrifty encoders are clockwise positive, and we need to make them counterclockwise positive to work with the WPILib libraries, although we haven’t proven this yet outside of YAGSL.


With the YAGSL library, we are pursuing trajectory following and enhanced joystick controls. This is slightly difficult because we don’t use command based, so we can’t use PathPlanner’s PPSwerveCommand or SwerveControllerCommand, but I am optimistic regardless, and have started work on a branch under our YAGSL repository.

Overall, swerve was a rough journey but we are glad that we struggled through it and very excited to use it in-season, unless FIRST decides to make it impractical - please don’t!

YAGSL Code: GitHub - FIRST-Team-1699/2023Swerve

5 Likes

Exciting to see 1699’s progress! I’m sort of happy you were able to experience these struggles with your swerve software as it shows how far you’ve come and how much you’ve learned. I’ve got a feeling it’s probably incredibly satisfying to see things coming together. And always nice to hear Kyle from 176 was helpful with swerve stuff. If you’re ever in a pinch, also feel free to reach out to me or our captains @dh28567 and @AidenK who are also both two of our software leads.

Best of luck, looking forward to more progress pics!

4 Likes

Thank you for the offer! We are very excited to finally get things together. Depending on how much we choose to pursue our own swerve, we may reach out!

If you need more let us know :D, happy to help

2 Likes

Kickoff Plans

This year, we have taken a lot of time to plan our kickoff weekend. This was written before kickoff but not edited until after, so please read it as such. The plan is as follows:.

We will start by meeting an hour before the game is revealed to socialize, boost team morale, share ideas and predictions, and prepare everyone for the weekend. Once the game is revealed, the team will just enjoy the video. On the second watch, we will take notes regarding general gameplay information. We will watch the video one more time and record more observations, and then break for lunch.

Lunch is time to decompress, process the new game, and have open conversations. This will let people grow creative ideas before critical analysis. After lunch we will watch the video again, and agree on gameplay rules. We aren’t going to focus on building rules until we start discussing how realistic it is to perform certain tasks. Our focus for day one is on strategy, not design. Once the team has a solid general understanding of the game we will split up individually.

In this initial stage of strategy, students attempt to devise the best strategy without considering limitations such as budget, resources, skill, etc while focusing on real limiting factors loosely, like the time it takes to drive from point A to point B. Individuals will form auto plans, and then merge with another person through deliberation, and then form groups of 4, 8, and so on until we have a full team discussion. We will attempt to form a loose general consensus for an auto strategy. We will repeat this for tele-op and endgame.

While groups are discussing, student and mentor moderators will be listening in on conversations with the intent to hear alternative perspectives from new students that don’t have the bias of experience. This is an attempt to help spark deeper conversation and bring to light more possibilities. This team of moderators will also break down the rules and if a student doesn’t know if a proposed idea is legal then the moderators will check the manual for them.

Once the team comes to consensus regarding what the best possible course of action is without certain limitations, we then break down these strategies to form a more team-centered strategy. This is not with the intent to limit the team’s potential, but an attempt to not take on too much. To counteract the potential of the team limiting itself, we strive to finish projects early and attempt to design and build with future iterations in mind.

When we break down each strategy the goal is to just have open conversations about what the team came up with. We will ask hard questions that really make the team consider how our strategy fits into the game. With this, there will be consideration for potential team limitation (as mentioned before), potential robot archetypes, and if the proposed strategy is over complicated or not ideal.

Once we pick apart auto, tele-op, and endgame strategies separately we plan on taking a break for human game simulations, xRC, and other fun activities. This will take about an hour, followed by dinner.

After dinner we will pick apart our team strategy as a whole. We will discuss what we have learned from our activities, and use a MoSCoW prioritization method (see slide 45) to figure out what exactly we want our robot to do. We will identify our priorities and things we want to avoid. We will also be deciding whether or not to use swerve this year.

Before sending students home, we will remind them to get plenty of rapid eye movement (REM) sleep (as prescribed by Mr. P) and play xRC Simulator if they have some free time to have fun and experiment with the game.

Simply put, Saturday is figuring out what we are doing. How we will actually make it happen is a topic for Sunday, when we begin to design the robot. The first day is just solidifying a concrete goal that will set the team on track for success.

Kickoff Recap

Saturday

Saturday went very well! We successfully put together a general strategy for the team, and even though we had to go home 2 hours early due to a Nor’easter snow storm, we still managed to accomplish our goals.

Saturday Strategy

*Disclaimer: This assumes no other robots on the field. We believe that defense and alliance cooperation will be keys to success, and our strategy team is hard at work developing various auto paths, teleop plans, etc. However, these initial strategies are how we determine our initial design requirements.

Auto

Score the preload in the speaker, score two of the ground pieces in the speaker, and score the other ground piece in the amp, before booking it to the field. We will have other auto routines, but this is our priority as we believe that it will maximize points and allow us to use the co-op button immediately after auto, signaling to the other alliance that we want them to use it.

Teleop

Score two in the amp, and one in the speaker while amplified, repeatedly. This will yield 7 points, instead of 6 from three speaker cycles. Assuming that they take the same amount of time, this is the most logical plan. We are hoping to design a robot that will fit under the stage so that we can minimize cycle time.

Endgame

Climb and score in the trap. We believe that the trap will be very important to securing ranking points and potentially winning matches. Unless we fail to design a capable mechanism, scoring in the trap is a must-have for us.

Sunday

On Sunday, we got 8.5 inches of snow and decided not to meet in person. Instead, we met from 10am - 5pm on Discord, which went very well. First, we identified our robot requirements.

Requirements

  • Must score in the speaker from against the subwoofer
  • Must score in the amp from against the wall
  • Must climb
  • Must score in the trap
  • Must intake from the ground

Then, we spent two hours discussing potential concerns with our strategies and identifying construction rules, before breaking out into three design teams. On Thursday, each of these teams will present their designs, and we will see how we can synthesize them into the best possible design that aligns with our goals.

Three Proposals:

Footnote: Apologies for the delay with posting, the build season has hit and we are feeling the pressure. We still plan on releasing updates once a week or more.

Robot!
1 Like

We definitely forgot to add that to our kick-off planning :see_no_evil:

3 Likes

Analysis looks great!
How many cycles are you expecting to do in teleop?

1 Like

REM sleep cycles? :wink:

2 Likes

I could give you a number but it’s really hard to speculate. A lot of it depends on robot traffic and defense, assuming we are alone on the field the goal is that it takes as long as it requires us to drive back and forth from amp/speaker to the source. We are planning a 4 piece auto in an ideal world, since we are new to swerve this is still in question and we are designing to make auto as simple as possible. I think other teams could do more than 4 pieces (1 of which being the preload) but I do think that’s realistic for the team. In teleop, we are hoping for 10ish (with a wide range of error up or down) cycles this is just guesstimating and based on 2013 number of cycles for certain levels of teams and the same for 2022. We have plans for being very hard to block for shooting if at all block-able, and we plan on getting under the stage so it really comes down to how well we maneuver around a different bot and how well the opposing alliances plays zone defense. But I think defense hopefully won’t slow us down. Against tank I have little concern outside of well played zone defense, swerve defense is a bit more scary but fortunately less common. We have really empathized inside the frame intaking as assuming the intake is outside of the frame perimeter there is a concern of the intake breaking in contact with obstacles, wall, other robots, etc. which wouldn’t be great, and if we want to drive as fast as possible without stressing out the drivers. We have been researching and working on design for an effective under the bumper intake. We’ll have little restrictions on how fast we’ll be able to drive with that. We plan on having some more finalized cad done by the end of Saturday and we’ll maybe post around then depending on some factors. I’m very excited with the concept!! (And I love the work your team is doing and has done in the past)

3 Likes

If anyone has any insight into this, please let us know!

Developing Robot Criteria Using XRC

Like many teams, this past week we have been discussing the necessity of going under the stage, and the pros and cons of intaking over the bumpers vs under. To help the team come to a consensus, our student strategy lead and I spent some time on XRC visualizing gameplay and cycles. Here are some of our takeaways.

Where will we see defense?

Before we could determine whether or not we wanted to go under the stage, we first had to figure out where other robots might try to stop our cycles. We first looked at the obvious, defending by your opponent’s speaker. This jumps out as obvious, because if you want to stop a team from scoring, you defend where they can score. However, we found that because of the congested nature of the wing, along with the launchpad and amp zones being protected, it is really easy for offensive robots to draw a penalty shooting from either location. The only real time defending in this area seemed viable was if the offensive robot could only shoot from the subwoofer, in which case the defensive bot would just park in front of it.

The next area of the field is the center. While you’re less likely to draw a penalty because there are no protected zones at midfield, you run the risk of slowing down your alliance members. On top of that, because midfield is not as congested with field elements, it is a lot easier for swerve bots to spin off the defense and continue with their cycle.

The last area we looked at was defending your opponent’s source. This area seemed to be the best compromise. While the source is protected, you can make it difficult for them to get there in the first place because of the placement of the stage. It’s just enough natural congestion to make it difficult to maneuver around the defense, with the added bonus of staying out of your alliance members’ way! We deemed this the ideal place to play defense and went forward with our discussions with this in mind.

Under the Stage

While going under the stage is not necessary to play the game and complete cycles, we found that a defender blocking off the source is very difficult to get around if you can’t go under the stage. Even if the defender is tank and the offensive bot is swerve, it is still very difficult to get around a defender. While XRC is not the perfect simulator and frame sizes will vary, skilled defensive drivers will have a huge advantage in this situation.

When we reopened the ability to go under the stage, it was night and day. That added element of making the defense guess where you are going to go gives the advantage back to the offense. It also gives the offense, especially swerve, more room to maneuver and spin out of defense.

Conclusion: We are making our robot go under the stage. Additionally, having a low COG robot has already been established as a team goal.

Over vs Under Bumper Intake

If you can’t pick up game pieces, you can’t score. A big consideration for our team was opponent interaction. For starters, you don’t want to have a collision with another robot or the wall into your intake and have it break. Second, you don’t want to accidentally reach inside another robot and draw a foul. After we came to the conclusion that heavy defense will be played by the source (where the intake is most vulnerable), the decision was pretty much made for us.

Another aspect we took into consideration was the drivers. If the drivers aren’t in constant fear of reaching into the opponent’s perimeter and/or causing damage to the intake, they’re going to be more confident and increase cycle efficiency.

Conclusion: Under the bumper intake.

5 Likes

Week 1 Update

Manufacturing

This week the manufacturing team made lots of progress with the temp field. We finished the construction of the Amp, and made progress on both the Stage and the Speaker. We discovered several times throughout the weekend that we did not purchase enough wood, so there were many Home Depot trips made. Other than that, we are on track to finish the rest of the components next Saturday. We have chosen not to build the Source as it is not necessary for our strategy, and we have limited storage space.

Other than the temp field, we are beginning to make decisions on our bumper construction, and should be building them next weekend. Right now we have to decide on mounting hardware and if we go with one-piece or two-piece bumpers. Additionally, we are hoping to design and manufacture a new driver station in the next two or three weeks so that we can have a more compact design finished before the robot is ready to be built. We had planned to do this in the preseason, but had communication issues and failed to produce a design in time, so we will instead make it in the next few weeks.

Programming and Electronics

We had a productive first weekend of the season. We got to work training the new students for programming on our 2022 robot, Sketchy Jane, by rewriting her codebase with the 2024 libraries. Simultaneously, we attempted to make our new swerve drivetrain follow trajectories for auto. We struggled to get Pathweaver working, and then realized that Pathplanner would be a much better option. However, we ran into a strange issue where the trajectories were rotated off by 90 degrees. Once we update our swerve code into the 2024 libraries, we will test this again and see what we can do to resolve it.

For next weekend, with software, we are hoping to: reimage the Rio for 2024, update our code to 2024’s libraries, work on trajectories, and continue training new members. As for electronics, we hope to work with the design team on planning out the wiring of the robot in order to avoid scrambling together questionable electronics-mounting schemes at the last minute possible.

Scouting

For scouting this year, we haven’t made any final decisions on what type of scouting system we prefer, but we do know what we want to be looking for during matches. We decided that unlike previous years, we would want to scout for more qualitative aspects of robots instead of quantitative. We also kept it simple when defining specifically what we are looking for. We are mainly looking for the number of cycles, consistency of the cycles, preferred scoring location, if they can do the trap, and how long it takes for teams to achieve their endgame, whether it be just climbing or climbing with a trap. We are also trying to track teams’ auto paths. We thought that this method of going over the general qualities of the teams is better than getting individual stats because the data are easier to record, less tedious to record, easier to compile, and more helpful while making match-to-match strategies and eventually pick lists.

We created a proposed scouting system that uses individual papers for each team at the competition. We chose paper for this proposed system as it is easy and convenient, as we don’t have to rely on scouts to bring their phones, keep their phones charged, and also use data at comps. We also have lots of experience with paper scouting as we have used it every year. There are still downsides to paper though, such as keeping it organized, compiling the data, and also just wasting paper, which is something we want to avoid as a team. This is why we decided to not solidify any scouting system yet, and have a team discussion about it sometime in the future. Below are images of the proposed paper scouting system.

This system is designed to be one double sided paper. The first side is the one that the scouts will be on during all of tele-op, where they can keep track of the team’s qualities across 7 different matches (4 matches for day 1, and 3 matches for day 2 to account for if teams improve over the course of the competition)

The second side has 4 pictures of the field where scouts can draw out an auto path and different tele-op cycles, as well as a section for notes for either auto or tele-op.

3 Likes

Weeks 2-5

Boy have we been busy! We are fighting hard to stay on track for our week one competition, and working on getting a comp-ready robot by the end of next weekend. Until then though, let’s look at what has happened over the past couple of weeks.

Manufacturing

Bumpers

This year, we decided to make our bumpers before week 8! We are using a uni-bumper for the first time, and had some difficulties while sizing the bumpers, but are at the point where all that’s left to do is finally mount the angle brackets to the bumpers and they should be good!

Chassis

By around the end of weekend 4, we finally finished our chassis! We are going with a 30” x 30” frame with the SDS MK4i modules in the corners, and had a nice fancy belly pan laser cut and spray painted. Once we got through the troubles with running wires and avoiding other components, the swerve was up and running!

We also got our 3D-printed swerve covers mounted. They simply clip onto the vertical spacers of the swerve units and were inspired by the clever design of Ajax Bachor. However, our design fully encloses the gearing of the MK4i units. Further, the covers accommodate 40mm muffin fans with snap-on filters to slightly pressurize the swerve units with clean air to keep carpet debris and other junk out. We have shared step files for the covers on GrabCAD here.

Intake

We used our routers to cut the side plates for our intake, and ran into some issues with not having the rollers close enough together to compress the game piece. Fortunately, it was easy to cut another piece with slight modifications and the intake has been tested on the robot. It finally works!

Shooter/Integration

Our shooter manufacturing came along pretty smoothly. We had some minor struggles with the pre-drilled extrusion from West Coast products. A number of the machined holes were slightly misplaced compared to the rest (not evenly spaced on 0.5” centers), so we had to drill out our polycarbonate holes slightly to align with the extrusion holes. We confirmed with both caliper measurements and other pieces of extrusion that the piece we had prepared for the shooter had the misplaced holes. We also had some issues with ordering the correct belts as well - oops. However, we found some work-arounds and the shooter has now been mounted. The initial transfer of notes from the intake to the shooter was not as smooth as we would like, so we are working to fine tune this. Our detailed CAD work this season has really helped minimize integration and configuration challenges prior to robot build.

Climber

We assembled our ThriftyBot telescoping tubes around weekend 2, and they came together pretty easily! We have also routed hooks to go on both of them out of ¼ inch polycarb. The hooks were designed with inspiration from 4481’s chain-catching design. Now, we are working on mounting the transmissions to the underside of the bellypan to drive the winches for the tubes. That should be the last step for the manufacturing of the robot!

Software

Auto

Before taking it apart for components, our swerve test base managed to follow some PathPlanner paths rather precisely! Now that we have the robot, we’ve been testing our auto system and it works well. We have an issue with path-following precision, so we aren’t able to pick up more than two notes precisely before the robot drifts off of the path, but hopefully we will be able to correct this with vision.

Vision

We briefly tested Photonvision’s pose estimator as well as Limelight’s pose estimator. We are hoping to go with Limelight’s software as we just picked up a Limelight 3, but we aren’t committed. Either way, it should prove very helpful with odometry.

2024 Robot

We have outlined all of our subsystems and tested our intake code. It works great, which is nice. Next weekend, we will be tuning our shooter setpoints - speeds and angles - for the speaker, amp, and hopefully trap. We will also be testing code for our climbers and building more autos. Our goal for Hartford - week one - is to have two shooter setpoints - from the subwoofer and from the protected zone on the stage - as well as to be able to shoot into the amp and theoretically the trap as well. From there, we will turn it over to drivers and keep building autos!

Oh, and one last electronics mishap…

We had a network switch short and it took out the vrm that was powering it as well as the Ethernet port on our Rio 2.0. We can connect to the Rio via usb and it works as expected. However, we get no comms when connecting via Ethernet. When a laptop is plugged into the rio’s Ethernet port, the Ethernet status lights will light up and stay on until the rio is power cycled, even if Ethernet is unplugged. Connecting the rio to the radio shows no status lights on the rio’s Ethernet port light. We didn’t see any visible damage to the rio when opening it. Figuring this out took a while as we were replacing everything on the networking stack trying to find the source of the comms failure. We replaced Ethernet cables. Tried connecting with different computers. Replaced our radio power module. Tried a new radio. We finally pulled the rio and replaced it with a spare and our issue was resolved. We are fortunate to have had a backup rio on our motor test board and have swapped the two, as we usually use usb to connect to the test board anyways. The only downside is that we are no longer working with a Rio 2.0, and hopefully we will not see any performance struggles as a result.

Design and drive team will be posting updates soon! I will also make a post ideally tomorrow with relevant media, like auto path tests.

Written by @kr1699 (me), Abby (senior captain), and @seth-crampton

1 Like

Promised Media Post

Initial Intaking


First intake while driving!

Slow-mo integration issues!

Chassis

Auto

3 piece??

4 piece??

Still working on the drive team and design posts, I promise!

2 Likes

We had a great weekend and are pushing to meet on Monday and Tuesday to see if we can get limelight aiming and shooting functional! Even if we don’t, we have a pretty consistent three piece auto and are happy with our shooting against the subwoofer/amp. We tried shooting into the speaker as well, and it works sometimes! Fingers crossed for tomorrow!

Here is a picture of our swerve covers with the aforementioned fans that circulate filtered air into them. Again, the .step files for these covers can be found here


3 Likes