The Game

Over Under Rules & Overview

VEX Over Under puts two teams, each with two robots, on a 12’x12’ field, competing to score the most points. The field includes 60 triballs–4 as preloads, 44 as match loads, split between the teams, and 12 beginning on the field. It also contains two elevation bars, four matchload goals, and two goals, all split between the teams. The game is divided into the “Autonomous Period” and the “Driver Controlled Period”. Points scored during the autonomous period carry over to the driver control period.

During the autonomous period, which lasts 45 seconds, points are awarded at round completion if specific requirements are met. A point is awarded if a team scores an alliance triball and contacts the elevation bar. A bonus of 8 points is awarded to the team that scored the most at the end of the period.

The driver-controlled period, lasting 75 seconds, has the team trying to outscore their opponent in multiple ways. Five points are awarded for each triball scored in a goal, and two points are awarded for each triball in the opponent’s zone. Finally, points (up to 20) are awarded for each of the four tiers of elevation.

Initial Field Analysis

Center Bar, Elevation Bar and Match loading

• The field features two opposing scoring zones separated by a roughly 3” tall bar, each with two zones for teams to match load.

• The match loading zones are separated from the field by a 30” long 2.5” diameter bar, from which bots cannot cross but can intake triballs.

• Scoring zones are connected by two gaps under the elevation bars, which are 11.63” tall. To access both sides of the field, a robot must be under this height or capable of driving over the 3” bar.

• White tape separates the left and right sides of the field and marks the area that robots can access during the autonomous period.

• Robots that do not climb are not considered while scoring the climb.

• Robots cannot contact robots touching the ground or the golden bar cap on the vertical elevation bar.

Triball Details

• Triballs are a constant-diameter pyramid-like shape with rounded sides and a rigid plastic exterior that weighs approximately 110 grams.

• Triballs are scored when two of the four corners are under the outermost part of the net, as shown to the right.

• During skills, the team’s alliance balls can be placed at any point on the field if unscored.

Initial Strategy

Once we completed the initial analysis of the game’s field elements and got a feel for how to get practical scoring underway, the team had some meetings to discuss potential strategies. The main factors affecting said strategies were the game’s autonomous phase and the triballs’ movement.

Early on in the season, it was desired to get an excellent autonomous strategy to get ahead of opponents once driver control started. Since this year’s game’s scoring elements mostly have to be introduced into the game as individual match loads, it was determined that a large portion of those triballs should be introduced during the autonomous phase of the game so that the bots can focus on other objectives during driver control. There are 22 triballs for each team as match loads, so ideally, above half of that will be depleted and scored during the autonomous phase.

Another deciding factor for our bots was how moving triballs would be done. From what the field looks like, the two viable options are through the air over the middle PVC barrier and pushing it through the outside beside the elevation bars. So the team initially went with a puncher shooting design to shoot the triballs from one zone to another, effectively going over the middle barrier. This will be complemented with one of the bots having a catcher mechanism, ideally catching every triball in the offensive zone shot from the shooter bot and out-taking the triball in the net to score top points. On top of that, our robots will have some side wings that act as a plow to push triballs on the outside towards the goal. This is to give variability to our strategy in case one method becomes more favourable. Other teams have proven these strategies viable with their mechanisms, but the team hopes to do so better.

24in robot

Competition Analysis

Season Goals

Going into this season, our goal was to expose a new set of creative members to all aspects of VEX, and part of this meant starting with a relatively simple design. Hosting QRC and having the team structured with many smaller sub-teams significantly helped with member engagement. It also significantly helped with the progress of the robots, allowing for more iteration and, therefore, more consistent designs. The lack of experience with VEX proved to be a benefit as the designs for the world’s bots are very original and take advantage of mechanisms and coding that rarely see use.

Discuss our world goals (ambitious) vs competition goals (ease of implementation) with a decision matrix.

Scouting Process

The scouting side of strategy is critical to the team’s success, as it gives our drive team a lot of knowledge of their opponents before our matches. As they get played, scouts will use the scouting sheet as an aide-mémoire to build strategies against their corresponding team and provide strategy leads/drive team members a visual representation of robot routes/functions, providing a deeper explanation of the opponent’s behaviour. The scouting sheet was made with a vision of including most of the questions the drive team would have regarding strategy for scouts to think about while watching matches. For example, the figures below show the scouting sheet, followed by two examples of how one of our scouts drew out an opponent team’s autonomous routes for both of their robots.

