2521 SERT Open Alliance Build Thread 2023

[catbert]

Hello everyone! We are team 2521 SERT from Eugene, OR. We began in 2007, and we are the only FRC team in the Eugene/Springfield area. After a rough start to 2022 with only 10 returning members, we are now operating with upwards of 30. We’ll be giving a short update on what each part of our team is working on, and we’ll be sharing our CAD and code this year.

We are currently working on our robot for Bunnybots, an offseason competition hosted by team 1540 The Flaming Chickens in Portland, Oregon. This week we are doing the final touch-ups on the robot before the competition this Saturday, the 17th.

This is our first year being a part of the #openalliance but we hope to be a part of it for a long time to come!

Website
Github
Instagram

[catbert]

BunnyBots Season Recap

Finalists! This was our first finalist appearance as a team since 2018. Thank you to teams 3711 Iron Mustangs, 6831 A05-Annex, and 2898 The Flying Hedgehogs for making up a killer alliance with the top two high scores of the competition! Congrats to the winning alliance of 2471 Team Mean Machine, 4043 Nerd Herd, 2733 Pigmice, and 3636 Generals! You all were a blast to play against, and we loved getting to see your amazing robots in action.

We went for an ambitious design with 5 new concepts for team members: a swerve drivetrain, pneumatics, chain, an over the bumper intake, and an elevator. Everything except for the swerve modules was machined in-house and assembled in record time. We learned a lot about our machining capabilities. As well, we had to figure out how to work efficiently and productively while still teaching our newer members how to be contributing members of our team and our community in general. We chose to build a very ambitious robot and we learned a lot from it. Last season SERT was focused on being able to compete and have a robot at all, but this season we are lucky enough to be able to start thinking about how we can build better and more complex robots. We’ll be summarizing an entire build season in one post, so buckle up!

Kickoff Process

Through the 3-meeting (2 hours each) process, we ran through a presentation linked here. We started with a brief overview of goals and things to keep in mind while reading the rules, then we read relevant sections, followed by filling out this worksheet (Adapted from a similar sheet by 2791 Shaker Robotics) in small groups. After this, we created a list of robot roles as a whole group, which we then ranked. We then brainstormed more specific robot attributes (still not mechanisms), and organized those into needs, wants, and luxuries. Next we ran through a quick presentation on mechanisms (thanks to team 6328 for some of the images) to familiarize our newer members with some good examples. We then broke up into groups of ~5 to draw up robot/mechanism ideas, roughly evenly by experience. When this was done, each group presented their design to the full team, allowing us to discuss as a group which designs to eliminate until we had 2-3 to prototype for each subsystem.

Overall, this process worked pretty well for us, but the processes for robot role and attribute brainstorming and organizing felt a little long and repetitive at times. The mechanism presentation felt quite useful, but it does need informed explanation to go with the pictures. Going forward, we hope to streamline things more in all aspects, which just comes with practice. The rules worksheet was also difficult to get participation on from new members, so we may make it shorter in the future. We also could’ve done better on revisiting our priorities for robot roles and attributes, which would’ve allowed us to change them over time and keep them as a guideline for our design process.

Prototyping Process:

We started with very rough plywood prototypes of individual subsystems made by groups of students, each with a student lead, then followed up on these prototypes with further iterations cut out of ½” plywood on our CNC router, including slots for bolts and multiple sets of holes that allowed for adjustability. As we nailed down certain subsystems, our prototyping became more and more refined within other prototyping groups. This iterative prototyping process is something we haven’t done a whole lot of in past years, but was a specific goal going into this build season.

Above: The CAD for our first CNC intake prototype, using a combination of slots and bearing blocks to quickly nail down dimensions that allows it to be held against the bumpers of an old KOP drivebase for quick testing.

Major takeaways:
The rough plywood prototypes were a good starting place, and the adjustable ones made on the CNC were super useful as they allowed us to dial in dimensions for things like intake compression within a single prototype iteration. The only thing we would really change about that is using higher quality, thinner plywood (like ¼”) instead of ½”, which would be quicker to machine and hold up slightly better. Our iterative prototyping process yielded much better results, and allowed us to make much more informed decisions. This was crucial in a game that included such unique game pieces. Not doing any integrated prototypes was definitely our biggest shortcoming here, as we lacked a way to see clearly how they would interact and it led to the manipulators being somewhat prone to jamming.

Prototypes that did not succeed and why:

• Tube Ejector: We considered using spinning flywheels to eject the tubes into the totes. We even prototyped it, making a high-velocity tube launcher. This was a viable option, but we decided that it would be too difficult to control.
• Stepped box: Early on we attempted a passive tube alignment system, using multiple steps. The hope was that gravity and jostling would cause the tubes to fall down the steps aligning themselves. This didn’t work well at all. The tubes had a tendency to get stuck on the walls, other tubes, the steps, and anything else possible.
• Inside the bumper intake: Had trouble intaking tubes at non-ideal angles, and with tubes having to pass through the bumpers to the compliant wheels, many tubes would be knocked off angle by the robot.
• Roller claw: This one also had trouble with misaligned tubes. Depending on our design it also would have been subject to the bumper knocking the tubes out of alignment similar to the inside the bumper intake.

CAD Process:

We used master sketches in Solidworks to create a complete and easy to edit model of our robot. We also split into two groups led by our experienced CAD members to divide the work into more manageable chunks.

Above: Our intake master sketch

Major takeaways:

While master sketching is a pretty common practice in CAD across different software, we definitely recommend it to any team who doesn’t already do it—it really makes a world of difference (This is a great video to get started). In the future with master sketching, we would want to divide the master sketches into more layers for easier editability and fewer errors within sketches when changing dimensions. Going forward, we’ll also definitely want to implement some sort of “crayola CAD” to decide on packaging earlier and avoid as many conflicts later on when combining the work of our two groups. Similarly, doing a crayola CAD would have forced us to nail down an indexer concept sooner, which would have made the CAD process smoother than it was, having to design around a big unknown subsystem.

Learning with our Shapeoko 3 XL

For those with a similar machine who are having struggles, what we learned throughout bunnybots may be very useful. We started off using ⅛” 2 flute and ¼” 3 flute end mills from Carbide 3d for aluminum, but they were not very successful. We used the ¼” bit for slotting and roughing to get faster material removal rates, but needed to do tool changes after making our smaller bolt holes with the ⅛”. The 3 flute bit would frequently get clogged and run into chip welding even at slow feeds with a low DOC, leading to a not-so-fun end to the run and terrible reliability. Manually clearing chips with a brush did help some, but this didn’t feel at all like a sustainable long-term solution. Upgrading to a 4 mm single flute end mill made a world of difference. We also started using an electric duster for chip clearing with air blast which isn’t perfect, but we already had it. These two things combined are not exactly revolutionary in the world of CNC routers for FRC, but especially on a lower-end desktop machine like ours, don’t underestimate the difference they can make in reliability and speed. We still got the new equipment pretty recently so we’re still testing how fast we can get with it, but for anyone with a similar machine feel free to reach out and we’ll let you know our feeds and speeds as soon as we figure them out.

TL;DR: Use single flute end mills and air blast, they completely transform a desktop class CNC router.

Intake

This was the first time that any current team members had done robot pneumatics. We broke our team’s usual rule of using pneumatics on multiple subsystems by only having a pneumatic over the bumper intake, but it ended up being a good way to learn about pneumatics because the system was fairly simple. We used Festos instead of CKDs because we had more of them (so we had spares) and it was easier for us to change them in and out of manual and software mode. We found that bubble testing was a very good way to locate leaks in the system. When we did this we found that one of the fittings on the air tanks was loose and was the sole cause of a large pressure leak. Because the game piece this year was 4.5” diameter 11” long tubes, we decided on a maximum width four bar over the bumper intake with 2” and 4” diameter compliant wheels driven by one Neo motor and a passive kicker bar. We had one piston on each side of the intake with a ball joint on the end to hopefully reduce piston bending if the intake got hit while the pistons were extended (while the intake was retracted). This design wasn’t as troublesome as some of us were worried it would be (we hadn’t built an over bumper intake before or done robot pneumatics). We only put spacers between the larger compliant wheels with the plastic hex hubs, but not between the smaller compliant wheels that were hex bore. This meant that after a few matches or intense testing we had to push the smaller compliant wheels back to appropriate spacing or else tubes would start to get jammed between the bars.

Indexer(s)

This photo shows the motor mount on the side of the indexer, and the belt path from the motor to the shaft below it. This also shows the churros that we 3D printed spacers for in order to use them as standoffs to a polycarb plate that we used for vectoring the tubes into the indexer.

This photo shows how our indexer feeds into our outtake box. We used orange polyurethane belting (on crowned pulleys) that we “welded” into loops using a heat gun to melt 2” of overlap of the ends of the belting together.

The picture above shows the lowest shaft on our over bumper intake while the intake is retracted. We used 4” diameter compliant wheels of different durometers, and they did a very good job of intaking the tubes even though the game pieces had very low coefficients of friction.

We have a two part indexer, one that was stationary, the other mounted on the elevator. Both are polyurethane flat belting on top, with polycarb bottom and sides. In our prototyping we found a maximum angle that we could mount the first indexer walls at to funnel the tubes into a thinner second stage without them twisting out of alignment. Also, during our prototyping phase we realized that we could use the tubes’ low coefficient of friction to our advantage. By limiting the amount of compression that the belts put on the tubes they would spin in place when pressed against a hard stop. This did two things: it allowed us to store tubes while the second part of the indexer was still running, and it would also correct for any misalignment in the tubes. We did still have numerous issues with misaligned tubes that we would have to eject, but with more tuning time we may have been able to minimize the number and effect of these jams. We had initial problems with the transfer between the two indexers because there was a polycarb lip that was stopping them from moving smoothly. Once we removed that the tubes had no trouble at all.

Takeaways:

Flat polyurethane belting continues to impress. With unfamiliar game pieces such as the tubes, more prototyping time is very useful in figuring out how the game piece will react in surprising ways.

