## Iron Reign Robotics

### Next Steps

Now, we can begin cutting the above-mentioned parts on the router once they've been fully modeled. We can also begin deciding what other parts need to be modeled that can easily be cut on the router.

# Control Mapping

25 Oct 2019

Control Mapping By Bhanaviya and Cooper

### Task: Map and test controls

With the Hedrick Middle School scrimmage being a day away, the robot needs to be in drive testing phase. So, we started out by mapping out controls as depicted above.

Upon testing the controls, we realized that when the robot attempted to move, it was unable to do so without strafing. To fix this issue, we decided to utilize a "dead-zone" of the left joystick. The dead-zone is a range of values in our code that is basically ineffective. Although this meant that that the zone did not have a purpose, we realized that its uselessness could be rendered to stop the robot from strafing. Although we do plan to implement strafe later on in our actual competition robot (TomBot), for the duration of the scrimmage, the deadzone in Frankendroid's (our scrimmage robot) controls will hold the set of values for strafe so that the robot cannot strafe at any point in time during the scrimmage. This will give our drivers more control over the robot during matches.

### Next Steps

We plan to drive-test at the scrimmage tomorrow to ensure that the robot can move accurately without strafing. Once we begin code on Iron Roomba, we plan to orient strafe in such a way that it does not interfere with the rest of the robot's controls. At any rate, the dead-zone has given us a possible solution to work with if the strafe issue occurs on our competition bot.Since this is the control map for our scrimmage robot, we anticipate that the controls will change once Iron Roomba is further along in the engineering process. A new post featuring Roomba's controls will be created then.

# Driving at the Hedrick Scrimmage

26 Oct 2019

Driving at the Hedrick Scrimmage By Karina and Jose

### Task: Figure out what went wrong at the scrimmage

We didn't do too well in teleop driving at the Hedrick Scrimmage, with our max stone deposit being 2 stones. There are several things to blame.

In usual Iron Reign fashion, we didn't start practicing driving until a day or two before. Since we were not familiar with the controls, we could no perform a maximum capacity.

There were also more technical issues with our robot. For one, the arm was mounted wihh little reinforcement. Small amounts of torque provided when dragging a stone across the floor gradually made it so that the line of the arm was not parallel to the frame of the robot, but slightly at an angle. And so, picking up the stones manually was not as straight forward a task as it should have been.

This flaw could easily have been corrected for if Frankendroid could strafe. Frankendroid struggled with this. When extended, the weight of the arm lifted the back wheel opposite the corner on which the arm was mounted on off the ground. Thus, strafing to align with a stone when the arm was extended was a lengthy and tedious task.

### Next steps:

Frankendroid has served its purpose well: it moved at the scrimmage and gave the team a better feel for the competition environment. But it's time to let go. Moving forward, Iron Reign will focus its efforts on building our circular TomBot Ironically, we will likely have to deconstruct Frankendroid to harvest parts.

# First Season Scrimmage at Hedrick MS

26 Oct 2019

First Season Scrimmage at Hedrick MS By Trey, Bhanaviya, Ben, Jose, Justin, Aaron, Karina, and Cooper

### Task: Compete and observe important things needed to continue the build of circle robot and for future competitions.

This Saturday Iron Reign attended the scrimmage at Hedrick Middle School. This scrimmage was for many rookies, the first exposure to a competition environment and the basic structures of team communication. Both the rookies and the returning team members had an opportunity to communicate with different teams and to get exposed to different ideas and their respective thought processes. Iron Reign used this scrimmage as a way to look at what robot designs were most effective and a lot of key aspects of the game we may have glossed over earlier in the season.

Many things determined a robot's effectiveness, for example, we noticed that the robots in the competition that did the best were the ones that had the most direct routes and were able to manipulate the stones efficiently and effectively. We also noticed that positioning and placing the stones on the towers was very difficult for us and the teams without programs that automatically line up the stacks. This strengthens our need for circle robot which when finished should be able to stack with much more precision than the average robot. The other thing that the circle robot would help with is lining up the arm to pick up stones which also proved to be very challenging for teams with grippers that need to grab a block in a certain orientation like us.

There were a lot of unexpected penalties that can change the tides of a game, for example, the human player can not place an object in the quarry if there is already an object in it. Doing this awards 15 points to the opposing team. Another thing we learned is that to receive the points from delivering a stone the robot must fully cross over the tape under the bridge. A lot of people with push-bots lost points because their robots didn't fully cross the tape. Overall, penalties and losing points were easy ways for a team to lose a match quickly and if we don't watch what we do we can potentially lose an entire competition because of them.

### Next Steps

Our next steps are to keep working on the circle robot because it should be able to better complete the challenge. We also see like never before that even though this robot is not done, we still have Frankendroid and we still need to perpetually do driving practice with it because ultimately, the best teams will have the most driving practice. However, the biggest next step we are taking is that we are coming to practice more often because our first qualifier is so close but we are so far from a good robot. There is still a lot of work to do.

# Coding Before Scrimmage

26 Oct 2019

Coding Before Scrimmage By Cooper, Karina, Bhanaviya, and Trey

### Task: Finish the temporary auto and work with drivers for teleop

Tonight, the night before the scrimmage, We worked on making the depositing of the stone and parking of the robot more reliable. Or as reliable as possible, as we are planning to use FrankenDroid, which is somewhat in need of repair, which I also did with the help of Trey, Bhanaviya and Karina. This had a few changes come with it, as while we solved the problems of when we started the auto, there were still many that cropped up.

Problem #1 - dragging the base

In the auto, we need to drag the build area into the taped off section in the corner. This poses a problem, as dragging it can lead to major inaccuracies in estimated positioning. This, however can be solved somewhat easily once we have a distance sensor, which we could use in junction with PID based turning. Though in theory I could have done it with just the PID turning. While I would have loved to test that, there was another problem--

Problem #2 - problem with hook

There was a problem with our hook. I tried every time I ran auto to get the hook to work. I changed the return value, I changed the physical positioning of where it started, yet nothing worked. This was interesting, as it does work in the teleop. In any case, it prevented us to actually dragging the base in this version of auto. Looking back on it, there was a possibility that I needed to set it as a timed state, like the gripper, since we were using a servo to control it. While its unlikely, it's possible.

Problem #3 - PID Tuning?

This was the major issue of tonight, which we haven't found the root of just quite yet. During the auto, at the third turn, where the robot turns to heat to the foundation, there is a ~25% chance that the PID does not check where it turns and it just continues wherever it turns to. This usually leads to it overshooting and then ramming in to the wall. There is a temporary fix, however. For now, it seems that if only happens after we upload the code to the robot, or if we run auto fresh off of it being off. That is to say, if we run the auto at least for a second and then reset and re-init, then it will be good. This is a good thing however, as any chance we get to fix the underlying code's problems, that means we won't have to make a work around after in the season.

Problem #4 - putting the block on the build platform

This was the major fixable problem in the code. During auto, we need to take a block from the quarry and put it on the foundation. The problem is when we actually go to deposit it. When we go to put it down, we need to be very accurate, which with FrankenDroid is not easy. With no distance sensors, the best we can do is to tune the exact movements. While this isn't the greatest solution, this will do for now. In the future, we will have a distance sensor so that we can know where we are exactly in relation to the base.

Next Steps

We need to implement the distance sensors and other sensors on the robot. Obviously we aren't going to be using FrankenDroid for too much longer. TomBot may bring new innovations like a telemetry wheel which will make auto more accurate.

# TomBot Suspension

26 Oct 2019

TomBot Suspension By Ben

### Task: Design a suspension for TomBot

3 Different iterations of the passive suspension.

We've decided to design a suspension for our circular chassis for one reason. Under the neutral bridge, there is a 15mm lip on the floor plate to connect the bridge support. Traveling over this plate can cause significant depreciation of the chassis and connected subsystems.

We have currently made 3 different versions of possible prototypes. We will be using a passive suspension system. The suspension will be 3D printed in Nylon, as it is fairly strong and flexible. It is also shatter resistant, making ideal for withstanding large and nearly instantaneous forces.
Our first design was a triangle, but we determined that it was too rigid and wouldn't flex enough to absorb the impact of running into the floor plate at high speed. The next design was an ellipse. An ellipse has the capacity to expand outward, making it ideal for absorbing significant impacts. The first ellipse, however, was too small and unable to support the weight of the robot and flex enough to absorb the impact. The second ellipse is taller, enabling it to withstand the weight of the robot and forces from driving onto the floor plate.

The suspension will be attached to a 3D-printed wheel mount. This mount will have the capacity to slide vertically as the suspension absorbs any impact.

Wheel mount with example suspension

As of now, we haven't conducted actual trials on any of these prototypes. In the event we determine that Nylon is not ideal; we may look into designing a shock absorber made from NinjaFlex. NinjaFlex may be suitable due to its flexible nature. A part could be designed, such as a cylinder, with a thick hexagonal infill. This would allow it to flex while maintaining some rigidity.

### Next Steps

After creating a few more different types of passive suspension systems, we will want to begin testing them. They will have to be attached to the robot and individually tested. We may also want to design a NinjaFlex suspension regardless of whether or not the Nylon suspension proves viable to see which is ideal.

# Hedrick Scrimmage - Code

26 Oct 2019

Hedrick Scrimmage - Code By Jose and Cooper

### Task: Discuss what went and what needs improvement in our code

Taking part in the annual Hedrick Scrimmage, we got to test our Robot In 24 Hours, FrankenDroid. Specifically, since both coders on the team are new to the sub-team, we wanted to see the code capabilities we could offer. For this event we had two autonomous paths: the first one simply walks underneath the skybridge for some easy 5 points, the other grabs a stone(we had no vision on FrankenDroid so no way to detect a skystone), moves to the building zone to drop said stone and parks under the skybridge. For being coded in a just a few days, these auto paths were both high in pointage and accuracy/precision. As well as auto, we wanted to test driver enhancements. These were coded at the event but proved to be useful. They include: a button press to move the arm to either fully retracted, perpendicular to the ground for strafing, and disableing strafing whilst in stacking or intake mode. These also proved to be effective on the playing field, making the drivers' life easier.

### Next Steps

We need to incorporate vision into our autonomous, most likely Vuforia, to be able to detect skystones as well as speeding up the auto paths to be able to complete a 2 skystone auto.

# Ordering a Slip Ring

26 Oct 2019

Ordering a Slip Ring By Jose

### Task: Order a slip ring for the turn table

In order to spin the turntable on TomBot we need to use a motor with a specific gear to make it spin and as a bonus we can use a slip ring to transfer power to it. Slip rings can prove to be useful since there would be no need to worry about wires getting tangled after the turntable spins a certain amount in the same direction and if done correctly, the turntable can be spun continuously, allowing for the very much necessary victory spins. The specific slip ring we need should have 6 wires, be able to handle 20 amps and 12 volts, and be at least 20mm in diameter. After some research on various sites, we found what we needed on aliexpress.com. This company features various slip rings for various purposes, which includes our "custom project" need. We ordered one at a hefty price, but if it works, its benefits will be worth it.

### Next Steps

Once the slip ring arrives we can begin testing it on a test turntable to verify its viability on TomBot.

# Updating TomBot's model

27 Oct 2019

Updating TomBot's model By Bhanaviya and Ben

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

