FRC 4099 The Falcons 2022 Build Blog

[zacfmhill]

Team 4099 is excited to be participating in the #openalliance this year! We’re a team in Poolesville, Maryland and have around 40 active members + 1 mentor (working to get more). We are currently working out of a church across from our school. We meet weekdays 3:30 - 7 and Weekends 12-6 pm.
We’re super excited for the start of the 2022 build season and are looking forward to talking with y’all throughout the season. Please feel free to ask any questions and offer any suggestions as we move through our build season!

All of our work for this year and last year can be found at one of these links:

2022 Onshape
2022 Github

2021 Designs
2021 Github
2020 Build Blog

To kick off our build blog we’d like to share what we’ve been working on over the offseason:

Workshops

Our team has focused a lot of energy in the last two years towards more in-depth and comprehensive workshops to get new members up to speed and old members back into the hang of things. Below are the complete presentations and recordings for our workshops from 2021 and 2022:

• 2022 Workshops Full List
• 2021 Workshops Full List

In the past month, on top of presentations, we have begun incorporating offseason projects, such as fixing our previous year’s drivetrain and electrical issues, into workshops to get more physical experience before the season.

Mule Chassis

During the 2021 season, we built two drivetrains, one mule, and one for the comp bot. The mule robot had several mechanical issues and in a lack of electronics last year we stripped it of some parts. During the offseason we’ve been having new members work to fix the old Thrifty Swerve modules and electronics. Members have been learning the correct amount of loctite to apply, how to remove stripped screws, and soldering/wiring basics.

One important thing that we’ve learned about the Thrifty Swerve modules is that the small pockets in the top plate should be taped over to prevent small screws or rivet mandrels from falling in and getting caught in the gears.

Issues we’re working to fix before it can drive:

• bad soldering connections caused us to have to redo some of the encoders, sometimes several times, which at this point are now unusable. The main issues stemmed from having the wrong gauge wire and so we were stripping individual braids off the wires which made it sloppy. After ordering better quality and correct gauge wire we’re ready to solder our encoders correctly but we now need to order replacements for the damaged ones (2).
• When initially testing code on the drivetrain without the encoders only one of the swerve modules was actually running. Right now we suspect that the roboRIO has very old code and was never updated so the next step is to try uploading current code.
• The wiring right now is very messy (as you can see) so we want to work on improving the neatness of it. This is something we’ve failed to do in past years and as a result suffered when attempting to debug electrical issues.

Scouting System

2021 was the first year that we officially started a scouting subteam in order to develop a new scouting system and improve our robot design decisions during kickoff. To create an efficient alliance selection system, Team 4099 utilizes visualizations created by Tableau Desktop, fed data from two sources: The Blue Alliances and Team 4099’s own novel scouting data ingest tool.