Bunny Claw

Some of you may have noticed that there is not a bunny claw on our robot. We originally planned to have a separate bunny manipulator on our robot, but ran out of time. We were down to the wire to get the robot finished mechanically, much less give software an adequate amount of testing time. Additionally, we designed our tube path in such a way that it took up most of the horizontal area of the robot, making the packaging of a separate bunny claw very tricky. We were able to secure a 5.5” spherical bunny that worked well in our tube path. The only downside was that we couldn’t index both tubes and a bunny at the same time without a high probability of jamming. Usually that was not a huge issue, but during eliminations when we were under heavy defense for the duration of the match, every cycle was precious. That meant to score our bunny, we had to sacrifice almost an entire tube cycle. If we had a separate mechanism that wouldn’t have been as large of an issue.

Takeaways:

We need to manage our building time better, and prioritize what we need to complete. This includes also having more realistic goals during designing, and also adapting as our schedule changes throughout the build season.

Swerve

This was our first ever competition using swerve. We decided to purchase Swerve Drive Specialities Mk4i modules last spring, and although we had gotten them driving over the summer we hadn’t tested them in a rigorous way. We were using Falcon 500 drive motors and Neo turning motors. The robot was finished mechanically and electrically a week before BunnyBots, and while our software team had already programmed several subsystems and drive code, there was still a lot of tuning to be done, especially when different mechanisms needed tuning and repairs. This only gave our handful of drivers about five minutes of total drive practice each (they all rocked it at the competition though). Our main challenge was with machining the frame. We did not have any hole patterned tube in stock, so we had to machine it ourselves. We took 30” pieces of 2”x1” ⅛” wall tube and with our manual mill put the 8-32 mounting holes for the modules as well as the 10-32 holes for the rest of the subsystem mounts. This worked well, but took a good four hours to machine all the holes. Overall we are very happy with how the modules performed, and how easy it was to set up the frame mechanically.

Takeaways:

We cannot recommend SDS modules highly enough. Zero issues so far, we are very satisfied customers. Machining frame tube takes WAY too long, so we’re planning on purchasing hole patterned tube for the FRC season. We have awesome drivers!

Elevator

Building an elevator from scratch was an ambitious goal. Our last experience with an elevator was 2019, and we had no current members with any experience building elevators. We decided to build a two-stage bearing capture design, modeled after the West Coast Products GreyT V2 elevator. However we made a few small changes to the design to fit our specific needs, including changing motor mounting and moving the second stage rigging to allow passthrough.

Since we were not using hole patterned tube, we had to spend a lot of time just drilling out mounting holes on our drill press. We then had to spend a lot of time squaring up each elevator stage, because surprisingly we’re not perfect at locating holes. As mentioned previously we are going to use hole patterned tube, so this should be a non-issue going forward.

Due to our previously mentioned indexer design we needed to maximize the width of the elevator carriage because the carriage width would dictate our intake width. To make the elevator as wide as possible, we mounted the drive motor parallel to the bottom shaft spaced out on a ⅛” aluminum plate attached to the base of the elevator (remember that, it WILL come up again). We used a Neo in a 50:1 planetary gearbox which drove the lower elevator shaft via a short chain run. The motor was mounted from the bottom of the gearbox by two bolts spaced up from the plate, as well as supported under the motor. This caused several problems. Remember that ⅛” sheet aluminum. Well, it turns out that the force needed to lift an elevator is pretty big. That force tried to pull the motor output shaft and the lower elevator shaft closer. It succeeded, and bent the aluminum mounting plate.

Over the course of three days we tried different solutions to try and fix this problem. We began with the lazy fix, securing another piece of sheet ⅛” aluminum between the drivetrain and the motor mount plate. This worked, but since it wasn’t attached at the end of the plate, it only stopped part of the bending. We then attempted to install a single plate with two bearings spaced at the correct shaft distance at the end of the motor output. The intent of this was to keep the unsupported end of the output from being pulled closer to the lower shaft. Technically this did what it was supposed to.

However we were faced with multiple more issues: the lower shaft was bending when the motor was being driven, and we still had not addressed the root issue of the bending motor mount plate. To get it to finally work, we implemented multiple fixes simultaneously. We bolted a second two-bearing plate to the output side of the gearbox in an attempt to keep the shaft from bending in the area with the chain run. We also replaced the motor mount plate with an equivalent piece of ⅛” aluminum angle that both keeps the plate from bending, and twisting because the angle was braced up against the drivetrain. Although this held through the competition we noticed that one of the bearings was still popping out, and may have even broken. We have yet to do a full inspection on our robot after returning from the competition, but competition seems to have taken a toll on this motor mount. This is definitely something we’ll have to keep in mind if we design an elevator for the 2023 FRC season.

We had issues with dyneema tensioning (or the lack thereof), although none of them seemed to be complete showstoppers. We had a clamping system that was meant for tensioning, but it slipped frequently and was inconvenient to tension. A system using a ratchet like on the Thriftybot elevator or Greyt elevator would be slightly more complicated but more effective.

We use rather hefty chain, #35 to be exact. I don’t know why we’ve accumulated so many #35 sprockets and chain parts, but we have, so that’s what we used. We used two AndyMark in-line chain tensioners to make sure we didn’t have any chain skipping issues. Due to other issues our elevator wasn’t perfectly square, so on one side the chain was not tensioned even with the tensioner trying its very best. This wasn’t causing issues until we got a tube stuck crossways in the elevator and tried to lift. As you can guess, that didn’t go very well. The chain made an awful skipping noise. The chain was less tensioned after this incident so we decided to remove a link and retention from there. Unfortunately when attempting to loosen the chain tensioner, it sheared. We suspect that the internals on the tensioner had been damaged during the chain skipping incident. We also neglected to buy any spares, so we were two days out from competition and an irreplaceable part was broken. We were luckily able to just reattach the chain without the tensioner, and although it was quite slack it worked for the duration of the competition.

One last note. We spent a lot of time disassembling and reassembling the elevator to replace bolt heads that were interfering in the elevator’s travel. Try not to let that be you. Use low profile bolts, rivets, or just be very careful to leave plenty of clearance.

Takeaways:

Unfortunately Newton’s 3rd law still applies, no matter how much we wish it didn’t. Cantilevering a motor is a recipe for disaster, and we need to approach our motor mounting solutions for elevators cautiously. This especially applies if we need to climb via our elevator. ALWAYS have spares. No matter how bulletproof you think a part is, if you don’t have a spare, it is the one thing that will break. Make sure that in CAD none of the bolt heads or nuts will interfere with elevator movement. Also make sure that you have all of the low profile bolts that you think you do before designing around them. Use hole patterned tube, or be able to machine it quickly in house. It will save you tons of time and headaches.

Mechanical Notes

• Talk to CAD! Make sure everyone who is working on a project knows the correct dimensions and put those dimensions on a Google Doc in the team drive so it can be accessed by anyone. This also prevents mistakes due to misread handwriting and losing checklists of stock dimensions.

• DO NOT skimp on buying inexpensive chain tensioners and buy spares. If your chain tensioner breaks, you need to be able to replace it quickly, as well, so put either half links or master links. Also, they only go so tight. Don’t try to over-tighten one, it’ll break. Snap right in two, and then you’re left with untensioned chain and disappointment.

• Elevators are precise and finicky. Stock up on low-profile bolts, because anything that could run into anything else is a problem. Try to give every bolt head and protrusion significant clearance from any moving part- more for wires.

• Bearings are finicky as well. If your elevator relies on bearings sliding smoothly against something, you need to make sure that your placement is precise, as if the bearings are too close together or too far apart, your elevator won’t quite work right.

• Elevators like to be square. They really do. Try to make things square as you build them- we used a system where we clamped each corner to something square in two dimensions, because then as we build it it’s solid and square. And don’t forget to check the alignment of your tools! We had to re-square parts of our elevator because our drill press table was slightly misaligned and drilled slightly diagonally.

• Remember to include junior members. There should always be enough work for everybody if you’ve planned well, so make sure to distribute labor so not every task relies on one thing that takes weeks. Try to make it so several tasks can happen at the same time, so you can go faster and don’t spend half of your build season waiting on another subteam or group.

Electrical

As far as the general layout for the electrical components go, our Bunnybots robot electrical board strongly resembled those that we had made in past competitions. Some key changes we made were wiring the Falcons, (which if anything was much simpler than the CIMs that we typically used on the drive train), and incorporating some pneumatics components that communicate with the rest of the electrical components. One other change we made was switching almost entirely to brushless motors. We used two brushed motors, a window motor, and a mini cim on the elevator outtake. Everything else was NEOs or Falcons. This meant that we ended up using Spark Max motor controllers exclusively. In the past, we had tried to incorporate Talons wherever possible for budget reasons, but given the quantity of Sparks we had from the previous season as well as new ones we purchased, we had a sufficient quantity to go all in on the Bunnybots robot. This helps because when only using Sparks, the CAN can be routed strictly from device to device without the need of canbuses which could take up space on the electrical board.

Speaking of space on the electrical board, due to some poor communication with other subteams, we ended up with a sub-optimal area to work with mounting components. We ended up using all but a few slots on our PDB, which made for some interesting motor controller placements going side by side, not even leaving enough room for zip ties, solely being held down by VHB tape. Additionally, we had to figure out where we could mount some pneumatic components which each presented their own difficulties. Whether it was the compressor needing to be completely isolated to avoid being near temperature sensitive parts of the robot, or needing a pressure gauge to be visible from a reasonable angle, we were left with a slim number of mounting possibilities just to fit the necessities around the PDB and Rio.

By far though, the largest problem we encountered was routing wires to the motors and sensors on the elevator. While we ended up with a functional robot, our solution was by no means a good one. We ran a strip of energy chain that curled with the elevator. We were only able to fit a few AWG12 motor cables through the actual housing so we ended up zip tying the other 2 AWG12 cables and a few AWG18 sensor cables to the outside of it. While this allowed for relatively uniform movement when the lift went up and down, it presented a very loose loop near the edge of our robot that could be potentially very prone to snagging as well as maybe pushing some frame perimeter dimensions.

