FRC 1102 M'Aiken Magic | 2024 Build Thread | Open Alliance

I’m happy to announce that our team will be joining OA for the upcoming season. We’ve benefitted a lot from open source code, designs/CAD models as well as being the beneficiaries of excellent COTS products that helped elevate our competitive edge. We’re hoping that by sharing everything that we do moving forward we can help others and hopefully receive some useful feedback on our designs and process as it becomes more transparent to the community.

A Tome of History

1102 is a 21 year old team based in Aiken, South Carolina right on the SC/GA border. The team was originally founded as a partnership between Aiken County Public Schools and our local Savannah River National Laboratory. The lab here has a long history in working in robotics to support the various missions performed here on site, and even had a stint where a group of SRNL employees got together outside of work and competed in the comedy central version of Battlebots. When our founding mentor Clyde was asked if he would get some lab employees involved in mentoring a new local high-school robotics team to compete in FIRST the rest as they say became history.

M’Aiken Magic has gone through a few different eras.

The first ~8 years of the team’s history I would say the team was very balanced between both outreach and robot activities and solely focused on FRC. The team’s outreach efforts saw them compete for EI annually and even saw them win a Chairman’s award in 07. The robot team was competitive as well. Our best performance came in 2007 when 148 selected the team to join them in the playoffs at the Championship.

The next 10 years from 2008-2018 saw the team shift it’s primary focus more towards lower cost robotics leagues with the FRC team largely just being something we did without a real goal. We did see quite a lot of competitive success locally in VEX / FTC throughout this time culminating in
the 2010 season being my Sophomore year as a student on the team and our FTC World Championship win. The FTC program was able to make repeated trips to the FTC World Championship during the early years, but eventually advancement became a nightmare and it was harder to consistently advance even if you won the state tournament.

The 2018 - 2023 transition…
To some in the CD community I am sure we are anecdotally known as that one team that joined Peachtree a little earlier than everyone else from SC… and we still to this day serve a handful students from Georgia schools. The story behind that move was simple. I knew districts would be a good experience for my team and when I was asked to become the 4th head coach of M’Aiken Magic back in 2018 the team was still operating largely out of closets at our home school. So I made an effort to attempt a move to an Augusta, GA build site so we could rebuild in a more favorable location. A little bit of competitive success later and some lobbying and our Aiken situation turned around into us now having an entire shop classroom dedicated solely for our use starting back in 2021.

Starting in 2024…
Our team has some strong foundations, but we needed some serious help to rebuild after COVID. The 2022 and 2023 seasons saw us with no more than 6 students at any given time. I’m personally good at some handful of things, but outreach is not one of them. Luckily things in our community were changing… a large turnover has happened in some of our local businesses and a lot of engineers are reaching retirement age and thus a lot of new talent hiring has started to take place. SRNL in the last handful of years has hired a number of engineers and it so happens that some of them are alumni of FIRST and a few are even alumni of our team. This has provided our team with a lot of new opportunities for mentorship with our current mentor base being made up of more than 60% FIRST Alumni. In the last 12 months with help from our newest leadership mentor @AmbroseWiering we have evaluated our priorities and have rededicated ourselves to doing more outreach and openness with these changes and also have a renewed commitment to building better student leaders.

Additionally we have made the choice to slow our direct involvement in doing FTC/VEX in house and focus our energies entirely on doing FRC as well as we possibly can. It might seem insane to some, but for 10+ years now our program would compete in FTC or VEX in the fall + early winter, and then transition to FRC come January. As you can imagine this left us in a desperate situation each year with kids that were not well prepared to tackle the more complex challenges of FRC. I’d say the last few years of on field success we’ve had came with luck and endless/borderline insane amounts of brute force effort on the part of both our kids and mentors. We’re hoping our change in pre-season approach will lead to more confident and prepared students to tackle and own parts of the FRC process earlier in the season.

Our media/outreach team will likely be largely responsible for the posts in this blog, but as a long time CD member I’ll always be trying to update this thread with my thoughts.