During competition, Team 4099’s scouts collect and input data into a form hosted on the team’s website, which is run alongside the team’s scouting data ingest (SDI) tool, and SDI collects live data from The Blue Alliance (https://www.thebluealliance.com/). SDI can simulate a live event outside of competition using spreadsheet data, JSON-formatted match data, and user input through a local GUI created using Flask. As of now, SDI puts both the calculated and collected data into a local SQL database, but SDI can (and already has) put data into a database hosted on Amazon Web Services (AWS) so that nobody needs to run the tool on their local machine. Team 4099’s SDI tool (https://github.com/team4099/scouting-data-ingest) is open-source. It is currently being improved upon alongside Tableau Desktop to calculate and incorporate new metrics into the visualizations, such as offensive power rating (OPR), to make the alliance selection process as efficient as possible come kickoff.

The scouting data we collect is visualized in Tableau to guide drive team’s match strategy during the qualification round and to help form our picklist. Drive coach visualizations include data on past performance during the autonomous, teleoperated, and endgame periods for the teams we are playing with and against for the upcoming match. Picklist visualizations aggregate data from qualification matches and create an initial ranking based customizable weights for each factor we are considering. We are currently working on putting out Tableau visualizations on Github for better collaboration between team members who are working on them.

Robobadge

In the past we’ve worked with local girl scouts troops to helps scouts get their Robobadge. Because of the pandemic and time restrictions we had been unable to continue this program but during the 2021 season and offseason we’ve been working to revamp the project and update our resources to also fit the needs of Boy Scout troops. Currently we’re in the process of communicating with local girl scout troop in Poolesville to host a session for them.

F4 Cadathon

Last year and this year our team has competed in the F4 Cadathon to get our design members up to pace with designing a full robot and design some elements we haven’t had much practice with in the past. Our full cad submission can be found here and our blender renders + kickoff design notes here

2022 Season Plans

Things We Are Keeping from 2020/2021

• Overall robot strategy. Our overall robot strategy in 2020 was pretty spot on in terms of what our team could accomplish. We built a tall robot with a fixed shooter, a climber and a simple mecanum wheeled intake. We want to stay on track with building robots that allow us to be done building by week 4.
• Swerve. After success in figuring out swerve software in 2021, we plan to stick with swerve for 2022. At this point our driver is used to swerve and our autonomous pathing is mostly figured out with our swerve chassis. If the game is completely opposed to using swerve, we may purchase a KOP chassis and stick pneumatic wheels on it — but we don’t think this is likely, because even a KOP chassis with 8” pneumatic wheels has less ground clearance than an SDS MK4 chassis configured for extra ground clearance. The only issue would be if the field might damage the modules but modern COTS swerve modules seem to be pretty robust.
• New member involvement. In both 2020 and 2021, compared to previous years, we had a lot more involvement from new members in terms of how much of the robot they were able to contribute to. We seem to be on track to maintain this.
• Subsystem vs subteam structure. Before 2021 our team, was organized into subteams like mechanical or controls, but this lead to members only knowing how to complete tasks in their specific areas and people not knowing enough about the robot in general to diagnose issues. It also led to times in the season where some We have begun using a subsystem structure for our team, with a couple of people from each subteam working in groups, in order to increase technical and design knowledge and make prototyping/design changes more streamlined. During the offseason, we still train members by subteam, so that we have people with in-depth

Things We Are Changing from 2020/2021

• No more practice robot. We learned in 2020 that building two robots is too much for our team to be able to do in four weeks. In 2020, had we built one robot (or at least competed with what we thought was our practice robot) we would have likely done a lot better at our week 1 event. So this year, we are building one robot, and we have a mule chassis already prepared for driver practice and autonomous testing.
• SDS MK4i instead of Thrifty Swerve. The Thrifty Swerve modules were great as a relatively affordable entry into doing swerve. But after some annoying issues with tread replacement as well as some assembly issues on our part, we decided that it made sense for us to go with the SDS MK4i modules for this year.
  • Specifically: tread replacement on the Thrifty modules was difficult because it was really difficult to get the holes for the tread drilled in exactly the right spot, and from there, it was really difficult to align the tread with the wheels and screw in, etc, while the wheels were on the robot. This would have been fine if we could have had pre-prepared wheels with new tread on them, but due to how the Thrifty Swerve is assembled, this was not a realistic option. Because of tolerance issues on some combination of the bevel gears, the wheels, and the shafts, the recommendation is that you insert shims in a couple of locations on the modules until the gear mesh is perfect. The problem is that if you change the wheels, and therefore the bevel gears, you would also have to adjust the shims — this process would take some time, which would defeat the purpose of having pre-prepared wheels.
  • I’m sure these issues will get addressed soon by the Thrifty team, but in the meantime, its seems that the MK4i modules are a more bulletproof solution. We have bought a ton of pre-cut tread and some replacement wheels and bevel gears, so that tread replacement should be a super quick job (pull out shoulder screw, replace wheel, put shoulder screw back in).
• All Falcon 500 motors. We’ll see how long this will last — there’s a good chance that in 2023, given the significant price hike to the Falcons, we might switch back to some NEOs. But for now, we got in on the Falcons for 2022 at the lower price. For us, the advantage is primarily that we don’t have to worry about the wiring between the motors and the motor controllers, especially the delicate encoder cable (we’ve written off a couple of motors due to their encoder cable connectors being crushed).

Good luck to everyone and stay safe!

[ThatSoftwareGuy]

@zacfmhill

delicate encoder cable

Glad to see y’all are partaking! Also, one mentor? They’re a trooper for sure; I hope y’all show them appreciation often.

As for why I quoted this particular section, I thought I’d add that avoiding encoder cable is always a plus. Fun fact: apparently the EM fields created by the wires powering motors can cause encoder drift and bad reads if the cords are next to the encoder cable

That was a lovely issue to debug.

[zacfmhill]

Kickoff Day 1 Recap

This recap will be smaller since we purposefully didn’t consider any robot mechanisms and instead focused on analyzing the rules and understanding the best robot archetypes to inform our design decisions for Day 2 of kickoff. You can find our full kickoff schedule here!

Game Manual Worksheet

The worksheet we had our small groups fill out as they read through the game manual can be found here. The worksheet took heavy inspiration (nearly directly copied) from 6328’s kickoff worksheet, which took heavy inspiration from 2791’s Kickoff Worksheet and 1678’s Strategy Offseason Training. On top of this, we had every group fill out the 1678 rules test (thank you for this amazing resource! It helped us notice a couple things we would have forgotten otherwise!!)

Robot skills, archetypes, and time based analysis

We first came up with all tasks that could score points and the things a robot would need to do (all possible capabilities). We focus on not visualizing a robot and only thinking about skills.

Following this we came up with different types of robots that can be made to accomplish the different tasks (254 in 2016, for example) and did a time based analysis for each one to see how many points each could get.

We found that all of the UPPER HUB archetypes were higher scoring than the LOWER HUB robots we looked at by a large margin. All of our analysis and task/skill lists can be found in this sheet. We’ve seen a lot of discussion around the LOWER HUB and I’ll be giving our own 2 cents about it along with our mechanism decisions tomorrow.

Needs, Wants, Wishes, Stop thinking about that :]

