3405 (The ALChemists) - 2023 Build Thread

The ALChemists are excited to be joining the #openalliance in 2023! We are joining to keep a log of all the ideas and models we are currently working on and a blog of all our adventures in the fantastic world of FIRST Robotics!

Team 3405’s Quick Links

2023 Events

  • Utah Regional (Week 1; 3/2 - 3/4)

History
The ALChemists were founded as the Golden Eaglebots at Maple Mountain High School in 2010. They won the Utah Regional their rookie year and competed at the FRC Nationals in Atlanta that same year. The team moved locations to the Advanced Learning Center in 2016 and adopted the name “ALChemists.” The team has competed yearly since 2010 (except for 2016) and is excited to be competing alongside all of you in 2023!

2 Likes

Week 1 Update

Kickoff Recap (1/7)

The ALChemists were excited to join in the global excitement over the release of a new FRC game concept this past Saturday. Per team tradition, the ALChemists were treated to a wonderful pancake breakfast while eagerly counting down the minutes to Kickoff. After the game had been revealed, team Mentors and Coaches met with the parents to discuss the agenda for this season. Because we have a shorter build season than in previous years (Utah Regional, Week 1), it was crucial to establish a more defined schedule to meet our deadlines. Last year, the team struggled to make it to our local event on time and arrived late on Check-In day. We have prioritized completing all necessary parts of the bot by February 11, as outlined by our team’s Gantt Chart (more on that later). This will allow a grace period of approximately three weeks to make adjustments or revisions to the robot. In addition, this period will also allow us to dedicate time to training a Drive Team and Scout Team for competition.

Engineering

The Engineering group primarily discussed how to design a device that would pick up cones and cubes. We felt an arm mechanism would allow us more flexibility to pick up and maneuver cones, particularly to the middle and upper nodes of the grid. Our team liked the idea of designing a hybrid device that could pick up a cone (in nearly any orientation) or cubes, so we designed a prototype device that we hope to improve upon in future iterations.

Intake Arm, Iteration 1

Our first design consisted of a 2x1 grid of inversed tennis ball halves on wooden dowels attached to a wooden board. Our hope with this iteration was to create a gripping device that could be adjusted with pneumatics to pick up the desired game piece. A shortcoming we quickly noticed with this version was that to move a cone into an upright position, we would have to flex the gripping device multiple times so that it would slowly fall into the correct position in between the tennis balls. This could cost valuable time on the playing field and was a component we immediately sought to improve upon.

Video of the Arm (v1.0) in action: YouTube Video

Picture of the Arm (v1.0) being tested:

Intake Arm, Iteration 2

The second iteration of our intake arm was much like the first. However, we replaced the wooden dowels holding the inverted tennis balls with a stack of ball bearings and threaded a screw through the whole stack to hold the tennis ball in place. Adding the bearings would prevent the Drive Team from flexing the grabbing device multiple times to bring the cone into an upright position. This left the job of righting the cone entirely to gravity, which we found worked much faster (and more reliably) than our previous iteration. We also tested grabbing the cone from a variety of positions, including on its side (facing to the left or right), on its side (facing away from or towards the arm), right side up, and upside down (leaning against a wall or sloped surface). In each instance, the cone successfully navigated to an upwards position without any force or influence from the user.

Drivetrain

Our team has routinely used the West Coast Drive in our competition robots in the last few years. The two-speed gearbox allows us to move quickly across the field in high gear and also provides precision and lots of defensive power in low gear. We have decided to use this drive layout again this year because we have become so familiar with the system that we can produce effective results in a shorter time period. We toyed with the idea of implementing a Swerve Drive, but did not feel we had the time or funds to learn a new system in time for the competition. This week, the Engineering team conducted a Dimensional Analysis of our planned intake arm to draw the final design for our Drivetrain, which we plan to fully machine and build by next week’s meeting.

Programming

This week, the Programming team spent a great deal of time updating all the software applications to their respective 2023 versions. When not updating software, they worked on updating and simplifying our website, which has needed some organization for a few years. They also began researching and building an Autonomous Balancing Method using a CTRE Pigeon 2.0.

A team of rogue Engineers also joined the Programming team in building a wooden replica of the Charge Station this week, which we will complete tomorrow. This charge station will allow us to test our autonomous balancing methods and (hopefully) get them smoothed out in no time. In the future, we will include notable segments of code in this section, but we don’t have much to update on other than the previously mentioned items.