We are an OnShape team so you can expect to be able follow along with our CAD progress once things get started. We are primarily a Java shop when it comes to software.

19 Likes

As the programming mentor my mission this year is to really find the right ways to teach kids with little to no software experience and create a path to have them confidently be able to understand the basics of coding the robot and chart a course towards more advanced subjects.

I’m not a Electrical/Controls engineer so my day job I’m working more in a general software development. This document I’m sharing below is the crash course workbook that I’m having my 5 programming sub-team students work through. It’s constantly being updated with more tasks and reference information. It is not a walkthrough of each task as I perform that duty in person at each meeting. My intent is to teach the students where the documentation lives and how to navigate it to find the information they need to solve each problem, and NOT to just provide a step by step example on how to do each task.

Our team has a test-bench that we use for a vast majority of these starter items which includes a Rio, PDP, Falcon 500 with a Gearbox, PWM VictorSP, and a CAN Spark Max + NEO, A REV Pneumatics Hub + Compressor and Single Solenoid.

I still have a long way to go towards being able to confidently teach more of the advanced subjects to a variety of kids whose background in math may not be where I need it to be yet. Things like PID tuning/fundamentals and then eventually I’d like to base more of our code on physics models and kinematics and that will require a lot of bridging the gap as well.

At the end of the day our team has gotten far over the years with a lot of very simple setpoints and drive practice, but we’re constantly looking for ways to improve ourselves to become more reliable on the field using more advanced techniques for achieving robust controls. One thing we have not done at all is logging. We display a lot of outputs to SmartDashboard, but saving data over a time period is not something we have accomplished yet. I know how important logging can be from how often I use PLC Tag change logs built into my microservice code at work so I want to get on top of logging very soon to ensure we have it ready for the next season. I’m sure AdvantageKit+Scope will likely be the route that we take.

4 Likes

Preparing for kickoff our team has been working in 3 areas of focus simultaneously.

CAD

Our manufacturing and design teams have been working on improving our OnShape use and knowledge through a student led workshop we held right before the Christmas/Winter break. We will post some of these documents soon.

We also have been experimenting with the use of the KrayonCAD library by prototyping and dimensioning robot concepts for prior games. One of our massive problems that we identified from our 2023 SCRIW build is that dimensioning of integrated systems did not happen on schedule and that left assembly and manufacturing scrambling to solve some hard problems. The robot did not get any software/drive testing prior to the offseason event. Everyone came to the understanding that this cannot happen during the next build and have been practicing and formulating processes to make sure communication and timelines for design and manufacturing are more clear for everyone.

Software

This year we have more students (7) interested learning about programming than ever before in the 20+ year history of the team. It’s been challenging to plan and implement ways to engage each new member so that they can start down the path towards understanding what we need team members to know in order to write code for our robots. We’ve created multiple documents that are meant to be basic primers and general topic guidance that we think are important to make sure each student on the programming team understands when it comes to Java fundamentals that then lead into Robot Programming Projects. We have a test chassis with SDS MK4 modules that we will be keeping together for explicitly programming subteam use as well as our 2023 robot which will stay together as long as it’s useful to us.

General Java Primer

Robot Project List

Leadership + Business/Outreach

Historically leadership positions on our team have been 1-2 captain roles each season decided by either mentor decision or democratic vote. This year we are taking a radically different approach.

For 2024 we are taking a more business/company approach to leadership. We have created 8 distinct leadership positions that have specific areas of focus and responsibility. We know we may not fill each role every year, but ideally we have a student that takes an interest in owning each part of our team’s foundation for success. Each captain position has a job description which I will link below. Our captain selection process mimics a job application as each interested student is required to submit a resume and cover letter and then they are interviewed by a panel of multiple mentors.

1 Like

We met for 5-6 hours today.

Prior to kickoff we reviewed the list of questions and topics to keep in mind while watching the reveal video that we formulated from our pre-season kickoff.

We used this and did a quick training exercise watching the 2013 FRC game kickoff video… little did I know I had precognition of similarities to the real game somehow.

