Iron Reign

# Summer Summary

11 Jul 2020
Post 1
Awards: innovate, design, and motivate

Summer Summary July 11, 2020 By Bhanaviya, Jose, Anisha, Paul, Shawn, Trey, Justin, Aaron, Ben, Mahesh, and Cooper

### Task: Prepare for the 2020-2021 Game Reveal season

Today kicked off our first meeting for the new Ultimate Goal season. Since the actual challenge for this year hasn't been released, the most we can do is to speculate what the new challenge might pose, and what we can do to prepare for it.

Recruitment

As most of our members have moved on to our Junior year, our team is now primarily upperclassmen-led. This means that within 2 years, we will need to recruit enough members to keep the team sustainable after our graduation. Unfortunately, due to the current pandemic, we will need to ensure that the Iron Reign program has the funding needed to maintain 3 teams in addition to ours. At the moment, our focus has been on keeping our own team viable over the virtual season, and this may mean that we will have to cut back on our recruitment and pick it back up closer to our senior year on the team.

Outreach

In an earlier post, we went over the plans for a new mobile learning lab. To clarify, the Mobile Tech xPansion program is owned by Big Thought, a non profit organization dedicated to education, but its outreach events are executed by Team 6832 Iron Reign. During these events, our team travels to low-income areas around the Dallas community with little access to STEM education, and teaches younger students about robotics and CAD to improve their interests in STEM which can sometimes be hard to discover without the access to a strong STEM-based education. Recently, Big Thought approved the plans for funding and expanding this program and our coach was able to purchase a new vehicle for the second, improved version of this Mobile Learning Lab. However, due to the ongoing pandemic, the plans for this vehicle have been put on temporary hold since most of our outreach events happen over the summer. As the count for COVID-19 cases in Dallas has been relatively high, there is no safe way for our team to interact with younger students and teach them hands-on robotics. As such, we will be placing our MXP outreach program on hold until the pandemic has improved (which will be, hopefully, soon).

Jose has been working on modelling various robot designs in anticipation of the upcoming season. The first is a kiwi drive, with a triangular chassis with 4 omni-directional wheels on each side of the chassis which enables movement in any direction using only three motors. The render of the robot itself is built using custom and goBilda motors. Another design was for an Inspirenc CAD Challenge, which resembled our Superman design from two seasons ago, but with a more rectangular chassis. All of these designs created over the summer will be within their own separate entry - this is merely a summary of our summer progress. Since we don't yet know what the challenge this year will look like, nor how much we would be able to meet in-person in light of COVID19, we plan on starting our build efforts with CAD designs to streamline the engineering process with an online reference in hand.

### Next Steps

One of the hardest things about this year's season will be trying to cover all our usual grounds virtually since the number of team members who can show up to in-person practices has been severly limited. In the meanwhile, we plan on using our Discord group to map out the skeleton of our new season - journal and CAD will, for the most part, progress business as usual but we'll need to rely on CAD and our planning calls much more heavily to go through with build, code, and outreach. We plan to keep up our pace as a World-class team as best as we can over quarantine, as uncertain as our plans for this season may seem.

# Printing Rings

14 Sep 2020
Post 2
Awards: design and innovate

Printing Rings By Trey

### Task: Print some game elements to get a kick start on the season

Recently, this year’s competition details were released, and while we couldn’t quite get started on a robot immediately like we did last year we were able to do some prototyping for ring launchers. The thing that we made which enabled us to do this was a rendering of the game element for the year. This was done by taking the model released on AndyMark’s website and 3D printing it. With this, we were able to start thinking about the size and proportion of our future launcher as well as its construction. The ring was printed in PLA at its exact size to best accomplish this.

The biggest problem with this method of construction is that the ring does not have the characteristic foam squishiness so we also made another ring out of foam tape to get a better idea of how the official game element might fly and how we can get it to fly. We were able to throw the two rings around and notice that there is a very noticeable spin that can be achieved and will likely be desirable in the future for maximum stability in the air. The realistic shape of the ring was helpful when we were trying to figure out how the ring would fly since different ring shapes would obviously fly differently so having a replica was nice.

### Next Steps:

We are going to kick off our development of a robot soon and with the rings we made we should be able to develop better early on than if we were empty-handed. This development is of course being curbed by the pandemic since at the moment only a few builders can come in to build at a time. Being one of these builders, I think the goal for the first launcher prototype is to see how easy it is to get a ring to fly and what variables will be important in the future for trajectory and speed rather than actual functionality. We are excited to have a whole season of development ahead of us.

# Robot in 2 Days - But in CAD

14 Sep 2020
Post 3
Awards: design

Robot in 2 Days - But in CAD By Jose

### Task: CAD a robot for the Ultimate Goal Challenge quickly in order to get ideas for a final robot design and prototypes

A new season, a new design challenge, and more opportunities to compete. Last season we participated in the Robot in 3 Days Challenge where teams race to build a robot for the new season as quickly as possible in order to accelerate the brainstorming and prototyping phase of the season. Due to certain circumstances this couldn't happen this season but overcoming the situation the idea of transferring the challenge to CAD arose.

### Day 1

The first step of course is to come up with a design for this robot. Many ideas came and went, many ideas were inspired by previous seasons' robots, but ultimately the main design was decided over a few hours and a basic CAD model was made. A time lapse of this can be seen here:

Since I was really lazy today, I mean since coming up with the design of the robot took a while and I was very busy today not much could be done in the first day. I began working on the claw to grab the wobble goal and taking inspiration from the one used in the xRC Sim version of the game(the sim can be found here: https://xrcsimulator.org/downloads/) I decided on a simple arm mechanism with a hook. The hook is designed to be passive, it's wide enough to go around the pvc pipe of the wobble goal, but small enough such that the top of the wobble goal can't escape as easily. Since the wobble goal isn't as heavy the arm doesn't need such a high gear ratio, so I went for a 30:1 final gear ratio.

### Day 2

Day 2! Time to do everything I was too lazy to do yesterday, I mean too busy to finish. The first step today was to check how much length I had left over for the ring intake, this turned out to be a little over an inch, not much, but enough. Since I am going for a conveyor design for this robot a base is needed below it to not only support the conveyor, but to also make sure the rings don't fall since they will be travelling below the conveyor in order to feed into the shooter. Some supports were added with REV extrusions, which made things start to come together.

Up next was to actually have a way to power the wobble goal grabber. However, this was really simple as I just needed to add an ultraplanetary motor and a belt.

Next on the list for today was to actually make the conveyor belt, this will have "spikes" in order to grab the rings. The conveyor is about 6 inches long to allow for some extra room when intaking. Spikes are in pairs and spaced about 3 inches apart. This was a simple assembly and I was able to move on to adding the pulleys and bearing shortly after. As far as a gear ratio goes, a direct drive 19.2:1 should do.

It's the final countdown..[plays the final countdown music], time for the final sub-assembly, the shooter. This was very simple to make. Holes in the polycarbonate base were made to allow for the shooter wheels(I used the new goBilda Gecko Wheel) and these were also direct driven with a 5.2:1 goBilda motor. This may be too slow but since this is CAD, it isn't very easy to test this. The process of getting renders of this robot proved to be resource demanding but it got done and here is the final product:

# Simple Roller Intake

26 Sep 2020
Post 4
Awards: design

Simple Roller Intake By Jose

This intake design is the most plain of them all, just compliant wheels on a shaft. The idea with this is to have it low to the ground, and drive up to the rings. This design has been tried and tested on many robots by many teams, but it will not work on ROBOT as there is no realistic way to transport rings so low to the ground up to the turret, especially not with the entry angle of the rings.

### Next Steps:

Continue prototying more intake designs.

# Archimedes Screw Intake

28 Sep 2020
Post 5
Awards: innovate

Archimedes Screw Intake By Bhanaviya, Jose, and Shawn

### Task: Begin creating intake systems on CAD to test their potential

The Archimedes Screw Intake, as the name goes, was based on an Archimedes screw. A screw shaped surface would draw the rings from the fields and transfer it directly to the launcher as the screw rotates. Similar to the Archimedes screw water pump, it makes use of positive displacement and would rely entirely on the screw's movement for the rings to travel upward towards the launcher.

While this is an intruiging system, our biggest concerns with it are size and timing. This system would take up most of the volume of the robot. Also, since the screw would have to rotate entirely for one ring to be taken upwards, this is likely not the most efficient system and even the mere drawing of the rings into the system is likely to be more time-consuming. It would also be very difficult to make. So, this intake ends here in the concept stage.

### Next Steps

Our next steps are to begin brainstorming ideas for other, more efficient intake systems. We may still come back to the Archimedes system but as of now, it is of lower priority. Rest in Peace Archimedes.

# The First Launcher

10 Oct 2020
Post 6
Awards: design and innovate

The First Launcher By Trey and Paul

### Task: Create and Test a Arm Disk Launcher

One of the centerpieces of any robot this year is going to be the disk launcher. It’s likely that most robots in the competition are going to be built around their launchers, so one could logically conclude that that’s a good place to start when building a robot. This is no different for us; however, we didn’t just want to build a flywheel like most other people. Instead, we started to look into other designs. One of the designs that came into mind first was some sort of arm that is powered by an elastic or bungee cord that throws disks sort of like a clay pigeon thrower.

But why did we start with an arm design? Wouldn’t a flywheel be easier? We started with an arm because we thought it was interesting and customizable. Yes, a flywheel would be easier but that would be at the cost of customizability. With a flywheel, there is only so much to change. You can change pretty much only the motor, the wheel, or the speed of the motor. This is good for a team that just needs a launcher that works but we want to be able to make a customizable launcher that we can tailor to our needs easily. There is a lot of open space and customizability with an arm launcher. For example, we can change the arm material, length of the arm, strength of the bungee, the time the disk is in contact with the arm, and much more.

So that’s what we built and it works to a degree. Yes, it does launch a ring, in fact, it can launch a ring across the field to a height of 55 inches at an angle of 44 degrees with an easily retractable arm; however, in its current state it breaks easily, isn’t consistent, and is quite big. The first two are fairly easily fixable because they are mostly because the base of the launcher is made out of particle board which falls apart easily but the last one isn’t quite as easy to fix. Cramming this design into a smaller space could provide a difficult challenge. The function of the design is to accelerate a ring over a distance with an arm which can be difficult in a small area because with a smaller arm you have to use a stronger bungee to achieve the same results.

### Next Steps:

I have only touched on a few major things to be improved. There are quite a few; however, the results that we observed from this design definitely warrant a second version, and there will be one. At the very least, I am thinking of new designs and improvements for this system. There are also many other things we can try and I know that regardless of what I have said about a flywheel launcher so far, it would have its advantages, mainly compactness, so I know we will definitely build one of those as well. There is still much more to be made and built for this robot.

# Code Planning For The New Season

17 Oct 2020
Post 7
Awards: control

Code Planning For The New Season By Mahesh

### Task: Plan changes to our codebase for the new season.

This year's game saw a significant boost to the importance of the control award, now being put above even the motivate and design awards in order of advancement. Therefore, it is crucial to analyze what changes we plan on bringing to our codebase and new technologies we plan on using in hopes of benefitting from the award's higher importance this year.

Firstly, the very beginning of the autonomous period requires the robot to navigate to one of three target zones, specified by the quantity of rings placed, being either 0, 1, or 4. Since the drivers will not be able to choose an opmode corresponding to each path, we will have to implement a vision pipeline to determine which of the three configurations the field is in. This can be done with OpenCV, using an adaptive threshold and blob detection to differentiate 1 ring from 4 rings through the height of the detected color blob.

Secondly, ultimate goal's disk throwing aspect opens up the opportunity for automatic shooting and aligning mechanisms and the software to go along with them. If a robot can use the vision target placed above the upper tower goal or otherwise localize itself, projectile motion models can be used to analyze the disk's trajectory and calculate the necessary angle and velocity of launch to score into the goal given a distance from it on the field. Such automation would save drivers the hassle of aligning and aiming for the baskets, allowing them to focus on more complex strategy and improve cycle time. Vuforia and OpenCV pipelines can be used to figure out the robot's location on the field, given the vision target's orientation and size in its field of view. If OpenCV is also used to allow for automatic intake of disks on the ground, then most gameplay could be automated, although this isn't as simple a task it may seem.

Asides from using the webcam, another localization technique we dabbled with this summer was using GPS. We were able to get +- 4 cm accuracy when using a specific type of GPS, allowing our test robot to trace out different paths of waypoints, including our team number, the DPRG logo, etc. If this level of accuracy proves to be viable in game, GPS could be considered an option for localization as opposed to the odometry sensors many teams employ currently. Another sensor worth noting is the PMW3901 Optical Flow Sensor, which acts similar to a computer mouse, in that its movement can be translated into a horizontal and vertical velocity, giving us more insight into the position of our robot. Regardless of how many different gadgets and sensors we may use, an important part of the code for this year's game will be automatic scoring, no matter how we choose to implement it.

As always, we hope to have this year's codebase more organized than the last, and efforts have been taken to refactor parts of our codebase to be more readable and easily workable. Additionally, although it is not necessary, we could use multithreading to separate, for example, hardware reads, OpenCV pipelines, etc. into their own separate threads, although our current state machine gives us an asynchronous structure which emulates multithreading fairly well, and implementing this would give us only a slight performance boost, particularly when running OpenCV pipelines.

### Next Steps:

The most immediate changes to our codebase should be both working on refactoring as well as implementing bare bones for our teleop and autonomous routines. Next, we should work on a vision pipeline to classify the field's configuration at the start of the game, enabling the robot to navigate the wobble goal into the A, B, and C drop zones. Afterwards, the physics calculations and vision pipelines necessary to auto-shoot into the baskets can be made, starting with a mathematical model of the projectile.

24 Oct 2020
Post 8
Awards: design and innovate

Instead of using a grip wheel to launch rings we went with the approach to make a custom flywheel. The key concept of a flywheel is to maximize rotational inertia. This is done by putting as much mass towards the edge of the wheel as possible. To do this, a ring of ninjaflex was designed, from there, 5mm flaps were added as an experiment to see if it would give the wheel more points of contact to the ring. However, the wheel needs a center to be able to spin, so aluminum plates were added to sandwich the ninjaflex ring. To decrease the amount of mass not on the edges of the wheel, these aluminum plates were pocketed, leaving aesthetically pleasing curved spokes on the plates.

### Next Steps:

The ninjaflex is to be 3-D printed and the aluminum plates will be milled on our CNC machine. Once that is done it will all be put together using M3 hardware.

21 Nov 2020
Post 9
Awards: design

### Task: Design a mechanism to trasfer rings from the ground to a future ring launcher

The initial vision for this intake design was inspired by FRC team 1983’s Ultimate Ascent robot. The “ladder” pivots from the back of the robot to rotate out. The wheels in the front are very similar to the simple roller design, except here they extend out of the robot. The intial CAD was a very simplified model in order to get the idea across. After some discussion, it was decided that the design would be shrunk down as it was unnecessarily large.

After that, a more realistic CAD model was made, using aluminum side supports and REV extrusions. This was then taken to the chassis CAD model to check for mountabilty. There seems to be a spot on the front of the chassis that allows the intake to work as intended, however more testing is necessary.

### Next Steps:

Physically build this intake in order to more acurately test for functionality.

# Auto Path Plan

24 Nov 2020
Post 10
Awards: control

Auto Path Plan By Cooper

### Task: Layout a plan for auto paths this season

To begin, as you can see up above (a diagram that was generated on https://ftcchad.com/ ) our first auto path takes very little movement, and no turns whatsoever. This path assumes that on the robot we have some way to grab the wobble goal at the start of the match and can release it in a controlled manner during autonomous. In such, with the robot facing with the "front" of the turret and chassis facing away from the back wall, and the robot in the center of the outermost tape, the robot would use vision to figure out which of the 3 stacks of rings are present. After which, the robot will drive forward and park next to the correct spot, and turn the turret to release the wobble goal on the correct target location. To finish, all it has to do is drive backwards and end up on the shooting line.

After that is coded, we'll add in features gradually. First, we would look at going back and getting the second wobble goal first using odometry, then vision. Next, and by the time all everything already said has been coded, we should have our first launcher and intake done, making it evident that we should shoot them into the high goal from where we sit on the back wall, and then intake and fire the ring stack before moving on to moving the wobble goals. The final revision would to be to use vision to find and then subsequently pick up rings the human player puts in the field after the wobble goal segment.

Get to coding!

# Modelling an Equation for Forward Speeds of a Ring

01 Dec 2020
Post 11
Awards: think

Modelling an Equation for Forward Speeds of a Ring By Bhanaviya and Ben

### Task: Model a projectile motion equation to approximate forward speeds of rings launched from a ring launcher

A key challenge in this year's game is finding the best possible position to launch rings to ensure optimal performance of the ring launchers. Part of this challenge includes approximating a potential forward speed for each ring as it is launched from the launcher itself. There was also height and distance constraints that needed to be taken into account before we could find these forward speeds. Modelling an equation to identify this forward speed would allow us to directly plug in this equation into the robot's code so it can automatically adjust itself to aim rings from an optimal angle and position.

In order to find the most optimal position and angle to launch the rings, we needed to first consider the angle of the launcher to be a variable to determine all possible forward speeds horizontally and vertically. We needed to look at the forward speeds both vertically and horizontally in order to attain the maximum distance (which would be tangential to the horizontal and vertical distance if we were to look at it like a right triangle). FTC constraints dictate that the maximum height a ring can be launched was 16ft we translated to 4.85 meters. While this was not a contant we inputted into our formulas, it was something for us to consider when we began. We knew that the height of our robot with the shooter mounted was roughly 0.41m and aiming to get the ring into the third level of the goals, we knew that the height the ring needed to reach was 0.88m. Subtracting the desired height from the initial height, we got 0.47m, and by placing that on one side of our projectile equation, we used simple algebra to find out that to isolate v0, 1/2(-a)t^2 needed to be subtracted from 0.47m for the vertical velocity. Since the final horizontal distance varies from launch to launch, we left it as xF (final horizontal distance) - 0 (inital horizontal distance) to reflect our steps for the vertical equation.

When we began planning our equation, there were 3 things we anticipated we needed to know. 1) Angle of launch - this was what we were intending to find but we wanted a formula so we wouldn't have to manually measure theta each time. 2) Initial vertical speed - this was another unknown which affected the distance our rings could travel, which, consequently, relied on the measure of the angles. Finally 3) time - there are two things we need to know about time. First, how long the ring stays in the air, and second how long it takes for the ring to reach zero vertical velocity (in other words, when does it reach its maximum height?) Another issue we needed to account for was how the end of our equation would be represented. Did we want the height of the third level goal to be the summit of the ring's arc or did we want it to be its final point? Since we knew that the ring were not being launched 0 meters away from the ground but rather 0.41 meters away, aiming for the goal to be the end of its arc past its apex would cause too much error in our model if we were to graph the ring's arc as a parabola. So, we settled for making the summit of our parabola be the third level of the goal. So, time in our equation was represented as t/2 since in a standard parametric equation, t for time represents the complete arc while t/2 cuts the arc off at the apex. With all this taken into account, we were able to model two different equations - one for the horizontal velocity of the ring and second for the vertical velocity of the ring.

Our equations were: Vertical: v0 = (0.47 - 0.5(-a)(t^2))/sinθ(t/2)) and Horizontal: v0 = (xF - 0.5(-a)(t^2))/cosθ (t/2)) t stands for time in seconds, a for acceleration due to gravity - 9.8 m/s^2 and xF for the final horizontal distance of the robot which will be calculated by the robot itself.