With our first qualifier being less than a month away, Iron Reign embarked on an ambitious project to create a robot with a circular chassis named TomBot (which was, for reference, named after our coach's cat, Tom). Before we began the build of the robot, we planned out the chassis design in an earlier post on CAD. Now, with our chassis progress from last week, the model has been updated.

The updated model still has the same base chassis design from the earlier model, but it now has extrusion bars above the chassis that were added in to the actual robot last week. It also has a turn table mounted on top of it to support our gripper arm and a gripper arm. As of now, the turn table hasn't been built yet but planning it out in the robot model will make it more efficient for us when we do start building.

### 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.

# Round Chassis Assembly

02 Nov 2019

Round Chassis Assembly By Justin, Trey, and Jose

### Task: Attatch Omni wheels to Round Chassis

Today we finished assembling the round chassis for our circle robot, TomBot. The most important system we added was the omni wheels to the front and rear of the robot. Without the omni wheels, the robot would tilt like a seesaw around the central 2 big wheels. These omni wheels lightly touch the ground in the front and rear of the robot to keep the chassis parallel with the ground.

The omni wheels were attached so that we have 3 wheels in the front and 3 in the rear. We used 3 wheels to give us more points of contact and more stability at high speeds. The wheels mounted to our new Go Bilda bearing mounts. The mounts have a central bearing with 2 mounting points that branch off of the bearing in a Y shape. The difficulty with this system of mounting the omni wheels is finding the correct height from the polycarb base to mount the bearings. The wheels should be as close as possible to the same height as the 2 big central wheels. The threads in the branches of the Y-shaped bearing mount are very short, which means that almost all the height adjustments need to be done with spacers and long screws. We used the longest screws we had, and after screwing them in to check if the height was right, we found that they were pretty close to what we needed. They still needed spacers to keep the screws from pushing up through the polycarb base, so we used the spacer heights to fine tune the height to get the omni wheels as even as possible with the big wheels. We found that exactly 1 and a half white plastic spacers looked pretty close to the height we needed.

After assembling both sets of wheels, we placed the robot on the field and checked to see how much it tiled back and forth. We found that the 1 and a half spacers was the exact height we needed, as the robot doesn't tilt or wobble at all, and the big drive wheels still have plenty of traction on the field to drive the robot.

These omni wheels allow us to use the chassis to test and work on our other subsystems, but we see some potential flaws in the wheels. The most significant flaw will occur at high speeds. The platform in the middle of the field has a steep edge to it, so driving over it at high speeds will cause those front omni wheels to take a lot of force. Since the mounting is rigid, that force will affect the whole robot and could either jam the robot up against the platform or cause the robot to hop and get shaken up a bit when it drives over.

### Next Steps:

One of our modelers is working on 3d printing a suspension system to allow the omni wheels to retract under force. For testing purposes, and for our first qualifier, the rigid system should be fine, but later on the suspension will allow us to move at maximum speed. Our next step is to start assembling the rest of the robot to the chassis.

# Transition from Expansion Hub to Control Hub

02 Nov 2019

Transition from Expansion Hub to Control Hub By Jose and Cooper

### Task: Discuss the transition from using the Expansion Hub to using the Control Hub

Over the past month we have used the control hub our robot in 24 hours, FrankenDriod. This was a great way to test its viability before implementing in onto our competition robot. We have already used the control hub at the REV test event where we were given a sample control hub to replace the existing expansion hub in our Rover Rockus bot. This proved the control hub to be much better than the expansion hub since there was no worry of a phone disconnect mid-match. This was no different on FrankenDriod, as we had less ping, didn't have to worry about a phone mount, and most important of all, we could push code to it via wifi. This is a useful feature since modifications to the bot's code can be done on the spot with no need for a wired connection. The only downside we see as of now is that an external webcam must be used for vision, this of course, is because we no longer have a phone to this. This is fine since we are used to using a camera for vision anyways so there is no difference there.

### Next Steps

Considering that our team is one of the NTX teams who have received permission to beta-test a control hub at qualifiers, we will now use it on our current competition bot, Iron Roomba, especially since we have proven the control hub to be fully viable on a competition bot, having used FrankenDroid at the Hedrick Scrimmage.

# Stub Gripper

02 Nov 2019

Stub Gripper By Jose

### Task: Building gripper iteration #7

As our 8th gripper design we modeled a stub gripper, inspired by 7129’s Ri30H. Several of our previous grippers were designed with the intention of being mounted our scrimmage/Robot in 2 Days bot Frankendroid. This is our first gripper design modeled with the full intent of being mounted on our circular chassis bot, TomBot. In essence, this gripper has some bars to align the gripper with the stone and grabs it by one of its stubs. The benefits of this design is that it’s the most compact of all our grippers and it can grab a stone from either its long or short side. The drawbacks are that it requires great driver precision and whatever we use to grip the stub needs to have lots of friction to not lose grip since there are few points of contact.

### Next Steps:

We will add this design to the others and decide which one is best to actually implement it on TomBot.

# Turn-table Assembly

02 Nov 2019

Turn-table Assembly By Aaron and Trey

### Task: Finish assembling the turn-table

During today’s meeting, we were able to complete the mounting of the pinion motor assembly to the turntable. This included drilling out holes and routing out a square in the polycarbonate disk that we are using as a base for mounting. We also rebuilt the pinion mechanism and implemented it into a smaller configuration.

The idea with the turn-table is to eliminate the need for strafing. In this game, precision is key. Strafing allows for the robot to precisely move from side to side, however, with a turntable, the robot won’t even have to move. We can attach the gripping mechanism to the turntable and move the gripping mechanism side to side independently from the actual robot itself.

### Next Steps:

Next we can mount the turntable on to the actual robot itself. We now have a slip ring that will allow the turntable to turn freely without worrying about wiring getting caught up in the motion.

# 3-Fingered Gripper

09 Nov 2019

3-Fingered Gripper By Jose and Aaron

### Task: 3D Model and build an 8th gripper design

As our 8th gripper design we are trying out a compact design known as the 3-fingered gripper. This was 3-D modeled before being built as a proof of concept. The back of the gripper has two bars to orient the stone before being grabbed. One bar contacts the stone and the other does too as TomBot continues to approach it. The actual grip comes from a plate that can open and close via a servo. Once the design was modeled it proved to seem reliable, especially because of the two bars orienting the stone.

Now for the fun part, actually contructing the gripper. REV extrusions were used for bars at the back since their width is ideal for the job. From here we used GoBilda parts such the plates and a hinge for the rest of the design. Optimizations were made for the attachment of the GoBilda plates since they aren't the exact length needed, and once another plate was attached to the first via a hinge we added a servo. This servo opens and closes the gripper(of course), to do so a polycarbonate bar was used to connect the servo and the hinged plate. Finally, we added grip material to the back bars and the gripping plate. By using a servo tester we were able to test its functionality. Tests proved that grabbing the stone is really easy, but the grip could use work.

### Next Steps

Compared to the other gripper designs this one seems to work best so we will optimize it some more add it onto TomBot.

# Gripper Iterations Summary

09 Nov 2019

Gripper Iterations Summary By Bhanaviya

### Task: Go over our 9 gripper iterations

This season, we experimented with 9 gripper models - both for our robot in three days project and for our competition bot. While we do not plan on using all 9 of these models, they allowed us to effectively implement the engineering process within our build season. Experimenting with each gripper 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 gripper designs so far.

### 1)Wheel Gripper

This was one of our first designs and was intended mainly for our robot in 3 days bot. This was also the very first gripper we actually mounted onto our robot. It started out as a rolling intake but then was modified so that the standard rev wheels on the gripper could swivel to grab the skystones.

### 2) Parallel gripper

This gripper functions with two rev extrusion bars moving inwards parallel to a stone to grasp it. We never actually implemented this design into any of our robots but it allowed us to understand that for it to work it would need to be mounted in front of a more solid back-plate. We later used a polycarb back-plate for a couple of our later designs.

### 3) Rack and Pinion Gripper

We've never used rack and pinions in our subsystems before so this was also a relatively new idea to test. We used polycarb grips to test out this gripper. While this gripper worked, it was also rather slow to function and we needed a faster gripper. While we didn't use these, we used the polycarb grips for our later gripper design.

### 4) Aaron's Super Cool Gripper That Works 100% Of The Time

This gripper has two ninja flex grippers to swivel to grab skystones. This was the second gripper that was used on Frankendroid after the wheel gripper. It also has a polycarb back-plate for stability.

### 5) Pivoting Accelerated User-Friendly Locker

This gripper, P.A.U.L for short, is modified version of the rack and pinion gripper. It has the polycarb grips but instead of a rack and pinion system it has two servos that control two gears mounted on a polycarb back-plate. This gripper was also mounted on Frankendroid. This design was later modified to create a more improved version.

### 6) P.A.U.L Version 2

Speaking of improved versions, this gripper replaced the polycarb grips on Gripper #4 with ninjaflex gears. It combines design #4 and #5 to create a more effective sub-system as it had more space to rotate to grip around the blocks. (this design does not have one single post but two - one about its testing and one about modelling the ninjaflex gears).

### 7) 3-Finger Gripper

This gripper has a plate attached to a servo such that the plate can move vertically to close down on the stone, with two extrusion bars on the back of the gripper to support the stone as it is being lifted. This is one of our newer designs but it has been tested, and we plan to mount it onto TomBot to determine its precision.

### 8) Stub Gripper

The stub gripper grabs onto mainly the stubs of the skystone. This gripper hasn't been built yet either but it has been modeled on Fusion 360. The effectiveness (and challenge) of this gripper relies on it being able to pick up a stone with minimal contact to the stone itself.

### 9) Cylindrical Gripper

The cylindrical gripper is being modelled on Fusion 360. It comprises of a c-shaped tube rotating and closing in around the stone. While we don't have any immediate plans to use it, its an idea that has potential and we plan to experiment with it once we've narrowed down the most efficient gripper ideas for the TomBot.

### Next Steps

Now that we have analyzed all of our gripper designs so far, it will be easier for us to streamline which design will be the best to implement on the robot. Right now, we are leaning towards the 3-finger gripper since it's compact, easy to function, and is the only gripper made with the specific intention of being implemented on TomBot.

# CNC Turntable Mounts

10 Nov 2019

CNC Turntable Mounts By Justin

### Task: Model and CNC way to mount the turntable to the chassis

Today we worked on creating a 3d model for a CNC cut part to mount the turntable to the chassis. Since the turntable already has bolts sticking out of the bottom, we decided to use those as mounting points for our part. The most efficient solution to mounting the turntable is to cut a plate that attaches to the turntable bolts and has points to attach legs that will attach to the polycarb base. For convenience, the legs will be vertical tapped rev rails.

Our first decision was deciding where to mount this plate. We determined that there should be 2 plates that attach to opposite sides of the robot. The plates would be curved and attach underneath the nylon gear. Each plate would attach to the turntable using 3 of the turntable's bolts, which uses all 6 of the bolts for mounting. Next, we needed to create bolt holes for the legs to attach to. In order to be able to drop bolts through the holes, this plate must extend slightly outside the turntable, because the plate will be flush with the nylon gear. We created a common radius from the center of the turntable where these holes will be placed, so that there is enough distance between the holes and the nylon gear. These holes would have to be placed so that the attached legs aren't blocked off by the rev rail already on the chassis. To fix this, we decided to put 7 total holes on each plate to mount the legs, all equally spaced around a common section of the circumference. This way we can play around with the mounting points, since we only need about 3 for each plate.

Next we decided whether to mount the plates to the front and rear, or the left and right of the turntable. We counted up how many mounting points were available for each orientation and decided that the front and back mounting would give us a stronger attachment. The front and back are also where the turntable will want to lift up and push down under heavy loads, so it makes sense to mount at those points.

During mounting, we found out that the spaces between the turntable mounting holes and the leg mounting holes at 3 points on each plate were too small to attach a REV rail leg. This is because the bolt from the turntable prevents the REV rail from being flush with the plate. To fix this, we used longer bolts on the turntable and used the revrail legs as both supports for the table and nuts to keep the plate onto the nylon gear/turntable.

### Next Steps:

Our next step is to mount the legs to the plate, the plate to the turntable, and the whole thing to the robot. We need to measure out what length of rev rail legs we need to allow the turntable to spin freely without interfering with the chassis. We then need to mark and drill holes in the polycarb base to attach the whole subsystem. These mounting plates still need to be tested with the full capacity of the robot. Any issues should only come from the rev rail legs, which can later be replaced with a more custom solution.

# Mounting the Slip Ring

10 Nov 2019

Mounting the Slip Ring By Aaron

### Task: Mount a slip ring onto TomBot's chassis

On our robot we have a turntable in order to increase the degree of precision at which we can maneuver skystones. We have one REV Hub under the base of the bot, and one on top of the turntable. This means, however, that we need 360 degrees of rotation between the two Hubs. Our solution to this problem was to use a slip ring. By using a slip ring it allowed us to have a center of rotation for our wiring to move freely around the point between our robot base and the turntable.

We mounted said slip ring to the circular piece of polycarb that is bolted down to the outside of the turntable. We then ran the multitude of colored wires through two separate holes drilled through the previously mentioned polycarb circle and through the base of the robot to the underside and to the REV Hub mounted to the bottom of the robot.

### Next Steps

Our next step is to ensure that the turntable on the chassis is mounted securely enough so that the motion of the slip ring won't cause it to topple over. To do this, Justin has modeled turntable mounts which we will mount onto the robot during the next meeting which will be the Saturday morning of the Woodrow Scrimmage.

# Responding to Girl Scouts of Desert Southwest

13 Nov 2019

Responding to Girl Scouts of Desert Southwest By Bhanaviya

### Task: Respond to an email about the MXP to the local Idaho STEM director of Girl Scouts.

The Mobile Tech xPerience

Today, Iron Reign received an email from the STEM director of the Girl Scouts of Desert Southwest saying that they are seeking to create their own mobile learning lab, similar to our Mobile Tech xPerience (MXP). As such, in the email we were asked for the story of the MXP - its deconstruction, construction, design and the like. Considering the MXP is nearing its time for expansion, it was fitting that we received this email. Since the correspondence comes from Idaho, this will also be our first out-of-state connect opportunity of the season.

In a brief summary, in our response we detailed the interior construction of the vehicle. Buried in this blog's archives is a series of posts that details the whole deconstruction and reconstruction process of the vehicle. Of course, no one from our current team was involved in this process and as such, we made sure to accredit the interior furnishing of the vehicle to our team alumni. This process included replacing the carpeting with wood-grain vinyl, adding new shelving to store LEGO robots, installing new wide-screen monitors, and creating a bay to stock 3D printers.

The floorplan for a second vehicle

We also made sure to explain how the MXP is operated. For reference, the vehicle is operated by Big Thought, our programmatic partner, and during the vehicle's deployment at outreach events like Moonday, our team mans and runs the MXP booth where we teach students how to block-program LEGO EV3 robots to battle one another, and how to 3D-print a keychain on SketchUp that they can take home. Now, the MXP is nearing end of its lifetime and Big Thought has plans to expand the program by creating a new, bigger vehicle.

### Next Steps

We were very gratified by the STEM director of the Girl Scouts of Desert Southwest reaching out to us about the plans for their mobile learning lab. Being able to take part of the MXP's mission to bring STEM education to students in the greater Dallas area has been one of the best opportunities Iron Reign has recieved, and its one we intend to pass on to others in our community like the Girl Scouts. We wish them the best of luck in putting their plans to fruition and are looking forward to answering any more questions they have on the plans for the vehicle.

# Logarithmic Spiral Design

15 Nov 2019

Logarithmic Spiral Design By Ben

### Task: Design a system that could linearly reduce torque.

Since last season, we have conducted a significant amount of experimentation on our elbow and slide mechanism. We are using a similar design because we have prior knowledge on how to construct and maintain the subsystem; however, our slide this year is larger due to our desire to stack the stones higher. Although our elbow could lift the entire slide, we want to reduce the strain on the system by designing a component that would apply torque to the slide. Reduced strain will decrease the maintenance we will have to perform and will also increase the efficiency of the elbow by assisting it. The part would be attached with a bungee from the part to another part also on the turntable a few inches away.

We decided to use a logarithmic spiral (r=ae^(bθ)) because it would reduce the torque exerted on the elbow linearly. To create this spiral in Fusion360, we had to write a script because there is no native spiral/equation builder. The code can be seen below and was adapted from code that can be found here. Once the code was executed, it created a sketch of the spiral, which you then had to spline into a line. Since we wanted the spiral to be tangent to the gear it would be attached to, we imported a model of the gear and aligned it with the spiral to find the optimal a & b values. Another requirement was that the spiral must be under 3 in and preferably 2.75 in to allow for space between the elbow and turntable plate. These values were a = 0.2 & b = 0.6, which were determined through various trials.

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 import adsk.core, adsk.fusion, adsk.cam, traceback, math def run(context): ui = None try: app = adsk.core.Application.get() des = adsk.fusion.Design.cast(app.activeProduct) root = des.rootComponent # Create a new sketch. sk = root.sketches.add(root.xYConstructionPlane) # Create a series of points along the spiral using the spiral equation. pnts = adsk.core.ObjectCollection.create() numTurns = 5 pointsPerTurn = 20 distanceBetweenTurns = 5 theta = 0 offset = 5 a = 0.2 #aVal b = 0.6 #bVal for i in range(pointsPerTurn * numTurns + 1): r = a * math.exp(b * theta) #Definition of a logarithmic spiral x = r * math.cos(theta) y = r * math.sin(theta) pnts.add(adsk.core.Point3D.create(x,y,0)) theta += (math.pi*2) / pointsPerTurn sk.sketchCurves.sketchFittedSplines.add(pnts) ui = app.userInterface ui.messageBox('Spiral Done') except: if ui: ui.messageBox('Failed:\n{}'.format(traceback.format_exc())) 

Final design over original spiral

Once we had the design, we printed it onto paper through the Fusion draw tool. We then confirmed that the holes aligned with the gear.

After confirming the design aligned, we began preparing it to be machined on our CNC. For this part we went with 1/8in aluminum because it is both durable and inexpensive. It will also withstand the forces that will be exerted on the part.

The finished part came out nicely with a few tabs that had to be removed. The part fit correctly and was successfully attached to the elbow and gear.

### Next Steps

Our next steps will be to machine the part again, creating an identical copy, and printing the same design out of nylon, but taller. The nylon component will be sandwiched between the aluminum pieces and will have a cutout that will connect a bungee cord to it. We also have to design a part that will connect the bungee to the other side of the turntable. After introducing the bungee, we will have to conduct trials on the elasticity to determine the best bungee length or composition. These are necessary because we don’t want to apply too much force, restricting the elbow from lowering, yet we want to apply enough force to considerably assist the elbow when lifting.

# Presenting Our Engineering Notebook

16 Nov 2019

Presenting Our Engineering Notebook By Karina, Justin, Bhanaviya, Cooper, Jose, Ben, Aaron, and Trey

### Task: Share with other teams how Iron Reign creates its engineering notebook

This weekend Iron Reign attended the Woodrow Wilson Scrimmage. On top of participating in the scrimmage, we were invited to present on Engineering Notebook Success as part of the morning workshops. The team went through our slides, going back and forth with our audience when they had questions, with two major focuses: journal content and the physical notebook. You can access the presentation below:

Iron Reign would like to emphasize that this is how our team creates its engineering notebook, not that it is the "right" way.

One thing we want to emphasize is that unlike previous years, presentations only run for 5 minutes before being cut off. And so, the engineering notebook is the main way teams can advocate for themselves to the judges outside of face-to-face interactions. Therefore, teams must effectively communicate what they want judges to know about their team through the notebook. Iron Reign does this by highly organizing content through the use of tabs and highlighting to correspond with specific awards. We included other suggestions, such as table of contents and a "how to read this notebook" page, all for the convenience of the reader.

# Woodrow Scrimmage

16 Nov 2019

Woodrow Scrimmage By Trey, Bhanaviya, Ben, Jose, Justin, Aaron, Karina, Cooper, and Paul

### Task: Compete and work on TomBot at the scrimmage at Woodrow HS.

This Saturday Iron Reign attended a scrimmage at Woodrow High School. Woodrow offered a variety of activities that improved the capabilities of our team like for example, the mock judging sessions. Our session gave us insight into how our judging presentation needed to be reformed and cut down to fit into the new five-minute time limit. It also gave us a chance to see who was going to do each slide and how long they should talk about it. Other criticism we received was founded on the same basis that we were not owning up to our story, were not motivated enough, and were more focused on the infrastructure we were given rather than what we had done with it. All of these points are entirely valid and were worth looking further into and making better.

Iron Reign also held a journal workshop where Rookie and veteran teams alike were able to learn the basics of constructing and preparing an engineering journal for competition. It went through the most important organizing structures, writing techniques, and time management practices. This workshop went well and we would definitely do it again in the future.

When it came down to performing in the robot game we did not surpass our expectations even though we made first place out of all the teams there. This was because we were using Frankendroid, the barely functional robot we built in two days. This robot was only capable of producing subpar results fully functional but at this particular competition, it was not fully functional. This means that Frankendroid was only able to make at most ten points because of a broken encoder cable that rendered the arm nonfunctional. However, we are not going to use this robot at the first scrimmage next Saturday. Instead, we are going to use TomBot which was being worked on the entire time. In that time we were able to attach the arm and gripper and write some basic code to control the robot which is still being debugged.

### Next Steps

Iron Reign is working around the clock to make sure that we don’t show up with a robot like Frankendroid at the first qualifier. We are well on our way to finishing the arm and turntable on TomBot. We are also working to better the judging presentation and to fit it into the newly established 5-minute time limit. So far it looks like we are going to get there by Saturday.

# Linear Slides on TomBot

19 Nov 2019

Linear Slides on TomBot By Justin

### Task: Mount linear slides to the robot.

Today we focused on getting the arm and linear slide ready to be powered up. Our first task was to move down one of the stages of the linear slide to align the slides. We also adjusted where the carriage stops to further align the slides.

Next, we began to run the belts through the pulleys. We needed to run the belts around the motor and accidentally put on an extra pulley, but we got the slides to move by pulling on the belt. To let the motor power the slide, we had to attach the both ends of the belt to the same carriage. To reach the below the slides from the top carriage, we had to attach a bracket with a screw sticking across to tie the belt onto. The bracket was made out of a bent GoBILDA flat plate. The hole spacing on the plate matched exactly the hole spacing on the nylon mounts for the final stage, which were also CNC drilled into the metal bracket. This made attaching the mount and bent plate to the metal bracket very easy. We extended the bottom row of the bracket out to one side to place the crossing screw away from the gears of the arm. The plate has a slight flex to it under the load of the belt, but will function fine as a tensioner for now.

### Next steps

Next, we need to check the robot for sizing and mount the last stage and gripper to the arm. The gripper mounting system needs to be decided, because wire won't hold up this weekend.

# Coding TomBot

20 Nov 2019

Coding TomBot By Cooper and Jose

### Task: Use existing code from the code base to program TomBot

To code TomBot, we decided to use the codebase from Frankendroid, as its the one we were most comfortable with. This will change after the qualifier, as we recognize that the robot is more like last year's robot, Icarus. This will, in the long run, help us as we will be able to minimize the amount of refactoring we have to do. But in the meantime, we made 4 major changes in the code for Tombot.

Change #1 - Mecanum Drive to Differential

The first was the change from a mecanum drive to a differential, arcade style control. This was done by commenting out the lines for strafing, and changing the method call to a dormant method, which was a remnant from some testing done with a linear op mode for an early version of FrankenDroid. We got rid of the power assignment for the front motors, and just used the back two motors to represent our 2 drive motors. This gave us some trouble, which I’ll cover later. After that trouble, the method was still broken, as the left stick y was controlling the left motor, and the right stick x was controlling the right motor. This was due to the incorrect power assignments in the code. With that fix done, it drove as it should after the switching of an encoder cable.

Change #2 - Rolling Gripper to 3-finger gripper

The next 'big' change was the change from the rolling gripper on frankenDroid to the 3- finger design on TomBot. I use the word big lightly, as it wasn't more than commenting out the lines for one of the servos. However, this will have a major impact, which can be seen in the details in our grippers post. This is also note worthy in terms of auto, as it will have adverse effects on auto. This is due to the current instability and overall unpredictability of it. So, in auto, we will have to compensate for it.

Change #3 - Turret

One of the biggest changes to the code base we made was with the Turntable class that I wrote. This was also, therefore, the hardest part. Due to the fact I'm still relatively new to this, I got a lot of my examples from the Crane class that Ahbi wrote last year. I started first by tackling making a basic skeleton, including methods like rotateTo() and rotateRight(). Then I started filling them in. For some reason, the first go around at this, I decided to through out all the things they taught me in school and use rotateRight() and rotateLeft() as my lowest level method, instead of rotateTo(). Another thing I failed to realize is that I didn't fully get the Crane class, and made a redundant positionInternal variable for the encoder values that is assigned at the rotate method calls and then another variable called currentPosition was assigned to that, and then the encoder value for the motor was set to that. This sounds stupid, because it was. This cost me a good day of working and was a great lesson in taking my time understanding something before I go off and do it

Once I had realized my misunderstandings of the Crane class, I was able to move on. I cut out all the unnecessary positionInternal code, using the other variable (currentRotation) to be changed in the rotate mehtods. Speaking of, I also got some sense into me and changed the rotate methods to use setRotation() as its lower-level method, making the code more professional in nature. This, still, was not our only problem. Next was encountered a bizzare glitch-like attribute to using the rotate methods. There was a sporadic, sudden movement whenever we pressed the button assigned for turning the table (the a button as it was just a test). After many looks at all the possible variables of failure, we whittled it down to be the fact that we assigned it to the controllers A button. What we observed was the turntable working, just not how we thought we were telling it to. In the button map, there was a method called toggleAllowed() infront of all the boolean-value button. This, unbeknownst to me was actually a toggle method written by Tycho many years ago. This toggle made it so the action assigned to the button only happened once, which is useful for things like latches and poses, as the driver could overshoot it if left to un-press the button in the correct amount of time. This, however, in our case led to the turnLeft() method (the one assigned at the time) only happen once, which was that sudden, sporadic movement after the a button.

Once we changed it to a trigger, it worked-- almost. there was still some bug in the code that made it do some pretty funky stuff, which is hard to describe. After we whittled it down to just a small error of changing a negative to a positive, it worked perfectly.

Change #4 - XML file

During the Woodrow Scrimmage, I spent most of my time dealing with null pointer exception errors and incorrect XML assignments. This was, again, due to a lack of knowledge of the code base. I tried to comment out certain motors, which led to the null pointers, and tried to get rid of those null pointers in the XML file. After awhile of this loop, I realized my mistake in that the null pointers were due to a method call on an uninstantiated object. When I put all the assignments back in the Init, I was finally able to get it running

Next Steps

My next steps are to tune the PID values for auto, so I can use the skeleton from FrankenDroid. Then I need to take some of the sounds from the driver phone, like the critical error one, as it can severely affect workflow and my sanity. Finally, I need to change the turret to make it so that it uses the IMU heading instead of entirely the encoder value from the turntable.

# Morph Chart

20 Nov 2019

Morph Chart By Bhanaviya

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

Iron Reign has seen several iterations of several subsystems 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 different subsystems coming together. To do this, our team used a morph 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.

The left axis showcases the different subsystems like gripper designs for both robots, chassis designs and progressions, and extension mediums. A morph chart is often used by professional engineers to document the cyclical nature of choosing and moving through various designs. So far, Iron Reign has been through 9 types of gripper designs, 2 chassis designs, 2 linear slides systems differing in lengths and a third one incorporating the logarithmic spiral described in an earlier post.

Across each row, alternative designs for each subsystem have also been depicted. As of now, our current robot has a circular chassis as shown in the second design in the fourth row, a flat gripper system as depicted in the first column of the third row, and a linear slide system supported by a logarithmic spiral in the fifth column of the fifth row.

### 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 morph 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.

# Last Minute Code Changes

22 Nov 2019

Last Minute Code Changes By Cooper

### Task: Debug some last-minute code to be ready for our first qualifier of the season

This article may seem a bit rushed, but that's because it is - for good reason. Tonight is the night before the qualifier and it’s roughly 2 in the morning. Tonight we got a lot done, but a lot didn’t get done. We can explain.

We finally have a robot in a build state that we could use to test the code for the turntable properly. The only tragedy - it wasn’t refined, per say. But it’s good enough for tonight. There are some random discrepancies between the controller and the actual turning portions of the turntable, but they seem to be largely minute.

Next, we had issues just a bit earlier tonight with the elbow. First off, the elbow was backwards. The elbow would count the ticks backwards, such that down was a positive tick direction. Looking through all the code, we saw that the motors’ encoder value was flipped through a direct call to the DCMotor class. So we turned that one off and tried it but that didn’t work, so we then found another and put back the first in a different position in the code, thinking they’d cancel out. But, eventually, the solution was as simple as taking out the encoder values, which allowed the elbow to count the ticks forward. We plan to fine-tune our solution after the qualifier, but for now, it will allow the elbow to work.

### Next steps

Get some sleep and then refine and complete the code tomorrow morning at the qualifier, and hopefully write some auto

# Night Before Competition Build

22 Nov 2019

Night Before Competition Build By Aaron, Cooper, and Trey

### Task: Transform a mass of metal into a functional something in the span of one night in time for the qualifier tomorrow.

Twas the night before competition and the robot was most definitely not competition ready. This is what usually happens, but once again we found ourselves scrambling around to get everything together before the end of the night. We ended up mounting the gripper, setting up the belts, making hooks for the foundation and of course a whole lot of minor fixes and adjustments.

Mounting the gripper was actually something that we completely finished at competition, however the night before we decided the previous mount would work. Although ingenious, the previous mount would have been to wiggly and not reliable. We ended up opting for a less simple design, however more stable and efficient. With the design we came up with, we realized we still wanted a degree of rotation on the x axis so that when stacking, gravity would automatically align the stone to the rest of the presumed tower. We achieved this in the simplest way by having two c shaped bars connected by only one screw in the middle on either side, allowing it to move back and forth.

The belt was probably the most difficult part. What we needed to mount the belt was a piece that went up and over the rest of the slide then back down the other side, in order to have an attachment point for the end of the belt. This piece would be attached to the back of the top slide, and would be the highest point of the robot, which presented its own challenge. We needed this part of the robot to be able to fit under the bridges, and couldn’t make it go over not even just a bit or it would get caught and ruin the whole game. We tried constructing this piece by drilling a line of holes into the section of the metal we wanted to bend, making it weak enough to bend, however that ended up in just breaking the metal. We then decided it would be much stronger if we used the already bent L channel and just used two of them attached opposite ways.

The hooks for the foundation were pretty last minute and ended up not being very functional. This resulted in us immediately changing them when we got back from competition. The hooks we had at competition were two polycarb L shaped pieces the simply would rotate downward. We mounted them onto and axle driving by a core hex motor. The main issue what that they didn’t have enough contact area to the foundation and we couldn’t effectively move it. We also realized that if we wanted to efficiently move the foundation, we would need to be able to rotate it, which would require contact from the back as well.

### Next Steps

With the robot completely (mostly) built for our first qualifier of the season tomorrow, our next concern is driver-practice. As of now, we have no drive practice so this is something which we will be trying out for the first time this season with TomBot tomorrow on the practice fields.

# Match Play at Allen Qualifier

23 Nov 2019

Match Play at Allen Qualifier By Jose, Ben, Aaron, Bhanaviya, Trey, Cooper, Justin, and Karina

### Task: Compete in Qualification Matches and maybe some Playoffs

Today was our first qualifier at the Allen STEAM Center and we were able to compete with our official competition robot, TomBot, at the event. With its build being done the day of and its code also minimal, we didn't have high hopes coming into this competition in terms of robot game. Nevertheless, the following ensued. For reference, we have a separate post underlining the analysis of the qualifier that does not include match analysis. This post merely details how each one of our matches went, and we will have a future post discussing our drive issues at the competition.

Match 1(Quals 6)

We lost 113-36. This match was a though one against 7172 Technical Difficulties, who managed to almost set a new world record alone. We had no autonomous at this point and very little driver practice led to our low score.

Match 2(Quals 11)

We lost 5 - 29. Early on in the match the wires that control the entire arm of TomBot were caught on the team number side shield, making the bot virtually unusable during the rest of the match. (insert sad face here)

Match 3(Quals 18)

For the second time in Iron Reign history we tied 10-10. With still no autonomous at this point we had an early disadvantage and to make things worse, the servo that controls the stone grabber disconnected, making TomBot a pushbot for the rest of the match.

Match 4(Quals 28)

We won 29 - 38. In this match we got to play with our sister team 3734 but against our other sister team 15373. Despite never practicing together before we had great synergy throughout the entire match and even pulled off a double park at the end.

Match 5(Quals 31)

We lost 36-50. Our luck ran out here despite the improvements shown in the last match. We were able to run a ten point autonomous with 15204 but our opponents closed the gap during Tele-Op.

We finished the qualification matches seeded 22nd out of 28 but that didn't stop us from asking the 3rd seed, 11629, if they would like to have us in their alliance, after a quick discussion they said they liked our bot and added us to their list. This ended up working out as we were their 2nd pick during alliance selection.

Semis 2-2

We won 58-38. This was a great match where our autonomouses combined scored 20 points. From here we used a feeding strategy where 15176 fed us stones while we stacked them. During end game we also managed to get a double park.

Finals 2

We won 48-28. In this tense match against the 1st seed alliance we were able to do our 20 point auto again and executed the feeding strategy like before. During the end, however, a quick attempt at a park caused the tower we build to fall, but luckily so did the opponents' stack.

Finals 3

We lost 38-86. Both our autonomouses failed which resulted in some time wasted during tele-op to push the foundation to the building site. We were able to pull off the normal tower we build and double park, but this wasn't enough to overcome 7172's and 9161's massive lead.

### Next Steps

With so little driver practice done ahead of the qualifier, we hardly expected to receive the Finalist Alliance award but the opportunity to compete in the finals match allowed us to analyze what code and build changes need to be made to our robot to put us in good shape for our next qualifier at UME Preparatory Academy on January 11th.

# Allen Qualifier

23 Nov 2019

Allen Qualifier By Bhanaviya, Karina, Cooper, Jose, Trey, Aaron, Ben, and Justin

### Task: Compete at the N. TX Allen STEAM Center Qualifier

Right off of a subpar performance at the Woodrow Wilson Scrimmage, Iron Reign walked on shaky ground to the qualifier at the Allen STEAM Center. In the 2 weeks leading up to the tournament, Iron Reign worked hard, with countless changes to our blog and robot. Despite this, we had virtually no driver practice for the qualifier, and did not expect to do exceptionally well at the competition.

##### Inspection

For possibly the first time in Iron Reign history, we passed inspection the first time around! Our robot fit well within the sizing cube, though we will need to improve our wiring management after the qualifier.

##### Presentation

We walked in, and started off out strong. Half of a good presentation is the energy, and we certainly had a good amount of energy going in. We were also able to finish our presentation within the 5 minutes allocated, which gave us more time for questioning. Unfortunately, during our robot demo in the questioning demo, one of our chains slipped which meant that our demo was not as successful as it could have been. The plan for the robot demo was that while the turntable rotated, the circular chassis would rotate in the counter direction. However, the slip-up with the chains also took away time from our questioning, so we were unable to convey our information as effectively as we could have.

##### Robot Game

To start off, we didn't really have a working robot. However, as the day went on, we were able to make additions to our robot that eventually rendered it capable of being picked for a semi-finalist alliance, and from there, advance to the finals. For reference, this is merely a summary of the entire day, and does not serve as our match analysis. The match analysis has been documented in a separate article.

###### Match 6

We lost 113-36. With no autonomous, and little driver practice, we were no match for our opponents.

###### Match 11

We lost, 5-29. The wires on TomBot got caught on our side shields, rendering us useless for the rest of the match.

###### Match 18

We tied 10-10. We still lacked autonomous and we were basically a pushbot for this match.

###### Match 28

We won, 29-38. Our autonomous wasn't solid, but both us and our alliance (our sister team, Imperial Robotics) were able to double park.

###### Match 31

We lost, 36-50. We had a semi-working autonomous, but our tele-op performance wasn't enough to catch up to our opponent's.

We finished qualifying matches in 22nd, but talking to the 3rd seed team Todoians prior to alliance selections, helped us secure a place in their alliance for semi-finals.

###### Semifinals Match 2-2

We won, 58-38. At this point, both us and our alliance partner, Broken Axles had a working autonomous and were able to double-park at the end of the game.

Through our performance in the semis, we qualified for the finals matches!

###### Finals Match 2

We won 48-28. Although our autonomous worked well, both ours and our opponent's towers collapsed, which led to a low point win.

###### Finals Match 3

We lost 38-46. Both us and our alliance's autonomous paths failed and although we double-parked, our opposing alliance took the lead.

In summary, although we did better than we expected robot game-wise, there is lots of room for improvement that we will work on over the weeks leading up to our next qualifier.

###### After-Judging and Awards Ceremony

While we thought we hadn't done well in judging, we were quickly rebuffed. A good measure of judging success is if the judges come back to talk to you, and this was no exception. We had four separate groups of judges come up to us and ask us about *every* component of our team, from business, to outreach, to code, to design.

In the ceremony, every single member of SEM Robotics waited. Iron Golem had been the 11th place ranked team; Iron Core had been the 16th - both impressive ranks for rookie teams at such a competitive qualifier; Imperial had been the 2nd seed alliance in semi-finals; Iron Reign had multiple in-depth discussions with judges. As award nominations went on, Iron Reign has not been nominated for any of the awards, which could be a good or bad sign. Then came Inspire. We heard two names echo off as nominations; neither of them SEM Robotics teams. Finally, a speech flew across the arena as Iron Reign stood for their Inspire Award.

### Next Steps

Even though we won Inspire, we have a long way to go. We are going to compete at at least one more tournament, and we aim to get all 3 of our sister teams qualified. Although 4 teams from one program at regionals is unusual for any team, we believe that all of our teams have the potential to qualify at the next competition on the 11th. In the meanwhile, there will be several post-mortem posts for our performance at Allen, and we hope to analyze our results at the qualifier with both the current and alumni members of Iron Reign.

# Inspire at Allen

24 Nov 2019

Inspire at Allen By Bhanaviya

This weekend, SEM sent four teams to the first qualifying tournament of the FIRST Tech Challenge 2019-2020 season. Iron Reign (6832) was a finalist in robot game and won the top award (Inspire) and has advanced to the Regional Championship in February.

Left to right: Karina Lara, Justin Bosnell, Benjamin Bruick, Aaron Daane, Cooper Clem, Bhanaviya Venkat, Trey Davis, Jose Lomeli. Not shown: Paul Lea and mentors Karim Virani, Catherine Lux and John Gray.

Imperial Robotics (3734), was 8th place in match play, the highest qualification ranking of our 4 teams, and made it into the semifinals playoffs, but was then eliminated in their second semifinals match.

Iron Golem (15375) was 11th in qualifying rounds, and won 3 out of their 5 matches. Their impressive performance at the first tournament for this all rookie team has set them up for a more successful experience at the next qualifier on January 11.

Iron Core (15373), another all rookie team, was 16th in qualifying rounds, and demonstrated coolness under stress as they experienced persistent issues with robot disconnections. They are already hard at work aiming for their next qualifier.

Our thanks go out to all of the people and sponsors who have supported us already this season, including but not limited to: Mr. Schelanko and Mr. Marx and the Dallas ISD STEM Department, Mr. Gray our faculty sponsor, Mr. Palacios and SEM staff, Ms. Huitt, The Texas Workforce Commission, FIRST in Texas, DEKA, Patrick Michaud - our FIRST FTC Regional Affiliate, Fried Elliott - Regional Judge Advisor, and the Virani / Lux family.

# Build Post-Mortem

24 Nov 2019

Build Post-Mortem By Bhanaviya and Aaron

### Task: Begin analyzing long-term build improvements

Moving on from the Allen qualifier, there are a couple issues we need to fix. Aside from the usual wear and tear a robot experiences in it’s relatively short life-span, there are some specific opportunities we have for optimal robot performance which we hope to act upon.

First, our grippers don’t have enough degrees of freedom to rotate fully. Being able to rotate gives the ability to pick up stones from any orientation. As such, we plan to create a swivel mount which will allow them to turn enough to grab and place skystones.

Second, our grippers don’t have the best grip potential, so we hope to find more “grabby” materials to improve their grip. This can be anything from 3D-printed parts to some oven-mitts, which we have been considering using for a while now.

Third, our robot moves slower than we’d like it to and the turntable lacks control when turning. Part of this comes with having motors and gears with a “good enough” amount of torque to give us more control or vice versa for speed. As such, we hope to calculate the exact amount of rotational force acting upon the robot to determine how to improve its speed or control in functioning. This can be as simple as finding new motors.

Finally, we want to build a completely custom-built robot. Other than being a pretty cool flex, customizing our parts allows us to have a greater degree of control on the functionality of our robot subsystems, as demonstrated with the logarithmic spiral we printed to reduce stress on the elbow. Part of having a custom-built robot means documenting all our current parts in a bill of materials and identifying which of these parts we can manufacture in our new CNC Mill. Although we know this isn’t a goal we can accomplish before our second qualifier on the 11th, it is one we can have done hopefully before regionals.

### Next Steps:

This time, we want to test our build improvements more often since testing is one thing we haven’t been too keen on during preparation. This is mainly a long-term list of goals we want to focus on but other smaller improvements will be detailed per usual in blog posts.

# Drive Issues at Allen Qualifier

25 Nov 2019

Drive Issues at Allen Qualifier By Justin, Karina, Jose, and Aaron

### Task: Identify points of improvement after driving at Allen

While using our untested code and inexperienced drivers at the Allen STEAM Center this weekend, we encountered many issues while driving. Our biggest issue was with the turntable, which bugged us the whole day. First it was really slow, then it turned but after a 3 second delay, then we finally made it driveable but it turns to the opposite direction a little bit before going the correct direction. This was a problem the whole tournament. The turntable also had runaway, and would drift to either side. To counteract these issues, we maintained a static turntable and used the chassis to rotate. We only needed to spin the turntable maybe twice to extend into the safe zone at the end of the match. We also encountered the claw getting stuck on the side numbers when we rotated it or extended it to the side. We determined the locked straight position was the best for today.

This wasn't a prevalent issue in this tournament, but the robot not being able to drive over the middle bridge could be a problem later on. Driving this robot around the field was so easy. We didn't have to worry about bumping into things and the claw tucked in very well. After about our first match, our coder added preset positions to the controller. This made grabbing and placing blocks very easy, and ultimately displayed the capabilities of our robot to other teams and judges. This also helped us actually score points. The gripper was very basic for this tournament, which was actually helpful as it made learning how to drive the robot very simple. They claw required very little adjustments during the match to pick up stones, and did so reliably. Adding a point of rotation to joint might allow us to pick up weirdly rotated stones. Something we noticed during this tournament was the amount of robots, including ours, that couldn't pick up stones that had been tipped on their sides. Being able to pick up sideways stones as easily as upright stones could give us a unique and very effective advantage over other robots.

### Next Steps:

Our biggest task is to smooth out the turntable both in code and build. The presets and smoothness of the turning need to be tested and improved. We also need to free up some room on the robot to allow the arm to swing around while the claw is fully retracted. The changes to the arm should be made pretty soon, to allow enough time to drive and test the robot. The chassis issues mentioned earlier are not an immediate worry, but we should continue testing and improving our work in progress suspension system. The suspension, when functioning, will allow us to drive over the middle bridge, which increases our mobility and allows us to perform different strategies during matches. We will prototype a way to rotate the gripper on the arm to allow us to pick up blocks from more orientations. We will also compare the benefit of picking up sideways blocks with the difficulty of picking them up, and determine whether or not that is something worth prototyping.

# Post-Qualifier Code Debugging

25 Nov 2019

Post-Qualifier Code Debugging By Cooper

### Task: Debug code after the Allen Qualifier

After the qualifier, along with articulation plans, we had a long list of bugs in the code that needed to be sorted out. Most of them were a direct effect of not being able to test the code until the night before the qualifier. In hindsight, there were some issues which needed to be debugged in the turntable and turret.

The first one that we tackled was the turntable wind up and delay. This was one of the bigger problems, as it led to the instabilities seen at the qualifier. These included random jerking to one side, inconsistent speed, and most importantly the delay. As described by Justin, it was a 2-3 second time period in which the turntable did nothing and then started moving. This was especially important to fix for stacking, as quite obviously precision and careful movements are key to this game.

So we started at the source of what we thought was the discrepancy— the rotateTurret() method. This was under scrutiny, as it was the lowest level call, or in other terms the only code that assigns new tick targets to the motor. In the rotate methods that are called by other classes, we assigned a new value to a different value called currentRotation. Once one of the rotate (right or left) methods were called, then the new value would be assigned to currentRotation. Then where the update() method for this turret class was called in the loop, it would call rotateTurret(), which would them assign currentRotationInternal to currentRotation, and then subsequently call the setTargetPositon() giving currentRotationInternal as it’s new tick value target position.

We also started going through the demo mode that was written last year. We have this idea for a great cool demo mode that will be documented once it’s in progress. However, to get there we need a working IMU. We technically had an IMU that worked at the competition, though it was never properly used or calibrated. So, we decided to look into getting the IMUs running. We started by looking at the current demo code and seeing what it could do. Most of it was outdated. But, we did find what we were looking for- the maintainHeading() method, in which we called another method, driveIMU. We then wrote a new maintainHeadingTurret() which works pretty well. Granted, we need to adjust the kP and kI values for the PID, but that is quite easy.

### Next Steps

Continue tuning PID values in both the turn-table and turret.

# Mentoring FTC Team 6964 Igutech

26 Nov 2019

Mentoring FTC Team 6964 Igutech By Bhanaviya

### Task: Respond to a request for outreach help from Team 6964

Recently, Iron Reign received a request for advice on how we run our outreach events from FTC Team 6964 Igutech from Bethlehem, Pennsylvania. They are organizing their first outreach event for a STEM club at a local middle school and reached out to us to ask our team on how we organize our outreach events.

As a team that has participated in several outreach events around the greater Dallas area, we were happy to respond. We started out by explaining the activities we have at our events - this includes bringing Big Thought's mobile learning lab, the MXP, to the event location and using its resources to teach students how to 3D-model a keychain using ninjaflex and block program a LEGO EV3 robot (similar to the kind used in FLL), and demo-ing our competition robot, and on occasion, letting kids test out the controls themselves by driving the robot around. Something that our team takes pride is being able to get students with little to no background in STEM interested in robotics. As such, in our correspondence to Igutech, we made sure to emphasize that one thing Iron Reign focused on was trying to create an interactive experience for all participants involved.

### Next Steps

We were very gratified by Team 6964 reaching out to us about the plans for starting off their outreach program. Being able to connect with teams so far outside the NTX region like 6964 in Pennsylvania served a good opportunity for our team to realize just how expansive the FIRST community is. We wish Igutech the best of luck for their first outreach event, and we look forward to hearing from them soon.

# Swivel Mount

26 Nov 2019

Swivel Mount By Aaron

### Task: Design a swivel mount to improve the degrees of freedom on the gripper

After the recent competition, we realized that a good way to increase precision would be to add, of course, another axis of rotation. This was the most efficient way to be more precise and pick up a stone from all angles. With a swivel mount, the gripper would be able to rotate on the y axis, via a servo. We already have a simple mount that rotates on the x axis, not motor driven, that utilizes gravity to automatically align the stone with the tower in stacking it, however we realized that a lot of time during teleop was wasting in trying to achieve the right angle at which to grip the stones.

The way we achieve a swivel mount is by mounting a servo facing downward directly onto the gripper, and yes, direct drive is never really a great idea and maybe the easiest thing to do right at that moment was to just mount it directly to the gripper but a swivel mount is a more universal solution for when the gripper needs to turn a certain angle. The only problem is that we also use a servo to actuate the gripper arm mechanism, meaning that we will have a wire that will limit the rotation of the gripper itself. We could get an itty bitty slip ring if we really wanted to, but in reality we don’t see ourselves actually needing the full three hundred sixty degrees of motion.

### Next Steps

Now that we have a swivel mount, our next step is to test, test, and maybe even test it. We don't know what degree of control we have on the swivel mount so testing it out will help us analyze what changes need to be made on our gripper.

# Finger Gripper Version 2

26 Nov 2019

Finger Gripper Version 2 By Jose

### Task: Design a swivel and add ninjaflex parts to improve the finger gripper

From what we learned at the Allen Qualifier the gripper needs some major improvements before it will work at its max performance. The first change that needs to be made is replacing the current grip material with some more flexible material, such as ninja flex which we have used before as a gripping material. The print we have on the gripper is large but when the gripper closes its flexibility allows for it to grip the stone much better.

The second improvement was to add a swivel to the entire gripper. This was done by adding some REV beams to the top of the gripper and attaching those beams to a servo. After some experimenting with the placement of the new, larger gripper we found a place that gives it over 180 degrees for motion. This will prove to be useful as not even the turntable will have to be turned to grab a stone, increasing the amount of stones we can score.

### Next Steps

We need to implement some code that will allow a second driver to control the swivel as well as add some articulations now that we have a new degree of freedom. Additionally, we will need to add a damper to the oscillatory motion of the whole subsystem while in action.

27 Nov 2019

Adding to TomBot model By Ben

### Task: Update the current robot model

Prior to updating the model, the model purely consisted of the chassis and the primitive turntable. Since then, both the turntable and chassis have been updated to reflect the current state of the robot, along with the addition of the elbow and slide. The elbow component consists of GoBILDA shafts, gears, and connectors, along with the logarithmic spiral. The elbow can be seen below.

The next addition is the linear slide. This consists of different slide components which were taken from a model constructed in PTC Creo and a linear slide gear mount. The slide can be seen below.

With this updated model, it will be much easier to develop strategies based on different articulations since we can now accurately visualize the robot. The updated model also allows coders to better visualize the robot, increasing programming efficiency.

### Next Steps

As you can see from the model above, there is no gripper. Our next steps will be to model the gripper which is to be constructed and attached to the next version of the robot.

# Allen Qualifier Post Mortem - Code

27 Nov 2019

Allen Qualifier Post Mortem - Code By Jose and Cooper

### Task: Analyze our strengths, weaknesses, opportunities, and threats for our code at the Allen Qualifier

Fresh off our first qualifier at the Allen STEAM Center, we decided to begin a SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis for code. While we will have other posts specifying what issues we needed to debug after the qualifier, and what articulations we need to implement within our code, this article mainly focuses on our code progress at the qualifier, and what can be improved in time for the next qualifier.

Strengths

• We have completely overhauled our codebase to be completely compatible with TomBot
• We know how to use state machines to code autonomous much easier

Weaknesses

• Our autonomous only scores 5 points
• We had few driver enhancements so many manual overrides were used

Opportunities

• We can have a tower height variable that makes the arm go to a certain height when stacking
• We have plenty more things to do during autonomous and can make use of the turntable to make it faster
• We can use a color sensor directly on the stone gripper to detect skystones during autonomous

Threats

• Any team with a 5+ point autonomous
• 7172, they have many of our ideas for code improvements already implemented

### Next Steps

Focus on building upon our opportunities, and begin creating plans for future articulations (which will be detailed in a later post).

# SEM Robotics Tournament

27 Nov 2019

SEM Robotics Tournament By Coach and Bhanaviya

## Qualifying Tournament needs Volunteers!

Iron Reign (team 6832), The School of Science and Engineering and the Dallas ISD STEM Department are happy to announce that we are hosting our third annual FIRST Tech Challenge qualifying tournament at our Townview campus on December 14th. Thirty Two North Texas robotics teams will compete for awards plus approximately 4 or 5 advancements to the Regional Championship to be held in February, and 4 advancements to the Wildcard Qualifer for another chance.

This is the third time our school has hosted an official qualifying tournament and we will need your help to make it a first-rate experience. This is a full day event on Saturday, December 14. There are also options to help with setup Friday afternoon December 13. Please feel free to circulate this message to everyone in the SEM community who can contribute their time and expertise. And if you can suggest a business that might want to sponsor the event, we'll be happy to talk with them.

## Volunteer Roles

One group of volunteers that support the running of robot matches include referees, score keepers, inspectors, field managers. Some of these roles require training and certification and we will generally draw from mentors already involved in FTC. Other roles supporting match play do not require training and include field management, pit management and queue management.

Another group of volunteers will support judging of teams for awards. Judges can be drawn from industry or academia and can have an engineering background or a general business backround in a technology industry. Judges assess the merits of teams' robots, their engineering process and journal, their strategic decisions, team dynamics and outreach. Judges will be led by a Judge Advisor, but will need to understand the awards criteria ahead of time.

Another group of volunteers will support the event overall. This includes team registration, crowd control, DJ, photography, A/V support, floaters, runners, concessions, load-in/load-out crew, etc.

This is just a summary of the most common roles, but there are many specialty roles. Full volunteer info can be found here.

For some roles it helps to understand the run-of-show for the day.

FIRST is the governing body of these competitions and they have a volunteer sign up system so that we can assure that all roles are filled by vetted volunteers. We are trying to get all volunteers processed through this system. It does involve creating a FIRST account if you have not previously done so.

Please sign up for as many roles as you feel comfortable fulfilling. We may need to be flexible with assignments depending on who is available and which roles can be fulfilled by our regional managing partner. Students may volunteer for certain roles and as event hosts, Iron Reign team members will be supporting the event throughout the day.

To begin, go to the volunteer signup page for our event: https://my.firstinspires.org/Volunteers/Wizard/Search/2?EventId=47076

If you have not previously registered with FIRST, you'll need to sign up / register and activate your account first. Then you can go back to the link above and indicate your preferences. We truly need your help and look forward to working with you to create a great tournament for our students. We hope this event will showcase SEM as the premiere home for future scientists and engineers.

All our Thanks,

Karim Virani and Cathy Lux

### Tournament day is very involved for the teams and volunteers. Here is a typical schedule of the day:

• 7:00 Doors open for volunteers
• 7:30-8:30 Teams arrive, register and load their robots and gear into the pit areas
• 9:00 - 10:30 Teams present their robots to Judges for the awards competition. They also get their robots inspected and approved for the robot game
• 10:30 Opening ceremonies and then qualifying matches of the robot game begin. Judges are observing teams in their pits and on the competition field
• Noon - Lunch will be provided for the teams and volunteers. Judges share information with each other about the teams they interviewed.
• Afternoon - qualifying matches continue until each team has competed 5 times. There are 4 robots per match and we'll have two alternating competition fields to speed things up.
• Mid-to-late afternoon is Alliance Selection, top teams from qualifying rounds will build alliances to compete in the elimination / playoff rounds. Judges continue deliberating.
• Playoff rounds usually take a bit over an hour
• Closing Ceremonies and Awards
• Pack up fields and equipment

We plan to end the tournament by 5:30pm, but events often run long. All volunteers are encouraged to stay until the end of the tournament - it's at the awards ceremony where it becomes clear how much your service matters. But it's not required if your role is completed earlier in the day.

# Finger Gripper Version 3 CAD

28 Nov 2019

Finger Gripper Version 3 CAD By Jose

### Task: Design a more comapct and efficient gripper design

This version of the finger gripper is going to be mostly custom made to make it as simple and as compact as possible. This is just the CAD model of the actual design and we plan to update a little more before we can actually make the physical change on the actual gripper. The design remains the same but the gripper now has a new addition, a capstone deployer. The idea is to have the capstone preloaded on the gripper and have a mini servo drop it on the last stone we are placing. The design of this capstone is in another blog post, but the idea is to make it as small as possible to not make the gripper much larger.

### Next Steps

We need to make this design perfect before printing, once that is done we can do so and begin its implementation on the robot.

# Creating a Robot Handle

29 Nov 2019

Creating a Robot Handle By Paul

### Task: Create a handle for the robot to make it more inspection-worthy

The robot handle is a revolutionary piece of precision engineering, designed to allow the robot to lifted by a carbon-based linear motor, known as a human arm. The handle is made of a composite material, consisting of a matrix of polyurethane fibers surrounded by a carbon-based synthetic thermoplastic polymer sheath. This cording material shall henceforth be known as “Bungee cording”. This “Bungee cord” is wrapped around two aluminium support struts to ensure structural stability and ensure that the forces induced by the carbon-based organic linear motor don’t exceed the ultimate structural limits of the attachment points, which would result in the uncontrolled acceleration and subsequent sudden deceleration when the robot impacts the surface below. This would be bad because the robot is expensive and the ground is usually hard.

This bungee cording helps protect the puny little meat sticks we call fingers, because for some reason that getting your fingers sliced open by the robot is bad or something. The meatbags that our team consists of need to be protected as per FTC regulations.

### Next steps:

Enhance the carbon-based organic linear motors so our engineers can lift the robot without looking weak. Also maybe a little more padding to help protect people’s fingies.

# Bill of Materials

30 Nov 2019

Bill of Materials By Bhanaviya, Trey, and Jose

### Task: Create a list of parts needed for the new robot

To determine all the materials we need for the new robot, we started a Bill of Materials. To do this, we first analyzed TomBot sub-system by sub-system. We determined the parts used for each sub-system and placed it into a spreadsheet. Upon doing this, we needed to get each part's exact measurements so that we could save time when trying to cut the new parts. Additionally, we needed the quantity of each part as well as which manufacturer it was from. Something new about the new robot is that we hope to have a completely CNC-ed bot with as many custom parts as we can incorporate. Using a good number of custom parts will allow us to be more creative with the robot design itself since everything we add to it will be custom-printed. This will also allow us to improve our engineering process as we iterate through multiple different versions of a part. This was critical because at the end of the day, the task was to build a better version of TomBot but using, more or less, the same parts.

### Next Steps

We will update the bill as we iterate through more parts. As of now, TomBot has several build issues that will be discussed in our post-mortem posts. Part of rectifying these issues includes ordering/printing more parts and editing the bill accordingly.

# Capstone Version 3

30 Nov 2019

Capstone Version 3 By Jose

### Task: Design a minimalistic capstone that can be deployed by the stone gripper

This version of our capstone is to be 3D modeled and printed as well as be as compact as possible to be deployed by the gripper. The basic idea is that the capstone is flat while meeting the minimum size for length and width. The capstone will be an 'I' shape to fit around the nubs of a stone. From here a small beam will be attached on the hole which is extended out of the 'I' as shown above. This will be 3 inches long, making this capstone technically legal. This capstone is small enough to allow another capstone to be placed on top if needed.

### Next Steps

We need to fully 3D model this capstone and change the bottom of the gripper so it can be deployed easily.

# Short-term Post-Mortem Talks

30 Nov 2019

Short-term Post-Mortem Talks By Bhanaviya, Cooper, Paul, Aaron, Ben, Jose, and Trey

### Task: Begin analyzing our performance at the Allen qualifier

It’s officially been a week since our first qualifier at Allen. Although we succeeded in qualifying there’s still a lot of work to be done before it we’re ready for the regional championship. Before we could begin any preparation for regionals, we needed to start off by analyzing our performance at Allen. To do this we created a SWOT (strengths, weakness, opportunities, threats) analysis.Today was simply a short-term version of this analysis and there will be a separate post detailing our comprehensive post-mortem analysis as well as other post-mortem posts for our build and code subdivisions.

We started off by analyzing our performance at judging. In the past, timing is an issue we’ve struggled to nail down during judged presentations. As such, this year we worked to make our presentation as concise but thorough as possible. During the actual presentation, while we hit the 5 minute mark there were other areas in which we could have been improved - particularly, our robot demonstration and our ability to explain our build decisions with calculations. To solve this, we plan to design a research poster for regionals which explains our mathematical reasoning for every aspect of the robot. The poster will allow us to allude to our calculations during both presentations and pit visits. As for robot demo, it is more a matter of being prepared with working controls which is an issue we will cover in our long-term post-mortem.

On the short-term, we also plan to better organize our bill of materials which will streamline our process of building our new robot. For reference, TomBot is our current robot. Before regionals, we plan to build a similar circular-chassis based robot but with more custom built parts which we plan to design using our new CNC mill.

On the issue of drive practice our solution is simple, effective and fully on-track with the Iron Reign way: double it and try not to break the robot. In all seriousness, the only way to resolve lack of drive practice is doing more of it. Part of this includes documenting our driver practices with statistics for us to better analyse our progress (or lack of thereof).

The final issue we discussed during today’s post-mortem talks was how we plan to organize our schools qualifier on December 14 . Although this isn’t related to our performance at the Allen Qualifier, our experience at the tournament allowed us to better understand what needs to be done to get all 4 of our teams ready to host a 31-team qualifier. Part of this includes all members registering for roles as well as ensuring that we have monitors, playing fields, and enough adult volunteers to pull off the whole event.

### Next Steps:

Over the course of next week’s meeting, we will finish our post-mortem talks and will continue our preparations to host the Townview Qualifier. In addition, we will also detail our SWOT analysis on this blog when our post-mortem talks are finished.

# Allen Qualifier Post Mortem

07 Dec 2019

Allen Qualifier Post Mortem By Karina, Bhanaviya, Jose, Ben, and Paul

### Task: Plan for upcoming tournaments

So our Allen qualifier was a success! Iron Reign won the Inspire Award, which we are so honored to have been given. We did a detailed SWOT analysis to identify our strengths, weaknesses, opportunities, and threats.

#### Strengths

• Preparation
• Earlier preparation of the engineering journal
• Productivity greatly increased under pressure
• Everything was up on blog
• Content was organized well
• Functional robot
• Judging box was prepared and had everything we needed
• Judging
• We were effectively able to communicate the reason behind our robot's unique shape
• Good transitions between ideas
• We were able to talk fluidly about our robot despite not having speeches prepared
• Able to redirect judges to specific highlights
• Storytelling abilities kept judges engaged
• Robot Performance
• We passed inspection the first time around
• Physical build was solid
• Focused on building/improving even throughout the competition
• Great teamwork - everyone was coordinated and on task
• Batteries were charged
• Scouting and Pit Engagement
• Good at queueing one another during pit visits
• Demo worked better than at presentation
• Scouters got to all the teams

#### Weaknesses

• Preparation
• Workspace is realy disorganized which made it hard to find tools and equipment that we needed
• No drive practice until the morning of the tournament since gripper was only mounted then
• Not enough people for load out
• Control Award submission
• Missed items on the checklist for materials
• Lack of rest
• Judging
• Redirected to topics that don't have a lot of substance
• Not enough calculation based posts to talk about
• Lack of driver statistics documentation
• Hand off between different speakers could be smoother
• Did not clearly discuss our focus on sustainability of the MXP
• Robot demo did not work since chains fell off
• Robot Performance
• All drivers need to learn game strategy
• Poor wire management
• Compact design was also the reason behind the turn table knocking chains off of wheels' sprockets
• Set screws came loose often
• We had no autonomous at the beginning of the day
• Scouting and Pit Engagement
• Need to be more systematic about checking team's claims
• Did not get video of all of our matches personally
• Not enough people at the pits to represent the team
• Unable to seed questions
• Lacking in enthusiasm
• Pits were a mess with backpacks thrown all over

#### Opportunities

• Preparation
• Taking up more afterschool and Sunday practices
• Allocating more time to preparation in the weeks before competition instead of days
• Preparing a pit design to optimize organization and places to put up banners
• Create business cards for handouts
• Post-event follow through: plugging in phones, charging batteries, etc.
• Judging
• Be more aware of what a judge is looking for/what award they are judging
• Make our binder stand out - aesthetically and by creating helpful guides such as a robot manual
• Robot Performance
• Allowing time for driver practice
• Making sure that everyone gets enough sleep the night before competition
• Test grippers
• Better collaboration with alliance partners
• Control swivel mount on gripper
• Fully automatic gripper with distance sensors
• Turn-table needs to stay in position while robot turns
• Completely CNCed robot (base - polycarb with aluminum sides)
• Dampen swing on gripper
• Make model for gripper before build
• Articulations - more accurate presets specifically for elbow
• Create a bill of materials with links
• Scouting and Pit Engagement
• Design pit layout ahead of time
• Dress up our pit with tent and banners
• Have a laptop ready with important info
• Detailed accounts for each match we do/play by play
• Have someone assigned to watch matches so that we can personally gauge other team's strength, weaknesses, opportunities for collaboration, etc.
• Take the chance to talk to other teams
• Make use of a scouting app

#### Threats

• Preparation
• Not getting focused until it is too late
• Busy schedules
• Not being able to prioritize
• Judging
• Rushing through important ideas because of the time limit
• Judging panel is always an uncertain variable
• Robot Performance
• High performing teams
• Time management
• Acquisition of all parts
• Enough time for modeling all the robot parts
• Scouting and Pit Engagement
• Sitting around looking at phones looks like disengagement even if we are researching stuff
• Lack of robot data and statistics to present potential allies with might drive them away

#### Next Steps

We're at the point now where we are prepping for our regionals tournament. Thankfully we will have another opportunity to test out TomBot at the ____ qualifier. Between the work we do now and up until the regionals tournament, we hope to achieve a full autonomous with greater stacking capabilities.

# Capstone Iterations

07 Dec 2019

Capstone Iterations By Bhanaviya

### Task: Go over all 3 of our capstone iterations

So far, we have experimented with 3 capstone models. While we do not intend to use all 3 of these models, they allowed us to effectively implement the engineering process on our robot. Although the capstone isn't physically a part of a robot, its various iterations influence the model of the gripper being used since the ideal gripper must be able to pick up both the skystones and the capstones over the duration of a match. As such, this article analyzes these designs to help us determine which gripper is best for use at our next qualifier on January 11.

### 1) Aaron's Super Cool Capstone That Works 100% Of The Time

The capstone that we made and used at the competition wasn’t the prettiest thing, but it had heart, and was destined for greatness. It was constructed from prototyping wire and duct tape. The basic design was a ring with a spherical top over it in order to not fall off when dropped onto the tower. It also had four large screws on each side in order to weigh down the capstone so as to not slip or slide off the tower when dropped. While this capstone was firm in structure, it requires a lot of precision to be placed on top of the stone itself. Since this year's game is very speed-based, a precision-based capstone is not the most effective.

### 2) Jose's Super Cool Capstone That Works 100% Of The Time

The next capstone was custom-designed and printed at our very own Robo Dojo. Simply put, it is a much flatter, rather 2D version of a skystone. It had two large rectangles in the center to drop onto both the stubs of a stone on a tower. It also has a small rectangular tab at its edge which will allow the gripper to pick it up. But given its shape, an issue would be the ability of our gripper to pick it up and drop it onto the tower without tipping over the entire stack. Once again, while it was destined for greatness, it was not built for the unrelenting force that is time and it would take too much control and seconds to be capped onto a tower.

### 3) The I-shaped Capstone That Works 100% Of The Time

Our latest capstone design is also custom-designed and 3D-printed out of nylon. Structure-wise, it is a flat 'I'. But in terms of capacity, it is the easiest of our capstone models to be picked by the gripper and drop onto the skystone. This capstone aims not to be dropped on the stubs of the stone but rather in in the middle of the capstone where it requires less precision to be dropped and is less likely to fall. It comes with a small tab similar to the one on our second capstone which allows the gripper to pick it up with ease.

### Next Steps

Now that we have analyzed all of our capstone designs so far, it will be easier for us to streamline which design will be the best to implement on the robot. Right now, we are leaning towards the I-shaped capstone since it's less precision-based, smaller, and easier to be picked up by our current finger-gripper.

# Future TomBot Articulations

07 Dec 2019

Future TomBot Articulations By Cooper

### Task: Plan out potential robot articulations to improve game strategy

Getting back from the tournament, we were able to immediately start to think about what was the big problems and possible improvements to the articulations of the robot. Overall, we ended up coming up with several ideas, both for fixing things and for efficiency.

### 1- Turntable Articulations

In the competition, we realized the extreme convenience that having some articulations for the turret. Not to say that we hadn't tried to make them before the competition, we were having some issues writing them. plus, even if we didn't have those convene, it would have been improbable that we would have gotten them tuned for the competition. Anyways, even though we agreed on needing to have these presets, we could not agree on what they should be. One argument was that we should have them field-centric, meaning that it would stay in one position from the POV of the audience. This was cited to have a good number of use cases, such as repetitive positions, like the left/right and forward of the field. However, another idea arose to have them be robot-centric. This would allow for faster relative turns.

So, what we've decided to do is write the code for both. The field-centric will be turns and subsequent static positions will implement the IMU on the control hub mounted to the turret. The robot-centric version will be based on the tick values of the encoders on the turret's motor. Then, we will have the drivers choose which one they prefer. This we believe is effective, as it will allow for a more consistent use of the turntable for the driver.

### 2- Move to Tower Height Articulations

this is one of the more useful Ideas, which would be to extend the arm to the current height of the tower. How would we do it? Well, we have come up with a 2 step plan to do this, in different levels of difficulty. The first one is based on trig. We used the second controller to increment and decrement the level of the current tower. That value is then used in the extendToTowerHeight() method, which was written as the following:

 public void extendToTowerHeight(){ hypotenuse = (int)(Math.sqrt(.25 * Math.pow((currentTowerHeight* blockHeightMeter),2)));//in meters setElbowTargetPos((int)(ticksPerDegree*Math.acos(.5/ hypotenuse)),1); setExtendABobTargetPos((int)(hypotenuse *(107.0/2960.0))); } 

As you can see, we used the current tower height times the height of a block to get the opposite side of the triangle relative to our theta, in this case the arm angle. The .25 is an understood floor distance between the robot and the tower. This means that the arm will always extend to the same floor distance every time. We think this to be the most effective, as it means not only that the driver will have a constant to base the timing of the extension, but we minimize the amount we have to extend our arm. If we assumed the length of the hypotenuse, there would be overextension for lower levels, which would have to be accounted for.

The next phase of the design will use a camera to continue to extend the arm until it doesn't see any blocks. not only will this allow for a faster ascension and more general use cases, It will eliminate the need for a second controller (or at least for this part.

### 3-Auto-grab Articulation

Finally, the last one that we came up with is the idea to auto-grab blocks. To do this we would use vison to detect the angle and distance that block is away from the robots back arm and extend to it. Then rotate the gripper, snatch it and reel it back.

### Next Steps

Use a culmination of drive testing and experimentation to refine the robots movements and ultimately automate the robot’s actions.

# Townview Qualifier 2019 - Set Up

13 Dec 2019

Townview Qualifier 2019 - Set Up By Ben, Jose, Karina, Justin, Bhanaviya, Cooper, Paul, and Trey

### Task: Prepare Townview for the upcoming qualifier

Tomorrow, December 14th, Iron Reign will be hosting the 2019 Townview Qualifier. 31 teams will be competing and we expect several hundred people to attend the event. We have recruited volunteers from Imperial, Iron Core, and Iron Golem, along with PTSA volunteers from our home schools, SEM and TAG. For our competition, we required over 31 individual tables for each team, 4 queuing tables, and about 6 other tables for snacks, equipment, and inspection. Three fields were also set up, two were brought in as competition fields, set up in the main cafeteria, while the third was provided by Iron Reign as a practice field in the far corner of the cafeteria. Two large monitors were provided by the schools to display match information during matches, along with live results, while the other was used to display inspection status and ranking. The competition fields were setup to the east of the cafeteria with several rows of chairs for spectators. Behind the fields were 4 queuing tables, two per field. We initially placed 4 chairs at every team table, however, more were available along the walls for teams to use. On every team table, we placed 2 signs with the team numbers of the team assigned to that table. Teams were organized by team number to make queuing easier.

A tournament also required judging rooms. Because the tournament was on the first floor of the building, we transformed 5 classrooms into judging rooms. This usually meant moving many of the tables and chairs off to the side to allow teams and judges to move easily about the room. We posted maps around the building and marked every judging room with the judging room number.

### Next Steps

Although we finished most of the preparation, there are still a few things left to do. We will need to construct a map of the pits, transport volunteer supplies (like snacks and water), and provide training for volunteers.

# Townview Qualifier 2019 - The Day Of

14 Dec 2019

Townview Qualifier 2019 - The Day Of By Bhanaviya, Jose, Paul, Aaron, Justin, Trey, Ben, Karina, Cooper, Jayesh, Tycho, and Max

### Task: Run the Townview Tournament

On Saturday, December 15, Iron Reign hosted 31 teams and 300 students at the Townview Magnet Center, our home school's campus. With 31 teams, this was one of the biggest qualifiers in the North Texas region. A video play-by-play of the matches can be found in a separate entry here. This entry serves more as a description as to how we got to the point of hosting the qualifier and what to consider when hosting one.

To start off, a full-fledged qualifier requires a large number of volunteers - both student and adult. While there are certain roles that are limited to adults only, many roles need a good number of younger volunteers - especially queuing and judging assistance. If the host team is not participating in the qualifier, then a good way to meet this cap is to recruit from a school's robotics program. In our case, student members from the Iron Reign Robotics program filled in positions such as game announcer, emcee, disc jockey, concessions, and around 10 queuers and runners. Prior to the start of match-play all our members helped with judging assistance. This includes ensuring that all teams are queued up on time outside their judging panels and ensuring that all teams have gone through field and robot inspection. This helps ensure that all teams are on schedule for the start of match-play. Below, you can see what specific roles which Iron Reign members helped fill during the tournament:

### Townview Qualifier Member Work Log

 Team Members Task Start Time Duration Karina Referee 7:00 12 hrs Justin Queuer and Runner 7:00 12 hrs Bhanaviya Emcee and Queuer 7:00 12 hrs Ben Queuer and Queuer 7:00 12 hrs Jose Game Announcer 7:00 12 hrs Cooper Queuer and Judge Advisor Assistant 7:00 12 hrs Aaron Queuer and Runner 7:00 12 hrs Paul Disc Jockey 7:00 12 hrs Trey Queuer and Runner 7:00 12 hrs

A good qualifier also needs adult volunteers. We had 2 judges in 4 judging rooms and one room with 3 judges. In addition, we also had 6 referees and one scorer. All of these are adult roles which meant we had to seek volunteers from a variety of sources including prior FTC Tournaments, alumni from our team, and even our own families. All adult volunteers must go through background checks as well as complete other training certifications on the FIRST website so this proccess must start at least 3 weeks in advance to recruit enough volunteers. To do this, we posted a request for volunteers on this blog for any visitors to our website to sign up.

Fresh off of the Allen Qualifier, we knew the pressure that teams felt at a qualifier - whether its caused by a lack of driver practice, tools or just undulated anxiety, we wanted to alleviate this stress. So, we ensured that a practice field set up away from the pit area for teams to practice right before their matches. We also kept a spreadsheet with inspection results on 2 monitors in the pits so that teams could be updated, and made pit maps so teams could find one another. These maps are also helpful to runners who need to find teams to queue them for their matches or for their judging panels. With so many members of our team floating around the pits, we were also able to provide any build or code assistance to teams who might need it. Finally, one trait all FTC team members share on the day of qualifier is the perpetual need for sustenance so we collaborated with one of our school's, TAG, PTSA to set up a concessions stand while the DISD STEM Department ensured that all volunteers received lunch.

### Next Steps

By the end of the qualifier, we were able to advance 4 teams to the North Texas Regional Championship, and another 4 to the Wildcard Qualifier on February 1st. The qualifier could not have gone as smoothly as it did without the help of all our volunteers for committing so much of their times on a weekend to promote FIRST and STEM. We'd also like the DISD STEM Department for proving all our volunteers with breakfast and lunch, to The School of Business and Management and our sponsor, Mr John Gray, for supporting the event. Finally, we'd like to thank our coach Mr Virani for managing all of the logistics for the event, including its set up and the qualifier itself.

# Third Annual Townview Tournament a Success!

15 Dec 2019

Third Annual Townview Tournament a Success! By Coach and Bhanaviya

## Thank you to all our volunteers!

Thank you to all the volunteers that gave up their Saturday to contribute to the FTC community in North Texas. Because of you this tournament was a rousing success. We served 31 area teams and 300 students. We advanced four teams directly to the Regional Championship in February and gave another four a second shot at the Wild Card tournament. More importantly, all teams received a fair chance at competing with excellent Judging and Refereeing - and we are certain that all of them learned how to improve. We really could not have done this without our volunteers carrying the load.

We extend our deepest appreciation to all volunteers, to the business school and our sponsor for supporting the event, to the TAG PTSA for providing concessions, to the leadership of SEM for hosting and to the STEM Department for feeding our volunteers and Dallas ISD students.

-Karim Virani, Dr. Catherine Lux, and the students of Iron Reign, Imperial Robotics, Iron Core and Iron Golem

For those interested, the full standings are up on The Orange Alliance and awards should follow soon.

We also were doing a test of streaming for future tournaments in our region. Because we had little time to set it up, there were issues with quality on one camera and a complete lack of audio for about half of the tournament. But most of the matches are visible (with the exception of the final match) and most of the awards ceremony was audible. We know what to improve and can hope for a better stream at some following tournaments. Here is what we got:

# Turret IMU Code

22 Dec 2019

Turret IMU Code By Jose and Abhi

### Task: Code some driver enhancements for the turret

With the return of the king(Abhi - an alumni of our team) we were able to make some code changes, mainly dealing with the turret and its IMU since that is our current weak point. At first we experimented with field-centric controls but then realized that for ease of driving the robot, turret-centric control are necessary. After a few lines of code using the turret's IMU, we were able to make the turret maintain its heading, as the chassis turn, so does the turret to maintain its position. This is useful because it will allow the driver to turn the chassis without having to turn the turret as well.

### Next Steps

We must continue tuning the PID of the turret to allow for more stable and accurate articulations.

# Finger Gripper Version 4 CAD

25 Dec 2019

Finger Gripper Version 4 CAD By Jose

### Task: CAD a slightly different capstone version to improve upon v3's issues

On this minor update to our flat gripper design a dropper for the latest capstone was added. Our capstone design (which can be seen here: E-65 ) is minimalistic to allow it to be placed on the gripper and only deployed until the last stone in the match is placed to cap it. The basic idea for this capstone dropper is to have a bar which has the number 6832 on it to match the 6832 indent on the capstone. This dropper will keep the capstone in place until the gripper is opened to beyond 45 degrees. To allow the gripper to actually close, a triangle was cut off the dropper as seen in the image above. Here is the final design:

### Next Steps

Once the design is finalized(there may be a 5th version if a change is needed) this will be 3D printed and will replace the current gripper on the robot.

# Materials Test Planning

26 Dec 2019

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 silicon oven-mitts and ice-cube trays, since we find these grip skystones pretty well. 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 the underside of our gripper, to improve its friction when in contact with a stone. Our current gripper uses parts of ninjaflex gears but these aren't the most effective in picking up stones quickly. This is a bit of a concern since this year's game is so speed-based. As such, the time has come for us to replace the material on our gripper. 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 rotating 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 skystone on top of the of the silicon oven-mitts/ice-cube trays 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.

### Next Steps

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

# Code Developments 12/28

28 Dec 2019

Code Developments 12/28 By Cooper

### Task: Gripper swivel, extendToTowerHeight, and retractFromTowerHeight. Oh My!

Today was a long day, clocking in 10 hrs continuously. In those ten hours, I was able to make tremendous progress. Overall, we have 4 main areas of work done.

The first one gets it’s own blog post, which is the extendToTowerHeight, which encompasses fixing the 2nd controller, calculating the TPM of the arm, and calculating the TPD for the elbow.

The second focus of the day was mounting and programming the swivel of the gripper. Aaron designed a swivel mount for the gripper the night after the qualifier, which was mounted on the robot. It was taken off by Aaron to finish the design and then today I put it back on, and then wired it. Once we tested to make sure the servo actually worked, we added a method in the Crane class that swivels the gripper continuously. But, since the servo is still a static one, I was also able to implement a toggle that toggles between 90, 0, and -90. With a couple of tests we were able to determine the correct speed at which to rotate and the code ended up looking like this:

 public void swivelGripper(boolean right){ if(right == true) gripperSwivel.setPosition(gripperSwivel.getPosition()-.02); else gripperSwivel.setPosition(gripperSwivel.getPosition()+.02); } 

The third development was the retractFromTowerHeight() method that was written. This is complementary to extendToTowerHeight, but is significantly less complex. The goal of this method was to make retracting from the tower easier, by automatically raising and retracting the arm, such that we don’t hit the tower going down. This was made by using a previously coded articulation, retract, with a call to setElbowTargetPos before it, such that it raises the arm just enough for the gripper to miss the tower. After a couple of test runs, we got it to work perfectly. The final order of business was the jump from ticks being used on the turntable to IMU mode. It was really out of my grasp, so I asked for help from Mr.V. After a couple of hours trying to get the IMU setup for the turret, we finally got it to work, giving us our first step to the conversion. The second came with the changing of the way the turntable moves, as we made a new low level setTurntableTargetPos() method, which is what everything else will call. Finally, we converted all of the old setTurnTablePos() methods to use degrees.

### Next Steps

As of now both extendToTowerHeight() and the gripper swivel are good. On the retractFromTowerHeight(), it may be important to think of the edge cases of when we are really up high. Also, the turntable is unusable until we tune PID, so that will be our first priority.

# Extend to Tower Height and Retract from Tower

28 Dec 2019

Extend to Tower Height and Retract from Tower By Cooper

### Task: Develop the controller so that it can extend to tower height

Since we have decided to move onto using 2 controllers, we can have more room for optimizations and shortcuts/ articulations. One such articulation is the extendToTowerHeight articulation . It takes a value for the current tower height and when a button is pushed, it extends to just over that height, so a block can be placed. This happened in 2 different segments of development.

The first leg of development was the controller portion. Since this was the first time we had used a 2nd controller, we ran into an unexpected issue. We use a method called toggleAllowed() that Tycho wrote many years ago for our non-continuous inputs. It worked just fine until we passed it the second controllers inputs, as then it would not register any input. The problem was in the method, as it worked on an array of the buttons on the controller to save states, and there was conflict with the first controller. So, we created a new array of indexes for the second controller, and made it so in the method call you pass it the gpID (gamepad ID), which tells it which of those index arrays to use. Once that was solved, we were able to successfully put incrementTowerHeight() on the y button and decrementTowerHeight() on the x button. The current tower height is then spit out in telemetry for the second driver to see.

Then came the hard part of using that information. After a long discussion, we decided to with a extendToTowerHeight() that has a constant distance, as having a sensor for distance to the build platform would have too many variables in what direction i t should be in, and having it be constant means the math works out nicely. So this is how it would look:

Now, we can go over how we would find all of these values. To start, we can look at the constant distance measure, and to be perfectly honest it is a completely arbitrary value. We just placed the robot a distance that looked correct away from the center of the field. This isn’t that bad, as A) we can change it, and B) it doesn’t need to be calculated. The driver just needs to practice with this value and that makes it correct. In the end we decided to go with ~.77 meters.

