Hello, and welcome to the 2023 #openalliance Build Thread for FRC Team 3636, Generals Robotics, hailing from Portland, Oregon, USA.
We are thrilled for the opportunity to return as a member of the Open Alliance this season and present our process for the 2023 FRC competition, Charged Up. All of the links for our photographs and other documentation can be found on our team Linktree. We will do our best to give a prompt response to any questions you have posted on this thread.
– Asa | 3636
Introductory Post
FRC Team 3636, Generals Robotics, based out of storage closet 076 at Ulysses S. Grant High School, comprises 59 active members, 10 mentors, and two co-coaches. Our rookie season was in 2011, with the Logo Motion challenge. In last year’s competition, Rapid React, our team qualified for the World Championships, thanks in no small part to the resources and feedback provided by the Open Alliance, and as a result of this, we saw an influx of new members this fall. We have rearranged our team structure in order to accommodate this much larger roster.
Team Structure
In past years, our team has been rather disorganized, as low numbers combined with strong central leadership have made compartmentalization and specialization unnecessary. This laissez-faire system of management is no longer sustainable. In between the 2022 season and the 2023 season, our active membership has doubled from 30 to roughly 60. 30 new members that need to be trained and given hands-on experience is too much for a single, centralized leadership group to effectively utilize. As such, our team has decentralized leadership into ‘heads’ of various subteams, overseen by three captains, a project manager, and a business manager. Now members, old and new, are divided into subteams, with different responsibilities and skill sets, along these lines:
Tools and Equipment
We have not acquired any brand-new, cutting-edge tools since last build season; however, we have refurbished and set up some of our unused machinery. For an itemized, annotated list of our tools and machining capabilities, see the first post on our 2022 Build Thread. We have cleared the necessary desk space in our build area for our manual mill and lathe, acquired a hand-me-down bandsaw from FRC Team 7034 that can be used with aluminum, and our PDJ Pilot Pro 2642 CNC router is now fully operational.
Offseason Accomplishments
Season Schedule
Our team meets twice a week: Tuesdays from 3:30 pm to 8:30 pm and Wednesdays from 3:30 pm to 5:30 pm. During build season, additional meetings on Mondays and Thursdays are common, and meetings on Wednesdays are often extended to 8:30 pm. In between competitions we hold meetings at the same times as during the build season, focusing on iteration, robot maintenance, and cleaning our build space.
Season Goals
Events
Team 3636 will participate in:
Wilsonville High School PNW District Qualifier
Oregon State Fairgrounds PNW District Qualifier
PNW District Championship (fingers crossed)
Good luck to all teams reading this post, and expect to hear from us again after kickoff weekend.
– Asa | 3636
Kickoff Summary
Our team greatly enjoyed attending the kickoff event at Skyview High School in Vancouver, Washington hosted by FRC team 2811, the Skyview StormBots. The day began with our arrival and viewing of the event broadcast. Following the 2023 game announcement, we broke out into groups, each comprised of members randomly selected from several teams, to rotate around kickoff activity stations where we participated in rules readings, strategic game analysis, a hands-on demonstration of the new Autodesk synthesis software, and human-robot gameplay modeling. Afterwards, we returned to our campus and fully reviewed the game manual as a team. Our day was cut short in the early afternoon due to time-engaged locks on our school building, so our final activity was to divide into smaller groups to complete some copies of the publicly available kickoff worksheet created by FRC team 6328, Mechanical Advantage. Despite not being together in person for the evening, many team members held brainstorming sessions over Discord.
Preliminary Game Analysis
Week 1 Goals
Season Goals (update)
– Asa | 3636
This year, we’re considering using swerve drive and have ordered six REV MAXSwerve modules set to arrive this Saturday; however, since the season has already started, we’re going to try to get it working within a hard deadline of the end of Week Two. If we aren’t able to do spinning figure eights by then, we’ll stick with the kit-of-parts drivetrain.
To achieve this, we’re going to dedicate a few CAD and Fabrication personnel to the project as soon as our modules arrive and a couple programmers as soon as construction is finished. We think this strikes a good balance between maximizing our chances of getting swerve working and minimizing our risk.
We believe auto will be very important this year, so we’re prioritizing working on autos in the first few weeks of build season.
With a fairly simple auto we should be able to get 3 points for scoring the preloaded game piece in the low goal, 3 points for leaving the community zone, and 12 points for engaging with the charging station. That means with just a drive train and a few hours of programming time we could have an 18 point auto.
Last year our auto chooser was a clunky switch statement that was horrible to work with and ended up causing the robot to run into walls and trash cans multiple times. This year we want to have a flexible way to create and store autos that will make them easier to work with. We also think it might be helpful to derive certain autos programmatically to reduce the number of paths we have to maintain manually. E.g., it would allow us to mirror autos depending on the alliance as which we’re playing.
We are hopefully going to purchase a Limelight 3 once one is avaible, but until then we will continue using PhotonVision. We recently purchased two Orange Pi 5s and set them up with PhotonVision for detecting AprilTags. We had some issues with latency, but we were able to fix them by tweaking some settings as recommended in this Chief Delphi thread. We also bought an Arducam USB OV9281 Global Shutter Camera which is recommended by Photon Vision for AprilTag tracking.
To make sure we’re able to get a Limelight once they’re available, we’ve also set up two methods we hope will notify us when the Limelight 3 is released:
Our first official meeting of the build season following the kickoff event we attended, entirely focused on brainstorming robot ideas, creating a priorities list, and designing “cardboard CAD” mockups of potential robots, was held on Tuesday the 10th. We began by writing out a list of all actions that could be taken to score points or prevent the opposing alliance from scoring and, from that list, developed a preliminary set of priorities (pictured below). Note that the priorities list in the photograph is from a very early stage of brainstorming. Our finalized priorities list is provided later in this update.
Needs:
Wants:
Luxuries:
With the above priorities list completed, we began to sketch potential robot designs to meet these goals. Pictured below are a few select whiteboard designs drawn by our members. All the designs we considered utilize a universal game piece manipulator that consists of a two-position roller claw, which is featured later in this update.
Single-pivot arm with a wrist that has 90 degrees of motion.
Double-jointed arm with fixed wrist.
Wait… what if we tipped the whole bot? Bumper code violation on wheels.
Following this brainstorming session, we were made aware that some Ri3D teams, as well as other Open Alliance teams, had been prototyping roller intakes that could massively reduce cycle times while successfully intaking both cones and cubes. With this new information in mind, we resolved to design and fabricate a kit-of-parts drivetrain bot with a single-pivot arm using a wrist by the end of the second build week so that our drivers can get as much practice in as possible while we iterate roller intake designs and, potentially, a swerve drivetrain.
Creating ‘Cardboard CAD’ models as very basic proof-of-concept designs is a practice our design team learned from team alum and former captain Charlie Becker, as well as from David, the current CAD lead of FRC team 7461, Sushi Squad. These skeletonized, blocky CAD models provide a helpful reference for understanding how our mechanisms will fit together and interact with the game pieces. Pictured below are some of the cardboard CAD models designed by our team on the first day of the build season.
Representation of a two-position roller claw capable of intaking both cubes and cones that is used in all of our following cardboard CAD models.
Single-pivot telescoping arm.
Arm with four degrees of freedom.
Single-pivot arm with vertically rotating wrist.
As stated earlier in this update, we plan to complete fabrication of a kit-of-parts bot with a single-pivot arm that uses a vertically rotating wrist by the end of the second build week in order to provide much-needed driver practice while the design team prototypes intakes and manipulators. Pictured below are the mechanisms we have begun the iteration process for.
Two-position roller claw model ready for prototyping.
Two-position roller claw prototype (closed).
Two-position roller claw prototype (open).
Roller intake prototype that is adjustable along all three axes.
Expect a full writeup on our alpha bot for driver testing in our update next build week as well as CAD updates in the coming days!
– Asa | 3636
Good luck from 997. See you at state fair!
(You’re the first team I’ve seen that also had the tipping concept.)
Section authored by Design Subteam Lead Ari Grace
So far, we have settled for a 2-degree-of-freedom long arm with a universal manipulator attached to a wrist. Above all, we have prioritized a simple design with the ability to score both game pieces in all zones. We hope to primarily acquire the game pieces from the human player station, coupled with the ability to pick up fallen cones if necessary.
Central robot structure (electronics not included).
Master sketch depicting multiple arm positions.
We designed this superstructure to allow for the manipulator to pass through the base and remain stowed within the drivetrain at the start of the match. These constraints, along with a desire to keep the overall vertical profile as thin as possible, resulted in a rather interesting shape. Currently, the entire structure is bound together by gussets and tube plugs, but we would greatly appreciate suggestions for better reinforcement techniques.
Superstructure side and front views.
Right now, our arm is a single piece of 2x2 1/16” wall box tube with a hole drilled through each end for the manipulator wrist axle and the dead axle. In total the arm weighs in at 6.3 pounds, including the mechanism to drive the wrist, which consists of a MAXPlanetary 90 degree gearbox attached to the tube via clamping plates with a chain running to the wrist axle.
Arm side view.
The arm itself is driven by a dual neo chain run with an overall reduction of 115:1, which should be capable of achieving stowed to L3 speeds of roughly half a second. I chose to incorporate an intermediate stage rather than run a single, extremely long chain up the superstructure to prevent tensioning issues and an unbalanced center of gravity. Note that this gear reduction remains subject to change in response to data gathered from arm testing.
Arm driving mechanism.
Our initial idea for a manipulator was an adjustable roller claw that would interface well with both game pieces and minimize the precision needed to intake them, with an effective gap of 15 inches between the claws. A secondary advantage of this design is that it enables the shooting of cubes into desired goals to further reduce cycle times, and potentially even the shooting of cones if testing proves it effective. The claw’s actuation is driven by a Neo 550 with a gear reduction of roughly 237:1, allowing for a predicted actuation speed of less than half a second. The rollers are driven by a Neo on a 4:1 reduction, which, while likely on the fast side, will be what we stick with until testing actually proves the need for further reduction.
Roller claw in open position.
Our current design utilizes a Kit-of-Parts drivetrain in a 28” long by 26” wide configuration in order to strike a balance between having a small chassis and maintaining robot stability, with a cutout in the front plate to make space for the arm in its resting position. We’re using a quad-Falcon drive once again due to the success we saw with it last season. Our iconic half-inch HDPE brainpan with wired LEDs also makes its return in this design, but may be swapped out for a pocketed aluminum bellypan later on for ease of mounting electronics. Depending on how successful we are at getting a swerve drivetrain up and running, we might go all out and manufacture a swerve drivetrain for our final competition robot.
KoP drivetrain with ½” HDPE brainpan.
In the last programming update, we mentioned that our swerve modules would be arriving soon, and, while we would put some effort into getting them working, if we could not do spinning figure eights by the end of build week two we would not be using swerve this season. The six 3” REV ION MAXSwerve modules we ordered arrived the afternoon of Tuesday 1/17. By the afternoon of Wednesday 1/18 we had a fully functional prototype swerve drivetrain capable of doing spinning figure eights, as can be seen in the video we posted in the Open Alliance discord server. Before the modules arrived, we thought it could take us upwards of two weeks of work to perfect a swerve drivetrain, but thanks to the REV MAXSwerve Template it only took a few hours to implement full field-oriented driving. With the majority of our fabrication, electrical, and programming subteams working on the prototype simultaneously, it only took us roughly 30 hours to go from opening the module boxes to driving loop-de-loops around our practice field.
Prototype swerve drivetrain (bumperless).
In our last update to this thread, we resolved to have a full alpha bot fabricated out of scrap box tube and ready for driver testing by the end of build week two. We did not achieve our goal as we spent both our weekly meetings this week working on swerve. Despite this departure from our schedule, we did get in a good few hours of work machining and assembling the arm on our meeting on Saturday 1/21. Pictured below is our current progress on the 2DoF arm and supporting superstructure.
2x2 box tube arm connected to a 48 tooth sprocket on a dead axle.
We have managed to get PhotonVision running successfully on the Orange Pi 5 using our recently-arrived Arducam OV9281 USB camera. The camera’s performance sits at about 50fps with less than 30ms of latency (measured by PhotonVision) but the accuracy is dodgy at best, so we’re still planning on buying a Limelight 3 when it releases. In the meantime, we’ll keep tuning our PhotonVision setup.
Well, I can safely say none of us expected we would get swerve capabilities up and running so quickly after receiving the modules. With this shocking development, there’s a good chance all y’all will get to see the first brand-shiny new 3636 competition ready swerve bot at the Wilsonville PNW district qualifier!
– Asa | 3636
https://youtu.be/wcrO8Pgxa2c 3636 Generals has a plethora of prototypes to showcase along with providing a CAD overview of their 2023 Charged Up Robot
Last week, we came to you to inform you we had been delayed in completing construction on a rough alpha prototype robot, as had been our goal for the end of build week two. However, as this week has been finals week at our school, we have been able to put in extra hours in order to finish construction on our alpha bot to send off to our drivers so they can get practice hours in. We have made some discoveries of note about our design during the fabrication process, namely, that the manipulator touches the ground in the arm’s resting position, as well as that when the arm is fully raised out the robot tips even with the added ballast of a thick wooden bellypan and a battery. We are currently redesigning the CAD for our second bot in order to fix these issues.
Alpha bot v1 (manipulator not attached).
We have made a minor change to the design of our roller claw universal manipulator, as it was discovered during the iterative process that, when intaking, the central compliant rollers moved cones too far back, causing them to lose contact with both sets of rollers and drop out of the claw’s grasp.
Backstop to prevent loss of contact with claw rollers.
Our programming and electrical subteams have expressed a desire for a pocketed aluminum belly pan to ensure easy wire management while providing the necessary structural support for our drivetrain, which has a frontal cutout.
First version of the pocketed aluminum belly pan in its place with necessary electronics visible.
This next week we will also be testing machined hex holes as a means of transferring torque within tight spaces. We found some success with a four millimeter single-flute end mill performing an adaptive clearing followed by a finishing contour with a negative stock to leave of -0.006.
Primary application of machined hex hole for transfer of motion from wrist to claw.
Throughout this build week we have had a small contingent of our drive and programming teams test driving and autos in preparation to put swerve on our competition robot. We will elaborate more on our auto testing and swerve calibration in a future update from our programming team. To prevent our NEOs from cracking when impacting walls and other robots, we 3D printed protectors out of PLA to absorb some of the shocks. We also designed a swerve drivetrain for our final, competition-ready robot, and are in the process of refitting our superstructure and arm CAD to mount to it.
Swerve drivetrain with pocketed aluminum bellypan.
For build week four you all can expect a dedicated programming update along with our standard weekly update. Until next time!
– Asa | 3636
Path following for autonomous has been surprisingly easy, at least compared to our experiences with tank drive. We were able to get it working quite well using WPILib’s SwerveControllerCommand with only trivial modifications to the MAXSwerve Java template and, incredibly, no tuning.
We also set up PathPlanner to edit auto paths graphically with little difficulty. It also has some really cool features like a server-client mode for live path updates without redeploys and automatic path mirroring by alliance. We highly recommend it for any teams using auto pathing.
We’ve continued tuning and improving our PhotonVision setup, and we’ve gotten extremely basic pose estimation using it working. Next, we plan to implement some method of interpolating between the slow, latent AprilTag readings using drivetrain odometry calculations.
We were able to purchase a Limelight 3 while they were still available, so it’s likely that we’ll switch to that once it arrives.
Also, we did some rainbows. We’re planning to use a serial connection to the RoboRIO to change the lighting based on the robot state.
By the end of build week 3, we had built a complete alpha prototype robot, but it used a superstructure and claw design that became outdated even as we were assembling it. With our visit to FRC Team 2471 Mean Machine’s STEMnasium practice field on the 2nd quickly approaching, we machined and assembled a second prototype robot using the updated claw and superstructure CAD. Our second prototype bot has a 2 degree of freedom arm with a tweaked claw and a wrist consisting of a captive aluminum hex shaft. Ideally, we will be able to transfer the superstructure and arm of this prototype robot onto a swerve drivetrain for our final robot.
Prototype bot v2 superstructure being assembled.
Prototype bot v2.
We have made a number of design changes throughout our iterative process this week. A number have been listed below. Firstly, after drive testing the second prototype robot for only a short time, the bushings between the arm and the round shaft dead axle it is mounted on slipped out. To prevent further occurrences along this vein, we have added PLA spacers on the round shaft and every other axle in the arm.
PLA spacers keeping the bushings in place on the arm’s dead axle.
Additionally, we have tweaked some of the gear ratios on the pulleys on the roller claw in order to ensure the manipulator would clamp down with sufficient force to deform the cones. We also added more spacers to the hex shafts in the claw.
Adjusted roller claw design.
Although we spent a lot of time and energy iterating our roller claw manipulator, we were so inspired by the three-roller intake design proposed by teams such as FRC Team 8177 Vector we began designing and prototyping our own tri-roller intake, with the hopes that we could mount it on the end of our arm. A tri-roller intake would likely be both lighter than a claw and less space-consuming at rest. Videos of our laser-cut wooden prototypes being used to intake game pieces can be found in our build week 4 photo album.
Master sketch depicting tri-roller intake geometry.
This year we have been using JST SM 2 pin connectors for our CAN bus, but we have faced many problems with them being unreliable and the wires they’re attached to breaking. They also take a considerable amount of time to wire and crimp properly. Last year we used lever nut connectors which were easier to connect but just as unreliable. We looked into a few solutions last year and settled on the JST SM 2 pin connectors because, although they have proved difficult to crimp, we thought they would be easier to maintain once they were crimped. After having to re-crimp our CAN connectors time and time again this year, we decided to look for more alternatives. FRC Team 1466 Webb Robotics suggested these connectors that don’t require any stripping or crimping whatsoever. We had bought some last year but for some reason weren’t able to get them to work properly and gave up. This week we gave them another try and it seems like they will work a lot better for our purposes. We only had a small pack of around 20 so we ordered more and are planning on replacing all of the CAN connectors on the bot in the next few weeks.
In other news, the Limelight 3 we ordered arrived this Saturday. We have designed a double-wide mount to mount it beside our PhotonVision setup in order to test them side by side to determine which suits our needs more. Our build week 5 photo album, which will be made accessible through our Linktree, will contain videos of our Limelight vision testing.
– Asa | 3636
The first notable change our design team has made this build week has been to mitigate the slipping of the opening gears on the claw by adding even more spacers to the hex shafts. The two flat spacers pictured below flip the bearings to the correct positions in order to ensure effective meshing of the gears and keep the claw arms attached.
CAD model of spacers that retain our claw’s bearings.
We have also designed a new 3 roller manipulator, taking great inspiration from FRC Team 8177 Vector. This design should provide significant “touch it, own it” advantages over the original roller claw manipulator. It is also made to be compatible with our current arm configuration to allow easy swapping between mechanisms.
CAD model of new “touch it, own it” 3-roller manipulator.
Finally, we have finalized the design of our new swerve drivetrain so that it functions with our current superstructure, allowing us to rapidly transfer the entire top half of the bot over from our kit-of-parts drivetrain. This new swerve drivetrain features a pocketed aluminum bellypan for easier wire management using zip ties and a simple two-piece polycarbonate cover fastened with wing-nuts to protect our electronics.
Finalized CAD model of swerve drivetrain.
Freshly machined pocketed aluminum bellypan.
Low-resolution image of our finalized swerve drivetrain, complete with pocketed aluminium bellypan.
This week our team visited FRC Team 2471 Mean Machine’s “STEMnasium” practice field in order to test the functioning of our overall design on a full size field. Unfortunately, due to a combination of code errors, wiring disconnections, and mechanism malfunctions, our entire manipulator arm was rendered dead weight for the duration of our visit, and we accomplished little other than drive practice.
Prototype v2 robot repaired and rewired following STEMnasium failure.
This build week we also held a bake sale fundraiser, selling over 130 boxes of bundt cakes. Next week expect an update on time (fingers crossed my washing machine doesn’t explode again), and hopefully dedicated programming and business subteam updates on our vision testing and fundraising efforts!
– Asa | 3636
https://youtu.be/JicswK3m4OU 3636 Generals are making great progress as they showcase their second robot build including a new intake. They also detail how they are trying out two vision systems to see which works best.
So far this build week we have finalized our roller manipulator design, assembled a working prototype out of laser-cut wood plates, and attached it to our prototype v2 robot. Not only is this tri-roller design significantly easier to code than our previous roller claw, but it also has the advantage of massively increased intake and outtake efficiency.
CAD model of our finalized roller manipulator.
After designing this (hopefully) final version of our tri-roller manipulator, we set to work constructing a prototype out of laser-cut wood parts, finishing just in time to attach it to our prototype v2 robot for a testing session at FRC Team 2471 Mean Machine’s “STEMnasium” practice field.
Roller manipulator prototype in the process of assembly.
In testing our tri-roller manipulator, we found that it outperformed our old roller claw design in almost every metric, intaking and outtaking faster in addition to gripping the game pieces far more securely.
A side project that some of our team members have been working on for quite some time now is the design and construction of a new robot cart. Our current robot cart has room for only one laptop for code testing, has almost no storage space for maintenance tools, and is just generally non-ergonomic. With all these issues in mind, a couple members of our design team set about creating a robot cart to meet the following criteria:
After some fairly intensive research into anthropometry and ergonomics, this is what we came up with.
CAD model of our new robot cart design with different types of wood colored differently to differentiate.
Once the design was complete, we were informed that the only type of wood that we could afford to construct the cart out of was three-quarters inch plywood, which was not at all ideal. Our design was meant to work with the structural support of two-by fours and two-by-tens, and having to screw into the laminated sides of the plywood made assembly just that much harder.
Construction progress on our new robot cart.
We will likely switch to a new format for these Chief Delphi updates for the remainder of the build season, with more frequent but shorter updates. Additionally, we have decided to use both a PhotonVision rig and our Limelight 3 on our final robot, with the possibility of us purchasing a second camera to use with PhotonVision, which would bring our total camera count up to three. Expect another update from us in a couple days after we paint our bot all fancy-like!
– Asa | 3636
Last Friday and Saturday, we finished machining our final roller intake design out of polycarbonate and aluminum. However, it has come to our attention that the hex shafts are slightly too long and bearing retainers need to be added to keep our intake together in the face of high-speed impacts. We plan to either match-drill holes next to the bearings and use bolts and washers to retain them or 3D-print bearing retainers of a custom design.
For build week 7 we hope to detach our superstructure from our kit-of-parts tank drivetrain and attach it to our completed swerve drivetrain, finishing our competition robot. Additionally, our business and programming teams have been tasked with writing Open Alliance updates, so expect to see those out in the next week or two. Competitions are only a couple weeks away, so hopefully we’ll see some of y’all at the Wilsonville PNW District Qualifier!
– Asa | 3636
Since our last update, we’ve focused mostly on our arm control code. Our bot’s arm has only 2 degrees of freedom, so our requirements are simpler than those of many other teams; however, none of our members had any experience with controlling arms, so we needed to bootstrap much of that knowledge.
Here’s a diagram of the control scheme we’re currently using:
We used WPILib’s SysID tool to tune the shoulder and wrist feedforward controllers, and then tuned the PID controllers manually.
This week we switched out our claw for a roller intake. The claw just wasn’t cutting it and it also ended up being a pain to program because of the clamping force needed to hold a cone in place. The roller intake adds a lot of control complexity though, because cones and cubes must be manipulated using different wrist orientations.
Soon after swapping out the manipulators, we discovered that the bot can do a “push up” if both the shoulder and wrist are pointing downwards. We’re currently working on a software fix for this which will work by keeping the wrist above the angle at which it would touch the ground (plus some tolerance). Here’s a Desmos graph visualizing the underlying math.
We’ve implemented better robot pose estimation combining both AprilTag data and drivetrain odometry calculations using WPILib’s SwerveDrivePoseEstimator class. It automatically handles latency compensation and accounts for measurement errors using a Kálmán filter.
Since we have both a Limelight and a PhotonVision setup, we added a generic abstraction over vision backends. This also allows us to dynamically toggle vision backends in case one fails.
This year, our arm has different scoring and intake positions for cubes and cones, so there are too many arm positions for the operator to easily keep track. To simplify, we decided to make the arm state a combination of two controls: cube/cone and low/mid/high. This is still too many buttons to comfortably fit on an Xbox controller, so we plan to make an operator panel with dedicated buttons.
Right now, we have the game piece type and arm position stored as a global, static variable which the arm accesses to get its target angle. We’re still not sure how best to model this control setup in code, so suggestions would be appreciated.
public enum ArmState {
High(Constants.Shoulder.HIGH_CONE_ANGLE, Constants.Shoulder.HIGH_CUBE_ANGLE),
Mid(Constants.Shoulder.MID_CONE_ANGLE, Constants.Shoulder.MID_CUBE_ANGLE),
Low(Constants.Shoulder.INTAKE_CONE, Constants.Shoulder.INTAKE_CONE),
Stowed(Constants.Shoulder.STOWED_ANGLE);
private final double shoulderCubeAngle;
private final double shoulderConeAngle;
ArmState(double shoulderConeAngle, double shoulderCubeAngle) {
this.shoulderCubeAngle = shoulderCubeAngle;
this.shoulderConeAngle = shoulderConeAngle;
}
ArmState(double shoulderAngle) {
this.shoulderCubeAngle = shoulderAngle;
this.shoulderConeAngle = shoulderAngle;
}
public double getShoulderAngle() {
return(gamePiece == GamePiece.Cone) ? shoulderConeAngle : shoulderCubeAngle;
}
public double getWristAngle() {
return (gamePiece == GamePiece.Cone)? Constants.Wrist.CONE_ANGLE : Constants.Wrist.CUBE_ANGLE;
}
public static ArmState target = ArmState.Stowed;
public static GamePiece gamePiece = GamePiece.Cube;
public enum GamePiece {
Cone,
Cube
}
}
Last year our decorative lights were driven by an Arduino. This worked well for static patterns, but this year we want to use our lights functionally, to signal to the human player which kind of game piece we want. One of our members is creating a new lighting control implementation running on a Raspberry Pi. She has already implemented simple patterns which can be selected dynamically using a NetworkTables API.
In the coming weeks, our first priority is autonomous. After some preliminary testing we have found that it is very easy for a driver to balance the robot on the charging station using only the drivetrain. However, the higher CG makes it harder to quickly balance the robot with the arm on it. We plan to try implementing a bang-bang controller at low speeds for autobalancing, but if that doesn’t work we will look into more complex solutions.
Additionally, we plan on implementing a way to automatically score when the robot is within the community zone. The first thing we plan on implementing is aligning with the nearest scoring node for the currently held game piece. We will also start working on a way for the operator to select which node to score on so the driver doesn’t have to worry about scoring and can focus solely on collecting game pieces.
Business Updates: from our team’s Business Manager - Megan Cavallucci
Hello all,
I wanted to give an update on the business team, what we have accomplished in the offseason, and what we are working on during the regular season.
Offseason:
From there we break down every line item (Income or Expense) into another group, where we go into detail, like with “Team Merch Payments”
This new budget set up, will hopefully make yearly budget making easier. As we are able to see categorized expenses/incomes throughout the years. Shoutout to our finance lead, Dani Gollier for making this beautiful budget!
But it didn’t represent us as well as we had hoped. Trying to explain what G36 is, was very annoying and made people very confused. So our graphic design team got to work designing a new logo. We discussed different symbols that represent our team well, and ended up with a Star, because our school’s logo is a large G with 4 stars underneath. After some brainstorming, we came up with this:
Regular Season:
If you have any questions or just want to talk business with me I would be very happy to answer, feel free to email me at [email protected].
Hello, and welcome back to our last general update for this build season. We apologize for our lack of content during Build Week 7 due to an unexpected blizzard, which caused our high school district to shut down all extracurriculars for a week. We’ve really been feeling the loss of so much valuable build time, and have been working overtime in our closet to make up for it ever since.
Over Build Weeks 8 and 9 we have continued work on our prototype v2 robot, painting it and replacing numerous gussets. We have made a number of minor design adjustments, namely, adding bracing at the top of our superstructure to diminish horizontal shearing, as well as designing a new mount for our PhotonVision camera. At the current moment, we can confidently say that our robot is ready to be driven at our first competition - the Wilsonville PNW District Qualifier.
Competition-ready robot (RGB disabled).
Competition-ready robot (RGB enabled).
Last-minute cage machined out of aluminum to protect our PhotonVision camera.
We have experienced some significant issues with our swerve modules over the last few build weeks. After sustained drive practice on our practice carpet and at FRC Team 2471 Mean Machine’s STEMnasium practice field, the wheels that came with the modules have begun to experience delamination between their treads and their rims. In order to have a drivable robot ready the morning of the Wilsonville competition, we have ordered untreaded swerve wheels, which we will be using with strips of black and blue nitrile tread.
Swerve wheel experiencing tread delamination.
Untreaded swerve wheels that we are now using with black and blue nitrile tread.
Furthermore, we were enlightened by a mentor from Mean Machine as to the real reason behind an issue with our odometry we had been having all build season. We had been noticing that whenever we drove our swerve drivetrain on carpet, our bot’s position in its odometry began drifting out of alignment with where it actually was on the field. On our most recent visit to the STEMnasium, one of Mean Machine’s mentors informed us that this was due to a phenomenon they had dubbed “carpet bias”, where our swerve wheels were gaining uneven traction depending on whether the bot was driving along the grain of the carpet or across it. The solution we have settled on is to check the grain of the carpet at our competitions by hand and then manually enter corrections into the odometry in the morning before our matches start.
We wish the best of luck to those of you that we will see tomorrow at the Wilsonville PNW District Qualifier!
– Asa | 3636
Our first competition this build season was the Week 2 PNW District Qualifier at Wilsonville High School in Wilsonville, Oregon, hosted by FRC Team 1425 Error Code Xero. Overall, we feel that we made a strong performance, placing second in qualifiers and going on to be picked by the first seed alliance captains, FRC Team 2046 Bear Metal. While we encountered some technical difficulties along the way, we were able to field a fully functioning robot for every match up until the semifinals. From this event, we earned a total of 55 district points - 50 from matches and 5 from winning the Industrial Design Award sponsored by General Motors. Below are photos of our scenes from the event.
Overall, if you go by our statistics for the Wilsonville District Qualifier as listed on The Blue Alliance, our robot and drive team performed consistently well. At the end of the day, our record for qualifying matches was 9 wins to 3 losses. Including the playoff matches we participated in brings that number to 11 wins to 5 losses. According to TBA, our average match score for qualifying matches was exactly 100 points, our average charge station points was 26.5 points, and our average auto value was 22.5 points. The OPR value (Offensive Power Rating) assigned to us was 52.8 points, the second highest at the event. We hope to perform well once more at our next competition - the PNW District Qualifier at Oregon State Fairgrounds in Week 4 of competitions.
We suffered some minor technical difficulties throughout the competition, all of which were resolved in a timely manner. After one of our qualifiers, we discovered that the NEO on our arm was impacting our robot’s superstructure with such force that its metal casing was loosening. We rushed to replace it in between matches, and in our haste, lost the chain tensioner for our manipulator wrist. Fortunately, FRC Team 2898 Flying Hedgehogs came to our rescue, generously providing us with one of their extra tensioners. Overall, the largest problem we encountered at the competition, and by far the most grave, was our breaker positioning. In Match 13 of the semifinals, as our driver turned the robot on a tight corner around the charge station, we gained air time as one of our swerve modules skipped over the edge, and our battery, which was poorly secured, jumped slightly out of position, activating our breaker switch and deactivating our robot. Being disabled, we lost the match, and were consequently dropped from the bracket.
After the Wilsonville event, we had a number of considerations on what fixes and modifications to make on our robot. We compiled a list of design, mechanical, electrical, and programming tasks that needed to be completed during competition weeks 3 and 4 before we went to the Oregon State Fairgrounds event:
Almost every item on this list was ticked off at some point in the past two weeks, save for a rim grabber. More can be read on our antics trying to pick cones up by the rim in our Open Alliance discord channel here. In the end, we found that we had run out of time to properly tune the new manipulator, and resorted to disassembling it and reattaching the old intake plates. We determined that it would be a lapse in judgment to sacrifice our ability to intake cones from the nose, which contributed to our almost 11 second cycle times during the Wilsonville event, to be able to pick cones up from the rim only somewhat reliably. All in all, our bot has been reassembled, repainted, and re-LEDed in preparation for our next District Qualifier. Good luck to all of you, and see you there tomorrow!
– Asa | 3636
Hello and welcome to our final update before the Pacific Northwest District Championships! We have qualified to participate following our performance at our second district qualifier, the Week 4 competition held at Oregon State Fairgrounds. We started out slow at the OSF Qualifier, but got up to speed by the second day and finished strongly as first pick of the fourth seed alliance. After ranking at 16th after the qualifying matches, it was a pleasant surprise as we were picked first by the fourth seed alliance captains, 1425. As an alliance, we went on to place third in the playoffs, being eliminated in Match 13 of the losers bracket. Overall, we earned 39 points from the event, as well as an additional 5 points by earning the Innovation in Control Award for the accomplishments of our programming subteam.
Iroh being serviced in between matches at the Oregon State Fairgrounds District Qualifier.
Depending on whether you go by our TBA statistics or our Statbotics insights, we performed very poorly or very well at the OSF event. Going by our ranking on TBA, which is an average of all of our performances at OSF, including the five matches we were disabled for, we performed below average, coming in at 16th in the event with an average match score of 96.33, an average charge station score of 25.83, and an average auto score of 20.16. All of these statistics are middling, and while it is up to the individual to decide whether they believe they are an accurate representation of our team’s overall performance, it is fact that they do not represent how well our robot Iroh has performed at its best. For that, we look to Statbotics, which uses its own relative skill calculations to rank teams. According to Statbotics, our EPA (Expected Points Added), a predictive measure of how much a team will contribute to an alliance, was 48.2 at OSF, placing third in the event behind 2521 and 2990. Furthermore, our teleop EPA was 31.6, placing second behind 2521, thanks in no small part to our senior driver’s extensive practice and our intake’s highly efficient cycle times. Overall, we can confidently say that when we were functioning during OSF, we made a strong showing, and if all of our problems are fixed by DCMP like we hope, we will continue to score well.
In a stroke of good luck, we experienced no mechanical failures at our qualifier this week. However, we more than made up for it in code issues and straight plain mistakes. We were disabled for the majority of our qualifying matches for the first half of the first day of the OSF event, due to reasons ranging from wiring coming loose to code deploying only partially, leaving our bot bricked. Overall, all of these issues were things that could have been avoided had we just managed our time and resources more efficiently in between Wilsonville and OSF. We tried to do too much too fast, and paid the price severely. We implemented so many changes to our robot and auto routines that we did not have the meeting time to thoroughly test everything we added. Kinks that could have been worked out in mere hours in the shop were instead hastily patched in our pit at the competition, leaving us high and dry for most of the first day of the competition.
In order to not make the same mistakes we did between Wilsonville and OSF, we avoided making too many changes that required significant resources to implement to our robot in between OSF and DCMP. Where many other teams have several hands-on mentors, we have only two mentors, neither of which touch the robot. Our lack of chaperones and oversight mean we are not able to meet nearly as often as many teams, and we only got in two meetings between OSF and DCMP, not including visits to Mean Machine’s STEMnasium practice field. With what time we did have, we have made massive improvements to our auto scoring and balancing and our teleop auto-alignment capabilities. We also toyed with the idea of adding a side climb mechanism to our bot, inspired by designs such as the one by FRC Team 7407 Wired Boars, in order to aid in getting those valuable triple climb points each match. Ultimately, we decided against adding the mechanism to our robot after machining all of the pieces, as we did not have the time nor the resources to effectively implement it before DCMP. Below are a number of minor modifications we have made to our robot in order to reinforce our existing capabilities.
Dual Orange Pi 5 camera mounts and an ultrasonic sensor attached to the intake assist with automatic alignment in teleop.
New shoulder encoder directly driven by the arm with a new plate attached to relieve horizontal stresses.
Side climb CAD (resting position).
Side climb CAD (engaged position).
After our strong performance at the Wilsonville qualifier, we ranked solidly at 13th in the district, well within the bounds to go to the World Championships in Houston for the second time in our team’s history and for the second year in a row to boot. However, following our issues during the Friday qualifying matches at OSF, we dropped to 16th in the district, leaving us on the boundary of not qualifying for Worlds. If we place well in the DCMP qualifying matches, and either get into a picking position or get picked by a high-seeded alliance, we will have good odds of either maintaining our current position or going up in the district rankings. Either outcome would result in us qualifying for Worlds. We look forward to seeing other Open Alliance teams at the District Championships, particularly FRC Team 7461 Sushi Squad. Good luck, everyone!
– Asa | 3636
