Week 1 and 2 Update
It’s been a while since our last update but we’ve been hard at work! Our meetings have been going from 3:30 until around 8 with different groups meeting at different times so finding time to write everything up has been difficult! Below is a progress update for every subsystem.
Drivetrain
Design:
We finished up with most of the drivetrain assembly this week. We CADed the bumper wood, the angle bracket connecting the wood, the bumper mounting mechanism, as well as the actual bumper itself. In addition, we moved the main breaker to inside the feeder and changed some electronics placement on the brainpan since some electronics were clipping. However, since we had already ordered the brainpan, we will just secure the electronics another way (zip ties). We are basically done with the drivetrain and moving onto next week, we will just make sure that everything looks correct and look out for any clipping.
Week 1 CAD Progress:
Week 2 CAD Progress:
Mech:
-
Swerve Assembly
- 6 MK4i swerve modules were assembled this week in with the motors mounted from under the top plate. 4 of them were fastened to the drivetrain rails, each using 6 bolts that go through the bottom plate, drivetrain rail, and middle plate. This configuration allowed us to conserve the most space on top of our brainpan while also allowing proper clearance near the wheels so that the motors weren’t in jeopardy of being damaged. The process of assembly was generally easy; we just watched the assembly video. We made sure to loctite all of the screws (not just the ones the dude mentioned in the video) because with the amount of pressure put on the wheels, it’s important for the module to stay together and strong. We also bought 5 extra wheels and large bevel gears because we think that the fastest way to switch out tread during competition (when a wheel’s tread is worn down) is to actually switch out the wheel with a freshly treaded wheel. We originally thought this would just entail taking out the axle screw that goes through the wheel spacer, but after taking that out, the wheel still doesn’t come out due to one of the triangular axle supports blocking the wheel’s movement when sliding out of the bevel gear meshing stance. So we had to take out two more bolts to take off one of the supports as well. Since it’s just 3 bolts with some alignment, we still think the process is faster than retreading on the same wheel.
-
Milling rails with the CNC
- We milled all of our drivetrain rails this week. This consisted of running pocket operations to add holes spaced 1/2” apart on the 1” and 2” faces. While we were waiting for our edge-finder bit to come, our method of zeroing the bit on the tube was different. We knew the x and y distance of the center of the first hole (the aluminum tubing comes with holes that are spaced 1 inch apart), and so manually moving the bit into the center of the first hole, we tried to see if the nozzle would spin freely by hand, and based on where it seemed to get stuck, we would adjust its position very slightly so that it spun freely, meaning that it was at the center of the whole. At that position, we set the x and y positions of the nozzle to the distances we knew that the center was at, and this sets the zero position of the nozzle exactly at the corner of the tube, which is where we want it to be before the operation starts. At certain times, this strategy seemed to have failed us because the holes seemed off-centered, but this could have been because there was coolant or metal shards in between the tube and the tube magic support which offset the tube a tiny amount but enough to make a difference in the hole. We were also kind of lacking in 4mm bits at the time, so we were using a dull bit for some of the pocketing in fear that we would be wasting a new bit if it broke quickly, and this made some aluminum threading stick to the edges of the holes, which could also be a source of misalignment if there weren’t cleaned off properly.
Controls:
Last week we created auto paths using PathPlanner to test out and finalized conversion from using Neos to Falcons in code for the new drivetrain and flashed 2022 firmware onto the roboRIO. Our practice drivetrain had two broken neo 550s which prevented us from testing our auto code. Once we replaced that we seemed to have a drifting problem last week.
Like last week, we started this week off by trying to fix our practice drivetrain. All the motors were replaced but the drivetrain was still slipping as seen in the GIF below. We tested the drivetrain on 3 different types of flooring: gym flooring, normal tiles, and carpet, but the slipping still persisted.
This resulted in the robot not being able to move straight when instructed which hinders our ability to tune auto. From here we limited what the problem could be down to three possibilities:
- The tread used on the front left swerve wheel (the wheel that is slipping in the gif below) might need to be replaced as it wasn’t gripping the floor enough
- Weight on the practice drivetrain (which at this point was just a bare mule chassis with a roboRIO, 4 swerve modules, a radio, SparkMAXes, and a PDP + VRM) wasn’t distributed properly which was pushing one side of the chassis down more than the other
- The drivetrain frame is warped (the sides aren’t leveled which causes one side to be higher than the other)
We moved forward with solving possibility #1 but found that the practice drivetrain was still drifting. We then attached our 2019 feeder + shooter mechanism to weigh the chassis down but the drivetrain continued to drift. Ultimately, we came to the realization that either the drivetrain is warped or the problem is something else that we didn’t necessarily have time to figure out as we needed to move forward with auto testing.
So, we took the roboRIO that we flashed the 2022 image onto and put it onto our 2021 robot. After replacing a NEO 550 on the 2021 robot, we got the robot to stop drifting and moved on to fixing the CANcoders.
Additionally, our practice drivetrain didn’t have working CANcoders so we took them off and changed our drivetrain code so that it would zero itself at whatever starting position it has when the robot turns on. This temporary fix was no longer needed once we realized that we were going to move to the 2021 robot so we reverted our changes and changed our code back so that it makes use of the CANcoders.
After some soldering and making sure that the IDs and names of the CANcoders in Phoenix Tuner correspond to what we have in code, we had an error which is detailed here. To summarize what was written in that Chief Delphi post, there are some dependency issues that need to be solved and we are currently trying to figure out if there is a solution that doesn’t require moving the missing file in manually.
As for auto-related tasks, we are continuing to design more and more paths on Path Planner with the hopes of testing them and tuning them once our CANcoder dependency issue is fixed.
- Currently, our
CTRE-Phoenix library is outdated. The latest CTRE-Phoenix JSON file is located here we were just referring to a different latest-json link. With this solved, we hope to start tuning auto.
Intake
Prototypes:
Finished and tested full protopipe of intake. Decreased the size of intake due to the amount of PVC we had, but the design still fit the space needed for the ball to enter the mechanism. Our initial design had 6 rollers but we ended up only using the first 2 because of the number of drills we actually had available. Each roller had hex shafts with TTB 2 inch compression wheels spaced across it. Our prototyping results found that 9.25 inches center distance of the shaft to the ground was an effective compression level and approximately 7-7.5 inches between the first roller to the bumper. Video results of our prototypes can be found below.
intake_protopipe_test3.mov
intake_protopipe_test2.mov
intake_protopipe_test.mov
Design:
Designs for the intake are well underway. We’re taking heavy inspiration of our intake design from 1678. We’re using TTB inserts on pulleys this year to address issues in stripping out of the 3d printed parts. Last year, we used a 3DP Falcon shaft bore to power our pulley, which would strip very easily. We tried to replace that pulley with a TTB insert over the summer, but that pulley was too small, so we’re being sure to include the inserts in our design this year. With our increased 3DP capabilities, the inserts are proving to be a very useful tool.
One of our main lessons learned from last year’s intake was how important it was to protect our pneumatics. We made sure when our intake was extended, our cylinders would be retracted, and vice versa. The four-bar should also hopefully add some flexibility to the system, which should also help. BTW, this is our first year (in a while at least) designing a four-bar mechanism like this, so any feedback would be much appreciated. 
Controls:
Last week we added intake.kt file with all the motor and pneumatic init with Logger caching. Added 6 basic commands for intake with triggers (IntakeBallsCommand.kt, LiftIntakeCommand.kt, PrepareClimbCommand.kt, ReverseIntakeCommand.kt, intakeCommand.kt, intakeIdleCommand.kt). This week we completed commands and fixed the suggested edits in out subsystem pull request. We added a limit for the motor power to fix problems from last season where the motors were drawing excessive power and drawing the battery very fast. We worked with the feeder team to figure out additional commands for intake and feeder. This week we will refine the code and continue to build out our multi-system commands.
Feeder
Mech:
More work on the prototype was done but in the end, the design was scrapped. We tested out a design with 2 separate feeder belts on 2 separate tables due to a lack of specific 3d printed parts. Then once the necessary pieces (mostly bearing blocks) were printed we tested a design with 2 feeder belts in one enclosure. After struggling with the poly cord belts we decided to scrap the design entirely because we were wasting time on the prototype when we could use compression numbers from other teams and compare to what we’ve used in previous years. We then decided to focus on the intake prototype instead because that’s a more important system in our design.
Design:
Last Week:
We finished designing the support structure of the feeder with crossbeams and gussets. We then CADed polycarb plates to mount our system of rollers, pulleys, and motors. The feeder is run in two separate sections, the horizontal and the vertical. Both are powered by a Falcon 500 and a REV MAX Planetary gearbox. We constructed the feeder funnels to direct the path of balls and its support pieces to attach to the crossbeams.
Week 2:
This week we made a lot of the adjustments we planned last week and basically finished the feeder assembly. We widened the feeder by half an inch on both sides to make sure the shooter would be wide enough for the 9.5 inch ball. We noticed that the motor powering the vertical section, which was originally on the bottom most shaft, to clip the climber, so we moved it to a different shaft. The widened feeder caused the outer gusset on our back vertical support to clip the swerve module; we were worried changing to using only a tube plug would weaken this attachment, so we kept the inner gusset in addition to it. Finally, we moved the motor powering the floor of the feeder to the other side so it wouldn’t clip the intake.
We also put in the electronics that are mounted on the feeder this week. We made new enclosures for the beam breaks and the radio largely referencing 1678’s on their 2910 clone robot https://cad.onshape.com/documents/eb7bd33298144810d3e0e352/w/0e9d896cbf3512f708ac5616/e/cfcfe5709333671783f3d666.
We’ve been running into an issue with Onshape kicking us off the document because the resource limit has been exceeded, and this is probably because of the way we mated the polycord belts. Next week, we plan to work on adjusting the mounting position of the beam breaks so they can detect as soon as a game piece contacts the vertical section of our feeder and we need to start spinning the polycord. We also hope to reduce the general weight of the feeder by considering minimizing the use of our rollers and polycord as well as pocketing our funnel plates. Lastly, as we finish up on the feeder assembly for this season, we hope to move on to CADding Team 4414’s roller feeder, https://youtu.be/-RMvPizLDHA, which has a more complex design, to refine our CAD skills and provide another option for our robot.
Controls: Last week we finished the subsystem file (Feeder.kt) including the init section and a ball count function. We also set up the Constants.kt file for feeder with temporary values for the motors and beams as well as the FeederState enum class. We created three commands (FeederCommand, FeederIdleCommand, and FeederSerialize) and are waiting to see if we need more after design is finished. This week we plan on working with intake to create commands for the subsystems to work together and are going to start thinking about auto mode. This week we fixed motor logging issues we had from switching from SPARKMAXes to Talon FXes. We fixed the issues outlined by the comments in the pull request; we put in the correct IDs for the motors and changed variable names for clarity. Also, we added triggers in ControlBoard.kt so the controller can interface with the feeder as well as importing the subsystem and commands in Robot.kt. We talked with Intake to figure out how we were going to implement the multi-system commands. This week, we will continue to update our code and flesh out other multi-system commands
Shooter
Design:
Last week we CADed shooter plate and started assembly for a single flywheel shooter. We started with the positions of our flywheel and accelerator wheels from our full system sketch, and we made appropriate belt calculations to determine to modify the precise positioning of our rollers and motors. From there, we sketched positions for standoffs supporting our hood and outlined a plate based on all the components. Venting took a lot of trial and error, but we ended up with a web kind of design that we were satisfied with for our shooter plate.
Working with the feeder group, we decided that the shooter plates would be mounted on the inside of the feeder support tubes while feeder plates would be mounted on the outside. We still had to leave room for the shaft going through the top feeder roller to pass through, so that’s why we have the 1.125” hole in the bottom right of the shooter plate in the first screenshot.
At the end of last week, we determined that we wanted top rollers on our shooter to reduce backspin (which would help lessen of upper hub bounce-out that Team 7592’s testing found to be a significant problem). As a result, we spent this week reCADing our shooter to include rollers on both sides. Our main reference in creating our design was a 4414-style shooter. The back rollers are designed to be the same as the front accelerator wheel rollers (nine 2” REV Grip Wheels on a shaft for each roller). We have a pulley running from our motors to our flywheel, which runs to the front accelerator wheels as well as a gear in the back that flips the direction of rotation for the back rollers. This week, we redrew our shooter plate sketch, made a new assembly with many more rollers, CADed a triangular bearing plate to support the gears, added more standoffs, and repocketed the shooter plate many times along the way.
For the gears, we started with two 30t gears but then discovered that it clipped with the feeder tubes, which had already been milled at that point. We then opted for a smaller second gear (24t) and increased the size of the first gear (36t). This changes the gear ratio, but we’re thinking that the extra speed to the back rollers may help reduce backspin further.
Like all the other subsystems, we need to figure out ways to cut weight off of the shooter (which is currently slightly under 20 lb.). We did pocket the back part of our shooter plate a little bit more, but we need to find other ways to reduce weight (probably in the rollers).
Controls: We continued researching PhotonLib and PhotonVision and writing commands for vision-based alignment. We also continued working on the command to adjust the robot’s position when lining up for a shot. We started to implement the math/projectile motion calculations to get an approximate heading and distance from the hub for the best shot as well. Some challenges we ran into while writing code were ambiguities in PhotonLib/WPILib documentation, so we had to make some assumptions that we will throughly test out later once more code is finished. It also took some time to figure out a good way to “approach” aligning the robot, since multiple systems of the robot are involved, like the shooter and drivetrain, and some physics. For the coming week we “aim” (no pun intended) to get more of vision-based alignment code done, as well as start adding actions to the Xbox controllers.
Climber
Design: This week, we finished CADing the telescoping arms and putting them into assembly.
We also implemented our traversal climb mechanism. Our main reference for the traversal climb mechanism is 1986’s 2013 climber. We are using the MAX Planetary gearbox with a NEO and a 125:1 ratio. Originally, we wanted to use Falcons on the traversal climb mechanism as well, however we realized that by using a falcon, the motor would extend beyond the frame perimeter. Our solution to this was to just use a NEO instead. We have a 12:36T #35 chain sprocket ratio. Our arms use a dead axle roller to make sure it can support the weight of the robot. We have a .25” polycarb spacer between the tube and the sprocket. We have bushings to make sure that it can rotate smoothly.
Dead axle:
Full traversal assembly:
We mounted this entire mechanism on a 2x2 tube because we want to mount the 2x2 tube onto the feeder. We saw that in the full assembly, our gearbox plate was clipping the feeder’s motor. It was an easy fix to just make it smaller. This week, are going to redesign a hook for the new pair of arms and also figure out a way to attach it to the feeder. In addition, like other subsystems, we are going to look for ways to cut weight off the climber.
Controls: We created the Lock Climber, Move Pivot Arm, Move Telescoping Arm, Open Loop Climb, and Unlock Climber commands. Changes were recommended in our pull request such as renaming variables to make them easily understandable and adding two motors to each arm rather than one for each arm, which we have been working on. We have been working on making carefully considered decisions related to how the arms would be coded because they operate separate from each other. The current code has them both under one subsystem with different settings, variables, etc. for each arm, however we are considering creating two subsystems, one for each arm, which would avoid confusion between the two arms in code and would allow them to easily operate independently. The main con of this would be that depending on whether the climber operates autonomously or by driver control, there may need to be commands that use both subsystems at the same time. Depending on the decision we come to, this week we may have to make drastic changes to the code.
Plans for week 3:
- Wire the entire drivetrain and do it well so we don’t have to do it again.
- Start building the robot as pieces get milled
- Mill everything
I want sleep - Zac
. I got an email tonight that it shipped but because we ordered with standard ground shipping, not knowing how much the order would be delayed, that means we will only get stuff in on Saturday.
. We’ve already cut and welded the polycords for the rest of the robot, so hopefully we can salvage some of that by shifting which cords go on which axles.