Then before we moved on we decided to calculate the TPM (Ticks Per Meter) of the extension of the arm, and the TPD (Ticks Per Degree) of the elbow, as it is necessary for the next calculations. For the TPM, we busted out a ruler and measure the extension of different positions in both inches (which were converted into Meters) and the tick value, then added them all up respectively and made a tick per meter ratio. In the end, we ended up with a TPM of 806/.2921. We did similar with the TPD, just with a level, and got 19.4705882353. With a quick setExtendABobLengthMeters() and a setElbowTargetAngle() method, it was time to set up the math. As can be seen in the diagram, we can think of the entire system as a right triangle. We know the opposite side (to theta) length, as we can multiply the tower height by the height, and we know the adjacent side’s length, as it is constant. Therefore, we can use the Pythagorean theorem to calculate the distance, in meters, of the hypotenuse.

 hypotenuse = Math.sqrt(.76790169 + Math.pow(((currentTowerHeight+1)* blockHeightMeter),2));//in meters 

 From that, we can calculate the theta using a arccosine function of the adjacent / hypotenuse. In code, it ended up looking like this: .setElbowTargetAngle(Math.toDegrees(Math.acos(0.8763/ hypotenuse))); 

Then we set the extension to be the hypotenuse:

 setExtendABobLengthMeters(hypotenuse-.3683); 