Scheduling

In the past, the ALChemists have struggled to maintain a schedule. To combat this, the team leadership drafted a Gantt Chart to keep us on track this year. So far, the team is ahead of schedule and operating quicker than in years past.

5 Likes

Week 2 Update 1

Week 2 Summary

This week, the ALChemists were able to complete the construction of a practice Charge Station and Scoring Grid. These elements will be useful for testing our autonomous routines as well as developing an endgame strategy. They were also able to conduct dimensional analysis for our drivetrain and intake device. Our programming team tested a “Robot Assist” to get three robots on the Charge Station for endgame, even a robot with three-inch wheels.

Engineering

Our Engineering team has been working extremely hard this week! They were able to complete a wooden copy of the Charge Station and Scoring Grid. In addition, they were able to come up with a concept for our Intake Arm and conduct dimensional analysis to begin manufacturing our Drivetrain.

Intake Arm, Iteration 2
Last week, we mentioned that we had needed to revise our initial concept for a universal intake device. Our device, which consists of a rotatable arm and a mechanical “wrist”, will feature two pneumatic pistons that will clamp in and out to grasp both game pieces. The “fingers” will consist of molded silicon for extra grip, and will be placed on a bearing mount so that a cone placed in our device will automatically right itself due to gravity. See the video link below for a demonstration: https://youtube.com/shorts/Jdxn5UInLaA?feature=share

Drivetrain
Our drive base this year will be a West Coast Drive, which is a system we have utilized for the past three years and have come to love. We decided to rebuild one of our old two-speed gearboxes, which meant cleaning the motor grease off of the parts we wanted to reuse. This cleaning procedure also allowed us to take inventory of which gears needed replacement and make a decision on whether or not we want to possibly change our gear ratio.

Programming

This week, the programming team used our newly-constructed Charge Station to develop autonomous and endgame strategies. We conducted a test of a “Robot Assist” to ensure that three robots could fit on the Charge Station during endgame. In addition, we updated all the firmware for our robot parts.

Autonomous Balancing
Our programming team came up with a series of ideas and a way to test each individual step of the process for Auto balancing. Two of them are listed in the image below. In addition to these steps, we discussed the possibility of using a PID Controller for our Auto Routine if these two methods do not work.

Endgame “Robot Assist”
Our team used three robots to test how difficult it is to get three robots on the charge station at a time for the endgame period. We discovered that if we use a robot with a heavier weight to push the charge station downwards, the other two robots (including one that had three-inch wheels) will be able to climb onto the station. The robot pushing down the station had to be right on the edge of the station in order for this test to work. We timed this routine, which took a total of 28 seconds to complete. This routine would be much faster normally, considering we drove slowly onto the charge station to ensure everything would work. See the video here: https://youtube.com/shorts/UUxBaGdtOZc?feature=share

9 Likes

That’s a great video to capture the process - thanks for sharing!

Going to be tough to convince me that 3 robots is worth the time/risk if you’re able to get the auto dock/engage points. I imagine we’ll see a lot more success from alliances having 2 robot docks and engage and then maybe one parked

Totally agree. Getting three robots on was very time consuming and took a lot more communication and effort than will probably be available at the actual event, given the noise in that kind of environment. It was still helpful to know it is possible, but would require teams to really consider the width of each robot and how much time they want to give up scoring on the grid versus on the Charge Station.

1 Like

Week 3 Update

This week, the team was able to begin finalizing our autonomous balancing routine and also finalize our CAD Drawings of the Arm Intake! We are rapidly approaching the Utah Regional (T-Minus 4 Weeks!) and still have a lot of things to work on. This week’s update involves a lot of programming, so we will try to post code segments with thorough explanation as we go. Our working repository of code for this year can be found on our GitHub Page. Best of luck to you all in Week 4!

Engineering

This week, the Engineering team worked on finalizing CAD drawings of various subsystems of our robot to be machined this week. Items included:

  • West Coast Drive frame
  • Belly Pan
  • 3-Stage Extendable Scoring Arm
  • Intake Device (To be attached to the Scoring Arm)

Pictures (and CAD files) will be added this week as soon as I get back to the shop on Monday.

Programming

This week, the Programming Team divided their efforts to focus on two main functions: Auto Balancing and the Scoring Arm. We utilized a Pigeon 2.0 IMU to assist in the balancing routine, and a SparkMAX Controller to control our scoring arm.

