2357 System Meltdown - 2023 Open Alliance Build Thread

[coderkevin]

Welcome to the FRC 2357 System Meltdown build thread for 2023: Charged Up! We are looking forward to our second year on the #openalliance and are planning on even more content than we produced last year. Speaking of last year, you can take a look at our 2022 build thread and our 2022 offseason summary if you’d like to read up on what we’ve been doing up to this point.

Last year, we set a goal to be a solid first pick at both of our regionals. We ended up the first pick on the 4th alliance at Greater KC, and the first pick of the 5th alliance at Central Missouri! We also received the Industrial Design award at Greater KC!

This year, we have several goals:

• Be very competitive for Impact Award / Engineering Inspiration (we’ve put a ton of work in on STEM outreach and community outreach especially this last year)
• Have a solid max-scoring autonomous mode (whatever is equivalent to 5-ball in 2022)
• Exude reliability at competition (thanks 1987 Broncobots for the idea on this one!)
• More than 20 hours of drive practice before first competition (including defense)
• Scouting team intel sent to drive team before each match (something we’re improving on)

Our team started in 2008, but we’ve really been raising our engineering and team activity levels by leaps and bounds since 2019. Last year we took 9 students to competition, and this year we’re starting with 19. However, all of our students this year are 1st and 2nd year team members! That’s ok though, we’ve been working hard throughout the offseason on our training and community outreach activities and we’re ready to go! We were just saying at our meeting today that we feel we are the best prepared for kickoff this year that we have ever been. The shop is mostly organized, we’ve checked our inventory of parts and materials and pre-ordered what we know we’ll need, and now we’re just ready to see what kickoff brings us!

You can follow our progress live as we work on our CAD and code:

We will keep our main robot design in Fusion 360 available here

And our code repo in Java will be available here

We also created a YouTube playlist for video updates here

Our competitions for this season are:

• Week 3 at Heartland in Olathe, KS
• Week 6 at Green Country in Tulsa, OK
• With some luck, the 2023 Championship

As mentioned on their thread, we’ll be joining forces for scouting with 5013, The Trobots at both regionals! We’re really looking forward to this as scouting and strategy are something we’ve been working on improving the last couple of years.

Good luck to everyone and we look forward to hearing/reading from you all!

[coderkevin]

Wow, what a great kickoff weekend! We’re all very excited for “Charged Up” this year! We think this game will be a deceptively tricky one that will require a lot of design iteration on the different tasks. Some of these tasks look easy (like balancing multiple robots on the charge station), but will require some iteration to get right consistently.

Day 1

We started with our traditional pancake breakfast. Then we watched the kickoff together and immediately after went into reading the game manual.

We split off into small groups to discuss, and each student came up with a game manual question and sent it to the team email where we put a Kahoot game together which all the students played. To our surprise, one of our first-years won! (And thanks to Broncobots 1987 for the Kahoot idea, it was fun!)

Game Analysis

We started with a base game analysis and given the limited scoring spaces, we figured the max theoretical game score (sans penalties) to be 193 points.

After that, we dug into game strategy, figuring out what parts of the game different categories of teams would do, cycle times, etc. We figured our estimates on a Week 6 level with no defense factored in. Of course previous weeks won’t be the same, and defense will happen. (and yes, we forgot to put the “park” option for endgame at the top, we added it after I had already taken the picture). From there, we went into the priorities for our team.

We finished the day with a human game simulation. Honestly I don’t think we learned very much from this, but it was fun

Day 2

On Day 2, we finalized our team goals and priorities for the build season, then we finally opened the floodgates for design discussion. After that, we went to the shop to work on some crude prototypes of our ideas.

Goals for our robot

We decided as a team we want to design for the possibility of being a top-4 seed team in the KC area regionals (we’re going to Heartland week 3), so here are our goals for our robot and gameplay this year:

• Drive base: SDS Mk4i L2 gearing (we have 5 of these modules and have them running on a test drivebase, complete with path planner working)
• Game Piece Acquisition: We will pick up both pieces from the floor in any orientation (as much as possible)
• Scoring on Grid: Both game pieces, any position
• Endgame: Engage (active balance) + 1 robot with us (stretch goal of +2 robots)
• Autonomous: Score 2 game pieces + Engage
• Single scoring mechanism for both cones and cubes
• Single intake for both cones and cubes if possible

Robot attributes

These are the attributes we want to keep in mind as we design the robot.

• Fast, maneuverable
• Positive, active game piece control
• Smaller width for triple-engage opportunities
• LOW Center of Gravity (preferably near center of robot, but may need to be offset for counterweight)
• Bumpers near top of bumper zone (for clearance on ramp)
• Robust, can take full-speed hits in center of field
• Able to dash over the charge station

