1675 - UPS - Open Alliance Build Thread

[ASmith1675]

Team 1675, UPS, is excited to deliver our perspective to the #openalliance this year. We’re hoping our approach to robot design and strategy is helpful to the community at large.

A quick introduction for myself, I’m Adam. I joined team 1675 in 2011 and am currently the longest tenured mentor on the team. Overall, I’ve been mentoring since 2005 when I started with team 677 while I was in school. I’ll be the primary poster in this thread, compiling information from our student leaders and other mentors.

Brief Team Background:
The Ultimate Protection Squad was founded in 2005. We’re certainly not a powerhouse, but have had a solid run through our history, winning a handful of awards and regionals over our 18 years of existence. Our goal each year is to push ourselves, but not over-extend.

One of our biggest limitations is access to our build space. Throughout build season we only meet 4 days a week. 3 weekdays (5:30 - 8:30), and Saturdays (9-4). We’re pretty much limited to only these hours in our shop so making maximum use of the time we’re on site is a big priority to us. We really don’t want to be standing around with limited shop time.

We also have a few limitations in our manufacturing capabilities. We do have a CNC plasma cutter which allows us to design custom aluminum plates and gussets, but other than that we mostly manufacture with a chop saw and hand tools. We don’t currently have access to reliable 3D printing either. We rely heavily on COTS parts and build our designs to incorporate these parts as much as possible.

With that in mind, we typically try to design strategically to do one game task very well, and be capable at a second task (typically endgame). In 2022, we designed a double-catapult high goal scorer and a simple level 2 climber. We had one of our most successful seasons in terms of student engagement and excitement and the robot did everything we designed it to do.

Pre-season
As a preseason project we’ve invested in SDS Mk4 Swerve modules. The high quality COTs optinos (as well as getting bullied mercilessly by swerve drives in 2022) helped us make the decision to finally take the plunge. The team has been working diligently to bring up a platform to prove out our capability to make this work as a drive base. We were hoping to be able to fully test out swerve as a drive base before the season starts, but we’re nearly out of time.

Additionally, we’ve been working hard to expand our sponsor base. We’ve been incredibly fortunate to add John Deere, Milwaukee Tool, and The Gene Haas Foundation to the group of our long-time sponsors Rockwell Automation, Regal Rexnord and GE Healthcare.

At this point, we’re likely to pick a strategy and design that would be able to work with either swerve or a kitbot chassis depending on how swerve development goes early in the season.

Website: https://frc1675.com/
Instagram: https://www.instagram.com/frc_1675/?hl=en
Onshape for 2023 Robot: Onshape
Github repo: FRC 1675 · GitHub

[ASmith1675]

End of Preseason Highlights

This past Monday marked the end of our pre-season meetings. Overall it was a fairly successful preseason with a lot of work on various projects in very limited time (2x 3-hour meetings/week).

Swerve Drive Development

We were able to get a full prototype swerve chassis assembled and wired. The wired chassis was handed over to programmers ~2 weeks ago and they’ve been working through getting the system set up and working since then.

The major issue that we’ve encountered is fighting with phoenix tuner to set CAN IDs for our CANcoders. It’s been several years since we’ve had to use the CTRE products having been in the NEO/Rev environment for several years so there was a bit of a learning curve there.

Unfortunately, we weren’t able to get a drive test working before the season, which was our ultimate goal. This will make it tough to commit to this drive train for the season at this point. However, we do have alternatives in place. We had good success with a kitbot chassis and drivetrain last year, so we did not opt out of the kit chassis this year to have as a backup option. We’ll be looking at strategies that might be improved by running a swerve drive, but not dependent on it.

Pit Redesign

We’re constantly looking to improve the efficiency and layout of our pit. We’ve been slowly making changes to our pit over the past few years to make it faster to set up and maximize use of the space to make sure we have everything we need at our fingertips when we need it.

One of our major challenges in this arena is transportation. We currently do not have someone to reliably haul a trailer to our events, so we’ve been investigating pit setups that will give us the storage we need, but still be able to fit under a bus.

We’re currently looking at two large work surfaces, one of which is a folding workbench: https://www.homedepot.com/p/Husky-6-ft-Folding-Adjustable-Height-Solid-Wood-Top-Workbench-in-Black-G7200FW-US/315530067#overlay

