FRC 2846 FireBears | 2024 Build Thread | Open Alliance

[Aryadragons]

Welcome to the 2024 build thread for FRC team 2846, FireBears! We are excited to participate in Open Alliance for the first year.

About us:

First competing in 2009 this is our 15th season. Operating out of Roseville Minnesota, we are currently a team of 40 students and 9 mentors. Broken up into 2 subteams; build and controls. Then in each subteam, students specialize in one of two areas. Either cad and mechanical for build or electrical and programming for controls. This allows for some training in each subteam, then more specialized training for the different areas of the subteam.

Build:

Currently our build subteam is using Onshape. Though we have just switched in the offseason from Solidworks. They have been working to refine a swerve drivetrain and create odds and ends. In addition all new build students were trained on our different power tools; mills, bandsaw, drill press, drills, and chop saw. With the returning students building a swerve drive base for 2023, early in the fall.
CAD links: Onshape
Onshape

To

Controls:

Lately the controls team has been working on updating our code for the 2023 robot from tank drive to swerve. They also have done training sessions for all programing focused students to get the new students up to speed but also to fill in gaps for returning students. While the electrical focused students have been either learning/reviewing how to stripe, crimp, and more. With the returning students also creating a new electrical board for the 2023 robot.

• GitHub - firebears-frc/FB2023

Outreach:

With the goal of increasing awareness, accessibility and acceptance of STEM we do numerous outreach efforts. Some of the biggest ones are:

• Gold Tier Partner of LGBTQ+ of FIRST organization: As a team we are working to spread awareness and acceptance of the LGBTQ+ community in FIRST. Through presentation, booths at tournaments, promotion in our pit and more we strive to create a more inclusive environment in the FIRST community.

• Minnesota Robotics Invitational (MRI): This is an offseason competition that we run in October. With 36 teams participating, it’s a great place for new drivers, while still being competitive.
  

  

• Lego Robotics Camp: This fall we ran a 4 day camp after school for 12 1st-3rd graders. Using an old FLL game they worked in small groups to build a mechanism that could complete a task on the field.
  

  

Goals for 2024:

As we prepare for the upcoming season we have set several goals.

• ⅔ rule. Meaning we want the robot to be able to contribute ⅔ or more of what is needed to achieve all ranking points. This includes auto, teleop, and endgame.

  • Ex: for 2023 this meant 8 game pieces and being able to balance in auto as well as endgame

• Don’t over complicate it. Meaning design a robot that is somewhat simple. Still make it fast, and competitive.

  • Ex: Last year we went with a two linkage arm design, with the Everybot intake. There were only two joints to worry about and just a wheeled intake. With it being able to score 5 pieces as a tank drive and 7-9 with swerve.
    
    

• Make it easily repairable. Meaning all parts of it should be able to be quickly taken off and fixed/replaced. In addition, you can see electronic components for quicker diagnosis work.

  • Ex: Last season the whole arm could be removed with 10 accessible screws, and the wiring had several disconnect points so you can not only quickly remove parts/subsystems but also wouldn’t have to rewire whole systems, just small sections.

[Aryadragons]

Pre-Kickoff Update

Practice Bot

Although Bag Day doesn’t exist anymore, we still build a practice bot. Its purpose has evolved from practicing post-bag to something of a beta robot like 1678. It allows us to learn from problems we encounter. Whether it be don’t tighten these bolts extremely tight or these holes need to be dead on, a practice bot gives a chance to learn these without hurting our competition bot. In addition, we can have a working bot for drive practice sooner. Although it won’t be a perfectly functioning bot, it still provides a lot of drive time with a season-specific bot.

Build Season Schedule

Events

This year we will be attending 3 events. A Week Zero event run by 2052 KnightKrawler, the Northern Lights Regional up in Duluth (Week 1), and the 10,000 Lakes Regional in Minneapolis (Week 6).

What To Expect From Us

Starting the season off with a post each day of kickoff weekend. Going into our prototyping week there will be 3 posts covering the design, building, and decision process. Following this will be posts covering the design refinement and the building and coding of our practice. Our next post will center around design improvement and the construction of our competition. After which we’ll explain our pit design and go over our preparation for and analysis of the Week 0 event. Followed by a robot reveal video and our prep for and summary of Northlight Regional. The next 4 weeks will feature weekly posts on any changes and improvements we are making. Along with our preparation for 10,000 Lakes Regional. After which we’ll post a summary of the competition.

[Tyler_S]

Kickoff (part 1)

