Efficiently Controlling an Arm
Brainstorming and simulating a code control system for an arm.
I’m back writing another blog post! I am writing this blog post due to the interesting challenge our robot design has presented us in the code (Thanks build team). This blog post will be a bit different as I will be writing about my thought process and how I came to the conclusion of the code I wrote. The Problem Our robot this year has an elevator and an arm with an intake at the end of the arm. The elevator and arm both have a motor and encoder, allowing the code to accurately position and control the height and angle the resulting angle of the intake using PID. The intake’s rotation is locked to the elevator tower, so the intake is at a permanent 45 degree angle. The arm can rotate around over the top to get from one side of the tower to another. However, if the elevator is to low then the intake can hit the elevator tower, giving us our dilemma. How can we effectively control the height and angle of the arm over time to get to a desired position is the least amount of time?
Bevy · Code · Frc · Kinematics · Pathing · Physics · Rapier · Rust · Simulation
7 minutes
Today in Code Team - January 15, 2025
Your semi-regularly updated blog from the code team.
Overview Today focused on two main areas: PID tuning for the test chassis and vision system improvements. Drake, Sean, and Ethan worked on debugging the swerve drive PID loops. We’re seeing issues where the wheels know their target direction but aren’t reaching it correctly - they either undershoot/overshoot or exhibit erratic behavior. While the code correctly calculates desired wheel orientations, there appears to be a disconnect between the commanded positions and actual wheel movement. We suspect this could be related to how the PID controllers are interpreting feedback from the turn encoders.
Code · Drive · Frc · Pid · Vision
1 minute
Today in Code Team - January 11, 2025
Your semi-regularly updated blog from the code team.
Overview After ongoing issues with the Kotlin language server (which appears to be unmaintained), Drake made the decision to switch the robot code back to Java. The team spent time converting the existing Kotlin code and adapting to Java. While waiting for the chassis, Drake implemented button mapping and control code for driving the robot. A subsystem manager was briefly explored but ultimately deemed too complex for our needs. When the test chassis was ready, we deployed the code and attempted to drive it. The drive motors exhibited erratic behavior (spasming) while the turn motors remained unresponsive. We suspect issues with the feedback sensors for the turn motors, likely due to significant API changes in the 2025 update.
Code · Drive · Frc · Router · Vision
1 minute
Today in Code Team - January 8, 2025
Your semi-regularly updated blog from the code team.
Overview Drake and the robot team in set up the 2025 robot project in Kotlin FRC extension after using WPILib to create the project. The FRC Kotlin extension caused some headaches since it was designed for 2024, but we fixed it by updating configurations and Gradle settings. Vendor dependencies like YAGSL and REVLib were set up, and we began structuring the robot code. Vendor Dependencie’s API changes remain an issue for next time.
Code · Drive · Frc · Router · Vision
1 minute
A sad day for the team.
Today is a sad day. We lost a trooper in the field. The Spark Max, a motor controller that has been with us since the beginning of the season, has been fried. The cause of death is unknown, but it is suspected that the motor controller was plugged in backwards. The motor controller was found dead on the field, with the smell of burnt electronics filling the air. The Spark Max will be missed, but we will continue to fight on in its memory. It was declared dead at 4:20 pm on October 2nd, 2024 with the cause of 12v gate fault. Rest in peace, Spark Max. You will be missed.
Electrical · Frc · Rev · Spark · Sparkmax · Whoopsie
1 minute
FRC simulation in godot to train drivers virtually.
This year, before we were able to finish designing and building our 2024 robot Bothoven, I was busy at home reconstructing the field in Godot from the CAD models provided by First to make a semi-realistic simulation. Building the field To make a good simulation you first have to start with the environment. In this case, it would be the FRC field. I first imported the CAD model from the Onshape page into Godot, however, all the textures and colors were gone due to the file format/Onshape. To fix this I made scripts in Godot to help apply textures I sourced online. I grabbed the carpet texture from the manufacturer’s website, images from first, and textures from various online sources. When I was done it looked something like this:
Code · Frc · Godot · Simulation
6 minutes