Titan Robotics is excited to announce that we are starting a build blog this year! We’re a new addition to the Open Alliance and are keen to share our process with the community, as well as learn from others.
Links:
Programming/Software: Github
CAD: (Coming Soon)
We’ll have an update on our pre-season projects and plans up soon!
With strength and well wishes, Titans together 
TEAM INFO:
Our School:
Illinois Mathematics and Science Academy (IMSA), is a 3-year (10, 11, 12) public high school with a goal to develop creative, ethical leaders in STEM. IMSA is a part of the IL higher education system (think: colleges), making finances more difficult for our team relative to others in our area. Students apply to attend IMSA, and we have a student population of ~650. All students are from all over the state and live on campus, which has caused challenges over breaks, especially spring break. However, we are not without ideas for these problems and have been working with our mentors and other IMSA admin to find solutions to these issues.
Who We Are:
Our team is made up of ~60 students from our IMSA. We are a student-run and student-led team, meaning students do (almost) everything, from finding sponsors to teaching other team members. We do have (greatly appreciated) adult mentors as well, who impart their experience and handle administrative tasks (such as ordering parts). Our mission statement is: “FRC Team 2022, Titan Robotics, strives to create a sustainable, independent, and diverse team that develops students’ passion for STEM by strengthening organizational, technical, and entrepreneurial skills and conducting significant outreach to underserved areas.”
This year, we will be competing in the Midwest Regional and the Central IL Regional.
After the game reveal, IMSA has something called Intersession. This is a 2-week long time where IMSA students participate in sessions separate from normal coursework. For robotics, this means we can build for 8+ hours a day, and call it schoolwork!
Team Structure:
We have 2 main subteams to our team, Operations and Technical. Underneath these, are our sub-subteams (see picture below). All of these subteams are headed by a student, who was chosen by the previous season’s subteam head (or was the previous season’s head). We call these student leaders the board. Below, you can see a diagram of our team organization, along with this year’s subteam head. Team members are welcome to participate in multiple subteams, as long as they balance their academics and other commitments as well.
As part of our first day together as a team, we organized a Must-Should-Can table which listed our major strategic priorities. The “Must” column is what would bring us the most advantage in a regional, considering factors such as time and reliability. The “Should” column is the aspects that would significantly improve our competition robot but have a lower reward for more difficulty or potential sacrifices. The “Can” column is what we considered to be least feasible due to either time or complexity constraints.
As amplified speaker points are worth significantly more, we decided that scoring into the Amp would bring more advantage to the alliance, especially if the other teams would focus on shooters. Since it would be ideal to end with two staged robots, climb also became our major priority. We decided not to go for the trap as it lives up to its name.
The ground intake is also prioritized as it would increase our cycle times by cutting distance. As much as it would be difficult to implement, the robot would be able to take advantage of what other teams likely won’t. This year the Note shape seems to be an easier shape to intake as it is symmetrical and only has a single potential orientation. On the other hand, intaking from source directly would be redundant and would add more complexity to the bot.
Intersession Structure and Organization
During the first half of today’s intersession, our team members brainstormed and prototyped possible subsystems. We’re considering either an over-the-bumper or under-the-bumper intake, and below is a video of a rough prototype of an under-the-bumper design. We’ve also been testing flywheels for a shooter, though prototyping is in the early stages.
Video of proof of concept under-the-bumper intake
During the second half, we implemented a spreadsheet to keep track of the subsystems being prototyped and what progress was being made on them. I’ll link a template below. This spreadsheet allows us as a student board to know where subteams are in progress, without constantly interrupting them while they are prototyping (which we found bothersome last year).
Titan Robotics Intersession Subsystem and Tasks Organization Template
CAD link (via Bild): CAD Link
Videos of protoype testing and other nerdy things from #2022: Playlist Link
Our team’s been hard at work the past few days… and so has the weather 
. We’ve been prototyping and started to CAD some designs.
Shooter Designs:
Belt Shooter:
This design is intended to shoot into the speaker. It uses polybelts instead of timing belts, as polybelts have more grip on the note. It sadly does not shoot too far, even during testing at multiple angles and with a motor running at different speeds. We hope to improve this design, though other shooter designs seem more promising.
Compliant Wheel Shooter:
This design uses 4-inch green 35A compliant wheels. It does shoot far, but the note did wobble during our testing, which is an issue we will attempt to solve once we are back in the lab (snow days, huh). We also hope to test this design for shooter accuracy.
Integrated 4-bar Shooter (named Mark):
Mark!
^ Mark shooting amp
This shooter was originally designed to shoot into the speaker. However, by adding a panel over the upper wheels, it can shoot into the amp when close, while still maintaining the ability to shoot into the speaker. The grey wheels are also a part of an intake design, but that portion of this prototype has not been tested yet. Similar to the compliant wheel shooter, we hope to test this design for accuracy once we are back in the lab. You can find more videos of testing this shooter (including slo-mo shots) in the playlist linked at the top of this post.
Horizontal Flywheel Shooter:
We’ve been testing a one-sided horizontal flywheel shooter, and are considering a design similar to the one we CADded above. The one-sided flywheel has some testing issues, as the wheels were set too close to the plate beneath it, leading to the note flying up and out whenever we attempted to shoot. We’re hoping to adjust the current one-sided prototype to solve this issue and add another side to test the idea CADded out above.
Climb Mechanism:
We are planning on using two pistons on the side of our bot with hooks similar to the one shown in the video above to climb on the chain. We need to make sure our bot does not slip down the chain, leaving room for other bots to climb onto the same chain. Hence, the video above. The hook design will be improved upon before we CNC it using metal, and we are also in the process of designing a mount for the pistons to attach to the bot.
Inverted Swerve:
Inverted swerve was our team’s largest preseason project. We had MK3 swerves, but we wanted MK4i swerves due to the reduced vertical space it provides. However, we did not have enough money for 4 new swerves, so we designed plates to work with our MK3 swerves and the MK4i inversion kit. These plates were designed in Onshape, but our team now uses Solidworks, so you can see the .stp file in Bild. For the first inverted swerve we assembled, the final bearing would not fit in place, but with guidance from our mentor and alum Kyle, we were able to solve the problem and build one more inverted swerve module. We are planning on assembling all four inverted swerve modules, are are excited to drive them at comp. At the moment, it does sound a bit clunky, but we are hoping to redo the CAD with the correct spacings and tolerance, and have our sponsor Share Machine cut them for us.
With strength and well wishes, Titans together
Over the Bumper Intake:
Our over-the-bumper intake is heavily inspired by Cranberry Alarm’s Ri3D intake. It deploys using a motor, and uses 2" wheels to guide notes into a pocket. Our pocket is deeper than the one Cranberry Alarm featured, so that it doesn’t collide with anything when rotated into the frame perimeter. We wouldn’t have been able to create such a compact design had we not converted our Mk3 swerve modules to custom inverted modules.
Horizontal Flywheel Shooter:
We built a prototype of the CAD above, and we fixed the issue of the wheels being set too close to the plate with our first test. After fixing this, the flywheel shoots pretty well. We are hoping to test for accuracy over the weekend. This can only shoot amp, so we are also looking for possible ways to modify this to shoot into amp.
Design Review Session & Finalized Bot w/o Climb:
We held a design review for relevant team members on Tuesday, 1/16. People presented their ideas, and received constructive criticism from others. Our goal is to have a bot capable of amp and speaker scoring by Friday, 1/19, so to reach this goal we determined which of our prospective designs was the most practical to build in such a short time frame. Our choice used the aforementioned OTB intake, an adjustable shooter, and a virtual four bar mechanism to score in the amp (pic 1). However, as the day continued it became clear that the virtual four bar, while it would work, was an overengineered solution. The night of 1/16, this subsystem was simplified to a simple pivot mechanism indexed from the intake at an intermediate position (pic 2). We are currently constructing this prototype bot.
With strength and well wishes, Titans together
I love to see this! Feels like Cranberry Alarm turned to 11!
Any idea if you’ll be able to do trap with your amp scorer?
We are working on a climb design with minimal consideration of trap scoring, but there is a slight possibility that we might make the geometry work. You win some you lose some 
Hey! Looks like we haven’t had an update in a while. On the mechanical side, we’ve been finishing up our inverted swerves and finalizing our robot design (more on that soon, hopefully). Meanwhile, I’m excited to share what’s been going on over on programming.
So far, many of our programming team members have been working on computer vision, but others have been working on a shooting algorithm. We decided to tackle the shooting problem in 3d, while taking into account the robot’s current velocity. I’ll spare you some of the more complicated math, but here’s the gist of it:
For the more mathematically inclined, here’s a photo of the work that you have to do:
It turns out that solving for the angle θ(shooting angle) isn’t possible analytically while accounting for the robot’s velocity(trust me, I tried working out the trig for 6 hours), so we had to write a program to solve for this angle. The essence of the program is splitting up our possible shooting range(0 - π/2) into many different regions, then testing angles in those regions to find the one that gets the closest height. If we have more operation time, we can continue running this algorithm on the new region we’ve chosen to further refine our angle.
// this import might not work if you don't have the g++ compiler installed, in that case, just import whatever the function needs
#include <bits/stdc++.h>
using namespace std;
const double PI = 3.14159265358979323846;
// so far, assuming perfect conditions (i.e. no air resistance, lift, etc)
int main(){
double x, y, z; // x, y, and z displacement from the speaker's bottom center
cout << "Enter x, y, and z coordinates from the speaker center: "; // z should be negative
cin >> x >> y >> z;
// facing the speaker, positives for the dimensions are forward(x), right(y), and up(z)
double a = sqrt(x*x + y*y);
double v_x, v_y; cin >> v_x >> v_y;
cout << "Enter your x and y components of velocity: ";
double v = sqrt(v_x*v_x + v_y*v_y);
double t1 = (v_x == 0 ? PI / 2.0 : atan2(v_y, v_x)); // angle between velocity and x
double t2 = (x == 0 ? PI / 2.0 : atan2(y, x)); // angle between robot and speaker
double t3 = t2 - t1; // angle between velocity and line to speaker
double v_a = v*cos(t3), v_b = v*sin(t3); // a velocity in direction of the speaker, b is perpendicular
cout << "Enter your shooting velocity: ";
double s; cin >> s;
double s_az = sqrt(s*s - v_b*v_b); // the b-component of s must cancel out v_b
double range = PI / 2.0;
double center = PI / 4.0;
double scale = 50.0;
int reps = 3;
pair<double, double> min1 = {DBL_MAX, -1};
const double g = 9.807;
while(reps--){
for(double angle = center - range / 2.0; angle <= center + range / 2.0; angle += (range) / 100.0){
double s_a = s_az*cos(angle);
double s_z = s_az*sin(angle);
double time = a/(s_a+v_a);
double height = s_z*time - g/2*time*time;
// quadratic formula
double a = -g/2.0;
double b = s_z;
double c = -height;
double determinant = b*b - 4.0*a*c;
if(determinant < 0) continue;
double first_hit = (-b + sqrt(b*b-4*a*c))/(2.0*a);
// this means that our angle results in us hitting the speaker on the way down, which we don't want
// there's probably a better solution, since the speaker is slightly angled and does allow shooting downwards
if(first_hit + .01 < time) continue;
double dif = abs(-z - height);
if(dif < min1.first){
min1 = make_pair(dif, angle);
}
}
range /= scale;
center = min1.second;
}
cout << center << " "; // angle from vertical
double s_z = s_az*sin(center);
double s_a = s_az*cos(center);
double s_b = -v_b;
double t4 = (s_b == 0 ? PI / 2.0 : atan2(s_a, s_b));
double phi = t4 + t2 - PI / 2.0;
double s_ab = sqrt(s_a*s_a + s_b*s_b);
double s_x = s_ab*cos(phi);
double s_y = s_ab*sin(phi);
cout << remainder(phi, 2.0*PI);
}
At the end, this should output 2 angles, the first being the shooting angle above the horizontal, and the second being the angle of the robot from the x-axis.
Here’s a desmos graph to test out the algorithm:
https://www.desmos.com/3d/3f796660bc
Here’s another one to optimize how many angles are tested each cycle: https://www.desmos.com/calculator/lkmpmox19p
We have still yet to implement air resistance and/or lift into the algorithm, which will pose a significant challenge as well. Air resistance, for example, is proportional to velocity squared, but it’s not as simple as just integrating, since the cross-sectional area of the note also changes as it travels along the parabola. We might end up implementing this using Euler’s method, or just shoot a bit higher and call it a day.
We have for sure missed a few posts since we’ve been super busy with school, breaks, and of course robotics. We have lots to get through so let’s cut to the chase:
Design
So our design from the last time you saw has drastically changed. Our previous design which was very similar to the Cranberry Aalarm was found to be unreliable in our early testing so we pivoted (no pun intended). From there we returned to the drawing board with another idea. We decided to use an under-the-bumper, Team #95 The Grasshoppers style, that feeds into an indexer embedded into an angle elevator, which either extends to the score amp or feeds directly into our shooter. The elevator will also act as our climb. We currently are planning on using 2 motors with a lower reduction for amp scoring with a third on a higher reduction in order to climb however we may be able to do it with only the 2 meant for amp scoring
Shooter
Our shooter design’s main specs are using 4” Colson wheels on the top and bottom with .5” of compression and a 14” wide spacing. Each axel is powered by a falcon on a 1:2 upduction. The shooter uses a linkage system that can angle the shooter between 15 and 65 degrees, allowing us to either shoot like the kit bot or from further downfield.
Intake
As stated earlier our intake is similar to Team #95 The Grasshoppers under the bumper intake which is made outside the drive base part of the frame. Ours is approximately 24” wide and uses 2” compliant wheels to intake. We currently have some problems as we planned on using a figure 8 polycord to reverse direction. Unfortunately, this hasn’t worked for us in testing and we are planning to either run only 1 set of rollers or redo our side plate to work with gears and use both rollers.
Elevexer
Our elevexer currently is being built as we were waiting on WCP to restock inline bearing blocks which our design relied on, but eventually made the decision to reduce the indexer’s width to build it using the new bearing blocks which are about .25” thicker, going from about 14” to about 13.5”. While neither of these has been tested, we hope to have both together and on the robot to be tested by the end of the week as our mentors are putting in some extra hours to help get our robot done as early as possible. The elevator currently has some problems with alignment but this should be fixed by the end of the week.
Drivebase
Our drivebase is unfortunately one of our largest delays early in the season as our CNC was occupied cncing our custom inverted swerve plates, however, they are together now and we have also upgraded to SKS MK4 wheels with an L3 ratio as well. Our bellypan is currently being CNC’d and is something that our shooter relies on and electrical setup as this year we put extra effort into making it easier and more organized for electrical compared to previous years. We are also running a 24x24 drive base but a 24x31 frame with our intake extension.
Bumpers
Our bumpers are currently being made and we plan on doing a raised front section for the intake in a small C shape with a larger, lower C shape in the back. We are currently waiting on noodles to come in but we have our fabric and wood.
We are hoping to post next week with final updates and a bot together, but we’ll see how that goes
With strength and well wishes, Titans together
Hello everyone 
,
As the season has ended, I would like to mention our new long-term changes for programming. Since the summer of 2023, we have been working on our reusable AprilTag and dashboard code. It was a little tough to get everything working reliably by our first competition, but we managed to get it working during the Midwest Regional (you can see our best clip here). Although we still haven’t run our dashboard in production, we are looking forward to expanding it for next year.
Titan Processing: https://github.com/titan2022/Titan-Processing
Titan Dashboard: https://github.com/titan2022/Titan-Dashboard
Here’s our dashboard:
Here’s our AprilTag code running on a MS Lifecam at 480p
Since then, we have switched to an Orange PI 5 as our main coprocessor and global shutter Arducams for AprilTag detection. The vision library uses OpenCV’s Aruco contrib module and its included SolvePNP implementation, and then converts all poses to a single field-oriented robot pose using a linear Kalman Filter that combines input from multiple cameras and assigns greater significance to cameras closer to tags.
For the 2025 pre-season, our main goals are implementing an Extended Kalman Filter, switching to a swerve library (we were running our own implementation), running PathPlanner with vision, and finalizing our switch to Titan Dashboard—especially since Shuffleboard is less maintained than ideal.
Our dashboard and vision doesn’t utilize NT for communication, but rather raw UDP sockets in a publisher/subscriber arrangement. This lets us have a little more control over networking as well as guarantee that there are no problems with starting message packets since all packets are sent without notice. We are also looking into NT4, but our current solution is sufficient enough.
We are excited to see what the new water game will look like in 2025!
