2656 Quasics - 2023 Open Alliance Build Thread

[smcmahon]

Welcome to the 2023 Quasics #openalliance build thread! Team 2656 is from Gateway High School in Monroeville PA, just east of Pittsburgh. We grew a bit for 2023 and have 18 students on our roster. We have 5 coaches.

2023 will be our 16th season of the FIRST Robotics Competition. We are registered to compete at the Greater Pittsburgh Regional in April. With our current level of funding, we are a “one-Regional” team. We do get to a fair amount of off-season events though. In 2022 we competed at WVROX and MVRC. Our team helped plan and volunteered at ‘Steel City Showdown’ in 2017 and 2019. SCS is a Pittsburgh off-season event hosted by Carnegie Mellon University. We are hoping to bring Showdown back to Pittsburgh in August of 2023!

Resources

Build space- we have a 10’ x 11’ storage closet inside one of the high school computer labs where we store our robot, parts, and tools. We also have additional shelving space in a 10’ x 10’ adjacent closet. We mainly build in the front half of the classroom, which is roughly 20’ x 10’. The room also has 24 computers, which we use for coding, 3D modeling, writing, and video editing.

Sponsors- Gateway School District provides our build space and transportation. We also started a Varsity Letter program with their support! Google, Bechtel Plant Machinery, Microsoft, Argo AI, Barnes & Noble, Sheetz, the Mukhtar family, the Hofmann family, and the MERS Group round out our sponsors.

Fun fact about Quasics: we are a Girl Scouts Western PA Program Partner! We have held 43 STEM Badge Workshops all around Pittsburgh. Through our events, local Girl Scouts have earned 597 STEM badges to date!

Thank you so much for reading about Team 2656. We’re excited to represent the #openalliance in Pittsburgh with our friends from Team 4467 - Titanium Titans!

Social media links
www.quasics.org
Facebook, Twitter, Instagram , YouTube

[smcmahon]

January 7 / Gateway HS / Monroeville PA

Like many FRC teams, we settled into our school’s LGI to watch the Kickoff broadcast on Saturday. Afterwards we enjoyed some Domino’s Pizza and then got into the rule manual. We broke into small groups to tackle #openalliance member 6328’s Kickoff worksheet. We had some further discussions to make a list of robot actions. We wrapped up Saturday by taking 1678’s Rules Quiz. As a team we got 41/45 so we passed! (Two of the questions that we missed were about the elimination tournament - something we haven’t seen since 2018…)

Here’s a photo of Team 2656 at our Kickoff!

[smcmahon]

January 8 / Murrysville, PA

We continued our tradition of spending the day-after-Kickoff with our neighbors and good friends Team 4150, FRobotics. We spent 4 hours making new friends and discussing Charged Up. We clarified some rules, made lists of contending robot qualities, and had the students draw up and present some robot ideas.

I really enjoy seeing the teams interact, and I’m looking forward to catching up with 4150 soon to see how our Build Seasons are going!

Here’s a photo of our joint meeting

[smcmahon]

January 13 / Gateway HS / Monroeville PA

This was our first meeting after our midterm exams. We reviewed the Charged Up game animation and scoring, and then we watched the Team Ri3d Strategy Guide! We also took in 15 minutes of the Charged Up panel discussion on FIRST Canada Live.

We broke up into three sub-teams to do some “Market Research”, consisting of researching answers to the following questions:

• What games have similar elements/game pieces?
• What games have similar movements to score? (Pick and Place games)
• What were the common robot designs?
• Which of those designs could be found on Regional winning alliances? Division winners? World champs?

We used the above information to try to pin down Charged Up robot archetypes.

We wrapped up Friday the 13th with a SWOT analysis of our experience and capabilities. Unfortunately we didn’t capture that data, but I’ll make a note to get it all together for next time!

[D_Price]

Excited to see the robot this year!

[smcmahon]

January 14 / Gateway HS / Monroeville PA

