FRC 4322 2023 Build Thread

FIRST Open Alliance
,
1

Welcome to Team 4322 Open Alliance build thread for 2023! This is our first year of posting on openalliance, and we are excited to join the community and embrace the vision of Open Alliance.

Overview

Clockwork Oranges-All photos-50733098698
Clockwork Oranges-All photos-507330986981280Ă—853 266 KB

FRC Team 4322 is a student-led community team based in Orange, CA. We are part of BSA Venturing Crew 1701, and are chartered by the Orange Public Library Foundation. We currently have 22 students spanning 3 school districts and 7 schools.

Open Alliance Posting Schedule
We plan on posting weekly updates to Chief Delphi(with lots of pictures). We will summarize what we did during the week and will make sure to include what worked and didn’t work as per the Open Alliance ethos.

Links
2023 CAD: OnShape
2023 Code: [Coming soon]
Website: https://frc4322.com/
Instagram: https://www.instagram.com/frc4322/
Twitter: https://twitter.com/frc4322
Facebook: FRC Team 4322 - Clockwork - Crew 1701
YouTube: https://www.youtube.com/@4322Robotics

5 Likes
3

This should be fixed

4

Here’s our 2023 Robot Code: GitHub - 4322/2023_Robot: FIRST CHARGED UP 2023

5

Week of 7/24 - 7/30 Update

Overview
For the 2023 off-season, the main project we’ve been working on is creating a three-motor swerve drive for our robot. After experimenting with trying to get our robot to do floor pickup, we realized that cubes were the only viable game pieces we could pick up from the floor due to our intake design. As a result, we decided to look at other aspects of the robot that would reduce our cycle time, and we came across three motor swerve. We decided to pursue this project for the off-season because we realized that it would not only reduce the time it takes to get to the single substation and back, but it would also be useful for upcoming FRC seasons. By having the capability to implement a 3 motor swerve on our future robots, we will be prepared for any sort of fast-pace game that requires quick cycle times. Additionally, the extra power from having 2 drive motors will allow us to push past any robots trying to play defense against us, which was a major problem we faced during the season.

CAD
We started off with the OpenSwerve 3 Motor Swerve Module CAD, and began adding our modifications to it. We switched the rotation motor from Falcon to NEO brushless motor because Falcons are not in stock, and we adjusted the mounting to be compatible with our 2023 robot. We created our swerve cover to have space to mount a SparkMAX inside, and this way the SparkMAX is safe and secure inside the cover. We added bearing locations on the top plates to support 3 motor shafts. In an effort to make the manufacturing process easier, several design modifications were implemented. First, the extra support surrounding the bearings was eliminated, making it easier to produce. Similarly, the pocketing was also removed to simplify manufacturing without compromising functionality. Additionally, chamfers were omitted from the design to reduce costs further.

Software
In terms of software, we just started adjusting our current swerve code to accommodate for the 3 motor swerve drive. So far, we have finished the code for the second drive motor including making the second drive motor follow the first and inverting it and we started changing the rotation motor to a Neo.

We plan on configuring the Neo to use the external redux encoder so that we do not have to use the sparkMAX encoder, which would decrease latency. Other plans for the future include the changing of the rotation motor gear ratio, updating the logic to controllers for the neo rotation motor, creating current and voltage monetization, and depending on testing, may revisit our anti-tipping code from 2022. The current and voltage monetization is being used since the 3 motor swerve will be capable of using much more power than the breaker is able to handle. As such, we will also need to include safeties which limit the power of the swerve modules to prevent browning out. As for the anti-tipping code, our team has prioritized having a low center of gravity on our robot, but if the increased speed from 3 motor swerve makes our robot more prone to tipping, then we may need to revisit our 2022 anti-tipping code. An alternative to this would be decreasing the acceleration and deceleration of the robot.

On the side, we are also undergoing software training for new members of the team. We have been teaching new members the basics of Java and are currently getting to intermediate topics which consist of understanding WPILib and the command-based framework.

2 Likes
6

Week of 8/7 - 8/13 Update

Overview
This week we have been creating a technical binder for our 2023 robot and have continued our software training for new students.

Our technical binder is split up into 3 main sections: design process, final design, and programming. The design process section covers the different designs we thought of during build season for each subsystem on the robot, including the pros and cons for each potential design. Our final design section covers the subsystems we decided on in the end, and the different modifications we made to them for each regional we went to (Orange County & San Diego Regional). Our programming section covers the autos we created, our driver controls, and the vision system we had on our robot. We are currently in the process of finishing up our technical binder, and a link to it will be posted on the Open Alliance once it’s finished.

Software
For software training, we have been learning how to read an FRC program, starting with our 2023 robot code. We learned to investigate robot code by starting off at the subsystems, then going to the commands, and then looking at RobotContainer. Looking at the subsystems lets us understand the basic capabilities of the subsystem. Looking at the commands lets us understand the logic behind how a subsystem’s methods are being invoked in order to perform a certain action. Finally, looking at RobotContainer helps determine the robot’s autonomous capabilities, and how the robot is controlled through its button bindings. We also learned about other intermediate topics like singletons and try-catch statements, both of which are commonly used in an FRC program. We are now going to start learning about Git and how it is used to manage our robot code throughout build season.