The second work surface we’re looking at connecting a wood worktop to two Milwaukee PackOut stacks using these 3rd part connectors on the bottom of the worktop: Packout connectors

Overall current proposed pit layout:

Will provide additional updates on the pit as the season progresses.

[ASmith1675]

Mock Kick-off

For the last two meetings of the preseason, the team held a mock kick-off to prepare members both old and new for how we break down a game and begin designing a robot. This year we used the 2019 game for mock kick-off.

Our kick-off strategy largely falls into two phases:
1. Determine our strategy - This is the primary focus of mock kick-off
In this phase the team is focused on figuring out how the game will be played, independent of specific implementations or mechanisms. We list out different abilities robots will likely have, and then combine the abilities into robot archetypes.

Game tasks for we determined for 2019 game:

We use these archetypes to play a simulated game with human robots. Each student is assigned to a robot archetype and plays the game with limitations imposed by the robot type they’re portraying.

While this is going on, we (attempt to) have other students and mentors scoring the robot types to get an idea of effectiveness.

Examples:

• If a student is a tank drive robot, they can’t move sideways.
• Certain robots can only shoot or score from specific positions.
• We may have some student attempt to control game objects with only their elbows to simulate poor game object control.

We use any objects we have easy access to to simulate game objects as much as we can and layout the field with tape on the ground. We also have some people recycling game objects in what can only be described as organized chaos.

From this chaos we get some rough scoring breakdowns for the robot archetypes that look like this:

This gives us good discussion points as to what tasks we feel would be most effective to focus our time on. We (as a team) don’t have the capability to do everything, and want to make sure the parts of the game we decide to attack will have the highest gain for given time spent.

We typically have one or more student champion the particular archetype they believe in and discuss the pros and cons as a team.

2. How do we do it
The second phase of kickoff starts to get in to the specifics of how we implement the strategy we’ve agreed upon (to some degree). From here we start to look at the things we want to prototype to prove out our concepts as early as possible. This will obviously vary widely from game to game. We don’t typically dive into this part as much during mock kick-off, but will instead show both highly successful designs from the year we are breaking down, as well as other robots and designs that we might want to emulate (in some way) in the future.

Some sketches of the “how to do it” phase:

[Technologyman00]

Excited to see what UPS comes up with this year. We will see you at the Milwaukee Regional!

[ASmith1675]

Kickoff

Last year we moved from Saturday-Sunday meetings on kickoff weekend, to a single very long meeting on Saturday. This allows our students to have Sunday to process everything we discussed before moving into build season proper, and (more importantly) give them time to get schoolwork done. We’ve also found that attendance on Sunday was usually a bit lacking and many important decisions were made without a majority of team members being present.

Long story short, kickoff has become our longest meeting of the year as we met yesterday from 9AM to 8PM to get as many decisions made as possible.

---

Pre Game Release

Before the game release we had a team discussion of our goals for the season. We want our goals to be as game-agnostic as possible as they will drive the discussion of robot concepts and abilities.

Goals are proposed and voted on as a team which we try to make as SMART as possible.

Team 1675’s goals for this year:

Overall the goals trend towards reliability and giving our drivers the maximum chance to succeed. We also aimed these goals to be attainable, but improvements on last year. Last year, our drivers didn’t really get much (any) practice until we were on the field in Duluth. We would like to rectify that this year by at least having something our driving can practice with 2 weeks before our first competition, again Duluth this year.

---

After Game Release

After reading through the rules, we broke down game objectives and robot concepts before running our humans-as-robots simulations to get an idea on cycle times and a better understanding of overall game flow.

One of the discoveries from this exercise is what appears to be a fairly effective defensive strategy:

With decent driving, the blue defender should be able to limit a red robot in their loading zone to the small corridor on the top of the arena. This area is already likely to be crowded for both alliances, and teams should be ready to run pick plays for their alliance members to break teammates out of this zone lock.

From the simulations and discussions that have occurred up to this point, students began pitching what we’d like to try to accomplish with respect to game tasks and what we’ll need to prototype to prove out these concepts.