While having two unknowns in our equation in a concern, we plan to find the velocity of one, plug it into the equation for the other side and retrieve theta from there. We want theta to be the same for both the horizontal and vertical equation assuming that the distance they travel is the same.

### Next Steps

The next step would be for us to plug in constants into our equations and check to see if the velocity and theta seem to be reasonable. We anticipate that these equations will undergo several changes as we continue to build the ring launcher. Even once the equation is finalized, we will need to figure out how to translate it into code and whether or not we can find values such as RPM and muzzle velocity in order to control our motor to provide us our desired launch.

# FTC Legal Belt Sander

12 Dec 2020
Post 12
Awards: innovate

FTC Legal Belt Sander By Paul

### Task: Create a prototype for a belt sander intake system

The so-called “FTC Legal” belt sander was an early iteration of the intake mechanism for this year's robot. It was composed of a belt, from a Ryobi belt sander, rev wheels wrapped in tape, to help center the belt, and a tensioning mechanism. The belt would provide friction, moving the disk game elements upwards towards the launcher mechanism. However, an issue we ran into was the distance between the bottom of the belt and the floor was hard to regulate, resulting in disks either not having enough space to be sucked up, or havag too much space and not enough friction to be dragged up. This was partially solved by replacing the belt sander belt with a Ninjaflex belt with flaps, which is the current iteration of the robots intake system, using many of the same parts and designs as the original “FTC Legal” belt sander.

Future plans include designing and constructing some form of leveling system, and a higher belt speed to more quickly collect disks. We are also considering using this sander design as an inspiration for a dual-tracked belt drive intake system and an elevator-like intake system with ninjaflex substituting for a traditional belt drive system.

# Caterpillar Track Intake

31 Dec 2020
Post 13
Awards: design and innovate

Caterpillar Track Intake By Ben, Bhanaviya, Trey, and Jose

### Task: Build and prototype an intake system

One of the first intake systems we made was the Caterpillar intake assembly (Tetrix tread intake). The inspiration for this design came from an earlier bekt drive comprising of a sander (which you can read about in our earlier post). This was originally built off a c-channel extrusion with a motor attached to sprockets that drive treads. The purpose of this subsystem is to transport the rings from the field into the launcher loading area.

We first tested the assembly without the rubber bands and quickly realized that the treads couldn’t create enough friction to grip the ring and move it vertically. Our solution was to attach rubber bands within each tred piece. There were 2 reasons for this, the first being that rubber in general has high friction and good grip. The second reason is that the flinging rubber bands will conform to the shape of the ring at high speeds and drag the rings up the intake.

We did experience a few problems with the construction of the assembly. We found that the rubber bands would often get caught on the edges of the c-channel and either fly off at a high velocity, snap, or tangle and prevent the assembly from moving. Because of the way the band fits into a tread, there wasn’t a way to permanently attach the rubber band without damaging the thread, meaning we would have to scrap the idea or find a work-around. We eventually decided to rebuild the intake with REV extrusions because it would be more compatible with our robot and we could replace the large c-channel with the smaller REV extrusions.

### Next Steps:

Although this prototype holds promise, we will continue to experiment with it and alternatives to find an alternative that doesn’t run the risk of tangling and disrupting the system.

# NinjaFlex Belt intake system

02 Jan 2021
Post 14
Awards: design and innovate

NinjaFlex Belt intake system By Trey

### Task: Design an intake with the NinjaFlex belt

So far we have made a few Intake assemblies including the belt intake and the Tetrix tread intake. However, as is Iron Reign tradition, we like to make systems that utilize custom parts to both help our robot’s aesthetic and functionality. To do this, we took aspects from the other two intakes to better design and make the one that is discussed in this post. To recap, the belt intake was a sanding belt on to barrels that spun at high speeds to pull in rings and the tread intake was made with Tertis tank treads with rubber bands and spun, in the same way, to grip and pull in rings.

The NinjaFlex belt intake takes the benefits of both systems without generating their issues. The NinjaFlex intake has the narrowness and form factor of the belt intake without the issues of the belt derailing which is caused by uneven pressure on the belt. Instead, the NinjaFlex belt intake is sprocket-driven with a custom belt to ensure that the belt stays on the rollers at all times as long as the two ends are aligned properly. Derailing was a big issue with the belt intake. Personally, I remember spending at least a few hours in total trying to get the belt to not fall off, with little success. That system would have needed much more work and improvement before we would have seen any results.

The NinjaFlex belt intake system also yields the benefits of the tread system in that the 3D printed belt provides sufficient grip on the rings in order to pull them onto the robot. Additionally, the NinjaFlex belt system also doesn’t use rubber bands as gripers that can tangle with nearby screws or protrusions, possibly causing the system to break. Instead, the belt has flaps which can also be changed or molded into different lengths or shapes. This brings up one of the biggest benefits, customizability. When we use 3D printed or CNC parts we enter this space of customizability which is always a good aspect because if a change needs to be made to a part, we can usually make a new custom part in a matter of days if not hours with our machinery which gives us a lot of flexibility in how we can build our robot.

Assembly-wise the intake is also super simple right now. It consists of 6 sprockets, 3 on each side that drive a belt with the sprocket spacing sits on to pulls in rings. The dimensions and specifics of how the belt was designed and made are in the post “NinjaFlex intake belt” but basically it’s just a belt with holes in it with the specific spacing of the REV sprockets. The motor right now has just been placed on one of the shafts but will be secured in a better location in the future, either parallel to the guide rails or perpendicular depending on how much space we have. If the motor is mounted parallel to the guide rails, then it will drive the belt with beveled gears, otherwise, it will be directly fitted onto the shaft.

### Next Steps:

As mentioned previously, the motor has yet to be permanently mounted so that would be the next clear step and after that, there will likely be more testing and comparing of different intake systems. Then, we will interface the new intake with a ramp to see how we can assemble the two together to finish our intake system and start planning to put it on the robot. For now, though, we have made good progress.

# Proteus' model

03 Jan 2021
Post 15
Awards: think, innovate, and design

Proteus' model By Bhanaviya and Jose

### Task: Update the model to plan Proteus' build

With our first qualifier being less than 2 months away, Iron Reign embarked on an ambitious project to create a robot with a circular chassis, an elevator-like intake system, and a fully automated launcher. While this robot is still in construction, we do have a name for it - Proteus. Named after the early-prophetic sea god who was also known for his versatility, this was the most fitting name for our robot given how flexible we needed to be this season and with only a few weeks left to construct a robot. In an earlier post, we detailed our decision to reuse our circular chassis in order to improve our robot's maneuvering abilities and get around other robot to avoid the traffic towards the goal posts. However, we are yet to decide which of our three intake systems to use as well as how the progression of our launcher might change considering that it is still in its CAD stage. To see how each of these intake systems look on the robot, we modelled the chassis design from the beginning stages and created multiple models to represent each launcher mounted on the robot.

Earlier in the season, we created a model of just the chassis itself to account for the fact that we are only reusing the chassis design from last year and nothing above it. The updated model still has the same base chassis design from the earlier model, but it now has three different iterations - one with the ladder intake, one with the caterpillar intake, and one with the elevator intake system (yet to be named). Since the elevator intake does not yet have a full-fledged design, we are holding off on a full robot model with it until we figure out how to make it compatible for a final design.

### Next Steps

With our robot model in progress, we can now plan out all our steps ahead of time in CAD so that we will make less mistakes on the physical build. We will be updating the model as the season progresses.

08 Jan 2021
Post 16
Awards: innovate and design

Ladder Intake Build By Jose and Bhanaviya

For the intake system of this year's challenge we first brainstormed several ways which a ring could be collected and transferred to the launching system. Through that and experimenting with CAD, the ladder intake system was developed. Essentially it functions by using the series of Omni wheels on its edge to collect the ring, and then pivot back up to the robot. As pictured below, the ladder intake will be mounted onto the back of the robot and pivot as needed to collect the rings.

#### Construction

The ladder intake was constructed using 8 REV extrusion bars connected by 6 plastic brackets, 2 servos, 7 Omni wheels, a shaft and its respective parts for the wheels to rotate on, a sheet of polycarb below the Omni wheels and shaft to support the rings, and 2 more brackets for the servos to be mounted onto. As shown in the picture below, the idea is for the rings to be reeled in by the Omni wheels and be held using the support of the sheet of polycarb below the shaft, and then be transported to their designated locations in the launching system by the intake pivoting back.

#### Testing

Although the system seemed promising on paper, it unfortunately did not work out as intended. When tested with some first draft versions of code, we found out that the system was unable to actually take in the rings, and instead could only hold them. There wasn't enough traction on the rings for them to be reeled into the system in the first place, which was an issue. We will use this experience to construct an intake that overcomes these issues moving forward.

### Next Steps:

Start brainstorming a new intake mechanism possibly using some of the components of the current intake that can overcome the issues that hindered the ladder intake from functioning optimally.

# Ring Launcher CAD Meets 1+2

11 Jan 2021
Post 17
Awards: design

Ring Launcher CAD Meets 1+2 By Jose

### Task: Begin designing a ring launcher

The initial vision for the ring laucher was to be a semi-circle in order to give the ring as much acceleration as possible. In this meeting, it was decided that instead it would be a quarter-circle for the following reasons: to save on space, since there will eventually also be an intake on the robot and a quarter-circle has been proven to give the ring enough acceleration, even if a faster motor is necessary.

With that decision made, the flywheel was placed in the CAD and the quarter-circle was brought into existance. There is a circular shaft in the center that will hold everything together, but the plate that the ring will rest on cannot be jointed to this shaft. This is because it has to clear the flywheel, so instead another aluminum plate will be placed below it to act as support. From there, walls were added to keep the ring within contact of the flywheel. These walls where also extended a bit beyond the quarter-circle, this is to prevent any variabilty in the lauching of the ring. Finally, a motor mount was extended out of the center aluminum plate to drive the flywheel with the use of a pulley and belt.

In the second meeting, some final design additions where made, namely screw holes were added(or removed, technically) from the plates and walls in preparation for 3-D prining and CNC milling. Additionally, any walls that were in the way of the belt driving the flywheel were split to make way for it.

### Next Steps:

There are still many features to be added, such as a way to transfer rings from an intake to the launcher.

# Flywheel Assembly

12 Jan 2021
Post 18
Awards: design and innovate

Flywheel Assembly By Jose

Following the milling of the aluminum plates and the 3-D printing of the core of the flywheel, it is time to put it all together. The first step was to sandwich the ninjaflex core with the aluminum plates, and secure them together with long m3 screws. The plates have a spot for bearings, and those allowed for the addition of a 8mm circlular shaft. From there, the cut-out pulley was directly attached to the flywheel using more m3 screws. This pulley is how the flywheel will be driven, and it has a cutout to be able to fit bearing inside of itself.

Following the assembly was testing, initial spinning by hand revealed some shakiness in the flywheel. This is likely due to variability in any of the parts, as well as the bearings.

### Next Steps:

Further investigate the reason for the shakiness of the flywheel when spinning, and modify the weight distubution as needed to correct any variability.

# 1/16 Build Progress - The first rings fly

16 Jan 2021
Post 19
Awards: mechanical and innovate

1/16 Build Progress - The first rings fly By Trey, Cooper, Aaron, Paul, Bhanaviya, and Jose

### Task: Continue developing the ring launcher and do preliminary testing

Today we continued to further our progression on our ring launcher, finally getting to do some preliminary testing to see what the design might do. For starters, we started to get some of the walls off of the 3d printer which was the first piece of our flywheel launcher barrel design that started to come into real life. We also modified the pulley for the flywheel with the CNC that would eventually be used in the final construction. We had to do this because we want to be able to use our REV motors and driving belts to move the non-REV wheel. In order to make sure that we could do this we set up a machining path that would remove an inner circle of material from a standard pulley so that we can put bearings through it.

The machining of the pulley is actually fairly simple. All we did was set up a path that would mill a cylinder out of the pulley. What was more complicated was what we had to do before that since you can’t mount the pulley on the CNC since it doesn’t lie flat. Instead, we modeled and CNCed a divot for the pulley to fit into along with some holes for screwing the pully to the CNC. You can see both the divot and the final product above. This operation isn’t that difficult on the machine since it’s just plastic and wood but this is the first time that we have had to mill a divot to machine a part which is what makes it notable.

Then we put what we had together for the first time on a sheet of particleboard and spun up the wheel to see if we could even get a ring moving. We did get some success and the rings did launch several feet but we did have a few problems. Mainly that the walls were being held in place by people so they were moving and we couldn’t get enough grip on the rings. However, actually assembling the flywheel in housing will solve this problem. Honestly, we weren’t looking for problems in the first place though. This event would fall more under team bonding because we really just wanted to see a ring fly. We put in a lot of work and it was quite inspiring to see the ring actually move.

### Next Steps

We still have a lot more manufacturing ahead of us. We still need to finalize the model and the CAM of all 3 of the plates in the barrel and 3d print more parts. We also still need to assemble and think about how we are going to get the rings into the launcher which will come and bite us in the butt at some point. For now, it was nice to see some progress as well as the first rings fly.

# Updating Proteus' model

16 Jan 2021
Post 20
Awards: think, innovate, and design

Updating Proteus' model By Bhanaviya and Jose

### Task: Update the model to plan TomBot's build

With our first qualifier being around a month away, Iron Reign is currently in the midst of trying to put together a functional (or semi-functional) robot. In a previous post, we detailed the earlier stages of our CAD design. As of now, Iron Reign is still testing our intake systems but before we finalize the system we want to implement, we plan to construct a robot with just our launcher system mounted. The reason for this is that we have more or less finalized the CAD design for our launcher (which you can read about in one of our earlier posts) and before we can begin the actual assembly and mounting, we need to have it represented in our robot model.

So, we created a render with just the launcher itself mounted onto our robot Proteus. We anticipate that although the model will change substantially once an intake system has been mounted, the position of the launcher will be consistent and having this modelled allows us to plan out our articulations and strategy for scoring rings into the goalposts.

### Next Steps

Once we have finalized which intake system we plan to use, the model will be altered accordingly to reflect these changes. As of now, this model will allow us to visualize and implement the addition of our launcher system which will streamline our ability to plan out how we want mount an intake in the future.

# Code Changes Leading up to the PvC Scrimmage

18 Jan 2021
Post 21
Awards: think and control

Code Changes Leading up to the PvC Scrimmage By Cooper

### Task: Finalize code changes prior to the PvC scrimmage

Leading up to the scrimmage, many code changes happened, mostly in the area of auton. To start, I tried to run 10 runs of every auton path, to check reliability. Time and time again though, the robot would go off towards joneses, crash into the far wall, or knock over the wobble goal when placing it.

To address the robots tendency to not want to go straight forward, we wanted to start to use VUforia and the vision targets to help us know our relative angle. However, we had problems with VUforia, as it wouldn’t detect much past what was immediately in front of it. The problem probably has something to do with our abysmal lighting conditions on our field, and while there are solutions, we didn’t have time. So, we went analog and used a distance sensor on the front right of our robot, facing right. This was to basically just do wall following, with one ace up our sleeve. We decided to modify our existing movePID that uses the IMU, to make a moveGenericPID, where it could be used for more generic purposes, like this one. We pass the method our target distance, our current distance, plus all the other generic move variables, and with a bit of fiddling with input multipliers, it worked.

The next issue caught me off guard, and put me into a state of confusion. Or I guess rather. In all seriousness, all I needed to do was decrease the distance it went for the far. To go into a little more detail on the final issue, it was caused by multiple things at the same thing. Firstly, the arm that holds the wobble goal is shorter than the robot; its end is inside the circumference of the robot when the base and turntable are lined up. That lined up position is how we start, so it had been where the arm just turns to one side to drop it off. Even swung out, the wobble goal is still 40% over the robot, as to where the robot lets go of it and it topples over. We decided to fix it by turning the robot in the opposite direction the arm is turning, at the same time. Then we aren’t losing time to it, and it's a clean drop.

### Next Steps

Given that we have attended to all outstanding issues prior to the scrimmage, the next steps mainly include testing the robot out during practice runs and being prepared to drive it through the week for all matches.

# Ring Launcher CAD Meet 3

22 Jan 2021
Post 22
Awards: design

Ring Launcher CAD Meet 3 By Jose

### Task: Expand the ring launcher to begin accomadating for a controlled system of firing the rings

The first step in accomplishing this task is to expand the center aluminum plate to almost a complete semi-circle. From there the back of it was expanded to allow for a place for the rings to sit. Offsets were added to accomadate for any new walls that will be added. Finally, at the back is a place for a servo to be mounted, this servo will eventually be used to rotate rings into the flywheel.

In terms of the center shaft assembly, the goBilda hyperhubs were removed as there were unnecessary, however the holes made for them were kept, in case they are ever needed again. Spacers and bearing were added to allow for clearance and minimal friction.

### Next Steps:

Finalize, the left side of the ring launcher, walls need to be added to prevent rings from falling off and a trigger needs to be attached to the servo to rotate rings into the flywheel.

# Ring Launcher CAD Meet 4

23 Jan 2021
Post 23
Awards: design

Ring Launcher CAD Meet 4 By Jose

### Task: Finalize the ring launcher design

The main thing here is a huge wall on the left to guide rings to their resting position at the back of the ring launcher. But before that, the ring trigger needs to be made first, as it needs to be worked around. The trigger contours the ring perfectly by design, and only needs to rotate about 40 degrees to put a ring within contact of the flywheel. With that done, the guide wall was designed around it, encompassing the enitre left side and connecting to the back center.

The final step here is to create a better motor mount. This will be a seperate part that will then be attached where the original motor mount was. This is being done to more easily allow for the mount to be slotted: doing so lets the motor's position be shifted to keep the belt it drives as tight as possible.

### Next Steps:

With the first iteration of the ring launcher design completed, it is ready to be manufacuted.

# Iterate Trajectory Calculations in Preparation for DPRG Meet

24 Jan 2021
Post 24
Awards: think, control, and connect

Iterate Trajectory Calculations in Preparation for DPRG Meet By Bhanaviya, Mahesh, and Ben

### Task: Improve the Trajectory Calculations

