Inertia

Define

I can't define what we wanted Inertia to be, for it simply followed the flow of our collective river. 🌊

As such, the following section will be written as a timeline of major developments.

At kickoff, this is what we said we wanted Inertia to do. I'll start off with the positives, and what we successfully accomplished. We were ablee to shoot into the hub in auto and teleop, as well as ferry from anywhere (including full field!). We were able to store balls and ground intake, drive under the trench and over the bump too!. However, what we did not do was any form of climbing. In retrospect, this was totally okay, as it provided little to no strategic benefit. Despite this, we did spend quite a lot of time attempting it.

The following section will attempt to describe, by section, each component of the robot that I contributed to beyond the prototyping process.

A Timeline Beyond Prototyping

We continued to use Java as our programming language of choice this year, lending to code that was once again developed rapidly. This was, however, not without its struggles. After an offseason of difficulty, I realized that I did not teach the new class to the point where they felt they had the confidence to make their own subsystem. This challenge effectively made the plan outlined below moot.

In addition, the code of the turret was incredibly more simple than we had thought it would be, especially with the advent of motion control technology from CTRE's TalonFX. This led me to become increasingly involved in other subsystems, effectively writing their code. This is fundamentally against my idealogy, but we were attemping to follow a strict deadline on an already-behind robot.

Code: Projectile Launching

There were three methods we wanted to try in order to get the shooter to work. A critical consideration is that we were turreted and hooded. This means we can make a shot at any angle and distance, and even shoot while moving with our turret. There are so many variables in this problem - robot distance, angle, robot velocity, etc. We must reconcile this information to get a turret target angle, hood target angle, and RPM setpoint.

Below, you can see an example with the Ballistic solver. Shots look like they are approximately aiming into the goal, but there are some major issues that are more subtle and difficult to fix.

Notably, this method had two major issues:

• Major loop overruns due to the ineffieicny of running the ballistic algorithm on Java

  • The original algorithm was written in C++, then ported over to Java with little-to-no optimizations

  • This led to loop overruns that sometimes led to the drivetrain being inoperable

• Inaccurate characteristic of the shooter

  • The physics solver imagines the shooter to be a perfect model of the simulation

  • However, issues such as drag and compression lead it not to be representative, leading to frequent undershooting

  • The extra work of tuning a Exit Velocity -> RPM function was deemed to not be worth it, leading us to shift

Below, you can see results achieved with the Desmos Physics approach. Unfortunately, there were some mathematical errors, leading to issues with its aim (constant overshooting). Additionally, there were many confusions between radians and degrees, further exacerbating the issues.

Ultimately, we decied we needed to shift. Reading the message below, we decided to go with the simplest solution, the Lookup-Table solver. This was just about two weeks before our first competition, so we were on a huge time crunch.

One of my biggest concerns as cited in the above message is if the method would actually work. So, I spent the entire evening testing and simulating to make sure there were absoultely no bugs. I did this in advantagescope, and it worked amazingly! Here's some videos of our process.

Luckily, our LUT approach actually worked first try! We tuned it outside, without realizing that wind actually affects the tuning. Despite this, we now had proof that the LUT approach works for stationary positions. We now proceeded to fully commit. Here's some videos of our tuning process.

Shoot on the move also worked immediately with the TOF approach, which uses velcoity to predict where the target is going to be.

Code: Autos

Similar to last year, we used PathPlanner