Before the livestream we as a team went over the Evergreen rules as a refresher. After the video was revealed we read the new ruleset to see how it differed from previous years. We split into groups and wrote down all the possible actions a robot could take, then decided and ranked what we wanted the robot to do.

We ended up deciding we wanted to focus on shooting into the speaker as a higher priority over scoring in the amp, but still want to be able to do both. We also want to climb and place into the trap using the same mechanism as scoring in the amp (as the mechanism would be very similar). We also agreed we would need a ground pick up system because we are planning on doing at least a two piece auto and picking up from the ground is always viable while the source is only usable during tele-op and on the other side of the field.

Some of the interesting things that we noticed were that notes can be placed in the trap during tele-op and autonomous, not just during an endgame sequence (of which there isn’t one). We also found a possible mistake in the field sizes as the red side is half an inch longer than the blue side. But one of the most interesting we believe is the fact that according to the climbing rules a robot counts towards the Harmony climbing bonus if it is picked up by another robot.

While we were eating lunch, we tried to use our physics knowledge to derive an equation for the distance from the robot, height to the speaker and the velocity of the note required to launch it correctly. We were struggling but got close as we have it derived to the height, distance and time which is annoying because we don’t care about the time it takes the note to get to the speaker but couldn’t get to the point where we had velocity without first plugging in the distance which we don’t yet have until we have a basic shooter design down.

Written by Kai, our Team Captain

[Tyler_S]

Kickoff (part 2)

We began the day by reviewing and refining our priorities for what we want the robot to do. We decided to rank the importance of our priorities as follows:

1. Pick up notes from the ground
2. Score in the speaker
3. Score in the amp
4. Climb
5. Score in the trap
6. Carry another robot

Following this the team split into groups and drew out ideas for how to accomplish our goals, before sharing them with the whole team.

We then began to prototype mechanisms with Lego and leftover parts. The team split into two larger groups, one which experimented with using squishy wheels and polycarbonate to intake notes, and the other which further refined designs for an arm and did the math on what would be feasible to build. The intake team found success with one powered axle filled with wheels on top of a sheet of polycarb, but also saw that if they spun the motors too fast notes would actually be pushed away from the wheels. We also practiced spotlighting notes using the grid from last year.

Spotlight testing

Ultimately we decided that we would use over the bumper powered wheel intake, and that we would use both an arm and a shooter to score consistently in the speaker, amplifier, and trap. The arm would be able to extend over the bumper to intake notes, then place them either directly into the amplifier and trap, or into a shooter for the speaker. We’re still working out the math on how far we need to extend to score in the trap.

We’ve currently only done some preliminary CAD, which, in addition to all future designs can be found in the Onshape document below:

Onshape

Github page: GitHub - firebears-frc/FB2023

Written by Lathan, our Build Captain, and JJ

[Tyler_S]

Today in robotics we have been constructing, refining, and developing new concepts for our robot this year.

We know for absolute certain we will be using a swerve drivetrain.

Today, the main ideas that were ameliorated and conceptualized were hook designs.

Challenges that shape the design include;

• Needing to grab onto a chain that has a range of heights; 2 - 4 feet above the ground.
• The chain is not parallel to the ground (when off center), this offsets the center of mass.
• Getting the hook low enough on the robot’s base so the robot can be as close to the chain when raised so it is closer to the trap to score.
• Keeping the robot’s height below 2 feet when taxiing so it can move beneath the stage.

The two main hook designs are as follows;

• Two rotating arms that fix the hook above the chain, while a winch pulls the hooks down- and the robot up.
• One to two vertical translationally moving hooks that latch onto the chain and pull the robot up. Inspiration comes from Cheesy Poofs’ robot, Sideways: 2022 FRC Season – Rapid React | Team 254

(Concept drawings of hook designs)

In mechanical, our acquisition system prototype was completed. Updates were made, and they have begun to rebuild the prototype with these redesigns. The design of the acquisition system is inspired by the Unqualified Quokkas ‘robot in three days’ for this year. Additionally, our CNC Router is working once more. We refined the software and settings of the router, and two test parts were created successfully.

(FireBears working on Acquisition Prototype)

In electrical, they finished creating an electrical test board that can be installed onto any drivetrain for testing and trial programming.

(Electrical Test Board)

In programming, they have completed many tasks and programs that will be utilized in this year’s robot. You can see the latest updates of our software tasks in our GitHub project here: Software · GitHub

In CAD, the students have been learning, and building their CADing skills for when the robot design is finalized.

(CAD students practicing skills)

