FRC 3082 Chicken Bot Pie | 2024 Build Thread - Open Alliance

Introduction

Welcome to the 2024 Open Alliance build thread for Team 3082 - Chicken Bot Pie! This is our first time participating in the Open Alliance, and we can’t wait to share everything we’ve been working on!

About the Team

Team 3082 is a student-led team from Minnetonka, Minnesota. We are a fairly large team, with around 60 members across 4 subteams. We have participated in FRC events since 2009. Our team is planning on attending the Northern Lights and Seven Rivers regional competitions in the 2024 season.

Team Goals

This year, our team goals are:

  • Create a community where everyone can learn and contribute
  • Prepare team members for the current and future seasons
  • Finish our robot well in advance of our first regional
  • Match or exceed last year’s performance
  • Build a reliable, efficient robot

Open Alliance Goals

In our first year of participating in the Open Alliance, we hope to:

  • Get input and advice from other teams
  • Connect with other teams and the FIRST community
  • Help teams who are struggling

And we’ll be posting:

  • An in-depth team update at least once per week
  • Additional smaller updates when we have cool stuff to share
  • Images and videos of our progress
  • Our CAD and code
  • Responses to questions and comments

Our Links:

9 Likes

Welcome to our first team update of the 2024 preseason! This post will just be a general summary of what we’ve done so far this year, so it won’t be very technical. We will be posting more detailed content in our future updates!

Team Restructuring

Our team’s structure has gone through several major changes since the end of last season. Previously, we did not have a formal team structure, nor did we have an accepted approach to project management. It was difficult for our subteams to coordinate with each other, which slowed down our progress throughout the season. This year, we have implemented a more formal team structure and an agile project management approach. Each subteam (build, programming, strategy, and operations) now has a subteam captain who is responsible for project management and coordination between subteams. Depending on size and workload, subteams may be further broken up into pods, which are smaller groups that specialize in specific tasks. We are hopeful that these changes will make collaboration easier and more efficient.

Offseason Event

We recently attended the Minne Mini Regional offseason event, which was a great opportunity for our new members to gain some competition experience before kickoff. Several shifts were assigned to each competition role, so most of the people who attended got the opportunity to contribute to the team. It was great to give everyone a chance to work in an active competition role, and we all loved being back at a competition again.

Build Training

Our build subteam has been busy training new members before kickoff. Build training starts with safety training, which every team member needs to complete before using tools or working on the robot. After completing safety training, there were several tasks for build team members to work on. First, we focused on repairing our robot for the Minne Mini Regional. In the days leading up to the regional, we repaired and reinforced our bumpers, replaced the motor on our robot’s wrist assembly, and disassembled our swerve modules for cleaning. It was our first chance this year to work on the robot, and it was a good way to give our new members some experience repairing it. We also spent some time repairing and repainting our robot cart. After Minne Mini, most of our time has been spent building a test swerve bot (as mentioned later in this post) and disassembling last year’s field elements.

Improving our Machining Capabilities

Our shop has a Haas CNC machine, but we have never known how to use it. A few members of the build team have been working on learning how to run the machine and design parts with this method of manufacturing in mind. We are hoping to use milled aluminum parts on our robot for the 2024 season.

Design and CAD Training

Our CAD pod has been hard at work learning how to design robot components, then create those designs in Onshape. Many of our CAD members aren’t familiar with Onshape, so we spent our first few meetings learning about basic functions like part studios, sketches, assemblies, and mate connectors. After that, we practiced these new skills by designing a simple swerve drivetrain. Not only was it a good way to practice working with parts and assemblies, it was a great opportunity for our more experienced members to help and collaborate with our new members. We also spent some time learning how to use KrayonCAD, which we think will be really helpful during kickoff.

Offseason/Outreach Robot

We have started working on an offseason swerve bot, which will be used for outreach events and training. We have purchased a set of SDS MK4i swerve modules for our offseason bot, as well as a set for next season’s bot. This will be our first time using MK4i modules, as well as our first time using L3 gear ratios, so we’re happy to get the chance to build a drivetrain on these modules before our competition robot in 2024. In the time leading up to kickoff, this robot will be a valuable learning tool for both the build and programming subteams.