On that last note, when we talked about defense this year, the most obvious fact is loading and scoring areas are protected; however, we fully expect a lot of high-speed collisions in the center of the field between those areas. It’s our best advice to other teams to make sure you’re holding on tight to those game pieces!

Prototypes

We had a lot of ideas to discuss, and we brought them down to a few things to try and split off into small groups to try some out:

Tossing cones onto a pole (even from a shorter distance than 3.5 feet)

We found this to be fairly unreliable still, at any range other than just a few inches away. At this time, we won’t consider this as a scoring option.

Tossing cubes onto a shelf

This actually seems fairly possible, but I’m not sure we’ll pursue it because we’d like to have a single scoring mechanism for both cones and cubes.

Wheel or belt “funnel” for initial intake

If you think about a cone lying on its side as a square base with a “tail” sticking off from it, you can knock the “tail” to the back and then pick it up from the square base side. While some of us did think of this overnight on the first day, there is actual industry precedent for this kind of pickup of traffic cones that we found later.

The idea for this initial intake is to have two rows of sideways wheels or belts that can catch the tip of the cone and push it away from us, leaving the open square side for us to pick up with a secondary intake feature.

Using vacuum suction for secondary intake of both game pieces and possibly a scoring mechanism

This would be after the alignment of the cone or cube to the center of our front bumper. An arm would come down and set suction cups on the game piece to bring it in. We did a very crude prototype of this similar to the Ri3D version to try it out. There are some expected disadvantages to this approach including the precision alignment required, seal quality, ability to knock the game piece off the suction, and requirement of a motor running to hold on for the duration.

Dual-purpose claw for scoring both game pieces

The design of this is similar to claws used in 2019 to pick up hatch panels from the inside hole, and pick up cargo balls from holding jaws around them. We mocked this up first in cardboard and then cut jaws in 1/4" hardboard. The claw held the cube reasonably well, and held the cone well enough, but we didn’t like the tension and potential wear it was putting on the hole at the top, also it’s a high precision operation to fit the tips of the claw into that 1" hole. We think a claw for scoring is still viable, but would need to hold on to the outside of the top of the cone instead of the inside.

Internal secondary intake

We also discussed the possibility of about a 9" bumper gap for a secondary intake to hold the game piece lower. Part of this design included a rotating clamping mechanism that would grasp the game piece from both sides and then use eccentric rotation to push it up vertically for the scoring mechanism to grasp. We don’t like bumper gaps in general for a couple reasons, so we’ll probably try to avoid this, but we do like the clamping mechanism idea for a secondary intake feature.

Some pictures of us prototyping in the shop:

We hope you all had a great kickoff weekend and we look forward to sharing more with you later this week!

[coderkevin]

Week 1 Recap

Wow, has it really only been a week and a couple days since Kickoff? We’ve already gone through so many iterations, it’s hard to remember the earlier ones!

We had several prototypes, most fell short of our expectations, but here’s a quick list:

Intake Prototypes:

• Highway passive “breaker bar” manipulator (already featured in many videos). This was too passive and works ok in a straight line, but FRC robots turn a lot. Also, no ability to pick up from wall or corner.
• 4-roller “from below” intake, catches edge of base on sideways cone and propels it upward. It was nice that this brought the base up first, but it’s very bulky and has many dead-spots to try to handle.
• Ri3D Redux Roller intake. We were impressed by how quickly this roller worked and was able to take cones from any orientation. They had a few dead spots, so we worked on some of the dimensions and went 3 rounds of prototyping on this. Definitely our most successful prototype, but it left a big question for us: How do we orient the cones after they’re in the robot?

Orienting Prototypes:

We were thinking if we end up going with the high-speed roller, it pushes the responsibility of orienting the cones to within the robot. So we tried out a couple options here. TLDR; we spent a good amount of our week racking our brains on trying to orient the cone game pieces. From what we’ve heard, most of y’all are doing the same.

• Deflection panels in polycarbonate to direct the game piece to the center. Seems to work, but have to be careful. Too aggressive an angle and cones get hung up.
• “Valley” boards that form a valley in the middle. This helped, but was too passive.
• Adding polybelts to the boards. These again helped some more, but weren’t giving us the results we wanted.

Scoring Prototypes:

• We first tried a claw that could expand in the top of the cones and contract on the cubes. We found that while these cones can be picked up from the hole, it’s too small to get something that can really support the weight of the cone this way, not to mention the accuracy needed.
• We tried some compliant wheels, like several other teams are doing for an intake. It seemed to work ok, but we’re really wanting a larger intake and if we do that, we want a lighter weight scoring device.
• We also had some students try out some suction methods for holding the game piece, but we didn’t really have the right equipment to adequately test, so we ordered some parts for possible further testing.
• We’re designing a claw gripper that will hold both a cone sideways from the mid-level and also a cube. We may 3D print some TPU for the gripper interfacing for this to see how a compliant surface will help us control the game pieces this way.

Scoring arm designs:

We’ve focused our cad sketch efforts on two major designs. Our requirements are that we score at the top level, but also are able to reach inside our robot to retrieve cones/cubes that have landed from our intake.

• 1-stage slanted elevator with simple rotating arm. Has potential, downside is requiring a motor/gearbox at the top of the elevator to rotate the arm. When extended, this motor/gearbox will be high up and outside the frame perimeter, which isn’t great CoG. Pros are the simple rotating arm, which could carry a small tensioned belt or wires/pneumatic tube without having a cable chain. And also, a simple arm can have a virtual four-bar for wrist movement up and down.
• 2-stage extension arm on a pivot. Boy this is a popular design this year! We’ll have to have a higher pivot than the bots that aren’t using a dedicated intake, but it could still be worth it. Advantages are being able to bring all gearboxes down near the drive base for low CoG while in-transit. Downside is just the geometry is a bit tight to retract the arm and still reach inside the robot for pickup. Also a downside is cable management for the extension.

Programming progress

Our programmers were busy at work updating everything to 2023 and getting our swerve drive working again after the updates. They ran into some issues with the SDS code initializing everything including the cancoders absolute values. Apparently sending a config at startup takes quite some time. So we’re looking at either pre-programming offsets into the cancoders using the Phoenix tool, or just handling the absolute offsets in the code ourselves.

Additionally, others on the programming team were helping with prototypes, trying out more Apriltags support, and working on more Arduino sensor options for our Arduino USB architecture.

Conclusions for Week 1

We’re at the point of making decisions for our implementation this year. Here’s what we know so far:

Robot dimensions

We’ve chosen a drive base size of 27"x27" at this point. We will see if we can get smaller later, but our CAD students are still fairly new and didn’t want the added challenge of smaller packaging yet.

Drive subsystem

We’ll be using the SDS Mk4i modules we got in the offseason last year. They’re still on a practice drive base and will remain there for the programmers until the new base is completely ready.

Intake

We will use a dedicated full-width roller intake like we prototyped above. It will be external, over the bumper, and retract with a four-bar linkage.

Scoring

We will use a 2-stage extending arm on an a-frame pivot. The end effector will be a simple claw mechanism, and won’t have up-down wrist movement, but will have rotary movement (see Cone Orientation below).

Cone Orientation

We plan on handling the yaw orientation of the cones with a rotating claw mechanism, using either an 8x8 ToF sensor array or a WPILibPi camera for detecting the rotation of the cone, adjusting the claw rotation to match for pick-up, and then orienting to the scoring rotation. As of now, this is the biggest risk to our design and our schedule. How are we going to mitigate that risk?

• We’re going to use deflectors on our intake to settle the piece as much as possible
• We have experience with Arduino sensors and WPILibPi cameras using OpenCV in Python. One of those should be sufficient for this task.
• We’re going to lower the claw in a vertical perpendicular orientation, which should result in a fairly uniform grip on the cone regardless of yaw angle.
• We are looking at moving the cone from the intake to the opposite side with some kind of conveyor belt system (still to be prototyped) and can use further deflectors to center the cone. This would help center the cone under the claw in both X and Y axes.

That’s all for now!

[coderkevin]

We had a late-entry dark horse prototype that came up in conversation on Tuesday. Initial testing went well, but we’ll do comprehensive testing on it at tonight’s meeting. If it goes well, we’ll be making some changes (for the better!) on our design. More to come!

[coderkevin]

Week 2 Recap

Late Entry Intake Prototype

As we showed above, we’ve been working on a different design for an intake that would quickly but accurately capture a cone piece for placement. Here are some videos of the latest (3rd) iteration:

We purposely only added the second set of 4" wheels on this prototype. We wanted to make sure the inner stages of the prototype were viable before widening the funnel. We’re looking at adding some more 2" wheels at an angle from here to widen that initial catch area. We may or may not include pneumatic hinging of the sides to grab the game piece better.

Charge Station

Our charge station is complete! And our programmers couldn’t wait to try out their self-balancing code on it. We still need to make the floor slides and add weight, but it’s looking promising so far.