• First, we came up with our goals for this season (what do we want to accomplish) below are the two most important ones we had:
  • No medical emergencies
  • Have fun
• Going through each task to figure out which category it fits into
  • needs: we absolutely have to complete this task in order to achieve our goal
  • wants: if it wouldn’t be a stretch to extend the design to do this, we will do it, but we will skip it if it adds significant complexity
  • wishes: if doing this is trivially easy given the rest of the design, we will do it, but we will not change the design a meaningful amount to accomplish it
  • stop thinking about: no :]

Our full list as well as goals can be found here but the most important are below:
Needs

• Intake from ground
• Climb onto LOW RUNG
  • Elevate <=1 Second
  • Line up ~ 5 seconds
• Hold 2 CARGO and preload CARGO
• Score preloaded CARGO and TAXI in AUTO
• Score CARGO at FENDER into UPPER HUB
  • At least 3 Cycles in TELE-OP
• Maintainable robot
  • Easy repairs
  • Easy electronics access
  • Good cable management
• Reliable Vision and Accuracy
  • Accuracy of 80% on shots
• Human Player scores a point 60% of the time
  • Having LOTS of practice with field

Wants

• Climb from MID RUNG (Elevate <=1 Second, Line up ~ 7 seconds)
• Collect CARGO in AUTO
• Human Player scores a point 70% of the time
  • Pushing TERMINAL wall CARGO back to HUMAN PLAYER (?)
• Accuracy of 90% on shots
• 5 Cycles in TELE-OP

Random Observations and Retrospectives

