Team2890/learning-garden
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Auto-publish: training content update 2026-05-20 17:21:08

Browse Source
This commit is contained in:
psb-gemma
2026-05-20 17:21:08 +00:00
parent 2f8831e649
commit 9319720a1f
310 changed files with 3 additions and 35555 deletions
Download Patch File Download Diff File Expand all files Collapse all files

151
training/modules/2890-codebase-index.md
View File

@@ -1,151 +0,0 @@
---
type: training-material
domain: robotics
subdomain: code-index
level: reference
tags: [frc, java, swerve, autonomous, pathplanner, photonvision, yagsl]
status: active
source: Team2890 Gitea (Mothman repo)
growth: tree
---
# Team 2890 Codebase Index — Training Reference
**Source:** https://gitea.hawkcollective2890.com/Team2890/Mothman
**Access:** Via Gitea API token (read)
**Language:** Java (WPILib)
**Note:** Concepts apply to C++ — syntax differs, patterns identical
---
## Repo Structure Overview
```
Mothman/
├── src/main/java/frc/robot/
│ ├── Constants.java — Robot-wide constants
│ ├── LimelightHelpers.java — Vision targeting helpers
│ ├── Main.java — Robot entry point
│ ├── Robot.java — Main robot class (periodic methods)
│ ├── RobotContainer.java — Joysticks, commands, subsystems wiring
│ ├── commands/ — Command classes
│ └── subsystems/ — Hardware subsystem controllers
├── src/main/deploy/
│ ├── pathplanner/ — Autonomous paths + autos
│ └── swerve/ — Swerve module JSON configs
└── vendordeps/ — Vendor libraries (Phoenix, REV, etc.)
```
---
## Key Training Resources by Topic
### 🏎️ Swerve Drive (YAGSL)
**Config files:**
- `deploy/swerve/neo/swervedrive.json` — swerve drive config
- `deploy/swerve/neo/modules/*.json` — per-module PID/physical properties
**Code:**
- `subsystems/swervedrive/SwerveSubsystem.java` — main swerve controller
- `commands/swervedrive/drivebase/AbsoluteDriveAdv.java` — advanced field-relative drive
**Training value:**
- YAGSL configuration structure (JSON-based swerve setup)
- Swerve module characterization
- Field-relative vs robot-relative control
---
### 📍 PathPlanner (Autonomous)
**Config:**
- `src/main/deploy/pathplanner/autos/*.auto` — named autonomous routines
- `src/main/deploy/pathplanner/paths/*.path` — individual path segments
**Example autos:**
- `1 Meter Test Auto.auto`
- `90 Degree Test Auto.auto`
**Training value:**
- Auto path structure (waypoints, constraints)
- PathPlannerLib integration
- Auto command sequencing
---
### 👁️ Vision (PhotonVision + Limelight)
**Code:**
- `subsystems/swervedrive/Vision.java` — AprilTag detection, pose estimation
- `LimelightHelpers.java` — Limelight vision helpers
**Training value:**
- Camera pipeline setup (PhotonVision)
- AprilTag interpretation (field layout)
- Pose estimation from vision
---
### 🎮 Subsystems
- `ClimberSubsystem.java` — Robot climber mechanism
- `IntakeSubsystem.java` — Game piece intake
- `ShooterSubsystem.java` — Scoring shooter
- `TargetingSubsystems.java` — Aim assist
**Training value:**
- Subsystem architecture (commands bound to triggers)
- Motor controller setup (Phoenix/REV)
---
### ⚙️ Vendor Dependencies (vendordeps/)
- `Phoenix5-replay-5.36.0.json` — TalonFX (legacy)
- `Phoenix6-replay-26.1.0.json` — TalonFX (new)
- `REVLib.json` — NEO, SparkFlex motors
- `PathplannerLib-2026.1.2.json` — Auto/path planning
- `photonlib.json` — PhotonVision
- `yagsl-2026.1.14.json` — Swerve library
- `ReduxLib-2026.1.1.json` — Sensors
- `Studica-2026.0.0.json` — Contour following
- `ThriftyLib-2026.json` — Thrifty cameras
---
## Key Files for C++ Developers
**For C++ teams learning from Java code:**
- **Subsystem class** — Java: `extends SubsystemBase` → C++: Inherit `frc::SubsystemBase`
- **Command binding** — Java: `+=` operator → C++: `AddCommands()`
- **Motor controller** — Java: `.set()` → C++: `Set()`
- **Joystick input** — Java: `driver.getRawButton()` → C++: `GetRawButton()`
- **Auto commands** — `pathplanner` (same library in both languages)
---
## What to Use for Training
**For students learning FRC programming:**
1. Start with `SwerveSubsystem.java` — see swerve control in action
2. Look at `AbsoluteDriveAdv.java` — field-relative swerve drive logic
3. Check `RobotContainer.java` — how subsystems + commands + joysticks wire together
4. Study the path files — how autos are composed from paths
**For C++ students:**
- The pattern is identical. Focus on the logic, not the syntax.
- YAGSL config (JSON) works the same in both languages
---
## External Mirrors
- **PhotonVision** → Team2890/PhotonVision — Vision processing (mirrored from github)
- **YAGSL** → Team2890/YAGSL — Swerve library (mirrored)
- **allwpilib** → Team2890/allwpilib — WPILib source (mirrored)
---
**Access:** `https://gitea.hawkcollective2890.com/Team2890/Mothman`

137
training/modules/2890-our-story.md
View File