1. We trying swerve for the first time, with this will help with parking on the ramp as well as maneuverability in the tight scoring zone and working around defenders.
2. We want to manipulate both cones and cubes, and pick them off the floor
3. We want to score on a least the 1st and 2nd levels (X means 1st level is not a focus, not something specifically designed for in this case)

---

Summary of the day from our Student Drive Coach, Noelle:

As a returning member it’s weird to think how new the game is after getting so well versed in the one from last year. It took a while to really understand what was happening, and how our team approaches it really helps. We read certain sections of the game manual and come together to recap so not everyone has to memorize it. We act out how a match works using people as robot stand ins to hammer home the process and movement of the game.

This has also helped in understanding which aspects of the robot are imperative and which can be improved on. Swerve drive was a resounding yes from the team, along with wanting to be more ambitious in going after multiple game pieces and height levels. But how exactly we do it is left up to debate, which is why the mentors’ experience with past challenges helps mold our ideas. We still have a while to go with prototyping our main subsystems, but at least we can feel confident we have a process to follow.

---

Next Up

Moving into this week there are still plenty of questions to be answered.

Additional things that we hope to finalize before the end of the first week.

1. Chassis size finalization and design in CAD. Hoping to begin manufacturing by next Saturday
2. Swerve base bring up and programming using our offseason chassis.
3. Investigation into pass-off arm vs. do it all arm/claw

[paulonis]

I think your team is right about defense exiting the loading zone. There is really not much space there that a defender needs to take up to be a real nuisance. The chance of coercing the target into the opponent loading zone and picking up G207 fouls makes this an even more effective defensive strategy.

[Technologyman00]

@ASmith1675

questions to be answered.

Something I was showing to the students on my team is that it’s not really about height but more about distance. The robot can be 6’6" and the tallest scoring area is 3’6"

[ASmith1675]

Yeah, i think its mostly terminology confusion. This is the first real “reaching” game in quite a few years and wrapping our head around the difference between lift up vs over will be a consistent conversation.

[beckz0rz]

Day 1

Intro
Hey everyone, I’m writing today’s update. I’m Rebecca (they/them) and I’m one of the lead mentors of 1675. I’ve been mentoring the team for 8 years and I describe my position on the team as “making the team run.”

Today’s (Monday’s) Meeting
For background, our team meets for 3 hours on 3 weekdays (Mondays, Tuesdays, and Thursdays) and 7 hours on Saturdays during the build season.

We started off today’s meeting with some group discussion of how we had been (as a team) using the word “intake” to really mean 3 things:

I also clarified that the challenge of scoring on the third level is more about reach (distance) than height, thanks for the good suggestion @Technologyman00.

Then we tried to answer some questions from our design team (on the right) and talked about how important we thought it was for 3 robots to fit on the charge station and how that affects the design questions.

As this is our first year doing swerve drive, we decided to have someone research how hard swerve is with a square chassis vs with a rectangular chassis, as that seemed like the easiest question to answer.

Then we broke into groups:

• Swerve team (1 programmer + 1 electrical student + 1 researcher) to get our prototype swerve drive from the preseason working and doing the research mentioned
• Woodie Flowers essay team
• 3 prototyping groups inspired by something a 111 mentor mentor used to say to our mentor James when he was a student – “Plan your work; work your plan”

Standup
Swerve team reported back that they had fixed some wiring issues on our prototyping and that all components were now getting assigned CAN IDs. They also said that 95% of team use a square chassis for swerve drive and recommended that since we are new at this, we do so too. The rest of the team concurred.

1st prototyping group made some progress on what we are calling a “lobster claw” manipulator for intake & placing:

2nd prototyping group has sketched an idea for a roller claw manipulator for intake & placing:

3rd prototyping group tested 2 ideas – scooping and a “forklift” under the cones. We will not be continuing with this prototype because it was hard to get material underneath the cone that is strong enough. They will be pivoting to something else tomorrow, a suggestion being a “combo roller scoop”. More info from another mentor on what we tried:

• This team started with scoop, testing on the carpet with the cone (upright position) with .1" lexan filed to a single edge could not get under the cone. The “feet” of the cone rest below the nap of the carpet, we could not get under it. 2nd iteration was a “fork” to pick up the cone between the feet. There really isn’t a “flat” surface on the bottom of the cone, it is hollow, so it needs to be supported from both sides, and/or all the way across the base. This also applies when the cone is on it’s side.

