FRC 4322 2023 Build Thread

FIRST FRC Open Alliance
,
1

Welcome to Team 4322 Open Alliance build thread for 2023! This is our first year of posting on openalliance, and we are excited to join the community and embrace the vision of Open Alliance.

Overview

Clockwork Oranges-All photos-50733098698
Clockwork Oranges-All photos-507330986981280Ă—853 266 KB

FRC Team 4322 is a student-led community team based in Orange, CA. We are part of BSA Venturing Crew 1701, and are chartered by the Orange Public Library Foundation. We currently have 22 students spanning 3 school districts and 7 schools.

Open Alliance Posting Schedule
We plan on posting weekly updates to Chief Delphi(with lots of pictures). We will summarize what we did during the week and will make sure to include what worked and didn’t work as per the Open Alliance ethos.

Links
2023 CAD: OnShape
2023 Code: [Coming soon]
Website: https://frc4322.com/
Instagram: https://www.instagram.com/frc4322/
Twitter: https://twitter.com/frc4322
Facebook: FRC Team 4322 - Clockwork - Crew 1701
YouTube: https://www.youtube.com/@4322Robotics

11 Likes
3

This should be fixed

1 Like
4

Here’s our 2023 Robot Code: GitHub - 4322/2023_Robot: FIRST CHARGED UP 2023

1 Like
5

Week of 7/24 - 7/30 Update

Overview
For the 2023 off-season, the main project we’ve been working on is creating a three-motor swerve drive for our robot. After experimenting with trying to get our robot to do floor pickup, we realized that cubes were the only viable game pieces we could pick up from the floor due to our intake design. As a result, we decided to look at other aspects of the robot that would reduce our cycle time, and we came across three motor swerve. We decided to pursue this project for the off-season because we realized that it would not only reduce the time it takes to get to the single substation and back, but it would also be useful for upcoming FRC seasons. By having the capability to implement a 3 motor swerve on our future robots, we will be prepared for any sort of fast-pace game that requires quick cycle times. Additionally, the extra power from having 2 drive motors will allow us to push past any robots trying to play defense against us, which was a major problem we faced during the season.

CAD
We started off with the OpenSwerve 3 Motor Swerve Module CAD, and began adding our modifications to it. We switched the rotation motor from Falcon to NEO brushless motor because Falcons are not in stock, and we adjusted the mounting to be compatible with our 2023 robot. We created our swerve cover to have space to mount a SparkMAX inside, and this way the SparkMAX is safe and secure inside the cover. We added bearing locations on the top plates to support 3 motor shafts. In an effort to make the manufacturing process easier, several design modifications were implemented. First, the extra support surrounding the bearings was eliminated, making it easier to produce. Similarly, the pocketing was also removed to simplify manufacturing without compromising functionality. Additionally, chamfers were omitted from the design to reduce costs further.

Software
In terms of software, we just started adjusting our current swerve code to accommodate for the 3 motor swerve drive. So far, we have finished the code for the second drive motor including making the second drive motor follow the first and inverting it and we started changing the rotation motor to a Neo.

We plan on configuring the Neo to use the external redux encoder so that we do not have to use the sparkMAX encoder, which would decrease latency. Other plans for the future include the changing of the rotation motor gear ratio, updating the logic to controllers for the neo rotation motor, creating current and voltage monetization, and depending on testing, may revisit our anti-tipping code from 2022. The current and voltage monetization is being used since the 3 motor swerve will be capable of using much more power than the breaker is able to handle. As such, we will also need to include safeties which limit the power of the swerve modules to prevent browning out. As for the anti-tipping code, our team has prioritized having a low center of gravity on our robot, but if the increased speed from 3 motor swerve makes our robot more prone to tipping, then we may need to revisit our 2022 anti-tipping code. An alternative to this would be decreasing the acceleration and deceleration of the robot.

