Amazing information in this post, go take your well-deserved nap! One possible solution for scoring in both the upper and lower hub from the fender is to just adjust the flywheel rmp. This would have to be verified during testing, but I believe that the angle required to score in the upper hub might work to score in the lower hub. Let me know your thoughts!
As a side note, I would love to hear more about notion. As a captain in my senior year, with the recent exodus of many knowledgeable seniors, I am struggling to coordinate subteams and individual people and ensure that everything has something meaningful to do instead of sitting in the back of the room “practicing soldering skills” (aka seeing just how big a pool of solder one can make). Yes, that was actually a favorite hobby of some kids and was promptly shut down once it came to my attention. Thank you again for all of this insight. It really helps teams like mine that are trying to rebuild!
Awesome write up. This is Mr. Ames from 4638 “Jabots”. If you need access to a CNC mill let us know. I know you have the router but if you need a real mill we can help.
Oh my gosh!! I’m very glad our team has never had issues like that!
Since starting to use notion 2 years ago to do planning instead of google sheets and docs a lot of our planning has been better organized and understandable! In terms of just our task board: it’s made from 2 connected databases (which are like more advanced excel sheets). We have the “Epics” where long tasks like “Finish Full System Sketch” are created. We’ve laid out our entire season with these epics and they have different properties like the subsystems and subgroups involved, and priorities. This is a screenshot of the epic database with the timeline view which helps us know whether we’re falling behind:
The Epic database is then connected to a “Tasks and Bugs” database which holds all of the smaller items that have to happen to make each epic happen. Because each epic is connected to the tasks database we’re able to assign the specific tasks to an Epic and you can view them organised as such (image below). Each of the tasks have different properties like who’s assigned to them, subgroups and subsystems, priority, and their own timeline. Our system so far has been very helpful in tracking progress and also making sure people know what needs to happen, reducing the strain on leads and the necessity for them to be with each group all the time.
Hello Mr. Ames! Thank you for the offer! We were wondering what your team is doing for field parts this year? We’re working with the MC campus to let us do practice in their space and we’ve bought the upper hub piece from AM. If you were planning to build the hangar setup we were wondering if it would be possible to test our climb later in the season?
We are limited. Next to my room is a stairwell with a landing. We will most likely set up a mock upper hub in the stairway to test trajectory. If we have time for driver practice shooting high we will take it to the gym.
As far as hangar, IF we decide to climb and traverse then we will build a setup similar to this and do it in our shop / my room. If we do that, your more than welcome to come over.
Our mech team is hard at work right now on prototypes! We’ve finished building the structure for our intake and the feeder structure is underway and should be finished today! Protopipe has made our prototyping so much faster this year and we should be done prototyping our Intake, Feeder, and Shooter all in week 1, something we’ve never been able to accomplish before!! We’re currently waiting for our intake rollers to arrive (today) and we can start our shooter prototype after today when CNC fixes hopefully are finished (putting on new wcp tube fixture)
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:
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.
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.
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.
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.
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’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.
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.
Full Robot Assembly (Drivetrain Day 1) Week 3 - Day 4
Fabrication of the final robot has begun! Last night we finished mechanically building the drivetrain with all of the swerves we assembled earlier in the week. Here is a progress update along with a couple of struggles we ran into during the process:
Warped Brainpan
This year in order to cut our brainpan we used SendCutSend to laser cut the piece after CADing it. The process was very quick and fairly cheap but because it was laser cut the entire piece is warped by a couple of thousandths of an inch. This made actually riveting the brainpan to the rails fairly difficult. It got the point of having someone hold onto the brainpan with a hammer from the top and pulling it with their feet resting on the rails while another person pushed down on the rivet from above. We found that riveting down two sides made the other sides much easier to get as the tension in the brainpan was readded into it.
Final Brainpain Assembly:
After spending about an hour longer than we should have needed because of warping, the drivetrain was fully assembled.
We also began wiring the robot but progress for this didn’t make it too far because of how long assembly took. We’re going to be continuing with our wiring this year but one thing we noticed last night that will make it difficult is how easily the silicon wires bend making crimping much harder. Because the wires bend so much sticking the crimps into the housing is very difficult to do and very frustrating. We found that a combination of pushing from the end with an electrical screwdriver and pulling from the top was able to get it in but it’ll be very annoying to start doing this for every single connection!
Battery Bulges
While searching for screws in our storage room I discovered that one of our batteries had begun bulging out and leaking while charging! The battery was one of our worst in terms of internal resistance and leaving it plugged into the charger had some pretty terrible effects!
Next steps:
Today we plan to continue wiring with our drivetrain. We’re going to take as much time as it takes to get everything neat and correct the first time because we know how terrible electrical issues later in the season can end up being.
I told myself (and Zac) that I would write some of the week 3 recap, then I got super busy and forgot and now it’s the end of week 4😬. Instead, this is what the students put together for summarizing what got done in week 3 (outside of the drivetrain stuff already posted).
Also, here’s a picture of one of the things I was busy with during week 3:
We finally got access to a classroom space at a local community college that we can use for driver practice. Still pending are the field elements and some plywood to line the drywall with so we don’t destroy their space. Unfortunately we will have to drive out here for driver practice and testing on our upper hub mockup, but that’s the reality of being a team from a small high school (we don’t have the classroom space to be able to set up anything semi-permanent).
I’ll write the week 4 post soon, I guess
Intake
Controls: Worked on programming LED states. The robot has states and changing colors based on if it has 1 ball, 2 balls, or no balls. Also there is a blinking pattern if the intake or shooter is running in order to indicate the subsystem is running. Also Blinkin Driver was configured with variable colors. This week we will continue working on the LED states and testing with the robot to see how to better integrate with other subsystems.
Feeder
Design: This week, we worked on adjusting the placement of our 3D printed beam break mounts so they weren’t clipping the climber in our full robot assembly and were in the optimal location for detecting when to start spinning the vertical section of our feeder. We originally wanted to align the beam breaks with the first part of the game piece that would leave the horizontal feeder, but because of the climber arm, offset it a few inches above.
In addition, because where we originally had our radio and RSL mounts was outside the frame perimeter of the robot, we repositioned them to be on the front and side of our back beams. Furthermore, we finished BOM for our subsystem, inventorying each manufactured and COTS part found on the feeder. Lastly, because our robot was over the weight limit, we worked on CADding an alternative option to our back rollers for the vertical section, instead trying to replace them with a curved polycarb plate and relying only our front rollers to spin the game pieces up.
We tried to have the polycarb follow as close to the original path as possible, making sure our ball compression was adequate along the entire way. Because we’re going to use zip ties and standoffs evenly spaced along the polycarb to fasten it in place, we made new side plates with standoff mounting holes that excluded any unneeded gearbox holes and bearings. We started a new assembly for this new feeder as well. Next week, we hope to continue working on the curved polycarb assembly and finish fastening it in place. In addition, we recognized that because there weren’t any more back rollers, we have to move the positioning of the MAXplanetary to spin the front rollers and be higher up on our robot. We hope to make a larger plate to accommodate that. Finally, if we get the chance, we want to begin CADding Team 4414’s roller feeder, https://youtu.be/-RMvPizLDHA, for an alternative option and to refine our design skills.
Controls: Feeder code was finalized last week so we talked to shooter about feeder + shooter commands and worked with climber to implement their code.
Shooter
Design: This week, our main focus was cutting down the weight of the shooter. First, instead of using a vented aluminum plate, we changed the material to polycarb and removed a majority of the venting. We created a venting pattern for the portion of the plate which attaches to the tubes, as we determined that each hole did not need to be attached to the feeder tubes.
We also decided to decrease the number of accelerator wheels (2” REV Grip Wheels) on each shaft from nine to seven. To more significantly reduce weight, we also determined that two of the back accelerator wheel rollers were not absolutely unnecessary, so we opted for a design that had a shooter hood to replace the two rollers. Our hood consists of a polycarb plate that has holes that will allow us to ziptie it to standoffs.
We also wanted to slightly reduce the amount of ball compression in our shooter (we originally had 2” of compression). However, we already ordered our belts and gears, so we were limited by how much we could adjust our compression by. Our design now has 1.75” of compression for the cargo going through it. Making this change shifted the geometry of our shooter plate, and we had to fix issues with the edge of the plate clipping the feeder rollers. Overall, we altered the positions of many standoffs on the shooter.
Another one of our major additions for the shooter this week was creating a camera mount. Like last year (2021), we are using a Gloworm and mounting it to 3D-printed piece that is supported by standoffs. Based on the geometry for our fender shot, we are angling the camera at 60º above the horizontal. We wanted the standoffs supporting it to reasonably fit within the shooter plate while staying a sufficient distance away from the flywheels and other standoffs. We added standoffs and adjusted positions of other standoffs to account for this change.
In the upcoming week, we plan to make adjustments to the shooter design based on the results of mech prototyping.
Controls: For programming, we continued writing vision-assisted aiming functions and finished the shooting/spin up command. Buttons on the Operator controller were assigned to shooting functions as well. On the electrical side, we started thinking about how we would route wires for shooter components.
Climber
Design: This week, we decided to pocket the tubes and gearbox plate for the traversal climber to cut weight. We decided that because tube with the hook on it had thin walls, it wouldn’t be worth the extra milling time to pocket them as pocketing them barely cut any weight. We decided to pocket the 2x2 mounting tube for the traversal climb mechanism because those tubes are thicker and would cut weight. In addition, we vented the gearbox which also cut more weight as it was also a thicker aluminum plate.
2x2 tube:
Gearbox plate:
We also created new hooks for the traversal climb and put 3-1/2” long 10-32 screws into CAD as our mounting mechanism onto the feeder.
Full Assembly:
Controls: We split the code into two separate subsystems, the pivoting climber (traversal) and telescoping climber (climber). We created constants files and commands for each. We still need to decide how the two subsystems will operate relative to each other. We needed to refactor the traversal climber’s code to incorporate neo motors rather than falcons. We intend to complete this next week.
Drivetrain
Design: This week, we put in all of the fasteners needed for the drivetrain. This includes countersunk screws to connect the bumper wood together with the angle bracket as well as the screws for the bumper mounting plate. The last thing that needs to be done in the CAD is putting in the bumper numbers, but besides that, the drivetrain CAD is done!
I’m back! Sorry for the double post, most of the content for the week 3 update was actually done in time for the end of week 3 but I forgot to post it
Anyway, after talking with the students before the season started, we decided that by contrast to last year, most of the blog posts would be written by students. I can’t see everything, and I can’t be at every single meeting, plus it’s a lot of work to write all of the blog posts myself. But I actually enjoy writing these, so I told myself I would write at least one. That will be this one, I guess.
Thanks! I definitely do feel appreciated, but I also want to say that this goes both ways. I know that I wouldn’t be able to do what I do as a mentor without the students on this team doing far more than their part to keep the ship afloat. The leadership groups for all of the four years that I’ve been mentoring have been incredible and filled in a lot of gaps that ideally would have been filled by other mentors.
And it’s also worth pointing out that while I am the only active mentor for 4099 for now, there are lot of other adults who play a role in making sure the team is successful, including teachers who handle paperwork and supervise some meetings, parents who manage their own kids’ transportation but also sometimes run carpools, families who are hosting team equipment (from robot parts to the machines that make all of those robot parts), the church across the street from the high school where most of our build work happens, and probably a ton more that aren’t immediately coming to mind.
I guess this is as good of a place as any to say that this will be my last year as an active mentor for 4099. I am moving to the Bay Area after graduating from university at the end of this semester, and the 36 hr driving commute back to Poolesville just isn’t practical for me. I still hope to be a mentor for some team for many years to come, so as we get closer to the summer I’ll actively start looking for a team to mentor. I think pretty much any team will have some challenges to overcome when losing a lead mentor, but I’m confident that this team will be able to overcome those challenges.
On a related note: if you’re in MD/VA with a reasonable commute to Poolesville and are interested in mentoring 4099, DM me
But that’s enough of my life updates – now, onto the actual team recap:
Rehan (our mechanical subteam lead) with the robot as of Friday
It drives!
General Updates
Lost in the mess of the week 3 update situation was that the vast majority of robot parts were milled and powder coated starting week 3 and finished by early week 4. Our realization about the robot weight (that it was probably going to be at least a little over the limit) was just before when we were going to start machining. We made the decision to make most of the robot sheet parts out of 1/8" polycarb rather than pocketed 1/8" aluminum or unpocketed 0.09" aluminum. So far, this decision seems to have worked out fine, but we will see, I guess, how it goes after testing the robot more.
Stress testing the polycarb shooter to see the limits for how much it will wobble with all of our standoffs in place (the answer was not very much).
We still have a few things to manufacture – bumper parts, 3D printed pulleys, and intake plates being the big ones – but for the most part, what’s left is now assembly, some wiring, and software. Also, we are still waiting for our Greyt telescope (ordered on kickoff day) to come in . 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.
Our Prusa MK3s set up with a Garolite print bed and a hardened steel nozzle ready to print some more NylonX pulleys
Mechanical Update
In parallel with the drivetrain being built in week 3, we also built our MAX Planetary gearboxes for the feeder and traversal climb mechanisms. This included changing the shafts on a few of our Falcons – enough for these mechanisms, our intake (which also needs an 8mm keyed shaft), and spares for all of those mechanisms.
Next, we focused on building the feeder structure. That got built relatively quickly, with a few minor hiccups. We somehow machined the hole pattern in one of our feeder tubes to be a little too small (like the holes were undersized for our rivets). My best guess as of now is that we used an old and extremely worn out bit to make those holes, but I’m not sure if that would cause this severe of a size issue. In any case, drilling out those holes was enough to make it work, so it wasn’t a big deal.
We also lost a little time waiting for a McMaster order to come in, because we needed nylock patch screws instead of applying our own Loctite, since everything is now going into a polycarb plate. But once those issues were resolved the feeder structure assembly was relatively smooth.
Where it got interesting, though, was the polycord belting for moving the CARGO through the robot. It’s been a while since we’ve used polycord, so we didn’t really have a gauge for how much to shorten the polycord relative to the belt length measured in CAD. We found on CD somewhere that a 10% reduction in length would get good tension, so that’s what we went with, but we ended up with this:
We could tell it was taking a ton of force to line the shafts up but we didn’t realize just how much force it was until after the shaft was in place an we could see how much it had flexed. Of course, we immediately disassembled it and both shafts seem to be fine now. In later testing we shifted the location of that shaft (in one of the only uses of our hole pattern on our tubing in the few years we’ve done it, lol) and found that shifting the center to center distance closer by 1" finally got what we would consider the “right” amount of tension on the belts. That means our cords were 2" too short . 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.
We’re also trying something new for bumpers this year, which I thought would be worth sharing. Basically, for the past few years, we’ve had issues with our bumper frame not fitting over the robot as nicely as CAD would have us think. This is partly because our Omio X8 has just barely not been able to fit the bumper wood (because we’ve been building large robots), so we have to manually make the bumpers. Unfortunately our manual measuring skills aren’t great, especially at getting precision on 30ish inch pieces of wood. This year, we’re trying printing a 1:1 scale drawing of the bumper wood using the school’s poster printer, and basically stenciling the wood and cutting/drilling it that way. Hopefully, we’ll get some better results – but we’ll get back to you on that in week 5.
Controls Update
It drives now (see video at top of post) so we clearly fixed this issue, but this was a very annoying thing to fix on Saturday. Basically, the issue was we had tuned the steering motor PID on our MK4i using Phoenix Tuner pretty effectively, but when we ran our robot code, the steering motors would start off by being a little jittery, not settle at the right angle, then eventually do what you’re seeing in the GIF – just start spinning in circles continuously.
Long story short, it turned out to be a simple software issue – the not settling at the right position was caused by some anti-jitter code we had to put in place last year, because for whatever reason setting an allowable closed loop error wasn’t working for us with our NEO 550 steering motors on our Thrifty Swerve. With Falcons on the MK4i modules, we have had no issues with the CTRE-provided allowable closed loop error functions. But when removing that old code, we also found that while we had tuned our steering motors using Motion Magic, in code, we were using Position PID. This meant that we had a feedforward set for Motion Magic, which multiplies the feedforward by the velocity setpoint on its internal motion profile. But when using plain Position, the feedforward is multiplied by the position setpoint – which, in motor ticks, kept increasing as the modules rotated.
Basically, the lesson learned was that we should always trace through the code before going through more complicated debug steps – we had graphs of everything set up in Glass to try to figure out what was going on.
Before this, the roboRIO 2.0 and radio were flashed and firmware was updated on all of the hardware currently on the robot. All of that went relatively smoothly compared to issues we’ve had in the past. We also switched the type of encoders we’re using on our swerve steering from CANcoders to the Thrifty absolute encoders. So far, I think we prefer the Thrifty encoders – the wiring is much simpler, with just a PWM cable run into the roboRIO, and running the control loop for steering off of the Falcon’s integrated encoders seems to be working fine for us. Zeroing the encoders was also far simpler than it was last year – though that was because we tried to use the CANcoders’ built in offset functionality, when we could just have computed that offset in robot code like we’re doing now.
One other thing we’re happy with this year is our gyro. Last year we used an Analog Devices SPI gyro, but this year we’ve gone back to the NavX we used in previous years. The NavX 2.0 has far less drift than the Analog Devices gyro from last year. Last year, if we spun in circles for 3 seconds, the gyro zero would be off by 10-20 degrees, which made driving significantly more difficult. If you watch offseason match footage from our 2021 robot you can see our driver zig zagging across the field because by mid-match, the gyro angle would have drifted by enough that going straight was far easier said than done. This year that seems like it’s going to be less of an issue.
Design Update
For the most part, the design work for v1 of what we are building has been done for a while now, but the intake has seen a few changes:
Initially, the green plate that is used as the mounting point for the four-bar pivots spanned the whole width of the robot. We thought we would be significantly under weight at the beginning of the season, so we were okay with a 1/4" polycarb panel doubling as a sponsor panel. Now, with weight being a concern, we cut that plate down meaningfully and added in a 1/16" sponsor panel instead.
Also, taking inspiration from 6328, we added a tube spacer to the intake to hold it a little bit more rigidly and hopefully prevent belts from coming off of their pulleys. We’re also adding bearing retention holes to prevent bearings from popping out when we take side impacts.
Things I’m Proud Of
I’m still impressed by the quality of work and engagement we’ve seen from new team members these past couple of years. This year, almost all of our mechanical subteam is new, and while there have been some hiccups, in general, the team is doing really well at getting stuff done.
After a while since we’ve had normal in-person build season meetings, I’m impressed with how quickly we seem to have gotten into the flow of things. We didn’t really build any additional lag time into our schedule for this year compared to 2020, but we’re meaningfully further along than we were at this time two years ago, even with all of the disruption caused by COVID.
The design subteam, even though they haven’t had an in-person meeting since the start of build season, has stayed really engaged and made continual iterations on their original CAD. I think this is by far the most iterations we’ve had on our design at this point in the season – the shooter group has played with accelerator wheels and top rollers, the feeder group has iterated on their design to cut weight, etc.
Anyway, that’s a really long update for it being 2am. Hopefully I get a chance to write another one of these at some point, but otherwise, I’m sure the students will chronicle our progress fine too.
Consider using the WPILib SimpleMotorFeedforward object and the arbitraryFeedForward parameter - this lets you combine a more robust feedforward implementation (with an API shape that makes its role in the signal chain clearer) with on-controller PID.
We had considered doing this initially, but for something as simple as swerve module steering, we didn’t think it was necessary. Perhaps we could have avoided this issue had we chosen this option, but at this point since it works to our standards it doesn’t really make sense to spend time during the season working on this.
We are, however, planning to use the WPILib feedforward classes and SysID for other subsystems (climber and shooter).
Yeah, that’s the main reason I advocate it - if it’s working acceptably now, for sure, lock the code down for the rest of build season. But moving forward, it’s a clearer architecture.
The arbitrary feed forward value needs to be between -1 and 1. If I recall, ks is written in volts right? So would you just divide by 12, multiply by the appropriate sign of your velocity and feed it to your steering motor?
Hello! It’s me again :).
This week our robot has gone from looking like a skeleton to a skeleton with some guts and stuff in it!!! This post is just a couple of videos of us testing the now completed (but soon to be changed, details coming soon) feeder.
Here is our initial test of the feeder. One thing that we noticed was the 4:3:1 ratio on the maxplanetarys was incredibly slow and so we wanted to try testing a different gear ratio.
This is the result of our tests with a 3:3:1 ratio on the maxplanetarys. This was a lot closer to the speed we were looking for and so moving forwards we need to buy more 3:1 pieces since we had only initially gotten the 2!
Finally, as the great Andrew Zhong once said, Parth made an incredibly Banger Blog last week and you should definitely look at it if you haven’t!
Recently, we’ve been looking into getting a new 3D printer for our upcoming pits set up, and we were interested in an ELEGOO Neptune 2S. It’s an inexpensive, yet reliable machine, making it ideal for a pits setup. ELEGOO sent us the Neptune 2S, and so far it appears to be a reliable machine. We’ll definitely be utilizing it for prototyping our future robots and in our pits. Thank you to ELEGOO for sponsoring us with a Neptune 2S 3D printer! You can learn more about them at: https://www.elegoo.com/.
Electrical Update: Getting Charged Up (with Batteries)
Brownouts suck. To avoid them, this season, we went with Interstate Batteries + 4 gauge battery cables + SB120 housings for our batteries and four gauge wire on the PDH and breaker side. At worlds, we realized we needed more (and better) batteries to make it through elims without reusing batteries so we could play lockdown defense without worrying about brownouts. In the offseason, we switched to using MK Batteries + 2 gauge + SB120 housings to optimize our batteries even further.
With products like Andymark’s 4 gauge battery cable and 900’s battery paper switching from 6 gauge to 4 gauge was incredibly easy. And because of 900’s excellent writeup, so was switching to 2 gauge. Throughout both switches, we learned a lot about the importance of taking care of our batteries, their battery cables, and the PDH lever terminals. These systems are all interdependent, making it incredibly difficult to pinpoint the source of an issue ranging from the PDH to the Battery. Thus, we set out to ensure all parts of this system were as perfect as possible.
Switching to using 2 Gauge
Switching to 4 gauge has already been well-documented (see above) so for the most part it was following existing directions with different materials. It’s worth noting that the PDH Battery Input channels can only be fed up to 4 AWG wire. This is why we picked up one 4 Gauge Battery Cable from AndyMark and altered it to connect to the PDH. See diagram (taken from here) below for what this means.
This does unfortunately bottleneck our system so it’s important we look to reduce the distance between the power wire from the PDH → Breaker and ground wire from the PDH → SB120 Contact.
Additionally, in our battery upgrade adventures, we had to strip the battery wires by slightly more than 0.75" (0.8" seemed to work for us). Stripping to precisely 0.75" led to the PDH biting on the insulation, which added enough resistance to reduce the voltage available to the PDH. In our tests, we found we were losing 0.5-0.6 potential volts because of this biting problem which sucked, given the intensity of defense we were playing this year.
And of course, MK ES17-12s Don’t have an order link for this one but you can call MK tell them you are ordering batteries for FRC. We found the MK batteries to be significantly better under large loads than the Interstate ones.
Also worth picking up a bunch of SB120 to SB50 Adapters for your chargers and Battery Beak.
Good Battery Practices
The most significant takeaway we, as a team, got from all this is that batteries are highly fragile, very susceptible to failure, and create (somewhat) undiagnosable issues. Right before our latest competition (Battle of Baltimore 2022), we had a battery mishap in our truck: they slid out of our battery cart and fell onto the floor. This made them unusable; we had to use an SB120 to SB50 adapter and connect using other teams’ batteries. It took us to finals, but we had an insane amount of brownout issues through BoB. To avoid battery issues next year, we plan to implement these practices to prevent battery issues.
Have 9 comp batteries (at least) so we can go through elims without ever needing to reuse one. Additionally, we want to pressurize and reset robot on another battery altogether. Competition batteries will generally not used for practice. We plan to use older batteries for regular practice and only use competition batteries for comp or driver practice.
Run CBA V tests on all of our batteries before competitions. 1640’s parameters worked well for the tests we did run this year
Overstrip the battery cables that are fed into the PDH
Reducing the distance of the 4 gauge wire from the PDH → Main Breaker and PDH → SB120 Contact as much as possible. Reducing the amount of 4 gauge wire in our battery system (when running 2 gauge) is essential to reducing the resistance of our system.
Logging battery beak stats before and after a match
Cushioning our robot’s battery holder so the battery doesn’t experience harsh impacts when the robot does.
Assigning one person in pits to manage batteries. Reducing the number of people who are managing batteries at competition helps ensure that batteries are always being rotated, recorded, and charged while also properly being cared for (i.e. not holding them by the cables, etc.).
. 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.