• The cube is so light and bouncy that is was very difficult to get it to stay on the scoop, really needed to be pushed against a backstop. We could get under it with enough speed, but it would bounce off the back of the scoop.

[ASmith1675]

Build Season - Meeting 2

I’m currently able to keep track of the number of meetings we’ve had since kickoff. We’ll see how long this is able to last.

As a longtime first veteran, I’ve found this game particularly hard to pin down for our team. Typically, by this point I feel like we have a decent idea as to generally where we want to go, but the reaching element of this game is new territory for me in FRC and has my mind tripping over itself.

Luckily our students have been charging forward with several prototype intakes and grippers.

Prototypes

Geared gripper: Simple and effective for both game objects.

RI3D Inspired Passive Orientation Gripper – could be combined with other options. I have a strong feeling we’ll be seeing a lot of these in the competition season.

Roller Claw: Our design philosophy in the past 8-10 years is typically: figure out how to do it with a roller claw. Most of our most successful bots since I’ve been on the team have been some implementation of a roller claw or roller intake. With that in mind, we also took the arm from our 2018 bot to quickly test the validity of a side-by-side roller intake, decent success. A little improvement with geometry seems to make this reasonable viable.

Swerve Update

We got our first bench test of the offseason swerve chassis we build. We found a dead sparkmax in the system (salvaged from an old robot). Overall, the team was impressed at how quickly the code worked out of the box.

A few gremlins were encountered when we tried the first drive test after replacing the controller. Seems like we had lost our calibration values in that switch-out. Part of the learning process, and something additional we’ll be adding to our swerve troubleshooting list when we find a solution.

Hopefully video to follow soon.

Other strategy discussions

Chassis Size

We’re currently looking at a square chassis for our first-year swerve. Initial research indicated most teams run square swerve, but there shouldn’t be and inherent issues with running a rectangular (or irregular) drive base. Overall, we decided for our first year, we were going to make it as easy as possible to troubleshoot by going square.

We also want to be on the small side, and there is a bit of a debate about size. We’re currently looking at something between 25x25 and 28x28. This decision will be finalized Thursday to begin cutting our new chassis members and getting the “real” drive base up and running ASAP. We need drivers to get practice with this new paradigm to make it effective.

We also raised the possibility of a chassis cutout with an offset arm. This has the possibility to allow scoring with a single jointed arm, as well as giving a good datum for alignment. Overall the team was intrigued with the concept, but we’re going to let it marinate for a bit before fully committing. The current concept would basically be a tunnel under the scoring side of the robot, so it would be fairly easy to replace the frame member to make this change.

There is also an ongoing discussion of the merits and challenges of ground pickup (particularly for cones). We’re hoping to limit our mechanism complexity this year to be able to focus on maximizing swerve for the team. Discussions will continue through the weekend of our overall strategy.

[Python_42]

Hello, my name is Jake and I am the lead programmer on Team 1675. I have a few more notes about the development of our swerve chassis that I am going to share:
As Adam noted, we were able to find a dead motor controller on our development chassis, which we replaced. After replacing the dead motor controller, we were able to drive the swerve chassis. However, the robot was not able to drive in a straight line, and rotating in place resulted in the robot drifting away from its starting position. In the next few meetings, we will examine the swerve chassis to determine if the issues are being caused by hardware failure, which was a common issue with this particular chassis as we are using very few brand new parts. As Adam noted, the issues we encountered also seemed to stem from incorrect offsets, which we will investigate next meeting. Despite these issues, the demo of swerve drive proved to us that swerve will be a very important strategical asset to our team this year.

[Python_42]

Build Season - Meeting 3

1 / 12 / 2023 Summary

During Thursday’s meeting, the majority of the team continued to work on prototyping possible manipulator ideas As well, a few programmers worked on the swerve chassis.

Swerve Chassis:

As we noted in a previous post, our swerve chassis was behaving erratically at the end of last meeting. After closer examination, we found that an encoder cable was unplugged. After fixing this, our swerve chassis worked overall. Before testing the swerve drive, we added scalers to the drive code so we could scale down the speed to safer levels. We also added scalers to the x translation, y translation, and rotation motor outputs. This allowed us to target certain robot behaviors with our testing. We were able to drive in a reasonably straight line, but this is something that we will be investigating further as a team. We were also able to gain a deeper understanding of field oriented drive, which our swerve chassis uses. We anticipate this type of driving being very popular with our drivers and giving us a competitive advantage on the field. During the later half of the meeting, we began preliminary research on autonomous driving with swerve drive. We will likely use PathWeaver, which is something we are still unfamiliar with as a team. We will have more information about our approach to autonomous driving with swerve next week.

X and Y translation with rotation. Field oriented driving works very well



Rotation is working well

Prototyping:

During Thursday’s meeting, we split into a few small groups and worked on four different prototypes. Our prototypes were:

• A claw
• A horizontal roller claw
• A vertical roller claw
• An auto cone righting grabber (inspired by Ri3D)

The claw was largely successful as a prototype. It was driven by a gear train; two small gears in the center for spacing and torque with the ‘fingers’ mounted on larger gears on the outside. The prototype was actuated with a drill by one of the hex shafts connected to a center gear. It was able to hold a cube without difficulty, but to grip a cone we had to add a piece of rubber for friction. There were some problems with the presence of torque on the drill, however this problem would likely not transfer to our final manipulator. The claw still can’t grip the cone without constant pressure being exerted inwards onto it, but we reasoned that this would not be an issue, as there will always be a gearbox between the motor and the claw. Depending on how the claw concept is implemented, it could be very advantageous. The claw is potentially capable of picking up from the ground or from the human player, and placing at all three heights. However, ground pickup may be a challenge since the claw does not provide an ideal opportunity for correcting the orientation of collected cones.

The roller claws were also successful prototypes. Both orientations of roller claw were able to collect cones and cubes quickly. Both orientations also were able orient the cones in a predictable manner, which would be essential for scoring manipulators. However, the horizontal roller claw faced some issues when collecting a cone which was standing upright. The cone would get stuck underneath the roller claws wheels, jamming the intake. This could pose a problem for the reliability of the roller claw. However, team members theorized that this problem could be solved with a bar over the roller claw which would knock over upright cones.

Vertical roller claw

Horizontal roller claw

Finally, the auto-righting cone grabber was not entirely successful, but it was a good proof of concept. The grabber would close on a cone in any orientation or a cube. The game object would (theoretically) be held in between the ends of the grabber. Our prototype implementation was not able to reliably hold game objects, as they would often slip out from between the grabbers ends. This could most likely be fixed with either more friction or more grabber surface area. Once the game object was grabbed, the grabber ends would rotate, reliably orienting the cone upright. This could be a huge advantage as far as building a scoring manipulator if we decide to implement this concept on our robot. Overall, the grabber prototype was successful because it showed us the advantages and disadvantages of this concept.

[ASmith1675]

Build Season - Meetings 4 and 5 Summary

We’ve been continuing with out prototyping. Overall, there are some interesting concepts, but we’ve yet to find that eureka moment that has screamed “this is what we should do”.

We’ve been using old robots and parts as quick-turn prototypes to get as much information as possible.

The team as a whole is still struggling with exactly how we want to play this game, which has put us a bit behind where we’d ideally like to be after a week. Based on the resources we have available to us, we are likely not going to be able to do everything as efficiently, so we will need to have trade-off discussions as to what we feel is more important.

Our current list of questions to lead strategy discussions:

Current chassis CAD is coming along nicely, but may be subject to change based on other decisions.

Focus for the upcoming week

• Finalize strategy decisions
• Begin major mechanism layout in CAD
• Manufacture chassis piece
• More swerve code refinement

[MachoStoopid]

What do yall do for cleaning up your plasma cut parts?

We have just been going by hand w files and deburring knives which can be time consuming.

[ASmith1675]

We’ve also been using primarily hand files and deburring knives.

We also have a few of these for quick deburring of holes: McMaster-Carr We just throw them into a drill chuck and they do a decent job. Perhaps not proper process, but good enough for what we need.