• Driver practice seems even more vital than ever in this game (Our human player needs to start practicing his ball game)
• The balls take a while to be recycled out of the hub
• The worksheet and pre-formed groups of carefully mixed subgroups and experiences helped to stimulate conversation and keep things on track
• While we’ve had issues with zoom meetings leaving some not speaking up, doing most of the work in breakout rooms seemed to work very well getting people engaged.

Recap of Day 2 of Kickoff coming tomorrow after I get some much-needed sleep .

[Jbkerns]

Is there a reason that you didn’t consider a robot that scores in the lower hub but climbs to the high or transversal bar? It seems like all other possible robot combinations were considered, and that would almost certainly challenge your statement that “all of the UPPER HUB archetypes were higher scoring than the LOWER HUB robots we looked at by a large margin.”

[zacfmhill]

The main reason is just the number of groups we had available but on top of that part of the decision came from our team philosophy. In general, we want to try to focus on making simple but consistent and reliable robots. The main question we ask ourselves is whether it’s something a top Einstein team could not have and still be competitive. Of the possible lower archetypes we focussed on the two ones we could more realistically build that could still be “competitive”.

**I should note that during day 2 we did briefly look at what a short high and transversal robot would look like but data isn’t in the table for that.

[zacfmhill]

Kickoff Weekend Recap 2: Electric Boogaloo (The Design)

The UPPER vs LOWER HUB debate

The starting conversations of day 2 for kickoff focused on the now heavily discussed topic of whether to focus on the LOWER or UPPER HUB.

• initial archetype analysis showed that UPPER HUB would score more points
• discussions on CD https://www.chiefdelphi.com/t/every-team-should-seriously-consider-the-low-goal-this-year/399051/ made us go back over things in the morning
  • time to recycle balls is much lower
  • Higher accuracy
  • Even lowering accuracy from perfect to our goal of 80% for robot showed UPPER as being more competitive.
  • https://youtube.com/clip/UgkxeD7FSg9MEyG0Lem-VFCl3tEFbCU7bmyp shows time for CARGO to stop bouncing after being ejected from the UPPER HUB
• Led to deciding to make a shooter that could be switched out for lower if week 0 showed actual competitive advantages
• In the end, a few factors helped us decide to go with the UPPER HUB for now:
  • We built a shooter in 2021 that was very accurate from up against the POWER PORT, and this challenge should not be meaningfully more difficult (plus now we have a reference design and code)
    • Given this, the complexity is not a leading factor in making this decision, so we would design for the LOWER HUB only if it legitimately seems to be a better option points-wise
  • We’re only planning on shooting from the fender, so a lot of the disadvantages of shooting vs. dumping in terms of accuracy should at least be less of a concern from there
  • We’re not convinced that bounce-out from the UPPER HUB, as well as the volume of CARGO being shot up high, will lead to a meaningful decrease in accuracy
    • There are only two game pieces per robot, so this isn’t the same as 2017 in terms of ball streams colliding
    • You can coordinate with alliance partners to wait a couple of seconds for your shot if you think this is a major risk
    • In terms of collisions with opposing robot CARGO, it should on average be 50/50 in terms of whose CARGO gets bounced out if one goes in and one does not
    • Dealing with bouncing CARGO is an issue. It seems to be 6 seconds before a CARGO dropped from the UPPER HUB settles to basically no bounce — we went back and added a significant amount of time to the UPPER HUB cycles in our time based analysis, but even including a ton of time waiting for balls to settle if scoring in the UPPER HUB, giving the LOWER HUB cycler at least one more cycle it doesn’t seem to make the LOWER HUB more worth it.
      • besides this, you should only account for 1/3 to 1/2 of the CARGO scoring on your alliance, so even if you score low, if partners score high, you will eventually have to deal with bouncing CARGO

Potential mechanisms and SWOT Analysis

In order to analyze and choose which mechanisms we’d be implementing on the robot (subject to change if the design process doesn’t work out) we did a SWOT analysis for each potential mechanism in each group to compare. The SWOT sheet can be found here but below is a more in depth description and analysis of each mechanism we looked at. **all the reference links are under the bullets since I couldn’t link them in the dropdown.