While it has yet to be seen its effectiveness, it should at the very least function well, as shown in our tests. This will help the drivers get into the general area of the tower, so they can worry more about the fine adjustments. For a more visual representation, here is the position in CAD:

### Next Steps:

We need to work on 2 main things. Tuning is one, as while it is close, it’s not perfect. The second thing to work on is using a custom vision program to automatically detect the height of the tower. This would take all the stress off the drivers.

# Testing Friction Coefficient

28 Dec 2019

Testing Friction Coefficient By Bhanaviya

### Task: Measure the coefficient of friction of our potential gripper materials

We want to measure various constants of materials on our robot. These materials serve to improve the grip on our gripper. But before we can decide which material will be most effective on our gripper, we need to find the friction coefficient of these materials through a slip test. The slip test is detailed in a separate post in E-67. This article serves mainly to show the specific friction coefficient produced by each material in the slip test.

To measure the coefficient of friction, we first had to simplify an equation to determine what values to measure.

Based on these calculations, we realized that the best way to calculate friction coefficient would be by deriving the angle of incline at which the skystone begins to slip from the material, which is placed on a flat wooden board. If we take the length of the side of the board being lifted to be the hypotenuse, and the height at which the board is being lifted to be height, then theta, the angle of incline, is arcsin. As the board is lifted, the stone begins to experience slippage and the angle at which it slides off the material being tested will be marked as its friction coefficient. The higher this value, the more grip the material has.

The materials we will be testing are a green silicon oven-mitt with hexagonal ridges, a red silicon oven mitt with small rectangular ridges, and an ice-cube tray with cubical ridges. The wooden board on which this the materials and skystone are being placed on has a length and width of 23.5 inches. This will be the hypotenuse for the purposes of this test.

#### Green Silicon Oven-Mitt

When the wooden board was lifted with this material on top of it, it took a height of 10.3 inches before the stone began to slip. Using arcsin, the angle of incline for this material was 26 degrees. By using the equation above, we can find that the coefficient of friction is tan(26) which 0.48.

#### Red Silicon Oven-Mitt

When this material was tested, the board had to be lifted 13.7 inches before the stone began to slip. The angle of incline for this material was 35 degrees so the coefficient of friction is tan(35) which is 0.7. Since this value is higher than the green oven-mitt, the red oven-mitt has the better grip.

#### Ice-Cube Tray

The board reached a height of 12.2 inches when the stone began to slip from the ice-cube tray. The friction coefficient for this material was 32 degrees, and its coefficient of friction was hence 0.66, putting it above the green oven-mitt, and slightly below the red oven-mitt in grip.

### Next Steps

The material with the largest friction coefficient will be attached to the gripper on the robot. Since the red silicon oven-mitt had the largest angle of incline, this will be the material we will use in the next iteration of our gripper.

# Sliding Foundation Grabber

28 Dec 2019

Sliding Foundation Grabber By Trey, Jose, and Aaron

### Task: Design and create a more efficient and compact foundation grabber

Moving the foundation throughout a match is an important part of the overall gameplay of a team. The builders on Iron Reign went through many different designs before reaching the one we have now. Early in the season, we simply settled for a simple hook attached to a servo on the front of the robot; however, this proved to be quite unstable. The foundation wobbled back and forth when the robot was in control of it and with this in mind, we went back to the drawing board. The second design we had in mind was a lot like the first but with two large, unwieldy, polycarbonate hooks that spanned at least four inches. These were often great at keeping a stable grasp on the foundation but they were made out of polycarbonate and flexed quite a bit and also were just too big in general.

The design we have now consists of a sliding metal door that is controlled by a servo with a spool of string on it. The metal door models something of a guillotine that lifts to let the edge of the foundation in and then drops to secure it. This door, with its wide bottom, provides a great amount of stability and the base that its mounted to makes it so that the force inflicted by the foundation is passed into the base and then into the drivetrain. The fact that the grabber is not only attached to the servo but also fixed to the robot makes it so that the moving parts are less likely to snap or slip. And all of the components fit into a small space that should not be too much of an obstruction to the arm. Overall, this foundation grabber checks the boxes that the previous ones did not, It's compact, controls the foundation well, and definitely won't bend or snap.

### Next Steps

No design for any part on any robot is perfect and this grabber is no different. The spool and string that is used to control the door is most likely temporary because there is probably a better way to open and close the door of the grabber. However, one thing that can and will be improved upon with the spool and string is that if provided with an upward force, the door of the grabber will open. This can be fixed by making the string on the spool continuous which will prevent this from happening by providing an opposite force, holding the door in place.

# Finger Gripper Version 2.1

29 Dec 2019

Finger Gripper Version 2.1 By Bhanaviya and Aaron

### Task: Replace the ninjalfex gears on the finger-gripper with a material with more grip.

The finger gripper is the pinnacle of technological evolution, with class, durability and most importantly, metal. But it does lack one defining feature - grip. Currently, the underside of the metal plate on the gripper has parts from our ninjaflex gears used in Relic Recovery, and while it has all the refinement of an almost 3-year old part, it could be improved. Introducing the Finger Gripper 2.1, brought to you by Iron Reign. (although this change is being made after version 3 and 4 of our gripper, it is listed as 2.1 since 3 and 4 have only been designed in CAD and we are yet to translate this into a physical change.)

On the matter of choosing which material to replace the ninjaflex gears with, we had 3 options to chose from. The first was a red silicon oven-mitt with rectangular ridges, a green silicon oven-mitt with hexagonal ridges, and an ice-cube tray with cubical ridges. To determine which material would work best, we put them a slip test, which can be found in E-69 . Of the 3 materials we tested, the red silicon oven-mitt had the largest friction coefficient. This makes sense, considering it had the sharpest ridges of the three, hence allowing it to grip the stone better. Hence, we replaced the material under our current finger gripper with a small piece from the red silicon oven-mitt. Although changing the material underneath the gripper seems like a minor design change, the improved grip will allow us to rely less on precision and more on speed during the actual game.

### Next Steps

Next we will test the actual gripper to see if the material lives up to its results from the slip test. Once version 3 and version 4 of the finger gripper have been fully modeled we will print these designs and modify the gripper accordingly.

# Last Coding Session of the Decade

30 Dec 2019

Last Coding Session of the Decade By Cooper

### Task: Gripper swivel, extendToTowerHeight, and retractFromTowerHeight. Oh My!

Today is the second to last day of 2019, and therefore the same of the decade. Thus, I want to spend it at robotics. Today I worked solely on vision testing and attempt of implementation. However they ended up being fruitless, but let me not get ahead of myself. To start the day, I tried looking at the example vuforia code that was provided. After which I hooked up a camera to the control hub to try any see it in action. We learned that in the telemetry, there are 2 lines of values spit out, which are the local position in mm and the XYZ values of the block. For the first bit of the day when we were testing, we thought to use the XYZ values, but they seemed to be unreliable, so we switched over to the local position. Once we had gotten that down and gotten a map of values of where the skystone would be, I tried to tailor the concept class to be directly used in our pipeline from last year, and then refactor all of it. But this didn’t work, as it would always throw an error and for the life of me I could not get it to work.

Today wasn’t a complete waste, however, as I have learned a valuable lesson -- don’t be lazy. I was lazy when I just tried to use the example code provided, and it’s what ultimately led to the failure.

### Next Steps

Take another stab at this, but actually learn the associated methods in the example code, and make my own class, so it will actually function.

# Assembling the Turntable Bevel Gears for a REV Motor

31 Dec 2019

Assembling the Turntable Bevel Gears for a REV Motor By Trey and Justin

### Task: Assemble the bevel gears to the turntable to fit a rev motor

Today we assembled a second version of our bevel gear assembly for the turntable. Our previous design used an Andymark motor, which was very fast but couldn't provide enough torque for precise movement. The custom geared REV motors allow us to power the turntable with our desired torque. This is further explained in our Calculating Torque at the Turntable post dated 2020-01-01 . The Gobilda motor mount was designed to fit motors wit 6 evenly spaced mounting holes, while the new REV motors have 8. We decided that the most efficient solution was to mount a rev rail motor mount to the Gobilda channel. First we had to make sure the holes lined up and the motor shaft was centered in the channel; the holes lined up perfectly and centered the shaft in the channel. The sides of the motor mount were too wide and had to be cut to allow the mount to slide in the channel enough to line up the mounting holes. Due to the apparent standardization of mounting holes, we could easily mount our new motor to the gears. The rest of the assembly was just following the Gobilda instructions for assembling the bevel gears and bearings. We were ready mount the new motor assembly to the turntable.

### Next Steps

Next we will remove the old motor assembly and replace it with the new one. We also need to test the strength of the mounting plate under the load of the turntable. We should also use the time with the turntable off to inspect the nylon gears for any wear.

# FIRST in Texas Grants

31 Dec 2019

FIRST in Texas Grants By Bhanaviya

### Task: Detail the FIRST in Texas Grants and understand how it will improve our business plan

It's the last day of the decade! With a new decade, comes new money, and similar to last year, Iron Reign is supporting 3 sister teams, Imperial Robotics, Iron Core and Iron Golem, the latter two being veteran teams with rookie members. This programmatic growth also comes with a financial curve to overcome. As such, we've applied to the FIRST in Texas grants to find funding for all 4 of our teams. This allocates a total of $2000 for the Iron Reign program, but if Iron Core and Iron Golem are considered rookies due to their new members, then our program can receive around$4000.

This, alongside the $3200 from University of Texas at Dallas for hosting the Townview Qualifier, the$200 GoBilda Product Grant and the the $4000 from DISD STEM Department, which covers our season registration fees, 4 REV FTC kits, and a full practice-field. This brings our total funding up to$11,400 for the Skystone Season . There is no end to how this funding can help with finding new parts, and investing in any machinery like our new CNC Mill. Additionally, since Big Thought our programmatic partner who owns the MXP vehicle, has agreed to invest in building a second, bigger vehicle for the program, this funding can also help us in improving our outreach efforts.

### Next Steps

We have also reached out to other companies in our area for increased funding and we hope to expand on our business plan as the new year progresses. In the meanwhile, we here at Iron Reign wish everyone in the FIRST community a happy almost new year!

# Control Mapping v2

01 Jan 2020

Control Mapping v2 By Jose

### Task: Map out the new control scheme

As we progressively make our robot more autonomous when it comes to repeated tasks, it's time to map these driver enhancements. Since we have so many degrees of freedom with TomBot we will experiment with using two controllers, where one is the main controller for operating the robots and the second handles simpler tasks such as setting the tower height and toggling the foundation hook.

### Next Steps

We need to experiment with the two-driver system as well as implement a manual override mode and a precision mode where all the controls are slowed down.

# Calculating Torque at the Elbow

01 Jan 2020

Calculating Torque at the Elbow By Bhanaviya

### Task: Design an equation to model the torque at the elbow linearly

In order to maximize our robot performance, we need to be able to use motors and gears with the most ideal gear ratios. This means having the right amount of torque to produce the most efficient performance out of our robot arm. As the arm extends, there is quite a bit of torque on the elbow. We want to model this torque as a function which will allow us to better analyze how much rotational force is being exerted on the elbow and whether the gear ratio of the gears at the elbow could be improved by using a different gear set.

The torque at the elbow is a dynamic variable that changes as the arm is extended further and further. As such, we decided to model this equation as a function. Torque is generally T = Frsin(theta). F is force which can be derived by multiplying the mass of the arm (m) with g, the acceleration due to gravity. g can be otherwise defined as g = G, the universal gravitational constant, * (m/r * r). r is the distance from the center of mass of the arm when fully retracted to the axis of rotation, which is, in this case, the elbow. This value can be defined by 170.4 meters. However, since the center of mass changes as the arm extends, r is not a constant and as such can be modeled as C + x, where C is the constant for the center of mass when the arm is fully retracted increasing by x, wherein x is the value in meters by which the arm extends. C can be defined by 2358.68 grams. As the arm is extended, the axis of rotation is in motion so theta, the angle in degrees between the vertical and the position of the arm changes linearly and as such, cannot be represented as a constant. However, since this angle is more difficult to derive, and since the angle between the position of the arm and the horizontal is already shown in the code for the controls operating the elbow, theta can simply be stated as 90 - theta_0, wherein theta_0 is the angle between the horizontal and the position of the arm. The torque due to gravity at the elbow can be represented as the function T = 2358.68 grams g(170.4 meters + x)sin(90 - theta_0) wherein theta_0 and x are parameters which can be taken from the articluation positions.

### Next Steps

Being able to model torque as a function will allow us to understand how much torque is needed for the robot to stack a certain number of stones. By identifying the non-constant values of the torque function, we will be able to analyze what specific values produce the best robot performance, as well as whether that performance can be improved by lightening the load on the arm.

# Logarithmic Spiral Update

02 Jan 2020

Logarithmic Spiral Update By Ben

### Task: Update the Logarithmic Spiral

As the design and build of the robot progresses, many components must be updated to be compatible with the current design. The logarithmic spiral, which was used to linearly decrease the load on the elbow with a bungee cord, is one of these. The article for the original design is numbered as the 45th post in the engineering section and is dated 15-11-2019. Prior to updating the design, the part would interfere with the drive shaft for the elbow. This typically wouldn't have been a concern, as it provided a safe way to limit the movement of the arm, yet we have determined that we need a greater range of motion. To do this, we simply cut a small half-circle out of the spiral. This was a relatively simple fix which would allow us to stack the blocks higher, scoring even more points.

The next fix was the mechanism for attaching the bungee to the spiral. We plan to attach a bungee from both the front and back of the spiral to generate a greater rotational force. A design issue we encountered was running a bungee to the back of the spiral. There was no simple method for attaching and containing the bungee. To overcome this, we decided we would attach the bungee to a string from the back of the spiral. The final spiral design required two individual machined parts. Each part would have a chamfered edge, forming a channel when the two were put together, allowing the string to run within that channel. The two parts would be connected using three new holes to prevent the string from wedging itself between the two.

The image below highlights the changes made to the original part. The chamfers along the edge were added along with three holes to connect two of the parts. The half-circle is also highlighted. These changes should enable us to assist the elbow in lifting the arm with greater efficiency than with the previous version of the spiral.

### Next Steps

Our next steps are to machine the two parts and determine how much tension we need on the bungees to generate enough torque to assist the elbow.

# Modeling TomBot Articulations

02 Jan 2020

Modeling TomBot Articulations By Ben

### Task: Model TomBot's Articulations in Fusion360

Modeling articulations is important for many reasons. The first of which is being able to effectively strategize. Having an idea of how the robot can move allows the team and drivers to understand the physical limitations of the components as well as enabling the drivers to determine how to control the robot most efficiently. Without such abilities, the drivers would only be able to visualize the robot's movements once it was constructed or a prototype was created. Drivers may also require new articulations which could be modeled and tested without having to program the movements.

The second reason for creating robot articulations is to assist the coders. It is important for the code team to visualize articulations because it allows them to better choreograph the movements of specific articulations. Coding is hard enough as is, but having a reference is certainly helpful after coding something for hours and hours without an end in sight.

To enable articulations on the model, joints were added in Fusion360 to allow motion. For our model, we added three rotating joints. One for the turntable, elbow, and gripper. The model also required 3 slide joints for each stage of the linear slide, all of which providing me with considerable trouble for something that supposedly just moves in a line. Fusion also allows us to set restraints to limit the motion of the joints in the model. This is useful because it allows us to animate the joints like how they would function in a real environment, along with making it dance until it apologizes for all the strife it has caused me throughout my lifetime.

### Next Steps

The next steps for the robot model are to update the gripper to the most recent gripper. This gripper has already been modeled but needs to be added to the robot assembly. We would also like to begin modeling our second robot from scratch. Modeling the second robot is critical if we are to use the CNC to construct components for the new robot.

# Calculating Torque at the Drive-Train

02 Jan 2020

Calculating Torque at the Drive-Train By Bhanaviya

### Task: Calculate torque at the drive-train and analyze our choice of motors

During drive-testing, one issue we noticed was that our robot was not as fast as could be, and in a speed-based game, this is not ideal. So, we decided to calculate torque at the drive-train, which currently runs on two Neverest Classic 40 motors. Currently, we are looking to replace these motors with REV HD Hex Motors with a 3-part cartridge. As such, we will find the torque acting on the drive train with both these motors to identify whether replacing the motors is the best choice, and if so, what combinations of a cartridge we ought to use on the new motors.

Currently, we have 4 gear sprockets for the two 8-inch wheels on the chassis. However, since these are all of the same gear ratio, they do not need to be included in the calculations to find torque. The Classic 40 Neverest motors have a ratio of 40:1 and a stall torque of 2.47 Nm, both of which are values which can be found in the individual part specifications. Using this information, we can find that the torque acting on the drive train to be 2.47Nm * 40 which is a total rotational force of 98.8Nm.

The Neverest motors give a significantly high amount of torque so looking to reduce it would help us increase the drive-train's speed which is our intended goal. A good replacement would be the REV Hex motors with the planetary cartridge but choosing the type of cartridge is the challenge. Ideally, three 3:1 cartridges would give the least torque but this combination would lack too much control. Especially since our supply of these catridges is limited, we want to choose a combination which gives a "good" amount of torque but also produces a decent speed. Currently, the Neverest motors are not slow and we only want a little more speed on the drive-train. Taking this into account, we want to choose a combination which is closest to the 40:1 ration but still falls under it. So, a combination of 3:1, 4:1, and 5:1 cartridges would be the best choice since it provides a compounded gear ratio of 36:1. Considering the stall torque of the Hex motors to be 2.1 Nm, we can calculate the torque to be 2.1Nm * 36 75.6 Nm.

### Next Steps

The hex motors with a 36:1 compounded gear ratio are not only the closest in ratio to the Neverest motors, but also have a significantly lower torque with enough to maintain good control. As such, we are going to replace the our current motors on the drive train with this specific cartridge. If we find that the drive-train's performance could be improved, we will find more cartridge combinations or go altogether with a different motor to improve control.

# Calculating Torque at the Turn-table

02 Jan 2020

Calculating Torque at the Turn-table By Bhanaviya

### Task: Analyze torque at the turn-table and how it affects our choice of motor sets

We want to know if we are using the best possible motor set on our turntable. Since our turn-table is programmed to rotate at the fastest possible speed, we are not too concerned with a motor that turns faster but rather one that has a higher level of control and produces a higher output torque. A faster turret gives us less control when we are turning on the field and we want to reduce the time we spend trying to get the turntable in the right orientation. So, it's time to replace its motors. Currently we are using a Neverest orbital motor on the bevel gear on the turret which has a stall torque of 0.23Nm. With a torque this low, we are not utilizing the turret to its maximum capability. We want to replace this with a REV HD Hex Motor with a double planetary cartridge. REV offers a manual which allows the user to see the exact gear ratios and output torque produced by each combination of cartridges. Based on the cartridges we have right now, two 4.1 cartridges have the highest output torque as per the manual. But we don't want to replace our current motor just yet, until we calculate the exact amount of torque and analyze whether this is a good amount.

The gears operating the turntable are an 8:1 pinion gear and a 2:1 bevel gear. Thus, their compounded gear ratio is 16:1. Using this, we can find the output torque produced by our current motor which can be found by finding the value of 16 * 0.23Nm * 3.7 which gives us an output torque of 33.6. Now, this value can be higher so if we switch out with the double staged 4.1 HD Hex Motor, we get a compounded gear ratio of around 13.1, according to the REV manual. The stall torque for these motors are 2.1Nm which is significantly higher than the amount produced by the orbital motor. Plugging both these values and the 16:1 gear ratio of the turntable gears, we can find that the output torque produced by the turntable REV planetary motors can be found using the equation 16 * 2.1Nm * 13.1, which equates to 440.16 Nm.

Based on these calculations, we can find that the planetary motors produce a significantly higher amount of torque and will give our turntable much more control and precision when operated. This amount of torque may cause some concern on how much the slower the turntable will be; as such, we also calculated the linear speed of the turret. To do this, we have to find the rotations per minute (RPM) of each motor. The no load RPM for the 3.7 motor is 1780 RPM. By dividing this by its gear ratio, we can find the RPM which is 1780 RPM/3.7Nm which is equal to 481.08m/s. As for the REV motor with more torque, its no-load RPM is 6000 RPM and when divided by its gear ratio of 13.1, we get a linear speed of 458.02m/s.Although this is a lower linear speed, the difference is very little, showing that the new 13.1 motors will not reduce our speed by much but will have a much larger effect on the output torque of the turret, thus maximizing the turntable's efficiency.

### Next Steps

Since we determined that our current turntable motor needed to be replaced, our next step was to make the physical switch on our bevel gear system on the turret. However, we are yet to test how much of an improvement the replacement will be so that will be our next goal. If we find that the motor set can be further replaced then we will use calculations similar to the ones in the article depending on whether we want to reduce or increase torque. Our next qualifier is this upcoming Saturday, so the new motors should improve our turntable control for the match-play portion.

# STEM Expo Preparation

03 Jan 2020

STEM Expo Preparation By Bhanaviya

### Task: Plan for the DISD STEM Expo

An FLL Team Gathered Around Iron Reign's Robot at the 2019 STEM Expo

Next week, a week after our second qualifier, Iron Reign along with members from our 3 sister teams, is participating in the DISD STEM Expo for our fourth year. As we have done for the past 3 years, we are bringing the Mobile Learning Experience Lab to the event area in Kay Bailey Hutchinson Center. The purpose of this event is to connect with children in the DISD Area by helping them a foster an appreciation for engineering and the sciences. With the support of the Dallas City of Learning, a non-profit organization operated by Big Thought which helps schedule The Mobile Tech Xperience (MXP), Iron Reign will have a featured exhibit within the MXP. To maximize event productivity, we will be working alongside volunteers from Microsoft and Best Buy who will help us ensure that the exhibit runs smoothly.

Iron Reign on the Student Passport at the 20202 DISD STEM Expo

For reference, every year that we have held this event, Microsoft, Best Buy and Big Thought provide volunteers to help teach kids on 3D-modelling and block-programming, the two key highlights of the MXP program. As the youth voice for this program, we teach these volunteers on how to teach the activity to younger students with little to no STEM experience. For the first time in our years organizing a booth, Iron Reign has been recognized as a vendor on the student passports which will be given to all participants!

As part of the exhibit, we will have events similar to those hosted as part of our summer outreach events. This includes the LEGO Mindstorm Sumo Robots Event as well as our 3D Printing keychains activity. We will also be bringing our field sets, so both us and our sister teams can demonstrate our robots to participants.

It is worth mentioning that this may be the last year we run this event with the current version of the MXP. Since Big Thought has approved plans for funding a new, larger vehicle, we hope that we will be able to present the new and improved MXP next season, in time for the STEM Expo.

### Next Steps

At the end of the day, modeling and coding are two of the many aspects encompassed in STEM, and more importantly, FIRST. In introducing these activities, we hope to promote a student initiative in FIRST Robotics. And who knows - tomorrow, we might just meet the future members of Iron Reign.

# Testing Two Drivers

04 Jan 2020

Testing Two Drivers By Justin and Aaron

### Task: Practice driving with two drivers

Today we started testing out our new two controller setup. The goal is to have one driver control just the base, and have the other driver control the arm and turret. With the early stage of the 2 driver code, we were able to practice maneuvering around the field and placing blocks. unfortunately the code wasn't completely sorted, so the turret controller lacked many features that were still on the drive controller.

An issue we noticed at first was that the drive controls were backwards, which was quickly fixed in code. After the robot was driveable, we spent most of our time practicing picking up blocks and testing out new code presets. Throughout the day we transferred functions between controllers to divide the workload of the robot into the most efficient structure. We found that whoever controls the base should also be responsible for placing the arm in the general area of where it needs to be, then the turret driver can make fine adjustments to grab and place blocks. This setup worked well and allows us to quickly grab stones off the lineup shortly after auto.

### Next Steps

Next we will practice becoming more fluid with our driving and look for more common driving sequences that can be simplified to a single button.

# Driver Optimization Developments 5/1

05 Jan 2020

Driver Optimization Developments 5/1 By Cooper

Today we worked on driver optimizations, since Justin was here. We changed around the controls for the arm to be more like the drivetrain and the D-pad on controller 1, with the left stick by controlling the elbow, the x controlling the turret, and y on the right stick to control the extension of the arm. This was cited to be more natural to the drivers than the previous setup. Then we tuned the PID values for the turret, while also reducing the dampener coefficient of the controller for the turret. Though here we ran into some issues with the dead zone rendering the entire axis of the given controller stick useless, but we shortly fixed it. There was also a problem with our rotateCardinal() method for the turret that we fixed by redoing our direction picking algorithms. Finally, I worked on tuning auto just a tad, but then had to leave.

### Next Steps

Analyze more driver practice to get more concise controls for the driver, and finish auto.

# Drive Practice 1/6

06 Jan 2020

Drive Practice 1/6 By Justin and Aaron

### Task: Practice driving with new code