I’m sure I’ll go into more detail about our plasma cutting process in the future, but the quick overview is that any hole we need that is 0.25" or below is setup up as a pierce operation and used as a center-point where we drill the holes on a press (or with a hand drill when we’re in a hurry). I think this process makes the cleanup of holes a little easier, but obviously the manufacturing has an extra step.

[MachoStoopid]

I’m going to have to steal that hole cutting process, right now we have just been dealing with the oversized holes which has its own set of issues. Its always nice to know there’s more of us out there with plasma only haha

[ASmith1675]

Yeah, it a bit of a pain on the CAM side. We have to import all of our files into AutoCAD after exporting as dxf to move the pierce operation to a different layer for this process to work on our machine. It would be nice if we could just do this directly in OnShape without the need for the secondary software.

[ASmith1675]

Meeting 6 - Decisions, decisions

After being a bit stuck on our path forward for a few meetings, we had a very productive strategy discussion with the entire time to align on an overall strategy for our robot.

We broke out into two teams who discussed game flow during the auto period as well as the tele-op and endgame period. This allowed us to solidify what we want to design for.

Autonomous Analysis Takeaways:

• Take advantage of human alignment pregame to easily score a cone at max height
• No level related bonuses – more pieces are better, regardless of location
• Scoring cubes low seems strong in auto for a fast way to score a lot of pieces (possibly launching with bumper over line)
• Likely 3 zones divided among alliance members: Left, Middle, Right will be common. Left and right available for multi-piece autos, center to score pre-loaded piece and balance.
• Best to end in the middle to start cycling, if time

Tele-Op Takeaways

• Best to clear out any remaining game pieces in left after auto first; probably 4-6 in early weeks and decreasing as level of play increases. Likely not enough game pieces for every robot to grab one.
• Majority of scoring will be loaded from human players
• Dropped pieces are most likely to be in protected zones (when attempting to score), minimizing the effect on lowering cycle times. (Compared to 2017 where gears were largely dropped in unprotected areas)
• May need a way to signal human player for correct pieces, or align on a pattern or strategy with alliance
• Defense could be very effective in creating choke points with uncoordinated alliances. This could shift the meta towards having shuttle bots to reduce traffic.

Endgame Takeaways

• Aim for at least a double balance
• Triple is definitely possible
• Continuing to cycle could be more valuable than triple balance depending on state of links. Finishing a mid-link + park is equivalent to an additional robot balance, plus a possible RP

---

After this discussion we had a trade-off discussion, to best understand our priorities as a team. While everyone would like to be god-bot game-dominator, we would prefer to be good at a few things compared to mediocre at everything.

We identified 3 strategy decisions which we considered high complexity and voted against each other to find what we would prefer for focus our time on.

These high complexity items were (in the order of importance that we ended up ranking them):

1. Score high
2. Maintain a small chassis
3. Ground pickup with pass-off to a high scoring mechanism

This was compared to what we considered our baseline robot for us, which would be

• Mid scoring
• Dedicated Ground Pickup for Cubes (no pass-off)
• Full size chassis

This will allow us to make quick design decisions. We’re basically throwing out the lowest priority high complexity task. After that, if we need to sacrifice having a small chassis for scoring high, we will do so.

---

Robot Concept

Overall this gave us the picture of how we’re planning to play the Charged Up (subject to change at a moments notice).

Robot:

• Ability to score cubes and cones at all levels when loaded from human player
• Ability to pick cubes (and maybe cones) off the ground, but only for low scoring or shuttling
• Small chassis to support possible triple balance and minimize congestion
• Swerve drive for maneuverability

High Level Strategy
Auto Options:

1. Multi-piece (hopefully 3) auto, 1 cone high, 2 cubes low
2. Cone high + balance

Tele-op Options

1. Quickly fill low goals with cubes to collect links for RP
2. Cycle from human player playing mid/high goals for points
3. Shuttle from human player to an efficient placer to minimize traffic
4. If needed, play defense in “the corner” to create bottlenecks.

Endgame Options:

1. Double/Triple Balance
2. 1-2 additional cycles to complete links with more open field

[ASmith1675]

2 for 1 Wednesday

The rare double-update!

As we’ll be diving into more complicated design aspects over the coming days/weeks I wanted to share how we’re attempting to make sure multiple designers are on the same page. To that end, we’ve created a requirements document where the needs to the design are captured before they end up in CAD.