Design adjustments

We’re making our final design decisions for our first robot version. We will likely make some more changes here and there as we iterate, but the design is taking shape.

Drive Base finalized

Our competition drive base is finalized and we adjusted to a 25"x27" frame perimeter. We felt after reviewing our designs we could bring in the width of the robot 2 more inches and still accommodate what we need.

Scoring mechanism

With the new intake design, it makes the most sense to clamp the game piece front-to-back and then lift it forward, so our intake and scoring mechanism will operate from the same side. We’re planning on a single rotating arm mounted on slanted uprights (no elevator), and one arm extension with a wrist and claw gripper.

We’ll have only two small air cylinders at the end of the arm, with 4 pneumatic tubes going out to the claw gripper, which should be a very lightweight system.

Additionally, while the arm mount will be fairly high at 40+ inches, we can move the motors and gearboxes for the arm pivot and arm extension down to the drive base for a low CoG (using a coaxial system with MAXSpline for arm rotation and an inner hex shaft driving a timing belt for arm extension.

Business / Marketing Team Updates

FIRST Impact Award

Our business and impact team have been busy gathering text and assets for our FIRST Impact submission. This last year’s offseason especially has been huge for us and we’ve worked harder in the community than ever, so we’ve got plenty of material to go over.

T-Shirts

Each year, we design thematic t-shirts for competition. Here’s the initial artwork for this year’s Charged Up season:

Logistics

We have also been selecting our hotel for Tulsa, Green Country Regional on Week 6, and also a preemptive hotel reservation for Champs. We’ve got some selections, and just need to reserve!

Scouting / Strategy

And finally, we had some of our students break off with our strategy lead and start some scouting info for every team at our first competition. We wanted to make sure to get as much information gathered as we can. We’ll continue to add more to our scouting data as we go. We’ve also been spending some time working on the android tablet based scouting system we’ll be using this year, to ensure we can capture all the data we need.

That’s all for this week’s summary. We’re not as far along in our schedule as we had planned, but we felt it would be worth it to take the time and get this intake right!

[Justin_Foss]

Good Morning, would you be willing to share the final dimensions and lessons learned on the dead spots with your Ri3D inspired intake? We would really like to have more data to compare to our own design for a similar intake, thanks!

[Bmongar]

Is this a gyroscopic balance or a pose balance?
If it is gyroscopic how are you dealing the the possibility of a stuck ramp (someone else’s auto put them in a dock state by accident) to prevent you from leaping off the high side of the ramp? We have put auto balance on a lower priority due to the concern of a rogue auto and leaping off the ramp.

[A_Jaguar_4192]

I second this, after adding some funneling wheels, could you also share how well cubes are being intaked, it seems that the base of the cone would need a similar width intake for a decently compressed cube.

[zkerfoot]

@Justin_Foss

share the final dimensions

We are more than willing to share our data we have collected. We ran a few center to center distance tests with our version 0 prototype for this intake. We found there is a happy medium between pushing too har and not holding onto the cone very much at all. Here are the distances we tested and what the students had to say about each.

Center to Center (CtC) Testing Results
*All of these tests had the backboard at 1.5" from the center of the wheel. Since these tests we have found that 2" from center seems to work better.

• 10.50" CtC: Seemed to be too close to grab the cone or cube, wheels were too tight for the wheels to effectively grab the cone base.
• 10.75" CtC: Cone and cube both were very tight between the wheels, lots of force required to move the cone and cube in/out.
• 11.00" CtC: Cone placed on backer board tight even when favoring one set of wheel, cube popped into place on all tests at this CtC.

Here is our latest prototype design. CAD for this design can be found here if you are looking for more measurements.

We found a couple edge cases where the cones would not go into the intake, excluding the obvious point first orientation. Here are those cases and what we plan to do to prevent/overcome them.

CONE EDGE CASES

Pushing the Cone Away
One issue we have found with the cones and this intake, hit the cone at the wrong angles (we are still playing around with it to find these spots) you throw the cone away from the robot. Like in the video below, with the cone offset too far from center the wheels direct the cone away from the robot. Most of these edge cases that we have found would be fixed with our front funnel design, but something for teams to watchout for and think about with their intake.

Sideways Cone Between Wheels
Another edge case I think we will be able to fix is the cone getting in the intake sideways. The largest factor to it getting stuck in this location is the motors stalling. Our working theory is that with a little bit more torque (and the motors not stalling) we can center the cone in is case. So far we have been running a Neo at 50% with a 5:1 reduction. If we gear to run the motor at the 80% we are targeting for our motors, we should be able to push the cone around and into place as desired.

@A_Jaguar_4192

share how well cubes are being intaked

For the cube we have not found a configuration yet that has not worked. Seems like with this style of intake anything that holds the cone base well holds the cube just fine. More testing to come with our next iteration of the intake.

[Justin_Foss]

Thanks for your willingness to share, can you also share the dimensions of your Ri3D Redux Roller intake? You said you went through several iterations and the final wooden prototype in the video looks to function great, we’d love to compare our layout to yours!

[zkerfoot]

Sure! Our first iteration of the design was just a rough idea with prototyping blocks and it tore itself apart before we got pictures. For the first iteration we really just wanted to make sure we could pick them up at all from the floor with a horizontal roller like that. We tested a few sizes of wheels and ended up liking how 4" threw the cone the best.

Iteration II
For the second go around we leaned on our CAD and CNC machines a little more. We wanted to have a design that we could test on our 2022 drivebase and change compressions on the cube and cone to get the best control and possibly help eliminate the randomness of the cone coming out of the intake. Here are the spacings we tried. The wheels were at a 45° angle. We ran this iteration through its paces and found that we like 10" center to center. Some notes we did not like about this intake is how inconsistent the cone entered into the robot. There was not really a rime or reason to how it landed. This intake eventually ripped itself apart and we moved on to the next iteration.

Iteration III
We ended up machined another design similar to before but with just the 7" spacing. The goal here was to control where the cone was landing so our scoring mechanism could consistently be able grab it in the handoff. We tried to control the cone various ways including a vertical funnel that the cone would settle in (relied on gravity and had too many edge cases where the cone got stuck), a horizontal funnel/guide system that used the momentum of the cone to center it (cone could get wedged between the two sides rather easy), and a turntable to rotate the cone after it settles on the robot (again, that pesky gravity).

At the end of Iteration III the team sat down and had a discussion about how we wanted to procced. We felt that we were going to be chasing how to control the cone (without gravity) with this intake design so we shifted our focus to our other intake style. I would love to here how your team is planning on controlling the cone after the intake.

[Woolly]

I see you have a different NEO on each roller, did you try having different speeds on each roller to see if you can control the trajectory out of the intake or get more consistent results that way?

[Tyson453]

It is a gyroscopic balance. The only limitation we have is that we don’t drive if the robot is tilted more than 15 degrees (full tilt of the charge station). We haven’t looked much into ways to prevent falling off the edge yet and instead just wanted a proof of concept. We will probably work on ways to stop us from falling off the ramp this week.

[zkerfoot]

Yes we did in fact experiment with various speeds. We discovered that keeping the lower rollers slower than the upper ones would allow for more control over the cone by keeping it low instead of throwing it. Even with the differing roller speeds we still were not quite happy with how inconsistent the cones entered the robot.

[osofdez]

For your horizontal 4" wheels intake did you do any tests picking the cone with the tip pointing to the backboard?

[coderkevin]

Yes, the bottom roller would pick up the tip of the cone just fine. To be clear, we loved everything about that intake except the difficulty orienting the cone afterward. We spent the better part of the week trying to solve the problem with everything from mechanical means to prospective vision systems, so if y’all find something that works consistently, we’d love to see it!

[osofdez]

Team Mechanical advantage has a similiar concept using mecanum wheels and a 3d printed spiral roller you should check it out. An extra question but about the other concept the vertical one 11" CtC distance. Did you do any tests con stand up cones and cones with the tip pointing towards the backboard?

[coderkevin]

Yes, for the second intake, it won’t handle tip-in cones. It should pick up any cone with the tip not directly pointed at the robot. Our goal is to handle 270 degrees of orientation. If the tip is directly towards the robot or within 45 degrees of it, we’d need to turn the robot before picking it up. We fel this was acceptable because 1. We’ll be using swerve, so turning is easy, and 2. We’ll likely have to turn around to get back to the community zone anyway.

[osofdez]

Our team is considering, doing something very similar. We are solving that issue in 2 ways.
a) Make the rear wheels compliant by making them pivot, this way they can hold the tip of the cone.
b) Have a cicular hole in the backboard with a ramp to center and give space for the cone tip to go through this way the fron compliant wheel can hold the back of the cone.

[coderkevin]

Those sound like great ideas if you can handle a cone in either orientation. Our scoring mechanism really needs the cones to be in the same orientation for the handoff between the intake and scoring parts of the robot. We’re hoping to have the next iteration of this intake on our swerve base this evening, so we’ll be running it through its paces and definitely post more info then.