Our Robot

Our 2023-2024 Engineering Process

Our process is called Metamorphosis and has been integral to our success. It is a 7-stage process that allows us to create a robot that evolves as the season progresses. Metamorphosis is an evolutionary process- changes are constantly being made to find the best possible design solution to all functional parts of the robot.

Stage 1 is Brainstorming. During this stage, our entire team collaborates about what we are trying to accomplish. Every member offers their input and presents ideas.  With full participation, consensus reached is the best possible solution.

Stage 2 is Prototyping.  In this stage, we make a proof of concept for the ideas born during brainstorming. We use cardboard, lexan, and hot glue to prototype the design. If the design doesn’t work in this step, we go back to brainstorming. If it does work, we start 3D Design. We CAD using SolidWorks and design the mechanism the way we expect it to look in the finished robot. Often times we create custom parts with our 3D printer to tie everything together. This stage acts as an “instruction manual” for our robot. We also run simulations and test stress levels to validate the design is durable. After we finish designing it, we start Building, finally putting the robot together. After the robot is built, we start Testing to see how the mechanism is working. This stage couples hardware and software as we use basic software to test motors and servos. Next stage is Analysis. This is where we discuss the effectiveness of the mechanism. We look for weaknesses and strengths in the design, asking ourselves, “How can we improve?” If the mechanism doesn’t work, we cycle back to brainstorming and restart the process. Last is Modify, where we edit anything we think might be beneficial. After this, we cycle the last 3 steps over and over: testing the changes, analyzing the effectiveness, and implementing improvements.

Meet Desperado

Our 2022-2023 Season Process

Our robot was designed with efficiency in mind and minimizes time spent intaking and out-taking. Our intake was a pass-through intake instead of a claw so we can get in and out of the terminal very quickly and not be in the way of teammates. We accomplished this efficiency with compliant wheels on flexible mounts that pull the cone into a slot in the middle of the robot. Our outtake mechanism picked up the cone from inside the robot and had a chain-driven flipping bar that lets us deliver on the other side from the intake. A servo allowed for a “wrist-like” movement and lets us orient our cone in any way. Our drivetrain had 4 Omni wheels and was powered by vertical motors that allow for maximum space efficiency.

Process

  • September

    Design Phase

    We are working meticulously to formulate the best possible combination of robot components to suit the game. We have been strategizing, running through virtual matches to try different scoring combinations, and brainstorming different ways to score efficiently.

  • September

    Sponsorships

    We worked diligently all month to draft and publish a sponsorship document, business cards, and this website to attract and inform potential sponsors by reaching out to several corporations and going to AT&T Stadium in Dallas for an event in which hundreds of companies were represented.

    September

  • October

    Prototypes and Construction

    This month, we have been working tirelessly to draft and finalize our robot’s design… for now. We started off with a basic chassis and worked up from there. Using CAD to model the robot, we know what we need and what it should look like. We then CNC-ed Lexan and made a prototype of the chassis and then moved to aluminum.

  • October

    Software and Calibration

    This month, we were able to begin programming the robot. We started the calibration process in Roadrunner, however, we faced obstacles with the robot’s unfinished state, so we tested our webcam’s program to scan the signal sleeve accurately and consistently. We also began programming the Tele-Op program for the chassis.

    October

  • November

    Marketing

    Our marketing department worked diligently to put together our 2023 Rookie Invitational Event! We also spent time formatting our engineering portfolio and creating the cover page and template. We also reached out to several potential sponsors and are excited to partner with some amazing companies this year!

  • November

    Software Development

    The software department labored away this month calibrating Roadrunner for our robot, although not perfect, and tuning our Auto Paths to score three cones initially. However, as our calibration still needs work, we had to cut down some time and now score two cycles and store another for the beginning of TeleOp.

    November

  • December

    Software Tuning

    Despite Winter Break, we tirelessly spent countless hours up at the lab grinding away at the Autonomous path to finalize it for Meet 3. An unhealthy amount of blood, sweat, tears, and time were spent dialing in the Auto as we re-tuned Roadrunner to optimize it for the new hardware changes and began experimenting with splines and eliminating or shortening sleep commands to save as much time as possible for extra cycles.

  • January

    Hardware

    The hardware team redesigned the claw mechanism of the robot for more elegant and effective results. We also redesigned the intake for a faster, more accurate delivery into the robot. We faced many obstacles such as limited space, broken wires, faulty parts, and lots of frustration, but overcame them in the final stretch before the tournament, leaving just enough time to program.

    January

  • February

    Software Re-Design

    We began the year using Roadrunner to try to be as accurate and consistent as possible in auto but realized that, while it was accurate, it had pauses between drives that added up to limit the number of cycles we could do to around three. Once we realized this, e abandoned Roadrunner and began programming our own version of Roadrunner. While we were at it, we split the auto into almost thirty different “modules” that isolated the hardware map and restricted what programs had access to what motors, servos, and sensors. We organized our modules based on function. For example, the forces sensors had their own program as did the lift, claw, wrist, driving, etc. We also used this for our stage-switching pipeline for the camera and various drive functions such as arcing, turning, etc. This allowed us to largely lessen, if not eliminate, the pauses between drives and gain extra time to score.

  • February

    Marketing Enhancements

    Our marketing team came together to make a number of improvements, building upon what we had. From designing new ideas for the side plate to making graphics for the engineering notebook, we’ve worked tirelessly to make sure we present our best! We incorporated new designs into our notebook to make it aesthetic while still maintaining its functionality and expressing all that we want to convey to the judges. We worked on our website simultaneously to convey messages similar to the notebook among others that we didn’t have enough room for in the notebook.

    February

Software

Our MethodTestProgram, used to systematically test and log the results of every one of our methods to effectively maximize our productivity.

We combine individual methods into larger ones like this to run several functions of our robot simultaneously while also providing options by passing in variables to determine which position we run to.

We isolate a certain aspect of our robot based on our needs in order to isolate errors and expedite the debugging process, passing variables into these smaller ones to run the motors based on certain commands.

We use a stage switching pipeline to be able to use the same method to run three functions of the camera. It’s a switch-case statement that determines whether to scan the cone’s color, search for the calibrated color, or read the QR code on our signal sleeve to determine which of the three parking zones to end the autonomous period in.

We pass our hardware map into its respective methods so that the only methods that need access to anything have said access. This is one way we isolate errors by keeping outside methods from changing any values of other features.

This is a split resistor circuit that returns zero volts as long as the force sensor is not in contact with anything else because we are reading the voltage between the two resistors (that means we basically read the voltage of the second half of the circuit). The first resistor, when not pressed, has a very high resistance, letting almost none through to be read. However, once it is pressed, the resistance lowers and the output voltage rises. We have two of these on our robot, one on our claw, and the other on our alignment arm used in auto to score the cones consistently. When the force sensor on our claw is pressed, the claw automatically closes as long as our lift is in the scoring position and the force sensor on our auto alignment arm is used to tell us when we are ready to drop the cone in auto.

LightSaders Robotics, St. Michael's Catholic School. Copyright 2024