Custom Auto Path Planning Software (ChickenPlanner)

Historically, our team has struggled during multiple seasons to get good, fast, and accurate autos ready in time for competition. To help with this, we are planning to develop a custom path planning software to make it easier to make autos. We could have used the official path planner application, but decided against it to allow for better customization and to shape the software to our specific wants and needs. The goals are to make paths with cubic bezier curves/splines, call specific robot actions(example: moving an arm, or calling a whole routine to move to a node and score like in Charged Up), then export and run them on the robot seamlessly.

Custom Network Tables Dashboard and Logging Program (ChickenDashboard)

The final programming project we are working on in the offseason is a custom dashboard program. The program will be able to graph, map, or display any value on the robot through network tables, as well as log and replay data. For example, it could replay data for a whole match so we could review multiple data points to see what we can improve through software or hardware.

Custom Vision Software (ChickenVision)

This offseason, we decided to take on the challenge of creating custom vision software, moving away from photonvision. The goal was for it to have custom opencv vision pipelines for apriltags, retroreflective tape, colored shapes, and also support for opencv DNN for machine learning based vision. We made a custom web server to view the camera stream remotely, and edit values for each pipeline. We have also added network tables support through the pynetworktables library. Finally, we have support for any number of cameras that you want to use. The final steps we are yet to complete are testing it on our robot and in the code to ensure it works, as well as making any changes to increase performance.

Operations Subteam

Our operations team has been working on two main tasks - fundraising and outreach. Operating an FRC team is expensive, and we wouldn’t be able to compete without the support of our sponsors. The operations team has been working on finding potential sponsors, as well as communicating with existing sponsors. They have also been working on planning and registering for community outreach events, such as a STEAM toy drive and a STEM event at a local science museum. We’re happy to say that our efforts to connect with our local community have never been stronger.

Strategy Subteam

We have decided to rework the way that we select our drive team, and the strategy team has been responsible for developing our new system. Like our old process, the new drive team selection process will take skill and strategy into account. However, the new system will also account for other factors such as coordination and communication skills. We haven’t had any significant issues with drive team selection in the past, but we believe that it would be helpful to evaluate potential members of the drive team more holistically. The strategy team has also been working on kickoff preparation and mock kickoff planning.

10 Likes

Business lead of 6995 NOMAD (also an OA rookie) here. First, I absolutely love your team name (and mascot). Second, it looks like in your restructuring, each subteam has a lead and each project division has a lead, but the pods don’t. Is there a pod leader that just isn’t mentioned in the graph? How do you manage having so many divisions in each subteam all reporting to the same subteam lead? Also, do you have a set communication/reporting system between subteam leads?
Third, did you already have a safety training system in place before the restructuring, or was that part of the project? My team has had trouble implementing a standard safety training program, and I’m trying to gather ideas.
Fourth, it’s interesting how similar our team activities are. We also attended off-season events after improving our hand and wrist, have a CNC router in our shop, use Onshape for CAD, made an outreach bot with MK4is, made a custom auto path planner, made a custom dashboard, are very invested in AprilTag vision, and are working on local outreach events. I’m somewhat curious to see how different your custom systems are to ours, but that was just something I found interesting.
I’ll definitely be watching this thread for more updates in the future to learn from an established team.

2 Likes

Hey there, thanks for the response! I’ll try to answer all your questions as well as I can.

I’m now realizing that it isn’t the most obvious based on the chart, but the project leads are responsible for leading the pods. Now that I’m thinking about it, it may be a good idea to change that role’s title to pod lead or something similar to reflect its function.