On the side, we are also undergoing software training for new members of the team. We have been teaching new members the basics of Java and are currently getting to intermediate topics which consist of understanding WPILib and the command-based framework.

6 Likes
6

Week of 8/7 - 8/13 Update

Overview
This week we have been creating a technical binder for our 2023 robot and have continued our software training for new students.

Our technical binder is split up into 3 main sections: design process, final design, and programming. The design process section covers the different designs we thought of during build season for each subsystem on the robot, including the pros and cons for each potential design. Our final design section covers the subsystems we decided on in the end, and the different modifications we made to them for each regional we went to (Orange County & San Diego Regional). Our programming section covers the autos we created, our driver controls, and the vision system we had on our robot. We are currently in the process of finishing up our technical binder, and a link to it will be posted on the Open Alliance once it’s finished.

Software
For software training, we have been learning how to read an FRC program, starting with our 2023 robot code. We learned to investigate robot code by starting off at the subsystems, then going to the commands, and then looking at RobotContainer. Looking at the subsystems lets us understand the basic capabilities of the subsystem. Looking at the commands lets us understand the logic behind how a subsystem’s methods are being invoked in order to perform a certain action. Finally, looking at RobotContainer helps determine the robot’s autonomous capabilities, and how the robot is controlled through its button bindings. We also learned about other intermediate topics like singletons and try-catch statements, both of which are commonly used in an FRC program. We are now going to start learning about Git and how it is used to manage our robot code throughout build season.

3 Likes
7

Week of 8/21 - 8/27 Update

Overview
This week, we have been building our 3-motor swerve, refactoring our swerve drive code to adjust for 3 motors, and are in the final stages of completing our technical binder.

On Tuesday, FIRST came out with the announcement that 3-motor swerve is banned for future seasons(Announcement). This was unfortunate timing for us because we’ve been developing our own 3-motor swerve in preparation for the off-season and future competitions, and the parts we ordered to assemble it have already arrived. Since we’ve already invested a considerable amount of time and money into the project, we decided to continue developing our 3-motor swerve for the off-season.

Mechanical
We began assembling our 3-motor swerve by first sorting parts for each module into their own pile. We then began tapping holes into the swerve plates, and also started working on assembling the wheels. Currently, we are using the SDS MK4i Swerve Module Assembly Guide to build the modules.

Software
We have been adjusting our encoder code for the turning motor due to it switching from a Falcon to a NEO. We changed the swerve drive logic to accept a SparkMAX instead of a CANCoder, and also adjusted the current limits for the encoder. In addition, we updated our Phoenix vendor library from 5 to 6(Phoenix Pro API became free and was renamed to Phoenix 6), and are currently in the process of migrating to the new framework.

For software training, we have been covering the fundamentals of Git and version control software. We have been dissecting our Git history from the 2023 season and are planning on doing exercises where we commit code and create new branches.

5 Likes
8

Week of 8/28 - 9/3 Update

Overview
This week we have continued building our 3-motor swerve modules, finished our technical binder, and have continued working on refactoring our swerve drive code.

Our technical binder has been completed. Here is a link to view it:
FRC 4322 2023 Technical Documentation.pdf (7.0 MB)

Mechanical
When tapping our first main plate for the 3 motor swerve project, we had to use a drill since we didn’t have our T-handle tap wrench. We found that some of the bolts that the modules came with to mount the bearing to the plate had a loose fit in the plate and some of them felt like we could just pull them out. We decided to go with slightly longer bolts and found that they held the bearing down more secure. We used loctite on all the bolts we used while assembling the modules.

After tapping the holes and attaching the bearing, we proceeded with steps 3-6.

We took off the Swerve X modules from our robot so we could remove the Falcons and encoder to prepare for step 8.

In addition to assembling the 3 motor swerve modules, we continued to work on the CAD for the cover plates. We added notches in the fronts of all the covers that allow us to fit a zip tie through for wire management.