Written by Rei, our CAD Lead

[Tyler_S]

Mechanical has spent their time working on our acquisition/shooter system (which unless we come up with a better name will be deemed upbeat and downbeat. Maybe we’ll call the whole thing the measure…hmm or maybe the rhythm). The top and bottom wheels for the pickup worked great, so now the next step is to determine whether we want side wheels or top and bottom wheels for our shooter.

Currently we’re leaning towards a design with top and bottom intake wheels, with side wheels for the shooter. This would allow us to use spin to (theoretically) keep the note in the air longer, and give it a more accurate shot.

However, after Friday’s prototyping endeavors, it looks like top and bottom intake AND shooter is the better way. We messed with two different 2 different wheel configurations, one with spaced out wheels, and one with wheels only on the sides.

Bad shooter testing

This ended up with the wheels pulling the front of the note too soon, so we moved the wheels to the sides only.

Good shooter testing

Good shooter testing

When we changed it to the side wheels, it solved the problem of pulling the note too soon, and the note shot WAY farther. The shooting to the side was mostly due to the note hitting the 80/20 on the way out, so in our final design we will need to be mindful to not find ourselves in a similar situation.

Mechanical decided on using high bumpers for the bot, for ease of going over notes. Which does work with swerve! Yay!

MAXswerve vs NOTE (FAST!)

MAXswerve vs NOTE

Other than mechanical, programming has worked on pathplanner: GitHub - firebears-frc/FB2024

Written by Bella, our Controls Captain

[Tyler_S]

Coming soon

Coming soon we’re going to have a post about proper care of a Blåhaj:

Software Update

In the meantime, we’re going to do an update on the software side of things. To organize our software team this year, we’ve utilizing a GitHub project:

This has helped our software team know what tasks are open for work, some deadlines, and know the status of each task. Our rough schedule was put together before kickoff, which is why some tasks were generically called “Subsystem N prototype”.

Last saturday we did a “challenge” (sponsored by the Lead Mentor) that whatever student made our 2023 robot (using MAXswerve) follow a complex path using PathPlanner would win the $4 prize. Our programming lead won the challenge with this path:

MAXswerve pathplanner

We’ve run into a number of issues with our MAXswerve chassis for 2024 which has pushed back our schedule a bit, but they’ve not been issues with the modules:

1. One of our Rev Throughbore encoders had a pin which hadn’t been properly soldered from the factory (it works once soldered):

2. One of our swerve modules we forgot to put in one of the bearings.
3. Our CAN wiring to the RIO was flipped green to yellow.
4. Our old navX seems to be dead. It always reads 0 degrees yaw. Here’s a before and after video of the same code running on the issue navX and then a working navX:

Bad field oriented MAXswerve

Good field oriented MAXswerve

In addition to PathPlanner and MAXswerve, our team is also starting to use AdvantageScope and AdvantageKit to log data and visualize it. We’re also experimenting with URCL to log data directly from our Rev devices.

Don’t talk to me or my son ever again

Written by Tyler, our Control Systems Mentor

[Aryadragons]

Prototyping Update 3

Intake/Shooter:

We are going with the Unqualified Quokkas intake/shooter/amp dumper design. By going with this design we can have a variable shooter and ground pickup in one mechanism. Which will allow us to have a smaller, and a simpler robot. The shooter will be a top bottom shooter with wheels in blocks on either end. Between our testing and the testing of 95 Grasshoppers and 111/112 Windstang this seems to work quite well. The arm moving it will be ~19” long and ~7.5” inches off the ground. Made out of 1” by 2” aluminum tubing that is 1/16th” thick, which is then filled with wood, providing light but strong arm structure.

Climber:

We are unsure what type we will use and will figure it out later. As it can be added as long as we save space for it.

Drivetrain:

We are using MaxSwerve modules this year. With a width and length of 22” by 28”, which gives it enough and a ground clearance of ~2” so we can drive over notes. Right now we have a temporary electrical board inside of it. Having this constructed early will allow our programming team to get working on testing autonomous code.

[Tyler_S]

Software update 2

While our mechanical side of things has been a bit delayed, I wanted to give an update on how our software has been progressing. Continuing with our pathplanner challenge, we’ve continued developing the auto paths. We drew out a 5-piece auto path but only had a chance to test the 4-piece path:

MAXswerve 4 piece auto

We did some accuracy testing of our odometry, and we’re currently seeing about 1 foot of skew each time we run our complex 6 meter long path (~5% error). We’re going to be tuning the wheel diameter to try and correct for this, since it is extremely repeatable.