As far as the components on the elevator go, we made an attempt to mount as few components to it as possible, but if we had to mount even one motor, adding other motors or sensors wouldn’t change the fact that there were wires that needed to be routed. In the end, there was a mini cim and a window motor, multiple cameras, as well as 2 limit switches on the elevator mechanisms that would all have to be run through the energy chain.

Software

For Software we used plain WPILib. We had experimented with swerve over the summer and had some swerve code built up from that. Currently we are still working on auto for swerve as the WPILib trajectory library is built for mostly tank drive. They do have support for swerve, but it is not very good, especially handling rotations can be annoying. We decided to experiment more with the robot code. So what a subsystem does and what a command does is not clear in the code currently. Currently, some subsystems manage the motors and only provide higher level control such as the intake, while subsystems like the lift provide low level control. I personally am leaning towards subsystems having most of the loops and lower level motor control.

We were hoping to use computer vision with apriltags for bunnybots, however we only had a few hours to test the robot so there wasn’t enough time. There is actually still the vision code in the code base, but it is unused. We had a really hard time getting vision to reliably connect. We only have a PI 3b (I think) due to the PI shortage and it seemed to have a hard time connecting to the roborio when using WPILibPi (it would usually fix after a restart of the vision code) and Photonvision only seemed to work with one camera. I was planning on fixing the WPILibPi connection problems by having it restart the code until the main robot code changed a NetworkTable value on the vision table. I never got to try that change.

We also added a whole system for tunable constants (you can check the code for details) that would allow you to change robot constants from shuffleboard for testing (not permanently). To my knowledge it worked, but it was never used because not a lot of tuning happened. Software only had a couple hours of time with the robot so the code is pretty messy. There wasn’t enough time to actually make the encoder values match any real world unit system (we always use metric software) so there are a lot of numbers that don’t really have any real world meaning. The PID values are more or less random and all the feedforward and PID values from Sysid’s tuning were doubled because those numbers were just tuned for the drivetrain which weighed less. Furthermore, I think the x and y coordinates are swapped. The auto also only really worked in testing so it had to be changed to do less in the actual competition.

The auto (actually hybrid, but we treated it as auto) for bunnybots was only ten seconds, meaning the robot had to move fast. Testing the auto also almost took up the entire testing room. When testing, the robot drove forward then outputted one tube in the inner zone, then drove backwards while putting the second tube into the outer zone. It then raised the lift, drove forward and outputted a tube into the top zone.

On the real field it wasn’t able to properly drive the right distance and we weren’t able to easily test on the real field, so the top zone part was removed out of fear that the flap was hitting the table.

Software Notes and Problems

• Brushed motors don’t work without disabling Hall Encoder for SparkMaxes.
• Indexers had to run at high speeds because speeds less than about 80% would make the tubes get stuck. This caused a lot of battery drain. Solution: Add encoders to the motors and run PIDF making them only run at 80% when needed.
• Robot rotated when there was no joystick input, but only for one joystick. Solution: The deadband was decreased for more precise movement in auto testing, but Ks in the feedforward were not tuned at all causing anything above 0.01 from the joystick to move it significantly, so increasing the deadband solved it.

---

And that’s our recap of our BunnyBots season! Thank you to the Flaming Chickens for hosting the competition, and to everyone for making it such a fun place to be!

[catbert]

SERT Pre-Kickoff Post

As the Kickoff comes closer, we've been preparing for the soon-to-be-busy build season.

Preparations Made:

• Cleaning our shop
  • Reorganized after BunnyBots, incorporating new stock and components
  • Getting the shop back to being a functional workspace
• Setting up newly donated laptops
  • Thanks to NuScale Power, we got 14 new laptops
  • It will provide a much-needed upgrade for media, software, CAD, and other subteams
• Ramping up business work
  • Finishing first wave of sponsor emails to allow for focus on awards
  • Preliminary discussion of FIRST Impact topics and approach
• Strategic streamlining
  • Planning regular design meetings
  • Pushing for more efficient strategy workflows

Our Goals:

• Robot finished by week 4
  • “First draft,” testable, robot is mechanically complete, and ideally fully mobile
  • Allows for more iterative design work
• Get picked at DCMP
  • This would mark a first for us; last year was close (ranked 16th after qualifiers)
• Win an event
  • This would mark another first for us
  • Coming off our finalist appearance at BunnyBots, we are optimistic
• Grow skills across the team
  • Expand upon experimental mechanisms used in BunnyBots
  • Closely involve newer members in both the design and build process
  • Juniors ideally end up having skillset parity with seniors
• Win a formal award
  • Shoot for FIRST Impact, as always, and Engineering Inspiration, Team Sustainability Award
• Start driver training during week 2
  • We will be keeping an off-season bot (Moose) intact to train software/driveteam.
  • Once our practice robot is complete, we will take Moose apart and use the swerve modules for our competition robot.

We also made a tour of our Foundry for those interested.

Shop/Foundry Tour!!

This is where our mechanical and electrical subteams do most of their work. It’s where we have our manual mill and lathe, CNC router, and a bunch of stock storage. (Back in the olden days this was our school’s auto shop and foundry)

We then have our makerspace, where Software, CAD, Media, Business, and Strategy make their home, along with some storage.

Finally we have our testing room, which is about a quarter of the size of FRC field.

---

So that’s what we’ve been doing! Hope everyone is ready for the Kickoff tomorrow!

[george.murchison]

Preseason Elevator CAD

With the expectation that Charged Up could be an elevator game, we decided to pre-cad an elevator that improved upon the shortcomings of our Bunnybots elevator and gave us a chance to practice making cleaner, more complete, and more easily editable CAD.

Design Details

• MAXTube Construction
• Machineable using a CNC router and hand tools
• Cascade rigging
• Use of gussets saves us cost as opposed to COTS bearing blocks
• Essentially an adaptation of the Greyt V2 elevator design

Step File Onshape Link: Onshape
Designed in Solidworks, so Onshape made the colors weird

[cincomurchison]

Kickoff Weekend

So far, we have mostly focused on strategy and mechanism ideas about the game, and just got started prototyping at the end of the day today. We discussed extensively how we want to approach the game’s challenges, but we’ll keep the post here limited to our major takeaways.

MoSCoW Sort

The end result of our game strategy discussions on saturday was the Must, Should, Could, Won’t priority sort pictured below (inspiration from team 6328’s 2022 Build Thread):

We decided that we needed to be able to pick up and score game pieces low, as well as have the ability to traverse the charge station to be competitively viable, but other than that our primary focus was scoring both game pieces at all levels. We feel that the point return (all of our numerical analysis can be seen here) for the high scoring locations compared to mid and low is too good to pass up. Turning cones upright is something that we plan to do if we (or someone else) can find a simple and easy way to do it, but otherwise we think we can get away with intaking from the starting positions in the middle of the field and the shelves at the double substation.

Mechanisms

We spent most of today talking about mechanisms, which left us with a table detailing pros, cons, and questions of various ideas we will and won’t move forward with:

For game piece handling, we are more or less between doing a roller claw and doing a “pinchy” claw with no rollers. The tradeoff we see there is that the roller claw is likely better at continuous intaking, but the lighter pinch claw could lessen issues with having extra weight far outside the robot at the high scoring areas. We will prototype both.

For getting game pieces to the high scoring areas, we chose to put most of our focus into developing geometry in CAD for an angled elevator with an arm on it, with a claw on the end that stays parallel to the ground using chain similar to 254’s 2019 robot. This also would allow us to add a wrist with few mechanical changes if it should seem necessary. We will prototype that part mechanically before implementing it. Rough sketch below:

We are also considering the “Pink Arm,” a telescoping arm on a pivot, which seems promising but difficult to execute with our manufacturing capabilities and knowledge. We chose not to rule it out and instead to wait as things develop to see if there are ways to do it that we feel we can approach.

We additionally plan to test what angle of polycarb our MK4i drivetrain can climb, what angle it slips at, and any ways we can prevent slipping if necessary. We think that it would be beneficial to keep from sliding around the Charging Station after balancing because it will make the process easier for our alliance partners.

[catbert]

The name of the game so far this week has been prototyping.

We have been working on five prototypes this week:

Adjustable angle elevator (Inspired by Cranberry Alarm Ri3D)

• Changed to use 2-stage elevator
• Manipulator positioned at an angle for better double substation pickup
• Current cone positions are sketched assuming use of a horizontal roller claw, but may be changed

Angled elevator with arm (in CAD)

• We worked through this design idea In cad and felt like it had potential issues with stability, arm length, and arm travel intersecting the grid

Static roller claw

• This is currently the claw that works the best on both game pieces
• However due to the extension limit, to be able to place a cone on a node you must hold the cone fairly far to the front of your claw, which is difficult with this design

Adjustable/Elastics Roller Claw

• What was intended to be an adjustable roller claw didn’t quite have the positions right, so we tested it with surgical tubing
• It’s ok…

Pinchy claw (pneumatically actuated non powered claw)

• Still in progress, but it works!
• After the initial claw mechanism was finished, we decided to add free spinning grips to allow for passive cone orientation. This claw (shown in the photo below) works as a proof of concept, it can hold cubes and cones, but the geometry is off. If we choose this design that is a problem that could be easily solved with CAD. Originally we had the idea to put a proximity sensor on the claw in order to improve accuracy when picking up game pieces, but when this was tested, unfortunately the sensor was too slow for this to be a good option. However, this prototype did exactly what it needed to do (show us that a simple claw could work).

Tipped Cone Claw (Inspired by Spectrum’s prototyping)

This was an attempt to find a good way to intake tipped cones with a continuous intake. The front wheels would pivot up about 90 degrees via pneumatics or spooling around the back shaft. This would allow us to place the cone on the nodes. With the extension limit being so close to the top nodes, if the cone sticks out the front of the gripper we can extend significantly farther. With the front wheels up, we would intake cubes through, and up against the back wall. To score it, we would softly eject it back out the front.