Here is a portion of what has been built out so far:

This is the first year we are trying this, but so far its been reasonably successful. We’ll continue to update and refine as the season goes on, but at the very least this will be an excellent repository of our design decisions and a nice talking point for judges.

[Python_42]

1 / 23 / 2023 Meeting

Programming:

Swerve drive:

The programming subteam has continued working on the swerve chassis quite a lot. Recently we have been investigating how swerve can help us in autonomous. We have been looking into path generation tools, namely PathWeaver and PathPlanner. These two tools both seem like they will be able to fulfill our needs. We will characterize the robot and choose between the two tools in the few meetings. As well, we have been working on using the gyroscope to perform some tasks which will be helpful in autonomous. We wrote a new command which makes the robot rotate in place back to a specified angle. This command uses a PID loop to ensure that the robot does not overshoot the target angle. We also used the gyroscope to correct for mechanical issues that were preventing the swerve drive from driving straight. This works using the following logic:

1. When no rotation value is provided, record current gyro angle.
2. Call drive subsystem with provided x and y translation and rotation correction value calculated using PID loop with recorded gyro angle as target value.
3. Repeat step 2 until a rotation value is provided.
4. If rotation value is provided, drive based on provided x, y, and rotation values.
5. Repeat step 5 until a rotation value is provided
6. Once a rotation value is provided again, go to step 1

This makes sure that the robot is rotating back to the point that it started with.

In case it has not been linked already, our Github is https://github.com/frc1675. 2023 robot development is taking place in GitHub - frc1675/frc1675-2023: Team 1675 robot code for the 2023 FRC competition Charge Up, and swerve development is taking place in GitHub - frc1675/swerve-dev: Code for initial swerve drive base development (for now).

AprilTags

The programming team has also been working on using a limelight to identify AprilTags. After numerous networking issues, the limelight was able to successfully identify AprilTags. The team also experimented with robot pose information from AprilTags. This worked very well, and will be very useful during autonomous.

Prototyping:

Our prototyping team has been working on our final prototype, which is a high-fidelity prototype of our cone and cube manipulator. The team continued testing our intake prototype based on 118’s everybot design. This prototype allows the team to try different wheel types, shaft spacing, intake width, motor speed, and intake angle. We are finding success in using AndyMark brand ‘Sushi Roller Intake Wheels’ for both cone and cube manipulation. We tested wheel reliability by running intake tests 50 times during the meeting. This is important, as we want to avoid frequent wheel changes during intake-heavy competitions. The reliability was promising, and we found a slight tradeoff between wheel traction and durability. Additional testing saw the use of our wooden grid structure. For the first time this build season, we were able to practice scoring by holding the prototype above the grid. The tests demonstrated the extension distance to score high, and also highlighted the strong scoring capabilities of the everybot intake design.

CAD:

The CAD team has been working on converting notebook sketches into 3D models. With 3 new CAD members leading the design, we have been focusing on simplistic design targeting 3 key areas of the robot: chassis, arm, and manipulator. We are targeting a 26in x 26in swerve drive chassis to allow us to easily fit multiple robots on the Charge Station. As we began the design of the arm, we quickly realized it would need to mount directly above the swerve module. We are in the process of expanding the chassis vertically to include a 2nd tier of 2in x 1in MAXTube which will allow us to mount the arm directly above the swerve module. The arm is currently being designed as a 1 DoF arm pivoting from the max height. This design should allow us to score high, mid, and low as well as picking up from the human player shelf stations. We are moving forward with an everybot style manipulator at a fixed angle on the end of the arm. We found a 115deg angle between the arm and manipulator allows us to reach the required scoring positions as well as keeping a simplistic design. With the information from the prototyping team, we have begun to design our own more compact everybot style manipulator.

Arm assembly

Chassis assembly

Test Field:

Finally, a few members of our team have been working on constructing a wooden scoring station for our drive practice and autonomous testing. They finished up the middle cube tiered design and started completing the first of two cone areas. Having access to this will vastly improve the quality of our autonomous and the skills of our drive team.

I am excited about the progress we have made and I cant wait to see our robot come together.