Software
We have continued migrating our code to the Phoenix 6 vendor library. Due to the major differences between Phoenix 5 and 6, we changed a few of our methods to accept rotations units instead of encoder ticks, refactored our PID initialization, and changed our coast/brake mode to accommodate for the new library.

For software training, we have created a new Git repository for us to conduct training exercises, play around with, and learn more about how Git works. We discovered that using the Git Rebase feature in VS Code makes the branch line in Git Graph(VS Code extension) look cleaner for cases where two or more people are working on the same branch.

Normally, if one person pushes their code, then when another person working in the same branch pulls and pushes their code, the graphical visualization will make it seem like another branch has been created and was merged in.

However, the rebase function rewrites the history of the merge and makes the branch graph look like a clean line made up of a series of consecutive commits, which is much easier to understand and work with. While there usually are concerns with rewriting history in Git, we decided that this feature will benefit us by making our commit history simpler to read & understand.

5 Likes
9

Week of 9/4 - 9/10 Update

Overview
We continued to build our 3-motor swerve modules and built our new robot cart this week. We also continued refactoring our swerve drive code for 3 motor swerve, and began working on our scouting website for future seasons.

Mechanical
We continued assembling the modules at step 6 since that is where we made it last week. We made sure to use loctite on all the screws in step 6.

Since we custom made our top plate, we had to order screws that were separate from those that came with the module.

While working on step 8, we noticed that a shaft for one of our Falcon 500 motors was wiggling, so we continued with steps 10 and 11 from the SDS Mk4i Swerve Modules Assembly Guide. We had to tap the encoder mounting holes and encoder enclosure since the plates are custom and we did not make them tapped to reduce cost.

In addition to building the 3 motor swerve modules, we assembled our new robot cart. We bought it with upgrades in mind, such as adding a space to place the driver station on and battery holders.

Software

In terms of software, we finished fully migrating our code to the Phoenix 6 library. We changed the stator and supply limit configs for the Talon motors, changed our rotation gear ratio from SwerveX to SDS MK4i, and also added CANivore support to our motors. CANivore increases the number of CAN FD Busses that can be added to the RoboRIO, and due to the additional motors and motor controllers for 3-motor swerve, we decided to buy the CANivore device and configure it in our software. The configuration process is very simple, and it requires one to pass in the string name of the CANivore’s name or serial number into a supported device’s constructor, and then the device is added to the bus(Link for reference).

Additionally, we have been working on a scouting app that we will be using for our 2023 off-season and future seasons. The software students have configured NodeJS and their development environment, and are now in the process of learning how to use the AngularJS web development framework in order to contribute to the app.

8 Likes
10

Just checking, you know that 12/3 motor swerve is going to be banned in the 2024 season, right?
Building it for offseason still makes sense but I just wanted to be sure.
The modules look super cool, though.

2 Likes
11

It states earlier in the thread that they are aware of it.

2 Likes
12

Oh, sorry. I tried to read up, but I guess I didn’t read well enough.

2 Likes
13

9/11 - 9/24 Update

Overview
We finished building 4 of our 3-motor swerve modules and worked on our spare module. We wired the robot and finished wire management. We also finished debugging our 3-motor swerve code and completed PID tuning for the rotation and drive motors.

Mechanical
We continued assembling the 3 motor swerve modules. Our drive pinions were not at the correct height, so we 3D printed spacers to make them fit better. We also had to replace a spline shaft on one of our falcons. When we went to mount the modules on the robot, we noticed that the center falcon on all the modules hit the belly pan, so the module would not sit correctly.

The orientation we originally had the falcon in made the wires get crammed against the PDH, so we rotated the center falcon on all our modules so the wires point to the side. The bottom of the falcons also had a section that stuck out farther, so we turned the second drive falcon to the side so we didn’t have to cut the belly pan for that.

We cut our steel belly pan using a jigsaw, but the blades kept getting ruined when we tried to cut the aluminum frame, so we switched to using a hacksaw.