DRIVETRAIN:

Final Decision: Swerve drivetrain with WCP Swerve X modules (Corner-mounted, flipped)

Major decision influences:

• Because the game this year is almost completely flat we opted for the flipped modules to give us more space for the feeder design. Last year designing around the swerves added extra constraints that made it more difficult.
• We opted for corner-mounted again for the small amount of space that it saves for the intake and feeder mechanisms.

Swerve modules we were considering and tradeoffs:

Thrifty Swerve

Our experiences with thrifty swerve over the 2021 season were interesting. These were the first swerve modules we’ve ever bought and they worked very well for us when they worked. A combination of not being careful during assembly and just the relative quality (which is still amazing for the price) of the modules caused us to have a lot of issues during competitions.

MK4 Swerve Module

These were a solid option. The main decision to go for the swerve X was primarily because of the flipped corner option that MK4 just didn’t provide

SHOOTER:

FINAL DECISION: Fixed position hood single flywheel- (nearly) full width of robot.

• We ended up deciding on a flywheel instead of the 6539 style shooter because of its simplicity which should allow us to get much more driver practice later in the season and make much better prototypes and iterations of the mechanism. The decision between full width or indexed we decided would be determined based on what the feeder group chose. Most of the decision then came down to a fixed vs two-position hood. Our initial idea was to choose the two-position hood because we would then be able to switch between upper or lower hub without making mechanical changes, but we then went back to why we chose the flywheel which was simplicity. A fixed position hood is simple enough where we can design one for both lower and upper and just mechanically switch them out before a competition if we determine that we want to go for lower instead of upper hub. On top of this, we’ll be able to do a lot more practice on just one cycle and hopefully, be much more prepared for competitions than we normally are.

Major decision influences:

• As discussed before, we wanted to focus on UPPER hub. This caused us to almost completely rule out designs like the 2019 and 2020 everybots which would primarily only work for the lower hub unlike the other two which were able to do upper and potential to switch between upper and lower.

Different mechanisms considered: references and tradeoffs:

6359 IR Shooter/Intake Combination

[Reference: video reference link here]
Strengths:

• Depending on gear ratios and design it could be implemented to work for both UPPER and LOWER HUB
• Its adjustable angle means it could shoot from multiple positions, allowing for LAUNCHPAD shots (although the necessity for this is fairly low)
• Combines intake, feeder, and shooter allowing for a much shorter robot (something we almost never do)

Weaknesses:

• Questionable consistency in shot accuracy
• Significantly more complicated than our usual shooter designs
  • More components for just one mechanism
  • Very different tuning than our controls team has ever done
  • Tight packing means much more intensive design work and might prevent us from doing as much iteration or practice as we want.
• Slow adjustments between each position (not a huge issue since in most cases the cycle time should be plenty of time to adjust)

FLYWHEEL SHOOTER (MANY different types listed below!!)

Type of flywheel:

Single flywheel with hood {Reference: 4099 2020}

Image reference:

Strengths:

• Uses one less motor (helpful for if we plan to do complicated climber and with historic brownout issues) **depends on design
• Easiest to tune of the 3 listed types
• Easiest to design and prototype quickly
• Quickest to build allowing for quick fixes and modifications during competitions

Weaknesses:

• Fewer options for shooting positions and angles
• Compression and path need to be dialed in really well since hood isn’t compliant **

.

2 flywheel shooter (Vertical Configuration)

[Reference: 2020 CD post for general idea]
Strengths:

• Adjustable spin on cargo making bounce out less likely
• More control on trajectory
• Reportedly helpful on longer shots **reference needed

Weaknesses:

• More complex tuning and code. Takes away from driver practice
• More prone to brownouts
  .

2 flywheel shooter (Horizontal Configuration)