We’ve been working on implementing an agile project management approach, which makes this really easy. We have a few “layers” of meetings that we do every day, so we don’t need everyone on a subteam to meet directly with the subteam lead.

  • First, the whole team gets together at the beginning of the day, and the subteam leads all share a progress update and plans for the week, which gives other subteams a general idea of what’s going on.
  • Second, subteam leads meet with their project leads (pod leads?) briefly to discuss the day’s plans. This is usually pretty informal and is done in a few minutes.
  • Finally, project leads (pod leads?) talk to their pods in a brief meeting where the day’s plans, project status, and any other important details are shared. This is also an opportunity for pod members to share input, ask for help, etc.
  • Project leads also occasionally meet with each other privately, but @TotallyNotNero would know more about it than me, since I’m not a subteam lead.

So far, I think this approach has worked really well. It not only keeps everyone updated on the status of projects going on in all of the subteams, but it makes it easy to convey all of the relevant information to a relatively large team. We’ll need to wait to see how well it’ll work in-season, but I think it’s looking promising.

Communication between subteam leads usually occurs at the full-team meetings we have every day, the private subteam lead meetings, or (most frequently as far as I’m aware) informally via text message or slack. A lot of the communication between project leads also happens this way.

We have had a mandatory safety training program for as long as I can remember, but the process was overhauled in our team restructuring. Previously, all you had to do to get certified on a tool was watch a video and pass a quiz on the operation of whichever tool you’re getting certified on. This is still the first step of the safety training process, but we now need to attend an in-person demonstration of the tool’s safe operation, then use the tool ourselves to prove we can safely operate it. I think this system has been a significant improvement, even if it takes a bit longer to train everyone. Everyone’s training status is logged in a spreadsheet, so it’s very easy to see which tools everyone can/can’t use. I would recommend talking to your coaches/mentors about creating and implementing a safety training program. If you want more information or details about our system, feel free to ask!

We’ll likely start sharing some of our work soon, so it’ll be possible to compare our projects! We’ll be publishing a bunch of information in our next few team updates or as soon as our projects are presentable enough to share. I think it would be really interesting to see how they compare with each other :slightly_smiling_face:.

Thank you! We’ll also be watching your team’s thread, it looks like your pre-season is already off to a great start :slight_smile:

If there’s anything I didn’t answer well enough, or if you just want more details, feel free to ask!

2 Likes

our custom vision codebase is public, i haven’t had time to work on it in the past 2 months or so, but it is mostly complete

2 Likes

Blockquote

About how long would you say this takes? Is it an offseason or winter project? One of our main challenges is that the offseason is spent preparing for offseason competitions, and we don’t meet during the winter at all, so there’s not as much time available.

1 Like

The amount of time you’ll spend on safety training will probably depend on the size of your team and how much shop time you’re willing to dedicate to it. We don’t let anyone use tools if they aren’t certified on them, so we start doing safety training as soon as possible. I believe we started mid-September this year.

It took around an hour to get everyone to finish their safety quizzes, but that can probably be done at home if you don’t have enough time at your meetings. We only did a couple tool demos per week, and they were all scheduled in the mornings before school, so it took quite a while to get everyone trained. However, if you are willing to dedicate a meeting for tool demos, you could probably get them all done in a day (depending on the number of people you’re training and the number of tools you’re demonstrating).

Since your shop time is pretty limited, I’d suggest asking everyone to do their safety quizzes at home. It might also be better for you to only demonstrate one tool per meeting, so you don’t need to dedicate an entire day just to tool training.

Team Update, December 19, 2023

Engineering Design Principles

We have been heavily discussing the engineering design principles that we want to use on our next robot. We have decided to focus on the following principles throughout the next season:

  • Simplicity
  • Lightness
  • Efficiency
  • Reliability
  • Stability

These are all areas that we struggled in throughout the 2023 season, so we hope that designing our robot with these principles in mind will result in a more refined and competitive robot.

Offseason/Outreach Robot

Our build and electrical teams have finished working on the basic chassis for our offseason practice robot. It is fully built and wired, but we are still working on a few software issues that are preventing us from driving it. We are hoping to finish this project soon so we can finally start using it!