QRC Analysis & Goals

For many reasons, the Queen’s Robotics Cup challenged the strategy aspect of the team’s functionality. The scouting sheets were made, but as the cup was hosted at our university, many team members attended, and since many of them wanted to be more involved with the team, they were scouts. It was to the point that there were twenty scouts for only five teams at the competition, and it was too much to process in such a short time. Multiple other factors include there wasn’t any primary constructive system in place for scouting to be communicated to the drive team, and given it was a small tournament, there wasn’t much time between matches, so the drive team prioritized the robot’s maintenance with our pit crew. Another thing to consider is that the early stage of the season meant our robots were far from perfect, and they faced many challenges during matches, like the intakes not working, some pneumatic functions failing, our autonomous strategy having some malfunctions, etc. It made it hard to visualize a concrete strategy without our robots giving us a taste of our capabilities.

To this point in this year’s game, there were few defined strategies to watch out for early in the season, meaning we didn’t have a good idea of what our strategy had to accomplish. Paired with the technical malfunctions, our biggest priority at QRC became learning how teams would play and what we could do for future competitions.

Takeaways:

1. Have a bot under 11” to transfer triballs under the elevation bar and stop other teams from doing the same.

2. Playing defensively makes scoring exponentially harder for other teams and gives your team more opportunities. It can be accomplished with more robust drivetrains and bigger wings.

3. Clearing your zone of triballs quickly allows your defensive bot to match load and put more pressure on their team’s defence.

4. There was no need to commit more resources to the climb; having an A climb would keep us competitive.

The most significant oversight was how teams would use the gap under the elevation bar to funnel match loads into the scoring zone consistently. A bot under 11” tall allows for a much more consistent method of transferring match loads, particularly in earlier competitions with less advanced robots. Knowing when to match load and being able to play consistent defence was also crucial to success in this competition. We learned that most strategies to this point revolved around having a bot that could score match loads in the offensive zone.

West Virginia Analysis & Goals

Compared to QRC, the West Virginia competition went a lot better in every aspect. There were lots of conversations about what to improve in terms of strategy and scouting for this competition, including a new member of the drive team working with the strategy lead to get a constructive and clear plan for the drive team’s comprehension. Thankfully, there were also longer times between matches compared to QRC, so the drive team had some time before every one of our matches to have a little huddle to make a strategy. With only seven scouts this time, communication wasn’t cluttered or interrupted. Everyone knew who to talk to and,

Hardware/Mechanical Overview

• Fit within the volume specified (15” × 15” and 24” × 24”)

• Use a maximum of eight VEX motors

• Maneuver quickly and be agile in a game setting

• Push opponents around and be strong enough to prevent being pushed

• Allow space and connection points for the other subsystems (catcher, shooter, etc.)

Pontoons: With the initial decision of a tank drive, including pontoons as part of the frame seemed feasible for both the strength and rigidity of the drivetrain. These pontoons house the wheels as well as the gears connected to the motors to provide shielding from any bots or other obstacles. They consist of four identical trapezoidal aluminum plates, which are connected in parallel in pairs, each making up one pontoon (two for each side of the bot). They have all the necessary holes to connect the driving axles and the gear axles to drive the bots. Still, they also hold some of the essential connection points of the drivetrain to hold it together and to attach other elements of the robot. To hold the pairs of plates together, thick and rigid metal blocks are situated between the plates at the front and back.

Motor Mounts: On the inside face of each pontoon are two sets of motor mounts. These motor mounts hold two motors together and must match the motor + casings’ profile. To do this, measurements from the motors and casings with all necessary dimensions were taken so the mounts could fit within the motor profile with minimal room for the motor to move around. The design also made sure that there were the necessary holes such that the motors could be directly attached to the mounts and the mounts could be attached to the pontoons, both with screws.

Geartrain: A geartrain, or more technically, a transmission, couples motors together and outputs torque to every wheel on the pontoon.

Cross Braces: Cross braces were used to connect the pontoons and hold the various added subsystems on top and behind the drivetrain. Because they were the anchor to almost the whole robot, they were designed to be strong and allow for other subsystems to be attached.