@@ -1,137 +0,0 @@
---
title: "Hawk Collective 2890 — Our Story"
tags:
- onboarding
- 2890
- team
- history
- identity
type: training-module
track: entry
owner: 2890
growth: tree
---
# Hawk Collective 2890 — Our Story
## Who We Are
Hawk Collective 2890 is Hickory High School's robotics team. We compete in the FIRST Chesapeake District. We are builders, programmers, designers, welders, machinists, and strategists. We're a team that believes in showing up for each other and leaving things better than we found them.
We're not the biggest team. We're not the richest team. But we've been at this since 2009, and we're still showing up.
**Rookie year:** 2009 — sixteen years and counting
**Location:** Hickory High School, Chesapeake, Virginia
**School address:** 1996 Hawk, Chesapeake VA 23322 — phone: 1-757-421-HAWK
**Competition area:** Chesapeake District (Virginia/Maryland)
## Why "Collective"
Most teams call themselves "The Hawks" or "Team 2890." We say Hawk *Collective*.
"Collective" is what we believe: the team is bigger than any one person. If one of us wins, we all win. If one of us is struggling, we all step up. The robot doesn't get built by a star — it gets built by a team.
When the 2009 senior class picked that name, they were saying something true about themselves. They knew they'd built something bigger than their own experience. The name stuck because the idea behind it was right.
## How We Got Here
### 2009 — The Beginning
A group of Hickory students looked at what other schools were doing and decided they wanted in. No robotics program existed at the school. No shop, no tools, no real budget, no experience.
What they had was a gymnasium they could use for storage, a salvage yard of mechanical parts, and six weeks to build a robot from nothing. They didn't know what they were doing. They did it anyway.
That original team of maybe 10 students is the reason you're reading this now. They made the space for everyone who came after.
### 2010–2015 — The Learning Years
These were the years of figuring it out. How to build something that doesn't fall apart. How to program it so it actually does what you want. How to compete without falling apart when things go wrong.
The team survived on bake sales, donations from local businesses, and the kind of stubbornness that comes from not knowing any better. Budget was nonexistent. Every tool was earned. Every competition was a road trip in someone's parents' van.
These were also the years that built the culture. The older students who figured things out started teaching the younger ones. The idea that you help the person next to you — that you don't hoard knowledge — started here. It's still how we operate.
### 2016–2020 — The Growth
The team got real. Students started bringing their younger siblings. The school started putting real money into the shop. Mentors from industry started showing up — engineers from the naval shipyard, machinists from local manufacturing, teachers who saw what this team was actually building in students.
This is when the team stopped being "some kids in a gym with a robot" and started being what it is today. The shop got actual tools. The team got actual space. The expectations got higher.
### 2021–Present — What You Joined
The team that exists right now, today. We've got a culture of showing up, learning out loud, and not quitting when it gets hard. Seniors who came in as freshmen learned to weld, code, and design because someone before them decided to teach instead of just doing it themselves.
We're still not the biggest or the richest team in the district. But we've got something that matters: a team that believes the person next to them deserves what they know.
## How We're Organized
### Students Run This
Not metaphorically. Actually.
Students make the real decisions on design, build strategy, competition moves, and team priorities. Mentors teach, guide, keep people safe, and share what they've learned. But the work belongs to the people doing it.
If you want to own a system on the robot — electrical, mechanical, code — you can. You just have to learn the fundamentals first and prove you won't break something expensive on a guess. The point of this team is to make you capable, not dependent.
Every senior on this team should be able to teach what they know. That's how we get better.
### The Roles
- **Build** — Mechanical — welding, machining, assembly, field setup. If it moves or holds something, Build makes it happen.
- **Electrical** — Power and sensing — wiring, pneumatics, battery management, sensor integration. The nervous system and circulatory system of the robot.
- **Programming** — Robot code, vision systems, autonomous routines, driver station setup. The brain of the robot.
- **Scouting** — Data and strategy — watching other teams, analyzing match data, informing alliance selection. Intelligence for the competition.
- **Media** — Team branding, documentation, outreach. How the world sees us.
You can do more than one. Most people do. Nobody starts knowing everything.
## What We Expect From You
**Show up.**
Consistency beats talent. The person who never misses a meeting will outlast the genius who shows up when they feel like it. You don't have to be the best builder or the fastest coder on day one. You just have to keep showing up.
**Ask questions.**
Every expert on this team was once a beginner who asked. There are no stupid questions in this shop. There are only questions you didn't ask and now something's broken. If you're confused about how something works, ask the person next to you. If they're busy, wait and ask a mentor. If you still don't understand, ask again.
**Admit when you're stuck.**
"I don't know" is not a weakness. It's the starting line for learning. The only thing that will get you in real trouble is pretending you know something you don't. Nobody is going to yell at you for not knowing something. They will yell at you for breaking something expensive because you didn't ask.
**Help others.**
If you know something that someone else doesn't, you haven't earned the right to keep it to yourself. The person who helps others doesn't lose their advantage — they strengthen the whole team. A team where everyone shares what they know is a team that wins.
**Take care of the space.**
The shop, the tools, the robots, the field elements — these belong to the team. Not to you. Not to any one person. Leave them better than you found them. If something is broken, tell someone. If something is about to break, tell someone. If you borrowed something, return it.
## What We Believe
> We show up. We learn out loud. We don't quit.
This isn't a motto. It's how we operate when things get hard.
If something breaks, we fix it. If someone is behind, we catch them up. If the game is hard, we figure out a way. If we lose, we shake hands and come back smarter. If something isn't working, we don't pretend it is — we acknowledge it and we solve it.
You will fail at something on this team. Everyone does. The difference between the person who grows and the person who quits is that one of them keeps going after failing.
## The Gear We Run
Team 2890's current standard drivetrain is **MK4i swerve modules** with **NEO Vortex** motors. Here's what that means:
**MK4i swerve** means each wheel can steer and drive independently. It's a more complex drivetrain than tank drive, but it gives you directional control that's worth it for most game tasks.
**NEO Vortex** is the motor. Made by REV Robotics. Fast, powerful, and reliable when configured correctly.
Each motor runs a **SPARK Flex** controller, which handles the CAN communication between the motor and the roboRIO (the robot's main computer).
For vision, we use **PhotonVision** with **Limelight** sensors. This lets the robot see the field, locate itself, and aim at targets automatically.
If you don't know what any of that means yet — good. That's what the garden is for.
---
**Next:** [[youth-safety|Youth Safety]] — read this before you touch anything in the shop

171
training/modules/first-robotics-overview.md
View File

@@ -1,171 +0,0 @@
---
title: "FIRST Robotics — The Big Picture"
tags:
- onboarding
- first
- history
- philosophy
- gracious-professionalism
- coopertition
type: training-module
track: entry
owner: 2890
growth: tree
---
# FIRST Robotics — The Big Picture
> "The vision is to transform our culture by creating a world where science and technology are celebrated, where young people dream of becoming science and technology heroes."
> — Dean Kamen, Founder of FIRST
## What Is FIRST
FIRST stands for **For Inspiration and Recognition of Science and Technology**. It was founded in 1989 by Dean Kamen — an inventor best known for the Segway, but more importantly, a guy who looked at American culture and decided that kids needed to see engineering as something worth doing, something heroic.
Kamen's problem was simple: science and tech were being taught as abstract, boring, solo work done by people who couldn't talk to anyone. Athletics got all the glory — the team jerseys, the pep rallies, the crowd cheering. He thought, why can't building a robot feel like that? Why can't engineering be just as exciting, just as celebrated?
So he built FIRST. And it changed everything.
Every year, FIRST releases a new robotics competition. Teams of students — high schoolers, mostly 14 to 18 years old — have **six weeks** to design, build, and program a robot that can compete in that year's game. Not a toy. Not a kit you assemble from instructions. A real machine, built from scratch, that has to actually work under pressure on a competition field.
There are four programs under the FIRST umbrella:
- **FIRST Lego League (FLL)** — ages 9-14, robots made from Lego parts
- **FIRST Tech Challenge (FTC)** — ages 12-18, more sophisticated robots, still student-built
- **FIRST Robotics Competition (FRC)** — the big one, what we do at Hawk Collective 2890
- **FIRST Championship** — the world finals where the best teams from every district compete
We're FRC. 3,000+ teams worldwide. The biggest robotics competition for high school students that exists.
If you've never seen an FRC match, stop reading this and watch one. Search "FRC match" on YouTube. Watch three minutes. Then come back. It'll make everything else on this page make sense.
## Why FIRST Exists
Here's the uncomfortable truth about how most school works: you learn something, you take a test, you forget it. The system is built for compliance and individual performance. Collaboration is a footnote. Failure is something to avoid, not learn from.
FIRST is the opposite.
You will fail. I'm not being negative — I'm being honest. Your first prototype will break. Your code won't work the first time. Your robot will do something embarrassing at your first competition. This is not a bug. This is the entire point.
The work is hard. The problems are new every year. The deadline is always coming. You have to work with people who have different skills than you. You have to ask for help and give help. You have to learn to lose without quitting and win without being insufferable.
That's what FIRST is building. The robot is the vehicle. The point is what happens to the people who build it.
> Students who participate in FIRST are twice as likely to major in science or engineering. That's not a marketing stat — that's a documented outcome of what happens when you give young people real problems to solve with real consequences and real teammates.
## The Three Core Values
FIRST has three guiding principles. These aren't suggestions. They're how you're supposed to act, on and off the field. Everyone in FIRST — students, mentors, volunteers — is supposed to live by these.
### Gracious Professionalism™
Coined by Woodie Flowers, a MIT professor and FRC legend who died in 2009. Gracious Professionalism means: compete hard, but treat people with respect. Win or lose, you shake hands. If another team needs help, you give it — even if it helps them beat you later.
The goal is to raise the bar for everyone. Not knock others down to raise yourself.
No trash talk. No sabotage. No burning bridges. If you won because you cheated or because you refused to help someone, you didn't really win.
This sounds soft until you see it in action. Watch an FRC match where two robots from rival schools bump into each other mid-game. Watch them both stop, assess, and figure out how to keep going. That's gracious professionalism.
### Coopertition™
Coopertition means: cooperate + competition. You can compete fiercely and still work with other teams. In FRC tournaments, teams form **alliances** of three robots for each match. That means you're often working with teams you just met, who might be your competitors in a later round.
It sounds contradictory until you see it in action. Watch alliance selection at a big event — top teams picking their partners, knowing full well they might face those same teams in the finals. And they still share strategy, still help each other debug.
### Invention and Innovation
No two FIRST seasons look alike. The challenge changes. The field changes. The scoring changes. The strategy changes. You cannot coast on last year's winning design. You have to think about the problem, not just copy a solution.
This is the value I personally think matters most for your future. The ability to look at a new problem and figure out how to solve it, without someone handing you the answer — that's rare. FIRST gives you practice at it.
## The Competition Structure
### District Events
Most FRC teams compete in district events first. These are smaller competitions run by regional FIRST organizations. We compete in the **Chesapeake District**, which covers Virginia and Maryland. Most of our travel is within a few hours of home.
District events are intense. You show up, you calibrate your robots, you compete in qualification matches where the alliances are randomly assigned. You scout other teams — watch their robots, figure out their strengths and weaknesses, plan your strategy. Then comes alliance selection, where the top teams pick their partners for the finals.
Points earned at district events accumulate over the season. Teams need enough points to qualify for the District Championship.
### District Championship
Top qualifying teams from the district face off. This is where it gets serious. The competition is harder, the stakes are higher, and the field is smaller. In the Chesapeake District, only the top teams make it this far.
### FIRST Championship
The world championship. All districts from all over the planet send their best. For most teams, this is a once-in-a-lifetime experience. The energy in the arena is unlike anything else in robotics — 10,000 students in one building, all cheering for engineering.
Hawk Collective 2890 has never been to Championship. That's not a secret. It's a goal.
## How a Season Works
### January — Kickoff
Somewhere between the first and second week of January, FIRST releases the new game. It's a global event — every team worldwide watches the same stream at the same moment. The reveal is theatrical, sometimes with a celebrity host or a surprise guest.
You get the game manual, the field specs, and six weeks on the clock. That's it. That's your season.
### Build Season — Six Weeks
This is the intense part. Most teams work nights and weekends. You design, prototype, fail, redesign, build, wire, program, test, break something, fix it, and repeat until you run out of time.
The last week before the build deadline is when the real crunch happens. The robot has to be bagged and tagged — no more work allowed after the deadline unless it's at a competition.
If that sounds stressful, it is. But it's also when you learn the most. There's no substitute for real pressure with real stakes.
### Competition Season
After bag day, you have a few weeks before your first event. Time to practice driving, refine autonomous routines, prepare your scouting system, and get the robot ready to ship.
Then: district events. Qualification matches, alliance selection, playoffs. You compete, you learn, you come back and fix things. Some teams go to two or three events before they're done.
### Off-Season
This is where real growth happens for most teams. No competition pressure. Time to train new members, fix the problems you identified during the season, redesign the things that didn't work, and get better at the skills that take time — machining, coding, driver practice.
Summer is also when most teams attend off-season events — competitions that don't count toward qualification but give you match experience in a lower-stakes environment. This is how good teams get great.
## How a Match Works
Every FRC match runs the same way:
### Autonomous Period — 15 Seconds
The robot runs pre-programmed instructions. No driver control. This is where good programming pays off — the robot has to make decisions and move without human input.
Autonomous is often the difference between winning and losing. A robot that can score during autonomous gives its alliance a head start that Teleop has to capitalize on.
### Teleoperated Period — 2 Minutes
The drivers take control. This is where human skill matters most — the driver, the manipulator, the human player, and whoever's calling the strategy from the stands.
During Teleop, alliances score points by completing game objectives. Scoring changes every year. Sometimes it's stacking cubes on a scale. Sometimes it's shooting balls into a goal. Sometimes it's climbing. Every year is different.
### End Game — Final 30 Seconds
Usually the hardest scoring objectives. The robots are trying to do things like climb, perch on a rung, or make last-second shots. This is where matches are decided — a good End Game can overcome a rough Teleop.
## The Point Isn't the Robot
Read this sentence twice: the robot is a means to an end.
You will spend hundreds of hours on this machine. You will miss sleep. You will argue with teammates about design decisions. You will have moments of pure frustration when nothing works.
And then you will have moments when everything clicks — when the code runs clean, when the mechanism works for the first time, when the driver pulls off a play you didn't think was possible.
The robot is the tool. The point is what you learn making it:
- How to solve problems when you don't have all the answers
- How to work with people who don't think like you
- How to fail and come back
- How to ask good questions
- How to finish something hard
If you leave this team knowing how to do those things, the robot did its job.
---
**Next:** [[2890-our-story|Hawk Collective 2890 — Our Story]]

71
training/modules/first-technical-resources.md
View File

@@ -1,71 +0,0 @@
---
type: training-material
domain: general
subdomain: canonical-resources
level: 1
tags: [first-inspires, technical-resources, cad, mechanical, prototyping, tools]
status: active
source: https://www.firstinspires.org/resources/library/frc/technical-resources
growth: tree
---
# FIRST Technical Resources — Official FRC Training Library
**Source:** https://www.firstinspires.org/resources/library/frc/technical-resources
**Authority:** Official FIRST Inspires resource library
**Purpose:** Canonical training references for FRC students and mentors
---
## Why This Matters
This is the official FIRST-endorsed training resource list. When 2890-claw doesn't have a specific training module, these are the go-to references. Think of it as the textbook spine for FRC education.
---
## Mechanical
- **Prototyping 101** — Core prototyping principles and methods
- **TCA Worksheets** — Mechanism design, manufacturing planning
- **Common Bolt Sizes Guide** — Reference for standard fasteners
- **Suggested Tools List** — What your team actually needs
- **NASA RAP Robotics Design Guide** — Design methodology from NASA
- **ReCalc** — Engineering calculators
- **AMB Robotics Calculator** — Specific robotics calculations
---
## CAD
- **Design 101** — Foundational CAD design principles
- **973 RAMP Videos** — Sketching and linkages (Team 973)
- **SOLIDWORKS Student Design Team Tools** — Official SOLIDWORKS resources
---
## Electrical
_(Full section available at source URL)_
---
## Programming
_(Full section available at source URL)_
---
## How to Use This in Training
1. **Level 1 students** → Start with Prototyping 101 and Suggested Tools
2. **CAD track** → Design 101 + 973 RAMP videos before anything else
3. **All tracks** → Bookmark this page as the canonical reference
4. **When unsure** → "What does FIRST's official resource say?" is always the right first question
---
**Note:** This page has multiple sections. Pull specific subsections as needed for curriculum building.

53
training/modules/fusion-360.md
View File

@@ -1,53 +0,0 @@
---
title: "Fusion 360 — CAD Training"
tags:
- training
- cad
- fusion360
- 2890
type: training-module
owner: 2890
status: active
sources:
- "https://www.youtube.com/watch?v=zmGbUH-P1lE&list=PLrZ2zKOtC_-C4rWfapgngoe9o2-ng8ZBr"
- "https://www.youtube.com/@ProductDesignOnline"
growth: tree
---
# Fusion 360 — CAD Training
## Team 2890 Standard
Team 2890 uses **Fusion 360** for all mechanical design work. Students are directed to these external resources:
**YouTube training path:**
- [Fusion 360 for Beginners playlist](https://www.youtube.com/watch?v=zmGbUH-P1lE&list=PLrZ2zKOtC_-C4rWfapgngoe9o2-ng8ZBr) — full beginner course
- [Product Design Online channel](https://www.youtube.com/@ProductDesignOnline) — comprehensive Fusion 360 content
## Student Context
- **Bruno** — had Mr. Silver's engineering class, decent Fusion skills
- **Riley** — strong CAD operator, team reference level
- Other students come in with no Fusion experience
## 2890-claw's Role
The wiki curriculum supplements the YouTube path — it doesn't replace it. Students work through Product Design Online at their own pace. 2890-claw handles:
- Answering real-time Fusion questions (specific stuck points)
- FRC-specific practice exercises (model a bracket, design a motor mount, create a Canjector enclosure)
- Filling gaps when external tutorials are confusing
- Helping students translate Fusion skills to competition parts
## Learning Path
1. **Sketching** → basic geometry, constraints, dimensions
2. **Part modeling** → extrude, revolve, fillet, chamfer
3. **Assemblies** → joint types, motion links, explode views
4. **FRC practice** → brackets, motor mounts, custom enclosures, Canjector cases
## Practice Exercises
Coming: FRC-specific Fusion exercises using Team 2890 parts.
*This module is a stub — expand as student questions come in.*

182
training/modules/gear-ratio-mechanism-design.md
View File

@@ -1,182 +0,0 @@
---
title: "Choosing Gear Ratios for FRC Mechanisms"
tags:
- gear ratio
- mechanism
- design
- motor
- torque
- speed
- frc
- 2890
type: training-module
owner: 2890
status: active
sources:
- "https://docs.wcproducts.com/frc-build-system/belts-chain-and-gears/gears"
- "https://www.frcdesign.org/learning-course/stage1/1B/torque-speed/"
- "https://blog.thebluealliance.com/2013/06/24/behind-the-design-understanding-motor-and-gearbox-design/"
growth: tree
---
# Choosing Gear Ratios for FRC Mechanisms
## Core Principle
**Speed and torque are inversely proportional.** A 4:1 gear reduction gives you 4× the torque but 1/4 the speed.
```
Gear Ratio = Driven Gear Teeth / Driver Gear Teeth
If ratio = 4:1 (input:output = 1:4):
Torque → multiplied by 4
Speed → divided by 4
```
## The Design Process
### Step 1: Define Your Goal
Ask these questions:
- What does this mechanism need to **do**?
- How **fast** does it need to move?
- How **heavy** is the load?
- What's the **time constraint** (game-specific)?
### Step 2: Calculate Required Output
For each mechanism:
- **Drivetrain** — Key metric: top speed. Typical: 10-15 ft/s
- **Elevator** — Key metric: lift speed. Typical: 3-6 ft/s
- **Arm** — Key metric: rotation speed. Typical: 90-180°/sec
- **Intake** — Key metric: roll speed. Typical: fast (1-2 sec)
- **Shooter** — Key metric: RPM. Typical: 3000-6000 RPM
### Step 3: Match Motor to Load
**NEO Vortex specs (Team 2890's standard):**
- Free speed: 6784 RPM
- Stall torque: 3.6 Nm (0.36 kg·m)
- Peak output: 640W
- Continuous (40A): ~375W
**Work backward from desired output speed:**
```
Required output speed = X RPM
↓
Account for mechanism reduction (belts, chains, gears)
↓
Calculate motor speed needed
↓
Find gear ratio
```
## Drivetrain Gear Ratio Selection (Team 2890)
Team 2890 uses **L1 and L3** on MK4i modules with NEO Vortex:
- **L1 (8.14:1)** — ~14.4 ft/s, lower torque. Use when high speed needed, less pushing.
- **L3 (6.12:1)** — ~12.8 ft/s, higher torque. Use when more pushing power, climbing.
**L1 = faster, less torque. L3 = slower, more torque.** Swap based on game demands. Field-swappable.
## Mechanism Design Guidelines
### Elevators / Vertical Motion
```
Motor → Belt reduction → Sprocket → Chain → Carriage
```
- Target: 3-6 ft/s vertical
- Common ratios: 4:1 to 10:1 per stage
- Watch for staging — two-stage elevators need compounding reduction
### Arms / Swing Motion
```
Motor → Gearbox → Arm
```
- Target: 90-180°/sec rotation
- Consider start-up torque (gravity fight at low angle)
- PID control essential for repeatable positioning
### Shooters / Flywheels
```
Motor → Gearbox → Wheel
```
- Target: 3000-6000 RPM wheel speed
- High reduction = more torque at wheel, faster spin-up
- Common ratio: 3:1 to 5:1
### Intake Rollers
```
Motor → Direct or light reduction → Roller
```
- Target: Fast roll-in (under 2 seconds)
- Low reduction or direct drive works
- Rubber roller = good grip, no gear reduction needed
## Motor Sizing Rules of Thumb
1. **Stall torque > Load torque at worst angle**
2. **Free speed > Desired output speed by 2× minimum**
3. **Current draw at stall < 80% of breaker rating**
4. **Continuous torque > Average load torque**
## Common FRC Motor/Gearbox Pairings
- **NEO Vortex** — Built-in 4:1, 1696 RPM output. Drivetrain, mechanisms.
- **NEO Vortex + planetary** — External reduction, variable output. Elevators, arms.
- **Falcon 500** — Integrated, 1680 RPM output. Drivetrain, high torque.
- **Kraken X60** — Integrated, ~1680 RPM output. Newer alternative to Falcon.
## The Calculation
```
Desired output RPM = X
Motor free RPM = 6784 (NEO Vortex)
Total reduction needed = 6784 / X
Example: Want 600 RPM output
6784 / 600 = 11.3:1 reduction needed
Split across stages:
Stage 1 (belt): 3:1
Stage 2 (gearbox): 4:1
Total = 12:1 — close to target
```
## Signs You've Got It Wrong
- **Too fast / not enough torque:** Robot stalls under load, wheels slip
- **Too slow / too much torque:** Mechanism moves too slowly to be useful
- **Motor overheating:** Too much load for continuous operation — need more reduction or bigger motor
- **Brownouts:** Current spikes from stalling — check breaker sizing
## For Team 2890 Students
When designing a mechanism:
1. **Define the task** — what does it need to do in the game?
2. **Pick the motor** — NEO Vortex is standard on 2890
3. **Calculate the speed you need** — game constraints (time limits, field size)
4. **Work backward** — gear ratio = motor speed / desired output speed
5. **Split across stages** — belt + gearbox is easier than single-stage high ratio
6. **Test and tune** — PID tuning can fix some speed issues, but wrong gear ratio can't be fixed with software
## Related
- [[swerve-modules]] — MK4i gear options for drivetrain
- [[neo-vortex-motor]] — motor specs
- [[spark-flex]] — controller configuration
- [[motor-basics]] — understanding motor curves
---
*Research from web search — gear ratio design for FRC mechanisms*
*Queue: research complete — stored in wiki*

114
training/modules/megatag.md
View File

@@ -1,114 +0,0 @@
---
title: "MegaTag — Robot Localization with AprilTags"
tags:
- megatag
- apriltag
- vision
- localization
- limelight
- photonvision
- odometry
- frc
- 2890
type: training-module
owner: 2890
status: active
sources:
- "https://docs.limelightvision.io/docs/docs-limelight/pipeline-apriltag/apriltag-robot-localization"
- "https://docs.yagsl.com/fundamentals/swerve-drive"
growth: tree
---
# MegaTag — Robot Localization with AprilTags
## What Is MegaTag?
MegaTag is a **Limelight-specific** robot localization system that uses AprilTags + IMU (gyro) data to determine the robot's position on the field. It's not a Limelight-only concept — similar approaches exist with PhotonVision + WPILib pose estimators — but "MegaTag" specifically refers to Limelight's implementation.
**Key point:** Team 2890 uses **PhotonVision**, not Limelight. MegaTag documentation is useful for understanding the **concept** of vision-based odometry fusion, but the implementation uses PhotonVision's pose estimator + WPILib's `SwerveDrivePoseEstimator`.
## MegaTag vs. MegaTag2
- **MegaTag 1** — AprilTag vision only. Good when tags visible, accumulates drift over time.
- **MegaTag 2** — AprilTag + IMU fusion. Gyro corrects drift, less sensitive to partial tag visibility.
**MegaTag 2** fuses robot orientation data from the IMU with vision pose. This means even if vision is slightly noisy or a tag is partially visible, the gyro steadies the reading.
## How It Works (Conceptual)
```
AprilTag camera → Robot pose (x, y, rotation)
↓
Gyro heading → Corrections / steadying
↓
Pose Estimator → Combines:
- Wheel odometry (always drifting)
- Vision pose (accurate but intermittent)
↓
Final robot position (fused)
```
## For Team 2890 (PhotonVision)
Team 2890 runs PhotonVision on Raspberry Pi, AprilTags on the field. The equivalent fusion happens in WPILib:
```java
// SwerveDrivePoseEstimator fuses:
// 1. Wheel odometry (always running, drifts)
// 2. Vision measurements (accurate when tags visible)
SwerveDrivePoseEstimator estimator = new SwerveDrivePoseEstimator(
kinematics,
gyro.getRotation2d(), // IMU heading
modulePositions, // wheel encoders
new Pose2d(x, y, rotation) // initial estimate
);
// Add vision measurement when tag visible:
estimator.addVisionMeasurement(
photonPoseEstimator.getEstimatedPosition(),
Timer.getFPGATimestamp()
);
```
## The Key Concept for Students
**Robot localization = knowing where you are on the field.**
AprilTags give you a reference point. The gyro gives you orientation. Fusing them gives you accurate, stable position tracking even when:
- Only one tag is visible
- Tags are partially obscured
- Robot is moving fast
This is critical for:
- Autonomous paths that need to return to same spot
- Field-relative driving with joystick
- Score estimation / match strategy
## Common Issues and Troubleshooting
- **Pose always offset in same direction** → Camera calibration wrong. Check camera tilt, height, direction.
- **Pose jumps when tag visible** → Vision trusting single reading. Add filtering, check timing.
- **No pose when tags visible** → Camera not processing tags. Check PhotonVision pipeline.
- **Odometry drifts despite vision** → Vision not being added to estimator. Check `addVisionMeasurement` call.
- **Gyro disagrees with vision** → Gyro calibration issue. Re-calibrate gyro, check wiring.
## Connection to Training
For students learning swerve odometry:
1. **Wheel odometry** — always tracking, always drifting
2. **Vision pose** — accurate when AprilTags visible
3. **Pose estimator** — fuses both for best of both worlds
4. **Field constants** — AprilTag positions, field dimensions must be correct
The MegaTag concept (vision + gyro fusion) is the same regardless of whether you use Limelight or PhotonVision. Understanding it helps students debug pose estimation issues.
## Related
- [[photonvision]] — Team 2890's vision system
- [[swerve-modules]] — MK4i with encoders for odometry
- [[systemcore]] — upcoming controller with improved processing
---
*Research from web search — MegaTag concept for FRC vision localization*
*Queue: research complete — stored in wiki*

67
training/modules/photonvision.md
View File

@@ -1,67 +0,0 @@
---
type: training-material
domain: programming
subdomain: vision
level: 2
tags: [photonvision, vision, apriltag, python, raspberry-pi]
prerequisites: [programming-level-1, electrical-level-1]
source: https://photonvision.org/
status: active
growth: tree
---
# PhotonVision — FRC Computer Vision
**Website:** https://photonvision.org/
**Purpose:** Free, fast, easy computer vision for FRC
## What It Is
PhotonVision is the largest FOSS FRC vision project. It runs on a coprocessor (Raspberry Pi 3/4, OrangePi 3, etc.) and handles:
- AprilTag detection and pose estimation
- Object detection (ML-based)
- Multi-camera support
- Driver mode integration
## Why We Use It
Team 2890 runs PhotonVision on **Mothman** for AprilTag detection. It's our primary vision system.
## Key Capabilities
- **AprilTag Tracking** — Out of the box FRC target support
- **Multi-Tag Pose** — Fuse all available data for peak accuracy
- **Camera Calibration** — Per-camera intrinsics maximize homography accuracy
- **ML Object Detection** — Hardware-accelerated inferencing for gamepieces
- **Driver Mode** — Same camera for driving and vision
- **Multi-Camera** — Run as many cameras as hardware supports
## Getting Started
1. Download PhotonVision image for your coprocessor
2. Flash to SD card
3. Connect to network — start tracking in minutes
4. Configure via web dashboard
## Connection to YAGSL
PhotonVision works alongside YAGSL (swerve). YAGSL handles drive control, PhotonVision handles vision targets.
## 2026 Champs Talk
PhotonVision 2026 presentation covers:
- Rubik Pi 3 hardware
- Object Detection with PhotonVision
- Slide deck coming soon
## In The Curriculum
This topic belongs in:
- **Programming Track → Level 2** (after basic Java/WPILib)
- **Vision Module** (Apriltag tracking, camera setup)
## Source
https://photonvision.org/

79
training/modules/systemcore.md
View File

@@ -1,79 +0,0 @@
---
type: training-material
domain: hardware
subdomain: control-system
level: 3
tags: [systemcore, roborio, control-system, hardware, programming]
prerequisites: [electrical-level-2, programming-level-1]
source: https://community.firstinspires.org/march-updates-on-the-future-robot-controller
status: upcoming
date: 2026-03
growth: tree
---
# SystemCore — Next-Gen FRC Robot Controller
**Status:** Upcoming (alpha testing later this year)
**Replaces:** roboRIO
**Source:** FIRST Community Blog, March 2026
---
## What Is SystemCore?
SystemCore is the new robot controller for FRC and FTC — the replacement for the aging roboRIO. It's a fundamental shift in the control system architecture.
> "SystemCore is the future robot controller designed to address the evolving needs of competitive robotics programs." — FIRST
## Hardware Specs
- ****Size**** — Large smartphone form factor
- ****CAN-FD**** — 5x CAN-FD ports
- ****SmartIO**** — 6x SmartIO (flexible analog/digital/PWM)
- ****I2C**** — 2x I2C ports
- ****USB**** — 4x USB 3.0, USB-C
- ****Ethernet**** — Yes
- ****RSL**** — Ring light connector
- ****WiFi**** — Integrated 2.4/5GHz
- ****IMU**** — Built-in IMU for odometry/localization
- ****AI**** — M.2 A+E port — Hailo-8 AI Accelerator compatible
## MotionCore
Companion motion controller for advanced motion control and sensing.
## Programming
**Limelight is building the web-based IDE** — Blockly, Java, and Python support.
This is a major shift: web-based IDE instead of VS Code / WPILib.
## Why This Matters for 2890
- Current students will transition from roboRIO to SystemCore
- Built-in IMU means no external gyro for odometry
- AI accelerator opens ML-based game piece detection
- New programming workflow with Limelight IDE
- Alpha testing begins later this year — curriculum needs to prepare
## Curriculum Path
When SystemCore releases:
1. **Hardware Overview** — Physical connections, compare to roboRIO
2. **SmartIO Configuration** — Flexible pin mapping
3. **CAN-FD vs CAN** — What changes
4. **Built-in IMU** — Odometry and localization without external gyro
5. **Limelight IDE** — New development workflow
6. **AI Integration** — Hailo-8 accelerator for object detection
## Status
- **Current:** Alpha testing
- **Expected:** Rollout TBD (monitor FIRST announcements)
- **Curriculum:** Track FIRST blogs for updates
---
**Monitor:** https://community.firstinspires.org/ for official FIRST announcements

352
training/modules/yagsl.md
View File

@@ -1,352 +0,0 @@
---
type: training-material
domain: programming
subdomain: swerve-drive
level: 2
tags: [yagsl, swerve, drivetrain, java, can, encoder, gyro, pid, autonomous]
prerequisites: [programming-level-1, electrical-level-1]
related: [swerve-training-hub, photonvision, systemcore]
source: https://docs.yagsl.com/
last_verified: 2026-05-15
freshness: seasonal
status: active
growth: tree
---
# YAGSL — Yet Another Generic Swerve Library
**Website:** <https://docs.yagsl.com/>
**GitHub:** <https://github.com/BroncBotz3481/YAGSL>
**Current Version:** 2025.8.0
**Team 2890 Usage:** Primary swerve drive library on Mothman
## What It Is
YAGSL (Yet Another Generic Swerve Library) is an open-source FRC library that lets you configure an entire swerve drivetrain through JSON files instead of writing custom Java code for each module. You describe your hardware in a few config files, and YAGSL generates the `SwerveDrive` object that handles kinematics, odometry, path following, and more.
The core idea: **one line of Java, a directory of JSON, and you have a working swerve drive.**
## Why We Use It
Team 2890 runs YAGSL on Mothman with SDS MK4i modules, NEO Vortex drive motors, SPARK Flex controllers, and CANcoders. YAGSL lets us swap hardware (different motors, different encoders, different gyros) by editing JSON instead of rewriting Java code.
**Advantages over rolling your own swerve code:**
- JSON config means hardware changes are data, not code changes
- Built-in support for PathPlanner autonomous integration
- Vision odometry integration (works with PhotonVision out of the box)
- Simulation support for testing without a robot
- Active community and frequent updates
## Hardware That YAGSL Supports
### Motor Controllers
- SPARK MAX / SPARK Flex (REV)
- Talon SRX / FX / FXv2 (CTRE)
- Victorian / Jaguar (legacy)
### Absolute Encoders
- CANcoder (CTRE)
- CANandmag (Redux)
- SparkMaxAnalog / SparkMaxAlternate / SparkMaxAttached (REV)
### Gyroscopes (IMU)
- Pigeon 2 (CTRE)
- NavX2 / NavX (Studica / Kauai Labs)
- ADIS16448 / ADIS16470 / ADXRS450 (Analog Devices)
- ADXL345 (WPILib built-in)
### Supported Motors
- NEO / NEO Vortex / NEO 550 (REV)
- Falcon 500 / Falcon 500 (v6) / Kraken X60 (CTRE)
- Brushed motors with external encoders (SparkMAX only)
## JSON Configuration Structure
YAGSL reads configuration from the `deploy/swerve/` directory in your WPILib project:
```
src/main/deploy/swerve/
swervedrive.json <- Main config (IMU, module list)
frontleft.json <- Module 1
frontright.json <- Module 2
backleft.json <- Module 3
backright.json <- Module 4
```
### swervedrive.json (Main Config)
```json
{
"imu": {
"type": "pigeon2",
"id": 13,
"canbus": "canivore"
},
"invertedIMU": true,
"modules": [
"frontleft.json",
"frontright.json",
"backleft.json",
"backright.json"
]
}
```
Key fields:
- `imu.type` — Your gyro model (pigeon2, navX, etc.)
- `imu.id` — CAN device ID
- `imu.canbus` — CAN bus name ("canivore" or null for rio bus)
- `invertedIMU` — Flip the gyro heading if your IMU is mounted upside down
- `modules` — List of module config files, clockwise from front-left
### Module JSON (e.g., frontleft.json)
```json
{
"drive": {
"type": "sparkflex",
"id": 2,
"canbus": null
},
"angle": {
"type": "sparkflex",
"id": 1,
"canbus": null
},
"encoder": {
"type": "cancoder",
"id": 10,
"canbus": null
},
"inverted": {
"drive": false,
"angle": false
},
"absoluteEncoderInverted": false,
"absoluteEncoderOffset": -50.977,
"location": {
"front": 12,
"left": -12
}
}
```
Key fields:
- `drive` / `angle` — Motor controller type and CAN ID
- `encoder` — Absolute encoder type and CAN ID
- `inverted` — Motor direction inversion (separate for drive and angle)
- `absoluteEncoderOffset` — CRITICAL: the angular offset to align the wheel forward (see below)
- `location` — Physical position of the module relative to robot center (inches)
## The Eight Steps of Bringing Up Swerve
YAGSL's docs recommend a specific order for first-time configuration. Follow these in sequence — do not skip steps:
1. **Install dependencies** — All vendor libraries (CTRE, REV, etc.)
2. **Check your gyroscope** — Verify it reads heading correctly
3. **Check your motors** — Verify CAN IDs and direction
4. **Create your configuration** — JSON files with correct device IDs
5. **Verify module locations** — Physical position matches config
6. **Tune drive PID** — Drive motor velocity PID
7. **Tune angle PID** — Steering motor angle PID
8. **Verify odometry** — Robot position tracks correctly
**Common mistake:** Trying to tune PID before verifying CAN IDs. Every wrong CAN ID causes cascading failures that look like PID problems but are actually configuration problems.
## Code Setup
### Dependency Installation (vendordep URLs for 2026)
Install these via WPILib's "Install vendor libraries" in VS Code:
- **YAGSL**: `https://broncbotz3481.github.io/YAGSL-Lib/yagsl/yagsl.json`
- **CTRE Phoenix 6**: `https://maven.ctr-electronics.com/release/com/ctre/phoenix6/latest/Phoenix6-replay-frc2026-latest.json`
- **CTRE Phoenix 5**: `https://maven.ctr-electronics.com/release/com/ctre/phoenix/Phoenix5-replay-frc2026-latest.json`
- **REVLib**: `https://software-metadata.revrobotics.com/REVLib-2026.json`
- **Studica (NavX)**: `https://dev.studica.com/maven/release/2026/json/Studica-2026.0.0.json`
- **MapleSim**: `https://shenzhen-robotics-alliance.github.io/maple-sim/vendordep/maple-sim.json`
**Important:** You MUST install ALL vendor dependencies even if you only use some of the devices. YAGSL is generic and compiles against all of them.
### Minimal Subsystem
```java
import edu.wpi.first.wpilibj.Files;
import edu.wpi.first.wpilibj2.command.SubsystemBase;
import swervelib.SwerveDrive;
import java.io.File;
public class SwerveSubsystem extends SubsystemBase {
private final SwerveDrive swerveDrive;
public SwerveSubsystem() {
swerveDrive = new SwerveDrive(
new File(Filesystem.getDeployDirectory(), "swerve")
);
}
public SwerveDrive getSwerveDrive() {
return swerveDrive;
}
}
```
That's it. The JSON config files do the heavy lifting.
### Driving the Robot
```java
// In your RobotContainer:
new Joystick(driverJoystick, 0); // Xbox or flight stick
// Map joystick axes to drive commands:
swerveSubsystem.setDefaultCommand(
new RunCommand(
() -> swerveDrive.drive(
// X, Y, rotation — WPILib ChassisSpeeds or raw values
joystick.getLeftY(), // Forward/back
joystick.getLeftX(), // Left/right
joystick.getRightX(), // Rotation
true // Field-relative?
),
swerveSubsystem
)
);
```
## Encoder Offsets — The Most Important Number
The `absoluteEncoderOffset` in each module JSON is the single most critical configuration value. It tells the steering motor where "forward" is for that wheel.
### How to Find Your Offset
1. **Align all wheels physically forward** — Point every wheel straight ahead
2. **Read the raw encoder value** from SmartDashboard or ShuffleBoard
3. **Negate that value** — That's your offset
4. **Put it in the module JSON** as `absoluteEncoderOffset`
Example: If the raw encoder reads `149.06`, the offset is `-149.06`.
**Pitfall:** Offsets change if you physically move the encoder gear or swap modules. Re-verify after any hardware change.
**2026 Note:** The `pushOffsetsToEncoders` and `restoreInternalOffset` methods are deprecated in YAGSL 2026+. Offsets should be set in the JSON config and left alone.
## PID Tuning
YAGSL has two PID loops per module: one for drive velocity, one for steering angle.
### Angle (Steering) PID
- Start with just P gain
- The steering motor wraps at 180°/-180°, so test with lateral (left/right) translation, not just forward
- Typical starting P: 0.5-2.0 depending on module
- If the wheel oscillates around target, P is too high
- Add D if the wheel overshoots and rings
### Drive PID
- Tune for velocity, not position
- Start with just P (try 0.1)
- Use ShuffleBoard or FRC Web Components to see actual vs commanded velocity
- Feedforward is important here — YAGSL supports kS, kV, kA
**Test order:** Always tune angle PID before drive PID. A mis-steered module gives garbage drive data.
## Inversion — When to Invert
The most common YAGSL problem is wrong motor inversion. The docs have a dedicated flowchart (see "When to Invert?"), but the rules are:
- `drive` inversion: Flip if the wheel spins backward when commanded forward
- `angle` inversion: Flip if the steering turns the wrong direction
- `absoluteEncoderInverted`: Flip if the encoder reads backwards
- `invertedIMU`: Flip if the gyro reads heading opposite to expected
**Test method:** Drive forward with ShuffleBoard open. If any wheel spins backward, flip its drive inversion. If any wheel turns the wrong way, flip its angle inversion.
## PathPlanner Integration
YAGSL integrates with PathPlanner for autonomous path following:
```java
// Create auto builder from SwerveDrive
AutoBuilder.configure(
swerveDrive::getPose, // Robot pose supplier
swerveDrive::resetOdometry, // Reset pose
swerveDrive::getRobotVelocity, // Robot velocity
swerveDrive::drive, // Drive consumption
new PPHolonomicDriveController( // Holonomic path follower
new PIDConstants(5.0, 0.0, 0.0), // Translation PID
new PIDConstants(5.0, 0.0, 0.0) // Rotation PID
),
swerveDrive.getSwerveDriveConfiguration(), // Config
() -> { /* alliance supplier */ },
this // Subsystem
);
```
## Vision Odometry
YAGSL can fuse vision measurements into odometry. This is how PhotonVision AprilTag data improves your robot's field position:
```java
// Add a vision measurement (from PhotonVision, Limelight, etc.)
swerveDrive.addVisionMeasurement(
new Pose2d(3, 3, Rotation2d.fromDegrees(65)),
Timer.getFPGATimestamp()
);
```
See [[photonvision]] for the full AprilTag pipeline.
## Debugging Tools
- **FRC Web Components** — Real-time swerve visualization widget. Connects to SmartDashboard/swerve. Blue lines = measured, shows each module's velocity and position
- **AdvantageScope** — Log viewer and swerve visualization
- **YAGSL Config Generator** — <https://github.com/BroncBotz3481/YAGSL-Example> includes example configs for common hardware combos
- **ShuffleBoard** — Standard WPILib dashboard, shows raw encoder values
## Common Problems
- **Wheel spins backward** → `inverted.drive` is wrong. Flip the boolean.
- **Wheel steers wrong direction** → `inverted.angle` is wrong. Flip the boolean.
- **Robot drifts while driving straight** → Encoder offset wrong, or angle PID not tuned. Re-verify offsets, then tune angle PID.
- **Robot won't go straight on its own** → No heading correction enabled. Use `swerveDrive.setHeadingCorrection(true)`.
- **"Invalid year" vendordep error** → YAGSL JSON has wrong FRC year. Update vendordep URL to current year.
- **Modules don't align on startup** → Offset not set or wrong CAN ID. Verify offsets and CAN IDs.
- **Odometry doesn't match field** → Module physical positions in JSON are wrong. Re-measure and update `location` fields.
## 2026 Migration Notes
- `pushOffsetsToEncoders` and `restoreInternalOffset` are deprecated — set offsets in JSON only
- YAGSL vendordep year must match WPILib year (2025 JSON → 2026 build = error)
- Update all vendor dependencies to 2026 versions simultaneously
- Check the Chief Delphi thread for YAGSL 2026 plans and ongoing beta testing
## Practice Exercises
### Level 1 — Configuration
1. Create a minimal YAGSL project from the example repo
2. Identify every CAN device on your robot and write down the IDs
3. Fill in the `swervedrive.json` and module JSON files with your hardware
### Level 2 — Bring-Up
4. Verify each motor responds to the correct CAN ID (use ShuffleBoard)
5. Find encoder offsets for all four modules
6. Tune angle PID until all four modules hold their target position
7. Drive the robot in teleop and verify field-relative control
### Level 3 — Advanced
8. Set up PathPlanner with a simple auto path
9. Add PhotonVision AprilTag pose estimation to YAGSL odometry
10. Configure simulation and test autonomous paths in sim
## Resources
- **Official Docs:** <https://docs.yagsl.com/>
- **YAGSL Example Project:** <https://github.com/BroncBotz3481/YAGSL-Example>
- **Chief Delphi Discussion:** <https://www.chiefdelphi.com/t/yagsl-2025-feedback-and-2026-plans/501479>
- **SDS MK4i Documentation:** <https://www.sweredrivespecialties.com/products/mk4i>
- **Team 2890 Swerve Hub:** [[swerve-training-hub]]
---
*Module maintained by 2890-claw. Last verified 2026-05-15 against YAGSL 2025.8.0 docs.*

210
training/modules/youth-safety.md
View File

@@ -1,210 +0,0 @@
---
title: "Youth Safety"
tags:
- onboarding
- safety
- conduct
- youth-protection
- required
type: training-module
track: entry
owner: 2890
growth: tree
---
# Youth Safety
> Read this before you touch anything in the shop. This is not optional.
## Why This Matters
The robotics shop has real tools. Saws, lathes, grinders, welders, batteries that can start fires if you treat them wrong. The work here is exciting and hands-on — and it will hurt you if you don't respect it.
Safety isn't about following rules because someone told you to. It's about not getting hurt. That's it.
I've seen students rush through something because they wanted to get it done, skip a step because it seemed minor, and end up in the emergency room. Not at this team — I've never seen it happen here. But I've seen near-misses that should have been warnings.
The rules in this document exist because someone, somewhere, got hurt doing what you're about to do. Learn from their experience, not your own.
## Workshop Safety — The Non-Negotiables
These are not suggestions. These are how you stay in one piece.
- **Safety glasses on.** Always. Not when you remember, not when it's just a quick cut — always. A particle in your eye will ruin your day permanently.
- **Closed-toe shoes.** No exceptions in the shop. Flip-flops and sandals are for the beach, not the machine shop.
- **No working alone.** Every tool operation needs a second person nearby. If you're using a power tool, someone else should be in the shop with you, watching, not just in the building.
- **Hair tied back.** Loose hair catches in lathes and drill presses. It's an easy fix — ponytail, bun, whatever works.
- **Gloves only when appropriate.** Not on rotating tools. Gloves can catch on a spinning shaft and pull your hand in. Use gloves for welding, for handling rough materials, for moving heavy things — not for anything with a spinning blade or bit.
## Tool-Specific Rules
Every tool in this shop can hurt you if you don't know what you're doing. Here's what you need to know about the ones you'll use most.
### Lathe
A lathe spins your workpiece while you cut into it with a stationary tool. Used for making round parts, cylinders, threads.
**What kills people on lathes:** loose clothing, rings, or watches catching on the spinning stock; holding the workpiece by hand instead of clamping it; reaching across the spinning chuck.
**Rules:**
- No loose clothing, no rings, no watches, no bracelets. Long sleeves must be fitted at the wrist.
- Always clamp your workpiece. Never hold it by hand while the lathe is running.
- Let the tool do the work. Forcing the cutting tool causes chatter, bad parts, and broken tools.
- If something sounds wrong — a chatter sound, a vibration that isn't normal — stop the machine and check before continuing.
### Mill
A mill holds a cutting tool in a spindle and moves it into your workpiece, which is clamped to a table. Used for flat surfaces, slots, holes, and more complex shapes.
**What kills people on mills:** the spinning endmill catching loose material or clothing; improperly clamped workpieces being thrown by the cutting force; touching the cutting tool while it's still spinning.
**Rules:**
- Secure your workpiece to the table with clamps or a vise before you start. Never rely on the friction of the table alone.
- Bring the cutter down to the workpiece slowly. Use the rapid override carefully near the material.
- Let the chip escape. Accumulated chips are hot and can burn. Use a brush or chip hook to clear them, not your fingers.
- After cutting, let the spindle stop completely before adjusting anything or clearing chips.
### Drill Press
A drill press holds a drill bit and pushes it down into a clamped workpiece. More precise than a hand drill.
**What kills people on drill presses:** clothing or hair catching on the drill chuck; holding the workpiece by hand instead of clamping it; using too much pressure and breaking the bit.
**Rules:**
- Clamp your workpiece to the table. Never hold it with your hand.
- Long hair must be tied back. A drill press grabs hair just as easily as a lathe.
- Use the correct speed for the material and bit size. The drill press speed chart is on the wall by the machine.
### Welder (MIG)
Welding joins metal by melting it with an electric arc and fusing it together. We use MIG welding (Metal Inert Gas), which feeds wire through the gun and uses a shielding gas to protect the weld from contamination.
**What kills people with welders:** eye damage from the arc flash; burns from hot metal; fumes from welding galvanized or painted metal; fire from sparks landing on flammable material.
**Rules:**
- Welding helmet on *before* you strike the arc. Off only after the last weld is complete and cooled.
- Wear leather gloves, long sleeves, and a closed collar. Sparks go everywhere.
- Fire extinguisher must be within reach before you start. Know where it is.
- Ventilation matters. Welding produces fumes that will make you sick if you breathe enough of them. If the space doesn't have good airflow, don't weld until it does.
- Inspect your equipment before every use: wire spool, ground clamp, cable condition. Damaged equipment doesn't just fail — it can catch fire.
### Angle Grinder
A grinder spins a disc at high speed for cutting or grinding metal. The disc is fragile and can shatter if damaged or misused.
**What kills people with angle grinders:** a cracked or damaged disc exploding at high RPM; the disc grabbing and kicking the tool; sparks igniting flammable material.
**Rules:**
- Inspect the disc before you turn the grinder on. Look for cracks, chips, anything that doesn't look right. If in doubt, don't use it.
- The guard must be in place. It routes sparks away from you.
- Hold the grinder with two hands. If it kicks, you want control.
- Face the grinder away from your body and away from anyone else in the line of fire.
- Let the disc reach full speed before you touch it to the material. If it sounds wrong, stop and check.
### Band Saw
A band saw has a continuous toothed blade that runs between two wheels. Used for cutting metal stock to length, curved cuts, and more.
**What kills people on band saws:** reaching across the blade while it's running; removing cutoffs before the blade has stopped; using the wrong blade tension or speed for the material.
**Rules:**
- Never reach over the blade. Ever. Even if it's a small piece.
- Let the blade come to a complete stop before adjusting the workpiece, changing the blade guide, or removing the cutoff.
- Remove cutoffs with a push stick or a piece of scrap wood. Not with your fingers. The piece gets hot, and your fingers are in the path of the blade if it slips.
## Electrical Safety
FRC robots run on **12V lead acid batteries** and powerful motors that draw significant current. A fully charged battery can deliver enough current to cause serious burns and start fires if shorted across metal tools.
### Battery Rules
- **Never touch both terminals with metal at the same time.** A wrench or screwdriver across both terminals = instant short = severe burns and possible fire. This is not hypothetical. This has injured FRC students.
- **Check the battery case for cracks or leaks before you use it.** If the case is damaged, do not charge or use it. Take it to a mentor and tell them.
- **Charge in a safe area.** Nothing flammable nearby. The charger can produce heat.
- **Transport upright.** Lead acid batteries can leak acid if tipped. Keep them upright always.
- **Keep terminals covered.** When a battery is not in use, keep the terminal covers on to prevent accidental shorts.
### When the Robot is Powered
- **No working on electrical systems while the robot is powered.** This means disconnect the battery before you touch anything in the electrical bay. Not "be careful" — disconnect.
- If you need to test something with power, tell a mentor and make sure you're using proper technique.
- **If you smell burning — burning plastic, burning metal, anything wrong — disconnect the battery immediately, step back, and tell a mentor.** Do not continue. Do not assume it'll be fine.
- 12V can also charge capacitors that hold charge after the battery is disconnected. If you're working on high-capacitance circuits, discharge them before touching.
## FIRST Youth Protection
FIRST requires all teams to follow Youth Protection guidelines. These are non-negotiable.
### Two-Deep Leadership
No adult is alone with a student. Ever. If a mentor asks you to stay after a meeting one-on-one, if an adult is regularly messaging you on a private channel, if someone you barely know wants to spend time alone with you — that's not normal. Tell Mr. Slater or a mentor you trust. You will be heard. Nothing you report will get you in trouble for reporting it.
### Background Checks
Every adult who works with students on this team has a current background check on file. If you see a new adult in the shop working with students and you don't recognize them, it's okay to ask if they're on the roster. You have a right to know.
### Communication
Students and mentors communicate in shared team channels. Nobody should be in a private DM relationship with a mentor that nobody else can see. If you get a message that feels wrong — even if you can't explain exactly why — tell someone.
### The Rule
> If something feels wrong, it probably is. Say something.
You will never get in trouble for reporting something. You might get in trouble if you knew something was wrong and stayed quiet.
## Online Conduct
Our team communicates through Discord. This is a professional space, not a gaming chat.
**Be respectful.** What you say here represents the team. Don't forget that other teams, sponsors, and members of the public can see what you post in public channels.
**No harassment, slurs, or targeted cruelty.** Zero tolerance. This includes jokes that aren't jokes, comments about someone's identity or background, and anything that makes another team member feel unsafe.
**No sharing personal information** about yourself or others in public channels. Your real name, your address, your phone number, other people's names — keep it in the team space.
**Keep it on topic in each channel.** #build-chat is for building. #programming is for code. General is for things that don't fit elsewhere.
Violations don't get warnings. They get consequences.
## Consequences
- **Minor mistake, nobody hurt** — We talk about it. You learn.
- **Repeated minor mistakes** — One-on-one. Parents notified.
- **Dangerous behavior** — Removed from the shop until a safety review.
- **Intentional harm or harassment** — Removed from the team. No debate.
Mr. Slater makes the call on anything beyond minor. But the point of consequences isn't punishment — it's so everyone goes home in the same condition they arrived.
## When You're Not Sure — Stop and Ask
This is the most important sentence in this document:
> If you don't know how to do something safely, **do not guess**. Ask.
A mentor, a senior student, Mr. Slater — it doesn't matter who. "How do I set up this piece in the mill?" is not a stupid question. "I didn't ask and now my hand is hurt because I assumed I knew what I was doing" is a stupid thing to explain to an urgent care nurse.
You will not be judged for not knowing something. You will be judged for not asking.
## Pre-Shop Checklist
Before you touch any tool in the shop, make sure you can answer yes to all seven of these:
- [ ] Safety glasses on
- [ ] Closed-toe shoes
- [ ] Hair tied back (if applicable)
- [ ] A mentor or senior student is in the shop with you
- [ ] You know where the first aid kit is
- [ ] You know where the fire extinguisher is
- [ ] Someone has shown you how to use this tool — not just told you, shown you
If you're not sure about any of these, ask before you start.
---
**Previous:** [[2890-our-story|Hawk Collective 2890 — Our Story]]
**Next:** Complete the Entry Path — you have finished the required onboarding for Hawk Collective 2890. The garden branches from here.

69
training/pathways/entry-path.md
View File

@@ -1,69 +0,0 @@
---
title: "Entry Path — Everyone Starts Here"
tags:
- pathway
- entry
- onboarding
- required
type: training-pathway
track: entry
owner: 2890
growth: tree
---
# Entry Path — Everyone Starts Here
> **Required for all team members.** No exceptions. Read in order.
---
Welcome to Hawk Collective 2890.
Before you touch a tool, write a line of code, or step into the shop — walk this path. It doesn't matter if you're a freshman who's never seen a robot or a senior who's been doing this for years. These three stones are for you.
They'll tell you what FIRST is, who we are, and how we stay safe.
---
## Stone 1 — [[first-robotics-overview|FIRST Robotics — The Big Picture]]
What is FIRST? Why does it exist? What do the competitions look like? How does the season work?
Start here to understand the world this team lives in.
---
## Stone 2 — [[2890-our-story|Hawk Collective 2890 — Our Story]]
Who are we? How did we get here? How are we organized? What do we actually believe?
This is the team you're joining. Know it before you help build it.
---
## Stone 3 — [[youth-safety|Youth Safety]]
Required reading. Shop safety, electrical safety, online conduct, FIRST Youth Protection.
Read this before you touch anything in the shop. Keep reading it until the rules aren't rules anymore — they're just how you operate.
---
## After You Finish
You've completed the Entry Path. You've earned the right to call yourself part of the team — not because you read some pages, but because you took the time to understand what you're part of.
From here, the garden branches. Your role, your interests, your questions — they guide you from here.
- Building? → [[swerve-training-hub|Swerve Training Hub]]
- Programming? → [[2890-codebase-index|Codebase Index]]
- Electrical? → [[power-distribution-hub|Power Distribution Hub]]
- Something else? → Browse the [[training-hubs|Training Hubs]]
Or keep wandering. The paths cross.
---
*Entry Path — required onboarding for all team members*
*Voice: Young Alumni / Senior Student*
*Status: Active*

118
training/pathways/index.md
View File

@@ -1,118 +0,0 @@
---
type: training-pathway
date: 2026-05-03
growth: tree
---
# 2890 Training Pathways
## Overview
The Hawk Collective uses a badge-based training system with three tracks. Each track has 3 levels. Completing a level earns a badge.
---
## The Three Tracks
- **Electrical** — Component ID → Board build + signaling → Troubleshooting
- **Mechanical** — Chassis + actuators → Advanced mechanisms
- **Pneumatics** — Component ID → System design
---
## Electrical Track
### Level 1 — Electronic Technician 1
**Goal:** Identify components, understand wire gauge, understand circuits
**What you learn:**
- Names of all electrical components (Battery, PDB, Main Breaker, PCM, Radio, etc.)
- Wire gauge basics (AWG 6 = thick/power, AWG 14 = thin/control)
- Complete circuit = two wires (positive + negative)
- Motor controller types (Talon SRX, Victor SP, etc.)
**Badge earned:** Electronic Technician 1
**What's next:** Level 2 — build a complete board, learn signaling protocols, crimping, soldering
### Level 2 — Electronic Technician 2
**Goal:** Build boards, understand signaling, demonstrate hands-on skills
**What you learn:**
- Signaling protocols (CAN vs PWM)
- How to assemble a complete board including PCM
- Crimping skills
- Soldering skills
- Team-approved connector systems
**Badge earned:** Electronic Technician 2
**Prerequisite:** Level 1
### Level 3 — Electrical Level 3
**Goal:** Troubleshooting
**What you learn:** Advanced electrical troubleshooting, circuit diagnosis
**Badge earned:** Electrical Level 3
---
## Mechanical Track
### Level 1 — Mechanical 1
**Goal:** Chassis and actuators, core mechanical knowledge
**Badge earned:** Mechanical 1
### Level 2 — Mechanical 2
**Goal:** Advanced mechanisms
**Badge earned:** Mechanical 2
**Prerequisite:** Level 1
### Level 3 — Mechanical Level 3
**Goal:** Advanced mechanical problem-solving
**Badge earned:** Mechanical Level 3
---
## Pneumatics Track
### Level 1 — Pneumatics 1
**Goal:** Identify pneumatic components
**Badge earned:** Pneumatics 1
### Level 2 — Pneumatics 2
**Goal:** System design
**Badge earned:** Pneumatics 2
**Prerequisite:** Level 1
---
## Cross-Track Requirements
Some achievements overlap between tracks. This is **intentional** — team members should understand how the subsystems connect.
---
## How 2890-claw Tracks Progress
I maintain a student profile for each team member. The profile tracks:
- Current level in each track
- Badges earned
- Next recommended step
- Last activity
When a student asks a question, I check their profile and route them to the appropriate level.
---
## For Students
Ask 2890-claw: "What level am I on?" or "What should I work on next?"

107
training/recommendations.md
View File

@@ -1,107 +0,0 @@
---
type: training-recommendations
date: 2026-05-03
growth: sprout
---
# Training Recommendation Engine
## How It Works
2890-claw generates recommendations based on:
1. What the student is currently working on (from board/asks)
2. What level they're at in each track
3. What gaps their tasks imply
---
## Recommendation Logic
### If working on electrical tasks → Electrical Level 1 or 2
- **battery, wiring, PDB, breaker** → Electrical Level 1
- **board build, PCM, CAN, PWM, crimping** → Electrical Level 2
- **troubleshooting, diagnosis** → Electrical Level 3
### If working on mechanical tasks → Mechanical Level 1 or 2
- **chassis, actuator, drive** → Mechanical Level 1
- **advanced mechanisms** → Mechanical Level 2
### If working on pneumatic tasks → Pneumatics Level 1 or 2
- **compressor, tank, solenoid, cylinder** → Pneumatics Level 1
- **system design** → Pneumatics Level 2
---
## Level Completion Criteria
### Electrical Level 1
- [ ] Can identify Battery, PDB, Main Breaker, PCM, Radio, Motor Controllers
- [ ] Understands wire gauge (AWG 6 = thick, AWG 14 = thin)
- [ ] Understands complete circuit = positive + negative wire
- [ ] Passed Electrical Level 1 test
### Electrical Level 2
- [ ] Can build a complete board with PCM
- [ ] Understands CAN vs PWM signaling
- [ ] Demonstrated crimping skills
- [ ] Demonstrated soldering skills
- [ ] Passed Electrical Level 2 test
### Mechanical Level 1
- [ ] Understands chassis fundamentals
- [ ] Can identify actuators
- [ ] Passed Mechanical Level 1 test
### Pneumatics Level 1
- [ ] Can identify all pneumatic components
- [ ] Understands how air pressure works in the system
- [ ] Passed Pneumatics Level 1 test
---
## Completions and Notifications
### When a Student Says "I Finished X"
1. Log the completion in their profile (Completions Log table)
2. If it matches a training level → update their level status
3. If it completes a badge requirement → announce: "[Name] earned the [Badge Name] badge!"
4. Recommend the next logical step
### When a Student Mentions a Badge
1. Add to Achievements Earned table in their profile
2. Include date and any notes
### 2890-claw Notification Triggers
- **Student earns first badge** → Announce: "[Name] just earned [Badge]!"
- **Student completes a level** → Announce: "[Name] is now Level [N] in [Track]!"
- **Student stuck on related task** → Surface gap: "[Name] working on [task] but hasn't started [recommended level]"
## For 2890-claw: How to Route Questions
When a student asks "what should I work on?":
1. Check their profile in `/entities/students/[name].md`
2. Look at their current task tags
3. Match tags to recommended level above
4. Tell them the next logical step
When a student asks a question they don't know:
1. Check if the answer is in the training slides
2. If yes → give the answer + "you're ready for Level X"
3. If no → gap-fill inline and create wiki content for it
---
## 2890-claw's Role
2890-claw monitors:
- Student questions that come through Discord
- Board activity for task gaps
- Ferry system for knowledge delivery
2890-claw delivers:
- Personalized next-step recommendations
- Training material answers
- Gap surfacing when students hit blockers
- Auto-builds missing wiki modules when gaps are detected

29
training/requests/20260515-frc-game-manual-update.md
View File

@@ -1,29 +0,0 @@
---
type: update-request
software: "FRC Game Manual"
old_version: "2026-REBUILT"
new_version: "unknown"
date: 20260515
status: pending
priority: high
---
# Update Request: FRC Game Manual
New version or content change detected.
- **Previous version:** 2026-REBUILT
- **New version:** unknown
- **Change:** No wiki module exists yet — create one
- **Source:** https://www.firstinspires.org/resource-library/frc/game-and-season-info
## Wiki Module
No wiki module exists yet — create one
## Instructions for Claw
1. Check the release notes/changelog at the source URL
2. Update the wiki module with new features, API changes, or breaking changes
3. If this is a major version bump, ensure prerequisites are still accurate
4. Mark this request as fulfilled in frontmatter when done

29
training/requests/20260515-wpilib-update.md
View File

@@ -1,29 +0,0 @@
---
type: update-request
software: "WPILib"
old_version: "v2026.2.1"
new_version: "unknown"
date: 20260515
status: pending
priority: high
---
# Update Request: WPILib
New version or content change detected.
- **Previous version:** v2026.2.1
- **New version:** unknown
- **Change:** No wiki module exists yet — create one
- **Source:** https://github.com/wpilibsuite/allwpilib/releases
## Wiki Module
No wiki module exists yet — create one
## Instructions for Claw
1. Check the release notes/changelog at the source URL
2. Update the wiki module with new features, API changes, or breaking changes
3. If this is a major version bump, ensure prerequisites are still accurate
4. Mark this request as fulfilled in frontmatter when done

32
training/requests/20260515-yagsl-update.md
View File

@@ -1,32 +0,0 @@
---
type: update-request
software: "YAGSL"
old_version: "2025.0.14"
new_version: "2025.8.0"
date: 20260515
status: fulfilled
priority: high
fulfilled_date: 2026-05-15
fulfilled_module: training/modules/yagsl.md
---
# Update Request: YAGSL
New version or content change detected.
- **Previous version:** 2025.0.14
- **New version:** 2025.8.0
- **Change:** No wiki module existed — created one
- **Source:** https://github.com/BroncBotz3481/YAGSL/releases
## Wiki Module
Created: `training/modules/yagsl.md`
- Full training module covering YAGSL fundamentals, JSON configuration, encoder offsets, PID tuning, PathPlanner integration, vision odometry, debugging tools, and 2026 migration notes
- Includes three levels of practice exercises (Configuration, Bring-Up, Advanced)
- Cross-linked to swerve training hub, photonvision, and systemcore modules
## Instructions for Claw
FULFILLED — module created and update-tracker.yaml updated.