Another thing to note with this project: it has been fantastic electrical practice. We struggled with poor CAN wiring throughout the 2023 season, which resulted in the loss of robot functionality several times. Creating a better CAN network (and generally improving our wiring) will hopefully result in a much more reliable robot for the 2024 season.

Build Subteam Projects

The build subteam has recently been working on hands-on build training, CAD practice, and building a new robot cart. For build training, new members on the team have been working on assembling simple gearboxes for NEO motors. This project has been a great opportunity for them to familiarize themselves with tools, fasteners, and other components that are commonly used on FRC robots.

The CAD pod has continued to familiarize themselves with Onshape. Recently, they have been working on designing custom 3D printed parts, similar to the ones we might use on our 2024 robot. At our last meeting, they worked on designing a 3D printed camera mount. This was also a great opportunity to learn about the strengths and drawbacks of 3D printing, as well as ways to minimize those drawbacks. They also learned about designing parts with proper tolerances.

Our final pre-kickoff build project has been a new robot cart. After FIRST announced the updated robot cart rules, we decided that it would be useful to have a robot cart that could be brought out onto the field (as our previous one was too large). We chose to repurpose a cart with a lifting platform that we already had, then add a driver station and adjustable robot stands. This project will most likely not be finished before kickoff, but it won’t stand in the way of our robot development.

Machining

We’ve had quite a bit of success in our efforts to learn how to use our CNC machine. We used the part in the image below as a bit of a benchmark to judge the accuracy and cut quality, and we’re happy to say that both far exceed any tool we’ve had access to before.

Science Museum Event

Last Saturday, we did an outreach event at the Science Museum of Minnesota. We spent the day showing visitors our robot and giving them a chance to drive it, which seemed to be very popular! It was also a great time to introduce FIRST programs to parents and children who might be interested in STEM. This was a super fun event for everyone who showed up, and a great way to interact with our local community!

Pre-Kickoff Plans

Today will be our last “normal” meeting before kickoff. We’re hoping to (mostly) finish our preseason projects, then spend a bit of time finalizing kickoff plans, as well as post-kickoff project management plans. At our school, winter break starts this Wednesday, so we won’t be able to meet until that ends. After winter break, we are going to host a mock kickoff event, which will closely emulate our kickoff plans. I’ll go into more detail about those plans in a separate post.

Thank you for reading!

3 Likes

Props for the amazing name tbh.

3 Likes

Hey everyone, just wanted to share this presentation on our approach to strategic design, design workflow, and CAD workflow. As always, please feel free to leave a comment or ask a question! This workflow is fairly new to us, so we’re always open to advice and suggestions! We’ll share some information and plans about kickoff soon, but in the meantime, I hope everyone has a pleasant kickoff weekend!

1 Like

(Apologies for the late team update! I intended to post this a couple of days ago, but I didn’t have a lot of time on top of all of the standard post-kickoff activities.)

Welcome to our next team update, and I hope you’ve all had a great kickoff! In this update, I will discuss our training leading up to kickoff, our kickoff process, and our plans going forward. Another update should follow very soon with some robot ideas and prototype results.

Pre-Kickoff

We have had 3 meetings since our last update: a pre-kickoff meeting, our kickoff meeting, and one regular meeting. The primary purpose of our pre-kickoff meeting was to prepare our students, especially our newer ones, for kickoff. We began the day with a brief presentation on strategic design and design workflow, which can be found here (or in my previous reply). We then gave a (brief) presentation on some basic design principles and best practices, like minimizing DOFs, maintaining a low COM, and keeping our team’s scope in mind. With our presentations out of the way, we gave a (very brief) overview of the kickoff agenda, then revealed the game animation.

We used 2016’s FIRST Stronghold as an example game, and ran through most of the kickoff process that I will discuss later in this post. By the end of the day, we had a basic strategy formed, including a want / don’t want list.

Kickoff

In the past, our strategy decisions have been somewhat underdeveloped, resulting in robots that did not follow the principles of strategic design (and had worse performance as a result). We set out to change that this year, so we:

  • Spent more time on strategy
  • Decided not to CAD or otherwise design the robot on day 1
  • Considered design principles we learned last year
  • Created a more comprehensive strategy planning process