Yesterday we were able to get our partial field set up and put the vision system back into our 2023 robot as our test base.

We then worked on integrating PhotonVision pose estimation with our current MAXswerve code. We’re still working to improve the jitters in multi-tag mode, but have some good ideas. If anyone is trying to follow along, I recommend looking at this PR for the changes we made to start. If you have any questions, feel free to ask!

PhotonVision & MAXswerve

Written by Tyler, our Control Systems Mentor

[Aryadragons]

BLÅHAJ

DO NOT CRUSH

Our Blåhajs are very important to us and we want to keep them in good condition! When you crush them you’re not only harming them but you are also messing with their fluff.

NO BLÅHAJ WERE HARMED IN THE MAKING OF THIS PRESENTATION

Do NOT allow BLÅHAJ access to lock picking

They will become too powerful and will break into cars and further their education enough to be able to take over the world!

Proper holding of the Blåhaj

Carefully hold you arm over both sides of the dorsal fin be careful not to crush the fin

In case Blåhaj wishes to drive the robot take these steps

• Give them safety glasses
• Make sure they are holding on tight
• Always have someone watching to ensure the safety of Blåhaj and Robot
• Keep a finger on the emergency stop (just in case!)
  
  

ABSOLUTELY ZERO DIRTY HANDS

No dirty hands you’ll get our beloved Blåhaj’s dirty

“I am IKEA shark

I have jaws they r sharper

Than ur paws

Used to live in an IKEA

With the meatballs

But my ownr bought

Me

From the mall

With sharp lil teth

And blu n wite

But if you come

Closer

I promise I wont bite” (From r/BLAHAJ)

(Thank you Bea, Bubbles, Gale, Bo, Blajaw, Penelope, and Boing for being part of our team!)
-Written by Zephyr our Safety Captain

[Tyler_S]

Software update 3

Prior to receiving the alpha robot, we had completed preliminary code for every subsystem, including the climber. Due to the various delays, programming has had a fairly uneventful week heading into this last weekend.

Friday night was a busy meeting where we ran into a number of problems:

1. We had multiple breaks in the CAN bus
2. We had a non-latching connector on one of our Spark MAXes
3. We had two Spark MAXes which always read “sensor fault” even when connected to a known good NEO.
4. We had one NEO which always reads “sensor fault” even when connected to a known good Spark MAX.
   A. We suspect these devices were taken off of our 2022 chassis. At off-seasons we had issues with Spark MAXes burning out since we didn’t have current limits on our drive train (and played a lot of rough, pushing defense). We suspect that these Spark MAXes and NEOs were then mixed into our stock.
   However, we finished the initial checkout of the robot and the robot shot its first note!
   https://youtu.be/udq9j-5jBeY

On Saturday, we set up our full field of carpet and moved on to testing the other subsystems. First up we tested the intake on our carpet!

Robot's first intake

We then moved on to setting up setpoints on the arm for stow, speaker, amp, and pickup. In setting up setpoints for the arm, we discovered a latent bug that we brought over from our 2023 codebase. If the angle went below zero, we were unable to recover with the manual control. Switching from a double (0 to 360 degrees) to a Rotation2d (-180 to 180 degrees) resolved this issue. Once we tuned the PID on the shooter, we found out that we’re still a bit under-powered. It looks like moving our wheels around should resolve the issue.

Robot speaker failure

We’ve not been able to test our autos yet, but we hope to do so tonight.

Written by Tyler, our Control Systems Mentor

[Aryadragons]

Design Refinement Update

Intake/Shooter

Our intake will be using 2” squishy wheels spaced 1” apart. The indexing system will be an additional roller controlled by a beam break sensor. Finally, the shooter will consist of top-down rollers with sets of two wheels off to each side with ½” compression. Currently, we are using 45A-compliant wheels, but we might change them out later. In addition, we will try out adding side compression to the note in the shooting section once we have it built.

Arm

The arm mechanism is powered by 2 Neos, one on each side, who run into 1:144 gearboxes which power the sprockets. Said sprockets are in a 1:2.13 gear ratio and directly power the arm. This means the axel is functionally a dead axel, but it is moved by the arm. This allows us to get an encoder reading off the axel’s rotation. Once built the arm should be able to move 90 degrees in 1.5 seconds. To tension the chain, we will add or remove platform spacers under the gearboxes.

Climber