1 Like
7

Week of 8/21 - 8/27 Update

Overview
This week, we have been building our 3-motor swerve, refactoring our swerve drive code to adjust for 3 motors, and are in the final stages of completing our technical binder.

On Tuesday, FIRST came out with the announcement that 3-motor swerve is banned for future seasons(Announcement). This was unfortunate timing for us because we’ve been developing our own 3-motor swerve in preparation for the off-season and future competitions, and the parts we ordered to assemble it have already arrived. Since we’ve already invested a considerable amount of time and money into the project, we decided to continue developing our 3-motor swerve for the off-season.

Mechanical
We began assembling our 3-motor swerve by first sorting parts for each module into their own pile. We then began tapping holes into the swerve plates, and also started working on assembling the wheels. Currently, we are using the SDS MK4i Swerve Module Assembly Guide to build the modules.

Software
We have been adjusting our encoder code for the turning motor due to it switching from a Falcon to a NEO. We changed the swerve drive logic to accept a SparkMAX instead of a CANCoder, and also adjusted the current limits for the encoder. In addition, we updated our Phoenix vendor library from 5 to 6(Phoenix Pro API became free and was renamed to Phoenix 6), and are currently in the process of migrating to the new framework.

For software training, we have been covering the fundamentals of Git and version control software. We have been dissecting our Git history from the 2023 season and are planning on doing exercises where we commit code and create new branches.

2 Likes
8

Week of 8/28 - 9/3 Update

Overview
This week we have continued building our 3-motor swerve modules, finished our technical binder, and have continued working on refactoring our swerve drive code.

Our technical binder has been completed. Here is a link to view it:
FRC 4322 2023 Technical Documentation.pdf (7.0 MB)

Mechanical
When tapping our first main plate for the 3 motor swerve project, we had to use a drill since we didn’t have our T-handle tap wrench. We found that some of the bolts that the modules came with to mount the bearing to the plate had a loose fit in the plate and some of them felt like we could just pull them out. We decided to go with slightly longer bolts and found that they held the bearing down more secure. We used loctite on all the bolts we used while assembling the modules.

After tapping the holes and attaching the bearing, we proceeded with steps 3-6.

We took off the Swerve X modules from our robot so we could remove the Falcons and encoder to prepare for step 8.

In addition to assembling the 3 motor swerve modules, we continued to work on the CAD for the cover plates. We added notches in the fronts of all the covers that allow us to fit a zip tie through for wire management.

Software
We have continued migrating our code to the Phoenix 6 vendor library. Due to the major differences between Phoenix 5 and 6, we changed a few of our methods to accept rotations units instead of encoder ticks, refactored our PID initialization, and changed our coast/brake mode to accommodate for the new library.

For software training, we have created a new Git repository for us to conduct training exercises, play around with, and learn more about how Git works. We discovered that using the Git Rebase feature in VS Code makes the branch line in Git Graph(VS Code extension) look cleaner for cases where two or more people are working on the same branch.

Normally, if one person pushes their code, then when another person working in the same branch pulls and pushes their code, the graphical visualization will make it seem like another branch has been created and was merged in.

However, the rebase function rewrites the history of the merge and makes the branch graph look like a clean line made up of a series of consecutive commits, which is much easier to understand and work with. While there usually are concerns with rewriting history in Git, we decided that this feature will benefit us by making our commit history simpler to read & understand.

2 Likes
9

Week of 9/4 - 9/10 Update

Overview
We continued to build our 3-motor swerve modules and built our new robot cart this week. We also continued refactoring our swerve drive code for 3 motor swerve, and began working on our scouting website for future seasons.

Mechanical
We continued assembling the modules at step 6 since that is where we made it last week. We made sure to use loctite on all the screws in step 6.

Since we custom made our top plate, we had to order screws that were separate from those that came with the module.

While working on step 8, we noticed that a shaft for one of our Falcon 500 motors was wiggling, so we continued with steps 10 and 11 from the SDS Mk4i Swerve Modules Assembly Guide. We had to tap the encoder mounting holes and encoder enclosure since the plates are custom and we did not make them tapped to reduce cost.

In addition to building the 3 motor swerve modules, we assembled our new robot cart. We bought it with upgrades in mind, such as adding a space to place the driver station on and battery holders.

Software

In terms of software, we finished fully migrating our code to the Phoenix 6 library. We changed the stator and supply limit configs for the Talon motors, changed our rotation gear ratio from SwerveX to SDS MK4i, and also added CANivore support to our motors. CANivore increases the number of CAN FD Busses that can be added to the RoboRIO, and due to the additional motors and motor controllers for 3-motor swerve, we decided to buy the CANivore device and configure it in our software. The configuration process is very simple, and it requires one to pass in the string name of the CANivore’s name or serial number into a supported device’s constructor, and then the device is added to the bus(Link for reference).

