Our Robot

This year our process of designing our robot has been very thought out. We spent almost two weeks designing, planning, and analyzing every game’s strategic aspect. Our robot is designed with efficiency in mind and minimizes time spent intaking and out-taking. Our intake is 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 accomplish this efficiency with compliant wheels on flexible mounts that pull the cone into a slot in the middle of the robot. Our outtake mechanism picks up the cone from inside the robot and has a chain-driven flipping bar that lets us deliver on the other side from the intake. A servo allows for a “wrist-like” movement and lets us orient our cone in any way. Our drivetrain has 4 Omni wheels and is powered by vertical motors that allow for maximum space efficiency.

Our 2022-2023 Season Process

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 2023