FRC 7525 Pioneers | 2025 Build Thread

Kickoff!

stratthing

Kickoff Activities:

We detailed our kickoff schedule in the previous OA post, if you’re interested take a look! Our kickoff consists of various activities meant to get everyone familiar with the game and ready to choose an architecture by the second day of kickoff. Here’s how everything went!

Shaker Sheets:

Right after watching the reveal video we broke up into groups and filled out this shaker sheet by 6328. Doing made sure everyone had thoroughly read the game manual before we started making any strategic decisions about our robot.

Needs, Wants, & Nice to Haves:

Each year after making shaker sheets we compile a list of robot actions and then sort them into Needs (our priorities this season), wants (secondary tasks), nice to haves (tasks we have a very low chance of doing), and junk (won’t be considering). In this discussion, we valued coral more highly than algae because on its own it can get much more points than algae. That leads us to this final chart!

Mock Game:

After letting our thoughts simmer overnight, we had a mock game! For our mock game, we had 4 people stand in the center of a half “field” (taped out area) to act as the reef while we had two “human players” hand off PVC pipes on opposite sides of the field. For algae, we placed balls on the ground and made the “reef” hold the algae, using a vending machine as a processor. This was pretty fun, and while we didn’t find any killer strategies from it, we saw that congestion is likely going to be a pretty big issue.

Architecture Decisions:

After coming up with a couple potential scopes for our robot, we eventually decided on a primarily coral-based architecture able to intake from the Coral Station and score in all 4 Reef levels. This is to allow for efficient cycling with a relatively simple design compared to trying to include a floor intake of some kind. We also plan on prioritizing coral because according to our analysis it would enable us to score more points and obtain more RP throughout a regional.

For algae, we decided on including a basic mechanism to help remove it from the Reef to open up more scoring spots for the ranking point. In addition, we are going to have some way to maneuver the algae into the Processor to get the Coopertition Point if needed. See the following section for an explanation on our decision to go with coral instead of algae for the robot.

As for endgame, we decided that unless we find an easy way to do a deep climb, we’re going to integrate a shallow climber into the robot, likely as a part of the elevator. All of this may change in the coming weeks and days as we prototype mechanisms, research other’s, and look at RI3D bots.

Mechanisms

Looking through our desired architectures, Ri3D posts, and other resources, we specifically planned out what components we will see on our upcoming design.

The team has agreed on a 29x29 chassis to mitigate the issue of high center of gravity and leave enough space for upcoming design ideas.

We chose to opt in for an elevator that is accompanied with a coral manipulator, algae intake, passthrough, and climbers for shallow cages.

We’ve also started some early experimentations with compression for each game piece, wheel/roller variations, and angle that can accomplish intaking from the coral station and releasing a coral onto a reef branch.

Goals and Timelines:

We outlined some SMART (Specific, Measurable, Achievable, Relevant, and Time-bound) goals for the season:

  • Score 10 game pieces per match (3 in auto, 7 in teleop)
  • Have 85% scouting accuracy throughout the season and only vod-scout 8 matches
  • top 3 captains or first pick alliances for MVR
  • 1000 followers on Instagram by Arkansas Regional (@pioneers7525 or @adroitstart if you want to help!)
  • No failures during a match by something preventable or repeated
  • Raise 10k by the Arkansas Regional through student efforts

Last season, we had some timelining and communication issues, specifically with handing off the robot for wiring. We ended up having to move and re-wire the PDH twice, costing us valuable meeting time :sweat_smile:. To avoid that this season, we’re using a Gantt chart to plan out our season in detail while clearly communicating between subteams. Over the kickoff weekend, Mechanical and Controls planned out and reviewed different starting dates and deadlines for the robot!

We decided January 10th is the date we want to solidify our mechanism decisions, giving us some time to look at RI3D designs and mechanisms other teams have come up with. Once we solidify mechanisms and motors, Robot-Programming can get started and hopefully finish programming the robot and verifying code in simulation before the robot is CADded. We set January 16th for an initial CAD iteration and a complete chassis. Once Robot-Programming gets the CAD, they can further verify code by using the CAD in simulation to make autos, test camera placement in sim, and more. Next, we want to have the robot ready to hand off for wiring by February 1st - which should give Robot-Programming a good amount of time to verify code on a physical robot and give the driver at least 10 hours of practice time. All this should lead to a completed robot by February 26th, a week before our first Regional, which can hopefully accomplish all of our robot-related goals!

4 Likes