However, with 4 inch wheels, the wheels cover the base of the cone more than is ideal for placement, so we’ll try it with 2 inch wheels, and/or grippy rollers tomorrow in an attempt to avoid that. We also haven’t tried moving the claw into the game piece rather than the other way around. There’s a lot to prove with this one, but so far it seems promising.

Parallel chain linkage (virtual 4 bar)

• It works!

• We knew it would!

• The parallel chain linkage we made was #35 chain supported by two 32 tooth fixed pinions. The ‘arm’ we tested it on was simply three pieces of plywood bolted together, and weighed around 5-10 pounds. The chain was relatively tensioned (we didn’t do any math, just set it where the tension felt right and made our pivot there), and as such we were able to test it. We found that (material difficulties notwithstanding) the linkage was able to hold its ‘claw’ (more plywood) level and support its own weight. Honestly… this prototype was kind of just a sanity check. It’s nothing new and nothing interesting, so really what it did was give mechanical more things to work on and those of us who worked on it more practice with chain. Which, oh boy, we got.

  • In other news, our chain tool has taken a beating. Whoops.

• It is able to support more weight than our prototyping materials can handle

Charge Station Testing

One of the major questions we wanted to solve this week was figuring out how well swerve and the Charging Station worked together. How well would a swerve robot drive up, and park on, the Charging Station? This was our goal because if we can be the first one on the charging station, and stay there, it would make it easier for our alliance partners to get on. To test our question we built a roughly 16 degree test slope of polycarb to see how well driving on it went. While it wasn’t great, it was definitely doable, and we were able to move in all directions, as well as spin with no real slippage issues. More importantly we wanted to test what would happen when we disabled the robot. If the wheels were oriented up the slope, i.e. if you just drove up and disabled, it would roll back down. However, if we put it in “park,” where the wheels formed an X, the robot was able to stay in place very well. After some pushing, pulling, and kicking we decided that the robot was locked in on the slope.

After this successful test we wanted to see how we would fare on the original 35 degree slope that the entry to the charging station is at. After building another slope we again had good results. A caveat here though: our bumpers are a little loose, which definitely makes it somewhat easier to get the front wheels onto the slope. I’m not sure it would make a huge difference on the real Charging Station though given what FIRST has demonstrated. Overall some very successful preliminary tests. We’ll know more after we build our field elements.

CAD

We’ve started CAD for the elevator, which will hopefully be finished tomorrow. It is based off the design of our preseason elevator, gone over earlier in this thread. We are making some significant design changes to fit into our robot architecture:

• Swapping from a carriage that starts at the bottom to a full height carriage for further extension (laid out like a 3-stage elevator with no carriage)
• Swapping thrifty elevator style chain power transmission for tighter packaging using plates mounted to the side of the base stage near the bottom (not in CAD yet), with gears to allow the motors to be placed on the inside and still have a hex shaft across the whole way. The elevator will pivot off of this plate as well.

[cincomurchison]

Updated Elevator CAD:

[catbert]

Week 2 Update

• At the end of last week we decided to go with a pivoting elevator, and we are in the process of an official CAD review
• We popped our first cube! PSA: if your prototypes have spinning shafts near the game pieces, make sure that the bolts in the shaft collars aren’t sticking out. If they are, you may not have happy cubes.
• We got our first field elements and taped out our drive space
  • Bert!

We have also been iterating on our intake prototypes

Adjustable Roller claw

Static Roller Claw

• This was a new design that added new geometry for rollers. It’s pneumatically adjustable with one position for cubes and one for cones.
• It works fairly well. We tested more realistic reactions between it and game pieces by clamping it to a furniture dolly and letting the testers go for it.
• This was the cube popping culprit.
• Moving it faster means the intake is more forgiving, especially with cubes
• Pros: Handles both game pieces, smaller and lighter
• Cons: Very small intake area making driver alignment hard, can’t pick up tipped cones, needs actuation

Static Roller Claw

Static Claw

• No new testing on this design this week
• This is a hard design to make work for high cone placement because the cone needs to be gripped near the back of the claw. This means that placing the cone on the pole without passing the extension limit is tricky to put it mildly.

Cone pincher+cube intake (inspired by Spectrum 3847)

• Pinches cones between a 4” and 2” compliant wheel
• Cubes get intaken with a top roller
• Cone compression didn’t quite feel high enough, cubes worked well
• Moving forward, we will likely use the Everybot intake as a reference point to get a better grip on the cone
• Pneumatic gear linkage

• New claw geometry
• Actually works now!
• Tested up to 60 psi with no popping, holds cubes like a vise. Needs work on cones
• It could use a little bit more work to get the geometry right
• We might add a piece to prevent the cones from getting too deep into the claw
• We will add more grip to the claw with smaller gauge rubber tubing
• Pros: pretty lightweight
• Cons: would require a pneumatic system

Cone flange grabber
More details

• A quick note on strategy: The value of picking up tipped cones is not cut and dry for us. We’ve been able to agree on having it as a “should have” for our intake. If it is too difficult or time consuming we will hopefully be able to have the capability by our second competition (we are doing week 1 & 4 so we will have some iteration time between comps). Using the double substation should rarely be a problem, but dropped game pieces are where it will come into play.
• We did more extensive testing of this prototype, adding delrin skids to allow us to move it into game pieces instead of vice versa to give us a more realistic interaction. Our furniture dollies put it a few inches higher off the ground than it would be if it was on a robot, so the skids allowed it to be a realistic distance off the ground and let us push it into game pieces at appropriate testing speeds
• We were testing with the foam rollers teams can get from FIRST Choice. A word of warning: they disintegrate fast! It’s really too bad because the mounting solution we came up with was rather cool. They’re also a nice diameter and compliance. For those of you who are curious about how we mounted them, we took hex spacer stock, drilled and tapped holes in it and the roller to secure it to the hex shaft. It works surprisingly well.
• Because this only intakes tipped cones, we added a kicker bar of sorts to knock over any cones we are disappointed to find still upright. We spaced it out so that cones would tip pretty perfectly into the rollers. However, when moving at high speeds, the cones fall slow enough that the base would end up behind the rollers. Oops.
• It intakes cubes too, we just didn’t get any video today
• In our testing we found that it intakes cones that are off angle by about +/- 20 degrees, although it may be higher than that.
• Pros: Can be full robot width, deals with both game pieces, keeps the cone to the front of the mechanism to give us more space before the extension limit, deals with tipped cones, fairly forgiving for driver orientation
• Cons: Needs actuation to pivot, rather large extending even farther outside the frame perimeter, can only deal with tipped cones
• Mechanical learned that we can inflate as many cubes as we want at a time by hooking them up to an FRC standard compressor (photo)
  • Could be useful for others with too many cones and puny hand pumps like we have.
• Frame perimeter has been defined at 28” x 28” (drivers rejoice) and all Maxtube has arrived, so we can finally begin cutting and assembling drivetrains! Yay!

Cone-picker-upper

CAD

• Everything is finished in CAD except the manipulator, which we will continue to iterate, and the pulleys for our dyneema winch, though the routing for that has been planned.
• This means the reinforced elevator, winch superstructure, dead axle pivot setup, encoder setup, and dyneema path planning have all been completed.
  [/details]

Reinforced Elevator

Since we will be extending our elevator outside of our frame perimeter, we have made some modifications to help it take potential impacts:

• Diagonal carriage crossmember:

• Adds strength to long carriage
• Polycarb support plate
  
  • Helps to support the static base stage of the elevator
  • Convenient mounting for hardstop blocks (the black blocks at the top)
  • Flat hardstop against our frame
  • Vanity plate to display our team number
• Aluminum crosstube spacers
  • Probably overkill, but a milled piece of aluminum here (hopefully) helps to eliminate a potential failure point when we get hit

Dead Axle Pivot Setup

• Dead axle pivot on ¾” OD ⅝” ID aluminum round tubing and ⅞” OD ¾” ID bushing
• Keeping mounting plates as close together as possible helps with rigidity

Encoder Setup

• Rev through bore encoder mounts directly to pivot plate
• 3D printed hub connects to the elevator with 2 10-32 bolts and has a hex bore to house a rounded hex shaft
• Retained by hex shaft collar on one side and bolt and washer on the other
• Setup minimizes backlash and possible problems, no need for tensioning

Dyneema Setup

• Path shown in screenshot
  • Idler pulley mounts at the back of our robot to keep the dyneema out of the way of the elevator, since MK4i modules force our superstructure to be further forward than we would otherwise like

• Manipulator development has slowed down somewhat, but we are currently working on some intakes loosely based on the one from the everybot with the same wheel spacing but rearranged wheel placement for better ground pickup. We are also seeing if we can conveniently integrate tipped cone pickup into these or similar designs. While not strictly necessary, we think tipped cone pickup could be very helpful.

Electrical

• Fortunately, the design of an elevator is not very intensive on the quantity of motors, with the majority coming from our drive train. Having four of those motors be falcons, we are probably looking at one of the smallest electrical boards we have had in a while, which is ironic given how much room we have in the belly-pan.
• A problem we encountered with our Bunnybots robot was the wiring of motors to the top of an elevator. The result was a pretty sketch energy chain that miraculously never got snagged on another robot. With that not really being an option for this competition, we are going to have to change our approach to routing cables and pneumatic tubing up the lift.
  • This may involve an entire passive mechanism to guide something similar to the energy chain to avoid it bowing outwards too much, or copious amounts of zip-ties to ensure that there aren’t any wires going anywhere we don’t want them
• Can-coders have been a recent area of problem we discovered. Following the Bunnybots competition where the bot performed as expected, some of the cancoders were inconsistently gaining and losing connection. After some quick research, they obviously required 6-16V which happened to be a little more than the 5V the Roborio can provide. Somehow we made it through a competition without any major problems, but this is also something we are going to have to change on this new robot.
  • Rather than using all 4 of the 12V ports of the VRM, our three options remain to either install a second VRM, use something like a breakout PCB to make a custom circuit to provide power to all of them, or splice the 4 together and plug them into an unused port on the PDH. Simply adding a second VRM seems like the most logistical solution, though we are hesitant to rule out these other workarounds that other teams have claimed to find success in.