Design Process: The initial design considered discussing and weighing the different drivetrain types regarding maneuverability, speed and other factors (see WEM below). It was decided that the tank drive was best for the first half of the year as it was relatively simple but powerful, allowing us to push other bots around. Many iterations were done throughout the design and CAD process, changing up some of the parts above. Once the CAD and manufacturing were done, we tested alongside some software teams to test our drivetrain and their code simultaneously. We used the QRC competition as an opportunity to test and understand the flaws of the design. Using the main issues we spotted during this competition and in preparation for Worlds, the drivetrain team split up to work on the 24” tank drive and the 15” drivetrain. Using what we learned, many iterations were done to allow our robots to be more agile and able to cross the center bar.

Idea Generation

All standard drivetrain styles were considered for the robots. These basic designs have been vastly explored in previous competitions. The possible designs are as follows.

Tank Drive: This design involves a forward-facing omni wheel in each corner and a traction wheel in the middle. Eight motors, four per side, would drive the wheels. The design generates a lot of torque but cannot strafe (move sideways). However, the design’s basis makes it difficult for opposing bots to push it from the side.

Solution Selection

The generated concepts were then evaluated using a weighted evaluation matrix, which can be found below. The following criteria were weighted based on their criticality to the design’s functionality.

• Speed: This criterion looks at the speed that the drivetrain can produce. This category is important because it will dictate how quickly the drivers can react to the other team during the match. A quick reaction to the other team will optimize the robot’s ability to score and defend, which is why it receives a weight of 4.

• Power: Power is the evaluation of the drivetrain’s ability to push other robots. This can be estimated through the torque generated by the wheels. This had the highest weight as it was determined that it was very important that our robot would be able to overpower other robots and also make it over the center bar.

• Strafe: Strafing is the drivetrain’s ability to strafe back and forth. It is low-weight because it is less important than maneuverability. Since it is not as crucial as maneuverability, it receives a weight of 2. If a drivetrain can not strafe, it gets a score of 1.

• Maneuverability: The ease with which the robot can turn. This category has a moderate weight as the robot needs to be able to maneuver precisely during matches. It also allows the drivers to react quickly to the other team; thus, it receives a weight of 3.

• Maintenance: This criterion evaluates the ease of maintenance on the drivetrain, including frequency and accessibility. This is an important category as there are many mechanisms and little time between matches, so the pit crew must be able to perform drivetrain maintenance quickly with few complications.

• Innovation: As part of our overall goal, an innovation factor was incorporated into the selection process. It evaluates the difficulty of the design and how its incorporation will set our robot apart from other teams. It is not weighed heavily because functionality is still the most critical aspect of the design.

Below is the completed evaluation matrix indicating each criterion’s scores for each design.

The tank drive was initially selected due to its high scores in power and speed. It allows our bots to push others around while being relatively maneuverable. With an easy manufacturing process and lower maintenance issues, the design was optimal for implementation in the short time frame of early competition.

However, this was re-evaluated after testing, where it was found that there were more strategic uses for having a robot that the other team couldn’t move. It was found that having two different drivetrains for the robots would be helpful. The 24” would maintain a simple tank drive to hold its ground, and the 15” would use a swerve drive, which allows it to maneuver easily. However, the swerve drive has more complicated maintenance. The x-drive was discarded because it would not reasonably be able to climb over the center bar.

Iteration

Rough Prototype: Very early in the design process of the drivetrain, within the first few meetings, a very temporary drivetrain was made so that the software teams could begin some learning and testing for their components. It consisted entirely of VEX parts, including some scrap VEX metal, old tires, and parts from previous bots. While not very strong nor effective, it taught the team some very early requirements and plans for the future drivetrains to be built. It also allowed the new members to get involved and learn how to make

as well as the cross-braces. This helps with our team and ensures that each other subteam has the space and attachment points to add their designs.

15” Swerve Drive

The 15” Swerve drive shown is an entirely new design with four replaceable drive modules that run using two motors each. The main benefits of the swerve drive include maneuverability, potential torque, and the ability to go over the bar. Implementing a swerve drive design also accomplished these tasks better than any other drive system. The main downside is designing and maintaining a working system. We aim to have these modules 3D printed to help with iteration, make it easier, and have multiple working replacements for worlds.

We aim to mount these modules to machined aluminum, similar to the 24” bot; however, if this becomes too costly, C-channel is another viable alternative.

Timeline

The timeline is colour-coded for easy comprehension. The legend is found below.