As mentioned in our earlier posts, one of the biggest control challenges we face in this year's season is identifying a equation to model how the path of a ring launched from our launcher is affected by its angle of launch. 2 weeks ago, we were able to create a starter equation to model this trajectory. However, this time, we want to be able to identify time as not a variable but as a fixed constant and values for RPM, muzzle velocity and rotations per second of a motor. We want to be able to list these values in anticipation of our virtual meeting with the Dallas Personal Robotics this coming week where we will present both our Flywheel Launcher and the calculations we have derived so far. We anticipate that these calculations will be subject to change and our error as we go about the process of identifying how best to put our equations into code and as such, the values in this post are not final in any way.

Our main purpose for modelling this equation is to correct the efficacy of our launcher - primarily what motor it uses and how the motor's PID values need to be fine tuned in order to provide us an ideal launch. In our previous post, we stated that the variables and constants we needed to derive the equations were:

$$\theta$$ - angle of launch

$$hv_0$$ - initial horizontal velocity of launch

$$hv_0$$ - initial horizontal velocity of launch

$$h$$)- height of goal at the third level which we know to be 0.88m

$$d$$) - the horizontal distance between the goal and the robot

$$g$$ (approximately $$9.8 \frac{m}{s^2}$$) - acceleration due to gravity

We initially created two equations - to represent the initial velocity of the robot horizontally and vertically. However, one key component which we originally considered to be manually calculated was time. In order to isolate time as a fixed variable, we needed to find the amount of time in seconds it would take a ring launched from the robot to reach 0 vertical velocity. We knew that for any shot that crosses through the goal with zero vertical speed, the ring needed to have an initial upward velocity such that the acceleration due to gravity brings it to zero vertical velocity at the point it reaches our target height. Regardless of what the horizontal component is, target time in this situation is governed by solely by gravity and vertical distance. Although we had initially modelled our equations to reach the summit in order to make the actual angle of launch more solvable since that would mean that we didn't have to consider "balancing" the initial height of the robot to derive the value of $$\theta$$. However, seeing as the summit is the center of the portion of the trajectory with the least vertical travel for a given span of time or distance, we would not only be able to isolate time but also find $$\theta$$ with the least vertical error. As such, we modelled an equation for time which can be found as shown below.

$\displaylines{t = \sqrt{v_0/(0.5* $$g$$)}}$

In addition to time, we also needed to find the RPM of the motor of the launcher, for which we needed to find the circumference of the launcher, which was 0.48066m. From here, we found the radius to be approximately 0.076m, which we could use for our RPM equation which was RPM = v = \omega r, with r representing 0.076m. To find muzzle velocity, we plan on using our velocity formula as of now but this is likely to change as we continue to inspect our equation. Here are the overall equations we have developed so far now that we know how to look for time at the apex. $\displaylines{d/cos(\theta)(t/2) = hv_0 \\ ((0.88 - 0.41) - 0.5(a)t^2)/sin(t/2)= vv_0, t = \sqrt{v_0/(0.5* $$g$$)}}$

### Next Steps:

Using these equations, we plan to be able to identify angle of launch, RPM and muzzle velocity for a range of distances away from the goal. Mainly, we plan to derive values for a very specific range (likely 2 to 2.5m) to present our calculations as well as our equations to Dallas Personal Robotics Group in the upcoming meeting on Tuesday.

# RingSlinger 9000 Build Progress

27 Jan 2021
Post 25
Awards: innovate

RingSlinger 9000 Build Progress By Paul and Cooper

### Task: Build and prototype the Flywheel Launcher

For this years new season we used an innovative flywheel-based launcher to score the disks into the goal. After 3 weeks of work, we also managed to come up with a name for it - The RingSlinger 9000. Any posts referring to our flywheel launcher refer directly to the Ringslinger itself. This launcher uses the properties of rotational inertia to propel the game pieces along a carefully calculated, fixed trajectory to ensure that the disks have the same launch trajectory every time, allowing both automation and driver control to more simple. The assembly is physically constructed from several sheets of aluminum and one sheet of polycarbonate, modeled by Jose and cut on our CNC mill. The spacers between the sheets are made of nylon due to its high strength and low friction, and we chose to use a custom ninjaflex ring around the CNC milled flywheel to ensure that the wheel could transfer the maximum amount of kinetic force to the disks. The launcher is designed in such a way as to impart rotational energy on the disks, spinning them. This helps maintain a constant trajectory, similar to how an NFL Quarterback spins the football when scoring a touchdown pass, or how the grooving on a rifle spins a bullet, ensuring in-flight stability. In tests, our design proved to be mostly effective, launching disks along a consistent trajectory. Our first firing test was during our video meet with the DPRG, and with a few tweaks, it was performing up to standards. However, there were some issues that needed to be addressed - mainly, we need to complete further testing to see if any of the rings experience damage as a result of our launch, where the general area the rings tend to cluster at, and fine-tuning an equation to model the launch. Correcting these issues will make the accuracy of the RingSlinger that much more accurate.

### Next Steps:

Future plans to expand upon this design include integrating a voltage regulation module, to ensure that the disks are always spun at a constant velocity. In tests, we noticed that as time in a round passed, the drop in main battery voltage caused the disks to be launched at a slightly slower velocity, not enough to phase a human driver, but enough to render automated shooting protocols inaccurate. To remedy this, we will find out the lowest point the battery will reach during the course of a match, and regulate the voltage being fed into the flywheel motor to not surpass the aforementioned "low" voltage during the match.

# New Addtions to the Elbow

28 Jan 2021
Post 26
Awards: design

New Addtions to the Elbow By Jose

### Task: Design new parts to better mount the ring launcher and encoder

First thing to do in this CAD session is to design a secondary mounting point for the ring launcher. To do this, the existing mount was projected and any unecessary parts were removed. Only the holes for adding the REV extrusion as well as the holes for encoder pivot were left.

The next thing to design was a mount for the encoder, as it needs to be prevented from rotating with the shaft. The closest stationary location was the REV extrusion on top of the GoBilda U-channel. This part has three holes at the bottom to be mounted on the REV extrusion, as well as a hole at the top to reach the encoder.

### Next Steps:

As for manufacturing, we need to mill out the ring launcher mount and 3-D print the encoder pivot and holder. As for programming, the new encoder should help with aligning the ring launcher.

# Correcting the Trajectory Calculations Equations

28 Jan 2021
Post 27
Awards: think and control

Correcting the Trajectory Calculations Equations By Bhanaviya, Ben, and Mahesh

### Task: Correct the trajectory calculations after the DPRG meeting

In the past week, we've been experimenting with a series of equations to derive the angle of launch of our flywheel launcher when we need it to travel a certain distance. 2 days ago, we were able to present the calculations we'd derived so far to Dallas Personal Robotics Group. After feedback from DPRG and a little more testing ourselves, we've discovered the following corrections we need to make to our equation. For reference, this is a correctional post regarding our earlier calculations - you can find versions of our earlier equations and calculations in our previous posts.

#### Time

One of the biggest fixes we needed to make to our equation was identifying how to derive time as a fixed variable. We wanted to be able to find the exact time in seconds it would take for our launcher to launch a ring at 0 vertical velocity. We needed this because we knew that for any shot that crosses through the goal with zero vertical speed, the ring needed to have an initial upward velocity such that the acceleration due to gravity brings it to zero vertical velocity at the point it reaches our target height. Regardless of what the horizontal component is, target time in this situation is governed by solely by gravity and vertical distance. As such, finding time at 0 vertical velocity would allow us to model an equation for the summit of the ring's trajectory, which is where we expect the goal post to be in order to reduce variability and error in our calculations. This understanding allowed us to create the following equation for time with h representing the height of vertical travel:

$\displaylines{t = \sqrt{h/(0.5* g)}}$

#### Initial Velocity

Initially, we had planned on solving for the initial vertical velocity of the ring then plugging into the equation for horizontal vvelocity, work backwards and find angle of launch. However, in order to have the most accurate trajectory possible, we expect the horizontal and vertical velocity to be varying, especially since the vertical velocity is affected by gravity and the horizontal isn't. Thus, we expect the vertical and horizontal initial velocity to look like the following, wherein t is time, initial vertical velocity is v_0 and initial horizontal velocity is h_v0:

$\displaylines{v_0 = g*t \\ h_v0 = d/t}$

#### Muzzle Velocity

Initially, we had planned on using velocity on its own for muzzle velocity. However, now that we have two initial velocities, our equation for muzzle velocity changed to look sort of like the Pythogorean Theorem with us solving for c, since the muzzle velocity represents the "hypotenuse" or trajectory in this case, mV representing muzzle velocity.

$\displaylines{mV = \sqrt{v_0^2 + h_v0^2}}$

### Initial Height of Launch

Previously, we measured the height of the robot - 0.41m - to be our initial height of launch. However, one issue with the vertical travel is that if we take 0.41 to be a variable which is affected by $$theta$$ then we need to figure out how much that change is for the vertical travel distance - an error bar or the design of experiments chart might work well for this so we can make sure angle of launch doesn't confound our initial measures for time and muzzle velocity since both of which rely on 0.47m (the height of travel taken by subtracting the height of the robot from the height of the goal) being constant which in turn relies on 0.41m.

#### Fixed Values

Since we know the height of travel to be 0.47m and $$g$$ to be 9.8 m/s^2, using our time equation, we found time to be 0.31s. Using time, we could then find the initial vertical velocity to be 3.055m/s and horizontal velocity dependent on the distance of the robot away from the robot, which we take to be our explanatory variable.