Today we worked on driving the robot with new presets. Over the weekend, our coders worked on new presets to speed up our cycling time. The first preset the drivers learned was the cardinal directions, which allows the base driver, but potentially both drivers to quickly rotate the turntable 90 degrees. This made switching from intakeing to stacking directions very fast. To further speed up our stacking time, our coders implemented a stack to tower height, which allows the driver to set a height and the gripper will raise to it. This took a lot of practice to correctly distance the robot from the foundation for the preset to reach the tower. To avoid knocking over our own tower, we decided that the arm driver should stop the 90 degree rotate before it fully turns, so when the arm is extended it goes to the side of the tower, so the driver can rotate the turntable and still place the stone.

We also worked on dividing the control between the two drivers, which involved transferring functions between controllers. We debated who should have turntable control and decided the base should, but we would like to test giving the turret driver control. The extend to height controls were originally on the drive controller but were moved to the turret to allow for a quicker extension process. The gripper wobble greatly slows down our stacking, even after dampening it.

### Next Steps

Our next steps are to practice driving for our next qualifier and modify our gripper joint. A lot of our robot issues can be solved with enough drive practice. We need to start exploring other gripper joint options to allow it maintain orientation but not sway.

# Dissecting the Turret

09 Jan 2020

Dissecting the Turret By Karina and Cooper

### Task: Figure out why the turntable isn't turning

Just as Iron Reign was at the point of getting driver practice started and hunkering down to do autonomous, the turntable stopped working. The issue was that there was heavy skipping of teeth between the planetary gear and pinion gear which drove the turntable. Still, there was no obvious reason for why the gears had suddenly disengaged.

To get to the root of this issue, we took to dissecting TomBot. We had to detach the metal frame which supported the turntable from the chassis just to get a better view of the problem area.

Ultimately we chalked it up to the metal plates shifting on the polycarbonate circle of the turntable from all the movement. Our solution was to shift everything on the turntable over a small amount in the direction of the point along the planetary gear where the pinion gear engaged so that there would not longer be skipping. We got to work with but drivers and pliers to detach the turntable attachments from the turntable, and then the slip ring, and then the circular polycarbonate plate from the mass of motors, wiring, gears, linear slide, and the gripper that make up the arm. Once we had the circular polycarbonate plate isolated, we used a dremel with a drilling bit to widen the holes through which the bolts attached the entire arm system to the plate. We figured shifting out the turret may alleviate the issue.

### Next Steps

We will have to find a more solid solution for this in the event that this becomes a recurring problem. I suspect that the underlying cause is that the materials that we used for either printed planetary gear or the polycarbonate plate upon which the whole arm rests could not handle the stress of the torque and speed of the turntable. Going forward we can conduct some material strength tests to determine if they can handle the stress, or if we should find a replacement. To be frank, even after dissecting Tombot, we were not certain about the cause behind the planetary gear disengagement.

# Finger Gripper Morph Chart

10 Jan 2020

Finger Gripper Morph Chart By Jose

### Task: Create a morph chart to analyze all our 3-finger gripper versions so far in this season.

Just like with our gripper designs, we've also gone through a number of changes with our final gripper - the 3 Finger Gripper. This calls for one thing - a morph chart! A morph chart shows us the various subsystems of the 3-finger gripper as it went through its different stages of design. The left axis addresses each part of the gripper like its grip material, back fingers, front finger, and capstone deployer. The right axis shows the different versions of each component visually. Right now, we are at a whopping 4 versions of the same design with 3 grip materials, 3 back and front fingers, and 2 different capstone deployer designs. The latest version has REV Extrusions, a GoBilda plate for the fingers, a red silicon oven-mitts for the grip material (and for helping with the turkey, of course), and no capstone deployer just yet.

### Next Steps

By putting all of our grippers in one chart, we can see how our gripper has evolved from its humble beginnings, and lets us see which ideas we could possibly recycle. To read about our comprehensive gripper morph chart, visit our article on Gripper Designs Morph Chart. As the finger-gripper undergoes more modifications, we will create another, more updated morph chart later on.

# Match Play at UME prep. Qualifier

11 Jan 2020

Match Play at UME prep. Qualifier By Trey, Ben, Aaron, Bhanaviya, Jose, Cooper, Justin, Karina, and Paul

### Task: Compete in Qualification and Finals matches

Today Iron Reign competed at our second qualifier at UME Preparatory Academy with TomBot which could have been better in terms of autonomous, driver practice, and build. But regardless of this, we were still able to be in the winning alliance and the following are descriptions of the match play that made that happen. For reference, we have a separate post underlining the analysis of the qualifier that does not include match analysis. This post merely details how each one of our matches went, and we will have a future post discussing our drive issues at the competition.

Match 1(Quals 3)

Match one was a little bit of a disappointment even though we won 26-19 because we made almost no points from auto (which we didn’t have) or the tele-operated period. The 25 points we did make in the endgame were made because we moved the foundation out of the build zone with the foundation grabber, which didn’t line up very well.

Match 2(Quals 10)

With the driver practice from match one, we entered match two, stacked two blocks, and tried to move the foundation again but the grabber kept getting stuck. And it didn’t help that In this match our partnering team did not contribute very much which led to the overall score of 8 vs. the opposing alliance’s score of 55.

Match 3(Quals 15)

We won this match 52-15 because of 40 points form the opposing alliance’s penalties and only 12 from what we accomplished. Those 12 points mostly came from moving three stones under the bridge and placing two on the foundation. We didn’t get very many other points because we still can’t move fast enough and sometimes when we place a stone on the foundation we knock it off shortly after.

Match 4(Quals 17)

We lost this match by 77 points. This was mostly because we were against 7172 Technical Difficulties and because we still weren’t able to quickly or accurately move blocks onto the foundation, with only one block in the end. We also were still having difficulties with the gripper and the foundation grabber, which kept getting stuck.

Match 5(Quals 26)

Things actually started to come together in this match and we won 72-16 because the drivers had a better feel for the robot and we fixed the foundation grabber. In the end, we were able to get 3 stones on the foundation and stack two of them. The other points came from parking and our partnering team’s auto which scored 15 points.

Semis 1-2

Contingent on the fact that we would place a capstone on their tower, 7172 decided to make us their second choice alliance partners. Together in the match, we scored 92 points even though, our capstone got stuck in the gripper. This meant that we contributed almost no points to the final score which was sad.

Finals 2

In this match we had the same strategy as the last one, sit around with a capstone and place it at the end of the game. The only difference between the placement of this capstone and the other one was that this tower was 2 blocks higher. And even though the tower’s height caused us to mess up and knock the whole thing over, we still won 51-89.

### Next Steps

Overall, the match play of this qualifier did not go plan. Between the awkward flexibility of the gripper’s attachment point, the jamming of the foundation grabber, the lack of driver practice, and the severe absence of a functional autonomous, we only made up to 20 points per match. And if we want to have any hopes in robot performance at regionals we need to do better in all of the aspects mentioned starting with driver practice and autonomous, the two factors that contributed the most to our overall performance.

# UME Qualifier

11 Jan 2020

UME Qualifier By Bhanaviya, Karina, Cooper, Jose, Trey, Aaron, Ben, Justin, and Paul

A solid month or so after our first qualifier, Iron Reign walked through the doors to our second qualifier at the UME Preparatory Academy with our three sister teams. Compared to last season, we had gotten significantly more driver and presentation practice, but we still weren't as organized as we could have been and in a robotics qualifier, this is a bit of concern. Nevertheless, we were optimistic (though wildly unprepared) for the day ahead.

##### Inspection

Just like at our first qualifier at Allen, we passed inspection the first time around! While this was a minor victory, it served us well later on in the day.

##### Presentation

Having practiced more the second time round, our presentation ran relatively smoothly. We did lack enthusiasm, however, and as one of the earlier teams to go through judging, this was not ideal. Unlike last time, though, our robot demo worked significantly better. Still, our questioning period could have worked off better and the transition from each question is something we will be focusing on improving before regionals.

##### Robot Game

First off, the turret on our robot had to be entirely dismantled the week of qualifier, and there had been a storm the previous night, and since robots and rain don't generally make a good combination, we didn't have too much driver practice. We had practiced in the couple weeks leading up to the qualifier though, so needless to say, we were in much better shape than previously. For reference, this post will not discuss our robot performance at UME and merely serves as a summary of our day in each sub-category. There will be another post detailing our match-play soon.

###### Match-Play

With a win-loss record of 3-2, our qualification rounds weren't the best. But somehow, we managed to scrape through to be ranked 8th! Our sister teams Iron Golem, Imperial Robotics and Iron Core had placed 6, 10 and 12 respectively, an impressive feat, especially considering that 2 of these 3 were rookies. Though our rank wasn't as stellar as it could have been, we were able to demonstrate TomBot's Tall-Mode and its capping abilities to the 1st seed team Hockabots and them and their alliance partner Technical Difficulties picked us during selections! Additionally, for the first time in the history of our robotics program, all 4 of our teams were selected during alliance selection for the semi-finals match.

###### Semifinals & Finals Matches

Ultimately, our alliance's performance in the semi-finals served us well into our advancement to the finals... until it didn't. Nearing the end of finals, our attempt to cap Technical Difficulties' tower ended up knocking over the stack. Fortunately, our alliance still ended up winning, but finding accuracy in our stacking, especially with regards to capping is something we plan to work on going into regionals. Currently, we have gone through 3 different capstones and capstone-droppers but those still require more testing in order to ensure our capping abilities improve by regionals.

###### After-Judging and Awards Ceremony

While we didn't have high expectations for our success, we did manage to garner several visits from judges to our pits. A good measure of judging success is if the judges come back to talk to you, and at UME, we had four separate groups of judges come up to us and ask us about each component of our team, from business, to outreach, to sustainability, to our robot design.

In the ceremony, every single member of the SEM Robotics program waited. With all 4 of our teams having made it to semi-finals, this was by far our most successful qualifier match-play wise. Since Iron Reign had already advanced at the previous Allen Qualifier, we were ineligible for the Inspire Award but we were still relatively hopeful. At the end of the day, we were finalists for the Design, Innovate, and Connect awards, closing off our day with 1st Place for the Think Award!

### Next Steps

Although only one team from our program has advanced to the regionals, this season was successful both on a program and individual-basis. All three of our sister teams performed impressively well at the qualifier, and although their match seasons might be over, their robots still have a while to go. Next week Iron Reign is helping organize and coordinate a booth at the DISD STEM Expo, where all three of our sister teams will be demo-ing their competition robots to students with little to no STEM experience. As the season progresses, Iron Reign is looking forward to recruiting new members from our sister teams, 2-3 at the least. While this may have been our last qualifier, we still have a lot of progress to make leading up to the North Texas Regional Championship. Our post-mortem analysis detailing our performance at UME and preparing for our next tournament will be on our blog soon.

# Growing Pains and Reigns

16 Jan 2020

Growing Pains and Reigns By Bhanaviya, Shawn, Mahesh, and Anisha

### Task: Expand the Iron Reign Robotics Team

One of our biggest challenges this year was learning to adapt our robotics program to the large influx of new recruits. Last year, most of us current members on Iron Reign were the new recruits, so to see the sustainability progress from a whole other outlook this season was at first jarring. However, just like last year, we expanded our robotics program to support 3 teams - Imperial Robotics, Iron Core and Iron Golem, bringing up our program count to a total of 30 active participants.

Each of these three teams have underwent their own successes and failures through the Skystone Season. However, moving on from our program's last qualifier of the season, it's time to take a look back at our highlights. From competing at a grand total of 2 scrimmages, 2 qualifiers, and hosting one tournament, our program as a whole has progressed to a different, higher level. Moving on from here, our next step is to discuss recruitment for Iron Reign specifically. For reference, our team serves as the varsity team in our robotics program and everything you've seen in this journal thus far is specific to our team. With our regional championship being 3 weeks away, recruitment for our current 9-member team is a question we have yet to answer. As of now, our team comprises of mostly underclassmen - 7 to be exact. Based on this count, and our sub-team specific needs, we have decided to recruit 3 new members from our sister teams as we go into the next level of competition - Shawn Halimman, Mahesh Natamai and Anisha Bhattaru.

### Next Steps

While we don't have any immediate plans to increase our team count further, we're confident that our 3 newer members will make a strong addition to our program as the season flies. All of us on this team were recruited from one of Iron Reign's sister teams, and being able to expand our team alongside our program will help SEM Robotics remain sustainable for years, if not decades to come.

# DISD STEM Expo 2020

18 Jan 2020

DISD STEM Expo 2020 By Ben, Justin, Jose, Cooper, Paul, Trey, Mahesh, and Shawn

# Auto Developments at the STEM Expo

18 Jan 2020

Auto Developments at the STEM Expo By Cooper

### Task: Improve autonomous and tune IMU

During the STEM Expo, while also helping volunteer, we worked on auto. There were a series of cascading events that were planned and completed. The first of which was to calculate the TPM of the base. There was, however, a problem before we did that. Our robot has a slight drift when trying to drive straight, which could be solved by driving based off of the IMU. However, we had discovered a couple of days ago that it doesn’t run. This made no sense, until a critical detail was uncovered -- it sets active to false. With this knowledge, Ahbi sluthed that the action was immediately being completed, since it was in an autonomous path. We then took a break from that and calculated the TPM a different, and far less complex way- we drove it a meter by hand and recorded the tick values. After we did that, we averaged them up, and got 1304, which in the end we decided to use, since just after that Ahbi figured out the problem with the driveIMU() method, and it went perfectly a meter. The issue was rooted in one wrong less-than sign, which was in the if statement to detect if we had gotten to our destination yet.

### Next Steps:

This is the first time we've actually tuned auto since the UME Qualifier, but now that Mahesh is trying to implement Vision, we plan to improve the sensor capabilities of our robot as well.

# Code Changes At STEM Expo

18 Jan 2020

Code Changes At STEM Expo By Mahesh, Cooper, and Abhi

### Task: Use Vuforia To Detect Skystones And Tune Ticks Per Meter

This Saturday, we had the privilege of being a vendor at the Annual DISD STEM Expo. While this event served as a good way for us to showcase TomBot at our booth, it also gave us the much-needed chance to experiment with vision. With this year's game rewarding 24 points for locating skystones and placing them onto the foundation, vision is an essential element to success. To detect skystones, we could have gone down three distinct paths: OpenCV, Vuforia, or Tensorflow.

We chose to use Vuforia instead of Tensorflow or OpenCV to detect skystones since the software gave the rotation and translation of the skystones relative to the robot's position, which could then be used to determine the position of the skystone, either left, center, or right. Additionally, Vuforia has proven to work under different lighting conditions and environments in the past, whereas Open CV requires rigorous tuning in order to prove flexible for a variety of field settings.

The second major task we worked on during the STEM Expo was calibrating ticks per meter. The issue we encountered when driving both wheels forward a set number of ticks was that the robot drifted slightly to the right, either meaning that the wheels are misaligned or that one wheel is larger than the other. To fix this issue, rather than tuning PID Coefficients, we figured out a separate ticks per meter measurement for both wheels, so that one wheel would move less than the other to account for the difference in wheel diameters. After experimenting with different values and tuning appropriately based on results, we arrived at a ticks per meter number for each wheel.

We could have used a more mathematical approach for calculating ticks per meter, which would be equal to (ticksPerRevolution * driveGearReduction) / (wheelDiameter * PI), with "wheelDiameter" being measured in meters. However, this solution would require a very precise measurement of each wheel's diameter, which our caliper is not wide enough to measure. Additionally, this solution would not account for wheel slippage, and for these reasons, we chose the latter approach.

### Next Steps

Unfortunately, the vuforia vision pipeline did not work at the STEM Expo, which may be a result of bad lighting or some other code error. Moreover, constants such as the camera's placement relative to the center of the robot have not been measured as of now, which is a task for the future. In order to make sure vuforia is working properly, we should send the camera's feed into FTC Dashboard in order to debug more effectively and pinpoint the issue at hand.

For last year's game, three different vision pipelines were used, Tensorflow, Vuforia, and OpenCV, and all three were compared for their effectiveness for finding the positions of gold cube mineral. This strategy can be employed for this year as well, since building a robust OpenCV pipeline would be impressive for the control award, and comparing all three options would give us a better idea as to which one works most effectively for this year specifically.

# Snapdragon - The Beginning

19 Jan 2020

Snapdragon - The Beginning By Bhanaviya and Aaron

### Task: Begin our 10th gripper design

As you could probably tell from our plethora of gripper articles, here at Iron Reign we have one too many grippers. And now its time for another one! We could do a whole post-mortem analysis on what went wrong about our build at our last qualifier, but for the most part, the design was consistent, with one underlying exception - our gripper. The finger gripper was a revolutionary piece of work, and has gone through a whopping 4 different iterations. But as all good things, its time must end. The issue was that the finger gripper lacked precision when it turned and was not quick enough in picking up blocks, requiring excessive control on the drivers' end to be able to focus on a stone and pick it up. In a speed-based challenge like this year's, this was not ideal, so it had to go.

A slapband in action

In it's place stands the Snapdragon, its quicker, more rugged replacement. The snapdragon functions as a passive gripper - at its core, it works as a slapband would. A slapband is, simply put, a wristband that wraps around one's wrist when slapped with enough force. Similarly, the snapdragon's closing action is an elastic-powered snapping action that is physically triggered when the gripper is lowered onto a stone. It's ability to grip is a direct result of the lower metal "flap" below the larger rectangular plate above. The effectiveness of this flap relies on the precise placement of rubber bands holding the flap to the plate above it. However this also means that the plates must be triggered in a very specific manner so that the gripper closes down at the right time.

### Next Steps

The beauty of the snapdragon relies on its ability to be self-triggered. However, it would still need to be reset after "snapping". This would require use of a servo. The servo would need to be able to close down on the stone, but this also means that the movement of the gripper needs to be controlled such that it does not snap upon contact with any other surface. Trying to find a balance between this passive action and the servo's movement will be our primary task since the gripper isn't ready to be mounted yet.

20 Jan 2020

Engineering Notebook Binder CAD By Jose