The timeline was decided upon during the first few meetings, pictured below. Any items with missing dates were at some point removed from the design.

on what we saw had worked at the competition. The best design was then determined and fully pursued for the worlds competition robots.

Idea 1 - Catapult: The design for the catapult involved connecting a slip-gear mechanism to a rotating bar with elastic bands. This design is straightforward to repair. It would also be easy to load the triballs into the mechanism. The problem with the design is that it was too big. Most of the robot would have to be dedicated to the catapult if it was pursued. The CAD for the catapult was finished in November and was mostly built. A few tests were done on the catapult, which determined it was somewhat unreliable. The speed at which it could shoot the triballs was also a problem because the motors had to gear down to produce enough torque to pull against the rubber bands.

Idea 2 - Linear Puncher: The linear puncher started being designed in October 2023. The first design had a puncher bolt with 6-10 elastic bands connected directly to a rack and pinion slip gear mechanism. Multiple iterations of the linear puncher were made before the first competition. The linear puncher was very good at consistently hitting the triballs while being extremely small. The main problem with the linear puncher is that it made intaking the balls very hard since they had to be moved overtop and around the puncher. Despite this, the linear puncher was chosen to be used in the first iteration of the robots.

The second design of the linear puncher started production after the first competition. It used constant-force springs instead of rubber bands for a more consistent shot and linear bearings on two rails to reduce friction. The slip gear was connected to a high-strength fishing line attached to a pulley and the puncher block. This design was entirely made in CAD and partially manufactured.

Idea 3 - Flywheel:

Unlike the catapult and the linear puncher, the flywheel was not fully pursued and made in CAD until after the second competition. When conceptualizing the flywheel in October, it was assumed that it needed two wheels

Repairability: This category concerns the ability to fix the shooter mechanism if/when it breaks. Repairing quickly is very important since things often break during competitions.

Below is the completed evaluation matrix indicating the scores for each design in their categories. The weights range from 1 to 10, and the scores range from 1 to 3.

The flywheel option scored the highest out of all the designs. The flywheel’s ability to shoot consistently and ease of intake made it the best design. Despite a linear puncher already being half-built, it was decided to make the flywheel instead.

Timeline

The timeline is colour-coded for easier comprehension. The legend is found below.

The timeline, pictured below, was decided upon during the first few meetings. Any items with missing dates were removed from the design.

Catcher

Executive Summary

Requirements: the catcher subteam is dedicated to creating a mechanism that can:

• Deploy within 3 seconds

• Trap launched triballs

• Deliver triballs to an outtake system

• Rotate to face the launching robot

• Retract when the driver wishes to go under the bar

Rotation mechanism: The rotation mechanism was decided upon by consensus. The method is simple, requiring one motor and using a limit switch to let the brain know when the motor has reached 90 degrees from neutral. This would allow the brain to restrict the rotation to 180 degrees so that the motors do not interfere with the outtake mechanism. The design involves a fixed 200-tooth base gear, and the motor attaches to the rotating base, where it runs a gear that connects to the base gear. This allows the motor to push the rotating base around the gear about its center.

Deployment mechanism: After evaluating three deployment mechanisms, it was concluded that the telescopic arms were the most effective. This design involves many increasingly small open cylinders. A string attaches to the top of the first cylinder, then loops around the bottom of the next one, where it fixes to the top, loops around the bottom of the next one, and so on. This results in the cylinders being pushed up when the string is pulled. It relies on gravity to retract.

Design process: The first and second iterations of the deployment mechanism were manually tested. For the first design, it was determined that the telescopic arms needed to be angled to increase the target area and prevent the ball from getting stuck between them. The next iteration was found to be functional but had some issues with balls bouncing out. The design was then iterated to catch the triballs like a soccer net, where the arms are slightly angled towards the catcher, as this would lead the triballs into the outtake more consistently. This method was tested manually before being mounted on the robot and tested with the shooter mechanism. It worked in both cases, therefore succeeding as the final design.

Idea Generation

The catcher subsystem is unlike anything anyone on the team has built. This resulted in a sizeable preliminary brainstorming and design phase. The first meeting was used to outline the subteam’s goal and, in turn, what the solution should accomplish. Every team member was tasked with researching and making a rough design of a system that could be used, which resulted in three major ideas.

