November 1, 2024 - November 8, 2024
Documented By Chris Chen
This year, to stay organized, we structured our code into different classes using object-oriented programming. This means we are not crowding everything into the opmode class and instead having different classes for parts of the robot and then running them in the opmode's runtime loop using their move methods.
HardwareInitializer.java & Values.java
Below is the code for initializing all the hardware on our robot and organizing them into separate categories: LED drivers, motors, and servos. Using the initHardware() method, we retrieve the hardware from the hardwareMap and assign them to their respective lists by name.
Following this are the getter methods, which allow the hardware to be accessed when used in the OpMode or separate component files.
On the right is the Values class, which stores the maximum, minimum, and preset values for all the robot's mechanisms. This makes it easier to understand what each value represents. Additionally, changing a variable here updates all the corresponding instances throughout the code, simplifying troubleshooting and reducing errors.
HardwareInitializer.java & Values.java
Here is the code for our field-centric mecanum drive movements. First, we retrieve all the hardware and assign it to the class.
Next, we have an init() method that initializes the hardware. In this method, the motors are set to brake mode to ensure they retain their position even when not moving. Additionally, the IMU is reset to establish the robot's heading.
Finally, we have the logic for the drivetrain. By utilizing an IMU and applying trigonometry, combined with the robot's heading provided by the IMU, we are able to program the drivetrain's movements. Additionally, we incorporated code from Game Manual 0 to refine the functionality.
This logic calculates and sets the power to the motors, enabling the robot's movement. The robot's mecanum movement is guided by the following diagram:
November 9, 2024
Documented By Chris Chen
Highlights:
- Highest score achieved at the event.
- Networked with many teams at the event.
- Robot didn’t receive major damage throughout the matches.
Highlight Video: https://www.youtube.com/watch?v=LWp21nkQWoM
Challenges:
- Driver practice could be fine-tuned.
- Due to claw sizing and early season components rather than finalized parts.
- The pivot motor was overheating.
Next Steps:
- Since we have aluminum, I believe our Studica drivetrain can be upgraded to a custom CNC-machined aluminum drivetrain. This would give us greater control over component placement and address the issue of the Studica chassis being so narrow that we currently have to disassemble the wheels and motors—along with the attached mechanisms—whenever adjustments are needed. A custom drivetrain would also help us solve many clearance issues, as we could place parts exactly where we want them, without being restricted by the fixed patterns that Studica provides.
- We have a minor wire management issue; currently, we’re using zip ties to secure the claw wires to the slides to prevent them from dangling and getting caught. However, this is a temporary solution, and the zip ties keep getting cut because they’re positioned near the moving slide strings. To address this, we’ll be reprinting some of the slide inserts to eliminate this problem.
- Our current claw is slightly too small, requiring high precision to pick up samples from the submersible. To improve this, we plan to add a larger claw and possibly a camera on the claw, allowing it to auto adjust to the position of the sample.
- I saw a robot online that can multitask: it picks up a sample from the submersible while scoring a specimen on the high goal, then drops off a sample in the observation zone and picks up a new specimen in the process. This might be an ambitious goal, but with enough tuning, perhaps our robot could achieve this as well.
- We are also creating a driver station to organize the driver hub and controllers.
November 11, 2024 - November 15, 2024
Documented By Chris Chen & Enhe Bai
Video of Slides Testing:
ArmControl.java
Here is the code for the control of the slides and our arm.
When tuning PIDF values for the slides, we accounted for their orientation, whether vertical or horizontal. Since the slides require different PID values at varying angles, we incorporated the F constant with Sin(θ) to adjust the PID values according to the slide’s angle. This concept was also applied to the Pivot motor's PID control. The motor requires the most power when it is horizontal and the least when vertical. By applying Sin(θ) to the motor's power, where θ represents the angle of the slides, we ensured optimal performance.
On the left is the code for the movement of the claw which consists of the: wrist, rotate and the pinch.
November 18, 2024 - November 22, 2024
Documented By Chris Chen & Enhe Bai
V1:
We initially used Axon micro servos for the rotation and claw open/close motions. However, the micro servo gears stripped when the claw hit the ground forcefully.
V2:
In the second version, we switched to an AK47 servo for improved durability and control. However, the wrist servos rotated along with the claw, and we wanted to make the servos stationary for better stability.
V3:
To address this, we made the servos stationary. However, since the servos are large, the claw component became oversized. In the next iteration, we aim to reduce the size for better functionality.
November 27, 2024 - December 1, 2024
Documented By Chris Chen
Here is the trajectories for our autonomous which is the positions that the robot will move to on the field as well as it's heading.
Here is our autonomous code for running pathing for Roadrunner 1.0. The paths and the actions are all in SequentialAction.
Running in parallel is the arm's move method because there is a PID for the slides and arm which needs to be constantly running.
December 1, 2024
Documented By Enhe Bai
Highlights:
- Won 4 matches out of 5 allowing us to be the 4th alliance captain and picking 22664 - R3P2 Pivotal Ponies because they had a sample auto, however their robot didn't work so we didn't make it to the finals.
- However, we were able to clutch with 2nd Place Inspire which qualified us for provincials.
- Additionally, we also networked and talked to many teams at the event. This allowed us to gather ideas on what our next robot design could be as well as making alliances for provincials.
- Robot didn’t receive major damage throughout the matches.
Challenges:
- We chose to score specimens, but our alliances had trouble even scoring samples. In the end, we figured out that scoring specimens will have 2 cycles but scoring samples only take 1 cycle, giving the score ratio of 16:10, which means scoring samples are more efficient
- The slides shake when fully extended since it is only one stack of slides. We wish to improve this on the next robot by having slides on two sides to increase rigidity.
- More driver practice is needed to increase cycle time.