January 8, 2024
Documented By Chris Chen
Highlights of the Day: The aluminum bits came and we finished all of the plates we needed for Hydra V3.
Problems Encountered: Nengjia didn't check the directions of the path, whether it's inside or outside. So we've wasted a piece, and learned that to watch the animation of the paths.
Gallery: Products of the Day
January 9, 2024
Documented By Chris Chen
Gallery: Priming Aluminum Parts
To ensure our aluminum parts remain stable during CNC cutting, we added tabs to hold them in place. However, this created uneven surfaces and tabs that needed to be removed. Additionally, variations in the aluminum’s Z-levels require further adjustments.
After cutting, we use a hammer to remove the tabs, followed by a Dremel tool and files to smooth and even out the aluminum surfaces.
Below are pictures showing the process of hammering out the tabs, and the subsequent filing and smoothing work:
On the top-right corner is a wooden plate used for mounting our intake to the horizontal slides, and on the bottom-left corner is the second inner plate for our drivetrain.
This is our intake assembled by Chris and Huan.
January 10, 2024
Documented By Chris Chen
Assembly of Odometry Pod, Inner Side Plate, and Hex Shaft Cutting for Drivetrain Motor Attaching to Belt Pulley:
Sanding and File of Slide Screws and Robot Inner Plate:
We had to sand part of the inner plate because it was our first big cut and the holes were not aligned so we had to file it down.
January 11, 2024
Documented By Chris Chen
Assembled and mounted slides, control and expansion hubs, drivetrain and slide motors, front and side plates, and the servos for the virtual double-reverse four-bar linkage for horizontal slides:
Reprogramming Axon Max Servos:
We wanted our Axons to be able to rotate 330 degrees, as most of our mechanisms required that range. To achieve this, we used the Axon programmer and downloaded the software for programming the servos.
Through this process, we learned that the degrees are scaled to 255. This means that 255 corresponds to 330 degrees, and any other angle can be calculated using fractions of 255. The other settings should not be altered, as changing them can interfere with the servo's internal PID control.
Assembly of Intake and Virtual Double-Reverse Four-Bar Linkage:
Problem with Virtual Double-Reverse Four-Bar Linkage:
Assembly of Drivetrain Wheels, Pulleys, and Belts:
January 13, 2024
Documented By Chris Chen
Reference:
Our Fix:
January 14, 2024
Documented By Chris Chen
Soldering Longer Control-Expansion Hub Communication Cable:
Programming Mecanum Drivetrain
January 15, 2024
Documented By Chris Chen
Light Control:
Wire Management:
January 16, 2024
Documented By Chris Chen
String of Slides:
Below is an image of the string being rigged onto the spool. On the right, we are threading it through the slide V-bearings on the slide inserts and tensioning it using springs.
Here is the initialization of the hardware we are using for this Hydra V3:
The mecanum movement for V3 is the same as V1, however we switched to robot eccentric (no IMU) because the IMU was unreliable and randomly turns off mid run.
OuttakeControl.java
Here is the outtake control which controls everything from the horizontal slides and the outtake pivot, wrist, rotate, and claw.
As you can see, the slides here also has a PID controller to have have precise movements.
Intake Control.java
Here is the intake control, which involves several moving parts, including the V4B extension (slides), turret, pivot, rotate, wrist, and claw. We retrieve the positions of these components and store them in their respective class variables for later use.
To improve precision, a throttle was implemented, allowing the intake to move more slowly and accurately during operation. Additionally, if-else statements are used to enforce the maximum and minimum positions for each component, preventing over-rotation and potential damage to the servos.
January 17, 2024
Documented By Chris Chen
Now that we have all of the moving parts and their limits, we can start coding the finite state machine. This helps the drivers not need to click or control multiple buttons to get to a position. One position and have states which the driver can be in. That way we can reduce cycle times and driving will be easier especially with 12 servos on our robot and 10 moving parts
Here, we are mapping controller inputs to their respective states, which will be used during the game:
Chamber: Picking up specimens from the observation area and scoring them in the high chamber.
Basket: Scoring in the high basket.
Dropoff: Quickly dropping off specimens in the observation zone.
Submersible: Extending into the submersible.
Transfer: Transferring the sample from the intake to the deposit.
Home: Resetting all mechanisms to their home position.
Before we dive into the finite state machine, there are two main types of variables we are using:
autoProcess: Represents the different states, as explained on the left.
autoStep: Represents the different steps within each process.
We are creating two sets of these variables—one for intake and one for outtake. The addition of "_i" indicates processes related to the intake, while "_d: represents processes for the outtake.
Below is the code for the Home process for both the intake and outtake, which will be executed after other processes. As you’ll notice, one of the steps is labeled as "10001". Here, the additional "000" and "1" represent the sub-step within the main step. This allows for finer control over timing, ensuring that movements occur sequentially rather than simultaneously, which helps prevent conflicts.
Here is the code for the transfer process for both intake and outtake:
Here is the code for the transfer process for the intake, which prepares the mechanism to grab a sample and successfully picks it up:
On the left is the code for picking up and scoring on the submersible. In the first segment (cases 1-20001), the mechanism picks up the specimen from the submersible. The video below provides an example of this motion (although the pickup attempt was unsuccessful, the demonstration illustrates the intended movement).
On the right is the process for scoring in the basket using the outtake:
January 19, 2024
Documented By Chris Chen
We decided to use Pedro Pathing instead of Roadrunner 1.0 due to Roadrunner's inconsistency and its overall poor interface. Additionally, the lack of helpful documentation and the unhelpful responses from their developers made solving problems almost impossible.
With Pedro Pathing, we have a direct connection with the creator, allowing us to create organic trajectories using Bézier curves. This means we can fully optimize our pathing. They also provide an active support server to assist with any issues we encounter. As of now, their documentation is excellent.
Pedro Documentation: https://pedropathing.com/overview.html
On the left is a video of the pathing I created using a generator. This tool generates all the points and control points for the paths. Unlike Roadrunner and MeepMeep, where you have to guess values, Pedro Pathing allows you to visually move the points and obtain accurate results.
The next step I took was to use the template provided by Pedro and create the program. First I had to put in all the points (including control points) into their respective variables as you can see below.
We have two types of paths: a normal path, which involves following a single path and then performing some actions, and a chain of paths, which we use to push the preset samples to the observation zone. Both types of paths will be declared in the buildPaths() method.
Here is a sample of how we declare the paths and trajectories that the robot will follow:
Finally, in the autonomousPathUpdate() method, similar to the finite state machine I created in teleop, it follows a step-by-step process. However, I found a good coding practice: using a new method called setPathState() (see below), which sets the path and resets the runtime. This approach makes the code cleaner and less repetitive. I plan to integrate this method into the finite state machine in teleop in the future.
Voilà, the pathing for autonomous is done. However, our next steps involve tuning the drive values for our robot and adding actions, such as picking up specimens from the observation zone or scoring them in the high chamber. On the right, you can see the values we still need to tune or determine. Additionally, I look forward to creating a sample autonomous program for provincials when we have more time. The reason we couldn't tune these values in time was that the encoder wire was cut, so we now need to solder a new one.
January 20, 2024
Documented By Enhe Bai
One challenge for Hydra V3 was the intake extension’s double-reverse four-bar linkage design. Initially, I ignored its complexity and wanted to save more space than a regular linkage. The first design failed because the bottom pieces of the arms coincided, causing the entire mechanism to tilt instead of separating. This was due to a missing belt that would have kept the top and bottom parts parallel.
The second design addressed this but required excessive torque to pass the coincidence point because the belt tension was insufficient, and the arms were misaligned due to the thicker wood used in the initial design. Finally, on the third iteration, we levelled the arms, and the design worked perfectly. Additionally, I learned the value of using bungee cords as a passive system to assist vertical slides, reducing the workload on motors.