When mounting the swerve modules, we noticed that the wheel hit the bottom plate when we were trying to spin it. We took our old swerve X top plates to fix the issue and used a bandsaw to cut notches into it so we could use it as a replacement. Since we used the Swerve X top plate as our bottom plate, we didn’t have long enough bolts, so we used thinner locknuts. Some of our mounting holes were misaligned, so we drilled new holes.

Our spare swerve module got loctite stuck in the hole for the non-bevel gear fork, so we couldn’t get the bolt fully screwed in. We tried using acetone to take it out, but were unsuccessful. We tapped the hole again and got it to work. We broke a tap off in the encoder mounting hole on our top plate, so we hammered it in so it was flush and used the other set of holes we had.

Our original vanity bumpers were sewn at an angle, so we used a seam ripper to undo the stitches. We then correctly sewed the fabric in a straight line, added our name and number with white vinyl, stapled it to the robot, cut the extra fabric, used gaffers tape on the inside, and added brackets.

We remade our cover panels so they now cover our battery since we removed the hopper and our arm now telescopes down and hits it when the robot is disabled. We used white polycarb to make it and velcro to mount it to the swerve covers on the robot. We made sure to add a label to indicate the main breaker on the robot.

Electrical

We added anderson connectors to all of our swerve modules. We used double sided tape to attach the spark max’s to the top of the swerve plate since we didn’t have time to 3D print our covers that had the spark max holder on them. We added the CANivore to the drive base and wired the CANbus. When testing our robot, we noticed that some of our andersons were not pushed fully into the plastic casing. We needed extra batteries for 3 motor swerve, so we added leads to those. We fully wire managed our robot. We had a CAN wire that was hanging over the PDH, so we added an extender. We lost two spark maxes while testing 3 motor swerve. We don’t know why either of them stopped working.

Software

Voltage code was completed and we worked on switching our controls from co-drivers to driver operator. We had a scoring driver and a loading driver for this past season, but we decided to go back to the driver operator model to make it easier for the drive team to have to focus on fewer things at once. We added a wheel lock at the last 10 ms of auto, fixed the game piece eject bug, added 8 new autos using our floor cube pick up, configured motor ID for the drivebase, and created an auto manager to make it easier for the drive team to select autos before a match. Our robot initially had issues with break mode, but we resolved those issues. When testing our robot at a practice field, the robot couldn’t drive straight. We created a version of autorotate to make sure we keep our heading degrees the same when we drive straight. We tuned the drive PID and updated our max speed and max acceleration values.

7 Likes
14

Just to confirm, two different students swapped off controlling the drive train of the robot in a match? How did you handle the transition between the two controls?

1 Like
15

Our loading driver would drive the robot from the community to the single substation and while they were doing that the scoring driver decided what piece we wanted to score and would change the led colors to let the human player know what we want. Once the piece was in the robot, the scoring driver drives the robot back from the single substation to the grid and scores it. Our human player would give the drive team a thumbs up when the piece was in the robot to signal to our scoring driver that they were good to drive it back. As soon as the piece was scored, our loading driver knew that they were good to get another piece. Whichever driver was in control of the robot during endgame was the one who would dock and engage the robot on the charge station. Our loading driver would say “intake” so our scoring driver knew that everything was good while they were looking for the best place to score a piece. I was our scoring driver this year, so when I decided what piece to score, I would just say whatever piece we were going to score and where I was scoring it.

4 Likes
16

Thanks for the explanation!

2 Likes
17

9/24 - 10/6 Update

Overview

  • Built our spare 3 motor swerve module
  • Driver practice
  • Created new cover panels and put sponsor stickers on them
  • Fixed auto problem that was causing CAN errors
  • Deleted logs that filled the RoboRIO memory
  • Made new tread hole pattern jig for mk4i wheels
  • Fixed auto code for auto balance and tuned PID values