We want to utilize our new CNC as best as we possibly can. Since we plan to CNC the second version of our current robot TomBot for regionals, the only companion that could serve a CNC-ed robot is a CNC-ed engineering notebook! Plus an aluminum-plated journal would also help us emphasize the iron part of our name to the judges (hi there, if you're reading this!). The first step is to make a CAD file for this binder which is what we have shown above. The most custom part is the cover, it features our team logo, name, team number and even outline of our robot. As per GM1, we can have 2 engineering notebooks so we will make 2 custom notebooks, one that reads "Engineering Section" and another that reads "Team Section". We plan to use piano hinges to joint all the panels of the binder, use polycarbonate as pockets, and steal some binder rings from other binders to be used for these. The panels of the binder will be made of aluminum and the cover will be carved out using our CNC.

### Next Steps

The outline of our robot, TomBot, may be changed in the future but other than that all we need is to CAM the binder CAD to be able to make it using our CNC. Once the journal is printed, all that's left to do is add the rings, panels, and pockets to the actual binder.

# Snapdragon - The Sequel

24 Jan 2020

Snapdragon - The Sequel By Bhanaviya and Aaron

### Task: Improve the precision of the Snapdragon.

Last week, we prototyped a new gripper called the Snapdragon. Now it's time to give it more complexity. The Snapdragon is a passively-triggered gripper which closes down on a stone upon an impact-heavy contact with it. The main issue we're focused on solving is the impact which triggers the gripper - the gripper needs to be able to close only upon contact with the skystone and not with any other surface. To solve this problem, we added the servo horns, which make the snapdragon look like an actual dragon, for an increased comedic value. Before the servo horns, an abrupt stop by the metal plate of the gripper and the momentum of the "flap" below it were needed to grip a stone but this requires too precise placement of plates. With the addition of the servo horns, the servo horns physically trigger the drop so that the rubber bands holding the gripper in place can be tighter and have more grip.

In addition to the servo horns, we will also be using a capstone dropper. The capstone dropper is mounted between the two servo horns, and has three small wired which will go through a hole at the base of the capstone. The dropper will be pre-loaded with the capstone and be released during the endgame. The capstone dropper has not yet been tested but we will get to that once we have controls to release the capstone.

### Next Steps

We need to test the Snapdragon's new version extensively so that our drivers can get a feel for it. Next, since this is a passive gripper model, it would need more grip, so we also need to conduct materials testing on more materials to determine which material has the best grip and can be mounted on the gripper.

# Coding the Snapdragon Gripper

25 Jan 2020

Coding the Snapdragon Gripper By Cooper

### Task: Code the new Snapdragon gripper

Last night we installed the new Snapdragon gripper, which means we needed to re-work the gripper code. We started out by getting the positions the servo would go to using a servo tester. Then we decided whether to make it an articulation, which originally we did. This articulation would set the servo to pull up the gripper front and then return to its relaxed position. After doing some testing, that method was not working.

So, we moved on to reformatting the gripper update sequence we had for the last gripper. There we still saw no success after that. So, we decided to call it a night, as it was getting late. The next morning, with a clear mind, we realized that the wire connection was flipped on the perf board, wherein after flipping it it worked fine.

### Next Steps:

We still need to test it with drivers, see if there are any quirks.

# UME Prep Qualifier Cumulative Post-Mortem

25 Jan 2020

UME Prep Qualifier Cumulative Post-Mortem By Jose, Bhanaviya, Anisha, Mahesh, Karina, Cooper, Justin, Paul, and Trey

### Task: Analyze what went wrong at the UME Prep Qualifier

It has officially been one week since the UME Prep Qualifier and we are now 4 weeks away from the Regional Championship. This is not great but it does mean one thing - a post-mortem talk! A post-mortem talk allows us to analyze our performance in full detail and take a closer look at our strengths, weaknesses, potential opportunities and threats in a cumulative SWOT analysis. The analysis itself is detailed by each of our subteams and on our performance throughout the day, and in our preparation efforts. You can see the analysis down below:

## Strengths

• Earlier preparation of the engineering journal
• Turret needs a better history - in an earlier post?
• Driver practice
• Robot Demo
• Content was organized well
• Functional (semi) robot
• Judging Box - more cohesive

## Weaknesses

• Disaster zone that is a flurry of parts and tools who knows where
• Pit needs to be better organized
• N A T U R E
• There weren't very many match videos that were taken
• Packing List
• Need a rack for bags
• Resizing images
• A lack of people staying late on Friday
• Presentation
• Last minute preparation the day of (logistics)
• Lack of Autonomous
• Gripper mounted too late
• Not enough people for load out
• Control Award
• Karina and Ben did all the packing the day of

## Opportunities

• Afterschool & Sunday Practices
• Allocating more time to preparation in the weeks before competition instead of days
• Tent, banners, business cards (for handouts)
• Post-event follow through: plugging in phones, charging batteries, etc
• Research posters
• Control map needs more hype

## Threats

• Laziness
• Busy schedules/low priority

## Strengths

• We won Think 1st place!
• Nominated for all awards except Motivate
• Had a good explanation for robot shape (mentioned center of gravity, turn table)
• Find a better way to show outreach separation
• Transitions at slides
• Very good at redirecting
• Storytelling
• Pit visits:
• Good at getting queues from one another
• demo worked better than at presentation

## Weaknesses

• Choices for content that doesn’t link to awards
• LACK ENERGY
• Don’t redirect to topics that don’t have a lot of substance
• Conclude better?
• Didn’t redirect
• More calculations based posts
• Document specific driver calculations
• Referring back to their questions
• Clarity about past achievement: We present a lot of information about outreach and prior accomplishments in our presentation but because of the sheer amount of information that we share, judges get the idea that our current team isn’t completely responsible.
• Hand off between presenters needs to be smoother
• Having our broom H A T S
• Having more people at the pits to rep team
• Did not seed questions
• Discussing our focus on sustainability effectively (MXP, etc)
• Needed people placed at pits to talk to judges

## Opportunities

• Be aware of what a judge is looking for
• Emphasize that circle helps with strategy
• Make our binder stand out - create robot manual
• Create a table for our swivels - qualitative research with Nylon, Ninjaflex
• Polycarb?, Aluminum swivel, CNC-ed robot

## Threats

• Not being able to communicate to judges effectively

## Strengths

• Inspection passed the 1st time
• Advertised well to 1st seed
• Physical build was solid
• Focused on building/improving throughout competition
• Teamwork

## Weaknesses

• Learn game strategy, learn to wave
• Less gripper wobble - fix dropper, improve placement
• Wire management
• Set screws

## Opportunities

• Driver practice - allocate time and practice match play
• CNC Bot:
• - Create a base plan + turntable
• -Gripper less jank: the ninjaflex part could use nylon
• - Jiggle test?
• LEDS MAKE BOT LIT
• Joystick compensates for distance - being able to change heights for extend to tower height
• Gripper less jank - measure elasticity
• Slow down arm movement - precision mode
• Test grippers
• Collaborating with alliance
• Fully automatic gripper with distance sensors
• Completely CNCed robot (base - polycarb with aluminum sides)
• Articulations - More accurate presets specifically for elbow
• Dampen swing on gripper

## Threats

• High performing teams(I would have never known!)
• Time Management(ok…)
• Acquisition of all parts
• Enough time for modeling all the robot parts

## Strengths

• Hand off between presenters needs to be smoother
• Having more people at the pits to rep team
• Did not seed questions
• Discussing our focus on sustainability effectively (MXP, etc)
• Enthusiasm
• Organizing pits (backpacks at pits - keep them in car)

## Weaknesses

• Follow through on checking other teams claims is anecdotal, not systematic
• Did we get video of all of our matches?
• Having more people at the pits to rep team
• Did not seed questions
• Discussing our focus on sustainability effectively (MXP, etc)
• Organizing pits (backpacks at pits - keep them in car)

## Opportunities

• Be aware of what a judge is looking for
• Make our binder stand out - create robot manual
• Design pit layout ahead of time (Ben and Paul responsible for this)
• Dress up our pit with tent and banners
• HAVE LAPTOP READY WITH IMPORTANT STUFF
• Center of Gravity for our hats
• Business cards - have robot
• 3D printed tiny robots?
• Detailed accounts for each match we do/play by play
• Watching other teams’ matches to see how good they are
• Take the chance to talk to other teams
• Scouting App

## Threats

• Sitting around looking at phones looks like disengagement even if we are researching stuff
• Having one person REIGN during pit visits
• Lack of data - stats
• Dominant autonomous teams

### Next Steps:

We will work to implement the opportunities mentioned as well as rectifying all of the aforementioned errors before regionals. As we get closer to regionals, we will have to update this list, but as of now, it serves as a to-do list for the next following weeks.

# TomBot Calibration Sequence

31 Jan 2020

TomBot Calibration Sequence By Cooper

### Task: Create a calibration sequence to find a starting position for autonomous

Today we worked on the calibration sequence. This has been a problem for awhile now, as the robot has so many degrees of freedom, and not a single flat edge to square off of (other than the guillotine, but that isn’t necessarily orthogonal to anything), it is rather difficult to come up with some way to ensure precision on startup, and this year its integral to the auton.

To start, the arm is in need of a good way to calibrate. In theory, we have a couple of constants. We have a hard stop to the elbow, thoughtfully provided by the logarithmic spiral. We also can get the ticks from that position to a point that we define as zero. In terms of extension, we have a hard stop on the full retract, which is really all that is needed. So, we start by retracting the arm and increasing the angle of the elbow until it stalls, and we set that as the 0 for the extension. Then, we go down -elbowMax while extending the arm, such that it doesn’t hit the robot, and quickly set that elbow position as the 0 for the robot.

Previous to this revision, we had different juxtapositions of the robot in terms of the arm and the base, because we couldn’t figure out what was the best compromise of precision and ease. This time around, we decided to have the robot and the arm face the north wall. In this way, the north is common between both alliances and sides, and we can just tell it with a button push which alliance it’s on. So, with that in mind, the next steps of the calibration are to raise up the arm and turn to be orthographically square with the wall. Then, it uses a driveIMUDistance to go back and tap the wall. This is how this sequence will probably stay relatively similar throughout the rest of the time with this robot, as this seems to be what we’ve been trying to achieve for awhile now. There, however, are still things that could be added.

### Next Steps

In the future, we could add a magnetic limit switch between the turret and the base, so we can automate turning the turntable to the correct position. Also, we could add distance sensors to the (relative) back, left and right, as to ensure that were in the correct position based on the distance to the wall.

# Preparing for the Meeting with Deloitte

31 Jan 2020

Preparing for the Meeting with Deloitte By Bhanaviya

### Task: Reach out to companies and their branches in the local Dallas area

Previously this season, Iron Reign has reached out and presented to various companies and individuals in the Dallas area. So far, we have been able to communicate and present our team to the political, non-profit and engineering sectors, including Representative Colin Allred, Big Thought, Best Buy and the Dallas Personal Robotics Group respectively. The one facet with whom we have not yet gotten in touch with , however, is a multinational corporation. As such, this year, we emailed a representative from Deloitte Touche Tohmatsu Limited, one of the world-wide "Big Four" accounting services, with a request for sponsorship and a meeting.

This week, we received an email back from Deloitte's Dallas Branch and they've agreed to meet with us! While Deloitte isn't an engineering company, we are specifically meeting with their Bot-Development team and members of the Dallas Branch with an interest and appreciation for robotics. During the meeting, we plan to deliver our usual judging presentation, alongside an introduction to FIRST Tech Challenge and Iron Reign. We also plan to bring TomBot and demonstrate its capabilities. As such, this meeting will focus more on the technical aspects of our team, but we will dedicate a portion to discussing our business plan, specifically the MXP and its expansion, as well as our plans for the rest of the season, moving into, and hopefully beyond regionals.

### Next Steps

We are incredibly thankful to Deloitte's office for giving us the opportunity to discuss FIRST and our robot with them. As one of the biggest multinational corporations in the Dallas region, we believe this meeting can help us further expand our robotics program nation-wide and further, as we plan to do with the MXP as it moves out of its pilot stage. We look forward to meeting with them this upcoming week.

# Updated Bill of Materials

01 Feb 2020

Updated Bill of Materials By Bhanaviya and Paul

### Task: Update the list of parts for TomBot for regionals

Being around 2 weeks away from the North Texas Regional Championship, Iron Reign has made significant new changes to its Bill of Materials. s of now, TomBot has several build issues that will be discussed in our post-mortem posts. Part of rectifying these issues includes ordering/printing more parts and editing the bill accordingly. But the beauty of the bill of materials relies on the fact that we will be building our second, improved version of TomBot soon - a little after regionals - and having a corresponding bill will streamline this process. We would like to iterate that regardless of whether we qualify at the Regional Championship, Iron Reign's build season will not end with the competition, We plan on furthering ourselves in our build season by creating a more custom version of TomBot, one which incorporates as many custom-cut parts from our CNC mill as possible, and documenting all of our existing parts allows us to better analyze which parts we can possibly custom-cut.

### Next Steps

We will update the bill after regionals, once we've finalized which parts we can custom-cut and which subsystems need a complete change. As of now, since we've shifted over to a new gripper, this was a big change we had to highlight in the bill and we will continue to do these with our other updated subsystems.

# Preparation for the Dallas Personal Robotics Group Meeting

01 Feb 2020

Preparation for the Dallas Personal Robotics Group Meeting By Shawn

### Task: Create a presentation for the Dallas Personal Robotics Group Meeeting Next Week

In a week, we will be giving a presentation to the Dallas Personal Group, or DPRG. The DPRG is an engineering-based organization in the Dallas area that has monthly meetings to discuss robotics. DPRG has been involved with Iron Reign for years now, and they have volunteered at our annual Townview Qualifier as well as hosted an exhibit with us at Moonday at the Frontiers of Flight Museum this season. They are one of the biggest engineering groups we have connected with this season. In addition, we have been giving them an annual presentation about our build season for the past 4 years, this year being our fifth time. Through our presentation, we hope to gain engineering-based feedback on our robot but also with regards to our overall presentation. Below, you can see DPRG’s preview of our presentation at their monthly meeting.

Part of the preparation for this presentation includes drive-testing TomBot and getting it ready for demoing. Last year, when we presented our season to them, they provided us feedback with our robot and our vision capabilities, which was pivotal to our accomplishments through the season. As such, alongside the demo, we will also be bringing our judging box, engineering journal and create a separate deck of slides for our code and vision progress this season.

### Next Steps

The visit to DPRG will be a good opportunity to practice our presentation in front of an actual audience and ask for feedback on our robot and journal. We have been considering a custom binder cover for our journal made out of engraved aluminum, and we also hope to receive feedback on whether we should proceed with this new design or keep our existing binder for regionals. The article about how the presentation went will be detailed in a later post.

# Friction Coefficient and Energy

02 Feb 2020

Friction Coefficient and Energy By Trey

### Task: Calculate the friction coefficient of various off-the-shelf materials

Before our last qualifier, we ran a couple material tests to find the friction coefficient of different materials. Now, since we've upgraded to a new gripper - the Snapdragon - a passive-intake gripper - we will need a newer material with much better grip than the ridged silicone oven-mitt we used for our previous 3-finger gripper. Since our new gripper works by slapping onto a block and clasping it, a better grip material will allow the skystones to latch more easily. As such, we ran a new series of materials tests to find a better material.

The materials we are testing are a blue ice cube tray, a green oven mitt, a red oven mitt, a black shelving liner, a rubber cement pad, and a plate dipped in Plastidip. Three of these materials we have already tested before, which you can read about in Post 69 of our Engineering Section, but we will still conduct another test on them to keep our values in the new test consistent. The surface we are using is a 24in*24in wooden board. To conduct the tests we put a block on the selected material at the top of the board on its side and its bottom. Then we lifted the board while the block was placed in both positions and measured the height of the top of the board from the ground. We used the average of the heights in both positions to calculate the angle that the board was at using some simple trigonometry seen below. Then we used the friction coefficient equation which you can learn more about here in post 66 of our Engineering Section.

#### Blue Silicone Ice Cube Tray

When the wooden board was lifted, with this material keeping the block on it took 11.5 in until the block started to slide off. Using the equation: sin(θ)=O/H to calculate the angle at which the board was tilted which was 28.63°. Then, using the equation tan(θ)=friction coefficient, we found that the friction coefficient of the blue ice cube tray was 0.55.

#### Green Silicone Oven Mitt

We did the same thing that we did for the blue ice cube tray as we did for the green oven mitt. We lifted the board 12.75 in before the block slipped, which translates to a 32.09° angle, and a friction coefficient of 0.63. This is slightly better than the Blue ice cube tray but not the best by far.

#### Red Silicone Oven Mitt

We ran the same tests on the red oven mitt, the material we have on our robot now, and it was raised 12.5 in before the block started to slip which means that the angle was 31.39° and the friction coefficient was 0.61. This makes it an ok material just like the ice cube tray and the other oven mitt. If we were to use these materials, the grip of the robot would be fine; however, the testing of the materials is not about finding an acceptable material, it is about finding the best material.

#### Black shelving liner

This material was one of the best by far, with a height of 16.5in. The height translated into an angle of 46.43° and a friction coefficient of 0.96 which is a very high friction coefficient. This explains why this material is used on many robots like ours that want to effectively grab blocks. Another interesting note of this material was that unlike, every other material when this material surpassed its limit it didn’t slowly slide down, but it just fell all the way down the board all at once.

The rubber cement pad was the most interesting and most effective material. It was made by freeze-drying some rubber cement in a mold. When it was dry it has the friction of a sticky hand. We lifted the board 18 in before the block slipped. That means that we had to lif the board at an angle of 48.59° which means that the friction coefficient was 1.13. The only downside to this material is that it has to be cleaned before match to get the best results out of it. Plastidip. This material was not very good. For one, It does not look very clean because of how clumpy it is. It also only had a height 12 in when the block started to slip, which means that the angle was 30° and the friction coefficient was 0.58.

### Next Steps:

With these numbers in mind we are now able to decide which material we are going to use on the gripper which is going to be the rubber cement. We also know that for future seasons we can use both the shelf liner and the rubber cement to grab game elements. We are also going to continue to calculate the friction coefficient of different materials so that we can make sure that the Snapdragon gripper is the best it can be. This includes Geko Tape which we might use in the future.

# Post UME Drive Changes

02 Feb 2020

Post UME Drive Changes By Justin, Aaron, Trey, and ben

Since the qualifier at UME, we have been focusing on tuning controls to make driving smoother. Our first set of improvements was changed turret controls. The turret driver now could turn slowly with the joystick and quickly with the triggers. This allows the turret driver to quickly move the arm when the base is driving and still be able to stack precisely. Next we noticed that manually moving the arm from a tower to a safe position was faster than our preset recall. We sped up this process to speed up our transport time. Drive practice has increased our capabilities with the robot a lot, and we hope it can make us competition ready.

The biggest improvement to driving was the addition of the Snapdragon gripper. The gripper allows us to align over a block and slap down to grab. This reduces the precision necessary to grab a stone, and reduces the time it takes to close the gripper. This gripper makes a lot of noise so as soon as the base driver hears the snap he or she should start heading towards the foundation. The increased speed of the turret allows the turret driver to move the arm out of the way while the base moves to the foundation. The use of progressive joystick movement makes precise placement of the base and arm much easier and gives our robot a smoother look in matches.

We have also made some adjustments to the extend presets for intaking stones. We have added a medium and long distance extension to allow the arm driver to quickly approach the stones, and quickly reach the safe zone from a distance during endgame. Practice with the arm has greatly sped up our cycle time and stacking ability.

### Next Steps

We plan to continue training our primary drivers as well as secondary drive teams. We plan on playing practicing matches using the other teams' robots to practice moving around a busy field. We also need to make stacking at higher heights easier for the driver.

# Cumulative Drive Test Log 2/3 - 2/6

06 Feb 2020

Cumulative Drive Test Log 2/3 - 2/6 By Jose, Justin, and Aaron

### Task: Summarize the driver practice done throughout the week

Over the course of the following week we have done much driver practice so we can improve our skills as drivers and also make some driver enhancements. On Monday we reached an average of 3.7 stones per match - this includes the endgame procedures but not the stones delivered during the autonomous period. We had a rhythm of driver 1 controlling the drive to have the wheels parallel the driver station wall while grabbing a stone and perpendicular when stacking. Both these alignments help driver 2(who controls the arm) stack much easier.

On Wednesday we increased our average stones per match to 4.5, with more fine tuning on the movement between the zones and increased coordination we can keep decreasing cycle times. Finally, today we achieves a 5.4 average stones per match, although not very competitive, we are playing with no autonomous or alliance partner. We also got the idea of having a button to automatically raise the arm up and slam down to grab a stone. Since the gripper works similar to a mouse trap, all we need is force to close it and the process of getting this force can be sped up dramatically.

### Next Steps

To continue to decrease our cycle times we can keep adding driver enhancements as well as learning to coordinate between the two drivers. These improvements will show up in a later post when implemented.

# OpenCV Grip Pipeline

06 Feb 2020

OpenCV Grip Pipeline By Mahesh

### Task: Develop An OpenCV GRIP Pipeline To Detect Skystones

With this year's game awarding 20 points to teams than can successfully locate Skystones during autonomous, a fast and reliable OpenCV Pipeline is necessary to succeed in robot game. Our other two choices, using Vuforia and Tensorflow, were ruled out due to high lighting requirements and slow performance, respectively.

With many different morphological operations existing in OpenCV and no clear way to visualize them using a control hub and driver station, we used FTC Dashboard to view camera output and change variables realtime. This allowed us to more rapidly debug issues and see operations on an image, like in a driver controller and expansion hub setup.

To rapidly develop different pipelines, we used GRIP, a program designed specifically for OpenCV testing. After experimenting with different threshold values and operations, we found that a 4 step pipeline like the following would work best.

The first step is a gaussian blur, used to remove any noise from the raw camera output and smoothen the darkness of the black skystone. Next, a mask is applied to essentially crop the blurred image, allowing the pipeline to focus on only the three stones. An HSV threshold is then applied to retain colors which have low values; essentially black. Afterwards, a blob of white pixels appears near the black skystone, who's center can be determined by using a blob detector, or even by finding contours, filtering them appropriately, and placing a bounding rectangle around them, then taking the center of that rectangle to be close to the centroid of the black skystone blob. Here is a visual representation of each stage of the OpenCV pipeline:

### Next Steps

The next and only step is to integrate the GRIP pipeline with our existing FTC Webcam capture system, which uses Vuforia to take frames, and decide which x-coordinates of the skystone coorespond to which positions of the skystone. Specifically, we have to take the width of the final images and divide it into three equal sections, then take the boundaries of those three sections to decide the location of each skystone.

# Presenting to Deloitte

07 Feb 2020

Presenting to Deloitte By Bhanaviya, Karina, Jose, Aaron, Cooper, Trey, Ben, Paul, Justin, Mahesh, Shawn, and Anisha

### Task: Meet with Deloitte's Bot-Development Team to discuss

Today, we presented to Deloitte LLC's Bot Development Team in their Dallas branch office to introduce them to our team, our robot, and FIRST. Deloitte is a multinational consulting company and we had reached out to them around 3 weeks ago, with a request for a meeting with their Bot Development Team and they agreed to meet with us last week!

We gave them our judging presentation but a more extended version of it. Since we were presenting to professionals in bot development with an interest in engineering and robotics, we also spent a significant portion of our presentation demoing our robot for them and answering their questions about this year's challenge, and how our robot's design stood out in solving this challenge. Before we begun our presentation, we also showed them this year's reveal video, giving them more context into our robot capabilities and needs.

We were also able to discuss the possibility of corporate funding from their office to our team. Especially since this year, we want to construct a new version of TomBot, corporate funding could bring our scope for innovation to whole new level. Once our presentation ended, we had a short Q & A session with the participants, all of whom were very interested in hearing about TomBot's potential and about how we had conceived the idea for its construction and capabilities. ONe feedback we received was that our focus on TomBot's turntable reflected our innovation with regards to our build season strongly. As such, this will be one point which we will be sure to hammer during the actual presentation.

We even met one professional who had connections to a gecko tape research program at a bio-mimicry lab in Villanova University, and who mentioned she would be able to reach out to the lab to answer any of our questions about potential gripper materials. Since, we are currently looking into implementing gecko tape for our gripper, this was great to hear. Then, we were taken on a tour of their branch, where we were able to see the large variety of tech and virtual media they had implemented across their offices.

### Next Steps

We would like to thank Deloitte for giving us the amazing opportunity to present at their Dallas branch. We really enjoyed being able to bring FIRST and our robot to their office, and we are incredibly grateful for their interest in our robotics team (and their generosity in providing us with cookies at the end of our visit!). We plan to reach out to them after Regionals, regardless of our qualification status, to find out about the possibility of partnering with them.

# Control And Vision DPRG Presentation

08 Feb 2020

Control And Vision DPRG Presentation By Mahesh and Cooper

### Task: Present Control And Vision To DPRG And Gather Feedback

This saturday, we had the privilege to present our team's Control and Vision algorithms this year to the Dallas Personal Robotics Group. During this event, we described the layout of our robot's control scheme, as well as our OpenCV vision pipeline, in order to gather suggestions for improvement. This opportunity allowed us to improve our pipeline based on the feedback from more than a dozen individuals experienced in the designing, building, and programming of robots. We were able to demo our robot on a playing field, showcasing the mechanics of its design as well as semi-autonomous articulations to help improve driver performance.

Here are is the slideshow we presented to DPRG:

For this year's game, we chose a four step vision pipeline to detect skystones, which comprised of a blur, followed by a mask, then an HSV threshold, and finally a blob detector to locate the centroid of the black skystone. Although this pipeline worked fairly well for us, differences in lighting and the environment we are competing in may result in varying degrees of inaccuracy. To combat this, the DPRG suggested we used some kind of flash or LED in order to keep lighting of the stones consistent throughout different settings. However, this may result in specular reflections showing up on the black skystone, which will interfere with our vision pipeline. Another suggestion thrown was to detect the yellow contours in the image, and crop according to the minimum and maximum x and y values of the contour, allowing us to focus on only the three stones on the field and discard colors in the background. This suggestion is particularly useful, since any tilt of the webcam, slight deviation in the calibration sequence, or skystones lying outside the boundaries of the mask will not affect the detection of skystones.

### Next Steps

The most significant input that DPRG gave us during the presentation was the cropping of skystones based on the size of the yellow contour present in the input image, allowing us to detect the black skystone even if it lies outside the mask. To implement this, we would have to test an HSV threshold to detect yellow contours in the image using GRIP, filtering those yellow contours appropriately, and cropping the input image based on the coordinates of a bounding box placed around the contour. Although this addition is not absolutely necessary it is still a useful add on to our pipeline, and will make performance more reliable.

# Presenting to the DPRG

08 Feb 2020

Presenting to the DPRG By Bhanaviya, Cooper, Jose, Justin, Karina, Ben, Mahesh, Paul, Anisha, Shawn, and Trey

### Task: Present to the Dallas Personal Robotics Group about robot vision and Iron Reign

We reached out to the Dallas Personal Robotics Group to present. The DPRG are an organization in Dallas who have monthly meetings for robotics projects In past seasons, we've given them presentations about our seasonal progress in build and code. This year, we wanted to present again on computer vision, as this is something that they were very interested in, but we also wanted to give our actual presentation as practice for Regionals. Our presentation was advertised here.

We presented to an audience of around 15. The initial agenda is hosted on our website, but briefly put, we started off by showing them this year's reveal video, gave our judging presentation, demonstrated our robot, and gave them a presentation on our codebase, particularly vision and our usage of the control hub. You can read about the vision presentation in the Post 94 of our Engineering Section. We recieved and answered questions about everything spanning our design, our approach to this year's game challenge, and on our code decisions. The entire presentation went a little over 2 hours. You can find the link to a video of our presentation here. We're going to upload the video here soon. We also asked for feedback from the listeners, especially with respect to our codebase, and our journal organization

The main feedback we received for the journal was to keep our introduction at the very beginning of the engineering section shorter and more summarizing of the current robot design. We also recieved feedback with regards to over decision to CNC a journal cover - especially to use either a plywood, acryllic or something more metallic for an edgy feel. In terms of vision, we recieved feedback as to crop our skystones based on the contour of the image. A more detailed summary of how our vision presentation went can be found in post 94 of the engineering section.

### Next Steps

We are incredibly grateful to DPRG for giving us the opportunity to present and showcase our robot at their monthly meeting, and for giving us substantial feedback about our robot and engineering journal. Overall, our presentation to DPRG was a great experience for us to gain insight from a group of engineers on how to improve our robot performance and other factors of our overall standing at NTX Regionals. Regardless of how regionals goes for us, qualification-wise, we plan to reach out to DPRG later on as we move into the next stage of TomBot's build, which is creating a second, CNC-cut version of all of its subsystems.

# Final Weekend Before Regionals - Meeting Log

08 Feb 2020

Final Weekend Before Regionals - Meeting Log By Anisha, Cooper, Trey, Paul, Aaron, Bhanaviya, Karina, Justin, Shawn, Mahesh, Jose, and Ben

### Task: Use feedback from our presentation at DPRG and get ready for regionals

A couple hours ago, we presented our robot at the Dallas Personal Robotics Group (DPRG), and we received insight on not only our robot, but also on our presentation, codebase, and our engineering journals. With this feedback in mind, and considering that we have a week before regionals, Iron Reign returned to the RoboDojo to do what we do best - panic, cram at the last minute, and repeat. (For reference, all our subteams will go into detail about their version of the scramble before regionals in separate posts. This is just a broader summary of our meeting).

Today, the Code team mainly worked on improving driver controls, improving the implementation of a GRIP pipeline, and finalizing our autonomous path before regionals. Having just returned from presenting the works of our code-base at the DPRG presentation, the code team gained more insight on improving TomBot’s autonomous which will be their focus leading up to regionals.

The Build team worked on Plasti Dipping the bottom of the foundation grabber for better grip when dragging the foundation. Plasti dip forms a layer of rubber on top of whatever’s being dipped in it and makes it stickier. Unfortunately later on, problems were discovered with the turntable. There had previously been cracks in the turntable from previous driving incidents but now they had gotten worse and were interfering with TomBot’s wheels. Because of a part of the turntable hanging off, the chain was being interfered with and stopping the robot. This was one of the most important tasks to do because obviously, without a functioning robot, there ain’t gonna be dubs at the competition.

Before the problems with the turntable revealed themselves, our drivers got a decent amount of driver practice. They mainly focused on stacking as fast/efficient as possible. Towards the end of practice, they were also able to train new members of the team on driving. During practice, they also collaborated with the coders on improving the controls.

The editorial team mainly focused on adding some finishing touches to the judging presentation after getting some great feedback from the Deloitte, and DPRG presentations (both of which have separate entries in our team section). They also worked on creating a research poster and a timeline of our notable events this past season to display at our pit during regionals.

The design team mainly worked on improving the polycarb base of TomBot’s drive-train to CNC after regionals. To claify, our team is planning on creating a fully CNC-ed version of TomBot after regionals, regardless of whether we qualify to the next level of competition. As such, finalizing the CAD designs of each robot system will better prepare us to CAM these parts to create the next version of our robot. However, we currently plan to still replace the current polycarb base with the custom one since as mentioned earlier, our current base is not in the best shape. The design team also worked on creating a model of our pit design for regionals, which you can see down below. Having a well-organized pit benefits both us and any pit visitors, and regionals was no exception. Finally, they also worked on the CAM of the binder for both our Team and Engineering Sections, which will be custom-cut in aluminium using our CNC mill. For more information on the to-be CNC-ed binder, you can take a look at the “Engineering Notebook Binder CAD” post.

### Next Steps

Although we had a significant amount of progress today, there's still plenty to do. Over the next weelk, our main goals will be finalizing our autonomous, getting our binder and new polycarb base manufactured, and ensuring that our journals and posters are ready to print for regionals.

# Designing a New Build Plate

09 Feb 2020

Designing a New Build Plate By Ben

### Task: Model and CNC a new build plate for TomBot

The renowned architect Frank Lloyd Wright once said, “The longer I live, the more beautiful life becomes.” This, however, is not the case for our build plate. Throughout the course of the season the plate has seen extensive use and has endured much abuse, which can be seen in the large cracks forming on the plate. Although there are many temporary remedies, such as attaching plates to hold it together. These are not permanent solutions and not only appear bad, but can only temporarily reduce the problem, as more cracks will inevitably form.

The first build plate was cut from Polycarb on a bandsaw from a pattern. This process resulted in many imperfections and uneven cutting, subtracting from the sleek circular design. This second time around we’re going to completely CNC the whole plate, including the wholes for bolts and wires. Using a CNC ensures a greater precision and guarantees a higher quality build plate.

Cracks weren’t the only problems facing the first build plate. Drive testing revealed a major flaw with the design, the flaps that folded down from the plate were too short, causing the foundation to get stuck under the robot during matches. This is obviously undesirable as no one likes a robot who drags a giant plastic plate around the whole match. To fix this we just slightly extended those flaps on the model to extend past the height of the foundation. There was also another issue, the bolts that secured the omni-wheels to the build plate were difficult to access because they were to close to one of the Rev rails. To fix this we just slightly increased that distance but also had to ensure that there was enough length on the ends of the axle to comfortably secure the wheel mounts. Other, smaller, issues such as wiring holes were also solved by providing adequate space for wiring next to the expansion hub mount.

Above you can see an image of the completed build plate. To ensure accuracy one side was developed them mirrored. This removes any variability within the model and creates a symmetric object. The screw holes were created by imposing the turret mounts and rev rails from the previous robot model onto the current one, providing an accurate placement for each hole.

### Next Steps:

After completing the model, we will print the pattern on a large sheet of paper and verify the placement of all the components that are to be attached. If there are any inaccuracies they will be fixed. We then have to develop a CAM path for the CNC machine. Construction of the second robot will begin once the second plate is completed.

# Big Thoughts for xPansion

09 Feb 2020

Big Thoughts for xPansion By Bhanaviya

### Task: Put the budgetary and technical plans for the second MXP in motion

A long, long time ago, - well, 4 years ago really - alumni members of Iron Reign converted an old 90’s RV into a fully equipped Mobile Learning Lab with 3D-printers and FLL robots. Today, this vehicle is operated by Big Thought, funded by Best Buy and other donors, and taken to outreach events, by our team, Team 6832, where we introduce children with little to no STEM experience to robotics, and FIRST. We call this program the Mobile Tech xPerience and it’s been in service for around 4 years now! For reference, in the outreach events we take the MXP to, both our team and our sister teams participate, however, Iron Reign 6832 takes the lead in these events , from the set-up, to interacting with younger participants, and training Big Thought’s volunteers, to whom we show how we teach younger students block programming and 3D-modelling.

Our team specifically and Big Thought, a Dallas-based company, are programmatic partners of the MXP program. Through the success of this program, Team 6832 has proven that the concept of a STEM classroom works, and this has inspired other organizations, like the Girl Scouts of Desert Southwest, who have reached out to us about creating their own version of the MXP.

# Research Poster

09 Feb 2020

### Task: Create a poster encompassing all of our calculations from this season

From analyzing the friction coefficient of a variety of different materials, to calculating torque for our various robot sub-assemblies, and creating an equation for our tower-stacking abilities in our autonomous, Iron Reign has seen several different series' of calculations this season. Since these calculations are spread throughout our journal, we have compiled all of them in a single poster for us, and visitors to our pit to refer to at the NTX Regional Championship. Below, you can see how the chart is organized:

#### Torque and Gear Ratios

The first column covers the torque and gear ratios of TomBot's elbow and drive-train. You can read about these calculations in Calculating Torque at the Elbow and Calculating Torque at the Drive-Train which are posts 75 and 78 of the Engineering Section respectively.

The second column also covers torque and gear ratios but this one focuses more on the torque of the turntable and on the logarithmic spiral, a custom-made part by our team to linearly reduce the torque on the elbow. You can read about these calculations in post 79 for the turntable, and 45 as well as 76 for the logarithmic spiral.

#### Materials Testing

The third column focuses on calculating the friction coefficient of various materials like silicone oven-mitts and rubber cement, which we used for our gripper materials. You can find the math behind the decision to use these materials in post 66, 69 and 91 of the Engineering Section.

#### Extend to Tower Height

The final column focuses on a method we implemented in our drive-controls which uses trigonometry to automatically calculate the height needed for the arm to extend to place a stone at a specific tower height. You can read about this method in post 68 of the Engineering Section.

To take a closer look at these calculations compiled together, you can take a look at the chart in the very front pocket, or come visit us in our pits to see a much larger version of this math!

# Spicy Side Shields

10 Feb 2020

Spicy Side Shields By Jose

In order to increase the spice factor for TomBot, we need to custom machine our own side plates out of aluminum using our CNC. The design is pretty simple, just a plate with our team number, but there are some other features such as the curved top. This keeps the side plates from being sharp and add some aesthetic to the design. Also, since the team number is to be put out of the aluminum, the circles inside the '8' need some strokes to keep them in place. To follow the font used these were at a set angle and thickness as seen above. The stroke for the '6' was also thickened to add some support as previous years' side shields have proven this stroke to be weak. Finally, there are holes on the top corners for the alliance markers. The idea for these is that a rectangle with both a blue circle and a red square is screwed to the top and is spun to show the color corresponding to the alliance we are in while the other color is hidden behind the side shield(of the spicy variety).

### Next Steps:

With a CAM file of these (if not already obvious)spicy side shields already made we can immediately machine these on our CNC during our next meet as well as screw them onto TomBot. Since we have a circular chassis we will have to bend the aluminum, which shouldn't be too hard.

# Milling The Side Shields

14 Feb 2020

Milling The Side Shields By Jose, Justin, Trey, Paul, and Shawn

### Task: Mill the spicy side shields for the competition tomorrow

In typical Iron Reign fashion we are making our side shields the night before regionals, as with many other things. The paper side plates look too jank on our robot that we are trying to make look professional, so we are going to use aluminum instead (a post covering the CAD and CAM of these can be found in a previous post). Since we are still fairly new to using our CNC it took us a while to get started, we broke 8 3mm mills before any major portion of the first side plate was done. After a few hours we were able to complete the milling of the numbers which we can use to label things like CartBot. To finish quickly as we were getting impatient, we used a 6mm flat mill to do the outside contour, some loose placement of the aluminum led to it drifting as this final stage occurred, but overall it finished quite well! After all these hours of suffering we still had to mill a second one this took a while, but not as long since we were used to the procedure.

### Next Steps:

All that's left is to show off these aluminum side plates tomorrow at regionals!

# The Night Before Regionals - Code

14 Feb 2020

The Night Before Regionals - Code By Cooper and Trey

### Task: Fix our autonomous path the night before regionals.

Twas the night before regionals, and all through the house, every creature was stirring, especially the raccoons, and boy are they loud.

Anyways, it’s just me and Trey pulling an all nighter tonight, such that he can work on build and I can work on auto. Right now the auto is in a pretty decent shape, as we have the grabbing of one stone and then the pulling of the foundation, but we need to marry the two. So our plan is to use The distance sensors on the front and sides of the robot to position ourselves for the pull.

Another thing we are working on is a problem with our bot that is compounded with a problem with our field. Our robot has a wheel that is just slightly bigger than the other. This leads to drift, if the imu was not used. But since our field has a slope to it, it drifts horizontally, which is not fixable with just the imu. So we plan to use a correction method, where the distance from where we want to go and the distance to the block to create a triangle from which we should be able to get the angle at which we need to go and how far we should go to end up perfectly spaced from the side of the build platform.

Our final task tonight is to simply speed up the auto. Right now we have points at which the robot has to stop so that we don’t overshoot things, but that is fixable without stopping the robot.

### Next Steps

Mirror the auto onto blue side and practice going from auto to teleop

# Wylie Regionals 2020

15 Feb 2020

Wylie Regionals 2020 By Bhanaviya, Cooper, Trey, Justin, Karina, Aaron, Paul, Ben, Shawn, Jose, Mahesh, and Anisha

### Task: Compete at the North Texas Regional Tournament

#### Preparation

Breaking our packing-the-night-before streak, we managed to start the night before. It helped that we had the day before the big day off, and had a decent sized packing list. Over the course of our preparation, we had our side-shields machined, presentation practiced, journals prepared, and autonomous in feverish motion. More detail on our last-minute robotics onslaughts will be detailed in a separate post, but to summarize, we were (mostly!) ready to go.

#### Inspection

We passed! This is one streak we haven't yet broken which is bit of a relief.

#### Pit Decorum

Unlike last season, our pit was much better organized and planned this year, decked with Roman Galea, 4 posters, and of course, Ducky. The clean outlook of our pit drew several visitors, including teams who wanted to get a chance at trying on our helmets.

#### Judging

Compared out last two qualifiers, we had much more practice at our presentation this time around, and we tried to maintain a decent amount of energy during the real deal. Unfortunately, after being accustomed to longer presentations from our visits to DPRG and Deloitte (which you can read about in earlier posts!), we were cut short. However, we were able to address most of the things we couldn't cover in our first 5 minutes during the questioning period, and the dmeoing of our turret on TomBot - our most unique subassembly. The overall outlook we presented, however, could have been more charismatic, which was our main concern after the session.

#### Pit Visits

However, we were able to bring back more energy during our pit visits. We recieved three panels of judges for what we guess were Connect, Motivate and Innovate panels. We were able to direct our visits to the posters in our pits, and something we recieved a lot of attention for was our financial and technical plans for the second MXP, which you can read about in T-50.

Iron Reign: Bringing back Imperial Roman Energy since 2010

#### Robot Game

We will have a separate post detailing our match play-by-play and the technical and human errors in each one. Overall however, our match performance could have been better. During our first 4 rounds we experienced losses, finally scraping through and pulling a victory during our final two. However, from both an awards and rank perspective losing a match is never great since part of the picture is the consistent functionality of at least one sub-assembly. We did not employ the functionality as well as it could have been, with regards to our autonomous, tele-op and endgame and this is something we will be focusing on extensively going into the build of our second robot.

#### Awards Ceremony

By the time the ceremony started, our energy levels were not stellar, especially considering a lack of sleep from the previous night. However, our energy quickly skyrocketed when we first received a finalist for the Control award! Following this, we also recieved the Connect Award, which was exciting especially considering that our plans for the MXP and its expansion were put into drive this season. Then, we were nominated as a finalist for the Think award! And finally, as Inspire nominations were beginning to come up, we heard the announcement, "Inspire 3rd place goes to Team 6832 Iron Reign!" It was safe to say at that point, that Houston, we did indeed have a problem.

### Next Steps

This season being our 3rd moving into the World Championship, we couldn't have done it without our partners and sponsors, the DISD STEM Department, Mr Andrew Palacios, our principal, our sponsor Mr John Gray ,and the VIrani-Lux family! It's worth mentioning that this is the first time where 3 DISD teams, in addition to our own, are moving onto Worlds! Our main goals moving into Worlds will be preparing for our next competition, the UIL Competition for Texas, and in solidfying the creation of the second version of our robot. We will be detailing our post-mortems and these preparations in the upcoming few posts. Until then, see y'all in Houston!

# Driving at Regionals

15 Feb 2020

Driving at Regionals By Justin, Aaron, and Jose

Driving at regionals was unfortunately a learning opportunity for our drivers. In our first few matches, for some reason we couldn't get our robot moving; we faced code crashes, cables being pulled, and incorrect calibration during the transition from autonomous to tele-op. These issues combined with our weak autonomous (sorry coders), led to a very unimpressive robot performance for our first few matches.

When we finally got our robot working, our lack of practice and coordination really showed. The lack of coordination between these drivers and coders resulted in drivers relying on manual controls, rather than preset articulations. Our articulations were also very harsh and untested, some resulting in constant gear grinding, which pushed the drivers to use manual controls. This slowed down our robot and made us very inneficient at cycling. The presets that gave us the most issues were transitioning from stacking or intaking to moving. The intake to north preset, which pointed the arm north after picking up a block, practically tossed the stones we picked up out of our gripper. The stacking to intake preset, which raised the arm off of a tower and pointed it south, would keep raisign the arm up, stripping the gears. This made us rely on our very slow manual arm and turntable controls. A failure in the capstone mechanism caused the capstone to fall off the robot during matches. With all of these issues, we stacked at most three stones during a match; not nearly enough to make us a considerable team for alliance selection.

### Next Steps

We need to get consistent driver practice while coordinating with coders about the effectiveness of their presets. Many of our failures at regionals could be solved by driver practice. Our drivers being comfortable with the robot, both manually and with presets, would allow us to stack much faster and speed up the robot's in code to make our robot as efficient as possible.

# Match Play at North Texas Regional Championship

15 Feb 2020

Match Play at North Texas Regional Championship By Trey, Ben, Aaron, Bhanaviya, Jose, Cooper, Justin, Karina, Paul, Shwan, Mahesh, and Anisha

### Task: Compete in Qualification and Finals matches

Today Iron Reign competed at the North Texas Regional Championship with TomBot which was a mess, to say the least. But regardless of this, we were still able to win a few matches and qualify for worlds, which we should be able to do much better in. But regardless of this, we were still able to be in the winning alliance and the following are descriptions of the match play that made that happen. For reference, we have a separate post underlining the analysis of the qualifier that does not include match analysis. This post merely details how each one of our matches went, and we will have a future post discussing our drive issues at the competition.

Match 1(Quals 2)

We lost this match 51-148 because our robot contributed almost nothing to the alliance’s total score. What we did contribute consisted of two stacked blocks and parking. The other points in the match came from the other robot which stacked 4 blocks into a tower that later fell. However, their auto did the most for the outcome, racking up a total of 12 points. Overall, it was a pretty disappointing match that set the tone for the rest of the day.

Match 2(Quals 7)

At this point, most of us were thinking “this couldn’t get worse, could it?”. But we were very wrong. The reason why we lost this match 20-64 was that we were prevented from running the calibration sequence before the match. This plus a Vufora fail at the start of the match made our arm stuck at a 45-degree angle for the whole match. And on top of that, the other robot in our alliance disconnected. The only points we made were from moving the foundation out of the building zone and parking in the end game.

Match 3(Quals 13)

Continuing on the downward slope, somehow we managed to do worse with a functional arm. Losing this match 14-67, this may have been the lowest point of the day. Some of the faults with our robot in the match were being the only team without an auto, taking more than 10 seconds to pick up a block, repeatedly dropping blocks, and not parking in time.

Match 4(Quals 20)

After seeing us stoop as low as we did last match, the head judge, Freid, decided that he needed to talk to us and try to get us to do better. He gave us an inspirational speech about how we are going to have to live with the results of the competition for the rest of our lives and when we look back we would regret it if we didn’t give it our all. This helped us pick up our act and things started to get better. However, our robot disconnected mid-match and we lost 15-77.

Match 5(Quals 29)

Somehow the combination of 8 matches worth of time to prepare for the next match and Freid’s talk picked us up enough to win this match. With a lead of 9 points, we won our first match of the day 65-56. However, as seen by the low margin, this doesn’t mean our robot is never going to lose another match again. There were still many problems like how our auto still didn’t function and how the gripper still took to long to pick up blocks.

Match 6(Quals 33)

This was our last and most successful match of the day. We won 75-64, however, once again it should not go without mention that our alliance partners scored most of these points and stacked over half of the 6 stone tall tower. But it is also important to mention that our robot, and more importantly our drivers, preformed way better in this match than any of the other matches so we were clearly making progress.

### Next Steps

After reading a short summary of the disappointing match play we had at regionals, it would be easy for one to point their finger at a particular team involved in the physical build and design of the robot. However, these results are a result of a failure to collaborate between teams and preform within teams. For example, it was common to see builders and coders need the robot at the same time. The solution to this problem was building a second version of the robot so that coders have their own robot and builders have their own robot. This will reduce friction between the two teams and overall, increase the efficiency of the overall team which will put us in a better spot for worlds, where we will hopefully not lose 4 matches.

# Wylie East Regional Qualifier Code Post-Mortem

15 Feb 2020

Wylie East Regional Qualifier Code Post-Mortem By Mahesh and Cooper

### Task: Reflect On Code Changes And Choices Made During The Wylie East Regional Qualifier

Despite putting in lots of effort in order to pull off a working autonomous before regionals, small and subtle issues that surfaced only during testing at the competition as well as various other small bugs with our autonomous routine prevented us from performing well on the field. Trying to write a full autonomous in the last week before competition was a huge mistake, and if more time was dedicated to testing, tuning, and debugging small issues with our code base, we could have accentuated the theoretical aspect of our code with actual gameplay on the field. The issues experienced during the Wylie East Qualifier can be boiled down to the following:

### Improper Shutdown / Initialization of the Webcam and Vuforia

We frequently encountered vuforia instantiation exceptions after attempting to initialize the camera after an abrupt stop. We suspect this issue to have originated from the improper shutdown of the Webcam, which would likely result from an abrupt stop / abort. During later runs of our autonomous and teleop with multiple, more complex vision pipelines, we saw that attempting to reinstantiate Vuforia after it has already been instantiated resulted in an exception being thrown. This issue caused us to not play in certain matches, since our program was either stalled or its execution was delayed from restarting the robot.

### Disconnection Of The Webcam (Inability To Access Camera From Rev Hub)

Ocassionally when attempting to initialize our robot, we saw a warning pop up on the driver station which read "Unable to recognize webcam with serial ID ..." indicating that either the webcam had been disconnected or was for some other reason not recognized by the rev hub. On physical inspection of the robot, the webcam appeared to be connected to the robot via USB. The solution we came up with was to quickly disconnect and reconnect the webcam, after which the warning disappeared.

This issue prevailed in other forms on the competition field, however. Sometimes, during gameplay, when the webcam was accessed, the blue lights on the rim of our webcam would not light up (meaning that the webcam was not active), and our program would stall on skystone detection. This happened despite getting rid of the driver station, warning, and is most likely another result of improper initialization / shutdown of vuforia after an abrupt stop or abort.

### State Machine Issues

At the end of our autonomous, if the statemachine had completed, our robot would proceed to spin slowly in a circle indefinately. This unexpected behaviour was stopped using a stopAll() function which set all motor power values to zero, effectively preventing any functions which messed with the robot's movement to be ignored at the end of our statemachine's execution.

### Lack of Testing / Tuning

By far the biggest reason why we did not perform as predicted at the qualifier was because of the lack of testing and tuning of autonomous routines. This would include running our statemachines multiple times to fine tune values to minimize error, and debug any arising issues like those that we experience during the competition. A lack of tuning made the time spent on our skystone detection pipeline completely useless as our crane did not extend to the right length in order to pick up the skystone, a direct result of inadequate testing. All of the above issues could have been prevented if they had surfaced during extensive testing, which we did not do, and will make sure we follow in the future.

### Next Steps:

In the future, we ultimately plan to put a freeze on our codebase at least 1 week before competition, so that the remaining time can be spend for building, driver practice, etc. Additionally, we have agreed to extensively test any new additions to our codebase, and assess their effect on other subsystems before deploying them onto our robot.

# The Revenge of TomBot

16 Feb 2020

The Revenge of TomBot By Bhanaviya

### Introducing...The Revenge of TomBot!

A long time ago in a galaxy far, far away there was a robot named TomBot. TomBot was a circle, a spinning circle with a turret and an arm that could extend to glory. Sadly, his reign was not destined for longevity - his cruel creators cut it short before he could enrich the FIRST world with his greatness. But TomBot remained scheming for many, many days, and in his wake followed... The Revenge of TomBot.

That's right, we're building another robot! Even before our disasterous robot performance at the North Texas Regional Championship, we realized that our current robot, TomBot, lacked one defining one feature - class. Of course, only way to give a robot class is to bring a CNC Mill into the picture. The essential design of the robot will remain the same, but all parts, from the polycarb base to the the turntable mounts will be custom-cut and designed. Being able to custom mill our parts for every subsystem of the robot will also give us better control over the functionality of TomBot's design.

### Next Steps

We will still be using TomBot in its original version for testing our code and drive practice and their corresponding blog posts. However, from this point onwards, every build post in our engineering section will refer specifically to our new robot - The Revenge of TomBot, coming to theatres near you.

# Meeting Log Post Regionals

22 Feb 2020

Meeting Log Post Regionals By Anisha

### Task: Get back to work after Regionals

Alright kids, back to the usual grind now. As Iron Reign came back from regionals taking a lot away from it, we immediately got back to work because we still had a lot to do before being ready for UIL or Worlds.

Because one of our main weaknesses at regionals was autonomous, our coders came back even more ready than ever to start working again. They worked collaboratively to continue calibrating the code for the most efficient and consistent function of the autonomous and also continued their work in Vuforia so it could systematically detect Skystones. They will continue to code autonomous and calibrate each and every part of it for consistent function in the next couple of weeks and hopefully by UIL we’ll have a really fresh auton.

Since Tombot hung out with the coders majority of the time for auton testing, the builders mostly had a chill day, brainstorming new ideas on how some parts of the robot could be improved, so that when they build the new robot, it can be really clean. Some people even helped out by trying to organize different parts that were found all over the Iron Reign Headquarters so that in the future when building picks up again, people wouldn’t have to flip the premises upside down just to find a single part. Doing this also helped free up some space inside the house and it was here where we realized how much room it actually had.

The modelling team worked on the finishing touches of the build plate for the new robot so that it can be CNC'd ASAP. They also worked on modelling the other parts of the robot, making frequent visits to where Tombot resided for accurate measurements of the parts.

The editorial team worked on really reflecting on how our presentations went at regionals to analyze what the team can improve on. They also worked on figuring out what really worked for the award blurbs in the journal and what weren’t too clear because after all, the judges shouldn’t feel overwhelmed by the thick journals.

### Next Steps

Overall it was a pretty productive meeting considering that it was the first after regionals and we look forward to making rapid progress in the next couple of weeks. Although Houston feel like a long time away, we know they’ll arrive quicker than anticipated.

# Wylie East Regionals Post Mortem

22 Feb 2020

Wylie East Regionals Post Mortem By Karina, Bhanaviya, Jose, Justin, Ben, Cooper, Mahesh, Shawn, and Trey

### Task: Reflect on what went right and wrong at the regionals tournament

Iron Reign is so excited to be advancing to the World Championship. But there's no denying that across the board, we did not perform as well as we were expecting. Following the long day, first we feasted as per tradition. But then at a later time, we all sat down to discuss where things could have gone wrong, and found that in the weeks leading up to the regionals tournament, our team was already showing signs of underperformance. This is more of a long term issue that needs to be adressed, starting with in depth retrospection and a frank conversation among ourselves.

### Judging

Strengths
• We got 3rd place Inspire, 3rd place Think, and 1st place Connect which we can probably say was due to the engineering journal and our presenting skills since our robot performance was not stellar
• At this point we've had a lot of practice
• Handing judges materials from our presentation box at the right times
• Manual demo of the robot was successful
• We got across all of our more important presentation material before the 5 minutes were up
• Anything that we didn't get to during the five minutes we were able to cover in questioning
Weaknesses
• Since we were tired, we sounded kind of low energy and unenthusiastic
• At the same time, we were talking super fast trying to get through all of our content
• There was not much interest in our robot demo
Opportunities
• Rework our presentation to focus on the most important information (at this point we have realized we will not have enough time to talk about everything we have done this season)
• Make good use of the questioning time - invite the judges during the initial 5 minutes to ask questions about our team's highlights after the 5 minutes are up
Threats
• The 5 minute time restriction
• Lack of sleep bringing down our energy levels

### Pits Presentation and Conduct

Strengths
• Our pit setup was super clean with everything hidden away under table covers, and our posters and aquila
• We had people stationed at the pits at all times to receive any judges who had questions
• Some people were drawn to our pits because of our hats!
• People also came to our pits when we displayed match results on our monitor
Weaknesses
• We didn't have a good scouting strategy and the scouting team was also lacking sleep
• Not everyone got an opportunity to speak during pit interviews
• As far as we understand, we did not get any pit interviews from design focused judges (we need to sell this more during judging)
• Though displaying match results attracted people, it also created traffic in our pit area
Opportunities
• Have a working rotation of people at the pits, scouters, people watching matches, etc.
• Have a more active scouting team
• Redesign some of the older cross banners
• Still display match results but find a way to minimize the mess created by this
Threats
• Not having scouting
• Not making conversation with other teams/forming connections
• Poor pit organization
• Team members being off task in the pits

### Robot Performance

Strengths
• Physically, the robot worked alright
• The foundation grabber worked
• Parking also worked
Weaknesses
• We did not do a good job demonstrating the components that did work
• We had to slap Snapdragon down multiple times on a stone before it would snap closed over the stone
• The polycarb base plate is heavily cracked and needs replacement
• While a lot of our autonmous functions worked in theory, they were untested, and so naturally they did not work
• In one of our matches we lost functionality of the arm because a wire came loose
• Capstone was never deployed
• The mounts for distance sensor was bent
• Drivers were unfamiliar with autonomous set-up
Opportunities
• Design a new 3D printed part for the gripper that triggers the snapping motion more effectively than the bent metal strip we have now
• Cut and bend a new polycarb base plate
• Better wire management
• Adding LEDs - make TomBot look more snazzy
• Add more sensor-assisted capabilities, such as stone retrieval
Threats
• Having to overcome the bad impression we gave at Regionals for the World Championship
• All the teams who have a super fast wheel intake

While there is a fair amount of time before the World Championship in Houston, we don't want to get too comfortable. We will be using the list above as a broad guide as to we should accomplish for the championship. We will be increasing the amount of afterschool meetings we have to develop autonomous and practice driving TomBot. The UIL tournament will serve as a good place to practice in a very realistic setting. Additionally, we are excited to be creating TomBot V2 for the World Championship, and seeing if we can create as iconic a reveal video as the previous year's.

# CNC a New Polycarb Robot Base

24 Feb 2020

CNC a New Polycarb Robot Base By Justin

### Task: CNC a new robot base

We finished manufacturing our new base today, with very little difficulty, but a few flaws. The CAM was already designed so all we had to do was run the operations on the CNC. We drilled out the various sized holes, cut out the inner wheel slots and cable holes. Next was the groove along the edge to fold the side flaps along, which was a leap of faith because the orientation and position of polycarb on the CNC had shifted, which meant we didn't know exactly where we had it originally. We got it as close as we could remember and then ran the funky groove operation, which turned out to have pretty close to perfect alignment. Finally, we cut out the outline of the base, with flaps to fold down to increase the strength of the polycarb and to reduce flex. After looking at our finished project we noticed that the center slip ring hole was not cut. The hole is for general cable management and for the slip ring wires to reach the REV hub under the robot. We checked the CAM and found that it had been left out of the inner contours, so we made an operation for it, and cut it out separately. The build plate was finished on the CNC side of its production.

Next we used attempted a new way to fold down the side flaps to make the structural ring of the base: some tasty oven baked aluminum. The plan was to heat the aluminum above the working temperature of polycarb, then place the edge of the hot aluminum in the groove and use the edge to make a straight 90 degree bend. We found that aluminum and polycarb just don't transfer heat very well, and ended up with a hot piece of aluminum and cold polycarb. Our less preferred alternative solution was the classic torch bend, which was prone to bubbling if rushed. We took our time and were very careful about how much heat we applied, so we only ended up with a few bubbles. Regardless, this was a major improvement over our previous build plate.

### Next Steps

We are now ready to start mounting our subsystems onto the new base. We should first start with the drivetrain and the turntable. We also should document any errors we encounter with the new build plate, so we can fix them in CAM and make another more polished attempt. Our next CNC parts include boring out gears to fit on our big wheels, and cutting out more banana shaped mounts for the turntable.

# TomBot v2- Gripper Triggers

25 Feb 2020

TomBot v2- Gripper Triggers By Jose

### Task: CAD, 3D print and test new, better, and more aesthetically pleasing gripper triggers

Since our gripper follows a design similar to a slap-band it needs a trigger to close it, for too long we have used a bent REV beam with screws on the end to hit the nubs of a stone. This proved to be very inconsistent as proven by driver practice before and at regionals since the screws were too small of a plane to hit the stone, forcing the driver to be precise to hit close the gripper. To help with this some better triggers were CADed by using the CAD of a stone as reference. since there is a servo on the top of the gripper the triggers have to work around that so a loft was made between the bottom circles and the attachment point on the gripper. Some filets were used to clean up some edges and this was sent to the 3D printer. At first the triggers were too short so they were extended by 2cm later on.

### Next Steps:

With the print done we can test these triggers on the actual robots to test its viability on TomBot v2.

# Code Changes The Week Before Regionals

28 Feb 2020

Code Changes The Week Before Regionals By Mahesh and Cooper

### Task: Assess Code Changes During The Week Before Regionals

Numerous code changes were made during the week before regionals, the most signicant of which were attempted two days before regionals, a costly mistake during competition. Firstly, three different paths were layed out for respective position of the skystone (South, middle, and North), which involved rotating to face the block, driving to the block, extending enough distance to capture the block, and driving towards the foundation afterwards.

Next, we proceeded to add small features to our codebase, the first of which was integral windup prevention. We saw that when tuning gains for our turret PID, we experienced a build up of steady state error which was counteracted by increasing our integral gain, but resulted in adverse side effects. We used the following code to declare a range which we refer to as the integralCutIn range, and when the error of the system drops below that threshold, the integral term kicks in.

This code was put in to account for a phenomenon known as integral wind up; when the theoretical correction given by the system surpasses the maximum correction that the system can deliver. An accumulation of error results in more correction that can possibly be given in the real model, so to prevent this, the integral term is active only within a small range of error, so that the robot can deliver a reasonable amount of correction and avoid overshoot.

We continued to tune and tweak our autonomous routine Tuesday, making minor changes and deleting unecessary code. We also encountered errors with the turret which were fixed Wednesday, although the biggest changes to our algorithms occured in our skystone detection vision pipeline on Thursday.

On Thursday, code was added in order to select the largest area contour detected by our vision pipeline, and avoid percieving any disturbances or noise in the image as a potential skystone. We achieved this by first iterating through the found contours, calculating area using Imgproc.contourArea(MatOfPoint contour), keeping track of the maximum area contour, and using moments to calculate the x and y coordinates of the blob detected. The screen was then divided into three areas, each of which corresponding to the three skystone positions, and the final position of the skystone was determined using the x coordinate of the blob. A snippet of the code can be seen here:

On the final stretch, we added localization using Acme Robotic's roadrunner motion profiling library, which will be expanded on in the future. We also tuned and tweaked PID gains and ticks per meter. Finally, we added code to read distance sensors, which will be used in the future to detect distance to the foundation and follow walls. In addition we integrated the vision pipeline with the existing addMineralState(MineralState mineralState) method to be used during the start of autonomous.

### Next Steps:

In the future, we plan to use the features we added during this weekend to expand on our robot's autonomous routine and semi-autonomous articulations. These include incorporating odometry and localization to reduce the error experienced during autonomous, and even drive to specific points on the field during teleop to improve cycle times. In addition we can now use distance sensors to follow walls, further improving our accuracy, as well as determine the distance to the foundation, allowing for autonomic placement of skystones using the extendToTowerHeight articulation.

# Narrowing Down the Configuration of the New Vehicle

11 Apr 2020

Narrowing Down the Configuration of the New Vehicle By Bhanaviya

### Introducing MXP 2: Electric Boogaloo

As we have explained in earlier posts, Iron Reign is currently involved in the process of creating a new version of the Mobile Tech xPerience vehicle, a mobile STEM classroom which we, along with our programmatic sponsor Big Thought, take to various outreach events around the greater Dallas area. Given the success of the MXP through its lifespan, we are currently moving into the stage of creating a new vehicle, for which our team will be creating a virtual design plan as well as a financial plan.

We'd like to make it clear that this 2020-2021 season, our team is not claiming any credit for the construction or events associated with the original vehicle but instead for the creation of the blueprint of the second vehicle. Now that schools all over the country are restricted to virtual learning, the best way our team can bring STEM to students across our community who lack the access to it is to move ahead with the virtual design for the new vehicle in hopes of bringing STEM in mobile fashion to them when the current COVID-19 pandemic has cleared. As such, we created a virtual model as created above of te exterior of the new vehicle. Using this student-designed plan for the new MXP, the board of directors in Big Thought were able to get a sense of our ideas for the new vehicle. Using this design, Big Thought has moved into the next stage of design, which is allowing their graphic design team to use our 3D-modelled version of the MXP to create a sketch for the design on the exterior of the vehicle . For a better sense of what this design can look like, you can refer to the image below of the design scheme for the pilot stage of the MXP.

### Next Steps

Although our scope of action is limited under quarantine, access to STEM education and the technology associated with it has allowed us to move forward in designing the MXP. As such, our main focus will be narrowing down the quality of our current virtual design, and possibly move into designing the virtual floorplan. Similar to how many teams in the FIRST community have taken action to bring their knowledge of STEM to improve the quality of life in their community, our collaboration with companies like Big Thought to find a way to bring STEM to more students is our response against the current pandemic, and we hope to re-double these efforts over these next few weeks. From us here at Iron Reign Virtual HQ, we hope that everyone in the FIRST community stays safe!

# Summer Summary

11 Jul 2020

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.

# Co-Hosting the Caravan CAD Challenge

08 Sep 2020

Co-Hosting the Caravan CAD Challenge By Jose

### Task: Help design a CAD Challenge game, make a reveal video for the game, judge submissions, and give feedback

Over the summer, we collaborated with FTC teams 3658 and 6964 to host the first annual Caravan CAD Challenge. The idea of a CAD Challenge is to come up with a game to release to everyone participating. From there the participants will CAD a robot, just like they would for an actual FTC robot, and submit a brief summary of how the robot should work, if it were to be physically built. The game we came up with was Rafter Rave, which involved shooting pucks and climbing a rafter. We had a total of 29 teams sign up and 14 submissions. Following the deadline for submission, we judged each robot, ranked them based on several categories, and gave out awards. This was all revealed in a premiered judging video.

One of the challenges of this past season was that we didn't get an opportunity to close it off properly owing to the pandemic. Hosting a CAD challenge in coalition with other FTC teams allowed us to not only connect with other teams who may have experienced the same abrupt ending, but also allowed us to provide an opportunity to all participating teams to acclimate to the likely virtual season by modelling a robot. If the season does end up being virtual, this is something a good number of teams would need to have under their belt if they were unable to meet in-person just as our team could not. A CAD Challenge not only speaks to the design elements of an FTC season, but also the necessity to plan ahead and be flexible with a virtual environment as well as the need to connect with other teams in the FIRST Community.

### Next Steps

We hope that this CAD Challenge allowed all teams to better envision and address their engineering plans in this upcoming season as well as gave all teams an opportunity to form new connections with other teams around them. We wish all teams best of luck for the new season ahead!

# Connecting with Motus Labs

08 Sep 2020

Connecting with Motus Labs September 08, 2020 By Bhanaviya

### Task: Reach out to potential sponsors in light of the 2020-2021 season

Earlier in the summer, we learnt of an engineering group whose focus lies in innovative robotic gear drive designing and manufacturing. Prior to the start of this year's game season, we had sent Motus Labs an email in an effort to present our robotics program, team and robot to them and better understand how a professional robotics company operates (especially during the current pandemic). This week, we recieved a response back!

In the email response, a representative from Motus Labs conveyed their interest to meet with us and discuss opportunities for sponsorship and to try out their new gear like the M-drives. As the younger generation for robotics, we are interested to meet with professionals in the field - particularly since they are a Dallas-based group like our team is. We have currently planned to schedule a time with them in January of 2021 to discuss any potential opportunities for mentoring.

### Next Steps

We are incredibly thankful to Motus Labs for giving us the opportunity to discuss FIRST and our robotics team with them. As an up and upcoming robotics company in the Dallas region, we believe this meeting can help us further expand our robotics program from robotics groups to corporations as well. We look forward to meeting with them in these upcoming months, whether that may be virtually or in-person.

# FTC 2020-2021 Game Reveal

12 Sep 2020

FTC 2020-2021 Game Reveal By Ben B, Jose, Anisha, Shawn, Bhanaviya, Justin, Mahesh, and Trey

### Task: Watch the FTC Challenge Reveal event live

Game Reveal:

Today was a significant day; the FTC 2020-2021 challenge was unveiled. However, this year was very different from previous years, where we would attend a local kickoff event. Due to global circumstances, only a couple of members met in person while the rest of the team had to meet online. We joined a video call and watched the live event as a group.

One of the major issues we foresee is ensuring accuracy in the launching mechanism. The clearance for the highest goal is significantly smaller than that of the lower 2 goals. We will prioritize launching the rings into the highest goal since it awards 2 more points than the lower goal. Because of the small clearance, if the driver or robot made an error and the ring fell into the goal below it, the other team will be rewarded those 4 points. Accuracy will also be necessary for knocking down the power-shot targets during the endgame since each target will award 15 points. Missing one of these targets would be a waste of precious time during the game's final moments.

We also discussed how we would aim the launcher. One method would rely on a targeting system that would automatically horizontally and vertically align the angle of the launcher based on the robot's position relative to the goal. This would be done through code and would be controlled through a preset. A second method would be based around the GPS location of the robot. When a button is pressed, the robot would go to the shooting line directly across from the goal. By doing this, the launcher's angle could be predefined and the only action that would have to be done is launching the rings. The GPS position where the robot would have to travel would be calculated at the start of the game based upon the robot's starting location. The driver would have to go the approximate position and a preset would take care of the rest. The launcher could either be attached to an arm to angle the robot, or we could utilize our “superman wheel” which has been developing over the past 2 seasons.

This season also comes with some unique challenges, one of which is the playing field's size. With our current setup, we can only fit the field and cannot accommodate the goal and human players. Luckily for us, remote events will only take place using half a field.

### Next Steps:

Our next steps will be to conduct experiments with the rings to determine how we could construct a launcher. While we don’t currently have the foam rings, we can 3D print a prototype. We will also have further to discuss strategy and model different types of launchers.

# Printing Rings

14 Sep 2020

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

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

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

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

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

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

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.

# Dealey Presentation Preparation

28 Oct 2020

Dealey Presentation Preparation By Ben, Mahesh, Jose, Anisha, Shawn, Bhanaviya, Paul, Cooper, and Trey

### Task: Prepare for our presentation to Dealey International School

On Saturday October 10 we received an email from the robotics coach at Dealey International School. Dealey is a public school in North Texas that is a primary feeder into our high school, making this an important long-term recruitment opportunity. This year they have started 2 FTC teams for the 7th and 8th graders and would like our team to join a Zoom meeting and discuss what our team does, explain the FIRST philosophy of Gracious Professionalism, and answer any of their questions.

We decided it would be best to give a presentation about our team and FIRST then answer questions. Over the course of the week we have been discussing what we specifically wanted to present and put together a PowerPoint covering those topics. The presentation will cover how the Gracious Professionalism FIRST Tech Challenge operates robot competition, engineering journal, and both community and professional outreach. We will talk about the various award categories and what they mean, how to write an engineering notebook and what the team/engineering sections need to contain. We will then present an overview of the previous season’s outreach to Deloitte, Colin Allred, and DPRG. Then, we will discuss Iron Reign’s prototyping process and how we go from ideas to creating a CAD model to manufacturing with 3D print and CNC. We will then transition to the programming pipeline. The programming team will explain how all the components are connected, how they are coded, and how we use vision. The presentation will be concluded with a statement about the 10-year history of the team and how we hope they will be joining our program in the future.

Today we joined a zoom call after school to distribute slides, practice presenting a few times, and troubleshoot and camera and microphone issues. Each subteam will present their respective specialties and each person will present around 2-3 slides. We aimed to keep the presentation under 25 minutes to allow enough time for questions. After practicing the presentation a few times and rearranging the order to be more consistent, we felt we were prepared to present to Dealey tomorrow.

### Next Steps:

Each person will review their slides again tonight and before we present to ensure they are prepared. They will also make sure their cameras and microphones are still functional and ensure they have an appropriate background. We will also have to keep an eye out for the meeting instructions tomorrow.

# Dealey Presentation

29 Oct 2020

Dealey Presentation By Ben, Mahesh, Jose, Anisha, Shawn, Bhanaviya, Paul, Cooper, and Trey

### Task: Give a presentation to rookie teams at Dealey International School

Today we gave a presentation to rookie FTC teams about FIRST and our team over Zoom. We began by introducing ourselves individually by saying our name, subteam, and Townview school and then jumped into the presentation. The presentation took about 30 minutes and went well overall with some minor rambling. Afterward we split our team into breakout rooms with 1 programmer, 1 modeler, and 1 builder and evenly distributed the rookie team into those breakout rooms to ask questions. This was done to give each team member more time with each rookie member and allow them to ask more questions. After 20 minutes we ended the breakout rooms and answered any more general questions.

We also wanted to discuss followup opportunities to help the team in the future. We talked about a possible mentorship relationship where some Iron Reign members would go to the Dealey lab and help educate the team on different things like 3D modeling and printing or programming. This would be especially helpful to them because they recently got new 3D printing technology. We also discussed ways to do virtual mentorship through Zoom, which would also include educating them on different aspects of the engineering process. We agreed to let them discuss it as a team and let us know what would be best for them.

We felt that the meeting was very successful because the presentation was great and they had lots of questions and showed a lot of interest. We also spent some time getting to know them. In the end, we were able to reach about 20 of their members and had a few follow-up emails from the members.

### Next Steps:

We would like to eventually have some follow-up meetings with the team and discuss their progress and hold some programming, modelling, and journal classes.

# Recruitment Update

31 Oct 2020

Recruitment Update By Bhanaviya

### Task: Plan for sustainability goals

Owing to the ongoing pandemic, our recruitment goals are not similar to that of previous seasons. One of our bigger concerns is that it will be harder to teach rookie members about our program and FTC in a virtual setting - especially if we support 3 teams like last season. So, in order to ensure that our program remains sustainable, we opted for a new recruitment strategy where we consolidate our 2 rookie and 1 JV team into a single Junior Varsity team.

Structure-wise, Iron Reign will remain the varsity team, and as such, will be responsible for tutoring and assisting the other teams, as well as other organizational decisions. Then, Imperial Robotics, Iron Core and Iron Golem will now be consolidated into one JV team, and be the intermediate training ground. We believe that this team will serve as a good platform for the younger members on the SEM Robotics program to understand what it means to be on a FTC team. As of now, we anticipate that there will be 12 members in this team. So far, all of our recruits are motivated and show great potential for the future of our robotics program.

We will deliver tutoring updates and joint outreach events on this blog, as well as our usual content. Everything claimed in this engineering notebook will be Iron Reign (6832) only, and we will hold the same standard of separation to the other teams.

### Next Steps

For ongoing tournaments and eliminations, we will recompose new teams of the most promising members. Our goal has been to ensure that the Iron Reign Robotics program is sustainable for years to come and with our 2 teams, we are confident that we will be able to achieve this. By next season, we hope to either be out of the pandemic or have adopted a good ryhthm for working virtually and hope to expand our recruitment design.

21 Nov 2020

### 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

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

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.

# Deconstructing TomBot

05 Dec 2020

Deconstructing TomBot By Trey, Jose, and Cooper

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

This season of FTC has been quite difficult for most teams in Texas. As a state with high rates of COVID-19, It has been quite tricky to pull a team together to come in person to build and code a robot. It's for this reason that strategically speaking, it makes the most sense for us to use our old robot from the FTC 2019-2020 Skystone competition as a starting point for this year’s robot. With plenty of modeling and virtual designing, we should be able to make a functional robot within a few months. I guess that's one of the silver linings of the pandemic, that we are forced to design in Fusion 360 before any build is done. For this year's competition, we also gain an advantage from TomBot's turret which is a refined piece of hardware that we developed over the course of last year and would have brought to worlds if we could have gone. However, even though, it's from a previous season, it can still be used to selectively target, pick up, and shoot rings this year. So it's for all of these reasons and more that we decided to start our robot from the disassembled remains of TomBot

The first thing we need to do in order to have a robot that is based on TomBot is disassemble TomBot. That is what we did today. The disassembly was easy. All we did was take some of the less important components off which basically boiled down to the extendable part of the arm and the platform grabber thing plus a few other servos and gismos that we don't need. However, we made sure that we kept a few things that could prove to be useful in the future. We made sure to keep the pivot of the old arm because we can use it as a strong pivot point for a disk shooter. We also kept the turret since we did spend a lot of time on it last year and the technology is very useful for aiming the shooter that we plan to build in the future. The vision is to have a robot that automatically targets and shoots at the high goal or the power shot; however, we are going to need a lot of development to get there.

### Next Steps:

This post is short because there isn't a lot to say on the topic of disabling TomBot but there is a lot to say about the future of this year's robot. We have struggled greatly just getting to practice but this one achievement shows that there is hope and a chance that we will be able to have a good robot this year. We have plans including a flywheel shooter, a belt intake, a ring elevator system, and code developments to make last year's robot work well for this year's challenge. Now we just have to build them. Our next steps are to continue to develop these systems and finish them to implement on the new robot.

# FTC Legal Belt Sander

12 Dec 2020

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

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

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

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

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

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

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.

# Presentation Prep-Run

12 Jan 2021

Presentation Prep-Run By Anisha and Bhanaviya

### Task: Practice the presentation prior to the PvC Scrimmage on Saturday

Iron Reign will be participating in our first competitive event of the year at the PvC scrimmage. One of the submissions we needed for this scrimmage was a recorded version of our judged presentation. A stark contrast to previous seasons, the virtual nature of this year required us to be less extemperaneous at least when it came to presentations like this. We started out by building the actual presentation for this year and then assigning slides. Another difference was that our robot wasn't actually complete - since we were more used to building presentations for qualifiers, we usually do not anticipate the need to create a presentation with an unfinished robot (but there's a first time for everything!). As such, we needed to focus our presentation on the iterative nature of our design and on our future plans as the season progresses.