Right now we are looking to do the design of two scissor lifts with hooks on the top, which are connected to a 1” strap that will be wound with a winch to pull the robot up. The scissor lift would only be bringing the hooks up, not pulling the robot. This allows them to be made out of polycard making them light. The winch will be similar to a climber in a box winch. This design offers the benefits of being simple and easily repairable compared to linear actuators and climbers in a box. However, one challenge with this design is there aren’t a lot of resources out there for us to look at.

Electrical Board

The electrical team has been working on designing the electrical board layout. This has been especially a challenge this year as the robot is only 22” by 28”. The small chassis leaves little space for the electronics. Despite this, electrical was able to design a layout with most electronics being easy to access. This was done by having the central board be double-layered, with the top layer mounted with a hinge. The bottom layer is on standoffs to allow for wires to run underneath.

[Aryadragons]

Alpha Update 1

Shooter/Intake and Arm

Our build subteam has been hard at work manufacturing parts. The CAD group has been running the CNC, to produce the intake/shooter sides, and gusset plates for the arm support. The mechanical group has been cutting tubing and wood for the arm and its support and assembling the intake/shooter.

When assembling the intake/shooter we noticed the bearing that holds the axles in place on the ploy side kept popping out. To address this, we added more bearing! These new bearings oppose the original ones, locking them in place.

We also discovered we don’t have the correct 15-tooth sprockets for the arm. Only these double ones. So, we’ll use 12 tooth ones for our alpha bot and order the correct ones for the comp.

Climber

Design progress has been made. We have finalized the design for the base of the climber. Made out of 1” by 1” tubing with a slot cut into it, one arm will slide down it, while the other is fixed on it. With a 1” strap attached on one side, flowing through a pulley at the top, and winding up in a winch. For a winch, we will be using hubs put end to end.

[Aryadragons]

Alpha Update 2

Our build subteam has been busy finishing the bot minus climbers.

Though they faced several problems along the way. First the arm ended up being too long, so when it extended up it was above the 48’’ high limit. To solve this, they shortened the arm by 2”. We also realized where the gears boxes that move the arm attached to the belly pan, the bolts would have ripped through the plywood belly pan. So, 20 gauge steel plates were designed and cut out, going under the belly pan and should spread the stress out.

Passing it on the Controls, the electrical board was installed. Unfortunately, the hinge on the board will have to wait until comp bot. Otherwise, installation went off without a hitch.

The initial testing of the bot was another story… One of the NEO shooter motors was acting up, leaving us with 2 dead Spark Maxes and a bad NEO. The motor and Spark Maxs are saying a sensor error, that we couldn’t clear and therefore won’t run. Eventually we got the shooter running but didn’t have time to test the movement of the arm.

[BryceHanson]

@Aryadragons

Climber

Right now we are looking to do the design of two scissor lifts

Hi! I’ve loved following your build blog so far, and I wanted to drop a note of caution on scissor lifts. Often, they are incredibly finnicky, hard to keep rigid, and prone to breaking in unfortunate ways. It’s just a lot of moving parts and potential points of failure. There’s a reason that you won’t find many/any examples of effective scissor lifts across high-performing teams, or at least in the last decade or so.

If I were to go about designing a simple climber that’s pretty narrow, I’d look toward a few different places for inspiration:

2020 Everybot climber

Noodle Climb

4481’s single-stage climber

Good luck with the rest of your season!

[ad10bv]

Do you have any more examples or information on the pool noodle climber design?

[BryceHanson]

Honestly, not really? Your best bet is to search the discord for the words “pool noodle climber” and then ping the people who were discussing it. I think @Nick.kremer has more info. From my understanding, it works more or less the same as the 2020 everybot climber (single direction ratcheting spool) but instead of telescoping, it folds along the length of your bot.

[Skipster]

Actually we are just using the scissor lift to raise up a hook that is then attached to a strap that will be winched up or down to lift the robot. We have one on each side of the robot so we can control the height of each side to engage the chain when harmonizing. We know it would be a poor solution to actually lift the robot with the scissor lift directly. The one advantage we saw with trying this method was that we can reach up almost 40” with a design that compacts down. We are just finishing up with building out the climber and will have pictures and video shortly.

[spearson23]

I would second this. We had a scissor arm last year and it was incredibly finicky and prone to breaking.

[Aryadragons]

Umm…It’s Sentient?!

Sentient robot (youtube.com)

Yes, the bot can turn itself on. Unfortunately, this did break the power switch. We have since disabled this feature by moving it back by half an inch.

Also, this is slightly concerning as last year’s robot could turn itself off. Our fear is best expressed by Kai, our team captain, “IT’S EVOLVING!!!”