Mechanical

  • Assembled most of spare 3 motor swerve module
    • Lost a spacer for falcon motor mount and need that piece to fully finish the module
    • Put andersons on NEO

  • Created cover panel out of polycarb
    • Cut a deep slit in the cover panels so intake doesn’t rip it off when arm homes
    • Added sponsor stickers

  • Created new tread hole pattern for mk4i wheels
    • Cut tread to length
    • Installed one piece of tread on a wheel as a test
    • Named all our wheels to keep track of when things get replaced

Software

  • Had an issue where our robot code wouldn’t deploy to the RoboRIO
    • Found that we had filled up its memory with logs
    • Deleted its logs, reformatted it, and reflashed the firmware
    • Deleted all of our RIO logging in the code
    • Determined that in the future, we need to implement log rotation to prevent the RoboRIO memory from filling up
  • Tuned our PID values
  • Work on our autobalance code for autos since they weren’t working
  • Added a white LED flash to help the operator know that the robot understood their preset change
  • Autochooser for autos wasn’t working
    • Fixed it by creating a custom utility class that has a method to wipe shuffleboard and redisplay the Autos corresponding to the grid location we picked
4 Likes
18

SoCal Showdown

  • Broke our intake plate by sideswiping the single substation
    • Replaced the plate
      • Cracked the replacement plate
    • Mechanical Solutions for next competition
      • Decided to have hot swap intakes for next off-season event
      • Decided to use a more flexible polycarb
        • Considered aluminum, but decided against it because sideswiping substation would lead to intake being permanently bent at an odd angle
    • Software Solutions for next competition
      • Going to create a substation-align command so robot aligns to substation automatically using custom april tags
        • Will make our cycle time faster since aligning to substation took a considerable amount of time
        • Will reduce chances of intake hitting substation
      • Going to extend only arm position when rotating to single substation, and when custom april tags are detected by limelight, telescope will extend
        • Reduces the chances of us sideswiping the single substation and breaking our intake


(this picture is where we first cracked our intake plate in quals 4)

  • Ripped bumper brackets
    • Had to use vanity bumpers as our red bumpers for some of the matches
    • Finger joints on bumpers started to split
    • Small tear in vanity bumper fabric from practice, but overall fabric held up well

  • Broke the kevlar cord for our arm counterbalance and had to replace it

  • Had many battery issues before and during matches

    • Large current draw from 3 motor swerve led to a few brown outs
      • Required us to only use batteries that were 12.3 V or higher
    • Even after ensuring battery voltage and resistance was good(by using a battery beak) and placing it in robot, voltage sometimes significantly decreased during ide mode
      • Caused us to have to frantically replace battery right before start of matches
    • Don’t currently know why battery issues are occurring
      • Already worked on current limiting before competition, but will look further into it to determine if we need to have more current limiting on falcons rive motors
      • Will look further into our battery charging settings and triple-charging mode

  • Some autos weren’t very consistent

    • Auto-engage charge station didn’t work very well and led to getting docked points many times during Auto period
      • Will tune Auto PID further due to switch to 3 motor swerve
    • Tested 2-piece auto once
      • Moved the wrong direction when trying to pick up cube from ground
      • Robot ended pretty far away from the grid when trying to score the ghost cube

  • Score preload cone didn’t work for a couple matches

    • Robot sometimes wasn’t aligned properly to grid
      • Made sure to push bumpers firmly against grid
    • Added longer eject time to outtake in order to make sure game piece was fully out before retracting arm

  • Switched to defense twice during the competition

    • Bug in telescope logic made our entire arm stuck in a certain position where we couldn’t intake or outtake
      • Causes us to play defense, which we realized we were very good at because our 3-motor swerve drive allowed us to push opponents very easily
5 Likes
19

10/9 - 11/2 Update