Our equation ultimately stays the same but the methods we used to calculate time and initial velocities have now changed, which should change our final values substantially. In our latest post, we had a set of very different values in our meeting with DPRG. However, with these edits, we now have the following calculations (which we simplified by plugging into a spreadsheet to get automated values.

In order to sanity-check our calculations, we also derived the following parabola to represent the arc of the trajectory:

### Next Steps:

Our immediate next steps are to model initial height as a function of $$theta$$. Since we know that initial height is susceptible to change as the elbow of the robot drops and raises in accordance with angle of launch, being able to model initial height as a function will allow us to reduce all possible sources of error and find an accurate measurement of trajectory calculations. This will likely require another process like the one we did here as we attempt to model initial height as a function. W'd like to thank DPRG for all their feedback and for their help in allowing us to fine-tune these calculations!

# Derive And Translate Trajectory Calculations Into Code

29 Jan 2021
Post 28
Awards: think and control

Derive And Translate Trajectory Calculations Into Code By Mahesh, Cooper, Shawn, Ben, Bhanaviya, and Jose

### Task: Derive And Translate Trajectory Calculations Into Code

To ease the work put on the drivers, we wanted to have the robot automatically shoot into the goal. This would improve cycle times by allowing the drivers, theoretically, to shoot from any location on the field, and avoids the need for the robot to be in a specific location each time it shoots, eliminating the time needed to drive and align to a location after intaking disks.

To be able to have the robot automatically shoot, we needed to derive the equations necessary to get the desired $$\theta$$ (angle of launch) and $$v_0$$ (initial velocity) values. This would be done given a few constants, the height of travel (the height of the goal - the height of the robot, which we will call $$h$$), the distance between the robot and the goal (which we will call $$d$$), and of course acceleration due to gravity, $$g$$ (approximately $$9.8 \frac{m}{s^2}$$). $$d$$ would be given through either a distance sensor, or using vuforia. Either way, we can assume this value is constant for a specific trajectory. Given these values, we can calculate $$\theta$$ and $$v_0$$.

However, without any constraints multiple solutions exist, which is why we created a constraint to both limit the number of solutions and reduce the margin of error of the disk's trajectory near the goal. We added the constraint the disk should reach the summit (or apex) of its trajectory at the point at which it enters the goal, or that it's vertical velocity component is $$0$$ when it enters the goal. This way there exists only one $$\theta$$ and $$v_0$$ that can launch the disk into the goal.

We start by outlining the basic kinematic equations which model any object's trajectory under constant acceleration: $\displaylines{v = v_0 + at \\ v^2 = v_0^2 + 2a\Delta x \\ \Delta x = x_0 + v_0t + \frac{1}{2}at^2}$

When plugging in the constants, considering the constraints mentioned before into these equations, accounting for both the horizontal and vertical components of motion, we get the following equations: $\displaylines{0 = v_0sin(\theta) - gt \\ 0^2 = (v_0sin(\theta))^2 - 2gh \\ d = v_0cos(\theta)t}$ The first equation comes from using the first kinematic equation in the vertical component of motion, as the final velocity of the disk should be $$0$$ according to the constraints, $$-g$$ acts as the acceleration, and $$v_0sin(\theta)$$ represents the vertical component of the launch velocity. The second equation comes from using the second kinematics equation again in the vertical component of motion, and again according to the constraints, $$-g$$ acts as the acceleration, $$h$$ represents the distance travelled vertically by the disk, and $$v_0sin(\theta)$$ represents the vertical component of the launch velocity. The last equation comes from applying the third kinematics equation in the horizontal component of motion, with $$d$$ being the distance travelled by the disk horizontally, $$v_0cos(\theta)$$ representing the horizontal component of the launch velocity, and $$t$$ representing the flight time of the disk.

Solving for $$v_0sin(\theta)$$ in the first equation and substituting this for $$v_0sin(\theta)$$ in the second equation gives: $\displaylines{v_0sin(\theta) = gt \\ 0^2 = (gt)^2 - 2gh, t = \sqrt{\frac{2h}{g}}}$ Now that an equation is derived for $$t$$ in terms of known values, we can treat t as a constant/known value and continue.

Using pythagorean theorem, we can find the initial velocity of launch $$v_0$$. $$v_0cos(\theta)$$ and $$v_0sin(\theta)$$ can be treated as two legs of a right triangle, with $$v_0$$ being the hypotenuse. Therefore $$v_0 = \sqrt{(v_0cos(\theta))^2 + (v_0sin(\theta))^2}$$, so: $\displaylines{v_0sin(\theta) = gt \\ v_0cos(\theta) = \frac{d}{t} \\ v_0 = \sqrt{(gt)^2 + {\left( \frac{d}{t}\right) ^2}}}$

Now that $$v_0$$ has been solved for, $$\theta$$ can be solved for using $$sin^{-1}$$ like so: $\displaylines{\theta = sin^{-1}\left( \frac{v_0sin(\theta)}{v_0} \right) = sin^{-1}\left( \frac{gt}{v}\right) }$

In order to be practically useful, the $$v_0$$ previously found must be converted into a ticks per second value for the flywheel motor to maintain in order to have a tangential velocity equal to $$v_0$$. In other words, a linear velocity must be converted into an angular velocity. This can be done using the following equation, where $$v$$ = tangential velocity, $$\omega$$ = angular velocity, and $$r$$ = radius. $\displaylines{v = \omega r, \omega = \frac{v}{r} \\ }$ The radius of the flywheel $$r$$ can be considered a constant, and $$v$$ is substituted for the $$v_0$$ solved for previously.

However, this value for $$\omega$$ is in $$\frac{radians}{second}$$, but has to be converted to $$\frac{encoder \space ticks}{second}$$ to be usable. This can be done easily with the following expression: $\displaylines{\frac{\omega \space radians}{1 \space second} \cdot \frac{1 \space revolution}{2\pi \space radians} \cdot \frac{20 \space encoder \space ticks \space per \space revolution}{1 \space revolution} \cdot \frac{3 \space encoder \space ticks}{1 \space encoder \space tick}}$ The last $$\frac{3 \space encoder \space ticks}{1 \space encoder \space tick}$$ comes from a $$3:1$$ gearbox placed on top of the flywheel motor.

To sanity check these calculations and confirm that they would indeed work, we used a desmos graph, originally created by Jose and later modified with the updated calculations, to take in the constants used previously and graph out the parabola of a disk's trajectory. The link to the desmos is https://www.desmos.com/calculator/zuoa50ilmz, and the image below shows an example of a disk's trajectory.

To translate these calculations into code, we created a class named TrajectoryCalculator, originally created by Shawn and later refactored to include the updated calculations. To hold both an angle and velocity solution, we created a simple class, or struct, named TrajectorySolution. Both classes are shown below.

public class TrajectoryCalculator {
private double distance;

public TrajectoryCalculator(double distance) {
this.distance = distance;
}

public TrajectorySolution getTrajectorySolution() {
// vertical distance in meters the disk has to travel
double travelHeight = Constants.GOAL_HEIGHT - Constants.LAUNCH_HEIGHT;
// time the disk is in air in seconds
double flightTime = Math.sqrt((2 * travelHeight) / Constants.GRAVITY);

// using pythagorean theorem to find magnitude of muzzle velocity (in m/s)
double horizontalVelocity = distance / flightTime;
double verticalVelocity = Constants.GRAVITY * flightTime;
double velocity = Math.sqrt(Math.pow(horizontalVelocity, 2) + Math.pow(verticalVelocity, 2));

// converting tangential velocity in m/s into angular velocity in ticks/s
angularVelocity *= (Constants.ENCODER_TICKS_PER_REVOLUTION * Constants.TURRET_GEAR_RATIO) / (2 * Math.PI); // angular velocity in ticks/s

double theta = Math.asin((Constants.GRAVITY * flightTime) / velocity);
return new TrajectorySolution(angularVelocity, theta);
}
}

public class TrajectorySolution {
private double angularVelocity;
private double theta;

public TrajectorySolution(double angularVelocity, double theta) {
this.angularVelocity = angularVelocity;
this.theta = theta;
}

public double getAngularVelocity() {
return angularVelocity;
}

public double getTheta() {
return theta;
}
}


### Next Steps:

The next step is to use PID control to maintain target velocities and angles. The calculated angular velocity $$\omega$$ can be set as the target value of a PID controller in order to accurately have the flywheel motor hold the required $$\omega$$. The target angle of launch above the horizontal $$\theta$$ can easily be converted into encoder ticks, which can be used again in conjunction with a PID controller to have the elbow motor maintain a position.

Another important step is to of course figure out how $$d$$ would be measured. Experimentation with vuforia and/or distance sensors is necessary to have a required input to the trajectory calculations. From there, it's a matter of fine tuning values and correcting any errors in the system.

# Build Progress 1/30

30 Jan 2021
Post 29
Awards: design, innovate, think, and mechanical

Build Progress 1/30 By Trey, Justin, and Jose

### Task: assemble different intake prototypes

Today we worked on different intake systems to place the rings in the launcher. We finished our first prototype for a belt type intake and lift. The 3d printed belt was able to slide rings along a vertical piece of polycarb to place rings into the launcher. The speed of the motor and belt makes this one of our quickest intake and delivery prototypes. Our other prototype was a spatula shaped "intake" that would scoop up disks, and flip them upwards into a basket on top of the launcher. We used aluminum CNC'd into a curved spatula that would perfectly fit around the disks to ensure an accurate launch. Rubber bands pull the spatula upward, where it hits stoppers and launches the rings upwards. This prototype created semi consistent flips, but it was hard to gauge how far down to pull the spatula to give a desired launch height. A problem with this method is the many different factors that can be changed to give an optimal launch. Different launch angles, distances from the launcher, rubber band tensions and lengths. This flipper would involve a lot of experimentation that would result in mostly failures. This method also requires a lot more driver skill to scoop up the relatively small disks.

We also tested our fully assembled launcher - the Ringslinger 9000 - with working code. We wanted to measure how consistent our launches were by shooting multiple rings at a target and measuring the furthest distance between impact points. We used flour on a flat surface to show where the rings were hitting, then circled the clusters for our trials to get an approximate radius of error. We found that our launches were mostly consistent within a small radius, but had outliers that were hitting the exact same outer lying spot. This indicates a consistent flaw with our launcher and requires a closer look at how it moves and launches the rings. We also repeated this test by identifying where the rings tended to cluster when they had been launched beyond the length of the goal-post - even though the Ringslinger 9000 was not supposed to launch rings at such a height, identifying where it tended to cluster after landing also allowed us to evaluate its general launch patterns and accuracy.

### Next Steps:

The belt system can easily grab disks and brings them to the other end of the ramp very quickly. While it works well when we test it with our hands, we need to create a rigid structure to connect the belt and ramp, which will be mounted on the chassis. This will allow us to see how the belt will need to pivot to grab rings, and if our current belt still maintains grip without human assistance. We will also take a closer look at our launcher to see what's different about our outlier launches.

# Programming Session 1/31

31 Jan 2021
Post 30
Awards: control

Programming Session 1/31 By Mahesh and Cooper

### Task: Set up FTC Dashboard

We wanted to setup FTC Dashboard for graphing, configuration, vision, and later on, odometry. FTC Dashboard enables graphing of numeric variables, which can simplify PID tuning enormously through plotting the current position/velocity and the target. Additionally FTC Dashboard enables real-time editing of configuration variables, and in the context of PID tuning, this enables PID constants to be edited on the fly. With the later goal of implementing odometry for localization, FTC dashboard can be used to draw the robot's pose (position and heading) on a canvas, to easily confirm the accuracy of our odometry calculations. Dashboard also allows for images to be sent, allowing us to also debug our OpenCV vision pipeline.

We used FTC Dashboard during this coding session to tune the coefficients of our newly created flywheel velocity PID loop. This would ensure that our flywheel would be able to maintain the desired angular velocity we want it to, in order to consistently shoot the disk into the goal using our trajectory calculator.

### Next Steps:

The next step is to harness the power of FTC Dashboard to verify our odometry calculations by drawing the robot's pose information onto the canvas, using vectors/arrows to signify the base's heading, the turret's heading, and the bearing from the robot to the goal. This would point out any glaring errors in our odometry calculations, and would serve to visually represent the degree of error our calculations would naturally experience as a result of slippage and other factors.

# Pink v. Cyan Remote Scrimmage Post Mortem

31 Jan 2021
Post 31
Awards: control and innovate

Pink v. Cyan Remote Scrimmage Post Mortem By Cooper and Jose

### Task: review the progression of matches in our latest scrimmage

We participated in the “Pink v. Cyan Remote Scrimmage” over the week, wherein we submitted our matches at an appropriate amount of time before the cutoff time. Doing this scrimmage has given us good insight into how to tune the performance of what is on the robot already, and what needs to be added. We submitted the standard 6 matches, and I want to go in depth for each.

Before I delve into the weeds, I would like to explain our hypothetical perfect run for these matches. In auton, since we aren’t using vision quite yet, we had the robot always assume a 4 stack. The robot should put the wobble goal we are holding in the start ibn the appropriate corner tile, then backup to park on the line. In teleop we should retrieve the second wobble goal and put it across the line. With this all such that we can, in the endgame, put both of the wobble goals over the back wall. So therefore, in a perfect run, we could have 60 points max. An example can be seen in the video above.

Match 1: Starting off on the wrong foot, when we started auton things looked fine. However, our pink decorations on the front of the robot got caught in the front caster wheel, making us veer off and hit the wall. We were able to re-orient the robot since the next few steps of the auton were based on the imu. However we didn’t park due to being off of the expected final position of the first movement. During teleop we successfully moved both of the wobble goals over to the other side of the shooting line, and then in teleop we just barely ran out of time putting down the second wobble goal over the back wall.

Match 2: We got lucky in the second round and got the preferred 4 ring stack. However, we couldn’t make use of that luck due to a driver error when selecting the auton-- auton did not execute. So in teleop, we moved both wobble goals over to the correct side of the shooting line. Then, in the endgame, we successfully moved one wobble goal over the wall. The second we ran out of time trying to grab.

Match 3: This time around, we had the opposite happen from the last round in auton. The rings randomized to be a 1 stack, but auton performed perfectly. Teleop was nominal, but endgame posed a new problem. When trying to put the wobble goal over the wall, it got stuck on the turret, seen in the video below at 2:44. This costed us enough time to have us not score any of the wobble goals

Match 4: this is the video at the top of the post, because it was a perfect match.

Match 5: Like match 3, we were randomized 1 ring, and auton performed perfectly. Unlike match 3, teleop and endgame were normal, with us scoring 1 wobble goal.

Match 6: Final match, auton almost worked. The wall-following messed up at the very end of the first run, making us drop the wobble goal just out of the box, and miss parking. In teleop/endgame, we almost had a repeat of match 3, but we were able to shake off the wobble goal and score one.

To start on the subject of lessons learned, It is obvious we should practice more. Driver practice has always been a weak area for us.(Having said that, for the amount practiced the driver did excellent). One thing the driver should not have had to account for is that possibility to lodge the wobble goal on the robot. This is subject to change anyways, as when the launcher is mounted on the robot, the wobble gripper is going to have to move. Not only move, but change; the current gripper has too tight a tolerance to be used effectively. It isn’t possible to have it stay the way it is when drivers will also be tasked with picking up rings. Finally, we learned that we need to work out the kinks in the wall following what happens at the beginning of auton. We only really did this, because we are still working on a better way to square the IMU to the field, and the human error was too great and cumulative on that far run to have it work reliably.

### Next Steps

Execute the solutions to the problems found.

# Intake Iterations Summary

03 Feb 2021
Post 32
Awards: think, innovate, and design

Intake Iterations Summary By Bhanaviya and Ben

### Task: Go over our 5 intake iterations

This season, we experimented with 5 gripper models - both for our robot in three days project and for our competition bot. While we do not plan on using all 5 of these models, they allowed us to effectively implement the engineering process within our build season. Experimenting with each intake helped us to identify the potential of each design as well as how two individual designs could be combined to create a more efficient one. Each of these designs has its own article but this is just a summary of all of our intake designs so far.

### 1)Archimedes Intake

This was one of our first designs and it was based on an Archimedes screw. A screw shaped surface would draw the rings from the fields and directly to the launcher. While this would have been a great feeder, our primary issue was that would essentially be a slower system which could likely only draw in ring at a time so it never progressed past its CAD stage.

This gripper functions with a series of omniwheels mounted in between two rev extrusion bars, which in turn are connected to a ladder-like assembly with a control hub mounted on the first rung of the ladder and to the wheels. As the wheels rolled, they would slide on top of the rings and roll them into the system. The issue with this system was that it had significant delay in "rolling" the rings in since if the omni wheels spun too fast, they would lack the tracton to "grip" onto the wheel.

### 3) Belt Sander Drive

This system was far more simplistic than our earlier ones and had a faster intake speed during testing too. The actual drive would be mounted onto the robot with the "back" of the system sliding over the rings and carrying them across the conveyor belt to the top of the robot. Despite its efficacy, it had one main issue - it didn't have the gription needed to ensure the rings slid across the belt.

### 4) Caterpillar Intake

Luckily, the gription issue could be resolved pretty easily with the caterpillar intake. This system was dual tracked unlike the first one, and had rubber bands threaded through the tetrix tracks to improve gription with double the power. Ultimately, this was a pretty successful issue but it did not have as much speed as it could have and lacked the signature Iron Reign charm.

### 5) Ringevator Ultra Flex Unlimited Intake

This gripper, the Ringevator, for short was a combination of our two previous best systems - the belt sander drive and the caterpillar. It possessed the mono-drive from the belt sander and similarly drew in rings from its back and carried them across a conveyor belt to the top of the robot and like the caterpillar, had a means for increasing friction with the surface of the rings. While the caterpillar intake did this with rubber bands, the Ringevator accomplished it with ninjaflex "fins" layering the "belt" to sweep in the rings. Both sides of the intake are covered with polycarb to encase the conveyor built internally and to ensure the rings don't fall off when picked.

### Next Steps

Now that we have analyzed all of our intake designs so far, it will be easier for us to streamline the best design to mount on the robot. While the ringevator seems to be our best choice, we still need to conduct further testing to see which one is the most efficient.

# Materials Test Planning

04 Feb 2021
Post 33
Awards: think and design

Materials Test Planning By Bhanaviya

### Task: Create a system to test our materials to better understand their grip potential

Here at Iron Reign, we're used to using off-the-shelf materials for our robot. For this season, these include pillowcases (front and back) and an Einstein wig, since we are looking for materials with lesser grip. However, we need to do a thorough investigation of these materials before we can determine their efficacy on the robot.

Specifically, we plan to implement these parts on a ramp connecting the intake and our launcher. Although we have not yet mounted our intake onto the robot, we expect to have a launch leading down from the intake to the launcher to enable to ring to slide down and then be launched. This requires a material with very less grip and a lot more slip. However, before we can decide which material would have the best grip, we need to test them to determine their on-robot properties. To do this, we will implement a slip test as shown below.

The main thing that we want to test is the amount of energy they have while sliding and then the amount of energy they lose upon collision. We plan to test this through the coefficient of friction of the mitts. Simply put, we will place the ring on top of the of the pillowcases/wig and will tape down the material being tested on a flat surface. Then, we will lift the surface and using simple inverse trigonometric properties, we will calculate theta, the angle at which the stone begins to slip from the material. The bigger the angle, the higher the friction coefficient of the material, which equates to it having better grip. Since we are looking for a material with the least grip possible, we will be looking for the material with enables the ring to slide down at the smallest angle.

### Next Steps

With our testing planned out, we will next begin documenting the angle at which the ring slips from each type of material. The calculations from the actual testing, including the equation we used, will be inputted into a separate post.

# RingSlinger 9000 Summary

05 Feb 2021
Post 34
Awards: design and innovate

RingSlinger 9000 Summary By Jose

### Task: Summarize the key components of Ring Launcher 9000

A ring launcher is more than just a flywheel; it needs a barrel to give the ring a path to move through. A 90 degree barrel is the best fit for ROBOT as the intake will take up the other half of the robot. The plan is to later on add an indexer to transport rings from the intake to the barrel in a way that can be controlled, that is, allowing the driver to manually choose when to let rings into the barrel.

The barrel design looks simple, but there are lots of hidden things making it work as intended. For one, the motor driving the flywheel is attached via a slotted motor mount. The mount is then placed directly on the center plate through an extension to the center plate. Additionally, there is a plate below the one that the ring travels on top of. This plate is used to keep the shaft in place, it follows a similar shape to the others to preserve strength, as it is half of what keeps the flywheel in place. The bottom plate also supplies support to the center plate, this is due to the fact that the center place is not attached to the flywheel, instead it has 3mm of clearance in case of any vibration the flywheel may have. Finally, at the exiting end of the barrel, the side wall extends linearly to ensure the ring doesn’t spin off its intended path.

Over to the other side of the barrel is the ring feeder. A huge nylon wall guides the rings into the ring flipper. The ring flipper is composed of a a servo with a custom made flipper to push rings into the flywheel.

### Next Steps:

With everything milled out and 3-D printed, the next step is to take this to programing as the idea is to have the ring laucher be almost completely automated.

# Ring Launcher 9000 On-Bot Testing

05 Feb 2021
Post 35
Awards: control and connect

Ring Launcher 9000 On-Bot Testing By Cooper and Jose

### Task: Test the intake now that it is on the robot

Today we performed proper field testing of the Launcher subsystem. While we have done many tests in the past with it, this was the first time we ran arrays of consecutive shooting with the launcher on the robot. Doing this meant some small modifications that led to an evolution of the “trigger” of the subsystem. Performing the tests was one of my friends, who we let drive the robot to gauge interest in being in the robotics program, and his ability driving.

First, lets cover the trigger evolution, which is what lets us more smoothly conduct the tests. As it stood, and as pictured above, the trigger was a single spike-like piece of 3-d printed nylon attached to a servo. Wherein it pushes rings into the flywheel to shoot them. It’s main body follows the contour of the shooter’s body that is directly above and below it, as to conserve space. We initially thought that this would be feasible to keep so small, however, we noticed in previous testing that the rings did not chamber correctly when fed by the in-built gravity-fed magazine. The ring would fall onto the trigger, and tilt backwards, leading to the ring getting jammed behind the trigger when it tried to return to its original position. That effectively meant that we could only shoot one ring before we would have to physically reload. To combat this, it was devised that a small plate would have to be added to the top of the trigger, protruding at the back top of the trigger. Since it was just me and the driver there that day, I fashioned a mock-up out of cardboard and painters tape, as seen in the video below. You might also notice a cardboard piece in front of the rings in the magazine, and this was another impromp-to thing, which addressed the unforeseen movement of the rings in the magazine during on-bot use. This ended up, later that night, for the resident CAD/CAM expert, Jose, to make adjustments to the model. The following day, a version of the trigger was printed that had the plate, and was tested/proofed to see that it worked as expected.

Moving on, let's talk performance. The shooter, after replacing the motor gears and removing an elastic band from the arm, did wonderfully. When firing consecutively in the same position, the effective spread of the shots was tight enough to actually hit whichever goal was being aimed for. The driver also came up with a test, where he would shoot a goal, move, and then return to the same position, to see if the turret auto-turn was fine enough. Turns out, having a different subsystem with different weight distributions means that the PID coefficients aren’t properly tuned. Of course this was to be expected, but it wasn’t too off, suggesting that all that needs to be done is to adjust ki and kd.

### Next Steps:

Tune said coefficients, make a final version of the magazine retainer, and further test the driver.

# Accounting For Initial Height

06 Feb 2021
Post 36
Awards: think and control

Accounting For Initial Height By Mahesh

### Task: Account For Initial Height

In the previous trajectory calculations post, "Derive And Translate Trajectory Calculations Into Code", we did not take into account how the length of the launcher would effect our calculations. In reality, the height the disk would have to travel would be shortened by the launcher, since when titled at an angle the vertical distance would be shortened by $$lsin(\theta)$$, where $$l$$ represents the length of the launcher. This is because our launcher is mounted on a hinge, and therefore the rotation of the launcher affects the position where the disk leaves the launcher.

To take this into account, we would have to add $$lsin(\theta)$$ to the vertical distance the disk has to travel, however, $$\theta$$ depends on this distance as well. To solve this problem of circular dependency we can use an iterative method. This is because when $$\theta$$ is calculated for a given trajectory, the initial height of the disk will be raised by $$lsin(\theta)$$. This means the disk has to travel less distance vertically, meaning that $$\theta$$ will be smaller with the new launch height. But, when $$\theta$$ is decreased, so will the launch height, will in turn will raise theta, and so on. This process is convergent, meaning that iterating the process described above will eventually yield a $$\theta$$ whose change in the launch height is reflective of the launch height's change in theta. The following process can be used to find the convergent $$\theta$$:

1. Calculate $$v_0$$ and $$\theta$$ from the current launch height
2. Find the new launch height given the previously calculated $$\theta$$
3. Repeat steps 1-2

We graphed out the convergence of $$\theta$$ to confirm that these calculations would work correctly. Below is an image of the convergence of $$\theta$$ given a distance of 4 meters and a launcher length of 0.3 meters:

To exaggerate the effect here is another image with a launcher length of 1.8 meters:

### Next Steps:

The next step is to implement this in code to account for the height of the launcher, a fairly simple task. Tuning the iterations for performance vs accuracy won't really be necessary since $$\theta$$ seems to converge exponentially and iterations happen very quick on modern hardware anyway.

One concern still exists which is that the horizontal distance the disk has to travel is also effected by the launch angle $$\theta$$. However, this would only effect the distance by a matter of fractions of a centimeter, so it is likely not a big problem. If significant errors are encountered which cannot be traced down to other hardware or software defects/bugs then we can consider taking into account the effect that $$\theta$$ has on distance, and vice versa.

# Meeting Log

06 Feb 2021
Post 37
Awards: think, innovate, and design

Meeting Log By Ben, Bhanaviya, Cooper, Jose, and Trey

### Task: Prepare the portfolio and intake before the qualifier

The three of us worked on the engineering portfolio, discussing what we needed to get done in these 3 weeks between now and the qualifier. It was agreed that Ben, Bhanaviya, and Jose would be largely responsible for the portfolio and having other team members add information when necessary. We also began drafting an email to a physics professor who may help us with our physics calculations.

Trey and Justin mostly worked on rebuilding the ring intake to make it easier to mount onto the robot. They also rebuilt parts of it to make it easier to service in the future. There were little issues with this, although access to the robot was limited at times during code testing. Time constraints also played a role in the progress that was made.

Cooper had planned on calibrating the ticks/degree on the arm, implementing the trajectory calculator, fixing the LED on the robot, and making progress on Vuforia. By the end of the work period, he had successfully calibrated the ticks per degree on the robot arm and implemented the trajectory calculator. He decided to fix the LED later because of its low priority and time constraints restricted progress on Vuforia.

### Next Steps

The next steps for the portfolio are to begin formatting and gathering information for all the subsystems and from team members. Once we have all the information, we will have to condense it into an easily-digestible 15 pages. We will also have to fix the LED lighting solution on the front of the robot, along with troubleshooting Vuforia.

# Adding Margins Of Error To Desmos

13 Feb 2021
Post 38
Awards: think and control

Adding Margins Of Error To Desmos By Mahesh

In order to visually represent the significance of placing the constraints we did, we modified our desmos trajectory calculator to include a margin of error box. This box would help to highlight the importance of keeping the summit of our trajectory aligned with the goal, and how deviations from the summit would result in drastically increasing margins of vertical error for the same horizontal error.

As seen above, even with the same theoretical horizontal margin of error, having the goal (which can be thought of as the center of the error rectangle) placed further from the summit of the trajectory results in a larger vertical error. This helps to visually justify why we chose to have the summit of the disk's trajectory at the height of the goal, because the disk's vertical margin of error is minimized with that constraint.

Additionally, we are able to minimize the energy required to launch the disk. This is because, by the law of conservation of energy, the energy at any point in the disk's launch must be equal to the energy at any other point. We can consider the point where the disk is about to be launched from the launcher and the point where the disk is at it's maximum height. The total mechanical energy (kinetic energy + gravitational potential energy) of the disk in these two points must be equal.

Kinetic energy is represented by $\displaylines{K = \frac{1}{2}mv^2}$

and gravitational potential energy is represented by $\displaylines{U_g = mgh}$

The higher the disk goes, the larger the total mechanical energy of the disk at the highest point in it's trajectory, since $$U_g$$ is proportional to $$h$$. And by the laws of conservation of energy, the energy at the start of the launch would have to equal this larger mechanical energy for the disk to reach a higher altitude. By having the disk only go as high as it needs to in order to reach the goal, we minimize the total energy we need to put into the disk and the initial velocity of the disk at launch (since $$K$$ is proportional to $$v^2$$). This is ideal for our flywheel as the likelihood of it being not fast enough is minimized.

The link to the edited desmos calculator can be found at https://www.desmos.com/calculator/csxhdfadtm, with $$E_c$$ being the variable to control the center of the error rectangle and $$E$$ being the variable to control the margin of horizontal error.

# Ringslinger 9000 Step-by-Step Guide

13 Feb 2021
Post 39
Awards: innovate and design

Ringslinger 9000 Step-by-Step Guide By Anisha, Paul, Trey, and Cooper

### Task: assemble different intake prototypes

The Ringslinger 9000 is a crucial part of the robot and requires careful planning to build. Although we have a relatively simple intake and launching mechanism, their components are a bit more complicated. After getting the individual pieces of our launcher system ready, we were able to start putting them together to form the system. This post will serve as a step-by-step guide on how the entire launching system was assembled.

The process starts with the launcher baseplate which was constructed using aluminum and was cut on the CNC mill. As shown in the picture above, several holes were strategically placed in various areas on the periphery of the plate for screws to go to hold the other elements such as the Ultraplanetary REV motor that powers the flywheel and the nylon guide wall which guides the rings as they move through the system. The plate itself is mounted onto 2 REV extrusion bars using several metal brackets as shown below.

The bars are mounted onto a hinge which carries the entire system and rotates as needed during the game.

#### Launcher Guidewall/extension

The custom-printed guidewalls are attached to the plates using retaining screws, and function to guide the rings to the flipper to be prepared for launching.

#### Motor Mechanism

The REV 3:1 Ultraplanetery motor which drives the flywheel is attached via a slotted motor mount as shown below. It is then placed on an extension of the launcher baseplate using 6 screws. The motor can spin its sprocket at 1,727 RPM and drives the wheel by a belt between the two sprockets.

As mentioned in the Ring Launcher Summary, our launching system essentially is made out of 3 levels: the mounting, driving, and ring levels. The pictures below show the driving level's center plate with 3D printed nylon spacers mounted to separate it from the ring level. The spacers closest to where the flywheel will be attached each contain 2 holes and are attached by screws. The larger spacers also contain 2 holes where screws are attached to mount the driving and ring levels together. After getting the two individual levels ready, they are put together using screws, as shown below.

Shown below is the custom-made servo spacer. The servo is mounted next to the opening that is next to where the motor is mounted. It is fixed into place using screws.

Pictured below is a bird's eye view of the center plate. The servo located on the back of the ring slinger essentially spins the ring flipper to exert motion onto the rings to prepare them for launching by pushing them into contact with the flywheel. The REV Ultraplanetery motor is mounted onto the platform using 4 screws and nuts and the servo is mounted also using 4.

The flywheel is composed of a NinjaFlex center wheel which is sandwiched between 2 custom aluminum plates.

The flywheel's upper aluminum plate works to keep the wheel from flying upward. A polycarbonate sheet works with its lower aluminum plate to fix the axle in place. The polycarbonate sheet is shown below. It also plays a role in keeping parts in place.

The Flywheel is attached to a pulley which drives it using the belt that runs from the wheel pulley to the REV motor. As seen in the CAD model above and the picture below, the wheel was assembled by connecting the 2 aluminum plates to the NinjaFlex wheel in the center using screws. The flywheel spins on the shaft that is locked into place with the shaft collar on each end.

As shown above, the whole launching system to the arm that sits on a pivot in the back of the robot which adjusts itself by rotating to the angle that is ideal for where a ring needs to be launched to.

Finally, a look at the robot after all the individual parts were assembled is pictured below.

### Next Steps:

One of the highlights of this system is that it is completely custom-designed and built . All our parts were either 3D-printed or custom-machined on our CNC. Documenting its assembly allows us to keep track of all of the parts involved in its print. Being able to showcase the build stages of the Ringslinger 9000 is also incredibly useful for two more reasons. First, if we ever intend to build a second one, we have the progress of the first one fully documented for inspiration and/or to isolate potential causes of structural error. Second, if any teams who follow our blog want to create a similar model, they have ours for a source to help. As the launcher continues to undergo changes, it is likely we will create another such assembly post - likely after our first qualifier in 3 weeks.

# Achieving Continuous Targeting and Launching

17 Feb 2021
Post 40
Awards: control

Achieving Continuous Targeting and Launching By Mahesh and Cooper

### Task: Achieve Continuous Targeting and Automatic Launching

With the goal of having the turret continuously aim towards the goal, the elbow tilt to the correct angle at will and the flywheel to ramp to the correct velocity at will, we began by verifying our odometry calculations using FTC dashboard. Our odometry calculations would be the cornerstone of our entire automatic launching system, since the distance between the robot and the goal as well as the bearing to the goal from the robot would both be determined using the robot's x and y position as given through odometry. Using FTC dashboard's field overlay, we were able to draw our robot as a circle onto the given canvas like so:

In the above image, the bottom circle represents the robot, with the top circle representing the goal. The longest black vector represents the heading of the drivetrain or base of the robot. The second to longest red vector represents the heading of the turret of the robot. The shortest blue vector, which is the same size as the circle robot itself, represents the bearing from the robot to the goal.

The blue and red vectors (bearing to goal and heading of turret) are equal in direction because of the PID loop running to continuously target the goal. We are able to accomplish this by setting the target heading of our turret PID controller to the bearing between the robot and the goal, which can be calculated with: $\theta = tan^{-1}\left(\frac{y_{goal} - y_{robot}}{x_{goal} - x_{robot}}\right)$ The PID controller compares this target angle with the IMU angle of the turret and corrects for them to be equal.

As for the other part, automatic launching, we were able to achieve this using our previously made trajectory calculator. The input to our trajectory calculator, the distance between the robot and the goal, was calculated using: $distance = \sqrt{(y_{robot} - y_{goal})^2 + (x_{robot} - x_{goal})^2}$ The outputs of the trajectory calculator, the angle of elevation of the elbow and angular velocity of the flywheel, were then set to the targets of the elbow PID and flywheel PID controllers, in order to consistently hold the desired articulation. When the flywheel ramped up to a velocity in a 5% error threshold of the target velocity, we toggled the trigger servo and launched the disk, with the ramping of the flywheel seen below through FTC dashboard:

### Next Steps:

By testing our continuous target and automatic shooting system, we quickly realized our calculations were slightly off. The next obvious step is to diagnose any sources of error in our calculations and account for them appropriately. The main one being how the angle of the launcher affects the vertical distance travelled by the disk (initial height of launch), and vice versa. This can be done using the convergent, iterative process described in a previous post. Other sources of error could include the turret being offset to the right of the center of the robot, and a later discovered glitchy flywheel power cable. We can now advance from simply implementing our theoretical calculations to diagnosing issues with them and addressing errors in our robot.

# Control Mapping

20 Feb 2021
Post 41
Awards: Control

Control Mapping By Bhanaviya, Mahesh, and Cooper

### Task: Map and test controls

With our first qualifier being a week away, Proteus (our robot) needs to be in drive testing phase. So, we started out by mapping out controls as depicted above.

One stark difference between this control map from previous years is that there a lot more controls than previously since one of our team goal's this season was to reduce human error as much as possible when it pertained to driving and having more expansive controls was reflective of this goal. For instance, last year, when our turret was still in use as in this year, we had two controls for rotating the turret. However, this season, since turret rotation allows us to maximize our capabilities when it comes to continuous targetting, we've set aside 4 controls for turret rotation alone since being able to vary its speed manually is something we've had difficulty with earlier in the season.

### Next Steps

As the season changes, we expect our controls to change as well and we will document these changes accordingly as time progresses.

# A Lot to Intake

20 Feb 2021
Post 42
Awards: innovate and design

A Lot to Intake By Paul

### Task: Prepare the intake before the qualifier

Today’s meet consisted of Cooper working on code, Paul burning polycarb, and Trey working on the intake with Paul. We were able to get the ringevator-esque intake working with some level of reliability, at least off the robot. The design is quite ingenious, using the friction of the rings against the floor and a polycarbonate scoop-type thing to integrate the flipping of the rings and the lifting of the rings into one cohesive unit, that saves space, motors, and weight. Paul was in charge of heat-bending the polycarbonate plate, but Paul overheated it and ended up warping the plate. However, this proved to be quite useful, as the warp helped to hold the rings against the ninjaflex elevator belt. Sometimes, rarely, screw-ups are a good thing.

Meanwhile in the robot garage dungeon, Cooper was working on optimization of the code and helped to optimize the odometry, calibrating the robot's autonomous mode to be more accurate based on its surroundings, using both the IMU and potentially an intel RealSense camera in the future. In addition, Cooper worked to enhance the robot’s position holding and automatic targeting systems, helping to ensure that the ring lands in the goal, every time, automatically. Pretty neat stuff.

In the more whimsical department, the robots 12-round chefs-hat extendo-mag turns the robot from an FTC legal precision machine to a motorized fear-inducing machine. This extended mag was used for demonstration, target testing and shooting rings at unsuspecting team members only, as FTC regulations only allow the robots to be in control of 3 rings at a time, not 12 (though that would be kinda cool).

### Next Steps

With the ringevator mounted, we plan to get the mag removed by the next meet to create more precision with our launcher system.

# Accounting For Offsets And Launching In Motion

21 Feb 2021
Post 43
Awards: control

Accounting For Offsets And Launching In Motion By Mahesh

### Task: Build A Forward Kinematic Model Of The Robot To Account For Turret And Muzzle Offsets, And Counter-Lead The Target To Allow For Launching In Motion

After building the base of a trajectory calculator to allow for continuous targeting and launching, the next step was to address the discrepancies between our robot in code and the real robot, a major one being the offset between the muzzle compared to the center of the robot. Thus far, we had been treating the muzzle exit point as the center of the robot, which in reality isn't the case. The center of the turret is positioned behind the center of the robot to be flush with the back edge, and muzzle is positioned in front of and to the right of the center of the turret. In order to account for these offsets in code, we would have to build, in technical terms, a forward kinematic model of the robot to figure out the final (x, y) position of the muzzle, or the point at which the disk leaves the robot.

To account for the turret's offset we calculated the center of the turret to have the coordinates: $\displaylines{x_t = x_r - dcos(\theta_r) \\ y_t = y_r - dsin(\theta_r)}$ where $$x_t$$ and $$y_t$$ represent the x and y coordinates of the turret respectively, $$x_r$$ and $$y_r$$ represent the x and y coordinates of the robot respectively, $$d$$ represents the distance between the center of the robot and the center of the turret, and $$\theta_r$$ represents the heading of the robot's base.

We then took $$x_t$$ and $$y_t$$ and used them to calculate the muzzle exit point using a polar approach: $\displaylines{x_m = x_t + rcos(\theta_t + \theta_m) \\ y_m = y_t + rsin(\theta_t + \theta_m)}$ where $$x_m$$ and $$y_m$$ represent the x and y coordinates of the muzzle respectively, $$\theta_t$$ represents the heading of the turret, and $$r$$ represents the "radius" of the muzzle, and $$\theta_m$$ represents the "angle" of the muzzle. In reality, the terms "radius" and "angle" of the muzzle don't make sense since the muzzle is positioned in front of and to the right of the turret, and using a cartesion approach we would have to make two separate adjustments for the x and y for the vertical and horizontal offsets, however converting these offsets into a polar form can help to simplify the process, and is where a "radius" and "angle" are derived from. If the horizontal distance between the muzzle and the turret center is $$o_x$$ and the vertical distance between the muzzle and the turret center is $$o_y$$ (when the robot is viewed from the top-down), then $$r$$ and $$\theta_m$$ can be derived like so: $\displaylines{r = \sqrt{o_x^2 + o_y^2} \\ \theta_m=tan^{-1}\left(\frac{o_y}{o_x}\right)}$ $$r$$ and $$\theta_m$$ are used in the previous equations for $$y_m$$ and $$x_m$$ to derive the final position of the muzzle exit point, and completes the "forward kinematic model" of our robot for trajectory calculation purposes. $$x_m$$ and $$y_m$$ are then substituted for $$x_r$$ and $$y_r$$ in all trajectory calculations to account for all offsets from the center of the robot. In the first image on this post, the turret can be seen repositioned from the center of the robot with a heading labeled with a red vector, and the muzzle can be seen with a smaller circle containing a neon-green line to the currently selected target.

Our second task was to allow the robot to launch at its target while in motion. The first step of achieving this would be to address how the robot's velocity in the x direction would affect the trajectory of the disk. We would have to counter-lead the target in the x direction to account for side-to-side motion of the robot while launching. This is because when the robot is moving with a velocity $$v_x$$ in the x direction while launching, the target will be offset by a factor of $$v_x \cdot t$$, where $$t$$ represents the time the disk spends in the air. To account for this we can simply subtract $$v_x \cdot t$$ from the target's x position in order to counter-lead it.

To account for the robot's velocity in the y direction ($$v_y$$) we can subtract $$v_y$$ from the disk's horizontal velocity calculation, which then becomes $$\frac{d}{t} - v_y$$. This effectively adds the robot's y velocity onto the y velocity on the disk, which reduces the needed horizontal velocity of the disk, hence why $$v_y$$ is subtracted.

With these two additions, we can now, at least theoretically, launch in motion. In practice, we saw that our underdamped PID controller could not keep up with the bearing to the counter-led target. In a perfect world, the turret's heading would equal the bearing the offset target, although due to poorly tuned PID coefficients, this was not the case. With some tuning we hope to correct this and get the turret to somewhat lock on to the offset target while the base is in motion.

### Next Steps:

Our next steps would be to continue addressing small errors in between our robot in code and our robot in the real world, perfecting our trajectory calculator to maximize accuracy and precision. From a few tests we determined our successful shooting rate was around 75% from a fixed location, which can be used to conclude that there are mechanical faults at play as well, which could be a non-stationary elbow or unbalanced flywheel. These are all investigations to delve into later in order to perfect our automatic launching.

# A Lot to Intake

22 Feb 2021
Post 44
Awards: innovate and design

A Lot to Intake By Paul

### Task: Prepare the intake before the qualifier

At today's meeting, Paul worked on the ringevator, with the guidance from Mr. V. The intake mechanism required a motor to be installed, which at first glance seems like light work. However, the intake is composed of two separate parts that move independently, connected by a hinge. The motor had to be attached to the static, robot part, however, the power had to be transferred to the belt, which just so happened to be on the dynamic part that swings around like a screen door in a hurricane, so mounting the motor on the swingy bit was out of the question. Paul took a page out of last years book, drawing inspiration from the elbow mechanism of Icarus and with some help from Mr. V, designed a mechanism that allowed the belt and hinge to rotate on the same axis, ensuring constant distance between the motor axis and the axis of rotation for the belt pulley. This allowed the motor to be mounted in a safe spot on the robot, away from the dangers of an FTC field, while simultaneously being able to drive the belt mechanism on the moving part of the robot. Future plans call for replacing the pulley drive bushings with custom fabricated ball bearings, and moving the motor further down the robot to lower the center of gravity.

### Next Steps

The ringevator still needs to be mounted on the robot but this was enough progress to hopefully get us to a working intake before the qualifier.

# Morph Chart

24 Feb 2021
Post 45
Awards: think, innovate, and design

Morph Chart By Bhanaviya and Ben

### Task: Create a flow chart to analyze all our intake designs so far in this season.

Iron Reign has seen several iterations of our intake over this past build season. With our first qualifier being 2 days away, its finally time to come full circle and identify the different iterations of our intakes coming together. To do this, our team used a flow chart. A morph chart shows the various subsystems of our 2 robots in this system - our robot in 2 days bot Frankendroid and our competition bot TomBot.

Each intake's progression is represented vertically, shwoing stages from the sketch, to the CAD to the final product. For the Ringevator intake design in particular was inspired by a combination of two other intaek designs - the belt drive and caterpillar. The combination of these two designs, as well as a description of each design is also represented on this chart.

### Next Steps

Placing all of our designs in one chart like this allows us to see how iterative our design process has been, and how much of an influence each design has had on another. With all of our designs so far placed in the flow chart, our next step is to continue to update the chart after our first qualifier so that we can have a pictorial summary of our entire build season for reference.

# Ringevator Overview

25 Feb 2021
Post 46
Awards: design, innovate, think, and mechanical

Ringevator Overview By Trey

### Task: Describe the construction and development of the Ringevator intake

This year we have done a lot of work on intakes and launchers. The purpose of this post is to go over the function and overall design and build of the Ringevator intake. It doesn’t go too far in-depth so if you are looking for something more specific I would recommend that you look at specific posts discussing different parts of our design but if not you are in the right place.

### Build Breakdown:

The construction of the Ringevator is moderately complex. It consists of a custom belt, two axels, a motor, a pivot, a base, and some elastics. The belt is custom modeled and printed in NinjaFlex. The design is based on the belt seen in one of our previous robots, Kraken, which competed in 2018. It has flaps that do the work of pulling in the rings and holes that are used by sprockets to drive the belt. The holes are the exact size and space apart to be fitted onto the sprockets on the drive axels which are attached to the base. The base is a simple H design that used to be in between the sprockets but now sits so that the sprockets are inside to make mounting easy. The axels are driven by one motor attached by a belt on the base of the robot.

As you can see in the photo above, the belt assembly base and the robot base have a pivot between them. The purpose of this pivot is to make picking the rings much easier. Normally you would have to pick a ring up horizontally and then turn it to a vertical orientation which is what we need but instead, the pivot allows for the belt assembly to walk over rings. This means that when the intake reaches a ring, the movement of the belt causes the mechanism to open and consume the whole ring. Since only one side of the ring is being pulled up by the belt, it is flipped vertically and travels up the rest of the mechanism and out the top. The elastics make sure that the belt keeps in contact with the ring at all times. The only other thing that is apart of the design is a guide ramp on the inside made of heat-bended polycarbonate. You can see a photo of this ramp below along with the intake before it was attached to the robot on a pivot.

### Testing:

We tested the Ringevator multiple times throughout its life to make sure that it will work. It gets a good grip on the rings and is able to pull them up most of the time. We still need to iron out a few tensioning issues with the elastics to make it more consistent but other than that it works well based on our tests so far which are few and far between. More testing will come.

### Improvements:

The design didn’t start out this well though, we made several improvements since the start. For starters, the whole pivot idea was a mistake, to begin with; however, we discovered while doing preliminary tests that the belt walking over rings was a feature, not a defect. We realized that picking up rings without the pivot would be far more difficult and that was the spark for the design we have now. We also suffered some grip issues with the polycarbonate ramp which wanted to grip the rings too much and hindered the ability of the intake. We fixed this with some friction-reduced tape and now it works well. The design is still in its baby stages so we haven’t found a lot of problems but we will eventually and we are excited to address them.

### Next Steps:

We are working right now on dialing in the shooter to make it more consistent and also testing a 1:1 motor to see how it compares to the 1:3 motor in terms of accuracy. We are also being posed with a challenge unlike any other challenge we have faced this season which is taking what we made when we were developing intakes and making a system that can feed into the shooter. This is going to prove a challenge because of the size of the shooter and the fact that it can be rotated or tilted to any angle. The challenge may be large but we are a worthy opponent.

# Making the Ringevator Legal

05 Mar 2021
Post 48
Awards: innovate, mechanical, and design

Making the Ringevator Legal By Trey and Paul

### Task: Make the Ringevator legal so we can use it in competition

We’re at the point now where we have a lot of our systems ready to be put on the robot, but we have to face another big challenge, which is making everything legal. Since the robot is a circle, we don’t exactly have any space to put an intake in the sizing cube. We can take advantage of the hypotenuse of the box by putting our equipment in the corners but then we raise the problem of height. This is because the Ringevator was never actually built to be permanently attached to the robot.

We built the Ringevator as a prototype that harnessed the abilities of all of our previous models without their problems. However, with time closing in, it became apparent that the ringevator would have to be on the robot regardless of what we think. In order to do this, we had to shorten the assembly by about 2.5 inches and somehow pull the assembly inside more. With only a few builders being able to join us at any particular time, this proved to be a challenge.

Two things needed to happen to make the robot even close to legal. The first was that the front would have to be chopped off, spitting the front Omni wheel assembly in two. And the second was actually shortening the ringevator which meant shortening the belt. The first part was easily accomplished by modeling two new Omni wheel bases for the front and surgically removing the front of the robot with a hacksaw. This was accomplished in the span of two days. After this was done, Paul also chopped the top of the ringevator off. The last piece was the belt.

The problem with the belt was that I was the only one who knew how to shorten it and I was stuck at home for the next few days. So after Paul was done with the robot surgery, he swung by my house at 3 AM and dropped the belt off in my mailbox. The next morning, I marked off about 5 inches or 5 flaps of the intake, printed a new rig for the welding, cut, and welded the belt into a shorter configuration with my own tools. Then to get the belt back to the robot, we thought about getting a courier to deliver it but instead, I showed up the next day with the new belt and it was assembled onto the robot. After all of that, the robot was still not legal. The reason why it wasn’t legal is because we used bulky REV extrusions as sides since they are easy for prototyping. Since those rails are thick it just barely falls out of the sizing cube. So we had to detach the whole assembly for our next competition.

### Next Steps

We would have liked to cut the assembly down more at this point but we couldn’t because we had already pushed the limits of its size. Our next step is to completely redesign the whole intake system. We knew this was going to have to happen at some point but we didn’t think it was going to be this soon. In order to make the intake legal, we have to CNC all of the parts. And I think that’s the kind of challenge Iron Reign is built for.

# UTD Qualifier Build Post Mortem

06 Mar 2021
Post 49
Awards: innovate, mechanical, and design

UTD Qualifier Build Post Mortem By Trey

### Task: Review our failure of rushed build leading up to the UTD qualifier

As discussed in the post "Making the Ringevator Legal" there was a lot of rushed build leading up to this qualifier. As a recap of that post, the Ringevator was too wide and too tall to be legal, so we had to cut off the front of the robot, split the omni wheels, shorten the assembly, and shorten the belt. For more information, read that post. So with all of this change leading up to the competition, one would expect that it all worked out.

Alas, it did not. By the end of the raised build, the robot was still not legal by any means. In fact, the ringevator had to be removed so that we could actually run matches with a legal robot. This, however, is not the end. Even though the robot may not be legal, the judges still respected the development we displayed in our journal and portfolio. We demonstrated real development in innovative systems that I suppose resonated with the judges because we were awarded the Inspire award. Ordinarily, any team would see this as a big accomplishment but the builders at IronReign were restless. We failed our goals. The end objective with building a good robot is to score high amounts of points and that’s the one thing we didn’t do.

At the very least we did learn quite a bit from the situation. Firstly, the troubles we had with the ring transfer from intake to outtake demonstrated that the pancake flipper was not a good idea. Such a path for ring transfer would be cool but a challenge too large for the coders. Besides, we already have put so much into the ringevator. Abandoning it now would be reckless. We also discovered that another pivot point at the bottom would be vital to the ring transfer. At the moment this is just a REV core hex motor but something more advanced would be helpful. There is also the added possibility of adding a slide to the bottom of the intake which paired with the current pivots, would make the intake far more versatile and clear of the spin of the turntable, which gets caught. There is still much thinking to be done in this department. Finally, the last thing we learned is that the ringevator would need to be remade in a fully custom, aluminum version to make it fit in the sizing cube. This will be a large feat but if we can do it, we will have points when our next qualifier rolls around.

### Next Steps

We’re going to need to do a lot more before our robot scores real points. I admire our progress but we still have a long way to go. We need to step up on driver practice, reevaluate the ringevator, and start thinking about a final version of the robot. What comes immediately next is modeling and redesigning the ringevator to lose any bulk in the system so it can fit on the robot. I hope that those new developments will allow us to run matches next competition.

# Future Plans For Programming

11 Sep 2021
Post 50
Awards: control

Future Plans For Programming By Mahesh

### Task: Plan Out Changes To Codebase and Use New Libraries/Hardware

This season, we plan to utilize the PAA5100JE Near Optical Flow Sensor (left image) and Realsense D435 Depth Camera (right image) to improve our robot's autonomous accuracy and reliability when running alongside other robots.

The optical flow sensor's potentially higher accuracy over traditional odometry deadwheels and immunity to slippage can make autonomous routines more reproducible. However, it is not a device that comes with out of the box FTC support, so a custom java driver will need to be translated from the existing python driver to have it correctly interface with the i2c ports on the REV Control Hub. Additionally, the device uses the SPI protocol for communication, so code will need to be written to convert the SPI calls to i2c, which can then be converted back to SPI via a i2c to SPI bridge chip.

As for the Depth Camera, a pipeline can be created to take its output, detect robots or other objects that the robot may collide with, and preemtively come to a stop during autonomous and possibly tele-op to avoid those collisions. This would save time spent communicating with an alliance partner prior to a match to determine where to place delays in an autonomous program to prevent collisions, since those delays would be performed automatically.

Furthermore, the optical flow sensor outputs movement in both the x and y directions, so only one is required to get xy localization on a holonomic drive. If we wish to also use the sensors for heading information instead of/alongside the IMU, two can be mounted on opposite corners of the robot. But what good is localization for autonomous if not to be used with path following?

We plan to experiment with the roadrunner motion profiling library for FTC robots, using as input the Pose provided by the optical flow sensors. It simplifies many of the common needs for path following, like providing OpModes for odometry tuning, path following for linear and even spline trajectories, as well as asynchronous methods which can easily integrate into our current asynchronous codebase. Since we are dipping our toes back into a mecanum chassis for robot in two days, roadrunner will be ideal to harness the full potential of a holonomic drive.

### Next Steps:

The most important first step is to get the optical flow sensor working with the Control Hub, so that we can have an accurate localization system as the backbone for future path following during autonomous. In a separate track, different pipelines can be experimented with to get obstacle detection working using the realsense depth camera.

# A Prerequisite Chassis to Robot In 3 Days

12 Sep 2021
Post 51
Awards: mechanical, innovate, and design

A Prerequisite Chassis to Robot In 3 Days By Trey, Cooper, and Aaron

### Task: Build a robot that can be adapted to any challenge

The challenge reveal is going to be quite soon. In the weeks leading up to the challenge reveal we began to wonder if there was anything we could do that would make our transition from preseason to prototyping any better. And obviously, there are many things we could do that would make our work easier when the time comes to see the new challenge. Mainly, we were thinking that since we do a robot in three days when the challenge gets revealed, it would be beneficial to have a robot chassis that could be used in most challenges and be adapted to the specifics of this year’s challenge. A robot like this should be easily maneuverable and have an arm or subsystem capable of interacting with ordinary objects. That’s where the idea for this robot came from.

N-bot is the solution to this problem. The idea for N-bot was that we should have a chassis that can drive over elements and manipulate them within the walls of the robot. In order to do this, we created a robot in the shape of a lower case n that can drive over objects. Ideally, the next step would be to give it an arm that can manipulate anything it can drive over; however, we did not have time to complete this. Instead, what we ended up with was a chassis in the shape of a lowercase n.

For wheels on this robot, we decided that mecanum wheels would be the best choice since we would be able to move in all directions on the field with them and position ourselves accurately over objects. Those four wheels are chained to motors and paired together in wall-shaped blocks that are linked together on top by 4 structural extrusions. The overall shape of the robot appears to be sturdy; however, it is actually quite flimsy. Linking two halves of a robot with only 4 beams on top is not a great idea if you’re looking for a rock-solid design. Instead, our robot tends to flex and shake but that’s ok because those issues are manageable. We sacrificed the structural integrity of our robot for ease of adaptation to challenge specific tasks.

### Next Steps:

The next steps for this project are clear: we wait for the challenge to be revealed and then we adapt N-bot to that challenge with any number of additional subsystems. We are planning on only using this robot for our robot in 3 days challenge and nothing else so none of the subsystems we produce will be used at any other point in the year.

# Chassis Brainstorming

02 Oct 2021
Post 52
Awards: mechanical, innovate, and think

Chassis Brainstorming By Trey, Cooper, and Shawn

### Task: Build a robot that can be adapted to any challenge

The new challenge is upon us and with a new challenge comes new robot designs. This year we have found that we are going to need to focus on the chassis of our robot more than ever. This is because the barrier to the warehouse is an important obstacle that we want to be able to climb or get around in order to score. The drawings and notes depicted below are the unfiltered notes that I took shortly after the discussions we had about chassis designs.

### Next Steps:

The next steps here are to pick one or two of these designs and run with them. We need to build some prototypes of these fast before the first scrimmage or competition. I think the ones we are most likely to prototype in the coming weeks are the Flipin' tank, the tricycle, and the Flippin' bot. We're excited to see where these designs take us.

# Flyset Workshop Vision Presentation

02 Oct 2021
Post 53
Awards: control

Flyset Workshop Vision Presentation By Mahesh

### Task: Deliver a Presentation Over Developing Vision Pipelines At The Flyset Workshop

This Saturday, we had the oppurtunity to present at the Flyset workshop, an event in which multiple teams could present a topic of their choosing, such as (but not limited to) build, design, and programming. For one of our two presentations, we decided to share our process for rapidly prototyping and testing OpenCV vision pipelines, taking a drag-and-drop visual pipeline in GRIP to a fully-fledged working android project that can be deployed to a control/expansion hub.

To begin the presentation, we introduced the programs and dependencies we use for developing vision pipelines. These include GRIP (a graphical tool to easily visualize and test out different computer vision pipelines), FTC Dashboard (a project dependency that allows for remote debugging with image previews, on-the-fly variable editing, live telemetry, graphing, and a field overlay), and EasyOpenCV (a project dependency that simplifies using OpenCV for FTC and runs vision pipelines in a separate thread for maximum efficiency).

Next, we laid the foundation for the HSV threshold step to come by introducing the audience to the HSV color space and its advantages that make it easier to tune for the purposes of sampling an orange cone or colored team marker. We then transitioned (not shown in slides) to the concept of an HSV threshold, which takes an rgb image and uses hue, saturation, and value ranges to let only certain pixels through the threshold, ultimately producing a binary image.

The final requirement for understanding our color-based detection approach is that of contours in the context of computer vision. We explained the definition of contours (boundaries that enclosed shapes or forms in an image), and how they can be detected from thresholded images.

The final constructed GRIP pipeline is shown above. It follows the steps:

1. gaussian/box blur
2. HSV threshold
3. contour detection

However, multiple contours/color blobs may be detected in the last step shown in the GRIP pipeline, so the largest contour must be selected by area. From this largest contour, moments can be used to find the (x, y) coordinate of the contour's centroid. Moments are defined as the weighted sums of pixel intensities (pixel values when converted to grayscale), weighted by their x and y positions to produce m_1_0 and m_0_1 respectively. These moments can then be divided by m_0_0 to produce the x,y coordinate of the centroid of the largest detected contour, the final desired result.

Finally, the completed vision pipeline was exported to java and modified to be compatible with EasyOpenCV, as well as select the largest contour by area and compute its centroid.

### Next Steps:

Possible next steps for other approaches of detecting FFUTSE cones include the shape-based approach and machine learning with tensorflow. The shape-based approach would use an adaptive threshold and contour detection to detect multiple contour, and can rely on the shape of the contour (tapered towards the top like a cone) to detect the location of the FFUTSE cone placed in the image.

In order to construct a tensorflow model to detect FFUTSE cones, training data (images of FFUTSE cones placed in various different orientations, lightings, and backgrounds) will need to be collected and labelled with the (x, y) coordinate of the FFUTSE cone in each image. Then, a CNN (Convolutional Neural Network) can be constructed, trained, and exported as a .tflite file to be used in the FTC ecosystem.

# Deriving Inverse Kinematics For The Drivetrain

08 Dec 2021
Post 54
Awards: think and control

Deriving Inverse Kinematics For The Drivetrain By Mahesh, Cooper, and Ben

### Task: Derive Inverse Kinematics For The Drivetrain

Due to having an unconventential drivetrain consisting of two differental wheels and a third swerve wheel, it is crucial that we derive the inverse wheel kinematics early on. These inverse kinematics would convert a desired linear and angular velocity of the robot to individual wheel velocities and an angle for the back swerve wheel. Not only would these inverse kinematics be used during Tele-Op to control the robot through joystick movements, but it will be useful for getting the robot to travel at a desired forward velocity and turning rate for autonomous path following. Either way, deriving basic inverse kinematics for the drivetrain is a necessity prerequisite for most future programming endeavors.

More concretely, the problem consists of the following:
Given a desired linear velocity $$v$$ and turning rate/angular velocity $$\omega$$, compute the required wheel velocities $$v_l$$, $$v_r$$, and $$v_s$$, as well as the required swerve wheel angle $$\theta$$ to produce the given inputs. We will define $$v_l$$ as the velocity of the left wheel, $$v_r$$ as the velocity of the right wheel, and $$v_s$$ as the velocity of the swerve wheel.

To begin, we can consider the problem from the perspective of the robot turning with a given turning radius $$r$$ with tangent velocity $$v$$. From the equation $$v = \omega r$$, we can conclude that $$r = \frac{v}{\omega}$$. Notice that this means when $$\omega = 0$$, the radius blows up to infinity. Intuitively, this makes sense, as traveling in a straight line ($$\omega = 0$$) is equivalent to turning with an infinite radius.

The main equation used for inverse wheel kinematics is:

$\displaylines{\vec{v_b} = \vec{v_a} + \vec{\omega_a} \times \vec{r}}$

Where $$\vec{v_b}$$ is the velocity at a point B, $$\vec{v_a}$$ is the velocity vector at a point A, $$\vec{\omega_a}$$ is the angular velocity vector at A, and $$\vec{r}$$ is the distance vector pointing from A to B. The angular velocity vector will point out from the 2-D plane of the robot in the third, $$\hat{k}$$, axis (provable using the right-hand rule).

But why exactly does this equation work? What connection does the cross product have with deriving inverse kinematics? In the following section, the above equation will be proven. See section 1.1 to skip past the proof.

To understand the equation, we start by considering a point A rotating around aother point B with turn radius vector $$\hat{r}$$ and tangent velocity $$\vec{v}$$.

For an angle $$\theta$$ around the x-axis, the position vector $$\vec{s}$$ can be defined as the following:

$\displaylines{\vec{s} = r(\hat{i}\cos\theta + \hat{j}\sin\theta) }$

by splitting the radius vector into its components and recombining them.

To arrive at a desired equation for $$\vec{v}$$, we will have to differentiate $$\vec{r}$$ with respect to time. By the chain rule:

$\displaylines{\vec{v} = \frac{d\vec{s}}{dt} = \frac{d\vec{s}}{d\theta} \cdot \frac{d\theta}{dt}}$

The appropriate equations for $$\frac{d\vec{s}}{d\theta}$$ and $$\frac{d\theta}{dt}$$ can then be multiplied to produce the desired $$\vec{v}$$:

$\displaylines{\frac{d\vec{s}}{d\theta} = \frac{d}{d\theta} \vec{s} = \frac{d}{d\theta} r(\hat{i}\cos\theta + \hat{j}\sin\theta) = r(-\hat{i}sin\theta + \hat{j}cos\theta) \\ \frac{d\theta}{dt} = \omega \\ \vec{v} = \frac{d\vec{s}}{dt} = \frac{d\vec{s}}{d\theta} \cdot \frac{d\theta}{dt} = r(-\hat{i}sin\theta + \hat{j}cos\theta) \cdot \omega \mathbf{= \omega r(-\hat{i}sin\theta + \hat{j}cos\theta)} }$

Now that we have an equation for $$\vec{v}$$ defined in terms of $$\omega$$, $$r$$, and $$\theta$$, if we can derive the same formula using $$\vec{\omega} \times \vec{r}$$, we will have proved that $$\vec{v} = \frac{d\vec{s}}{dt} = \vec{\omega} \times \vec{r}$$

To begin, we will define the following $$\vec{\omega}$$ and $$\vec{r}$$:

$\displaylines{ \vec{\omega} = \omega \hat{k} = \begin{bmatrix}0 & 0 & \omega\end{bmatrix} \\ \vec{r} = r(\hat{i}cos\theta + \hat{j}sin\theta) = \hat{i}rcos\theta + \hat{j}rsin\theta = \begin{bmatrix}rcos\theta & rsin\theta & 0\end{bmatrix} }$

Then, by the definition of a cross product:

$\displaylines{ \vec{\omega} \times \vec{r} = \begin{vmatrix} \hat{i} & \hat{j} & \hat{k} \\ 0 & 0 & \omega \\ rcos\theta & rsin\theta & 0 \end{vmatrix} \\ = \hat{i}\begin{vmatrix} 0 & \omega \\ rsin\theta & 0\end{vmatrix} - \hat{j}\begin{vmatrix} 0 & \omega \\ rcos\theta & 0\end{vmatrix} + \hat{k}\begin{vmatrix} 0 & 0 \\ rcos\theta & rsin\theta\end{vmatrix} \\ = \hat{i}(-\omega rsin\theta) - \hat{j}(-\omega rcos\theta) + \hat{k}(0) \\ \mathbf{= \omega r(-\hat{i}sin\theta + \hat{j}cos\theta)}}$

Since the same resulting equation, $$\omega r(-\hat{i}sin\theta + \hat{j}cos\theta)$$, is produced from evaluating the cross product of $$\vec{\omega}$$ and $$\vec{r}$$ and by evaluating $$\frac{d\vec{s}}{dt}$$, we can conclude that $$\vec{v} = \vec{\omega} \times \vec{r}$$

## 1.1

Based on the constants defined and geometry defined in the image below:

The equation can be applied to the left wheel to derive its inverse kinematics:

$\displaylines{\vec{v_l} = \vec{v} + \vec{\omega} \times \vec{r_l} \\ = \mathbf{v + \omega (r - \frac{l}{2})}}$

where $$r$$ is the turn radius and $$l$$ is the width of the robot's front axle. Applied to the right wheel, the equation yields:

$\displaylines{\vec{v_r} = \vec{v} + \vec{\omega} \times \vec{r_r} \\ = \mathbf{v + \omega (r + \frac{l}{2})}}$

Applied to the swerve wheel, the equation yields:

$\displaylines{\vec{v_s} = \vec{v} + \vec{\omega} \times \vec{r_s} \\ = \mathbf{v + \omega \sqrt{r^2 + s^2}}}$

where $$s$$ is the length of the chassis (the distance between the front axle and swerve wheel).

The angle of the swerve wheel can then be calculated like so using the geometry of the robot:

$\displaylines{\theta = \frac{\pi}{2} - tan^{-1}\left( \frac{s}{r} \right)}$

Mathematically/intuitively, the equations check out as well. When only rotating ($$v = 0$$), $$r = \frac{v}{\omega} = \frac{0}{\omega} = 0$$, so:

$\displaylines{ v_l = v + \omega(r - \frac{l}{2}) = \omega \cdot -\frac{l}{2} \\ v_r = v + \omega(r + \frac{l}{2}) = \omega \cdot \frac{l}{2} \\ v_s = v + \omega\sqrt{r^2 + s^2} = \omega \cdot \sqrt{ s^2} = \omega \cdot s}$

In all three cases, $$v = \omega \cdot r$$, where $$r$$ is the distance from each wheel to the "center of the robot", defined as the midpoint of the front axle. Since rotating without translating will be around a center of rotation equal to the center of the robot, the previous definition for $$r$$ can be used.

As for the equation for $$\theta$$, the angle of the swerve wheel, it checks out intuitively as well. When only translating (driving straight: $$\omega = 0$$), $$r = \frac{v}{\omega} = \frac{v}{0} = \infty$$, so:

$\displaylines{ \theta = \frac{\pi}{2} - tan^{-1} \left( \frac{s}{r} \right) \\ = \frac{\pi}{2} - tan^{-1} \left( \frac{s}{\infty} \right) \\ = \frac{\pi}{2} - tan^{-1}(0) \\ = \frac{\pi}{2} - 0 \\ = \frac{\pi}{2} }$

As expected, when translating, $$\theta = 0$$, as the swerve wheel must point straight for the robot to drive straight. When only rotating ($$v = 0$$), $$r = \frac{v}{\omega} = \frac{0}{\omega} = 0$$, so:

$\displaylines{ \theta = \frac{\pi}{2} - tan^{-1} \left( \frac{s}{r} \right) \\ = \frac{\pi}{2} - tan^{-1} \left( \frac{s}{0} \right) \\ = \frac{\pi}{2} - tan^{-1}(\infty) \\ = \frac{\pi}{2} - \lim_{x \to +\infty} tan^{-1}(x) \\ = \frac{\pi}{2} - \frac{\pi}{2} \\ = 0}$

As expected, when only translating (driving straight), $$\theta = \frac{\pi}{2}$$, or in other words, the swerve wheel is pointed directly forwards to drive the robot directly forwards. When only rotating, $$\theta = 0$$, or in other words, the swerve wheel is pointed directly to the right to allow the robot to rotate counterclockwise.

### Next Steps:

The next step is to use PID control to maintain target velocities and angles calculated using the derived inverse kinematic equations. Then, these equations can be used in future motion planning/path planning attempts to get the robot to follow a particular desired $$v$$ and $$\omega$$.

A distance sensor will also need to be used to calculate $$s$$, the distance between the front axle and swerve wheel of the robot.

# Deriving Maximum Chassis Length On Turns

08 Dec 2021
Post 55
Awards: think and control

Deriving Maximum Chassis Length On Turns By Mahesh and Cooper

### Task: Derive The Maximum Chassis Length On Turns

Having a chassis able to elongate and contract during play poses its advantages and drawbacks. If properly used, the chassis can serve to strategically defend portions of the field. However, if not shortened during turns, the extended length of the robot can lead the swerve wheel to lose traction and start skidding on fast turns. Therefore, it is crucial to derive a model for the maximum chassis length achievable on a turn of angular velocity $$\omega$$ before skidding starts to occur.

More concretely, the problem is the following: given an angular velocity $$\omega$$ and other physical constants, what is the maximum distance $$s$$ achievable between the front axle and swerve wheel before the centripetal force required to keep the robot in circular motion $$F_c$$ exceeds the force of friction $$F_f$$ between the wheels and the ground?

To start, we can define the force of friction $$F_f$$:

$\displaylines{F_f = \mu N = \mu mg}$

where $$\mu$$ is the coefficient of friction betewen the wheels and the ground, $$m$$ is the mass of the robot, and $$g$$ is the acceleration due to gravity.

Then, we can define the centripetal force required $$F_c$$:

$\displaylines{F_c = ma_c = m\omega^2r_s}$

where $$a_c$$ is the required centripetal acceleration, $$\omega$$ is the angular velocity of the robot, and $$r_s$$ is the distance from the swerve wheel to the center of rotation.

Setting these two equations equal to eachother and solving for $$r$$ will yield the final equation:

$\displaylines{F_f = F_c \\ \mu mg = m\omega^2r_s \\ \mu g = \omega^2r_s \\ r_s = \frac{\mu g}{\omega^2}}$

However, the $$s$$ must be related to $$r_s$$ to be used in the above equation. This can be done by substituting the expression $$\sqrt{r^2 + s^2}$$ for $$r_s$$, where $$r$$ is the true turn radius, which will compute the distance from the swerve wheel to the instantaneous center of rotation. So,

$\displaylines{r_s = \frac{\mu g}{\omega^2} \\ \sqrt{r^2 + s^2} = \frac{\mu g}{\omega^2} \\ r^2 + s^2 = \left(\frac{\mu g}{\omega^2}\right)^2 \\ s^2 = \left(\frac{\mu g}{\omega^2}\right)^2 - r^2 \\ s = \sqrt{\left(\frac{\mu g}{\omega^2}\right)^2 - r^2}}$

As seen in the above screenshot of the following desmos calculator, the slower the robot rotates, and the closer $$w$$, or in this case $$x$$, is to 0, the higher the maximum chassis length $$s$$, or in this case $$y$$, is. Intuitively, this checks out, since when at a standstill, the robot can be as long as possible with no side effects. When rotating slowly, the robot needs to be slightly shorter to maintain traction, and when rotating fast, the robot needs to be very short to maintain traction, as reflected in the downward slope of the graph.

### Next Steps:

The next step is to use PID control with input as the measured chassis length as given by the distance sensor and target being the output of the derived equation for $$s$$ to maintain the robot's length to keep traction. Additionally, the coefficient of friction $$\mu$$ between the wheels and ground will need to be tuned to the drivers' liking.

# Control Award Video - Freight Frenzy NTX Regional Championship

26 Feb 2022
Post 57
Awards: Control and private

Control Award Video - Freight Frenzy NTX Regional Championship By Cooper and Mahesh

# Meeting Log 3/12

12 Mar 2022
Post 58
Awards: innovate

Meeting Log 3/12 By Trey and Leo

### Task: Decreasing the Movement of Linear Slides During Expansions

The continuous expansion and contraction of the robot placed a lot of stress on the mounting gear attaching the slides directly to the chassis. With each expansion the slides stretch out, and under their own weight, they would flex downwards. During regionals, the slides were subjected to these forces all day, and by the end our sliding components, “carriages”, were pretty damaged. The internals were unevenly worn and the ball bearings just fell out on the field; If left unattended, the carriages would eventually detach from the slides and the robot would literally break in two.

To fix this, Trey came up with a double-carriage approach, aimed at reinforcing the mounts attached directly to the front of the robot. He machined an aluminum plate on the CNC, and then combined two different carriages to create a single sliding component. This effectively doubled the “strength” of the mounts by shifting the pivot point of the slides further in, and adding more resistance to the gravitational torque acting on the bar. Overall, the slides weren’t as steep and so carriages were much smoother during extensions.

### Next Steps

We noticed that the slides did sag a little, however we need some compliance to allow for twisting caused by sharp crane movements and turns.We also noticed that the slide attached to the swerve module did flex so we might need to address that. Testing was limited however so we’d like to get some driver practice in and see how well the upgrades perform on the field.

# Iron Reign and the Three Magnets

14 Mar 2022
Post 59
Awards: innovate

Iron Reign and the Three Magnets By Bhanaviya and Georgia

### Task: Evaluating what magnet type works best with the FFUTSE and bucket attraction

FFUTSES with magnets mounted

Iron Reign has its final event of the season, the UIL championship, in just one month! One driver task we've been needing to complete has been picking up and depositing a Freight Frenzy Universal Team Shipping Element (FFUTSE). To read about the FFUTSE and Iron Reign's open-source design, please refer to our FFUTSE repository. To overcome this part of the game challenge, we have decided to attach magnets on the underside of our bucket-intake and to the top of our cone-shaped FFUTSEs. The idea is that when the bucket roves over a FFUTSE, its magnet will be strong enough to attract the one atop the shipping element. However, the magnetic attraction must not be too strong, otherwise the bucket will not be able to drop off the FFUTSE on the shared shipping hub if the magnet is still affixed to the robot.

In order to determine which kind of magnet could best meet these two criterion, we experimented with niodimium and ceramic magnets. Of the niodium magnets, there are 3 differently-sized ones - a large, medium, and small, with their sizes corresponding to the degree of magnetic attraction from greatest to least respectively.

To reinforce the shipping element's attraction to the bucket, we have also created an array of corresponding magnets inside the bucket rather than simply affixing one magnet, since that way, the vertical thrust of the crane when is lifted upwards will not disrupt the attraction of the FFUTSE to the intake.

It was clear that the ceramic and smallest niodimium magnets were too weak - even with an array of magnets in the bucket, they required too much precision on the driver's part in order to swiftly attract a FFUTSE and part of our idea is to minimize the driver effort and error that can come into play with this FFUTSE pickup process. Between the large and medium-sized niodimium magnets, though the large could attract a magnet faster, it did its job too well since dropping off the FFUTSE was not a task it could accomplish since the attraction of the magnets was too strong

### Next Steps

In the end, our decision was influenced by Goldilockian principles - not too large, not too small but just right. The bucket does a reliable job of picking up and transfering FFUTSEs but as of now, this component has not yet been programmed. Once programmed, there is a chance we may have to either use a stronger magnet or find amiddle ground between the largest magnet and medium-sized one in order to minimize driver accuracy while maximizing efficiency.

# Hybrid Swerve Drive Progression

19 Mar 2022
Post 60
Awards: innovate and think

Hybrid Swerve Drive Progression By Georgia, Shawn, Trey, and Bhanaviya

### Task: Fix issues found by Drive Practice in the robot

Iron Reign has seen several dIfferent iterations of our swerve module this past season. In this post we’ve identified the different versions of our modules so we can isolate the failures and successes of each modification from sketch, to a CAD model to the constructed, manufactured iteration.

To accommodate for our expanding chassis design this year, we’ve had to create a hybrid-differential swerve drive which means the combination of two differential wheels and swerve wheels and how they work together to achieve 2 degrees of freedom.

Our first version of the swerve drive had a thrust bearing the same size as the ring gear. Unfortunately, this iteration was too small to cross over the barrier.

The second iteration had a larger compliant wheel to cross over the barrier. Alas, the swerve drive created a high center of gravity for the robot, causing the robot to tip over.

The third version had custom-machined aluminum plates for further weight reduction.The Hex Motor was moved inside and above the wheel hub to reduce the center of gravity. Sadly, the wheel was not malleable enough to pass over the barrier without dropping the freight.

The fourth iteration is a rover-inspired swerve module made of six custom CNC carbon-fiber plates and ten custom 3D printed components. The wheel is made of NinjaFlex and has gothic arch-style to support a large vertical force. The wheel hub is made of nylon and has been holed to reduce weight. The walls of the holes have added infill to increase the strength of the wheel. This version has a lower center of gravity and a lighter wheel module.

### Next Steps

We will contact the original designers of the rover-inspired swerve module, an Australian college rover team.

# Meeting Log 3/19

19 Mar 2022
Post 61
Awards: innovate

Meeting Log 3/19 By Anuhya, Georgia, Aarav, Bhanaviya, Mahesh, Trey, and Gabriel

### Task: Get more drive practice before the UIL Championship

This weekend, we focused on on-boarding new recruits as well as getting more drive practice to get us ready for the UIL competition next month.

#### New Recruits Learnt to Create Blog Posts

Bhanaviya taught us how to make blog posts on different topics, and also showed us the most efficient ways to bug the experienced members to get the information we needed.

#### Drive Practice (we really need it)

Gabriel got in practice going straight and using the extension function to minimize the amount of turning. Different angles of blocks were tested to see how the gripper would pick them up. An average of 3 pieces of freight per round was achieved.

#### Build Improvements

To help prevent the turret from drifting, we were looking at two options: implementing a tensioner to one of the belts to prevent skipping or adding an IMU to help the turret know where it is. We also added a potentiometer to be able to reliably be able to tell the shoulder position. There was a lot of shaft left, so Trey used a dremel to cut down the shaft so he could add the potentiometer.

#### Code Changes

There was an issue with an intake. The intake was running at a very high speed so it would spit the freight back out, for lack of a better phrase. A distance sensor was added to slow down the gripper when a shipping element is located nearby. Finally, he worked on fine tuning the crane so the transfer is seamless, and he is currently working on balancing the crane so it doesn’t bump into the shipping hub.

### Next Steps

We have to test our robot without outriggers to see if the robot starts to tip over. (NB - We tested it out, it didn’t work. Let’s see what happens at the next meeting.) We also have to fine tune autonomous, so we can have a reliable auton which regularly works. We also have to work on driver optimization using present positions, so it’s easier on our drivers to control. Automating the intake cycle is also on our todo list.

# Repairing ‘Reach’

19 Mar 2022
Post 62
Awards: innovate

Repairing ‘Reach’ By Gabriel

### Task: Fix issues found by Drive Practice in the robot

To better prepare for UIL, we have started using Driver Practice to find issues that would’ve impacted the robot performance at the competition. Within the first 15 minutes of driving the robot, the servo that sustains the crane experienced thermal overload and could no longer hold up the axel by which the crane was able to move vertically.

This required the deconstruction of the component to be able to access and replace the Steel Servo that had issue with the weight of the crane. This led to further experimentation with different aspects of the crane, such as the servo horn to test whether the axel would fully insert into the horn and reworking the distance sensor on the bucket so that it would function properly and automatically drop any held element onto the top of the shipping hub, though dropping elements into the shared shipping hub still needs some improvement. Unfortunately, even after changing out the Servo, the weight of the crane would still cause thermal overload, leading us to determine that it was unable to be fully fixed without reworking the crane in its entirety.

### Next Steps

Continue with Drive Practice and rigorous testing of the robot attachments to see what needs improvement or complete reworking before UIL

# Solving Tipping Issues in The Reach

19 Mar 2022
Post 63
Awards: think

Solving Tipping Issues in The Reach By Aarav, Shawn, Mahesh, and Bhanaviya

### Task-Identify and solve the problems that led to The Reach tipping over mid-match.

Our robot, The Reach, utilizes a hybrid-differential swerve drive along with an extending design in order to effectively cross the barriers and score freight. Although this design is unique and avoids the congested areas of the playing field, it comes with trade-offs and flaws.

At our first qualifier, we noticed one major flaw in the design of The Reach. The robot would often tip over during game play, rendering it unable to move and score points. Observing our matches and looking over our design, we attributed this problem to a couple of key components of our design.

First off, due to limitations on the dimensions of the robot at the beginning of matches, the robot had quite a narrow base for its extended length of around 5 feet. This led to the robot being susceptible to tipping when in motion when combined with a variable center of mass.

Furthermore, the jerky and sudden acceleration of the robot when traversing the playing field and extending caused the robot to fall over due to the sudden movement.

Finally, our robot has an unusually high center of mass due to the design of its drive train and wheel modules. The motors that powered the wheels were housed above the actual wheel in the module, which led to a high center of mass. This issue was exacerbated by the extending crane arm we used for scoring freight, which led to a variable center of mass.

Overall, we mainly attributed this failure to our robot's high and variable center of mass, which changed rapidly due to the robot's expansion and contraction. These factors combined with the narrow base were the key factors leading to the robot tipping.

Looking at these diagrams of the robot and its center of mass, we can see how as the crane extends past the base of the robot, the center of mass moves towards the base. Eventually, the center of mass reaches a position outside of the base and the robot falls over. To solve this problem, we would have to either lower the center of mass or limit its fluctuation during movement.

You can see from these free-body diagrams that as we lower the vertical component of the normal force, the overall rotational torque exerted by the swerve module is decreased, which inspired our decisions to lower the center of mass.

We did this by redesigning our wheel modules and moving the motor further down. Our redesigned wheel modules utilize custom printed "barrier beaters" instead of the rock climbers we used before. These wheels were printed out of ninja flex and nylon and utilized a Gothic Arch design inspired by Monash University's rover wheels. The custom wheel modules used custom carbon-fiber plates and holes in the nylon hub to help reduce weight. Overall, these wheels were excellent at traversing the barriers, weighed less, and the wheel module allowed the motor to drop 5 inches in height. This led to a lower center of mass for the robot.

However, in the situation that the crane and robot extension did lead to the center of mass nearing the base, we installed an outrigger system as a preventative measure. An outrigger is essentially a beam that extends from a robot that is used to improve stability. Our outriggers used omni wheels and functioned similarly to training wheels, preventing the robot from tipping over when the crane moves out and extends.

Finally, we implemented some code changes to help deal with this problem, building anti-tipping limiters which allowed for gradual acceleration. This prevented the sudden acceleration mentioned earlier which was a cause of our tipping issue. We also programmed in pre-set arm locations to help keep the center of mass near the wheelbase, making sure that the center of mass never passes the base of the actual robot.

### Next Steps

Building a unique and innovative robot like The Reach comes with a unique set of challenges and obstacles, and we will keep iterating our swerve module by experimenting with different wheel designs and weight-reduction patterns to reduce odds of tipping.

# Meeting Log 3/26

26 Mar 2022
Post 64
Awards: innovate

Meeting Log 3/26 By Anuhya, Georgia, Bhanaviya, Leo, Gabriel, Aarav, Ben, Shawn, and Mahesh

### Task: Work on teamwork with drive practice for the UIL Championship

This weekend, we worked on giving the new recruits a basic understanding of HTML so they could operate the blog when we were no longer here to help them. We also worked on communication in drive practice, because we have two drivers and two controllers.

#### Gabriel and Georgia got in some drive practice

They got in more practice working together driving, and figuring out how they wanted to split up the responsibilities. We have a robot which works better with two drivers controlling two separate controllers, but this means we have to spend extra time planning out our strategies and deciding how the controls will work for each individual driver.

#### The new recruits are learning how to use HTML

Bhanaviya and Shawn taught us how to use HTML to upload blog posts to the blog. We wrote our first blog posts a couple weeks ago, and today we learned how to upload them to the blog and possibly run damage control if we accidentally break something in the blog.

#### Code Changes

Mahesh worked on updating the code for picking up blocks. Now, whenever the robot is trying to pick up a block and drops it midway, instead of going through the whole motion of putting it in the bucket, it goes back down. This will help our robot become more efficient, as it will have more time to pick up blocks when it’s not wasting time.

#### Making an Innovate Poster

Bhanaviya and Shawn worked on making an Innovate poster which detailed our game strategy and the build for our robot. This is the main award for the UIL Championship.

### Next Steps

First things first, we need to fine-tune the autonomous for our robot. We are planning to get more drive practice with an autonomous system so we’ll know how to time things properly. We also want to get in more drive practice in general, so we'll have better control over our robot overall and will be able to control the arm better.

# Meeting Log 3/29

29 Mar 2022
Post 65
Awards: journal

Meeting Log 3/29 By Anuhya, Georgia, Trey, Gabriel, Ben, Cooper, and Paul

### Task: Getting in some serious drive practice at Woodrow

We took some time out of our week to get in some drive practice at Woodrow so we would be able to practice working together with another team and collaborating with a make-shift alliance.

#### Drive Practice at Woodrow

Practice matches run: 16 The main purpose of our drive practice at Woodrow was getting drive practice with another team, the Mechanicats. This would be one of our only opportunities before UIL to practice with another team and play in a full practice field with another team working as an alliance. One of the challenges we faced today was with our drivers learning how to work together. There were many kinks with having two people drive, including having two separate controllers with their own unique functionalities. One controller deals with the intake inside the warehouse while the other deals directly with the alliance shipping hub and the arm. Learning how to collaborate while using both was a difficult obstacle to overcome, especially because we didn’t have as much drive practice overall as we would have liked. Another major challenge we faced was getting the team shipping hub to not tip over. Our arm would extend too low and it would tip over the team shipping hub if we weren’t careful. Right now, we are working on maneuvering so it doesn’t tip it over, or only slightly nudges it. We also started working on our duck game, because we realized we didn’t have our duck spinner as efficient as we would have liked. The band which held the duck spinner back from deploying early snapped when we were setting it up, so we had to make do while practicing.

### Next Steps

We are planning on getting even more drive practice as the days progress and we’re getting closer to UIL. We also need to work on not tipping over the alliance shipping hub, because that is a major penalty and it also makes it nearly impossible to get any points afterwards. We also need to figure out how to “double duck” with our current duck spinner, meaning we have to spin the duck off the duck spinner and then deposit them in the alliance shipping hub. Trey is currently working on redesigning the duck spinner so it has a wider range of compliance. This is so we can maintain our goal of “double duck”, which needs a larger range of motion and a robot which can reach further. We also need to keep working on strategy, so we can finalize what we’re running with at UIL and have time to practice it.

# Meeting Log 4/01

01 Apr 2022
Post 66
Awards: journal

Meeting Log 4/01 By Vance, Georgia, Trey, Gabriel, Bhanaviya, Leo, and Mahesh

### Task: Replace Crane Servo with a Motor

After six broken servos amounting to around 240 dollars worth of funding, it became apparent that the current model of servo we were using wasn't up to the task that it needed to fulfill.

First came the issue of figuring out how to mount the motor. An HdHex Motor was decided upon as it was able to support additions to increase the gear ratio, while a CoreHex motor had around the same power as the servos previously used. We were able to use a 90 degree mount in order to attach the motor as to not allow it to jut out of the robot, which would break the proper sizing restrictions. After assembly, it was found to solve most issues found with the servos, though did introduce the issue of leaning due to the unequal weight distribution. So far, it has had a better performance than the servos did

### Next Steps

Figuring out how to mount on a counterweight to offset the weight of the motor so both the crane and the robot no longer lean off to one side

# Think Gripper Progression

01 Apr 2022
Post 67
Awards: think and innovate

Think Gripper Progression By Vance

### Gripper Progression

#### V1

Our first gripper design was for robot in 2 days and with the time crunch came some downsides: little power and poor reach. Our second design intended to fix these downsides.

#### V2

Our second gripper design was made just before a scrimmage. While it fixed all V1's downsides it was bulky and heavy.

#### V3

Our third gripper design was used during our first qualifier. While it was significantly lighter than V2 and had much more reach, its gripper power was still too low.

#### V4

Our fourth gripper design was used for regional and it used a new beater bar on a continuous servo to pull blocks into the intake. The beater bar/spinner was controled by a distance sensor which could detech if a block was in the intake. It was held together using a carbon fiber-nylon sandwich (with aluminum shavings) system. It had 6 CNC carbon fiber plate and had 9 Nylon 3D printed parts.

# Meeting Log 4/2

02 Apr 2022
Post 68
Awards: innovate

Meeting Log 4/2 By Anuhya, Georgia, Aarav, Bhanaviya, Mahesh, Trey, Gabriel, Ben, Anisha, Vance, and Shawn

### Task: Solve minor issues with the robot’s design and code. More drive practice in preparation for the UIL Championship next week.

With only one week left until the UIL FTC State Championship in Houston, we doubled down on our efforts to fix a few small problems that remained in The Reach, as well as prepare for the State Tournament. Specifically, we had to finish constructing a new duck spinner that could extend farther out, and fix minor difficulties in the code of the robot that was messing up the positions of the crane during gameplay.

#### Designing and Constructing a New Duck Spinner

There were a couple of key issues with the old duck spinner that led to the development of an improved version, which Trey designed and constructed. The old duck spinner was too short to reach the duck carousel when the gripper was lowered and in an intake position and the drivetrain for the duck spinner motor was not very good. Trey designed and 3-D printed a new motor mount that allowed the spinner to be directly driven by the motor. To address the length issue, the entire mount was attached to a carbon fiber rod. This new system allows the hot swappable duck spinner to extend further out and work in tandem with the beater. We managed to mount the duck spinner by the end of our meeting.

Remember to use safety glasses kids!

#### Fixing Minor Build Issues

There were a couple of structural and wiring issues with our robot that needed to be sorted out in order for the robot to function properly. On the bucket, the distance sensor that allowed an automated transfer system and automated drop off was re-wired to ensure that it didn’t unplug during the robot’s motion. This allowed for the proper transfer of freight from the beater to the bucket. Then, the servo for the second gripper beater was properly wired to make sure that the gripper could intake freight into the gripper properly. Finally, the magnets used to score our team shipping element were reattached so that we could lift FFUTSE’s and placed them on the alliance shipping hub.

#### Code Modifications

We recently added a new shoulder servo for the crane, and we worked today to help integrate it into the code and fine-tune it. We also dealt with an issue with the code that caused the crane to turn only to the right during freight drop-off.

#### UIL Posters and Documentation

Bhanaviya, Anisha, and Shawn worked on documentation posters for the UIL State Championship to submit for the awards at State. Bhanaviya worked on the engineering and design posters that highlighted how we developed and designed our robot. Shawn completed the innovate poster, which showed how we thought outside the box and created an innovative design. Anisha worked on the connect and motivate posters which displayed how we connected with industry professionals to improve our robot and how we spread robotics and opportunity to our community. Shawn also worked on designing our pit layout for UIL.

### Next Steps

More drive practice. Don’t destroy the robot in the one week before State. Try and not have to pull an all-nighter the night before competition. Continual maintenance and upkeep of the robot would be useful to make sure the robot still works in a week. Documentation will also have to be finished and finalized in the coming week in preparation for UIL.

# Iron Reign’s Mechavator - Safety Features and Protocols

09 Jul 2022
Post 69
Awards: innovate and control

Iron Reign’s Mechavator - Safety Features and Protocols By Gabriel and Trey

### Let's not do this!

Intrinsic Hazards and Safeties
Primary Safety
Backup Safety
Site Safety
Operational Safety

### Intrinsic Hazards and Safeties

#### Intrinsic Hazards

It’s important to keep in mind that with a 3 to 4 ton class mini excavator we are dealing with forces that can crush and pull down trees, destroy structures and potentially end lives. There is no place for any lack of vigilance and caution for safely operating this machine.

#### Intrinsic Safety

The machine has two emergency stop controls and we employ them redundantly in fail-safe modes. The only intrinsic safety lies in the reliable slow motion of the machine. The engine will only be run at idle speed. Its normal ground travel speed is equivalent to a slow walk and it cannot move faster than an able bodied person can run. There are still cautions around this. Swinging the arm when extended can cover a lot of ground quickly. People need to maintain safe distances. Therefore, we have established Operational Safety and Site Safety protocols.

### Primary Safety

The Primary Safety functions as a lock-out of the hydraulic pump. When the safety is engaged, no part of the excavator will move with the possible exception of a very slow sag of heavy components to the ground. For example, the bucket and arm may sag by a few millimeters per second if they were left off the ground.

The Primary Safety is constantly engaged by a rugged bungie. To disengage the safety (UnSafed – therefore hydraulics activated) a servo can actively hold the safety lever down.

#### Fail Safes

• The servo is configured as a deadman switch – the operator needs to continuously hold down a button on the primary remote control for the servo to remain in the Safety-Disengaged position.
• If the servo or control system loses power or browns out, the bungie will pull the safety back into the engaged position.
• If the control system stops receiving active disengage commands from the remote, the safety will re-engage. This covers out-of-range conditions.
• We specifically chose a digital servo that does NOT have a memory of the last good position signal. Some digital servos will continue to hold the last good position they received if they continue to receive power. The servo we chose does not have this feature, so if the PWM position signal fails for any reason, but power remains on, the servo will fail to hold position and the safety will re-engage.
• If the control system app crashes, the safety re-engages
• All of the above have been tested
• We can’t say it’s impossible for the control software stack to crash in a state where it continues to send a safety-disengage PWM position signal. We’ve never seen it happen and we believe it’s prevented by the interaction of the firmware and the app – but we can’t say it’s impossible. It’s also possible to imagine a freak condition where the servo gearbox breaks and locks up in the safety-disengaged position. So we decided to create a redundant backup safety.

### Backup Safety

The Backup Safety uses similar fail-safe design principles as the Primary, but it is completely independent of the normal control system.

The Backup Safety is operated through an independent standard RC (digital radio control) transmitter and receiver.
• The Backup Safety kills the engine when it is Safety-Engaged.
• The Backup Safety is also normally pulled into its Safety-Engaged position by a tensioning system.
• To suppress/disengage the Backup Safety, a servo can hold the kill switch in the down position.
• The servo is configured as a deadman switch – the operator (a different operator than the Primary Safety operator) needs to continuously squeeze the throttle on the RC transmitter for the servo to remain in the Safety-Disengaged position. The throttle is spring loaded to return to Safety-Engaged.
• If the servo or loses power or browns out, the bungie will pull the safety back into the engaged position.
• If the RC receiver stops receiving active disengage commands from the transmitter, the safety will re-engage. This covers out-of-range conditions. It also applies when the transmitter is turned off.
• We specifically chose a digital servo that does NOT have a memory of the last good position signal. Some digital servos will continue to hold the last position they received if they continue to receive power. The servo we chose does not have this feature, so if the PWM position signal fails for any reason, but power remains on, the servo will fail to hold position and the safety will re-engage.
• All of the above have been tested

### Site Safety

Site safety speaks to conditions of the site and surrounding properties that informs the risk to people and property.

The site is the backyard 3 acres of our coach’s residence and the primary structure on the site is the home itself (blue oval, below). The site slopes downhill fairly steeply from the back of the house to the creek that cuts all the way across the property at the bottom (right side in the image). The site is heavily forested with the exception of an open glade, a clearing for a future workshop, and a gravel driveway connecting them uphill to the main driveway for the residence.

With the exception of the driveway, the open areas are surrounded by impassable forest (yellow line in the overhead shot below). By impassible we mean that the excavator would stall on trees and undergrowth within 10 feet if it tried to push through the surrounding brush without skillfully employing the arm and bucket to uproot the vegetation. In addition to the forest/undergrowth, all of the neighbor’s properties are further isolated by being either significantly upslope or on the other side of the creek. The creek has cut an impassable 20 foot sudden drop across the property’s southern border, effectively creating a moat that would protect the only neighbor property that is downslope. Right now there is no path to the creek that the Mechavator could take.

The future workshop site (white oval) is the only area that the Mechavator will be allowed to operate in. The ground there is mostly loose soil but does have rocks, mounds and branches that should be treated as trip hazards. Team members need to be aware of the terrain at all times. We will refer to this area as the arena.

### Operational Safety

Operational Safety consists of the training and protocols that will be followed to assure minimal risk to the participants.

• Mechavator will only be operated in the arena.
• Our coach will always be present and supervising operations. The machine may not be started without an OK by coach.
• There will be a minimum of two operators, a driver and a safety operator. The primary driver will operate either the arm or the chassis as well as the primary safety. The safety operator will operate the backup safety and is primarily responsible for nothing but safe operations of the vehicle.
• A secondary driver is required if the plan calls for operating the chassis and the arm at the same time.
• Every session will begin with a meeting to discuss all planned movements to be sure that everyone in the area knows what to expect as well as what could go wrong and to address specific safety concerns.

# Designing the New Workshop

30 Jul 2022
Post 70
Awards: journal

Designing the New Workshop By Aarav and Anuhya

### Task: Design a floorplan and model for the new workshop

With the limits of our current workspace reached and the need to expand with more recruits and machinery; Iron Reign set off on a new summer project. The objective: design a new workspace for Iron Reign to be constructed further into the property. This new workshop would help Iron Reign improve our fabrication and machining capabilities and expand our program. It also served as a productive way to spend our summer and improve our CAD skills.

A few major constraints and requirements had to be fulfilled by the new workshop, mainly increased capacity for teams and equipment. 2 full-size playing fields were needed to accommodate both Iron Reign and its growing sister teams, and more space for machines, tools, and storage to help delay the workshop's inevitable descent into chaos would be ideal. Finally, we also decided to include brainstorming areas, basic amenities, and a garage for vehicles.

With our concepts and ideas somewhat straightened out, we began developing a floor plan that fits in the cleared-out patch of land on the property. After a few days of work and revision, we had a basic floorplan complected with dimensions. Below is our preliminary floorplan, which included all of the requisite areas.

After that, we decided to take the design to the next level by turning our 2D design into a 3D model, using Fusion 360. Here we had to add components like doors, windows, hallways, walls, and roofs to our design. This helped better prepare it for construction and allowed us a chance to include model furniture to help verify our dimensions and make sure we have enough space. After a couple of weeks, we had a preliminary 3-D model. It is still not finished, and we are continuing to iron out any issues and add more components.

### Next Steps

After finishing the 3-D model, the next step would be to think about construction and start contacting contractors to help sort out any potential issues, along with potentially finding ways to fund this project.

# League Meet #2 Post Mortem

03 Dec 2022
Post 71
Awards: control and innovate

League Meet #2 Post Mortem By Anuhya, Georgia, Gabriel, Trey, Vance, Leo, and Aarav

### Task: review the progression of matches in our latest League Meet

Team 6832, Iron Reign, and our sister teams, Iron Core and Iron Giant had our second league meet earlier today. Overall, it was a very good learning experience and we got to see the functional robots of many of the teams in our league in action. After observing many unique robots, we learned a lot about the differences in strategies between us and other teams and how we could use our differing strategies to work together in a cohesive alliance.

#### Play by Play

Match 1: Win

We got a total of 45 points, but we got a 20 point penalty for our human player placing a cone in the substation at the same time the robots were in the substation. In the autonomous section, Taubot's arm wrapped around the pole, which got stuck in the wires. We were unable to get a cone or parking. During driver control, we got 3 cones, and we got 1 cone with the beacon during the end game. Our robot scored 28 points by itself.

Analysis: During autonomous, our robot was overshooting while trying to place the cone, so it would get stuck around the pole.

Match 2: Win

We got a total of 88 points, but we got a 10 point penalty for our human player, once again. In the autonomous section, we were unable to get the cone, but the overshooting issue was resolved and we got the points for parking. During driver control, we got 4 cones, and we got 1 cone with the beacon during the end game. Our robot scored 53 points by itself.

Analysis: Our autonomous section needed to be tuned, and our drivers need more drive practice so the arm can be more reliable.

Match 3: Win

We got a total of 68 points, with no penalties. Our human player was incredible at telling the other team to not put their robot in the substation as she was placing cones. In the autonomous section, we scored a cone and got parking. This was the most we were capable of in autonomous. In driver control, we got 3 cones and we got another cone with the beacon in the end game. Our robot scored 53 points.

Analysis: We could have gotten more points during driver control if our gripper mount wasn't so loose and didn't need to be constantly tightened, and we needed more drive practice for more precision/reliability.

Match 4: Win

We got a total of 78 points, with no penalties. In the autonomous section, we scored a cone and got parking, once again. In driver control, we got 5 cones, and we got another cone with the beacon in the end game. We scored 63 points with our robot, which is the highest score we got individually the whole tournament.

Analysis: This match was the limit of both our autonomous and driver control, which means we need to push the limits and make the robot more efficient so more points are possible.

Match 5: Loss

We got a total score of 67 points, with no penalties. In the autonomous section, our robot couldn't score the cone, but we got parking. In driver control, we got 3 cones, but we didn't manage to get a cone with the beacon during the end game. We got a total score of 35 points with our robot.

Analysis: We need more driver practice and precision, because adjusting the arm slightly when it's fully extended is incredibly inaccurate as it has very high momentum. We also need to practice different strategies, specifically defense, and not get distracted from our strategy by the strategy of the opposing team. Our autonomous section also needed to be more reliable.

### Post Mortem

Strengths:

• Not having to move the placement of the robot to score
• Flexibility - we can score across the field and change where we pick up our elements without interfering with our alliance's strategy or robot
• Human player - very good at telling teams not to move into box when she's placing things
• Communicating with alliance partners

Weaknesses:

• Robot is bad at making circuits due to design of the robot
• The big arm is too shaky to score quickly because of the weight
• Cycle time is too long

Opportunities:

• Doing some defensive play
• Scoring on multiple poles
• Adding a fourth extension stage by decreasing the weight of the already present rods
• Increasing the motor count to 5 on top of the turntable to support shoulder joint with more torque for the 4th stage of the arm

Threats:

• Letting the strategy of our alliance team interfere with our strategy
• Getting distracted by the opponent's strategy, limiting how well we can perform
• The cables of the robot getting tangled around itself or poles