After reviewing the kickoff broadcast we split into small groups with each responsible for helping the team has a whole digest the manual’s highlights. Every student will need to understand the manual, but for kickoff this helps us get kids more engaged and presenting information than just group reading the whole thing.

The team then spent a fair amount of time breaking down how the scoring system works and which tasks have higher value. I’ll give a better description of how that process went later on.

Finally we met our day’s milestone which was creating our action list and tiers of general priority. We need to add a few more items to this list but it’s starting to take shape in the direction we want to go in.

3 Likes

Purchasing

Prior to kickoff we stock up on some items we know we will need. We do not keep entire robots together from prior seasons so we will be reusing the RoboRIO 2.0 we had from last season as well as most of the REV Control system parts PDH/Pneumatics Modules etc. As well our our SDS MK4i Modules.

This is what we pre-stocked for the season so far. We still do not have everything we ordered in house as some of these WCP items were backordered. We also have an open order with CTRE for 8x of the new Kraken x60 motors.

Our first In-season purchase were to use most but not all of our AndyMark voucher.

This is our FIRST Choice Priority List for Round 2. We did not use any points in Round 1.

2 Likes

Additional Notes from our kickoff discussions and game analysis

  • An Amp dedicated robot would have a dead period where it would not be advantageous for it to score during the 10 second amplification of a speaker.

  • A team could stockpile rings under their stage to assist in protecting them from being stolen by the opposing alliance.

  • Stockpiling rings would allow a team to shoot multiple rings within the 10 second amplification of speaker.

  • A team would have to score in the trap to consistently score the endgame RP.

  • If a team does not have the ability to score in the trap, the value of getting Onstage is lower than the value of scoring in an amplified speaker. This is primarily a playoff minded anecdote.

  • The ability to pick up rings off the floor greatly increases the flexibility and strategic value of a robot in terms of controlling game pieces in the arena.

Floor pickup allows the following:

  • Reducing traffic jams around the Source
  • Scoring multiple rings within the same 10 second amplification
  • Monopolizing rings from the neutral zone
  • Stealing loose rings from the opposing alliance

We believe that the ability to drive under the stage greatly increases the strategic value of a robot

Driving under the stage allows the following

  • Reduced traffic bottle necks when traversing the field
  • Gaining access to placing and picking game pieces under your alliances stage
  • Gaining access to stealing game pieces from under your opponents stage
  • Ability to draw fouls from defensive robots that are attempting to prevent your scoring in the speaker
1 Like

One of the exercises that the student leadership team was asked to undergo before kickoff was to plan our our Build Season timeline on a Gantt Chart. This timeline has the team’s conservative estimates on we expect projects to be finished. This is the first time we have ever done this kind of timeline so we have a lot to learn and refine about the scheduled timeline we use. We also realized pretty quickly that the CAD/Design timeline should have extended back to kickoff.

5 Likes

Concept Generation

Our initial meeting out of the gate was spent generating concepts based on our priority list from earlier. This was a brainstorming exercise with the goal of generating as many creative solutions as possible. Ri3D concepts were also reviewed and discussed. The team was divided into four small groups to focus on concept generation, and in the last hour of the meeting, the team reconvened to discuss and build upon each idea.

Attached is a brainstorming training document that helps illustrate our team’s concept generation philosophy: Effective Group Brainstorming.docx - Google Docs

Prototyping

After generating concepts and narrowing our focus, the team divided to tackle prototyping. Our goal with prototyping was to evaluate unknowns and collect new knowledge. If a prototype concept had already been shown to be viable online, the goal was to develop a more thorough understanding of why and how it works, as well as any packaging and geometry constraints. Prototypes were expected to be fully functional not just a visual proof of concept.

There were three initial concepts we set out to explore:

  • Hammerhead
  • Vertical Shooter
  • Seesaw Intake/Shooter combo

Hammerhead

image

Conceptual Approach

This concept was inspired by the RI3D design from Unqualified Quokkas. The prototype objective was initially to evaluate a separate intake and shooter mechanism, but it evolved into exploring the geometry required for scoring into the amp and speaker with the same mechanism.