Our autonomous routine will require a bit more revision, but for now our test robot was relatively consistent at getting onto the Charge Station and balancing it. A video can be found here. Our working code can be found here.

Week 4 Update

Wow, what a week it has been! The ALChemists have been busy brewing up some new prototypes in preparation for our official build day this Saturday! Traditionally, our team will build multiple iterations of prototypes before we begin assembling any final products. This type of process lends itself well to simpler games, considering the tight schedule we have this year to prepare for the Utah Regional on March 2. Engineering has been busy drawing up designs for a large batch of machined parts that we will begin manufacturing this week. Our gameplan was initially to have all the prototypes completed by today, which we have successfully achieved. Programming has been busy perfecting an auto-balancing routine, as well as programming our intake arm. The supply shortages this year have been especially hard on the Programming team, as they have had to reconfigure some older parts to work like new again. They are thrilled with the progress each member is making and come to each meeting with brand new ideas that work splendidly.

Our last week’s post was a little bit empty as far as updates are concerned: our Head Coach had to go out of town on a business trip, and our facilities manager requested we not use any of the power tools in his absence. We kept busy organizing the shop, drawing up CAD files, and making buttons to give away at competitions (237, to be exact!). The programming team built a program that used a Pigeon 2.0 to recognize when the robot was on a slope, and set the idleMode of its Falcon500s to Brake Mode. This sort of function would be useful in the Autonomous period when the robot is trying to balance, but fails. This would keep the robot falling slowly to keep it engaged with the Charge Station for as long as possible.

Without further ado, let’s jump into this week’s updates!

Engineering

As mentioned previously, the Engineering team worked on completing the prototypes for our intake arm and intake “clamp”.

“Clamp” Photos, Descriptions, Videos

Clamp grabbing a cube:

Clamp grabbing a cone:

Videos of the clamp in action can be found below:
Cone Test
Cube Test
Clamp Demonstration (No Game Pieces)

Arm Images, Descriptions, Videos

The “clamp” device will attach to the end of a three-stage extender arm (Thrifty Telescoping Tube from The Thrifty Bot). SparkMAX Controllers use the WPI LIbrary’s built-in PIDController function to set to certain predefined positions. So far, the arm is still a little bit buggy, but is something that is being improved each day.

The Arm (beta):

You can find a video of what we’re working with here.

Programming

This week, the Programming team worked on the Auto-balancing feature and setting the Intake Arm to certain positions. Both programs still need some work, but are close to becoming the actual software for our team to use this year.

Autonomous Balancing

Our autonomous balancing routine is largely tuned to the scenario in which there is only one robot attempting to balance on the Charge Station during Auto. Our program utilizes the Pitch readings from a Pigeon 2.0 to move forward until detecting a change in pitch above a certain threshold. Once there, we shift into Low Gear and move forward until the Pitch readings return within a certain threshold. Once there, we have a timed function that moves the motors backwards for .15 seconds and sets the motors to Brake Mode to prevent further movement. In each of our tests, we were able to constently place the robot’s center wheel near the center of the platform.

Our entire Autonomous Routine consists of a Sequential Command Group that takes different commands and runs them in sequence. Our very first command drives forward until a change in pitch is detected above a certain threshold (7 Degrees in this case):

public class BeginBalance extends CommandBase {
  private boolean isFinished = false;
  /** Creates a new DriveForward. */
  public BeginBalance() {
    // Use addRequirements() here to declare subsystem dependencies.
    addRequirements(RobotContainer.m_drive); // Add the DriveTrain Subsystem as a requirement
  }

  // Called when the command is initially scheduled.
  @Override
  public void initialize() {
  }

  // Called every time the scheduler runs while the command is scheduled.
  @Override
  public void execute() {
    if (!RobotContainer.m_drive.onSlope()){
    RobotContainer.m_drive.tankDriveVolts(Constants.AUTOSPEED, Constants.AUTOSPEED); // Drive forward at 4 volts
    return;
    }
    if (RobotContainer.m_drive.onSlope()){
      RobotContainer.m_drive.arcadeDrive(0,0);
      isFinished = true;
      return;
    }
  }

  // Called once the command ends or is interrupted.
  @Override
  public void end(boolean interrupted) {
    isFinished = true;
    RobotContainer.m_drive.tankDriveVolts(0, 0); // Stop the robot when the command ends
  }