Idea 1: the first proposed system drew inspiration from a car windshield wiper linkage. The preliminary idea was generated in an app called Linkage, as shown below:

• indicates that some gear ratio must exist to achieve the functionality of the design.

• Retractability: the device’s efficiency of retraction. This was weighed as a 4 as it was determined that if the device could not retract, it would impede strategies that require going under the bar and any climbing mechanism, a vital part of the game.

• Space to extension ratio: compares the space the design can take up to the amount it can extend. This category was given a weight of 2 because it is less critical to have a large catcher than it is to have a functional one, hence why it is weighed less than categories evaluating functionality.

• Reliability: the likelihood that the device will malfunction or the maintenance required to avoid a malfunction. This was weighted as moderately important, a 3, as it would be preferable not to require maintenance after every game, leaving more time for the parts that undergo more stress during each match.

• Innovation: the innovation and creativity behind the design. This was weighed the lowest but still considered, as our team strives to create innovative designs and display technical prowess in designing our robot.

Below is the completed evaluation matrix indicating the scores for each of the three designs in their categories.

Based on the evaluation matrix, the telescopic arms are the optimal design, as it was very compact, with a high potential for extension. Being able to store each cylinder within the previous means the size of the design is only defined by the largest cylinder. The shape is inherently strong with little material, with each cylinder supporting the others. It is also easily retractable and is a robot design that has not been seen before in our research. The two drawbacks of this design are the load required by the motor and the reliability. The load received a low score as while the design lacks mechanical advantage it can still function without an external gearbox. Furthermore, the design is somewhat unreliable, as any issue in the stringing could cause a malfunction.

Iteration

Deploy Mechanism: the first prototype was manually assembled and tested on November 17, 2023. The testing process involved securing the catcher to a stable base and throwing a triball with varying power. The testing showed that the telescopic arms and the base could withstand the throws, starting with an underhand and advancing to an overhand. However, the ball sometimes would get stuck behind the arms. In response, the arms were angled, and the tension in the net increased.

The second prototype was completed on January 31, 2024. It was tested the following day by manually throwing triballs, where it was found that the back angle on the net would sometimes allow the triballs to bounce out. To fix this, the design was adjusted to receive triballs similar to a soccer net where they hit the net and roll down into the receptacle.

The third iteration will be completed on March 10th, 2024 and will be tested using the actual shooting mechanism, which will be completed at roughly the same time. This will tell us if the catcher is effective at receiving the triballs from our shooter mechanism and demonstrate any possible improvements that can be made.

Base Plate: The initial design involved a 50-tooth base gear 9 inches in diameter with a hole in the middle. The arms would be mounted to the back of the base gear, which would rotate around a hollow shaft where

Timeline

The timeline is colour-coded for easier comprehension. The legend is found below.

The timeline, pictured below, was decided upon during the first few meetings and iterated through the year. Any items with missing dates were removed from the design.

• Design a mechanism capable of retrieving a ball from the match-loading zone and transporting it to the flywheel mechanism.

• Interface the design with other subsystems (such as drivetrain, flywheel and electronics)

The design must include the following features to be considered successful:

• A long, cantilevered profile that can reach into the match-loading zone when the drivetrain is at a 25-degree angle relative to the match-loading pipe. This way, the robot can propel balls toward the 15” catcher robot without positioning the drivetrain inside the match-loading zone.

• A dynamic component that can ‘grab’ stationary triballs — this requirement complies with this rule on intake match-loading: https://www.robotevents.com/VEXU/2023-2024/QA/1857

• Allow the cantilevered structure to hinge so the intakes can drive over the middle pipe.

• Actuate all rollers using only two motors.

• Most importantly: Have a high (95-100%) intake success rate so match-loading can be done consistently, i.e anti-jammable.

Design process:

• Requirements and Idea Generation: The design process began with determining the key design components and performance indicators that we considered critical to a successful intake mechanism. These elements were the basis for brainstorming, which included devising ways to achieve the above factors.

• Solution Selection: Once ideas were conceived, they were included in a WEM and ranked according to our key design components. From the WEM, the highest-scoring design was selected. Upon selecting this design, before any CAD was made, the team determined quantifiable/measurable goals for the mechanism that could later be validated to ensure design success.