Construction components:

We used plywood, hex shaft, hex bearings, collar clamps, 14 tooth pulleys, belts and wood screws to construct. A layout on wood was sketched out and the bearing holes were drilled out using a hole saw.

Iteration 1

The initial iteration included a frame and arm assembly to prove the geometry required to score into the amp and the speaker.

Iteration 2

Due to inconsistencies in the shooting performance, guides were installed in the shooter that centered the ring, aligning it with the shooter wheels.

Iteration 3

Performance was evaluated with various shot angles. We analyzed its performance when the intake fed the note into the shooter from a standstill, rather than a continuous motion from picking up the game piece through shooting.

Vertical Shooter

image

Conceptual Approach

We hypothesized that scoring long range amp notes would reduce cycle time and provide a competitive advantage. The prototype goal was to evaluate the possibility of shooting into the amp from a distance. A hypothesis was that a note with backspin shot at the correct vector would skid off the back plate of the amp, contact the sidewall, and snap down into a scored state. A two wheeled flywheel shooter and a hooded single wheel shooter were both discussed, and the prototyped team decided to move forward with the two wheel concept.

Construction components

We wanted a prototype that could be easily adjusted so we used both the 2x1 Rev ion tubing with the press fit bearing holes and the ½ inch 10/32 hole pattern. The wheels selected were grey compliance wheels. We also used ½ inch hex shaft, bearings, collar clamps, deck screws, 2x4 wood sections, and some scrap polycarbonate. Later on we added 1.5 inch grey stealth wheels and spur gears to provide a chute accelerator/feeder mechanism.

Iteration 1

Our initial test compressed the note significantly and was oriented horizontally.

Iteration 2

We reoriented the shooter into a vertical position and added another sheet of plastic to guide the ring as it moved through the shooter wheels.

Iteration 3

We reduced the compression on the inlet guides by slanting them, and we adjusted the wheel speeds to generate backspin.

Iteration 4

We added a series of accelerator/feeder wheels to reduce the friction on the note from the guide chute.

Horizontal Shooter/Intake Combo

image

Conceptual approach

This concept was an evaluation of a question raised in our concept generation discussion: Can an intake shoot and score in the speaker using the same components? If so, the potential for mounting two of these assemblies on a seesaw arm with a pass through between them opened up possibilities for scoring in the speaker, amp, and trap using the same assembly. It also provided the ability to pick up and shoot from either side of the robot without reorienting.

Construction components

We again wanted an adjustable prototype so we used the 2x1 rev ion tubing with the ½ inch hole pattern alongside some recycled aluminum gussets to hold the ½ inch hex bearings with pop rivets. We used various wheels including the 4 inch grey stealth wheels, 2 and 7/8th inch T81 bane bot wheels of various durometers, and 1.5 inch black compliance wheels. We also used a variety of ½ inch hex shaft, collar clamps, and spacers.

Iteration 1

Our initial test was using the 4-inch stealth wheels on top and the 1.5 inch compliance wheels on bottom. It was able to pick up but could not shoot very far.

Iteration 2

We chose to reorient the mechanism with the larger set of wheels on bottom. We also increased compression between the two axles by ½ inch. This decreased the range of the shot and made it difficult to pick up the pieces.

Iteration 3

We changed to the T81 Bane Bot wheels and adjusted the compression back down. The shooter was able to score in the speaker once and picked up pieces very consistently.

XRC Simulator

Brain breaks are a huge help for productivity. For our lunch break, we set up 6 player stations for a local game of XRC simulator. The objective was to get students used to the flow of the game, including how traffic, shooting positions and end game would evolve during the match. The exercise was limited by lag and gameplay issues, but it was fun and entertaining.

5 Likes

A bit of an update on the software side of the house.

We have more students than ever on our programming team and we’re working on two things in parallel at the moment.

First is that we have a test chassis with Mk4 SDS modules on it and we are using it to train and learn about the Phoenix 6 upgrades to the CTRE library as we plan to continue using TalonFX powered motors (Falcon/Kraken) this season.