Prog-a-thon!

controlsthing

In order to prepare everyone for build season and solidify the skills we’ve been working on throughout the off-season, we had a 1.5 week Prog-a-thon! Both the Pioneers and Frontier Robot-Programming teams chose a robot to program in the style they hoped to use in this build season.

Pioneers:

You can find Pioneer’s code here

With the Pioneers, we decided to program the CAD-a-thon robot made by our CAD team (expect a post on that later!). In short, the robot consisted of an elevator, indexer meant to hold 6 PVC pipes, and a slapdown floor intake.

In the past, our code style has relied on a state machine style “manager” class that stores instances of each subsystem (which also uses state machines) and controls the state of the entire robot by changing the states of subsystems. For this robot particularly, we needed a different approach for the indexer because we wanted it to have some autonomy, allowing it to let the intake remain out and constantly pass up game pieces while the indexer is simultaneously ready to intake. This led to us making a distinction between “Rogue” and “Managed” subsystems - where rogue subsystems manage their own states with some outside input from the manager while managed subsystems are fully controlled by the manager.

For driving, in the off-season, we swapped to CTRE swerve and made the template compatible with our state machine style of robot programming. This meant we could easily drop in the code as it already had sim. Similarly, we were able to drop in our 2 camera vision system, which we had programmed in the offseason. By leveraging PVs sim, we were able to learn much more about the code side of april tag detection.

We didn’t quite get to finish and it would be great to add in some features like MapleSim and LEDs in the future, but it was super useful as a learning experience for new and old programming students!

Frontiers:

You can find Frontier’s code here

To get some practice, we decided to program 319’s 2018 robot using their CAD to understand what is needed. This was chosen to prepare for a pick-and-place game since it would expose different mechanisms to us like a wrist, claw, and elevator.

The wrist is similar to parts we have coded before, like an amp bar or intake. The claw taught us how to use pneumatics and the elevator posed an interesting challenge - a shifting gearbox. This gave insight into what was typically used a few years ago to have options like “high speed” or “high torque”, which uses pneumatics and a ball shifter mechanism to engage one of two gears. This was not included in our code, but it provided a learning experience of using our resources to obtain new perspectives and information. Also, we expanded our drive code to have a defensive X-formation when a certain button is pressed and added a controller for the Operator, so there are two separate Xbox controllers, unlike before when we would only have one for the Driver.

Team lib & Build Season Changes:

Over the summer and off-season, Pioneers has been developing a team library for use in our build season. You can see our code here. Instead of copy-pasting the folder into a new project each time we make one, our code is now stored in github packages so we can make slight modifications to our build.gradlew and then we have access to the lib! The lib mostly consists of abstractions for a custom subsystem class that makes programming with state machines in our code style much easier and more readable.

Although we didn’t use it in the prog-a-thon, Frontier plans to use the team library in the build season, which we have programmed a few mechanisms with for practice! For driving, Frontier plans to continue using YAGSL and should hopefully have a vision system with at least 1 arducam and an orange pi. Their season code will be stored here.

For Pioneers, we plan to continue using CTRE swerve because it is very easy to configure with Tuner X, has long testing hours, and makes use of many optimizations. We will also continue to use photon vision with 1 orange pi and 2 arducams, which should give us good enough odometry in addition to the 250hz odometry we have with CTRE swerve. We have already started programming and are making great progress, hoping to use auto aligning to specific locations heavily in this game, giving us mostly autonomous cycles (expect a post on that pretty soon!). You can see our code for the build season here.

5 Likes

Build Season Update 1

Mechanical:

mechthing

CAD:

CAD has officially begun! Below I will be placing some slides that we created to explain each of our mechanism choices and what the next steps are.

General Updates

Chassis

Elevator

Coral Manipulator

Passthrough

Algae Manipulator

Climber

Strategy Programming:

stratthing

With a week passed since kickoff, strategy programming has made some pretty significant progress! Just like we did pre-season, we are choosing to use React Native, Expo, and TypeScript to develop our app. Our first task was creating a timeline, which aims to have our app finished by February 15th, so that our scouters can have as much time as possible to get used to it. We’ve also finished a rough draft for the app’s appearance and layout. We hope to finish an MVP within a week or two, and we will begin as soon as we finish polishing up our design!

7 Likes

Build Season Update 2

Mechanical:

mechthing

Fabrication:

We’ve made some progress on prototyping our components, testing out methods of intaking game pieces, and fabricating plates needed to experiment with orientation of wheels and wheel types. Though we did not manage to meet our expectations of our prototyping, we hope that we continue to make observations to refine our design.