As a result, we are hoping to make a more simple & elegant design that is more in-line with our team’s design preferences.

Okay, enough background. It’s time for the fun part: kickoff!
We started the day with a team picture and a brief discussion about strategy, then watched the kickoff stream. The team then broke up into small groups and analyzed individual parts of the game manual.
After each group presented their findings, we did a game action analysis - something we haven’t tried in the past. We created a list of every action a robot could perform during a match, as well as the associated difficulty and benefit of those actions. This helped greatly with strategy later.

It was then time to form a strategy and a want / don’t want list. These both happened in the form of a full team discussion, where individual students could be called on to voice their opinions. After a bit of discussion, we decided that we generally wanted to focus on offense, but also put a focus on reliability, consistency, and simplicity. With those basic principles in mind, we discussed our wants / don’t wants.

We concluded that scoring in the amp and speaker are both incredibly important for teams that wish to be competitive, but scoring in the trap would likely not be worth the time and effort required to make a trap scoring mechanism. We also thought that climbing on and driving under the stage would both be important for scoring and cycle speed respectively. We decided to primarily focus on ground intake, since a ground intake can be used to recover missed shots and perform a multi-piece auto. However, we will likely incorporate a direct source intake into our design, as the short distance between the opponent’s speaker and our source incentivizes game piece stealing.
After that, our meeting was concluded. We did not meet for the few days after kickoff, but many students on the team spent that time researching prototypes made by other (mostly RI3D) teams and thinking about basic robot architecture.

Post-Kickoff Plans

As mentioned above, many students independently researched and developed mechanism ideas outside of official meetings. Some of these ideas were determined to be potentially useful, so we decided to prototype and test them. We have already built a couple basic prototypes, with more on the way. We will keep this thread updated with the results of our prototyping as more are finished. That’s all for now, thank you for reading!

2 Likes

I was going to wait until our next update to share this information, but I think it would be more helpful to other teams if I posted it now. We have been working on 3 prototypes - a side roller shooter, a top roller shooter, and an over the bumper intake. We also considered an under the bumper intake that would force the note under the frame, but have determined that it is likely not worthwhile to consider using a MK4i swerve drivetrain.

Here are the videos of our side and top roller shooters. The videos aren’t great (and I’ll try to get a better video of both in the future), but I hope they get the general point across.

We were somewhat surprised to see that the top roller design was significantly more powerful than the side roller design. We tested a variety of compressions and wheels on the side roller design, and nothing could rival the top roller design’s performance. We found that harder wheels (colson wheels, black compliant wheels) performed better than softer wheels (green, blue, and red compliant wheels) on both designs.

We will likely continue to prototype the top roller design, as we think the performance is very promising. For anyone wanting to replicate our results, we were using colson wheels with around 0.5in of compression on the game piece.

As mentioned above, we are also working on an over the bumper and under the bumper intake, but we don’t really have much to show for them yet. However, it’s worth noting that the game piece compresses a lot less than expected. We thought we could probably force the game piece under our drivetrain (using SDS MK4is), but it was basically impossible to force the game piece under. This means an under the bumper intake is likely not feasible unless you can increase ground clearance.

As always, if you have any questions, feel free to ask!

5 Likes

Prototyping

In the time since our last post, we have continued to work on several prototypes.
First, we have an intake prototype.
This intake uses two sets of 2” wide polyurethane belts on crowned pulleys to pull notes into the frame. The belts compress the note around 0.5 inches. We were really happy with this intake’s performance, so we are currently planning to use a similar intake on our final robot.

We have also continued to refine our horizontal (top-bottom) roller shooter. The shooter’s performance is promising, so we have decided to use this style of shooter in our final design. One thing worth noting is that its accuracy was relatively inconsistent when notes were fed into the mechanism by hand. When we added a fixed platform to slide the pieces on, it became significantly more accurate.

Robot Architecture

