Fatema shiyaji week3

build.gradle

@@ -1,6 +1,6 @@
 plugins {
     id "java"
-    id "edu.wpi.first.GradleRIO" version "2025.2.1"
+    id "edu.wpi.first.GradleRIO" version "2025.3.2"
     id 'com.diffplug.spotless' version '6.20.0'
 }
 

src/main/java/frc/robot/subsystems/ArmSubsystem.java

@@ -1 +1,42 @@
-// Homework for Week 2
+// Homework for Week 2
+package frc.robot.subsystems;
+
+import edu.wpi.first.wpilibj2.command.SubsystemBase;
+import com.ctre.phoenix6.hardware.TalonFX;
+import com.ctre.phoenix6.controls.Slot0Configs;
+import com.ctre.phoenix6.controls.PositionVoltage;
+
+public class ArmSubsystem {
+    private final TalonFX motor;
+    private final PositionVoltage positionRequest;
+    /* i dont really know what TalonFX is
+    i just saw it on the elevatorsubsystem code
+    */
+    // i also dont know what a PID is but i saw it on the elevator subsystem example
+    public ArmSubsystem() {
+        motor = new TalonFX(1);
+        Slot0Configs slot0 = new Slot0Configs();
+        slot0.kP = 2.0;
+        slot0.kI = 0.0;
+        slot0.kD = 0.1;
+        motor.getConfigurator().apply(slot0);
+        positionRequest = new PositionVoltage(0).withSlot(0);
+    }
+    public double getMovementRadians(){
+        return motor.getRotorPosition().getValue()/10;
+        //this seems pretty similar to getHeight in the elevator subsystem code except in radians
+    }
+    public double armAngle(){
+        /* i dont really know how to code this but i know i want to use an imu
+        sensor to find the pitch yaw or roll the arm is currently at (depending
+        on which axis it spins on). maybe a future use for this coule be if we
+        wanted to pick up game pieces using this arm, knowing the angle of the arm
+        would make it easier to align it with the game piece?
+         */
+    }
+    public boolean isHolding(){
+        /* i dont know how to code this either but to check if the arm is holding or
+        grabbing something maybe we could use a beam break sensor?
+         */
+    }
+}

src/main/java/frc/robot/subsystems/notes

@@ -0,0 +1,6 @@
+idk what we're supposed to be taking notes on so im js taking notes on the article thingy on the doc
+1 -- the CommandScheduler class organizes and runs the actions; it uses the periodic() method to do these actions 50 times per second
+2 -- Subsystems are a organized collections of robot hardware, with private functions to not expose the code and make it easier to make changes on. They are used alongside CommandScheduler as well, where commands specify the subsystem they're used in. Subsystems can also have default commands, which are like background actions.
+3 -- Subsystems are a subclass of the abstract class (a class that has no role on its own, but exists to be the blueprint for other classes) SubsystemBase. We used this in the ElevatorSubsystem code. motors and sensors each have their own private, final variable which doesn't get changed and only gets accessed through the class they're in. hardware has port numbers, so when there are multiple of each (ex. multiple motors) the computer doesn't get confused by which you're accessing.
+4 -- periodic() is a method inside SubsystemBase. this runs every 20ms and can be used to log repetitive activites of your choice. without having created your own periodic() method in your code, this method will do nothing as it is empty in the parent. motors shouldn't be controlled with periodic(), since this method always runs which would make the motor always run if it were used.
+5 -- subsystems directly correspond to the hardware part, so there should be multiple for the same part. they also shouldnt do 2 commands at the same time. if a command controls a whole subsystem, it is said that that command requires that subsystem. when a command doesnt require a subsystem it only runs the periodic method if there is one, which is why we sometimes have default commands.