Overview

  • Build hot swap second intake
  • Driver practice
  • Made more tread
  • Fully finished spare 3 motor swerve module
  • Remade red and blue bumpers
  • Added rivets to arm supports to reduce arm wobble
  • Improved battery logging
  • Fixed auto alignment at single substation
  • Made mobility auto end with the robot rotated to the single substation

Mechanical/Electrical

  • Batteries
    • Made a way to drain batteries without using them so they can charge better
    • Fixing two batteries by lowering their resistance
    • Made all batteries 4 gauge wire instead of 6 gauge
    • Created a battery logging binder to mark when we put each batter in, the starting resistance, starting voltage, ending resistance, ending voltage, and any other comments we had about its performance

  • Made second intake
    • Cut shafts to length
    • Tapped shafts for spare intake to put squishy wheels on
    • Put old squishy wheels on spare intake so we can use the nice new ones on the main intake
    • Planetary gearbox was squashed because the bolts connecting the neo to the intake was too long

  • Removed half links on arm chain
    • They’re all full links now
    • Tightened the chain
  • Did a wheel swap since the tread was wearing down
    • Noticed a pattern in our front left and back right wheels tread going flatter faster

  • Broke kevlar cord on our counterbalance
    • Had to replace it

  • Took intake off of robot
    • Replaced broken plate and added new back plate
    • One screw was stripped while trying to mount intake plate to telescope
    • Phillips screws weren’t strong for the intake, so now we’re using 3 inch socket heads to make it more sturdy
    • Used washers to stabilize the brace on our intake
    • Still snapped the intake brace at the single substation because our arm flipped over to score mid and swiped against the top of the substation

  • Added missing bolts to arm neo cases so it doesn’t wiggle
  • 3 motor swerve spare
    • Added spacer for falcon motor mount on 3 motor swerve module spare
    • Added NEO andersons
    • It is finished now

  • Bumpers
    • Cut new wood for red and blue bumpers
    • Removed red and blue fabric from old bumper wood to put on new wood since fabric held up
      • On red set, had to attach the top corners with the screws from the brackets
      • On blue set, stapled corners of fabric to the wood since bracket was put in the center
    • Used stronger brackets on new wood
    • Small tear in the bottom corner of our blue bumpers
    • Used T-nuts to hold the bolts that mount the bracket to the wood

  • Tread
    • Cut and drilled 18 pieces of spare tread

  • Replaced falcon motor shaft

    • Hole was stripped on cover plate for swerve, so replaced it with the one from the spare module

  • Drilled holes in cover panel so we could zip tie the two together

  • Filled in the extra rivets that we didn’t put in at the start of the season to reduce arm wobble
    • Originally left some of them out because we knew it would be good to put them in later in the year when we needed them after the robot had been used a lot

  • Added CAN extender to can loop so it doesn’t go over ethernet

Software

  • Autos
    • Autobalance for charge station was adjusting too slowly while on the charge station
      • Tuned the adjusting power to be fast enough to balance within the 15 second period but slow enough so that it doesn’t overshoot
      • Increased distance traveled by robot to fully go over charge station and get mobility points before coming back to balance
    • Modified mobility autos at grid locations 1 and 9 to end closer to the center of the field and rotated correctly to the single substation position

  • Issues/improvements found while doing driver practice

    • Arm was sometimes stuck in certain preset positions when it was supposed to go back to the home position
      • Found out that limit switch was broken and couldn’t be used to reliably detect when arm is back in the home position
      • Since we have a physical hard stop for the arm, we changed the logic to move the arm back until it detects that it can’t move back any further(when it hits the hard stop) and then say that it is at the home position
    • Decided to move the arm to single substation position when robot is auto-rotated to the single substation position
      • Normally, arm and telescope extended out together to the substation position when a button was pressed
      • Now only the arm comes out, which reduces the chances of sideswiping the substation since the intake remains within the robot frame until it clears the sides of the substation

  • New Software Feature: Auto-Aligning to Substation using April Tags

    • We decided to create this feature because our intake was getting caught on the side of the single substation when trying to move to load a piece, which caused it to break many times
    • Auto Align to Substation uses custom April Tags we place at the front of the single substation to adjust the robot to the single substation
    • Limelight use:
      • Get horizontal degree offset to april tags to adjust the robot forwards and backwards on the field (field relative)
      • Get vertical degree offset to april tags to adjust the left and right movement of the robot (field relative)
        • Debated between using the April Tag area versus vertical offset degrees to get distance from robot to the front of the substation, but went with vertical offset degrees for convenience since we already had existing logic for how far the robot needs to move based on the degree offset
    • We use 3 april tags, 2 small ones on the left and right side, and 1 large one in the middle (courtesy of 987)
      • The large one in the middle is the primary one we use to align with the substation, but the other two give us a larger detection area for our limelight
    • We use LEDs to let the driver know when auto-align is occurring and when it has been completed with a game piece loaded into the intake
      • LEDs turn red while aligning, and then turn green when completed, which gives control back to the driver
        • We implemented a breakout button so that if auto-alignment were to fail, the driver can immediately assume control and manually align to the substation