We have considered several robot architectures. We ended up deciding on a robot with an over the bumpers intake that feeds into a shooter on the opposite side of the robot. However, we also considered a variety of other designs, including designs with under the bumper intakes, elevators, a shooter and intake on the same side of the bot, and more. Here’s the first krayoncad model we made of our current architecture, as well as the final model we based our final design on:


Design Decisions

As stated above, we are planning to use an over the bumpers intake, which feeds notes into a shooter that launches them out the other side of the robot. This year, we are going to be making a very compact and lightweight robot.
We chose to use a 26x26 inch frame, which has since expanded to 26.5x26.5 inches with the inclusion of structural 1/4 inch aluminum plates. We chose these dimensions because we thought that smaller bots are generally lighter and better at evading defense bots, and 26x26 is close to the smallest drivetrain we can fit all of our mechanisms in.

We are using 1/4 inch aluminum plates for our robot’s structure because they are more space efficient than 1x1’s and 1x2’s, and they give us a bit more design freedom.
For the intake, we are either going to use 1/4 inch polycarbonate or aluminum, depending on how durable each material is. The intake will have the option to either eject the note directly into the frame, or actuate backwards to constrain the note’s position.

The shooter is constructed out of aluminum plate, and is driven by a chain and sprocket setup. We might change it in the future to use a different drive system if the chain is too inconsistent. The 2 sets of 60A compliant wheels compress the note 0.5 inches, and should launch them fairly consistently.

CAD

We can’t wait to release our CAD and show you all what we’ve been working on, but we have a few more changes we’d like to make. I’ll update this thread with a link to our final assembly as soon as it’s finished, but for now, here are some pictures of our progress!



2 Likes

This post will just be a somewhat brief update, as we don’t have many technical details to share yet. We will be releasing a technical binder soon, which should have significantly more detail.

Drivetrain

In the time since our last open alliance post, we have fully completed our drivetrain and bumpers. Fabrication took a relatively long time because the frame needs to have a lot of precisely drilled holes to mount mechanisms to. The frame is a 26x26 swerve drivetrain (equipped with L3 SDS MK4is), and is otherwise fairly standard. It uses two “C” shaped bumper halves, mounted using Citrus Circuits style bumper mounts.

Shooter

We have also made a significant amount of progress on our shooter. It isn’t fully complete, but should be ready for testing soon.

Climbers

Our climbers, like the shooter, are mostly complete as well. We have noticed some issues where the extending portion of the arm binds to the part mounted to the frame, preventing it from actuating. We think we can solve this issue with a bit of extra lubrication and increasing tolerances, but we are preparing another design just in case that doesn’t work.


Intake

The intake is… definitely a work in progress. All of the parts are machined, and we have started to assemble it. The polycarbonate part that actuates is almost completely finished. However, the aluminum structure that mounts to the frame and contains the gears, pulleys, and sprockets to drive the intake has proven to be very complicated to assemble. We believe that it shouldn’t be too difficult to repair, but the initial assembly is much less straightforward.

1 Like

Do you have any concerns of a note getting caught on your climber arms?

1 Like

I don’t think that will be a major issue, but it’s definitely possible. If we have any problems with it during testing, it should be pretty easy to fix. I think that connecting the ends of the two climbers with a churro (or something similar) would make it impossible for a note to get stuck.

1 Like

Welcome back to our Open Alliance thread! It’s been a little while since the last post, and we’ve gotten a lot done! We’ve also had some setbacks and issues, which I’ll talk about later.

General Mechanical

After a lot of work, our mechanical subteam has finished the robot (at least enough to function normally)! We had some setbacks, since we had to rebuild several parts of the intake, climbers, and shooter, but we’re finally at a point where we can start using the full robot. We still have some work to do though. We have had some concerns with the intake and indexer design, so we may need to go through a partial redesign before our wk.0 and wk.1 competitions.

Intake and Indexer