• Again, while electrically, most of this robot is going to look pretty similar to our previous bot, we are going to try to continue to improve where we are able to. This means looking into a new shipment of batteries, we have had notoriously low voltage batteries under load in the past, and streamlining the electrical board to allow for easier access to ports that we might need to be able to get to quickly in a competitive environment.

[gokalparas]

@catbert

Static Roller Claw

Would you mind sharing any compression or dimension? It looks great.

[george.murchison]

here’s a picture I took to have for quick reference. I can get a more detailed screenshot later though. The geometry could definitely use some improving, mostly the front two wheels were too close to be great at cubes. It probably could’ve had a better grip on cones as well with modified geometry. I suspect the back rollers weren’t really necessary and it could’ve just had a wall there to reduce size and weight

[Britt]

have some interesting manipulator designs . hopefully we get to see more

[Felix_Halaska]

We have many more testing videos in our google photos album, linked HERE. It will also be updated with even more over the course of the season!

[catbert]

Week 3 Update

Mechanical

• We actually started building a robot this week, which was nice.
  • Nut and bolt shortages (and lack of foresight) have caused significant slowdowns on the elevator construction
• Investing in Heavy Grid Maxtube is a good thing. It was not available when we wanted to purchase, and our self-drilled holes for mounting the superstructure and elevator pivot were slightly misaligned. This led to the attachment of our superstructure to our frame taking two meetings instead of twenty minutes.
• The elevator is coming along. We’re using light grid maxtube for our elevator, and it’s working alright- that stuff is practically paper, though, so I’m interested to see how well it’ll hold up against our ‘testing’ (drive team practice)
• Belly pan cut out and finished by electrical
• All our stock for making the pivot has arrived, and so we can now start assembling it.
• Generally, a very productive week. Maxtube is great. It’s allowed us to actually just assemble things instead of drilling and dremeling out all of our holes. Yes, dremeling. Because they’re never on-center.

New cleaning policy!

• Leads randomly yells at everyone to drop what they’re doing and clean if the foundry gets too messy (except lead)
• At the end of every meeting, we clean. If we ‘forget’, it’s at the beginning of the next meeting.
  • If this happens too many times, we up the ante and make everyone put everything away. No, we don’t care if you’ll use it tomorrow. Yes, we want you to put away your 23 allen wrenches.
• We’re trying to keep our workspace cleaner and more organized, because in the past it’s become a mess by week 2. In the past we’ve cleaned once every couple weeks when we become physically unable to work in the space, and I’m just not down with that. It’s inefficient. So now we clean every day for 5-10 minutes and if it gets too bad we clean longer.

CAD

• Not much has changed since our last update as far as full robot CAD, but we have finished the dyneema/winch pathing for the elevator pivot and have added plates that support the elevator horizontally in its down position.

• We also worked on some new manipulator iterations, inspired by the Everybot intake and by 3847’s intake on their alpha bot.

• The Everybot-inspired option seems more promising for now, but the ability to pick up tipped cones seems nice to us and we will continue to explore the idea.

Electrical

• Most of the week was spent planning, designing and building the electrical board for the practice bot.

  • With the more open robot design that we’re currently following, electrical is left with an impressive amount of space in the belly pan to work with and very appreciated easy access to it from the top. However, with this openness comes the demand for some sort of shield to protect the precious components of the electrical board… we’ll have to work with mechanical and CAD to whip something up.
  • The manipulator we have currently chosen to pursue doesn’t require pneumatics which frees up even more space on the belly pan! Unfortunately it also means that we won’t get to experiment with our adorable new pneumatic hub…

• Other than that we keep ourselves entertained by playing around with LED strips and maintaining our status as cleanest workspace in the foundry.

• Looking forward to next week when things will (hopefully) start lighting up and moving around!

Software

• We started writing the robot code this week
• Currently we plan on controlling the elevator angle with a PID and Feedforward
• We also plan on controlling the elevator height with just a PID in Bunnybots putting the motor in braking motor and having a PID was enough to control the elevator
• We are also testing apriltag vision, currently it is just Photonvision on a PI 4 with a pose estimator

Design Notes and Thoughts

• After seeing that 1339 Angelbotics was moving away from a pivoting elevator we took a hard look at our plans. They had several concerns with the design, namely:
  • Center of gravity: The COG has to be pretty high when driving across the field because your elevator either has to be vertical, or outside of your frame perimeter. With full-field cycles under defense, both velocity and acceleration will be important to be able to execute without tipping.
  • Impact Resistance: The elevator is working as a long lever arm, and when it gets hit at the very end of that arm, the forces on the pivot will be quite large. Additionally, your elevator also needs to be able to withstand this impact without catastrophically failing.
  • Using gravity to pivot the elevator
  • Exposed string rigging
• After this review, we’re pretty sure that we can mitigate most of the concerns they had to a degree where it isn’t worth it to return to design. We’re working on several ideas to minimize damage done to our elevator when it is hit outside the frame perimeter.
  • We’re adding “capture plates” at the front of the drivetrain that will decrease the length of the lever arm, and isolate the pivot point from the majority of the force. These will be nice wide aluminum plates covered in pool noodle foam to absorb some of the force, and distribute the rest over a large area.
  • Since the elevator pivots freely upward, we can use that to our advantage to try to dissipate some of the impact energy. To try to do this, we’re going to add angled polycarbonate plates on the sides of the elevator at bumperish height. That way, when another robot contacts the elevator, the force will push the elevator up, lessening the sideways force the elevator will have to withstand.
• We decided on a manipulator to initially pursue, but we will continue to develop other ideas in the background. Unfortunately, our first iteration of this manipulator won’t be able to pick up tipped cones, but we need to get something manufactured and mounted to the robot so we can start drive practices.
• At Bunnybots we were driving relatively slowly. This was due to both a lack of software time where we could tune the controls, and also the gear ratio we bought. We have SDS L1 gear ratios, which have a top freespeed of about 13 ft/sec, or an actual top speed of about 11.5 ft/sec. That’s not too fast, and speed will matter a lot in this game. There is the option of upgrading to SDS L2 to get another 2.5ish ft/sec, but that requires money, build time, and re-tuning time. We’re still very much undecided on what to do about this.

As always, these posts are about what other teams can take from them, so if you have any questions, or want to see additional videos, photos, etc, please ask away!

[catbert]

Week 4 Post

The Week In Review:

One of our team goals for the season was to have our practice/alpha robot mechanically and electrically done by the end of week 4. We’re happy to say that we met our goal!! Yesterday we finished up attaching the manipulator and wiring (almost) everything. This is a good step in faster iteration for us! Last year at this point we hadn’t even gotten our cargo handling system fully installed on our drivetrain. This year we have a mechanically complete, and relatively complex robot ready for testing.

Another one of our goals was increased iteration. We’re also executing on this by way of continuous iteration on our intake. Even yesterday, as we finished up the robot, we also designed two new intake geometries. We fabricated and tested one of them, and prepped the other one for manufacturing today.

We fixed a software/firmware issue with our BunnyBots robot (now swerve and vision tested) so a few prospective drivers were able to try out the newly tuned swerve drive!

We hope to start giving drivers practice on a robot that is at least close to what we’ll take to competition, as well as give software time to work on vision and autos. We also want to do more rigorous testing of the fully completed mechanism, since we haven’t been able to do that yet. Many of the concerns we have with our robot architecture (center of gravity, elevator robustness) haven’t been fully addressed yet, but we hope to do that this week, so we have time to refine a little bit before our week 0 (-1?) scrimmage on February 19 hosted by Team 997.

CAD:

This week’s big focus was intakes. We wanted to first complete an intake we could put onto our practice robot so we could then put our full effort into optimizing our geometries, especially for tipped cones.

This is the intake we put onto our practice robot:

It’s much heavier than we’d like, but because the main goal was to get something working for now on the practice robot, we decided to build it without optimizing for weight for now. We also realized that we had made a mistake and this geometry can’t properly intake cones from the double substation, though a quick redesign in geometry and test confirmed a new geometry that will work just fine. For now, though, we are holding off on building that geometry as we test a variety of intakes capable of intaking tipped cones off of the ground. We believe this can be valuable for quicker cycles that have less of a concern with the congestion that will likely occur at the double substation. We were very impressed with what we saw from 111 Wildstang’s intake in terms of tipped cones, as it seems to work well with our robot architecture. We tested a slightly modified version of that geometry that can function on a fixed angle with our pivoting elevator. Going forward, we will experiment with different geometries that can hopefully intake tipped cones with less help from the robot driving forwards.

Mechanical:

This week we mechanically finished our practice robot! The name of the game for most of the week was getting the elevator fully assembled and mounted to the frame. The mounting process seemed daunting, but it took less than an hour, making us feel a little better about when we will need to do repairs in the pits. The intake assembly also didn’t take a very long time, with assembly starting on Friday evening and being mounted Saturday afternoon. Our intake and elevator pivot rely on a dead axle, which we had never done before, but installing the tube nuts was much easier than expected. We have also been working on hard stops and deciding on sensors for the elevator positions and how to mount them well.

• We also…
  • Made a springy net to cover our electrical board and prevent game pieces from getting stuck in it
    • After some unfortunate experiences at Bunnybots that required our robot to spin to try and dislodge game pieces, we’re trying to keep that from happening again
  • Helped mount and route the energy chain
    • With an elevator that tilts there are very few distances that stay constant. Additionally, because there is no carriage, and the manipulator stays at the top of the elevator, traditional energy chain routing becomes difficult because it can’t extend above the motor mounting area
  • We’re slowly building a system (accidentally) to give our tilty tilty elevator some more resistance. This is in the form of our rope tensioner/ slack take up and our net.
  • Built bumpers! So much bumper building
    • We’re building two piece bumpers for the first time for a competition robot!
    • Since this is our first year in several years doing a custom drivetrain, we’re having to pocket our bumpers slightly to allow them to sit snugly around the gussets mounting our superstructure