• Testing and Evaluation: After the idea was selected, a prototype was designed in CAD and simulated in software, involving mathematical modelling of parameters (i.e. motor reduction requirements or beam deflection calculations). This included using collision analysis in Solidworks to determine possible sources of error before the prototyping stage. After this, the design was 3D printed and tested according to key performance indicators and iterated upon.

Idea Generation

The idea generation phase included referencing past designs (from this year and previous) of QVEX and other teams’ intakes as inspiration. Elements that seemed to work effectively were noted and compiled into a list. From this list, mechanisms that aligned well with the key performance indicators were elaborated on and built into fully functioning ideas. Here are the plausible ideas we came up with

• Idea 1: Top-roller, long-cantilevered intake actuated by two motors and a chain/sprocket system

• Idea 2: Side-roller, long cantilevered intake actuated by two motors, one per side

• Idea 3: Conveyor belt style intake

Solution Selection

The generated concepts were then evaluated through a weighted evaluation matrix, which is found below. The following criteria were weighted based on their contribution to the functionality of the design.

Criteria Description

• Repeatability: A measure of how often a ball successfully (i.e. not getting jammed) into the intake, expressed in a percentage

• Size: A measure of the mechanism’s physical form factor. Larger is worse because it typically means a heavier and less maneuverable robot.

• Effectiveness of Dynamic Component: A dynamic component (i.e., pin-jointed roller or actuated intake) can intake without human intervention. Measures reliability of the dynamic component, expressed as a percentage

• Number of Motors Used: A measure of how many motors power the mechanism.

• Ability to Get Over Middle Bar: Measure how difficult it is to create a design that will allow the robot to cross the middle bar

Below is the completed evaluation matrix indicating the scores for each design in their categories.

Problems:

• The first problem with V1 was that the belts we used were prone to slipping and often did not mesh well with the pulleys. This led us to use idlers to guarantee contact between the belt and pulleys. However, this led to a lot of friction and caused the motors to stall out after a short time.

• The second problem with V1 was that the belts would get caught in the flex-wheel material and jam the transmission. Here is an example of this:

Intake V2:

Both problems were addressed by switching to a chain+sprocket system that has less potential for slipping (and thus doesn’t need idlers, which cause unnecessary friction) and moving the transmission onto the top platform. Here is a render of the chain/sprocket system on the top of the intake.

V2 is currently being tested.

15 inch intake:

The 15-inch intake is different to account for the catcher’s space requirements. It is a top roller whose primary function is to outtake the trolls caught with the catcher.

(15 inch intake picture)

Timeline

The timeline is color-coded for easier comprehension. The legend is found below.

The timeline was decided upon during the first few meetings, pictured below. Any items with missing dates were at some point removed from the design. The process for this new intake begun in February.

Design process:

The team initially looked into two different mechanisms. The first drove up the pole, and the second was a four-bar. During the first semester, the team worked on making a driving mechanism that could drive up the pole. Although this mechanism worked well on an empty pole, the small black bump prevented it from climbing during a match. Additionally, the drive train was not correctly made to drive over the ground beams and could not mount the pole properly. The team then made a robotic arm that would lift two robots, combined with a clip mechanism to attach the two robots.

Idea Generation

Multiple climb designs were considered, as the requirements were unlike any the team had encountered before. This resulted in a large preliminary brainstorming and design phase that encompassed the majority of the season. Every team member was tasked with researching and making a rough design of a system that could be used, which resulted in four major ideas.

Idea 1 - Wheels: The idea was to drive up the pole with wheels, using the moment arm of the robot to keep it up. The mechanism was placed on the robot’s side around the center of mass.

Idea 2 - Belted arm: The lower bar has a belt going from the motors to the centre joint controlling the shaft. From there, the idea was to hoist the robot up as the shaft rotated from the motors. The issue was that the arm was not kept parallel to the bar. This caused the lower half of the arm to rotate inwards instead of the upper half of the arm rotating upwards.

Idea 4 - Four-bar arm: This idea involves rotating the arm upwards using a belt to allow the motors to remain on the drive train. The support was extended to the back of the arm to allow for a more compact design.

The next iteration was a robotic arm. This was designed to ‘hoist’ the robot up; however, it lacked control over the claw. To fix this, the third design was created by making a four-bar, allowing the robots to be hoisted upwards.

Timeline

The timeline is colour-coded for easier comprehension. The legend is found below.

The timeline, pictured below, was decided upon during the first few meetings. At some point, any items with missing dates were removed from the design.