Next, we needed to gather the whole team to run the presentation. Another significant difference was how we actually ran the presentation. In past years, we would meet in-person to practice the presentation but this year, all we needed was to find a time to meet virtually to make it happen. One downside to this is that usually, we provide our judges prototypes of our earlier designs and unorthodox materials considered for the final design (oven mitts, ice-sube trays, etc.) but with the virtual format, this is no longer a possibility. On the other hand, this means that our live robot demonstration is no longer limited to the constraints of a judging room. Since we have access to our field while we present, we can show our audience our robot in action by making full use of the game elements such as the goal posts.

### Next Steps

Overall, we were able to successfully record our presentation. While timing is something we need to be mindful of, we expect to fine-tune this as the season progresses along with our actual presentation itself.

# 1/16 Build Progress - The first rings fly

16 Jan 2021

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

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

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

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

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

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.

# DPRG Virtual Meeting

26 Jan 2021

DPRG Virtual Meeting By Bhanaviya, Jose, Trey, Paul, and Cooper

### Task: Present our flywheel launcher to the Dallas Personal Robotics Group

Every year, Iron Reign presents our robot or standout subsystems to the Dallas Personal Robotics Group (or DPRG) - a group of professional robotics enthusiasts based here in Dallas. The DPRG are an organization in Dallas who have monthly meetings for robotics projects In past seasons, we've given them presentations about our seasonal progress in build and code. In an earlier post, we detailed the introduction of our ring launcher - the Flywheel Launcher. Initially, we had only gotten past the CAD design for the launcher, as well machining the plates and 3D-printing its nylon (which we needed to improve the 'gription' of the launcher. But today, we were able to begin the actual assembly and testing of launcher - and we were able to do all of it live on a virtual meeting with DPRG! A link to this presentation is here.