• We learned that the mechanical lead likes sitting and playing with knots because like he’s a little gremlin boy

Electrical:

After a few long weeks electrical was finally in full swing, having relatively unmitigated access to the robot for components and wirings. After seeing some of the mechanical systems physically in place on the robot we had to move some sparks and wire routings, but just about everything is tidied up now. The energy chain for how we plan on getting wires to and from the top of the elevator was a problem we knew we were going to have for a while, yet neglected to take really any action given the lack of a tangible prototyping structure. Since mechanical mounted the elevator, we were able to try a few different designs before finding one that worked quite well for protecting and guiding the wires to the NEO on the manipulator. With the entire CAN routed as well as the number of miscellaneous wires on the rise thanks to the first through-bore encoder mounting, the sisyphean task of routing wires around the electrical board has officially begun. Aside from the motors, most of the electrical work was finished in the previous days so all that remains is to patch up any bugs we encounter along the way, and iterate on the energy chain, which technically is finished, but I would like to see a more clean solution by the time it comes to build our competition bot.

Software:

In Software we flashed the motors on the practice bot and finished coding the elevator and claw. We also learned that if there is a strange issue, we should get video evidence of it. Turns out when some people look at things, the problem is mysteriously fixed until they leave. We found that if we don’t assign a different id to each Spark, it makes the LED’s create interesting patterns. (Purple and intermittent yellow blinking is not a pattern that should happen.) It turns out that the REV Hardware client wasn’t saving the id’s of the sparks after they were updated, so after much trial and error, we used the REV Spark Max Client to save the id’s for the Sparks. The cancoders also decided to have id issues, but that was fixed relatively easier after updating the RoboRio and clicking around a bit. We never did figure out the exact cause of the yellow flashing from the Sparks, but it’s gone now.

[catbert]

Week 5: It Lives!!

Overview:

This week was about getting the robot moving and scoring, something it finally did today. It’s all still a little rough, but it’s getting there. We were hoping to get started building our competition robot, which I’m sure will be touched on later in the post, but until we do more testing of our practice robot to make sure we are happy with the architecture we’ve chosen. With scrimmage next Sunday we’ve got to make sure we’re ready to go and get some good testing in!

CAD

CAD did a ton of intake designing and testing this week on our Wildstang-inspired claw. After lots of work and a vote, we’ve decided to move forward with it for our competition robot.

Our initial testing showed that because we don’t use a wrist, our pickup angle makes a two-belt design less than ideal, especially for tipped cones. To fix this, we added an extra roller with two-inch compliant wheels at the bottom, which we were able to do because we don’t need to intake from both sides of our robot like wildstang does. We also added a hardstop for the tip of the cone so we don’t take in the flange, making the near horizontal outtake angle much more consistent. Final CAD is still being worked on, but below are some videos of our final iteration doing its thing:

(old iteration but cube intake geometry wasn’t changed)

Mechanical:

Mechanical didn’t really do a lot this week. Generally, we spent the week fixing assorted issues that popped up with testing, detailed below:

• We changed the ratios on our neos that extend the elevator from 25:1 to 20:1 (possibly 15:1, we weren’t entirely sure if we used 3:1 modules or 4:1 modules). The extension had too much torque, as evidenced by the crushing of our headstops with ease. We didn’t need that much torque on our elevator, and we wanted to have some more speed.

• We re-routed the energy chain to better support itself, and to prevent it from dropping into our elevator’s pinchy bits. It will need additional refinement as it still occasionally gets caught in the elevator

• We dismantled and re-mounted our net (see last week’s update) to prevent it from interfering with our hard stops. However, the tension of the net was high enough that it made it slightly annoying for the software team to work with, so it’s currently off, to be replaced later if software can work around it, or we can use a non-tensioned web.

• We made bumpers! The bumper crew is doing a great job with the fabrication of what is probably the hardest bumper design we’ve made- this is the first time we’ve had protrusions outside our frame perimeter, and we’re a bolt team, making it even harder to execute. We’ll be riveting ¼” polycarb onto our frame to expand it and let the bumpers fit firmly against the frame. We’re using clamshell, a two piece bumper construction to make switching even easier between matches. To secure the bumpers we’re using McMaster pins vertically through brackets and into the frame tubes. In addition, we’ll also have brackets mounted to the frame which a bolt through the bumper sits between and has a horizontal pin keeping it in place vertically. This is the least bad solution we’ve used in the past (i.e. not having our bumpers fall off, or having to dremel on the bumpers to get them to fit between every match), but we may also be experimenting with wingnuts or something similar. Weird design, great job bumper crew.

• We took apart our bunnybots robot (Moose), stripped it down to a drivetrain, and mounted 80lbs (~39kg) of weights on it so we could more accurately test auto-balancing on the charge station. By unanimous vote, Moose was renamed Mo in a nod to its reduced stature. (PICTURE)

What did we learn?

• Our “carefully crafted” schedule went out the window. This was due to the fact that we can’t build a comp bot until we know what the problems with the practice bot are- so we have to test some before we start building. This leaves mechanical with some unfortunate gap time where we’re kind of just fixing general issues that come up with the practice bot and sitting on our hands, waiting for the order to come down to start construction.
  • This may also be due to the fact that the mechanical lead did not spend much time on the Gantt chart and it wasn’t thoroughly planned out
• We’re coming up on Scrimmage (seven days at time of writing (this will be abbreviated to ATW for further use)), and that leaves us with pretty much zero time to build a competition bot. For anyone out there reading- plan better. Seriously, either build your subsystems independently so you can test them independently or make a practice bot before week 4. It’s worth the time so you can iterate on everything and test everything before you make a comp bot.

Electrical

We replaced our up/down limit switches on our elevator with reed switches- we decided that the limit switches were too hard to place accurately and would bend over time, leading to reduced accuracy. We then realized that the reed switch placement we had come up with required too much precision, and decided to just rely on using the through-bore encoder as an absolute encoder for the position control. We may add a sensor at the top to account for angular drift over the course of the match, we’ll see.

The Neo we’re using to control angle was getting relatively warm (~50 C) which is concerning because we’d like to keep our elevator inside the frame perimeter while traveling, which currently requires stalling the motor. We’re probably going to up the gear ratio to give it more torque to try and solve the issue.

Software:

Software got the robot this week and all the motor controllers were flashed early this week. We also tested an old robot on the charge station, but didn’t get farther than basically a pid loop that only works at slow speeds.

For the intake we have 3 buttons: one to intake cubes, one to intake cones and one to outtake. We haven’t decided on the button mapping for the elevator, and the swerve is one joystick to move and one to rotate. Currently we have a pid loop on the elevator extension and one on the tilting; however, we plan on changing them to trapezoidal motion profiles. The feedforward on the tilting will likely need the Kg multiplied by the extension or something. The claw just runs at a percent with a current limit to intake.

The only serious problem besides tuning was using a through bore encoder as an absolute encoder. The DutyCycleEncoder class didn’t seem to work in the way we wanted so we had to add this piece of code to properly zero without making it flip to +2pi radians when going below the zero (instead going negative).

(angle - flipOffset).mod(2 * PI) + flipOffset - offset

This code should cause the output to flip (go from x to x + 2 * pi) at flipOffset and then zero the angle by offset (so it can be negative).

A Summary of Strategy Thoughts:

• Single Substation
  • Seeing team 8177 Vector’s extensive single substation cone drop testing, it gives us confidence that dropping a cone down the single substation will be consistent enough to have as a main plan and save time over extending to intake from the double substation. This gave us the confidence to decide on an intake that does not intake from the double substation particularly well.
• Cycle Coordination
  • After looking at the field once we got our charge station built it’s clear that coordinating cycles with your alliance partners is important. There’s very little room to maneuver or pass your partners behind the station.

Some videos from this week

Robot depositing cone on pole

Cone Pickup

Charge Station Testing

[catbert]

Week 6 Recap:

This week we made good progress on testing and tuning the robot code. It’s now able to score game pieces on every level, and pick up game pieces from the floor. Both DOF on our arm now move in a smooth and elegant way, due to a lot of software tuning, giving us fewer heart attacks during testing. We’ve been working on our competition/beta bot as well as a second robot-worthy iteration of our manipulator. We had a little bit of drive practice this week, but Scrimmage will be a good learning opportunity.

Pre-Scrimmage Overview

This Sunday we’re going to Scrimmage, a week -1 event that team 997 is putting on at Corvallis High School. We’re hoping to get some good full-field testing and give our drive team a chance to practice coordinating with other robots. It also gives a good deadline to have a robot in a finished-ish state so we can collect good data.

CAD

As the season progresses, things are getting quieter and quieter for CAD. Our main task this week was to completely CAD our intake so we could get it working on the robot before scrimmage.

It’s a little heavier than we’d like, but we were somewhat limited by shipping times (because we wanted to get it ready before scrimmage), and the design is also just heavy because it has 5 different hex shafts.

Here’s how the full robot CAD looks with the new manipulator:

After putting the manipulator on the robot, we weren’t super happy with the performance on intaking standing cones. It was hard to test accurately in our prototypes and turned out to be relatively inconsistent, though there’s still some work to be done on the exact set position we use, which will hopefully improve performance. Because of this, we will likely continue to develop the intake geometry and hopefully have a refined version before week 1 at Clackamas.

We also added “capture plates” attached to our drivetrain which support the elevator through hard foam (not in the CAD) which should hopefully improve rigidity when we get hit with our elevator in its intake position.

L channel brackets support the plates on either side, which should (hopefully) keep it from bending. There is also a hole in the center for wire routing.

Mechanical

Mechanical did a lot of stuff this week. We:

1. Cut all the pieces for our backup elevator. We’re planning to take a full replacement elevator to competition to swap out in case it breaks. On this revised elevator we’ve made some small changes. The base stage is now made out of entirely heavy grid MaxTube, and each stage is a few inches shorter. Those changes will hopefully make the elevator more rigid, and keep less of it outside of our frame/bumper perimeter while intaking from the floor. There’s a chance we may make a full competition robot before Clackams, but we may instead make small changes to our practice bot to make it competition worthy instead. We’ll see what time allows, and what information we gain after scrimmage. (ie: what breaks)
2. Changed out our hard stops on the elevator to make it not try to phase through the ground. However, with our new intake, it still hard stops on the ground. There seems to be a discrepancy between CAD and real life that makes it not work. We’ll be re-CNCing hard stop plates soon to make that work.
3. Removed the net. Although we loved that it could launch cubes 10 feet (2014 strategy anyone?), the pull down restoring force was wreaking enough havoc with the positional control that we’ve removed it for now. We’ll probably replace it with a non-tensioned net eventually, but we’re slightly worried about it getting caught in our swerve modules.
4. Changed the upper hard stop on our elevator to allow for the new intake geometry to be legal. Our new intake is larger, meaning that our previous hard stop left the intake outside of our frame perimeter. We’ll just hard stop against our superstructure instead.
5. Switched our intake to a geometry better able to deal with all game pieces and orientations. As CAD talked about, there are still some issues to be ironed out, but it picks up tipped cones wonderfully.
6. Cut pieces for and fabricated our capture plates for the elevator. The purpose of these is to provide a little extra stability in a crash. These plates have been in the works for a while (I think this is the third iteration), but they finally made it onto the robot. They serve to essentially shorten the lever arm that is elevator in the intake position, and hopefully dissipate force, isolating our pivot point, in the event of heavy contact on our elevator while intaking.
7. Our energy chain continues to be a time sink. We’ve spent hours fixing it, yet it continues to be problematic. The links break apart, and get caught on the elevator. We’ve ordered some WCP energy chain, which should be better, but if anyone has enlightening suggestions, we’d love to hear them!
8. Finished our first set of bumpers and started our second! Good job bumper crew!

What we’re hoping to learn at scrimmage:

• Energy chain: Where/how does it catch
• Elevator capture plates: How can they be improved?
• Intake: General troubleshooting/how durable is it?
• Elevator: How can we alter the bearing captures to be more slidey? What breaks?

Electrical

Not much changed in electrical land this week.

• The power adapter for the Beelink we plan on using on our competition robot was finished. This involved:
  • Creating power cables running to the PDH
  • Splicing them to 2 current steppers
  • Running the two parallel converters through diodes before converging back to the main pc power cable
• This will allow us to run more rigorous vision cameras for our competition bot, but for now we will stick with the low-power Raspberry Pi. The cameras we only need for driver awareness as there are still some things we want to test with the new power cable
• Played around with some new led configurations
  • Different PCM outputs for each RGB value??? Didn’t think that would actually work but certainly opens up some possibilities
• Rerouted some wires so the elevator wasn’t hardstopping on insulation
  • (Yes there were some exposed wires after repeated stress)
• Fiddled with the energy chain a little
  • Still not perfect, definitely looking for a more permanent solution by comp season

All in all, the robot was ready for competition a little bit ago, and recently we’ve been mostly planning how to improve upon the practice bot in order to streamline our competition bot. Most of our information will come from scrimmage, so we are eagerly looking forward to this as a way to further our current designs!

Strategy Stuff:

• Week 0 observations:
  • Very high scoring matches for pre-season competitions, especially with a defined scoring ceiling
    • To be fair a lot of penalty points were present in those matches
  • The absolute crush in the center right after auto
    • That will be dangerous for our elevator/manipulator if we are to enter the fray
    • However, there did seem to be a lot of leftover tipped cones, which will benefit hugely since those work well with our current intake
  • Being able to utilize pieces in the center will be crucial to reducing cycle times, especially in early week events
  • Triple balances seem “easy”
    • Easy may not be quite the right word, but they seem very doable, making the RP associated with them crucial to obtain every time
  • The grids will be full at district competitions
    • This will make defense critical
  • Double elimination brackets are awesome

Photos and Videos

Scoring some cones and cubes

Picking up cones and cubes with our new claw.

Claw Demonstration

Demonstration of our elevator arm.

Elevator Demo

[catbert]

Week 7 Update

Last Sunday we went to a scrimmage hosted by team 997 at Corvallis HS. It was a great event, and we all had a really good time! Other than some energy chain shenanigans, it went really well. We learned some things we have to do before Clackamas (our next event, in 4 days), detailed below. As well, we got some really valuable driver practice and some good experience for our drive team. Hopefully we’ll be getting some more of that in the coming weeks.

CAD

This week has been slower than previous ones for CAD, since the robot is pretty much done. Following scrimmage, there were a couple of things that needed to be changed in the CAD to address durability issues with our winch system, with a support plate for our winch gearbox and a beefed up top pulley plate, both pictured below:

Another major thing we did work on was improving the energy chain setup and cable management for our elevator. The solution we have now is pretty simple, but a much needed improvement. It now uses west coast products energy chain instead of the flimsy stuff we had before. The system uses one ‘fixed’ section of energy chain to route wires up to the top of the base stage of our elevator, and a second ‘moving’ section of the energy chain that fixes to the top of the base stage on one end and the top of the second stage (on the manipulator) on the other end, with a large loop of chain below to allow for our elevator’s ~40in of extension.

Mechanical

Mechanical has had a bit of a hectic week. We reinstalled the energy chain (replaced with WCP 45mm chain this time), re-routed all of the string for the elevator, managed to shatter a whole intake plate, FINALLY finished our bumpers, and started on our spare elevator. More details below.

Energy Chain

• This thing has been a nuisance since week 1. Essentially, our previous routing was too weak, and when it got caught in our elevator (frequently) it would either rip out some of the wires in it or explode.
  • It exploded at Scrimmage. Literally we are still picking bits of it out of the PDH.
• New energy chain! This stuff is great. The built-in mounting points are wonderful, CAD CNC’ed us a new place to mount it and a plate, and now it doesn’t catch on anything much. We do still need to add a fillet on one piece of the elevator, but that’s a minor fix.
  • (Knocks on wood)

Elevator string

• How we had our string for our winch-up system for the elevator’s angle would have gotten it caught in the way of the energy chain. We decided to remove the attachment point on the elevator, moved it literally half an inch, and it worked.
• We also reinstalled the dyneema we’ve been using, as it was getting frayed, and had the lathe gremlin smooth all of the pulley faces and edges down.
• This led to an interesting problem where the gearbox we’ve been using to move the pulley started to break. We think we figured it out, and will be doing more testing soon, so more on that next week.

Bumpers

• We finally finished our bumpers! This involved reimagining our bumper mounting system, drilling out the holes in our second set of bumpers, and attaching our pool noodles and fabric.
• The old system was 80-20 L brackets, four of them per bumper. This was… okay, but wasn’t necessarily FRC-legal, as we used vertical pins to hold them in place.
• We replaced this with 1” pieces of C-channel in the same places, so we could put vertical fixed bolts on our frame and bolt the bumpers on, thereby providing a secure vertical and lateral connection.

Spare Elevator

• This is just a simpler elevator, redesigned by CAD to have smaller stage overlap and to stick out of our bumpers less, thus reducing the chance of collisions.
• It’s essentially the same process as the previous elevator-building, except for the fact that all of the long bits are shorter and we’re doing it faster this time.

Electrical

Besides the energy chain breaking every other match, there were few to no electrical issues experienced at the scrimmage. The energy chain supports were too flimsy and didn’t offer the proper support or structure to the wires within it. This led to wire joints being loosened or even unplugged and possibly damaging them as well. Thankfully the new west coast products energy chain seems to be holding up much better!

Other than that we made some minor fixes on the robot. We swapped the 20 amp breakers for 10 amp ones on the PDH for our VRM– something we’ve wanted to do for a bit but couldn’t because of shipping issues. (Thankfully we didn’t suffer any of the consequences of what could’ve happened.) We also moved about half of our spark motor controllers out from under our elevator hinge onto a side panel for easier access and wire safety. Finally, we just did some general wire management and readjusting of components to get comp ready!

Software

We worked on a couple of things this week, including working on the auto, feed forward, collision safety, tuning, and balancing on the charge station.

Autos so far: the most advanced auto we have drops off a cone, picks up a cube and balances on the charge station. There haven’t been many interesting problems with the auto and pathplanner is working well. The main annoyance is we don’t have a full field.

We also added feed forwards to the arm control systems. They are just single numbers and the angling one is multiplied by the cosine of the angle and the linear one multiplied by the sine of the angle.

We also spent a lot of time working out the math for polar lines and stuff to prevent the elevator from colliding with the drop off zone. It is quite complicated, but essentially you can use r=\frac{a}{cos(θ +b)} and find a and b from the point slope form of a line. a is the closest approach to the origin and b in the angle.

For the charge station we found that we can have the robot drive a set amount of time and it will work pretty well. When it isn’t balanced from that we basically have it drive up the slope according to the gyro until it starts tipping again. You can find the direction of the tip of your robot by normalizing the vector made by the arctangent of your pitch and roll, and the magnitude of that vector is your tilt.

[catbert]

Post Clackams Update!

Finalists again! After a hard fought competition we came out as the finalists, with our fabulous alliance partners 7034 2B Determined and 4061 Sciborgs. Congratulations to the winning alliance of 3218 Panther Robotics, 1540 The Flaming Chickens, and 5920 Vikotics! We also won the Autonomous award thanks to the awesome work of our software team.

There were many positives to take away from this weekend. We walked away with 58 district points. We went to the finals in an FRC event for the first time since 2014, and the second time ever. We saw many promising signs from our robot including quick cycles, ease of intaking tipped cones, and a robot that can take the occasional hit. This competition was exciting, exhausting, and a ton of fun.

However, there are definitely things we need to work on. We could only run our autos on the non-cable protector side of the Community, and we had trouble intaking when under heavy defense.

Mechanical learned some good stuff