Our analysis for horizontal configuration essentially ended before it started. We decided that any benefits that could be gained from the horizontal shooter wouldn’t be justifiably better than the simple one flywheel and we were running low on time. [/details]

Type of Hood:

Fixed Position Hood

[Reference: Our 2020 Robot]
Strengths:

• Much quicker to build and fix
• Would allow for fast prototyping and higher quality finalized hood design
• Very easy to design, would allow for more iteration
• Simple

Weaknesses:

• Can only shoot from one position on the field
• Can’t do both upper and lower hub

2 Position Hood

[Reference: Our 2021 Robot]
Strengths:

• Can do both upper and lower hub in the same match
• Easier than any position hood by a large margin in design and tuning
• Uses the pneumatics system we already need for climber arms

Weaknesses:

• A lot more complex than fixed position hood
• More prone to breaking
• Fewer prototype possibilities
• In 2021 when we built a 2 position hood we never actually used the second position. If we’re trying to split our practice between different cycles we’re not going to be as efficient as practicing one solid cycle for just upper or just lower hub.

Any Position Hood

[Reference: CD post with several good examples and discussion]
Strengths:

• Can shoot from almost anywhere on the field
• Can score in both upper and lower hubs
• Don’t have to know the angles for upper and lower hubs in design, can be done in tuning

Weaknesses:

• Extremely more complicated than 2 position or fixed position hoods to the point where it’s almost impossible it could be worth it.
• Unnecessary.

Width/Size on robot:

Indexed

[Reference: Our 2020 Robot]
Strengths:

• More control on the spacing of CARGO when shooting
• Much easier than normal since there’s only a max of 2 CARGO

Weaknesses:

• More prone to jams in indexing system, shutting down shooter for the entire match

Full width

[Reference: 2135 Behind the bumpers]
Strengths:

• Faster shooting in succession
• Faster than indexing

Weaknesses:

• Excessive for 2 CARGO
• Accuracy might be an issue, especially if we don’t perfectly center on the fender

Vision Aiming?:

Turret

Strengths:

• Very precise vision adjustments

Weaknesses:

• Extremely complicated
• Not needed for shooting at fender (our currently planned cycle route)[/details]

Everybots 2020 Dump Outtake

[Reference: Everybots 2020 Reveal]
As discussed earlier, we didn’t want to be locked into doing only the lower hub and so we scrapped this idea.

Everybots 2019 Ramp style Outtake

[Reference: Everybots 2019 Reveal]
As discussed earlier, we didn’t want to be locked into doing only the lower hub and so we scrapped this idea

FEEDER:

FINAL DECISION: Linear feeder

• The decision was basically just between Roller Feeder and Linear Feeder and was decided based on the shooter group. Because the shooter group opted for a robot-wide shooter we chose the non-indexing option the linear feeder.

Major decision influences:

• The choice for feeder was highly influenced by the shooter choice and whether it needed to be indexed.
  Different mechanisms considered: references and tradeoffs:

Roller Feeder {Reference: 4414 2021}

[Reference: 4414 2021 Robot:Onshore]
Strengths:

• Very small and efficient packaging
• Less likely to jam than linear feeder
• Indexes fairly faster compared to linear feeder from last year.
• Uses fewer motors than linear feeder. (good for brownout issues)

Weaknesses:

• Much much more complex and something we’ve never designed before.

Linear Feeder {Reference: 4099 2021}

[Reference: Our 2021 Robot]
Strengths:

• We’ve done it before and we know how to do it well
• Much easier to prototype
• Quick and simple to build

Weaknesses:

• Fairly slower than other methods.

Spindexer

Strengths:

• Much more organized output from feeder
• More consistent in output and flow of feeder

Weaknesses:

• It’s overkill.
• Much more difficult to design
• Very hard to repair quickly
• Takes up a lot more space

INTAKE:

FINAL DECISION: Pneumatically actuated horizontal roller spanning the width of the robot