  // Returns true when the command should end.
  @Override
  public boolean isFinished() {
    return isFinished;
  }
}

For reference, our onSlope() function in the Drivetrain folder of our 2023 Test Bot Code returns true when the pitch is above or below a negative pitch (-7) and its absolute value (7). The pitch is continuously returned using a NetworkTableEntry in the periodic function of the Drivetrain subsystem:

public boolean onSlope() {
    return pitchVal < Constants.MINPITCH || pitchVal > Constants.MAXPITCH;
  }

Once the robot has detected this change in pitch and stopped movement, it shifts to Low Gear and drives forward until the pitch is within a certain threshold again (-7 to 7). Note that we have commented out some code in the execute function. This will allow us to test an alternative to a timed function later:

public class Balance extends CommandBase {
  boolean isFinished = false;
  /** Creates a new CheckBalance. */
  public Balance() {
    // Use addRequirements() here to declare subsystem dependencies.
    addRequirements(RobotContainer.m_drive);
  }

  // Called when the command is initially scheduled.
  @Override
  public void initialize() {}

  // Called every time the scheduler runs while the command is scheduled.
  @Override
  public void execute() {
    if (RobotContainer.m_drive.pitchVal < Constants.MINBALANCEPITCH){
      RobotContainer.m_drive.tankDriveVolts(Constants.AUTOBALANCESPEED, Constants.AUTOBALANCESPEED); // Drive forward
      isFinished = false;
      return;
      } 
    if (RobotContainer.m_drive.pitchVal > Constants.MINBALANCEPITCH || RobotContainer.m_drive.pitchVal < Constants.MAXBALANCEPITCH){
      RobotContainer.m_drive.tankDriveVolts(0,0);
      isFinished = true;
      return;
    } 
    // else if (RobotContainer.m_drive.pitchVal > Constants.MAXBALANCEPITCH){
    //   RobotContainer.m_drive.tankDriveVolts(-Constants.AUTOBALANCESPEED, -Constants.AUTOBALANCESPEED); // Drive backward if necessary
    //   isFinished = false;
    //   return;
    // }
  }

  // Called once the command ends or is interrupted.
  @Override
  public void end(boolean interrupted) {
    isFinished = false;
    RobotContainer.m_drive.tankDriveVolts(0, 0); // Stop the robot when the command ends
  }

  // Returns true when the command should end.
  @Override
  public boolean isFinished() {
    return isFinished;
  }
}

Our final timed function simply reverses the motors for 0.15 seconds and sets the drive motors to Brake Mode. This will stop all forward momentum and prevent the robot from coasting off the other side of the Charge Station:

public class TimedBalance extends CommandBase {
  Timer t;
  /** Creates a new Balance. */
  public TimedBalance() {
    // Use addRequirements() here to declare subsystem dependencies.
    addRequirements(RobotContainer.m_drive);
  }

  // Called when the command is initially scheduled.
  @Override
  public void initialize() {
    t = new Timer();
    t.start();
  }

  // Called every time the scheduler runs while the command is scheduled.
  @Override
  public void execute() {
    RobotContainer.m_drive.tankDriveVolts(-2,-2);
  }

  // Called once the command ends or is interrupted.
  @Override
  public void end(boolean interrupted) {
    t.stop();
  }

  // Returns true when the command should end.
  @Override
  public boolean isFinished() {
    return t.hasElapsed(.15);
  }
}

Ideally, our robot would detect if it has fallen outside of the pitch thresholds once on the Charge Station. We will probably implement a timed function to run after the entire sequence that checks to see if the robot has begun falling off the Charge Station and correct it if necessary.

The final SequentialCommandGroup looks something like this:

public class AutoBalance extends SequentialCommandGroup {
  public AutoBalance() {
    addCommands(new BeginBalance(), RobotContainer.m_drive.ShiftGears(), new Balance(), new TimedBalance(), new setBrake());
  }
}

Arm Positions

We are working with the PIDController function that comes with the SparkMAX Controller’s library of code. The program is continually in the works and will be heavily improved upon during the week.

Looking Forward to Week 5

This week, our team will begin manufacturing the final pieces to construct our 2023 bot! We are excited to begin practicing with it over the next week and half. It will be a great addition to our team and we are eagerly counting down the days to the Utah Regional! As always, best of luck to each team working to complete their bot!

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.