Software Overview

• Innovation: Although this is considered less critical, the team wants to create memorable solutions and try new things that deviate from the norm, which may be beneficial.

Below is the completed evaluation matrix indicating the scores for each design in their categories.

The evaluation matrix shows that it makes sense to invest time into 3 Wheel Odometry and Drive Encoder + IMU Odometry, as these are relatively easy to implement. After we complete these, we can work on UKF localization with several sensors mounted on the robots.

Motion Controllers

Executive Summary

Requirements: the motion controllers subteam is dedicated to creating software that can:

• Control the drivetrain of the robot using motion algorithms

• Accurately and efficiently get from one point to another

Subprojects:

• Ramsete controller: Allows for feedback control when following a pre-generated path.

• PID algorithms: Can be used to control individual mechanisms, such as the drivetrain and the entire robot during the autonomous period.

• Pure Pursuit: Another method which allows the robot to follow a curve smoothly.

Solution Selection

The generated concepts were then evaluated through a weighted evaluation matrix. The following criteria were weighted based on their criticality to the robot’s functionality. These numbers were then used to decide which way

conditions and execution determined through subroutines based on controller input, data from sensors, or inter-subsystem/inter-robot communications. Subsystem states are determined on a case-by-case basis. They are entirely dependent on the components/mechanisms being encapsulated within it, except for an “idle” state in which the subsystem is not in use and, therefore, does not use hardware.

This systematic method allows subteam members to create solutions that match our selection criterion (listed below under “Solution Selection”). These solutions are typically easily adaptable to changes caused by updated designs or error fixes. Solutions are programmed in Rust using vex-rt, our Rust runtime for Vex V5 components.

Solution Selection

Subsystem controllers are designed with adaptability and must be susceptible to change to match the dynamic nature of the whole team’s work and design processes. Rather than a strict evaluation method, we use criteria to determine whether a solution fits our needs. The subsystem controller will be constantly evaluated under this criterion, and changes will be made as necessary.

Criterion:

1. The subsystem controller must completely encapsulate the hardware design. Ensure complete functionality is available within specified constraints (e.g. expected abilities, performance, range of motion, applications).

2. Multiple units/subsystems expected to operate simultaneously must not interfere with each other or result in unintended behaviour. Examples include multiple units attempting to use a shared component, multiple subsystem controllers using the same input from a V5 controller (e.g., the same button performing multiple actions), or unintended actuation during autonomous routines.

3. Conditions (data from sensors, states, etc.) must be met before components are actuated to prevent unexpected behaviour.

4. Control schemes are practical and easy for the drivers to use and understand (based on feedback from drivers)

5. The subsystem controller must be accessible enough for programming autonomous routines (based on feedback from autonomous programmers, criterion 1 must be satisfied)

The solution will be used several times during preparation. This may be in programming autonomous routines, practicing for competitions, or testing hardware or other software. The subsystem controllers subteam has many opportunities to receive feedback on the solutions to each unit from those involved in these processes, and changes are made as necessary to ensure our finalized solutions not only meet the expectations for what our robots are capable of but also streamline the preparations above and bolster our performances at each event.

Iteration

Following QRC- in which our performance didn’t meet expectations- we looked at what went wrong and how we could refine our solutions. Due to a majority of issues being mechanical and the small number of changes being made before our next competition, the changes we looked into for the individual solutions were quite small:

• New subsystem controller- Controlling the new flaps/walls on the robot’s side.

• Adjust intake/puncher controllers - If the other team shot a triball into the range of the intake’s sensors, it could interrupt our autonomous routine (failing to meet the second criterion of our solution evaluation). The intake wasn’t fully consistent and could get jammed, so behaviours were adjusted to detect if a triball was stuck in the intake and expel it.

• Autonomous programming difficulty

Overall, the subsystem controllers subteam couldn’t properly conduct tests for various scenarios that may happen in an actual match. We fell short in some areas and had some oversights. As a result, our evaluation criterion was updated to include the 5th criterion and an amendment to the 2nd criterion to include “unintended actuation during autonomous routines.”

During our competition in West Virginia, we saw massive success since we had a fantastic performance and managed to qualify for worlds. However, we still had lots to do due to the larger number of teams compared to QRC; we had many more opportunities to observe our robots in real competition to evaluate the overall