2024 Programming - TAMSFormers5212/TAMSformers-Database GitHub Wiki
Overall, programming mechanical subsystems ended up being a bit easier with the new subsystem focused framework. We also learned a lot more about the vendor libraries and included new things like current limits, position and velocity conversion factors, feedforwards, and utilizing the periodic functions. These were lacking last year and led to worse controls and burnt out motors (didn't burn out any motors this year!).
Our second year of swerve. We found mechanical, electrical, and progrmaming problems from our 2023 implementation. Some we solved, some we are still working on, and we also made some more mistakes this year.
First, over the offseason we disassembled and cleaned out the modules. This was good for the health and longer term durability of the modules, but we made the humongous error of not labelling each module. As a result, we didn't put them all back in the same spots afterwards. This was compounded with wiring the encoders upside down, one encoder burning out, the NavX breaking, and the rewritten code not working.
The 2024 code was another rewrite largely based off the same structure as the 2023 offseason code with extra care to structure and document the systems. Additionally, Thriftybot sent us the revised encoder housings that made the encoders about 10x more accurate and a replacement for the burnt encoder. We also got a new NavX from first choice that had the Studica revision which made it more robust. The drive was finished on the second week of build season this year (compared to week 2 of competition season last year).
Mechanically, we used the same SDS mk4 modules, but the drive frame was 28x28 vs 27x27 last year. Additionally, we added a 1/8th inch steel bellypan for mounting electronics, center of gravity, and overall durability. It provided an very strong frame that did not need to be maintained at all (only a few dents and no bent tubing). The bolts were also installed from the bottom which made assembly and maintenance easier and was part of the bumper mounting system.For this years arm, we wanted to vastly improve on last years design. First, we added a REV throughbore encoder on the load bearing hex shaft. This provided direct, absolute positioning on the arm. Additionally, we wanted to prevent the arm sagging with the reduced, speed focused, gear reduction, so we implemented a feedforward to the arm PID. For the most part, it was just a gravity constant and velocity and acceleration were ignored.
The intake this year was very similar to last years competition design. Programming was also relatively similar, but we added motor configurations like we did everywhere else this year. Later in the season we added some logic for intaking and outaking at different speeds, and we also made it so the intake was faster when shooting to reduce the note stretching.
We had a flywheel shooter this year. It had two rows of powered wheels to impart an equal amount of energy on the top and bottom of the note. We didn't not use any spin to keep the shooter mechanically simpler. We used a feedforward and PID controller to control the rotational speed of the shooter. The feedforward got the rpm close to the setpoint, and the PID would adjust it closer. We found some differences, mostly due to friction, between the two shafts, so we had two sets of feedforward and PID constants for the two motors powering the two shafts, one shaft each.
We used infrared beam break sensors from dfrobot. They detected when an object was obstructing the path of the beam from the emitter to the receiver. These were easy to use because they just had three pins that could be connected to the roborio's DIO ports. We used these to detect if a note had been picked up or not.
First year of actually using the limelight to do things. We used it to read the center speaker apriltag to aim the shooter. We got the distance using ty and trig calculations, and we aligned the robot using tx.
Ran off Pathplanner, had to redeploy code each time to change Autons. Had trouble with Autonomous paths flipping directions when on the red alliance but staying the same on the blue alliance.