• Loctite cracks polycarb. I mean, we knew that, but we didn’t KNOW it until our intake almost broke in, like, five places. (Though it’s great when a team needed to dissolve some polycarb and there weren’t any normal solutions)
• Ploycarb isn’t infinitely impact resistant. Again, we knew it, but we didn’t KNOW. Again, our intake almost broke in roughly five places.
• Poly belting is incredibly amazing, and can be bonded by scotch weld (at least for patching up peeling welds). That’s nice. Really nice.
• Our elevator is nice. Good job CAD, that’s a great design. It survived getting knocked into many, many times with nary a dent. (The ‘how’ is less clear. I theorize that CAD has special daemons they send into the superstructures, but nobody is willing to confirm nor deny this)
• Swerve tread needs to be replaced at least once per comp, and that is not an easy task, nor one for those with shaky hands. It’s difficult to do, but definitely worth it.

Electrical learned many equally important lessons

• There are conflicting sources of information about specifically where to wire your VRM from, but inspectors rule that it is from the low current ports.
• Leaving Andersons to themselves for long enough will result in them taking a blow to unplug them, retention clips will certainly be used in the future.
• Zip tying battery connections is an excellent safety measure and good for peace of mind (shout out to 7034 2B Determined for the suggestion!)
• We did not account for nearly all the brute force we likely should have
  • The LED strips got crunched a few times, protecting them a little more would be good.
  • Radio nearly slipped out from its mount (Probably partially due to when it was removed to get flashed and we didn’t want to cut zip ties)
• A polycarb panel to cover the electrical board was installed at one point, but since wirings have moved around that no longer fit so we decided to go without it.
  • We have learned that we may in fact need that and we will be resizing one to fit.
• We were also having some mysterious Raspberry Pi issues, however we may just end up going with the beelink to run more computational intensive vision code.
• Finally, we thought that we had fried a spark, but somehow it ended up just being a tripped breaker. After spooling our elevator winch the wrong way, the NEO got way too hot so we replaced it. In the following match the elevator still wasn’t working, however the NEO felt cool, and upon further inspection we realized the spark was unresponsive. We have had some mysterious Spark/NEO failures in the past but this wasn’t very reminiscent of that. We replaced the Spark and got the robot working. In the pits later, after plugging the Spark into a laptop, it appeared to be functioning fine. We are still not entirely sure what caused this, but other than that electrical had a relatively successful competition. We are looking forward to maybe trying some more advanced designs if we wish to incorporate vision or play around with some different swerve module gearings!
• It is in fact possible to reach the thermal limit of a Neo!

Software

Most of the code worked with few changes necessary, and some problems, such as an auto going rogue or the arm over wrapper, turned out not to be software issues. However, some of the software issues that did exist were:

• An auto was not updated to the latest tuning even though it was largely the same, it was a different file and so didn’t get updated in the last minute tuning. To fix this we may create more advanced auto paths from simple paths.
• Another problem was that the cone dropping failed a couple of times in the auto. We have to wait a bit after reaching the setpoint for an unknown reason right now, as the tolerance is pretty low although maybe not low enough.

Example of cone dropping: (Far blue robot)

Qualification 55 - 2023 PNW District Clackamas Academy Event

• Sometimes auto would drop the cube we picked up. We will probably have to have the claw run constantly to fix this.

Cube falling out: (Near red robot)

Final 1 - 2023 PNW District Clackamas Academy Event

• The alignment to stuff took a long time so we could have decreased the deadband or something. We are also considering vision. We bought two beelinks for ~$150 dollars each and some cameras recommended for them so we may use vision with apriltags for alignment.
• Also, we had some problems with arm oscillation. When the arm got caught on something it over-wrapped, meaning it essentially inverted the motor leading to in pressing hard into the top hardstop heating the motor a lot. To fix this and the oscillations we may change the code to double check the absolute encoder on the angle arm with the encoder on the motor.

Some pictures from comp:

Our Pit:

Robot:

Googly eyes!

Triple balance:

[catbert]

Week 9 Update

CAD

Each passing week seems to get quieter for CAD as we progress through competition season—a welcome break after a busy build season.

CAD-wise, our main addition this week was polycarbonate centering flaps heavily inspired by team 3512 Spartatroniks, who kindly shared a variety of videos showcasing how effective theirs were. We made ours very similar, with only minor adjustments to fit our slightly different intake.

These required new intake plates to be cut that had mounting points for the flaps, which was not a problem, as our intake needs replacing anyways after all of the abuse it took at Clackamas. The fresh intake should be going on soon, after some delays with getting stronger pulleys printed with PLA+, more wall layers, and a shorter layer height to prevent the issue of layer separation we had on a couple of our pulleys at Clackamas.

In some of this newfound free time we’ve had at meetings, we’ve been analyzing our own match footage for the ways in which we can best improve. We also watched a lot of week 2 events to understand what is most successful, especially in qualification matches where we found some difficulty at Clackamas. The most major takeaway from this has been that we can get the links RP much more often if we recognize when we can still win a match while scoring a lot of cubes low. Strategy-wise we’ve also spent a fair amount of time pre-scouting for our Salem competition, which is somehow already in less than two weeks.

Mechanical

Mechanical mainly did just housekeeping and small building today. We did a couple big things, including:

• Finishing our spare elevator and making the dyneema runs tensioned and working. On our current elevator, our dyneema run is split into two from the tie-down to the clamp, and vice versa. That led to uneven tension and extra slack in the system. We just kinda threw more tensioners at the problem, which seems to do the job.
• Start work on our new intake with stronger crown pulleys and intake centering flaps. We had issues with our last crowned pulleys splitting along the 3D printed layers, so we’re printing stronger ones. These centering flaps essentially make it so the cones are drawn nose-first into the intake and center themselves to ±15º of center. We’re yet to do much testing, but what we’ve seen from team 3512 Spartatroniks, they look extremely promising. These will be crucial because many of our missed cones at our first competition were because of cones that were misaligned in the intake. It will also make vision alignment possible, because without it there would still be too much manual alignment.
• Replace swerve treads! Our jig was… bad… so we had to make a new one, which put us out probably two feet of swerve tread and several treads we just can’t use. We also stretched our new treads, and eventually they started to work.
• We took apart and put back together all of our spare swerve modules, making sure to clean and grease them.
• We also hope to replace the spooling motor to speed up our arm raising and lowering time. It currently takes about 1.5 seconds which is too long to keep our elevator down unnecessarily in the danger zone. We learned that one the hard way at our week 1 competition.

Electrical

Electrical’s main task this week was to install a Beelink system onto the robot for vision purposes. Before installation however, we first robustified the mini PC as it wasn’t quite up to gameplay turbulence standards. To do this we disassembled it and added extra solder and hot glue at points to strengthen pieces. Furthermore, we added loctite to the inner screws (a very very small amount as it likes to eat plastic). We also made sure to add a thin layer of foam padding on the bottom when installing it into our robot to reduce shock. To power the Beelink, we are using a custom circuit buck-boost converter to run it at 12V. We currently have two cameras attached to it that are mounted on the side support beams of our robot for maximum FOV.

To our delight, the Anderson retention clips arrived this week. We immediately applied them to all of our Anderson connections (along with a strip of gaff tape for good luck). As it turned out we needed a lot of them (60+) so we will soon be getting more.

Electrical was blessed with a lot of robot time this past week which we used to its fullest extent to bombproof the electrical board as well as we could. This process mainly consisted of shifting a few components around (mainly sparks) to make wire paths more efficient and reduce excess wire in the robot. We also labeled our wires into the PDH with their assigned motor numbers to help speed up troubleshooting should things come to that. Finally, and perhaps most importantly, a multitude of zip ties were added to the electrical board. They mainly serve to help secure components (like the radio that almost slipped out during competition) but also to help manage the roiling sea of wires and keep them away from the swerve modules.

Software

This week Software has been working on vision. As the electrical team mentioned we are using a beelink with two Arducams. We get about 13-20 fps running the Arducams at 1200x800 resolutions with the beelink and haven’t had many issues. It is a standard photonvision setup as can be found here. The camera outputs are connected to a SwervePoseEstimator with (1.0, 1.0, 0.01) for the non-vision trust and (1.0, 1.0, 100.0) for the vision trust numbers. These are mostly random. For the actual controls of the vision we have it setup so there are two buttons one that aligns to the nearest cone tower using the vision system and one that aligns to the single substation. We have it setup so that the vision controls the rotation for the robot and the side to side movement relative to the target while the driver can still drive forward. It just uses two basic PID loops. It just works fairly well without too much precision put in. One problem is our intake is wide so cones are not necessarily centered, so the mechanical team is looking at fixing that. Right now the gunner controller has a slider that tells the robot what percentage of the intake the cone is in. Overall vision has been harder than I expected, especially red blue swapping to work with pathplanner and just the precise measurements, but it is working fairly well.

Coach’s Notes

Hi! I’m Felix, our drive coach for this year. This is my first season as drive coach, and so far it’s been quite a fun experience. One of the things I’ve learned is how little is visible from the driver station. I’m quite tall, and that has some pluses and minuses. The team number displays block my line on sight to the display screen, and the opponent driver station. That means if I want to check something on the screen, I have to make a physical effort. The other thing I’ve found is how hard it is to see the hybrid nodes. Like I said, I’m pretty tall (about 6’ 5”) and I can barely see into them. This causes problems for my coaching. As we’ve learned more about how to play the game this year, it’s become quite apparent that hybrid nodes are crucial to getting the link RP, and by extension ranking high. If I’m having that much trouble seeing scored pieces, it must be significantly worse for people who aren’t as tall. I’m happy for the improved cross-field visibility over past years, but this is still pretty bad.

Watching our match footage is not a comfortable experience, seeing the potential links I didn’t notice, and most of those were low links. I now know I have to make a conscious effort to look for those potential links across the entire hybrid grid, and that they matter much more than I thought they did. Watching more matches and hearing from our strategy team will improve my coaching for our future events now that I know better how to play the game most efficiently, and how to react in matches to maximize our abilities.

I think that’s all for now!

[feverittm]

As a replacement for the retention clips we have used small cable ties between the holes (exactly where the retention clip mounts).