• As we looked through robot designs from previous medium-sized ball games, the first decision we had to make was between a vertical and horizontal intake. We quickly went with horizontal so it would be more feasible to pick up more than one ball at a time and easier to operate. The next thing we looked at was whether the intake should be able to move separately from its intaking capability by having a wrist or arm to control the position. We ruled out a stationary design despite its simplicity since it would have to fit inside the frame perimeter. We ultimately went with pneumatically-actuated over motor-actuated movement due to the lack of complexity in a two-state movement, which eliminated the need for using the precision as well as power that a motor can give. Finally, we have to choose the type of roller used to control CARGO. We considered a scoop with a roller on top and a platform on the bottom, a compliant wheel roller, a mecanum wheel roller, and and intake that doubles as a shooter. At this time, we have not come to a final decision since we will need to prototype to pick an optimal design.

Major design influences:

• With our plan to shoot directly from the fender, we wanted to mainly intake CARGO from the CARGO RINGs as well as from the ground after dropping from the EXITs. ****Since we wouldn’t be moving very far during cycles, we would want to have more room to quickly pick up CARGO without very precise maneuvering required for a thinner intake.

Different mechanisms considered: references and tradeoffs:

Scoop Intake {Reference: 125 2016 }

[Reference: 125 2016 robot]
Strengths:

• Same mechanism for outake as intake

Weaknesses:

• For our implementation, the balls would have to be indexed into the robot through a feeder, and using this rotatable arm scoop, would complicate that process
  • For this reason, using scoop (platform under the rollers) is just less efficient / slower

Shooter Intake {Reference: 16 2016 }

[Reference: 16 2016 robot]
Strengths:

• doubles as shooter
• saves on robot space
• could be used for both LOWER and UPPER HUB

Weaknesses:

• more complicated design
• accuracy may not be reliable

CLIMBER:

FINAL DECISION: Single telescoping arm with bar

• The main decision that we had to make was between a telescoping arm going for the MID climb or using a rotating hook mechanism similar to 1986’s 2013 climber to go for the TRAVERSAL climb. In the end, we decided to climb to the MID RUNG using a single telescoping arm with a bar attached to the end for extra stability. We chose this over the traversal climb due to, again, simplicity. Although the traversal climb was tempting, we realized that the complexity may not have been worth it for us. Rather than spending lots of extra time testing with harder field elements to build and trying to get this complex climb working, we would be able to spend the time to do more driver practice and build a mechanism that works consistently. For the arm, we are planning to use the 2 stage GreyT telescoping arm from WCP. We decided to use the GreyT version of this in order to save us lots of time in milling as well as building. It would be easier to assemble and more reliable than what we have done in the past. We thought that the extra stability of having 2 arms would be unnecessary and decided that the extra bar would provide enough stability. The only problem with this would be extra space which we could think about later when we think about the layout of the robot.

Major decision influences:

• One thing that we discussed was that we did not want the climber to be heavily influenced by swing. We saw various climbers from 2013 which had a lot of swinging and decided that it would be unreliable and that we didn’t want to take our chances in hoping for a good swing. We wanted a consistent and reliable climb.

Different mechanisms considered: references and tradeoffs:

1986 Rotating Hook

[Reference: 2013 Reveal]
Strengths:

• Would be able to climb to all rungs, including the TRAVERSAL RUNG
  • An extra 9 points compared to the mid rung and would help in getting the hangar bonus
• Can implement the GreyT telescoping arms that we already have

Weaknesses:

• Complexity
  • Would take a lot more time to test and make sure that the climber works reliably and consistently, which is a goal we had
  • Time could be put into other things like driver practice
• Climbing to the TRAVERSAL RUNG could be kind of slow
• Would take up more space

2481 Single Telescoping Arm with Bar

[Reference: 2020 Reveal]
Strengths:

• Relatively easy to assemble
• Not too complex
  • Allows us to be more consistent and reliable