6 Likes
20

Tidal Tumble

MECHANICAL

  • Fixed cracking intake plates by switching to a more flexible polycarb (plates did not crack even with single substation side swipe)

  • Bent a bolt that mounts a swerve plate to the frame of the robot

  • Bracket started to rip out from one of the corners of our blue bumpers
    • Staples holding the fabric in the corner were coming out too

  • Failure: Cracked the intake brace near our bearing
  • Fix: Replace brace and create spares

  • Robot tore a hole through the carpet and rubber to the floor
    • White mark on the field is where the hole was
      • Tread was not impacted

SOFTWARE

Failure: We experienced multiple brownouts due to 3-motor swerve drawing too much current
Fix: Reduced our stator limit from 80 to 60, which solved the issue

Failure: Auto-substation align code caused our robot to bug out many times. It caused our robot to charge into the opposing alliance loading zone without the driver being able to regain control
Fix: We removed the auto-substation align command and let the driver manually align to the substation

Failure: Experienced a major issue during 1 match where our Gyro was giving false readings and caused our wheels to turn while the robot was stuck against a wall, which caused us to burn through the carpet.
Fix: After turning on robot, wait about 30 seconds for the gyro to settle down and initialize before moving it

Failure: Didn’t tune Limelight properly, which caused us to sometimes fail at detecting retroreflective grid tape and April Tags at substation
Fix: Move the robot around to different positions to make sure it’s consistent at picking up vision targets. Also tape the substation april tag in front of the polycarb holder to reduce vision glare.

PLANNED IMPROVEMENTS:

  • Fix auto-align to single substation software for Beach Blitz
  • Driver practice on flat carpet
  • Create spare intake for Beach Blitz
8 Likes
21

Beach Blitz

MECHANICAL

Failure: Cracked intake brace.
Fix: Replaced intake brace with spare one.

Failure: Disabled because of transitively touching robot through game piece.
Fix: Use a cone to push the cube further intake.

Failure: Auto cone scoring was missing many times.
Fix: Angle cone when placing it in the robot so the flange of the cone goes on top of the intake place in diamond formation.

Failure: Arm got bent while sideswiping single substation during auto alignment.
Fix: Try to force arm back into place. That didn’t work, so we did practice at the practice field with lining up with crooked arm.

Failure: Bent arm was getting caught on cover panels.
Fix: Cut cover panels to allow the arm to clear.

SOFTWARE

Failure: Auto-substation align swayed a lot while trying to align to the single substation and the switch from autonomous control to driver control was unclear for that command.
Fix: Tuned the P value for the PID and added a blue flash so the driver knows they have control of the robot again.

Failure: Telescope wasn’t retracting when scoring mid due to hardware gear slip.
Fix: Added operator button to manually retract telescope and reset the homing position.

11 Likes