These two mechanisms are our biggest concern and most likely performance bottleneck at the moment. Our main concerns boil down to a few main points:
The intake currently doesn’t have any note centering capabilities (which should hopefully be easy to address, but an issue nonetheless)
The intake actuation mechanism is very complicated and somewhat hard to maintain
Some of the polybelts on the indexer are not tensioned properly, leading to slip
There is too much friction in the system, so it may overload our NEO 550 motors (whether or not this will be an issue is a heavily debated topic right now)
The intake binds slightly when actuating (it’s also unknown if this will be an issue, but probably not)
Really, the severity of these issues will only become apparent when we test the robot, so they’re mostly speculative at the moment. There are varying levels of concern on the team, ranging from “we should tweak this a bit before week 0” to “we need to redesign and rebuild this assembly immediately”, so I guess we’ll see who’s right in the coming few days. Regardless, we know that we will need to make some changes before our upcoming competitions to be competitive.


(picture for context - apologies for the mess, we’re in the middle of wiring)

Shooter

Good news - our shooter is working very well! We have tested it extensively over the past week or so, and it seems like it is going to be very accurate. The intake wasn’t done for most of our testing, so all of the notes were fed by hand. Admittedly, this might affect the results a bit, but we think (hope) the intake and indexer will just make our shots even more accurate.

(shot grouping, note for scale)

It also seems to be very stable with minimal tumbling as it flies through the air.

Climbers

The climbers have both been mostly done for a while now, and we’ve just been waiting on things like rope rigging and climber hooks. We recently finished all of that, so the climbers should be fully functional now. We also added an RSL and indicator light to them, as well as a camera bar (which holds 4 cameras, one in each direction).

Electrical

Now that the build is done mechanically, we have been working to get the whole robot wired up. We already had most of the robot (at least what was assembled at the time) wired up a while ago, but we decided to redo a large portion of the electronics to make them more reliable, serviceable, and organized. I can’t go into much detail since I don’t work with the electronics, but maybe someone who does could provide some more details if anyone’s interested!

On a less positive note, we broke a Falcon. Maybe two. One of our Falcon 500s had some mechanical issues which rendered it unusable, and because of the FRC motor rules, we won’t be able to repair it either. So I guess we now have the only paperweight you’ll ever need. The other Falcon has a chance at repair, since it may only be an external wiring issue (at least we reeeaaally hope so). If it’s unusable as well, we won’t have enough Falcons for the whole robot. Which means we’ll either need to wait for one of the Krakens we ordered, or we’ll need to replace it with a NEO (and order a new motor controller). So yeah, that really isn’t great, but hopefully it won’t be a huge issue…?

Other stuff

I think we’re on track to be ready for our upcoming wk.0 and wk.1 competitions, but it’s possible that we could have some major issues that could set us back (mostly with the intake and indexer). If those mechanisms don’t work, I’m not really sure what we’ll do or how we’ll fix them in time. I guess we’ll just have to wait and see how it goes though.

On another note, if anyone has some bumper number related advice, we’d be really appreciative of it. We decided that we were going to spray paint our numbers on, since stick on numbers continuously failed for us last year. We made a flexible stencil with a 3D printer, taped it to a set of test bumpers, and, uh… yeah.

This definitely won’t work. We already have our bumpers assembled, so we can’t really sew our numbers on, so what would you all recommend?

Conclusion

Anyway, that’s all for now. Our technical binder will be ready pretty soon, so be on the lookout for that. I’m also going to post our CAD in another post today. Otherwise, if you have any questions, comments, or advice, that’s always welcome!

CAD Release

Here is a link to our public Onshape document. We will update it whenever there is a significant update to our CAD models, but it is currently up to date. Also, there may be a few broken mates at the moment, but we’ll fix them in the future.

CRESCENDO Public CAD

1 Like

McMaster sells quality stencils. We keep one for spraying on bumper numbers in a pinch.

1 to 5 Character, 4" High Message Stencil McMaster-Carr

Have you had any issues with paint leaking in around the edges of the numbers? I think the main issue we had was that the stencil wasn’t flush with the bumpers.