• Good stability
  • 2 contact points
  • No need for an extra telescoping arm that would cost us more motors and space

Cons:

• Takes up more space with bar
  • Look at layout of robot later and see if the bar would fit

Full System Sketch

I’m not going to go super in depth into our progress on the full system sketch as of now because I’m writing this on day 1 of build week and our design has already changed quite a bit. Expect an update tomorrow that goes in depth on our Full System Sketch and changes to our design since making it.

Prototyping Plans

After coming up with our mechanisms we then started deciding what needed to be prototyped. We also plan to compare our results to those found from RI3D and open alliance teams. Below is a synopsis of our prototyping plans and materials we will be using:

Intake - Priority 1

• Goal: how high the rollers need to be off the ground when picking up a ball (rig it up over the bumpers)
  1. Right grip, right compression of balls (if any)
     1. Getting over the bumper
  2. Testing different wheels for right squishiness
• Materials:
  • Protopipe (pvc, 3d printed parts)
  • Flex wheels
  • Drill
  • Try testing with our 2021 intake

Feeder- Priority 3

• Goal: compression (spacing between two sides) with ball in between belts (vertical setup, tubing)
  1. Tension of belts is set
• Materials:
  • Protopipe (pvc, 3d printed parts)
  • Polycord belts
  • Drill

Shooter- Priority 2

• Goals:
  1. Wheel-to-hood compression
  2. Vary grip using different wheels and backing material
  3. Speed
  4. Accuracy (test for stationary hood angle)
• Materials:
  • 1/4” plywood plates
  • Aluminum shafts for standoffs
  • Wheels
  • Motor
  • Tubing for mounting into chassis

Calculators and web resources that were helpful

FRC 2022 trajectory calculator
ReCalc - Flywheel Calculator

Plans for Day 1 (updates for the rest of the week to come soon):

While our team will be split by subsystem for the majority of build season, we’re taking day 1 to group as subteams and get everything set up to enable groups to work without leads. Our team is trying to use Notion to keep track of progress and tasks/bugs that everyone should be working on. If you’re interested, you can keep up with our task board here:https://team4099.notion.site/59f4d93f3ef54567bba16716654749ca?v=ec6392b71eab4fb4b226caf4b12ed924. This is a really cool system and I’d love to talk more about it so if you have any questions please do ask. Our overall season plans are here.

Build day 1:

• Design & Mech: Finish full system sketch
• Controls: Create branches and begin initial outlines of subsystems in code
  • Drivetrain subsystem group: Begin creating paths in pathplanner and updating drivetrain code to work for the mule chassis. Because the mule is currently missing encoders we’re changing the code to zero the position of our swerve modules on boot without the encoders so work can be completed ASAP.

This was an insanely long post but I hope that all of the content here helped to explain our design decisions well. Expect a day 1/2 recap soon!

I need a nap. -Zac

[RBTC]

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!

[amesmich]

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.

[zacfmhill]

@RBTC

seeing just how big a pool of solder one can make

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.

[zacfmhill]

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?

[amesmich]

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.

See 1:23 mark for test setup. Ri3D 2022 | Successful Climber - YouTube

[zacfmhill]

Prototype Update #1:

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)

Intake Update Photos:

Feeder Update Photos:

[zacfmhill]

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:

1. 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
2. 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
3. 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

[zacfmhill]

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.

Wiring:

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.

[plusparth]

Week 3 Recap

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!

Controls:

[plusparth]

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.

@ThatSoftwareGuy

Also, one mentor? They’re a trooper for sure; I hope y’all show them appreciation often.

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:

---

Week 4 Recap

Rehan (our mechanical subteam lead) with the robot as of Friday

New video by Parth Oza

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.

New video by Parth Oza

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.

–Parth

[Oblarg]

@plusparth

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.

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.

[plusparth]

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).

[Oblarg]

@plusparth

Perhaps we could have avoided this issue had we chosen this option

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.

[vargoose84]

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?