We presented to an audience of around 18. We started off by giving them an introduction into this year's FIRST Tech Challenge game, as well as what goal specifically we were intending to attain with the flywheel launcher. For reference, the flywheel launcher consists of a spinning wheel sandwhiched between two custom-machined plates and as it the robot intakes rings, the spin of the wheels ejects rings with enough force to get it into the goal post. We started off by explaining how the CAD of the design progressed. Considering the multi-staged nature of this subsystem, it required 3 CAD sessions total and we were able to show DPRG each of these stages as well as how we went about the custom-machining of the parts.

Next, we were able to discuss the ballistics calculations that this design inspired. In our previous two posts, we discussed the iteration of an equation we developed to model the inital velocity, muzzle velocity, RPM, and rotations/seconds of a ring launched from this flywheel, taking into account its circumference in order to determine the ideal angle of launch as well as how the PID values of the HD HEX motor on the flywheel needed to be tuned. Below is the slide from our presentation containing these values. Our ideal range for the horizontal distance of the robot is between 2-2.5m; this being said, we calculated all our values based on this range. 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)) While we couldn't perform a sanity check of these calculations at the time of their presentation, we found values from the average velocity of a frisbee to test the accuracy of our values.

Finally, as this was ongoing, Paul and Cooper were able to assemble and perform the first-ever launch of our flywheel launcher! Since this subsystem had already been pre-modelled with all the necessary plates pre-machined, they were able to complete its assembly and test within the 40 minutes of our presentation. While the actual video of the first launch can be found on DPRG's video of the presentation, a video of a launch recorded soon after our meeting can be found here:

At the end of this presentation, we were able to get tons of valuable feedback from DPRG - particularly about how to improve our testing process of the flywheel launcher. We anticipate that the equation we modelled earlier and those values are subject to change as our robot design becomes more sohpisticated and as we add more sources of error to the machine itself - in order to eliminate these confounding variables contributing to the launch and isolate the one that has the most effect (which we predict is the angle of launch itself), DPRG suggested that we use a Design of Experiments chart. A Design of Experiments chart is a system of organization that can be applied to virtually any machine to reflect the different variables that might affect its efficacy. More specifically, it identifies which variable had the greatest impact on a function and rank the variables in order of their influence. Applying a DOE to our flywheel launcher calculations would streamline our ability to identify which variable could have the greatest impact on our launch as we vary it by distance of launch, angle of launch, type of motor used, etc.

### Next Steps

We are incredibly grateful to DPRG for giving us the opportunity to present our team and flywheel launcher to them for feedback. Our immediate next steps include continuing the testing of our flywheel launcher to see just how much we can improve driver control. Part of this includes fine-tuning our calculations and as we get deeper into the testing phase, we can check whether these equations work as well as they do in theory by using the DOE to identify any confounding variables. We plan on sending DPRG an updated version of our equation and calculations as we continue to periodically test and fine-tune our launcher.

# RingSlinger 9000 Build Progress

27 Jan 2021

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

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

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

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

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.

# Flywheel CAM

31 Jan 2021

Flywheel CAM By Trey and Justin

### Task: CAM and cut our flywheel model

Today we CAM'd the flywheel model and cut it out on the CNC. This was our first CNC project this year in the new house, so we spent a lot of time setting everything up. We first drilled all the holes and screwed the plate down, then proceeded with the pattern contour. We discovered issues with our CAM G-code settings: The CNC started cutting material too high above the plate, and before each operation it would raise the spindle all the way to the top and hit the emergency stop switch. We checked the G-code export settings and found that the safe retract height was set to the home position of the machine, not the clearance height we set. This was probably a default fusion setting that we didn't fix on the new computer. We fixed the stock height, the height of the material that the machine starts cutting out of, which was set to have an offset from the model. In the future we will be sure to make our models the exact thickness of the aluminum and use no stock offset.

After solving these issues we continued the pattern contour with no problems, but realized that it would have been a better use of time to cut the outside contour first. The pattern contour is very time-consuming, and if something goes wrong afterwards we will have wasted all that time. We learned our lesson when the cutting surface slipped during the outside contour, and we ended up with a line in the flywheel. This will affect the balance and how well the flywheel spins, but can be compensated with different sized screws. This could have been easily avoided if someone had checked to see if the screws were tight, but we learned to check in the future.

### Next Steps:

Ultimately this project got us comfortable again on the CNC. We broke a few bits trying to get the speeds right and rediscovered things that we need to pay attention to, like what bits to use, model stock, G-code presets, and making sure the cutting surface is actually tightened down. We will be able to more efficiently machine the rest of the launcher now that have experience with cutting speeds and settings that work. Next we will work on finishing the launcher, cutting motor mounting plates and the main structure of the launcher assembly.

# Ringslinger 9000 Overview

31 Jan 2021

Ringslinger 9000 Overview By Trey

### Task: Describe the construction and development of the flywheel ring shooter

The launcher of any robot is a central part of the design, just like the intake which is why we developed the two systems separately in order to achieve the best design for both. We also used our knowledge of shooting systems and previous prototypes to develop a mechanism that is both reliable and accurate. This post will detail the function and overall process of building the Flywheel shooter and its parts. It is not a post outlining specifics, the specifics of each set of parts are outlined in their respective posts.

### Build Breakdown:

The overview starts with a mechanical build breakdown. The best way to look at the design of the shooter is in levels. From top to bottom, there are the mounting, driving, and ring levels. The lowest level is where the mounting hardware sitsThis is where the shooter attached to the arm which sits on a pivot in the far back of the robot which changes angle depending on where the ring needs to be shot. The second level is the driving level where the motor, pulleys, and timing belts sit. Currently, the motor that is mounted is a 3:1 REV UltraPlanetary motor that can spin its sprocket at 1,727 RPM which drives the wheel in the ring level at a 1:1 ratio by another sprocket driven by the belt between the two sprockets. The last and final level is the ring level which is where the ring is actually gaining momentum to travel through the air. The rings are loaded into the holding area where they are pushed by a servo-driven arm into the wheel that both speeds up the ring and starts it turning as it travels down the barrel. After traveling the curved section, it reaches a straight portion where the ring is allowed to travel forward to help adjust its path to the target, ensuring a more accurate system. And that’s it. It’s a very basic construction. Boiled down to the simplest form, all that is happening is a wheel is spinning and accelerating a ring to get it to fly. The rest is just parts that are added to make it actually move.

### Manufacturing:

Creating the shooter in real life is also quite complicated. Due to the pandemic, we are doing a lot more design in fusion 360 which allows us to take a more custom approach to building systems. The majority of the launcher is custom with 9 3D printed parts and 6 CNCed parts. Each one was specially designed to serve its purpose. The majority of the 3D printed parts are the spacers that separate the 3 CNCed plates, housing each level. There is also a custom spacer for the motor, NinjaFlex center for the flywheel, and push rod for rings which are all custom designed and 3D printed. The CNCed parts also include the plates on the top and bottom of the flywheel and the slide mount for the motor. The CNCed parts should have a post detailing the CNC process and there should also be a modeling breakdown for the spacers and other 3D printed parts.

### Testing and Calculations:

The last thing that should be spoken at least briefly of is testing and flight prediction. The overall goal is to be able to pick up rings and automatically know where to point the barrel and with how much speed to launch a ring to automatically score it. We want to be able to let vision keep the barrel on target the whole time so we can quickly cycle rings. To do this we need to both have an accurate system and know where the rings will land depending on the situation. Making an accurate system is accomplished by rigorous testing to see how closely clustered a set of consecutively fired rings hit a target. We do this by setting the robot a fair distance from a foam board and monitor where the rings it launches hit and then show how close the shots are. The closer the better. We conducted our first round of tests a few days ago with ok results. A photo of the results is above. We are hoping to do better than this in the future so improvements need to be made. We also need to be able to calculate where the rings will land and are doing this with projectile and ballistics physics calculations which can be replicated in the code to target the shooter. More on that in posts that cover it.

### 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.

# Programming Session 1/31

31 Jan 2021

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

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.

# Pink v. Cyan Remote Scrimmage Code Post Mortem

01 Feb 2021

Pink v. Cyan Remote Scrimmage Code Post Mortem By Cooper

### Task: review the code changes needed from our latest scrimmage

After looking over the progression of matches of the scrimmage, it is obvious that there needs to be some code changes. I’d like to go over in detail those issues, and how they’d be solved.

First off, the issue prevalent when the robot turns in auton- the PID loops aren’t tuned. The PID constants were from last year, and with the robot arm being much lighter right now, the kP was ridiculously high. Both the base and the turret overshoots really bad when doing right angle turns. While I could go into the specifics of how we tune our PID loops, I’m instead going to explain why we aren’t going to fix it yet. It's really simple-- the launcher is going to be as heavy, if not heavier than the arm of last year. At the very least it's going to be different, which means if we tune the PID right now, we’ll have to tune it again very soon when the launcher is mounted. Therefore, we will tune it then.

Next, and maybe a bit more broad this time, auton is busted. It's obvious from the many auton runs that ended up with the robot wildy veering off course. This is caused by the fact that for our long run to the other side of the field uses a wall following, and that I made and tuned it in 30 mins before the scrimmage. To fix this, we need to implement a more sensor-fusion based model, including vision and odometry to check each other off on, or improve the distance sensor’s reliability.

During teleop, it is evident that having wobble goals get stuck on the robot was not good. While this is another thing that is subject to change, the appropriate solution for this would have been making an articulation that puts the arm at the correct position, and having some logic in the call to the toggle articulation to prevent it if the arm was below a certain limit angle.

### Next Steps

Fix all of the items listed in this post.

# DPRG Virtual Meeting 2/9

02 Feb 2021

DPRG Virtual Meeting 2/9 By Bhanaviya and Mahesh

### Task: Present our flywheel launcher to the Dallas Personal Robotics Group

2 weeks ago, Iron Reign presented our Ringslinger 9000 - our launcher, for brevity - to the Dallas Personal Robotics Group. For reference, Dallas Personal Robotics Group, or DPRG, are a group of robot enthusiasts and engineers who host weekly meetings to discuss personal projects in robotics. This meeting, Iron Reign had the opportunity to present our progress in build, code and documentation to DPRG based on the feedback we receieved from them from 2 weeks ago. You can find a link to our post detailing our first presentation with them this season here.

We presented to an audience of around 20. We started off by giving them an update of our trajectory calculations. The last time we presented, we showed DPRG the initial version of our calculations which were meant to depict the trajectory of a ring launched from the Ringslinger 9000 when it was a certain distance away from the goal posts. Both the changes to our initial calculations as well as our takeaways from the first DPRG meet are in an earlier post in the Engineering Section of our journal. Using feedback from DPRG on our initial equation as well as what we could do to make it more accurate, we were able to generate a new set of calculations and equation, both of which we could show to DPRG. We also provided them with links to the corresponding blog posts which you can find here.

Next, we focused on showing them the code and build changes that occurred over the week. Since the last time we presented, we could show DPRG the assembly of our launcher as well as its very first launch, this time, we could show them multiple test shots of the launcher we had recorded over the week in slow motion. You can see one of the videos we showed to DPRG below. DPRG members provided us with suggestions to improve the trajectory of our launcher including checking for ring damage and showing our equation and calculations to an expert in the field for review. One of the more fun takeaways of this meeting was that we were also able to put our various ideas for a launcher name up for vote and we settled on the Ringslinger 9000 thanks to input from DPRG. All references to our launcher will, from this point onwards, be referred to as the Ringslinger 9000.

### Next Steps

We are incredibly grateful to DPRG for giving us the opportunity to present our team for feedback. Our immediate next steps include continuing the testing of our flywheel launcher to see just how much we can improve driver control. Part of this includes ramping up our testing progression as we get closer to the qualifier. We plan to meet with DPRG after our first qualifier to present our progress and performance as we seek to improve our robot and launcher capabilities.

# Intake Iterations Summary

03 Feb 2021

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

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

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

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

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

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.

# Fixing Odometry

10 Feb 2021

Fixing Odometry By Cooper and Mahesh

### Task: find and fix old odometry code

This year, more than the 2 previous years, odometry plays a critical role in our solution while vision is on the fritz. This is due to the fact that we plan to do continuous targeting, which requires a way to know the distance and angle to any given target. Our original plan was to use VuForia, but after preliminary testing gave mixed results, we decided to review our other options. Odometry seemed fitting since it's a lot more stable. Plus, if we find that it drifts, we can always add live offsets through a sensor-fusion based model.

So today we went through the catacombs of the code and dusted off some 2-3 year fine aged code. Uncommenting the code and adding some of the variables to dashboard, we started up the robot to be met with the variables in dashboard going absolutely wild. They seemed to be rapidly going from -infin to infin. After a bit of head scratching, a couple of Hmms, at least one sip of coffee, and no fewer than 3 “A-Ha!” moments (as opposed to “ABBA!” moments), we fixed the run-away. And, get this, the code just worked. They do say 2018 was a good code year, after all.

With that in the bag, we started working on the supportive code. First the getters and setters, then a getDistanceTo() method. These were all the methods that will be useful to us for continuous targeting. However, we took it a step further, and made a driveToFieldPosition, and a supplementary method getBearingTo. While not validated as of writing this, when working it will help us both in auton and in demo.

### Next Steps

Test reliability of odometry over long durations of time, and validate the driveToFieldPos method.

# Adding Margins Of Error To Desmos

13 Feb 2021

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

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

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

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

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

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

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

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

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

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

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.

# Recruitment in Senior Season 2021

06 Jul 2021

Recruitment in Senior Season 2021 By Bhanaviya

### Task: Decide plans for expansion and recruitment strategies

For the first time in 11 years, Iron Reign had a no-recruitment year, owing to the pandemic, and the difficulty of introducing new recruits to an event which is not usually remote. However, now that all of our members are upperclassmen and since this upcoming season - Freight Frenzy - will be the final one for most of our team members, we have to ramp it up (puntentional). So, this summer, we have been discussing new methods to increase recrtuitment and the following participation as our school year transitions from remote to in-person.

For all of its lifetime, Iron Reign has been a school-sponsored program. This is a tradition we intend to keep and we've specifically been looking at recrtuitment efforts in our home school - School of Science and Engineering - as well as our sister school - School for the Talented & Gifted. Over the summer, TAG is having a club fair which we currently have plans to participate in. Following this, we plan to go the traditional recruitment route with posters galore. Mainly, we want to ensure that before our graduation, we are able to set up a proper feeder system to keep our program running past our (high school) life-time.

One major difference is that this year, we plan to go with only one feeder team - FTC 3734 - rather than 3 feeders, which has been our practice in yearss where we are pressed for recruitment. This mostly has to do with how sustainable we can keep our group - fewer teams means we are less concerned about resources and instead can work to individually improve our two teams and expend energy on smaller elements of each time. This does mean, however, that we will be taking on fewer personnel and therefore, our "tryouts" process could be more competitive based on how much interest we've garnered. This process generally consists of putting new recruits into a smaller "group" (not necessarily a team) and looking at their ability to work one another and/or their willingness to learn new skills.

### Next Steps

With school starting in a week, our primary goal is to get the robot in working condition for robot demo for the TAG club fair this week, and then build up an interest form that we will put on our website and display to school-based websites the underclassmen use. Based on how the form fares, we will make a more concrete decision on how many members we want to take and what kind of sub-skills we need for both the growth of this season and the next one. Our ultimate goal (puntentional part two) is to ensure that our team can be sustainable past our generation. As our time on the team and program ends, we want to ensure that we are adequately set-up to welcome and help acclimatize new members so FIRST Tech Challenge and our program is as fulfilling for them as it was for us.

# Wattever Meeting

31 Jul 2021

Wattever Meeting By Trey, Anisha, Bhanaviya, Shawn, Ben, Mahesh, and Cooper

### Task: Meet with the team Wattever and give insight

This Saturday, all of Iron Reign met with team 16296, Wattever, to discuss how the Iron Reign robotics program works and give them a detailed insight into how they can improve their own operations. The members of Iron Reign gave them a quick tour of our space from the first floor to the second and then had a long conversation on the base floor shortly after. We answered questions and offered insight into how we operate. Our main advice consisted of making sure that every team member gets a chance to have a voice in the journal, to prioritize custom parts, improve operations in CAD, etc. We tried to help them in ways that might not have been available for an online meet, seizing the opportunity of meeting in person. We gave them insight into how our program works. That meant that they got to see what works and what doesn’t which gave us an opportunity to show good examples of Iron Reign’s ability to innovate and quickly prototype but also show them how we are a bad example of organization and time management. With this, they could imagine what the “perfect” FTC team looks like and better make decisions to become ever closer to it.

Of course, any in-person meeting is a fantastic opportunity to bond and share common interests and this inevitably happened. The conversation in the main room of the workshop was as engaging as it was insightful. The teams talked together for what seemed like minutes but was in fact, several hours. From this meeting, Iron Reign certainly strengthened its relations with Wattever and had some fun, improving team morale and helping a relationship that contributes to team sustainability.

### Next Steps:

With this being a pre-season event, there isn’t a straightforward next step. We would like to have another meeting with Wattever at some point and continue to grow our relationship with them. In addition, our summer projects need to continue so that we can be better prepared for the new season when it starts. Other than that, the watters ahead look clear!

# Club Fair 2021-2022

05 Sep 2021

Club Fair 2021-2022 By Bhanaviya

Thank you for your interest in Iron Reign robotics! Please fill out the following interest form. Check out the rest of this article for more on our robot!

# Future Plans For Programming

11 Sep 2021

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

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.

# Code Cleanup

12 Sep 2021

Code Cleanup By Cooper and Mahesh

### Task: prepare code-wise for robot in three days

To better prepare for “robot in three days” (ri3d for short), we decided to get ahead a bit and resuscitate the code base. After making sure everything was up to date, we set off on cleaning it up. Going through it, we simplified the movement pipeline, got rid of unused variables, and generally worked on formatting. After which came the big part of the day; getting rid of Ultimate Goal-specific code.

This was tough for one main reason. The aforementioned movement pipeline is the same lower-level pipeline we’d been using for years, with some new code on top of it to act as a higher-level interface for movement. The purpose of which was a rather basic field-relative movement method. However even basic, it was extremely useful last year in Auto, and would make sense to keep. All well and good, but since the entire method was built on the old pipeline, it was designed for 2 wheel differential steer robots. Go all the way back to rover ruckus, and you can see even back then we were using 2 big wheels instead of mechanums.

Therein lies the problem. The ri3d chassis that we had pre-built uses mechanums, and the 5-year-old mechanum code that was left in the codebase was certainly off. So, we decided to try and fix said code to see if the pipeline would be compatible. Surprisingly, after about an hour of head-scratching, not only were we able to get it to move in tele-op, but auton as well. This boils down to the fact that in essence, we’re still using the mechanums like normal wheels. But for ri3d, it was good enough.

### Next Steps:

Integrate strafing into the pipeline such that the higher level move code can use it intelligently.

# Chassis Brainstorming

02 Oct 2021

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

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

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

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

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

# Meeting Log 3/12

12 Mar 2022

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

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

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

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

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

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

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

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

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

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.

# CONNECTions through the season

02 Apr 2022

CONNECTions through the season By Anuhya, Bhanaviya, Shawn, and Ben

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

This past year, we connected with a lot of professional engineers that helped us optimize our robot performance and capabilities. We got a lot of helpful advice from professionals in our field as well as opportunities to learn more about the field itself. This way we have some insight as to what we will be able to do in the future, when we’re no longer in FTC.

#### Dallas Personal Robotics Groups

21 adult mentors, 4 hours total
In the first zoom session, on December 6, 2021, we identified the gap in time between when the swerve wheel changes direction and spins. This was also the first live demonstration of the robot as well as the expanding mode, or the “reach”. In the second zoom season on February 8, 2022, we discussed solving the tipping over problem through the usage of counter-balances, training wheels and limiting wheel acceleration.

#### Texas Instruments

1 test engineer mentor, 1 hour total
On November 24, 2021, we showed the first drive of our hybrid differential-swerve robot and we discussed tensile tests to improve our robot’s durability.

#### NVIDIA

1 adult mentor, 1 hour total
NVIDIA is a computer systems design services company. On January 17, 2022, we discussed image processing, radar and object detention to improve the distance sensor feature on our gripper with them. The distance sensor feature auto-dumps the bucket.

#### Monash Nova Rover

2 adult mentors, 1.5 hours total
Monash Nova Rover is a college robotics program based in Monash University, Australia. On January 31, 2022, we discussed unpressurised wheel/tire designs. Their wheel design inspired our current gothic interleaved arch design which is made entirely out of custom 3D-printed parts.

#### US Congressional Representative

32nd District TX Rep. Colin Allred
On January 27, 2022, we discussed FTC and Iron Reign’s work in STEP education and we urged for the passage of a bill which improves access to STEM programs in rural education districts. This bill was passed this year and Iron Reign was attributed as one of the reasons Representative Allred voted to pass.

#### Bell Helicopter, Lockheed Martin, Design Connect Create

4 adult mentors, 3 hours total
On July 31, 2022, we worked with engineers from these companies and delivered a joint presentation about avenues to STEM careers through school to 40 high school girls.

#### Deloitte

2 adult mentors, 0.5 hours total
On February 23, 2022, we discussed our game strategy and sustainability plan for the current season. This was also the first time our rookie members communicated directly with engineers through our program.

# Meeting Log 4/2

02 Apr 2022

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.

# Last Practice Before UIL!

07 Apr 2022

Last Practice Before UIL! By Anuhya, Georgia, Bhanaviya, Ben, Mahesh, Gabriel, Aarav, Trey, Shawn, and Leo

### Our Last Meeting Before UIL!

This marks our final competition of the Freight Frenzy season.

#### Getting in our final drive practice

Trey, Georgia, Ben and Gabriel got in their last couple hours of drive practice at the RoboDojo. Knowing this was our last time we would be able to practice in our home field, we made sure that we knew exactly what we would be doing at UIL. Mahesh was cleaning up the code, tuning up the arm and getting it so that when you press dump, it goes up and then goes down so it doesn’t run into the shipping hub.

#### Yesterday's meeting

Yesterday, Trey and Georgia got a lot of drive practice. They tested the robot with the sizing cube to make sure that it fits within the regulations. Trey also installed a grasp rivet on the bucket which allows the distance sensor wire to go through the pivot point so it doesn’t tangle and so the bucket’s auto dump works. The bucket’s auto dump wasn’t working because the distance sensor’s wire couldn’t be plugged in without getting tangled. The grasp rivet helped the wire go through the pivot point without it breaking, so we could use the distance sensor seamlessly.

#### Packing for UIL

We had to pack up all the necessities for the UIL trip. We worked on ensuring that we were fully prepared for success at the UIL competition and we tried to foresee any unexpected circumstances and prepare for them. We were fully ready to stock up the bus tomorrow morning before heading for Houston.