We setup the drivetrain using the TunerX application and generated a template project. We set off to work creating a custom command class that performs a set of behavior similar to our code base last season for applying speed limiting on the drivetrain as well as a set of cardinal direction rotation controls. We had to familiarize ourselves with the new SwerveRequest objects that CTRE introduced to their Phoenix 6 Swerve library.

Once that task was completed we spent some time trying out some of the different dashboard options available to us to display information about our drivetrain to start. We really like using AdvantageScope’s Swerve widget and other charting and graphing tools and we believe that we will be making heavy use of it during our development/testing this build season.

We also really like the Shuffleboard alternative that was released here on CD called Elastic.

We will be testing it out as a candidate for our competition dashboard.

Lastly on the drivetrain side we finally got to work trialing the changes made to PathPlanner 2024. We manually implemented a path following command into our swerve drivetrain code base last year, but we wanted to start fresh with our new students reading the documentation and implementing a solution that they liked. This lead us to trying out the AutoBuilder method and our first trial runs were extremely straightforward and easy to setup. We built a multi-path auto program in no time at all and are now working on setting up our practice field area to mock up the real field and note positions to start creating competition viable autonomous paths.

Next we began testing out our Limelight3’s with the latest revision of the AprilTags. We don’t have a ton of information to share yet, but getting the detection working in a very basic sense was super simple. We did some basic comparisons to the PhotonVision image for the Limelight3, but it’s too early for us to say which software package we will be running. The community is full of very helpful folks and we already have more information to look into at our next meeting to optimize the performance of our cameras.

Lastly we managed to trial the object detection using a Google Coral on our Limelight3 and we got some pretty cool results. We used the model linked below and managed to get our Limelight detecting notes in nearly every orientation really well. The framerate was on the low end, but we have yet to discover how high of a framerate we need for our neutral zone auton plans. If we need to go higher framerate we are considering an OrangePi 5 + PhotonVision alternative to potentially get upwards of 30+ FPS.

1 Like

What kind of framerate was the LL running the model at? Are we talking like 5fps or 15?

Closer to 10-12fps average. We used the edgetpu file in that zip folder.

1 Like

I just want to add a quick note to that: the model I trained there was my first success in training a model for the Coral, and I wanted to share it because I hadn’t seen any other public model anywhere yet. Since then Spectrum has also released a model I’m going to test to see if their process creates a faster/more effective model than mine, while still working on optimizing my initial method and dataset. It’s still super cool that you were able to get it running on the LL and have some data working on it.

Yea we were going to try a few things to create a model ourselves, but it was nice to have something to try today. In the end there is clearly something that can be done better because reports were that the Cone/Cube model from last season got much much higher framerates.

Design discussion:

After reviewing our in-house prototypes and the online design concepts from open alliance and RI3D, we dove into a two hour long design discussion. We use a weighted decision matrix to help us quantify our evaluation. While using the decision matrix is time consuming, we believe in its value when it comes to organizing the discussion and ensuring all designs are methodically evaluated based on all criteria. Our first step in the process is identifying and weighting the criteria by which we evaluate the designs. We then score each design for a criteria before moving to the next criteria. To save time, we were able to eliminate several criteria based on a lack of significant differentiation between designs.

Decision Matrix:

Our decision matrix pointed us towards continued development of the hammerhead concept, inspired by the Unqualified Quokkas. Our next steps were to define detailed dimensions and packaging using Krayon Cad and a 2D master sketch. We also put some work in identifying some preliminary design criteria by which we will evaluate our modules’ performance. We will continue to iterate our mechanisms to improve their performance based on these criteria.

Criteria:

Shoulder/Arm Intake Shooter
Positioning speed Packaging Shot consistency
Stability Angle of approach Range
Packaging Frame extension size Trajectory
Strength Jam proof Wheel speed control
Weight Shooter feed control/indexer Game piece compression
Consistency Durability
Acquisition speed Rigidity
Pickup range/width
Durability/Impact absorption

