Quartz sync: May 19, 2024, 4:20 PM

content/Advanced Stuff/Advanced Stuff.md

@@ -0,0 +1 @@
+[[AutoAim]]

content/Advanced Stuff/AutoAim/2024 VorTX Autoaim.md

@@ -0,0 +1,4 @@
+![[2024-VorTX-AutoAim-WhitePaper.pdf]]
+
+
+Above is a white paper explaining our process of creating auto-aim for our 2024 robot.

content/Advanced Stuff/AutoAim/AutoAim.md

@@ -0,0 +1,2 @@
+AutoAim for the 2023 FRC season:
+[[2024 VorTX Autoaim]]

content/Files/File Structure.md

@@ -0,0 +1,5 @@
+[[RobotContainer.java]]
+[[Robot.java]]
+[[Subsystems]]
+[[Commands]]
+[[Util]]

content/Files/Robot.java/Robot.java.md

@@ -0,0 +1,47 @@
+Not much goes on in Robot.java compared to [[RobotContainer.java]]
+
+However, there is still some important stuff to be done in this file. 
+
+There are a few built in functions we call to add commands to robot initialization or autonomous periodic. 
+
+There are 5 main robot states we can override.
+- Robot
+- Teleoperated
+- Autonomous
+- Disabled
+- Simulation
+
+Each of these modes have their own initialization and periodic function. 
+
+**Initialization functions** are called once the robot enters a certain state. These are useful for commands which need to be called once, like scheduling the autonomous command once the robot enters autonomous modes. 
+
+**Periodic functions** are called once per scheduler run (while the robot is in a certain state). These are useful for commands which need to be run continuously such as updating values in a dashboard. 
+
+- *Initialization and Periodic functions can also be made for each subsystem. 
+
+Below is an example of a periodic function running continuously while the robot is on which puts diagnostic values into SmartDashboard.
+
+```Ex:
+/**
+* This function is called every 20 ms, no matter the mode. Use this for items like diagnostics
+* that you want ran during disabled, autonomous, teleoperated and test.
+*
+* <p>This runs after the mode specific periodic functions, but before LiveWindow and
+* SmartDashboard integrated updating.
+*/
+
+@Override
+
+public void robotPeriodic() {
+
+// Runs the Scheduler. This is responsible for polling buttons, adding newly-scheduled
+// commands, running already-scheduled commands, removing finished or interrupted commands,
+// and running subsystem periodic() methods. This must be called from the robot's periodic
+// block in order for anything in the Command-based framework to work.
+
+CommandScheduler.getInstance().run();
+
+SmartDashboard.putBoolean("intake/Beam Break",beamBreak.get());
+
+}
+```

content/Files/RobotContainer.java/RobotContainer.java.md

@@ -0,0 +1,42 @@
+Initializing subsystems like the arm, shooter, intake, etc. with the IDs of the motors. Initializing the command file takes in a parameter of the subsystem which you are creating a command file for. This should all be initialized BEFORE the constructor. 
+```Ex:
+public static Intake intake = new Intake(16);
+public static IntakeCom intakecom = new IntakeCom(intake);
+```
+
+Inside the constructor is the button bindings. At the top of the constructor, initialize the VorTX controller library with this call.
+`configureBindings();`
+
+Once this has been done, you can create functions utilizing values from the VorTX controller library.
+
+Uses button bindings that are available from the VorTX Xbox controller library. These are the options for buttons.
+```
+aButton, bButton, xButton, yButton, view, menu, ls, rs, lb, rb, lt, rt,
+povUp, povUpRight, povRight, povDownRight, povDown, povDownLeft, povLeft, povUpLeft
+```
+
+Put the command / subsystem to use for the button binding inside a function. 
+```Ex:
+con2.xButton.whileTrue(
+
+	intakecom.intakeNoteCom()
+
+);
+```
+
+A run command is a way to run a command for a certain subsystem. Usually, these run commands are placed within a button binding which can be seen above. Inside the run command, the first argument is the command you want to run. This can be done with the double semicolons below, or can be done with a lambda.
+
+```Ex:
+intake::stopIntake        || (Runs the command stopIntake)
+() -> intake.StopIntake() || (Also runs the command stop Intake)
+```
+
+Example of run commands 
+```Ex:
+intake.setDefaultCommand(
+	new RunCommand(
+		intake::stopIntake,
+		intake
+	)
+);
+```

content/Files/Subsystems/Basic Guide to Subsystems.md

@@ -0,0 +1,5 @@
+[[Arm]]
+[[Elevator]]
+[[Intake]]
+[[Shooter]]
+[[Drive]]

content/Files/Subsystems/Subsystems.md

@@ -0,0 +1 @@
+[[Basic Guide to Subsystems]]

content/Files/Subsystems/Subsytems/Arm.md

@@ -0,0 +1,46 @@
+The arm uses an encoder ( values are in terms how far the encoder is rotated) to get values so that the once it hits a the set limit which is a soft limit so that the arm does not go too far back when it goes up. When it goes down it hits a soft limit which after it hit s the limit it uses gravity to go down slowly. 
+ Example of the code of arm going down using  brakes and gravity : 
+``` public BooleanSupplier getArmDown() {
+
+return () -> position <= (Constants.ArmConstants.groundArmPos + .05);
+
+}
+
+public void setArmBrake(IdleMode mode) {
+
+ArmNeo1.setIdleMode(mode);
+
+ArmNeo2.setIdleMode(mode);
+
+}
+```
+Example  of moving to set point using the positioning from the encoder to  know where to go : 
+
+```
+```public void moveToSetpoint(double setPointPos, double p) {
+
+move((setPointPos - getArmPos()) * p);
+
+}
+
+  
+
+public void hold() {
+
+// double pos = armEncoder.getAbsolutePosition();
+
+setpoint = (int)position;
+
+ArmNeo1.set(hold.calculate(position * 2 * Math.PI, setpoint * 2 * Math.PI) + armFF.calculate(position * 2 * Math.PI, kv));
+
+}
+Arm getting values from the encoder :
+public double getRadiansTravelled() {
+
+return armEncoder.getDistance()/(2*Math.PI);
+
+}
+```
+
+
+

content/index.md

@@ -0,0 +1,5 @@
+This is a comprehensive guide on all the ins-and-outs you need for FRC programming. 
+
+[[File Structure]]
+
+[[Advanced Stuff]]