Additionally, we have been working on a scouting app that we will be using for our 2023 off-season and future seasons. The software students have configured NodeJS and their development environment, and are now in the process of learning how to use the AngularJS web development framework in order to contribute to the app.

3 Likes
10

Just checking, you know that 12/3 motor swerve is going to be banned in the 2024 season, right?
Building it for offseason still makes sense but I just wanted to be sure.
The modules look super cool, though.

11

It states earlier in the thread that they are aware of it.

1 Like
12

Oh, sorry. I tried to read up, but I guess I didn’t read well enough.

13

9/11 - 9/24 Update

Overview
We finished building 4 of our 3-motor swerve modules and worked on our spare module. We wired the robot and finished wire management. We also finished debugging our 3-motor swerve code and completed PID tuning for the rotation and drive motors.

Mechanical
We continued assembling the 3 motor swerve modules. Our drive pinions were not at the correct height, so we 3D printed spacers to make them fit better. We also had to replace a spline shaft on one of our falcons. When we went to mount the modules on the robot, we noticed that the center falcon on all the modules hit the belly pan, so the module would not sit correctly.

The orientation we originally had the falcon in made the wires get crammed against the PDH, so we rotated the center falcon on all our modules so the wires point to the side. The bottom of the falcons also had a section that stuck out farther, so we turned the second drive falcon to the side so we didn’t have to cut the belly pan for that.

We cut our steel belly pan using a jigsaw, but the blades kept getting ruined when we tried to cut the aluminum frame, so we switched to using a hacksaw.

When mounting the swerve modules, we noticed that the wheel hit the bottom plate when we were trying to spin it. We took our old swerve X top plates to fix the issue and used a bandsaw to cut notches into it so we could use it as a replacement. Since we used the Swerve X top plate as our bottom plate, we didn’t have long enough bolts, so we used thinner locknuts. Some of our mounting holes were misaligned, so we drilled new holes.

Our spare swerve module got loctite stuck in the hole for the non-bevel gear fork, so we couldn’t get the bolt fully screwed in. We tried using acetone to take it out, but were unsuccessful. We tapped the hole again and got it to work. We broke a tap off in the encoder mounting hole on our top plate, so we hammered it in so it was flush and used the other set of holes we had.

Our original vanity bumpers were sewn at an angle, so we used a seam ripper to undo the stitches. We then correctly sewed the fabric in a straight line, added our name and number with white vinyl, stapled it to the robot, cut the extra fabric, used gaffers tape on the inside, and added brackets.

We remade our cover panels so they now cover our battery since we removed the hopper and our arm now telescopes down and hits it when the robot is disabled. We used white polycarb to make it and velcro to mount it to the swerve covers on the robot. We made sure to add a label to indicate the main breaker on the robot.

Electrical

We added anderson connectors to all of our swerve modules. We used double sided tape to attach the spark max’s to the top of the swerve plate since we didn’t have time to 3D print our covers that had the spark max holder on them. We added the CANivore to the drive base and wired the CANbus. When testing our robot, we noticed that some of our andersons were not pushed fully into the plastic casing. We needed extra batteries for 3 motor swerve, so we added leads to those. We fully wire managed our robot. We had a CAN wire that was hanging over the PDH, so we added an extender. We lost two spark maxes while testing 3 motor swerve. We don’t know why either of them stopped working.

Software

Voltage code was completed and we worked on switching our controls from co-drivers to driver operator. We had a scoring driver and a loading driver for this past season, but we decided to go back to the driver operator model to make it easier for the drive team to have to focus on fewer things at once. We added a wheel lock at the last 10 ms of auto, fixed the game piece eject bug, added 8 new autos using our floor cube pick up, configured motor ID for the drivebase, and created an auto manager to make it easier for the drive team to select autos before a match. Our robot initially had issues with break mode, but we resolved those issues. When testing our robot at a practice field, the robot couldn’t drive straight. We created a version of autorotate to make sure we keep our heading degrees the same when we drive straight. We tuned the drive PID and updated our max speed and max acceleration values.

2 Likes
14

Just to confirm, two different students swapped off controlling the drive train of the robot in a match? How did you handle the transition between the two controls?

15

Our loading driver would drive the robot from the community to the single substation and while they were doing that the scoring driver decided what piece we wanted to score and would change the led colors to let the human player know what we want. Once the piece was in the robot, the scoring driver drives the robot back from the single substation to the grid and scores it. Our human player would give the drive team a thumbs up when the piece was in the robot to signal to our scoring driver that they were good to drive it back. As soon as the piece was scored, our loading driver knew that they were good to get another piece. Whichever driver was in control of the robot during endgame was the one who would dock and engage the robot on the charge station. Our loading driver would say “intake” so our scoring driver knew that everything was good while they were looking for the best place to score a piece. I was our scoring driver this year, so when I decided what piece to score, I would just say whatever piece we were going to score and where I was scoring it.

1 Like
16

Thanks for the explanation!

1 Like