KrayonCAD:

2D Master Sketch:

Drive Train:

Our preliminary work analyzing packaging allowed us to lock in our frame perimeter and CAD out our drive base. Our goal is to batch complete modules in CAD so that we can keep our manufacturing team busy with work during the design process. The drive base parts will be ready for manufacturing soon and we will assemble and wire the drive base so we can use it for autonomous path planning and practice navigating the field elements with our true dimensions. We purchased the Kraken X60 motors and were fortunate enough to have received those early in the season. On Saturday we swapped out our swerve drive module Falcons with Krakens on the drive motors.

Drive Base CAD:

New Kraken Motors:

Manufacturing:

Our manufacturing captain is working on a few lean continuous improvement projects. These include developing standard processes for making parts on our various machines, creating a skills training matrix to document our students abilities and identify where we need to focus training efforts, and developing a barrier tracking system that will allow us to track waste during the season and will guide root cause corrective actions in the off season and next year.

8 Likes

I wanted to add on to this post that we had the students consider things to be significantly different or upgraded from the design that we studied from the Ri3D team.

In no particular order…

  • Wrist on the Hammerhead for more shot range variability
  • Undertaker that feeds into the hammerhead
  • Arm could telescope to potentially be able to do Trap
  • We could climb with the arm or with a separate mechanism
  • The shooter part of the Ri3D design had a lot potential improvement/optimization that can be done with different rollers, horizontal compression, and better motors.

One of the cool parts about the Ri3D design is that it was really similar to what we were already talking about internally before we ever saw the video. Our lead mechanical student was theory crafting a robot concept based around 2910 and 4188’s robots from last year before the end of kickoff.

We are just starting to work on CAD so we will update this thread later this week with some links to the WIP Onshape assemblies.

Fun fact. This will likely be the smallest frame perimeter 1102 robot we have ever built. The previously unmentioned frame perimeter is roughly 25"x25"

7 Likes

Continued some work with our Limelight 3s last night. We optimized our settings a bit to match those found in this document.

We could get 2D AprilTag tracking working from 15-20 ft away pretty well using these settings tweaked to the lighting in our shop. However 2D was just a start… 3D tracking did not work at all as we experienced severe issues with “ambiguity flipping” behavior.

We realized that while our non-calibrated cameras worked last season with the grid and the shorter distances we need to track 3D tag information from much farther away this season and so we will need to spend the time to do a full camera calibration for first time to see if that helps with the problematic behavior we are currently experiencing. More testing to come.

1 Like

Could you expound on why you think 3d over 2d is recommended?

Let me clarify that 3D is not specifically recommended it’s just something we want to get working.

If you want to do vision corrected Odometry/Pose estimation you need the 3D AprilTag data to be able to do so.

We could very easily decide to forgo 3D and build auto alignment and distance measurement functions that work with 2D tag information.

4 Likes

Make sure you have MegaTag enabled. I found that it was super stable with 2 tags in view, even in cases with very high pose ambiguity on one tag. The placement of tags next to the speaker this year make that a very achievable reality. Getting single tag pose to work out is potentially not worth it.

Calibration is very important to get perfect accuracy, however. I’m not sure how to upload new calibrations to LL but the stock cal can be way off, with range errors in the neighborhood of 10-30%.

I have to spend more time on it, but MegaTag isn’t a setting you have to turn on as far as I am aware. It’s enabled by default when 3D Targeting is turned on and you have a field map uploaded, which I do.

I was looking at the Robot Pose in Field space visualizer and saw MegaTag information on the screen, but for whatever reason the position estimation it was giving me was way off. The problem boils down to both tags flipping, not just one.

I actually was interested to see if Photonvision was having the same ambiguity flipping with both tags from where I was testing about 12 feet away and from the very little time I spent on it Photonvision also showed the same problem.

I tried higher resolutions and did not get the ambiguity to decrease much.

My next steps are definitely to calibrate the camera on LL OS first and see how that effects things. LL OS wants the user to do to 50 calibration images vs Photonvision only wanting 12.

1 Like