We spent most of Saturday testing things “in real life”. We did a lot of measuring, taping off spaces, and testing the game pieces with our 2021 and 2022 robots. Here are our observations:

• Cones were able to wedge under the 2022 robot (7" bumpers at top) - high speeds, pointing towards wheels, squished underneath (25%). Requires more testing.
• Cubes stay with robot when driving straight - both slow and fast
• Access to scoring grid is much smaller in real life
• Scoring Grid is much larger in real life than it looks in CAD
• Possible to shoot cube
• Pushing viable for both game pieces
• Passive manipulator plausible for both game pieces
• 3 robots can fit on charger station - tight fight, smaller width better
  • Robot could hang sideways if you’re brave
  • Bumpers can hang over edge
• Possible to shake BOTH game pieces off robot
  • Driving forwards or backwards causes it to fall off
  • Cube falls straight down
• With a 22” frame, maximum 10” hole can clear both cone and square
• Tolerances for scoring game pieces (based on comparative surface areas; lower #s are better)
  • Cone on post scoring tolerance (16%)
  • Cone on floor (upright) (27%)
  • Cube on shelf (29%)
  • Cube on floor (37%)
• Turning corners with manipulator/mechanism sticking out more difficult
  • Ideal to fold up, especially for defense

We also discussed our drive base, prior to seeing the MCC robots from REV Robotics, WCP, and the Everybot.

Drive Base specs:
24”W x 26”L
SPARK Max/NEO controllers and motors
Gear box ratio: stock for now
Wheel size/type: stock white HiGrips for now, 6"

[smcmahon]

Photos from Saturday’s IRL testing:

[smcmahon]

Prior to the MCC robot reveals we made the following Priority List:

Priority	Action/Skill
1	Drive (reliably)
2	Charging station (Teleop)
3	Strong defense
4	Mobility points (Auto)
5	Score preloaded cargo (Auto)
6	Highly maneuverable (fast from point to point)
7	Charging station (Auto)
8	Acquire Cubes (floor)
8	Acquire Cones (floor)
9	Score Cubes First Row
9	Score Cones First Row

[smcmahon]

January 17 / Gateway HS / Monroeville PA

We reviewed the MCC robot concepts from West Coast Products, REV Robotics, and Everybot. We had some discussions before and after on whether or not these concepts were right for us. The students chose to build a machine different than these ones, which focuses more on our priority list from the previous post. I like to call it the EveryPartner . Our hope is to build a fast and reliable Hybrid scorer that can also deliver pieces to the community for partners who can reach the floor, score the Charging Station in both Auto / Teleop, grab the Mobility points, and play aggressive midfield defense. We believe a machine like this has a place on a Regional eliminations Alliance.

Our mech students assembled the AM14U5 wheel pulleys and began brainstorming ways to capture the game pieces from the floor / Substations. Our coding team generated skeleton code for our Charged Up robot and installed the 2023 tools on our laptops and workstations.

[smcmahon]

January 19 / Gateway HS / Monroeville PA

We broke out into subteams to explore 3 different intake ideas. We’re looking for something that can flip out and collect both Cones and Cubes, and safely transport them across the arena to partners or the Hybrid grid. The three initial models were the WCP concept intake, the REV Robotics starter robot intake, and a Y-shaped gripper. We’ll have photos of their progress in our January 24 update. Here are brief summaries from the students!

Team REV

We began by examining different intake designs and started prototyping the Rev Robotics intake. We cut and measured the 2 by 1s and 1 by 1s for the frame. We used duck tape to hold the shape of the frame in place while drilling. One issue we encountered was the lack of hex shaft, so we had to cut smaller bars for the joint instead of using longer ones. Then we filed them down because it created more hex shape then a straight cut.

Y gripper

I built a Y acting gripper thing that can somewhat pick up a Cone, with a lawnmower grip handle. The plan is to use some form of air cylinder to add more grip to the Cone, when adding or releasing the Cone. I also plan to reconfigure the grip device to gain more of a grip. I also plan for it to pick up a Cube but the prototype dimensions are currently too small to test that information.

On the drive base side, we cut all six frame rails and began assembly. We also got the Anderson connectors on four new NEO motors so they would be ready to mount into the AndyMark gearboxes on Saturday.

The Coding team was busy as well! Our Coding Lead noted the following tasks were in progress:

• Finished Installing all FRC 2023 tools on all 4 laptops (trained newer programmers)
• Reimaged both of the RoboRio 2.0 units and one RoboRio 1.0 for the testing drive bases (trained newer programmers)
• 2 Programmers continued their training on basic C++ syntax and implementation
• 2 Programmers Drafted a Drive base Subsystem Sketch and began creating implementation
• 1 Programmer drafted and began implementing a self-balancing command

[smcmahon]

January 21 / Gateway HS / Monroeville PA

Our Coding Lead provided the following updates from January 21:

• 2 Programmers made significant progress in their training on basic C++ syntax and implementation
• 2 Programmers continued working on the Drivebase and tank drive implementation
  • Instantiated Motor controllers
  • Linked Tank Drive Command with Playstation Controller
  • Added Turtle, and Turbo speed support
  • Drafted a slew limiter implementation
• 1 Programmer continued working on the Self Balancing Command
  • Downloaded Romi Tools
  • Reimaged a Romi
  • Tested Romi on Balancing Board
  • Adjusted Code for Additional Functionality
  • Began Practicing Tuning PID on Romi

Here’s a photo of the Romi working on the balancing board!

[smcmahon]

January 21 / Gateway HS / Monroeville PA

Excited to announce that our wooden Charging Station is nearly complete. We need to get some Lexan coverings. We’re hoping to have that done on the 24th.

Following are updates from Team WCP and Y gripper teams from January 21:

Team WCP

Our subteam decided to design a prototype based on WCP’s intake. To do this, we used geometry measurements from their CAD. Their prototype uses several 3 inch wheels, but we have much more 4 inch. We decided to keep the same geometry and spacing, but our wheels will stagger because of the extra width. We drilled 3 bearing holes in each of 2 aluminum 2 by 1s, then we attached these to create a U shape. For now, we will just be testing the geometry with the cubes, but WCP’s intake is able to adjust for cones. The prototype will have a 7 inch opening as did the original. We started assembly with hex shaft and wheels, so next meeting we will be able to finish that up and test how the cube fits. If possible, we might run the wheels with drills to test.

Y gripper

The best thing for gripping the cone is the green wheels and the second is pink pencil eraser blocks. Also the y grip thing has 3x3 parallel wheels in an X pattern.

Next put a 2nd parallel set below the first but doesn’t work as well but ran out of time to test.

Weird thing noted is that to pick up cones it holds better with the wheels flat facing towards you and not flat facing down. The original plane of a rope or something to clamp the side beams to hold the cone or cube does not work and must be redesigned.

Note: Can pick up cubes, but a bigger gusset was needed, however when we did that it felt harder to hold the cone? We do think that the contraption was better and we slowly made it worse.

Overall relatively successful so far!

We also have our 24" wide by 26" long AndyMark drive base assembled! Next up for her is a temporary electrical board and bumpers!

[smcmahon]

January 21 / Gateway HS / Monroeville PA

Here’s a cool photo of a design meeting being held in our high school’s new eSports Lab!

[HollywoodINC]

Love the romi on a balance board idea.

[smcmahon]

Ah thanks! Our coding mentor and Lead thought of that! They’re having fun testing that idea.

[smcmahon]

January 24 / Gateway HS / Monroeville PA

We removed the shooter and climbers from our 2022 robot, Sally, and handed over her drive base to the Coding team for development.

Fabrication finished attaching polycarbonate to our Charging Station for auto / teleop testing. They also cut the bumper wood for our 2023 machine’s first set of bumpers. We wanted to get them done earlier this year to do our best testing on the Charging Station.

Team REV continued work on their testing version of the REV Starter Bot intake, noting the following, “In just 3 hours, we were able to assemble the first prototype of the REV Robotics intake concept. Although there were still a few problems such as holes not lining up and a not long enough hex shaft, we were able to quickly solve them. We are on track to test on 1/26 and then begin making revisions to improve the design. We will also start planning how the intake will be stored in the robot before a match starts.” Here’s a photo!

On the software side:

• 1 Programmer continued training on C++ Syntax
• 2 Programmers continued working on drive base (Tested Tank Drive Code, Adjusted Slew Rate Limiters, Updated Firmware on SparkMAX’s and Power Distribution Hub)
• 1 Programmer continued working on self-balancing command (Fixed Bugs, Continued training with tuning PID on Romi)

[smcmahon]

January 28 / Gateway HS / Monroeville PA

Team 2656 has a big update from this past Saturday’s meeting!

I’ll start with Coding, who wrote up a lengthy summary of what has been done recently and things on the horizon.

Autonomous options were brainstormed, and initially prioritized for implementation (based on perceived need):

1. Do Nothing
2. Drive out of the Community
3. Drive towards desired location(defense)
4. Score Game Piece
5. Score Game Piece then Leave Community
6. Charging Station Balance
7. Score then Charging Station Balance
8. Score and End Near a Game Piece
9. Drop Game Piece
10. Drop Game Piece and Leave Community
11. Drop Game Piece then Charging Station Balance

Possible basic elements of functionality:

• Drive at Power for Distance
• Turn at Power for Angle
• Pick Up Piece(TBD)
• Drop Piece(TBD)
• Manipulate Piece(TBD)
• Place Piece(TBD)
• Auto-balancing
• Line up with April Tags

Future plans:

• Test Drive at Power for Distance and Turn at Power for Angle Commands on Floor
• Create Autonomous Chooser:
  • Set up Autonomous Options on Smart Dashboard
  • Create Command Series for Possible Robot Movement(Autonomous Options: 2 and 3 for different Robot Starting Positions
  • Maybe PathWeaver For Smother Movement?
• Fix Communication Issue with current Drivebase(Watchdog)
• Address possible issue with Self Balancing Command on Big Bot
  • Rapid Movement when utilizing PID
  • Either Forgot Power Reduction Somewhere(Was reducing to 0.4)
  • Or PID input is too massive, scale down PID constant and/or input data
• Begin Testing the Self Balancing Big Bot on Charging Station

----- On the non-Coding side, work continued in several areas:

Our four game piece manipulator designs were discussed, and cut down to two: the REV Robotics Starter Bot intake and a double roller intake, inspired by Team 4481’s Open Alliance work. This was determined by isolating the main parts of the robot and then voting. This lengthy process led to the choices we made.

A temporary electrical board was set up allowing for testing of the 2023 robot drive base to begin.
Tests were run in the LGI and on blocks to run the wheels. Josh and Ethan from the Coding team took care of the latter.

Pool noodles were measured and cut, and then taped on the bumper frame. Blue fabric is being ordered. Next up is printing the bumper numbers for the red set on the Cricut, cutting the red fabric, and heat-pressing the numbers in place.

The twin rollers were fine-tuned with some math to determine that 13x wheels 0.25" spacers were the amount needed for optimal usage. The double roller is also being made into metal from an acrylic prototype.

With proof of concept on both designs, decisions on how to store the intake are occurring . The roller team is also exploring the idea of storing the game pieces in the intake rather than pulling them inside the robot and then dumping them back out into the Hybrid scoring locations.

Bonus photo of the end of the hallway we took over on Saturday!

[smcmahon]

February 4 / Gateway HS / Monroeville PA

We have some intake updates and a bumper update. Coding had such a big day that they are getting their own post!

Twin rollers intake
We finished assembling our double roller prototype this past meeting. Each roller consists of 13x 4" wheels along with 0.25" spacing between each one. We found that the bottom roller needs to have only a 0.5" gap from the floor to properly intake the Cone in various orientations. When that spacing is correct, the rollers can successfully intake the Cone from many different angles, along with the Cube. To test it more accurately, we attached it to our robot base using bearing gussets so that there is a pivoting point for storage. We were able to simulate moving the robot into the game pieces, which seemed to work well. We did have an issue with the spacing from the ground though due to incorrect math when accounting for the bumpers. We have a few ideas to fix this problem along with some other improvements to make to the prototype: lower intake attachment, replace acrylic bearing end gussets with aluminum ones, replace socket head screws with button head screws because of shaft collar clearance, figure out motor mounting and pivot actuation, and replace the full length pivot hex shaft with two smaller ones. Again, big thanks to 4481 for sharing this idea early on. We really like!

REV Starter Bot gripper
Team REV has been working on arms to extend and retract their gripper for storage inside the robot frame perimeter. The top bar was adjusted to prevent collision with the bottom bar and a curved bar was designed to go around the bumper as the bottom bar would have gone through it. After that, the gripper with the 4 bar was assembled, holes were drilled, and bars were cut. A major issue encountered was the collision of bars which was resolved by making the bars longer and adding more distance between them.

Bumpers!
We laid out and cut our red bumper fabric on Saturday. It’s 10’ long and 15" high. The bumpers are meant to be a single piece we lift on and off the robot. Last year we bolted them down with 0.25" bolts through rivnuts on the frame rail. We’re planning to do the same this season. After we cut the fabric, we cut out the bumper numbers from white Siser EasyWeed HTV on our Cricut. We were able to iron on the first set of numbers before the day ended!

[smcmahon]

February 4 / Gateway HS / Monroeville PA

Our software team submitted the following Bug Report to REV Robotics. We’ll let you know what their software team gets back to us with.

Bug report - SparkMaxRelativeEncoder::SetPosition() method is unsynchronized with GetPosition()

Description:

Calls to the SetPosition() method on a SparkMaxRelativeEncoder are not immediately reflected in the value returned by GetPosition(); instead, the encoder appears to be receiving the update asynchronously at some later point in time.

This can result in unexpected/incorrect behavior in client code.

Example steps to reproduce:

Assumptions:

• An frc::Subsystem class (discussed below) has at least one CANSparkMax motor controller and related relative encoder.
• An frc2::Command class (discussed below) uses the subsystem. Simplified example:
• Simplified example code:

class DriveBase : public frc2::SubsystemBase {
 private:
  rev::CANSparkMax m_leftFront{MotorIds::SparkMax::LEFT_FRONT_DRIVE_MOTOR_ID,
                               rev::CANSparkMax::MotorType::kBrushless};
  rev::SparkMaxRelativeEncoder m_leftFrontEncoder = m_leftFront.GetEncoder();
  // Note: controllers and encoders for other motors have been elided
 public:
  DriveBase() {
    // Configuring encoder to report position in meters (based on wheel size/gearing)
    // is elided (but assumed)
    . . . .
    // Reset encoders to 0
    resetEncoders();
    std::cerr << "Left position in ctor: " << getLeftPosition() << std::endl;
  }
  void resetEncoders() {
    if (m_leftFrontEncoder.SetPosition(0) == rev::REVLibError::kOK) {
      std::cerr << "Successfully reset encoder.\n";
    } else {
      std::cerr << "Failed to reset encoder!!!\n";
    }
  }
  double getLeftPosition() {
    return m_leftFrontEncoder.GetPosition();
  }
  void drive(double percent) {
    m_leftFront.set(percent);
  }
};

class DriveForDistance : public frc2::CommandHelper<frc2::CommandBase, DriveForDistance> {
 private:
  DriveBase* driveBase;
  const double distance;
  double start;
 public:
  DriveForDistance(DriveBase* base, double meters) : driveBase(base), distance(meters), start(0) {
    AddRequirements(driveBase);
  }
  void Initialize() {
    driveBase->resetEncoders();  // should print success message
    start = driveBase->getLeftPosition();
    std::cerr << "Left position on init: " << start << std::endl;  // should report 0
  }
  void IsFinished() {
    double position = driveBase->getLeftPosition();
    std::cerr << "Current position: " << position << std::endl;
    return (position >= start + distance);
  }
  void Execute() { driveBase->drive(0.3); }
  void End() { driveBase->drive(0); }
};

1. “Do stuff” with the subsystem so that the encoder will take on a non-zero value.

• Note: this allows the steps below to demonstrate the issue in step 2, but is not strictly required.

2. Restart the robot code, triggering constructor for the subsystem.

• Expected results:
  • subsystem construction should report success on resetting encoder
  • subsystem construction should report that current encoder value is 0
• Actual results:
  • subsystem construction reports success on resetting encoder (OK)
  • subsystem construction reports that current encoder value is still non-zero (UNEXPECTED)

3. Trigger DriveForDistance command with distance of (say) 1 meter.

• Expected results:
  • Initialize() method should report success on resetting encoder
  • Initialize() method should report that current encoder value (assigned to start) is 0
  • First time that IsFinished() is called, it should report that the current encoder value is 0
  • Drive base should move for total distance of 1 meter
• Action results:
  • Initialize() method reports success on resetting encoder (OK)
  • Initialize() method reports that current encoder value is now 0 (Desired, but unexpected given failure observed in step 2)
  • First time that IsFinished() is called, it reports that the current encoder value is 0 (OK)
  • Drive base moves for total distance of 1 meter (OK)

4. Trigger DriveForDistance command again with distance of 1 meter.

• Expected results:
  • Initialize() method should report success on resetting encoder
  • Initialize() method should report that current encoder value (assigned to start) is 0
  • First time that IsFinished() is called, it should report that the current encoder value is 0
  • Drive base should move for total distance of 1 meter
• Action results:
  • Initialize() method reports success on resetting encoder (OK)
  • Initialize() method reports that current encoder value is 1 meter (UNEXPECTED)
  • First time that IsFinished() is called, it reports that the current encoder value is 0 (INCONSISTENT WITH EARLIER RESULT)
  • Drive base moves for total distance of 2 meters (FAILURE)

Theory

From the behavior exhibited, we believe that the call to SetPosition() is probably either:
a. effectively scheduling an update to be applied to the encoder in the future (e.g., before the command is triggered), but not applying it immediately, or
b. updating the encoder’s live value, but not updating a cached value being returned from the call to GetPosition().

Additional comments

If this is the intended behavior, then we would ask that the documentation for the Spark Max encoder be updated in order to clearly reflect this, particularly since it is less than fully intuitive.

[smcmahon]

February 4 / Gateway HS / Monroeville PA
Software team summary

Things accomplished:

• Isabelle
  • Continued to Work on the next programming project
• Rylie
  • Downloaded Programming Tools
  • Began populating a Toy Sample Command
• Josh
  • Transferred Mae Code to 2023 Tools
  • Began Debugging the code for changes between tool versions
  • Issued a portion of basic autonomous commands to create
• Ethan
  • Tested Fail Cases For Driving At Power For Meters
  • Tested Fail Cases For Turn At Power For Degrees
  • Began Fine Tuning Drive At Power For Meters Command
  • Began Fine Tuning Turn At Power For Degrees
  • Issued a portion of basic autonomous commands to create
• Matthew
  • Finished Fine Tuning Self Balancing Command
  • Created and Populated Command Drive Until Angle Change
  • Implemented A Sequence Command: Drive and Self Balance
  • Reimaged RoboRio 2023
  • Issued a portion of basic autonomous commands to create
  • Created and Populated assigned autonomous commands
    • Driver Station 2 Both Sides
      • Get Out and Balance
  • Created a Autonomous Chooser on Smart Dashboard

Future Plans

• Populate remaining portions of basic autonomous commands
• Create multiple Dropdown Boxes in Autonomous For Easier Readability
• Begin experimenting with April Tags and Subsequent Robot Movement