CAD:

CAD is continuing to make progress! Update slides will be placed below.

General Updates

Chassis

Elevator

Coral Manipulator

Passthrough

Algae Manipulator

Climber

MOO:

moothing

MOO took some time out of the day to set deadlines including Impact, Woodie Flowers, merch, and fundraising goals. We hope to stick to them as the season progresses.

We’ve also started up Aventura again, having students assist alongside enriching activities to continue educating the kids in robotics skills even after their competition. Alongside that, our team will help assist Hivemind’s local FTC invitational, the FTC team we partner with, and the FLL East Tennessee State Championships. We will keep heading out to more sites, whether teaching across the city or helping feed our local communities, and keep the impact going year round. Later this week, we’re going to introduce our Impact project in a new light and provide some designs/CAD teams can use if they’d like to replicate it in their cities. Keep an eye out for that post.

Robot Programming:

controlsthing

Pioneers:

Over the past week Pioneers has programmed the robot based on our initial architecture decisions while keeping up with Mechanical to make sure we’re not programming anything too incorrectly.

Subsystems:

We’ve mostly finished programming and are polishing up our code to get it ready for testing and tuning once the robot is built. In total, we have 6 physical subsystems (and 2 software ones!) in our codebase:

Drive:
We’re using CTRE swerve because it’s super easy to configure with falcons for azimuth, krakens for drive, and a pidgeon all on a CANivore bus. We haven’t made any significant modifications to our drive code since the offseason and are excited to start working on autos.

Algae:
The algae mechanism is meant to intake algae from the reef and (hopefully) floor then score it in the processor. This relies on a pivot and an intake which we’ve programmed before! We’re adding an absolute encoder on this pivot so hopefully we’ll get experience wiring an absolute encoder and setting them up on a mechanism other than swerve.

Coraler:
The coraler is super simple, it’s just a set of wheels with two beam breaks!

Elevator:
We had also had some practice in the offseason with programming an elevator so we were easily able to drop in that code. We plan to just use current zeroing (after manually pushing down the elevator pre-match) to zero it to limit the points of failure with a limit switch or absolute encoder (also because we don’t have much experience with either of those sensors :sweat_smile:).

Climber:
The climber is also pretty simple, it’s just a neo that brings up or down the climber. We’re probably going to do a similar thing for zeroing as the elevator.

Vision:
This year we plan to use 2 arducams and an orange pi. It should give us good enough field localization in addition to 250hz wheel odometry from swerve.

Manager:
The manager is one of our two “Software” subsystems, it manages all of the other subsystems and handles “state transitions” which just means it changes the target setpoints of each subsystem it manages.

Auto Align:
We know auto aligning to score coral is going to be super important in this game - because of 12 different pegs to score on per level on the reef and long alignment times. Because of this, we plan to have what are basically half autonomous cycles. The driver will have a button (left and right button corresponding to each coral station) to drive to each coral station and intake a coral. For scoring on the reef, the operator will have 6 buttons for selecting the side of the hexagon to score on and a left/right button to choose to score on the left or right peg. In order to implement this while avoiding crashing into the reef, we’ve implemented a repulsor path planner (we used 6995s repulsor field) which works in tandem with “dumb” PID (just a PID controller on rotation and translation) to drive to a location. Auto Align will switch to dumb PID from repulsor path planning when it has a direct line of sight to its target setpoint, so when it’s not obstructed by the reef. Here’s Auto Align working in sim (ignore the robot clipping the reef, real robot has different dimensions)!

2025-01-14 19-01-11

State Diagram

Because we use state machines in our codebase, each year we can pretty easily diagram out how we plan to structure the entire codebase in drawIO (free and super helpful!). Here’s what our state diagram looks like for this year, and the only major changes we’ve made to this structure are how Auto Align interacts with manager and the amount of states it has:

As always, our code is publicly available here (currently in the staging branch, we plan to merge everything after testing!)

Frontier:

In terms of programming, Frontier has continued learning by programming some practice subsystems. This week they’ve focused on programming a version of Auto Align that uses basic PID to align to the closest point to the robot on the reef. As far as actual subsystems go, they’ve also programmed a pretty simple algae only robot with a OTB floor intake for algae that feeds into a claw on a pivot which can score algae on in the processor and in the net. All this practice should help them hit the ground running next week once we select a vendor bot for them to program and build!

1 Like