Articles by tag: think

# 2018 Worlds Day One

2018 Worlds Day One By Ethan, Evan, Kenna, Austin, Charlotte, Abhi, Tycho, Karina, Justin, Janavi, and Shaggy

### Task: Present and play first match

It was a dark, surprisingly non-humid, Houston morning. Tarballs blew through the parking lot from dusty, abandoned oil refineries down by the bay. One by one, phones went off in the hotel looming above the lot, waking up their inhabitants. In these rooms, their occupants dusted off their Bucees wrappers and Iron Reign shirts and stumbled to the tournament.

The first day was relatively short, with a lot of waiting. There were two main parts of the day, presentation and first match.

##### Presentation
Our presentation went well. We were able to get all of our information across effectively and we got in-depth questions from all of the judges (including our first question about coding all season). Throughout questioning, we were able to hand off questions so that no individual member dominated the questioning time.
One problem we had with the presentation was that the rooms were constructed within the competition hall with fabric. This made it so that sound did not carry very well within the rooms, and that sound could carry over from other rooms, so the judges had difficulty hearing us at some points depending on the speaker. Despite this, we're confident that the majority of the information came across.

##### Game 1
We won this game, 319-152. Both us and KNO3 outdid ourselves in robot game, scoring more in autonomous that our opponents did the entire match. In telop, we lagged behind, but there was already no catching up for our opponents.

# 2018 Worlds Day Two

2018 Worlds Day Two By Ethan, Evan, Kenna, Austin, Charlotte, Abhi, Tycho, Karina, Justin, Janavi, and Shaggy

### Task: Compete in robot game

It was the beginning of Day 2. Our members rolled out of bed, covered in old Fiesta receipts and Chipotle wrappers. One by one, they stumbled onto their charter bus, unprepared for the new day.

##### Game 26
We lost this match, 213-401. Our robot wasn't working reliably on the field and we were still debugging issues. Because of this, there was only one true competing robot on blue, and it couldn't keep up against two bots.
##### Game 34
We won this match, 428-172. Both us and our partner had high-scoring autonomii and teleop, and we were able to score the relic while our opponents weren't.
##### Game 55
We won this match, 484-405. We were about evenly matched, but we were more than pushed over the top with the 180 penalty points from the other team. However, we were partnered with RedNek Robotics, the top team at the tournament, so we should've done better than a slight penalty win.
##### Game 73
We won this match, 459-441. At this point, we had gotten in the groove and were actually competitive in the robot game for once. We got 200+ points in autonomous *and* teleop, a feat that we'd never done before. While our competition was equally matched, we had a slight initial advantage that was never overcome.

We also entered the block design competition this day. AndyMark released a form on their Twitter a few weeks before to enter, and we requested 64 blocks. We settled on a throne design, using a bread carver to add more details. We had teams from all over gravitate to our pit to sit in our chair and get help in their own designs.

# 2018 Worlds Day Three

2018 Worlds Day Three By Ethan, Evan, Kenna, Austin, Charlotte, Abhi, Tycho, Karina, Justin, Janavi, and Shaggy

### Task: Compete in robot game

It was the beginning of Day 3. We awoke, covered in metal parts and broken servos, took our sleeping-caps off, and went off to the Houston Convention Center.

##### Game 82
We won this game, 467-442. This was personally, our best game. We went against the BLUE CREW and won, which was no small feat (they went undefeated until this match). On top of that, we completed a full cryptobox, which we had never done before.
##### Game 99
We lost this game, 254-333. Our autonomous didn't work well, so we lost a good amount of points. As well, we just couldn't keep up with the blue alliance in TeleOp.
##### Game 116
We lost this game, 431-492. Like the last, we just couldn't keep up with our opponents.
##### Game 131
We lost this game, 232-408. Our phone fell off our robot at the beginning and disconnected :(.

See awards information here.

# Finishing the Chassis

Finishing the Chassis By Kenna and Janavi

We have been working on this chassis for over 3+. In out last post, we had thought the wheels were ready to go. However, various parts, such as wheel mounts, had been put on backwards or were unusable so we had to do everything over again.
Now that the robot has wheels, we started on attaching the REV expansion hub and battery. The chassis is square, but has an asymmetrical structure of tetrix bars. Attaching the battery was the simple part since previous version of the robot had a 3D-printed battery holder that would be screwed on. There was no way to effectively place the expansion hub on the tetrix rails. Instead, we attached a thin plank of wood to two parallel bars, drilled a couple holes, and screwed the hub on.
Overall, it is a very no-frills chassis. We had to cut most of the side shields off because they were becoming more of an obstruction than an aid.

### Next Steps

Though the physical robot has been built, it has no code. Both of us will be learning how to program a basic pushbot.

# UIL 2018

UIL 2018 By Abhi, Karina, Evan, Janavi, Austin, Justin, and Shaggy

### Task: Attend the 2018 UIL Robotics Competition

##### Background

For those who don't know, UIL Robotics is the premier state robotics competition for Texas. Iron Reign has been a beta-testing partner since its inception, and this year was the event's first year as a full-fledged program.

To participate in UIL, a team must win at a Regional level, and have a good overall showing. This year, since we got 2nd Inspire at Regionals and 3rd Inspire at Oklahoma Regionals, we were a shoo-in for an invitation. Being a state event, the DISD STEM Dept. supported us through transportation, food, and lodging along with other DISD teams such as Mechanicats.

##### The Night Before

As with all Iron Reign tournaments, we stayed up way longer than we should have. But, unlike other times, we had a purpose: to help fellow teams.

We assisted the other DISD team, Mechanicats with programming and driver practice. In particular, they didn't have a working autonomous to begin with. But, with our half-field and glut of programmers, we helped them create a basic autonomous for the next day. As well, we collaborated on their TeleOp to make it more driver-friendly.

##### The Day Of

We walked into the tournament, tired, but excited for the last tournament of the season, led by our two robots, Kraken and C.A.R.T. BOT. Kraken is our Relic Recovery robot; a tank on wheels with specially cut aluminum sideplates and our proprietary REVolution system. So, it got plenty of looks. Then, we also brought the newest addition to the Iron Reign family: CART BOT. CART BOT is the automated corpse of our robot cart. For the past month, we've been tearing it down, replacing its wheels, motorizing it, adding a power source, and so much more. It tops out at 20 MPH and can carry 300 lbs. without blinking an eye. Naturally, we thought UIL was the perfect place to bring it out.

Since UIL is the last tournament of the season and has no real consequences, we use it as a trial field for next year's changes. First, we had Evan lead our pit crew team as practice for next year. As well, we used the competition to practice driving for next year as well as improve our scouting strategies after worlds.

One of the best things about UIL is the ability to really interact with other Texas-area teams that we normally wouldn't see until Supers. A lot of the teams came over to see our robot, which is kind of understandable because it's probably the best robot we'll ever build. But, we had a surprising number of teams come up to talk to us about our Engineering Journal, including people who had already seen our journal online and wanted to talk about it to us in person (Vitruvian Voltage).

##### Robot Performance

Even though we enjoy UIL, it's never our best competition of the year. Some of this is due to exhaustion; we tend to run out of steam by then, but it can also be attributed to that UIL is a robot-game intensive event, and Iron Reign tends to focus more on awards. So, we tend to comparatively underperform as compared to a theoretical Iron Reign stand in.

We started off the day in a bad place, as one of the chains on the robot snapped for the first time in the season. However, we still managed to win the match as we were carried by our partner. But, we managed to do decently in the next four matches. This wasn't entirely due to luck, it was just that we had more competition experience than some of the other teams due to Worlds, and were able to perform more effectively.

Luckily, our scouting paid off, and we were chosen as the first pick of the #1 alliance. We won our first final match, but then lost the next two due to unreliability.

##### The UIL Difference

Unlike FTC, UIL puts much less of an emphasis on judging. First, there aren't any presentations: everything is done at the pit. In addition, UIL judges are FRC first, and FTC second, so they weren't aware of many differences between the two. Finally, the awards mean nothing.

### Next Steps

This was the last competition of the season, so now Iron Reign will go into Funding, Outreach, and Recruitment mode for a while for the next season, but keep track of our blog to see what we'll do next. Relic Recovery '17-'18, signing off.

# Swerve Drive Experiment

Swerve Drive Experiment By Abhi

### Task: Consider a Swerve Drive base

Last season, we saw many robots that utilized a swerve drive rather than the mecanum drive for omnidirectional movement. To further expand Iron Reign's repertoire of drive bases, I wanted to further investigate this chassis. Swerve was considered as an alternative to swerve because of its increased speed in addition to the maneuverability of the drive base to allow for quick scoring due to its use of traction wheels at pivot angles. Before we could consider making a prototype, we investigated several other examples.

Among the examples considered was the PRINT swerve for FTC by team 9773. After reading their detailed assembly instructions, I moved away from their design for many reasons. First, the final cost of the drive train was very expensive; we did not have a very high budget despite help from our sponsors. If this drive train was not functional or if the chassis didn't make sense to use in Rover Ruckus, we would have almost no money for an alternate drive train. Also, they parts used by 9773 involved X-rail rather than extrusion rail from REV. This would cause problems in the future as we would need to redesign the REVolution system for X-rail.

Another example was from team 9048 which appeared to be more feasible. Because they used REV rail and many 3D printed parts, this was a more feasible prototype. Because they didn't have a parts list, we had the find the rough estimate of cost from the REV and Andymark websites. Upon further analysis, we realized that the cost, though cheaper than the chassis of 9773, would still be a considerable chunk of our budget.

At this point it was evident most swerve drives being used are very expensive. Wary of making this investment, I worked with our sister team 3734 to create a budget swerve with materials around the house. A basic sketch is listed below.

### Next Steps

Scavenge for parts in the house and Robodojo to make swerve modules.

# Swerve Drive Prototype

Swerve Drive Prototype By Abhi and Christian

### Task: Build a Swerve Drive base

Over the past week, I worked with Christian and another member of Imperial to prototype a drive train. Due to the limited resources. we decided to use Tetrix parts since we had an abundance of those. We decided to make the swerve such that a servo would turn a swerve module and the motors would be attached directly to the wheels.

Immediately we noticed it was very feeble. The servos were working very hard to turn the heavy module and the motors had trouble staying aligned. Also, programming the chassis was also a challenge. After experimenting further, the base even broke. This was a moment of realization. Not only was swerve expensive and complicated, we also would need to replace a module really quickly at competition which needed more resources and an immaculate design. With all these considerations, I ultimately decided that swerve wasn't worth it to use as a drive chassis at this time.

### Next Steps

Consider and prototype other chassis designs until Rover Ruckus begins.

# Big Wheel Ideas

Big Wheel Ideas By Janavi

### Task: Create a Unique Chassis

This summer, we're working on creating unique chassis that are outside of our comfort zone. Often we choose safe bases - opting for ones that we have tried in the past and know work. But, taking the opportunity to explore unique bases allows us to see their performance. One of our ideas is for a two-wheeled robot, with two large wheels and one, smaller, non-motorized omniwheel. We think that this 2-wheeled robot would be a good opportunity for Iron Reign, as we know that our robot has to be lighter than the Relic Recovery robot and a non-mecanum drive would be much lighter. Here is a drawing of what we plan the chassis to look like:

To make this chassis the most efficient based on what we currently know about the competition (light weight robot needed) we are planning to do different tests and calculations to determine the proper motor-gear ratio needed and the wheel locations to properly balance the robot. We also need to perform tests to determine the best material to use for the robot. In the past we've used REV rails for the majority of our structure but due to the weight limit on our robot we plan to minimize metal in our design rather opting for materials that are just as functional but weight less.

### Next Steps

Perform calculations comparing different motors as well as different wheel ratios to determine the optimal ratios

# Position Tracking

Position Tracking By Abhi

### Task: Design a way to track the robot's location

During Relic Recovery season, we had many problems with our autonomous due to slippage in the mecanum wheels and our need to align to the balancing stone, both of which created high error in our encoder feedback. To address this recurring issue, we searched for an alternative way to identify our position on the field. Upon researching online and discussing with other teams, we discovered an alternative tracker sensor with unpowered omni wheels. This tracker may be used during Rover Ruckus or beyond depending on what our chassis will be.

We designed the tracker by building a small right angular REV rail assembly. On this, we attached 2 omni wheels at 90 degrees to one another and added axle encoders. The omni wheels were not driven because we simply wanted them to glide along the floor and read the encoder values of the movements. This method of tracking is commonly referred to as "dead wheel tracking". Since the omnis will always be touching the ground, any movement will be sensed in them and prevents changes in readings due to defense or drive wheel slippage.

To test the concept, we attached the apparatus to ARGOS. With some upgrades to the ARGOS code by using the IMU and omni wheels, we added some basic trigonometry to the code to accurately track the position. The omni setup was relatively accurate and may be used for future projects and robots.

### Next Steps

Now that we have a prototype to track position without using too many resources, we need to test it on an actual FTC chassis. Depending on whether or not there is terrain in Rover Ruckus, the use of this system will change. Until then, we can still experiment with this and develop a useful multipurpose sensor.

# Chassis Flyer

Chassis Flyer By Ethan

### Kraken

This is Iron Reign’s world-championship robot from last season. The basic rundown is this:

• Weight - 42 lbs
• Size - 18x17.8x17.5 inches
• Drive - Mecanum
• Main parts kit - REV

Iron Reign uses two design processes in conjunction with each other to create efficient and reliable parts: iterative, continual improvement and competitive design.

An example of these design processes working in conjunction is the process of designing our cryptobox intake system. One person had the idea to build an arm-style grabber seen on many current competition robots. His design, however, included shorter arms for space’s sake and a more compact lift system than normal. The second person decided to build a unique conveyor-belt system which used friction to hold blocks in space and move them vertically. Through the competition, we determined that the prior design was more efficient and took up less space than the latter, so we settled on his design, adding in a linear slide for lifting at the end of the process. Then, Kaizen comes in. Through firsthand experience in scrimmages, we learned that the grabber system isn’t as reliable as we thought when first testing. So, we have designed a new grabber system that moves like the arms did previously, but also rotate with soft spikes attached to hold blocks with friction better without damaging them.

As this soft-spike system ceased to perform to our expectations, we looked to other mechanisms to pick up and deliver blocks effectively. We created a new grabber that still used the rotating systems of the soft-spike, but instead, we used custom 3D printed “octopuckers” which had a much tighter grip on the glyphs. As well, inside the gripper, we created a custom “lift” made out of NinjaFlex so that the blocks could be moved up and down internally in the gripper, eliminating our need for stacking.

Later, we further improved upon the grabber design, attaching it to a conveyor belt so that we could move glyphs all across our robot in order to score higher, using our REVolution system. This is the most ambitious use of our REVolution system yet, and we strongly encourage the reading judges to view it at the pits.

### BigWheel

The main purpose of this robot is to see if larger wheels will give us an advantage in the competition. Right now, we’re guessing that the competition field will have debris, and we hope that the large wheels will perform better in this environment.

• Size: ~18x18 in
• Wheels - 8in large, regular omni wheels in front
• Part System: Custom parts

### Garchomp

For skill development we have newer builders replicating the chassis portion of our competition robot (Kraken). This one will not be weighed down by the additional upper structure of the competition robot and so should be a closer comparison in weight class to most of the other chassis designs under consideration here. Garchomp has a simplistic design and is nothing more than mechanums, rev rails, motors, sprockets, wires, and a rev hub. The large mechanums are held together using side plates from the 2017-18 competition season. These are geared up to neverest 40:1 motors.

• Size: ~18x18 in
• Wheels: Mechanum
• Part System: REV
• Motors: Neverest 40:1

# Summer Chassis Project - July Meeting

Summer Chassis Project - July Meeting By Kenna, Ethan, Charlotte, Karina, Shaggy, and Abhi

### Task: Compare & Collaborate on Chassis

At Big Thought's offices in downtown Dallas, three teams met. Technicbots (Team 8565), EFFoRT (Team 8114), Schim Robotics (12900), and Iron Reign are all part of the North Texas Chassis Project. The goal is for each team to create any number of chassis and improve their building skills by learning from the other teams.

The meeting began with an overview of all teams' progress. Each team presented their thought process and execution when creating each bot and discussed why/how everything was done. At the end, we all reviewed the rule changes for the 2018-19 season. Once all questions had been asked and answered, testing began.

Austin Lui of Technicbots gets their chassis ready for testing.

Using leftover tiles from last season, we set up a small field in Big Thought's blue room. Technicbots provided a ramp to do enhanced testing with. All teams plan on testing:

• Forward speed
• 3 second turn
• Up/Down ramp
• Balancing stone
• Weight-pulling
• Straight line drift
• 90/180° turn offset

Connor Mihelic of EFFoRT adds some finishing touches.

We know from Google Analytics that our website has about 200 visitors a month but we rarely meet the people who read and use our blog posts. Today, we got to meet the mentors of Team 12900 from a middle school in Plano, TX. When they and their students were starting out as a team, they utilized our tutorials and journal. Apparently their teams members are avid followers of our team, which was very meaningful to hear. Some non-FTC friends visited as well and were introduced to cartbot.

Terri and Grant Richards of Schim Robotics.

### Next Steps

Using what we learned from the other teams, we will begin to improve all of our chassis. Most of them are at varying levels of completion so now we want to concentrate on getting all of them to the same level of functionality. Garchomp is, notably, the most behind so he will be getting the most attention from here on out.

# Replay Autonomous

Replay Autonomous By Arjun

### Task: Design a program to record and replay a driver run

One of the difficulties in writing an autonomous program is the long development cycle. We have to unplug the robot controller, plug it into a computer, make a few changes to the code, recompile and download the code, and then retest our program. All this must be done over and over again, until the autonomous is perfected. Each autonomous takes ~4 hours to write and tune. Over the entire season, we spend over 40 hours working on autonomous programs.

One possible solution for this is to record a driver running through the autonomous, and then replay it. I used this solution on my previous robotics team. Since we had no access to a field, we had to write our entire autonomous at a competition. After some brainstorming, we decided to write a program to record our driver as he ran through our autonomous routine and then execute it during a match. It worked very well, and got us a few extra points each match.

Using this program, writing an autonomous program is reduced to a matter of minutes. We just need to run through our autonomous routine a few times until we're happy with it, and then take the data from the console and paste it into our program. Then we recompile the program and run it.

There are two parts to our replay program. One part (a Tele-op Opmode) records the driver's motions and outputs it into the Android console. The next part (an Autonomous Opmode) reads in that data, and turns it into a working autonomous program.

### Next Steps

Our current replay program requires one recompilation. While it is very quick, one possible next step is to save the autonomous data straight into the phone's internal memory, so that we do not have to recompile the program. This could further reduce the time required to create an autonomous.

One more next step could be a way to easily edit the autonomous. The output data is just a big list of numbers, and it is very difficult to edit it. If we need to tune the autonomous due to wear and tear on the robot, it is difficult to do so without rerecording. If we can figure out a mechanism for editing the generated autonomous, we can further reduce the time we spend creating autonomous programs.

# C.A.R.T. Bot Summer Project

C.A.R.T. Bot Summer Project By Evan, Abhi, and Janavi

### Task: Enhance our robot-building skills

At Iron Reign, we hate to waste the summer since it’s a great time to get all the ridiculous builds out of the way. Thus, we created C.A.R.T. Bot (Carry All our Robotics Tools). Our constant companion these last few seasons has been our trusty Rubbermaid utility cart which has been beaten and abused, competition after competition, as it carried all our tools and robots. Because of all of this, we decided it was time to show the cart a little love, and in typical Iron Reign fashion, we went all out and turned it into a robot.

Our first step was to switch out the back wheels on it to elf-sized bicycle wheels, allowing us to take on the mightiest of curbs and motorize it. To attach the wheels, a four foot or so cylinder of threaded steel was inserted in holes on either side of the cart. Two slots were cut out in the bottom for the wheels and they were eventually slid on, but not after 3D printed mounts for sprockets were attached to the wheels, enabling us to gear them in a one to one ratio with the sprocket attached to the motors, which consisted of two SIM motors commonly found on FRC robots.

Before we used SIM motors, we attempted to power the cart using two Tetrix motors which were geared for speed but, due to load, barely moved at all. Besides a lack of power, they also tended to come out of alignment, causing a terrible noise and causing the cart to come to a stall. This was quickly scrapped. To mount the motors, we used two pieces of aluminum bars and bolted them to the motors, then screwed them to the floor of the cart, aligned with the wheels. We chained them together and got about powering the system. We got two 12-volt batteries and chained them in parallel so as to not overload the system, and hooked them up to a REV hub. Then, we ran them through a switch and breaker combination. We connected the motors to the rev hub and once we had it all powered up, we put some code on it and decided to take it for a spin.

It worked surprisingly well, so we went back in and put the finishing touches on the base of Cart Bot, mainly attaching the top back on so we could put stuff on top of it, and cutting holes for switches and wires to run through, to make it as slick as possible. We added a power distribution station to assist with the charging and distribute current to any device we decided to charge on the cart. We will eventually hook this up to our new and improved battery box we plan on making in the few spare moments we’ll have this season, just a quick quality of life improvement to make future competitions go smoothly.

### Next Steps

Our cart box isn’t done yet, as we intend to make a mount for a solar panel, which we will be able to charge the cart during the downtime in competitions (only if there’s a good window we can park it next to). The cart wasn’t just about having a cool new and improved cart that we don’t have to push (which it is), it also was a test of our engineering skills, taking things that never should have been and putting them together to make something that we will utilize every competition. We learned so much during this experience, I for one learned how to wire something with two batteries as not to destroy the system, as for everyone else, I can’t speak for all but I think we learned a very important lesson on the dangers of electricity, mainly from the height of the sparks from an accidental short that happened along the way. Despite this, the cart came out great and moves smoother than I ever could have hoped. The thing is a real blast and has provided a lot of fun for the whole team, because yes, it is ridable. We predict the speed it’s set at is only a fifth of its full potential speed, and since it already goes a tad on the fast end we don't intend to boost it anymore while there’s a rider on it. Overall, the project was a success, and I’m personally very proud of my work as I’m certain everyone else is too. Come to see it at our table, I really think it’s worth it.

Adjusting Garchomp's Chains By Janavi and Kenna

In our last post, we thought that we had finished Garchomp. However, as we came back to the next practice, we realized that Garchomp's chains were incorrectly linked.

So, we started to diagnose the problem. We noticed that the old REV rails we were using had dents in them, which caused the motors to shift, therefore causing the chains to come off the gears.

To amend this problem, we decided to replace the REV rails ensuring that the motors would not shift during movement. To accomplish this we:

• First, we loosened all of the screws on the current bar, carefully slid it out, and replaced it with new bars
• Then we fixing all of the chains and confirming that each of them were individually working
• we re-attached all of the cables to the robot
• Ran a stress-tester program and hung the robot on a hook to allow us to properly observe the wheels
Due to our tests we discovered that our wheels were running at different speeds, meaning that our robot constantly moved in circles. After checking that the motors were working, we discovered that it was our encoder cables that were plugged in wrong. After that, Garchomp began to run smoothly.

### Next Steps

We will run more stress tests on our robot and make sure that it is up to par with our past robots.

# My Summer at MIT

My Summer at MIT By Abhi

### Task: Spend a Summer at MIT

Hello all! You might have been wondering where I went the entire summer while Iron Reign was busily working on tasks. Well for those of you interested, I was invited to spend a month at MIT as part of the Beaverworks program. I worked in the Medlytics course and analyzed medical data using machine learning methods. This seems distant from the work we do in FTC but I learned some valuable skills we could potentially use this season. But before I discuss that, I want to talk about the work I did while I was away.

Traditionally, machine learning and artificial intelligence were used for enrichment of the technology. We have been seeing development of search engines to learn our searching trends and craft new results or online shopping websites like Amazon learning our shopping to suggest new items to buy. With the help of machine learning, all this has become possible but there are potential healthcare applications to the same technology. The new algorithms and techniques being developed have shown potential to save lives in times where traditional approaches had failed. Even with basic implementations of artificial intelligence, we have seen instances where a doctors provided an improper diagnosis while a machine said otherwise. These scenarios have further inspired research for medical analytics, which has become the focus of my course at MIT. The Medlytics course was dedicated to learn more about these issues and tackle some real world problems.

The work I was doing was very intensive. I applied the algorithms we were being taught to a number of situations. One week, I was analyzing physiological signals to determine the state of sleep. The next week, I was training models to detect breast cancer from mammograms. Within all this work, the underlying structure was just techniques that could be applied to a number of fields. That brought me to think about the potential applications of my work in FTC. The neural networks and similar models I was training learned a number of scenarios of images or signals. I realized that by integrating computer vision, I could come up with something similar in FTC.

To demonstrate an example of where this could potentially leave an impact, I will go with object detection. Right now, Iron Reign captures a series of images of the object of interest (an example is a cryptobox from Relic Recovery) and attempts to manually fine tune the OpenCV parameters to fit the object as accurately as possible. This sort of task could easily be delegated to a Convolution Neural Network (CNN) architecture. What is a CNN you ask? Well here is a brief description.

In essence, the model is able to determine a pattern in an image based on edges and details. The image is processed through a series of layers to determine the shapes in the image. Then the model attempts to label the image as seen above with the car. If this was brought into context of FTC, we could train model to learn the shapes of an object (for example a wiffle ball) and then feed the information to the robot. The bot could then navigate to the object and pick it up. There are a vast number of applications to this, with this just being one. I hope that my knowledge can be of use for Rover Ruckus.

### Next Steps

Wait for Rover Ruckus reveal to see if I can combine my expertise with new code.

### Task: Create a mockup for BigWheel

We've been working on a design for the chassis workshop for quite a while now. We already presented it at the first meeting, and now we need to work on the other components of our presentation: the weight testing, torque calculations, speed testing, and finally, a chassis model. To do the last one, we made a simple model in PTC Creo.

# Bigwheel Presentation

Bigwheel Presentation By Arjun and Karina

As a new freshman on Iron Reign, I took on the responsibility of a robot we called Bigwheel. Karina and I worked on getting the robot into something that could be put through load tests, meaning tightening the chain, fixing misaligned sprockets, and getting the wiring together. We participated in the Chassis Presentation workshop hosted by technicbots for teams all around the North Texas region to work on one or more chassis, perform various tests with them and then present their findings. We presented our chassis Bigwheel, which is driven by 2 large 8-inch wheels, with a pair of 2 free-spinning Omni wheels in the back. This can be seen in the presentation below:

To create our chassis we used 2 8-inch wheels, each driven by 2 Neverrest 60 motors. There are also two free-spinning omni wheels in the back. The robot uses REV rails and plexiglass for it's main body.

Our first test is the 5-second distance test. Our robot had a lot of torque due to the Neverrest 60 motors, so it moved slower than other robots, but was unaffected by the additional 30lbs weight.

Our second test is the 3-second turn test. Again, some other robots could turn better faster than us. However, due to having no proper mechanism for restraining our weights, along with other mysterious problems such as battery disconnections that only happened during this test, we were unable to try this test with load, however we presume that due to the torque, the results should be similar to those without load. Our center of rotation is also off due to only the front two wheels being powered. As such, the back of the robot makes a wide arc as it turns.

Our next few test results are unremarkable.

Our robot had a lot of sideways drift, mostly due to bad build quality. If we intend to use it during the season, we will try to fix this.

Overall, our chassis performed well under load, but could use a little speed boost. If we want to further develop it, we plan to use Neverrest 20s with more torque on our external gear ratio, so we can get more speed out of it.

# Garchomp Presentation

Garchomp Presentation By Janavi and Kenna

### Task: Present in the Inviational Presentation Series

Today, we participated in the Chassis Presentation workshop for teams all around the North Texas region; the project was to design robots and perform various tests with them, then present findings. We presented our chassis, Garchomp, a mechanum wheel chassis as can be seen in the slide photos below.

### Presentation

To create our chassis we used 4 never rest 40 motors one for each wheel and the structure of the chassis was created by using tetrix rails. We connected the wheels to the motors by using a 1:1 gear ratio. While there are many benefits to using a gear ratio for your wheels be forewarned that if your wheels are not perfectly aligned attaching your chains to mechanum wheels will become a living nightmare as can be seen in our previous posts.

One of the reasons that attaching the chains was so difficult for us was because we discovered that because we had used wooden sides instead of the aluminum sides that Kraken used our wheels became misaligned to the two different types of wood used for the sides.

While our robot is not able to do a 360 degree turn as fast as some other robots presented today it is able to hold a considerable amount of speed while moving at a constant speed.

Since this chassis was designed for last years competition it is able to consistently drive onto the balancing stone

# Post Kickoff Meeting

Post Kickoff Meeting September 08, 2018 By Karina, Charlotte, Ethan, Evan, Kenna, and Abhi

### Meeting Log September 08, 2018

Today Iron Reign attended the FTC 2018-2019 season kickoff at Williams High School. After the event, we gathered back at our coach's house to talk about how we might approach this season's challenge. We welcomed prospect team members as well. They joined us in reviewing the reveal video and the games manuals.

### Today's Meet Objectives

We wanted to have an understanding of the game design so that we could start going over robot designs. To do this we:

• Watched the reveal video
• Skimmed through game manual 1 and the preview of game manual 2

Until we receive the field elements, we will have to plan and strategize using the resources listed above.

Because we also had new possible team members over, we set expectations for this year. Actively recording our progress and blogging for the engineering journal was heavily stressed. We recognize the importance of having a good engineering journal and how it can help us advance. Our coach's house, the place where we have our meetings, is also cleaner than it has been in a long time after an intense cleaning session. Having an organized space maximizes efficiency, especially with the a larger team. Therefore, we expect for all team members to clean up after themselves and maintain the organization.

Before we could discuss robot build ideas, we talked strategy. Parking in the crater and the landing zones will undoubtedly be easy to do. Since we know that designing a way for our robot to be able to lift itself onto the lander will be a more interesting challenge and will score us the most points, we will prioritize working on prototypes mechanisms for this task. Finding a way to gently lower down form the lander may be difficult. We will have to consider ways to not damage the robot, wiring, etc. We also agreed that it would make the most sense to have one mechanism that latches onto the hook on the lander, grabs gold and silver elements from the crater, and places these elements into the columns.

Other topics we talked about include drive trains, problems with trying to create a mechanism that grab both the silver balls and gold blocks, as well as how we would be able to grab them out of the crater without going over the edge of the crater and getting stuck.

Also, in previous seasons, we have had strong autonomous game, and so we decided to make the tasks in autonomous another top priority. We had our coders start discussing the field path for autonomous. Unfortunately, we will not be able to launch our team marker into the team depot.

After the end of last season, a storm passed through and turned over shelves, trashing the robo-dojo. Some of our team members cleaned up the tent this afternoon. While it may not seem very important at the moment, this will be very helpful later in the season once we get our field elements for this year's challenge and want to set the field up. While cleaning, they also uncovered old, rusted metal tools and and pieces, which we will now be able to repair and save for future use.

Besides helping with cleaning the tent, the new members showed a lot of interest in the game as well. They were eager to start building, and actually started creating prototype mechanisms for picking up the silver and gold elements.

### Today's Work Log

 Team Members Task Start Time Duration Karina Working on blog 2:00 4 hrs Abhi Autonomous planning 2:00 4 hrs Evan Robot brainstorming 2:00 4 hrs Charlotte Robot brainstorming 2:00 4 hrs Ethan Working on blog 2:00 4 hrs Kenna Cleaning tent 2:00 4 hrs

# Rover Ruckus Brainstorming & Initial Thoughts

Rover Ruckus Brainstorming & Initial Thoughts By Ethan, Charlotte, Kenna, Evan, Abhi, Arjun, Karina, and Justin

### Task: Come up with ideas for the 2018-19 season

So, today was the first meeting in the Rover Ruckus season! On top of that, we had our first round of new recruits (20!). So, it was an extremely hectic session, but we came up with a lot of new ideas.

#### Building

• A One-way Intake System

• This suggestion uses a plastic flap to "trap" game elements inside it, similar to the lid of a soda cup. You can put marbles through the straw-hole, but you can't easily get them back out.
• Crater Bracing
• In the past, we've had center-of-balance issues with our robot. To counteract this, we plan to attach shaped braces to our robot such that it can hold on to the walls and not tip over.
• Extendable Arm + Silicone Grip

• This one is simple - a linear slide arm attached to a motor so that it can pick up game elements and rotate. We fear, however, that many teams will adopt this strategy, so we probably won't do it. One unique part of our design would be the silicone grips, so that the "claws" can firmly grasp the silver and gold.
• Binder-ring Hanger

• When we did Res-Q, we dropped our robot more times than we'd like to admit. To prevent that, we're designing an interlocking mechanism that the robot can use to hang. It'll have an indent and a corresponding recess that resists lateral force by nature of the indent, but can be opened easily.
• Passive Intake
• Inspired by a few FRC Stronghold intake systems, we designed a passive intake. Attached to a weak spring, it would have the ability to move over game elements before falling back down to capture them. The benefit of this design is that we wouldn't have to use an extra motor for intake, but we risk controlling more than two elements at the same time.
• Mechanum
• Mechanum is our Ol' Faithful. We've used it for the past three years, so we're loath to abandon it for this year. It's still a good idea for this year, but strafing isn't as important, and we may need to emphasize speed instead. Plus, we're not exactly sure how to get over the crater walls with Mechanum.
• Tape Measure
• In Res-Q, we used a tape-measure system to pull our robot up, and we believe that we could do the same again this year. One issue is that our tape measure system is ridiculously heavy (~5 lbs) and with the new weight limits, this may not be ideal.
• Mining
• We're currently thinking of a "mining mechanism" that can score two glyphs at a time extremely quickly in exchange for not being able to climb. It'll involve a conveyor belt and a set of linear slides such that the objects in the crater can automatically be transferred to either the low-scoring zone or the higher one.

#### Journal

This year, we may switch to weekly summaries instead of meeting logs so that our journal is more reasonable for judges to read. In particular, we were inspired by team Nonstandard Deviation, which has an amazing engineering journal that we recommend the readers to check out.

#### Programming

Luckily, this year seems to have a more-easily programmed autonomous. We're working on some autonomous diagrams that we'll release in the next couple weeks. Aside from that, we have such a developed code base that we don't really need to update it any further.

### Next Steps

We're going to prototype these ideas in the coming weeks and develop our thoughts more thoroughly.

# Testing Intakes

Testing Intakes By Ethan and Evan

### Task: Design a prototype intake system

In our first practice, we brainstormed some intake and other robot ideas. To begin testing, we created a simple prototype of a one-way intake system. First, we attached two rubber bands to a length of wide PVC pipe. This worked pretty well, but the bands gave way a little too easily.

For our next prototype, we attached a piece of cardboard with slits to a cup approximately the size of a cube or block. It operates similarly to a soda cup lid with a straw hole. An object can go in, but the corners of the hole spring back so that it can't escape.

### Next Steps

We probably won't go with this design - we'd have issues separating the different kinds of game elements, and it may be too slow to feasibly use. But, its a first step and we'll see what happens.

# Rover Ruckus Strategy

Rover Ruckus Strategy By Ethan, Kenna, Charlotte, Evan, Abhi, Justin, Karina, and Aaron

### Task: Determine the best Rover Ruckus strategies

 Challenge Game Timing Points Level of Difficulty (1 - 3 [hard]) Priority Idea Landing Autonomous 30 2 Medium Latch attached to linear slides that allows us to descend rapidly Claiming Autonomous 15 1 High Autonomous, easy as bumping into wall Parking Autonomous 10 1 High Autonomous, just need to move Sampling Autonomous 25 2 Medium Autonomous, OpenCV solution as in similar years Latching End Game 50 3 High 3D-printed latch attached to linear slide strong enough to lift robot Robot in Crater End Game 15/25 1 High Driving Mining [Depot] Tele-Op 2 per item 1 High Rolling intake into box, then conveyor belt into the depot Mining [Cargo] Tele-Op 5 per item 2 High Long linear-slide arm that reaches the two feet into the lander with an intake/deposit on the end

# Choosing Drive Train

Choosing Drive Train By Janavi

In our last post, we created a chart where we listed each task asked based on point value and the level of difficulty, separated by autonomous and teleop. Our goal is to find a drive train that will allow us to build a robot to accomplish all of these tasks efficiently and consistently, but this matrix will allow us to determine what to focus on first.

### Drivetrain Comparison

This summer we created a variety of drivetrains for a summer chassis project hosted in coordination with other teams from the North Texas region. We have compiled a list of the drivetrains and the criteria we need to consider for Rover Ruckus.

### What do we need to look at in a Drivetrain?

• Light
• Sturdy
• Easily Maneuverable
• Fast
• Low center of mass to avoid tipping
• Reliability

### Comparison

 Eliminated? Reason for Elimination Pros Cons Miniature Mechanum Drive NO N/A Omni-Directional Fast turning Easy to design Experience with Driving/Building light Uneven power Big Wheel NO N/A Unique Design We have less experience Larger Mechanum Drive YES Need light robot; may use mini mechanum chassis instead Familiar Design Too heavy for this years competition Swerve YES Difficult design, Many motors and servos, we have less experience Easier to maintain at high speed Unfamiliar and difficult to design and maintain 8-wheel Drive YES Many wheels, Difficult of maneuver, no omni directional movement 100% power forward Difficult to maneuver Holonomic Drive YES Less push power in all directions; hard to integrate into robot Easy to turn and maneuver Hard to design; hard to integrate into base; Only 50% power in all directions

# Selecting Wheels

Selecting Wheels By Janavi

### Objective: Determine the type of wheel that best suits the chassis

In the Choosing Drive Train E-16 we decided that we will use the chassis BigWheel. We know that our wheels need to be light weight but we need to determine the size of the wheel that will keep our robot far away enough from the ground for us to provide enough clearance to allow us to climb over the crater rim. But, if we choose wheels with a large radius we risk raising the center of mass.

 Pros Cons Ironton 12in. Solid Rubber Spoked Poly Wheel light durable Large Turns Extremely Large Ironton 16in. Solid Rubber Spoked Poly Wheel light durable Raise center of mass Extremely Large To prevent tipping we now have a much shorter distance to correct imbalance Ironton 8in. Solid Rubber Spoked Poly Wheel light durable Not large enough to significantly move the center of mass

# Brainstorming Two

Brainstorming Two By Evan, Abhi, and Janavi

### Task: Have a 2nd brainstorming session

We had another brainstorming session today, which allowed us to break down into some new building tasks.

#### Intake System 3 - TSA Bag Scanner

This part of our robot is inspired by the bag-scanning machine in TSA lines, more specifically the part at the end with the spinning tubes. The basic design would be like a section of that track that flips over the top of the robot into the crater to intake field elements.

#### Intake System 4 - Big Clamp

This one is self-explanatory. Its a clamp, that when forced over a block or a cube, picks it up. It's not that accurate, but it's a good practice idea.

#### Lift 2 - Thruster

We want to make lifting our robot easy, and we're thinking of a slightly different way to do it. For our new lift idea, we're installing a vertical linear slide that forces the robot upwards so that we can reach the lander.

### Next Steps

We're working on building these prototypes, and will create blog posts in the future detailing them.

# Meeting Log

Meeting Log September 15, 2018 By Charlotte, Karina, Kenna, Janavi, Evan, Abhi, Justin, and Ethan

### Meeting Log September 15, 2018

Today Austin, an Iron Reign alumni, visited us from A&M! :)

### Today's Meet Objectives

As our brainstorming and discussion continues, we are putting our ideas into action and making various prototypes and designs. We will continue to work with our new recruits and let them participate in a meaningful way with our building and in getting ready for competition.

### Today's Meet Log

• Further brainstorming and discussion
• Taking some inspiration from 30 hr robot reveal videos, we have continued the brainstorming for this year's robot. Our main subjects of discussion are our intake and lift, and some ideas that were thrown around were a conveyor belt-like intake and a lift that utilizes a linear slide which lifts the robot chassis. The details of our brainstorming session can be found at (E-19, Brainstorming Two - Enter the Void).
• Prototyping and linear slides
• Today, Abhi worked on a hook for hanging off the rover at first with Styrofoam, and then began a 3D model. Evan started working with our new linear slides (see the picture below); we expect to use linear slides a lot this year, with reaching into the craters and hooking onto the rover. We pre-drilled some holes into these new slides using an optical punch and a drill. Janavi worked with a different linear slide kit, this kit is lighter than our new kit, which is helpful, but it is very delicate and requires precision to put together.
Evan looking through an optical punch
Evan with a linear slide
• Field setup
• Many of our new recruits returned today and have continued to be active. During the week, we received the field parts, so we had them help us put it together so that they can be familiar with the field design and with certain power tools. They also helped with various devices we worked on, like the linear slides, etc.
Field assembly progress from our new recruits.
• Chassis testing
• We plan to use the chassis we built this summer for preliminary autonomous testing. Janavi and Kenna got Garchomp up and running today and added a better and more secure phone holder so we can run autonomous.
• Vision and autonomous
• We began exploring in Open CV so that we can have a visual tool to find the minerals; the algorithms we are exploring can be used for both autonomous and tele-op. We had a discussion on our goals for vision this year, which can be found at (E-20, Vision Discussion). We also began mapping our autonomous paths to act as guides to our coders.
Open CV progress

### Today's Member Work Log

 Team Members Task Start Time Duration Karina Robot build and team marker design 2:00 4 hrs Abhi Open CV 2:00 4 hrs Evan Prototyping 2:00 4 hrs Charlotte Blog and brainstorming 2:00 4 hrs Ethan Working on blog 2:00 4 hrs Kenna Robot build 2:00 4 hrs Justin Field assembly 2:00 4 hrs Janavi Prototyping 2:00 4 hrs

# Vision Discussion

Vision Discussion By Arjun and Abhi

### Task: Consider potential vision approaches for sampling

Part of this year’s game requires us to be able to detect the location of minerals on the field. The main use for this is in sampling. During autonomous, we need to move only the gold mineral, without touching the silver minerals in order to earn points for sampling. There are a few ways we could be able to detect the location of the gold mineral.

First, we could possibly use OpenCV to run transformations on the image that the camera sees. We would have to design an OpenCV pipeline which identifies yellow blobs, filters out those that aren’t minerals, and finds the centers of the blobs which are minerals. This is most likely the approach that many teams will use. The benefit of this approach is that it will be easy enough to write. However, it may not work in different lighting conditions that were not tested during the designing of the OpenCV pipeline.

Another approach is to use Convolutional Neural Networks (CNNs) to identify the location of the gold mineral. Convolutional Neural Networks are a class of machine learning algorithms that “learn” to find patterns in images by looking at large amounts of samples. In order to develop a CNN to identify minerals, we must take lots of photos of the sampling arrangement in different arrangements (and lighting conditions), and then manually label them. Then, the algorithm will “learn” how to differentiate gold minerals from other objects on the field. A CNN should be able to work in many different lighting conditions, however, it is also more difficult to write.

### Next Steps

As of now, Iron Reign is going to attempt both methods of classification and compare their performance.

# CNN Training

CNN Training By Arjun and Abhi

### Task: Capture training data for a Convolutional Neural Network

In order to train a Convolutional Neural Network, we need a whole bunch of training images. So we got out into the field, and took 125 photos of the sampling setup in different positions and angles. Our next step is to label the gold minerals in all of these photos, so that we can train a Convolutional Neural Network to label the gold minerals by learning from the patterns of the training data.

### Next Steps

Next, we will go through and designate gold minerals. In addition, we must create a program to process these.

# Chassis Brainstorming

Chassis Brainstorming By Ethan and Evan

At the moment, we've used the same chassis base for three years, a basic mechanum base with large wheels. However, we don't really want to do the same this year. At the time, it was impressive, and not many teams used mechanum wheels, but now, its a little overdone.

Thus, we have BigWheel. We used this as a practice design, but we ended up really liking it. It starts off with two large rubber wheels, approx. eight inches in diameter, mounted at the back and sides of the robot. Then, we have two geared-up motors attached to the motors for extra torque and power. In the front, we have a single omniwheel that allows our robot to turn well.

First, we need to add an intake system. For this, we're considering a tension-loaded carwash that can spring out over the crater wall. It'll pull elements in and sort them through our intake using our separator, which we will detail in a later post. Then, the robot will drive over to the lander and lift itself up. Since the main segment of the robot is based off of two wheels, we're attaching a telescoping slide that pushes off of the ground at the opposite end and pivots the front of the robot upwards. Then, the intake will launch upwards, depositing the elements in the launcher.

### Next Steps

We need to create a proof-of-concept for this idea, and we'd like to create a 3D model before we go further.

# Meeting Log

Meeting Log September 22, 2018 By Charlotte, Janavi, Evan, Abhi, Justin, Ethan, Arjun, Karina, and Kenna

### Meeting Log September 22, 2018

Home Depot Trip!

### Today's Meet Objectives

As we are starting to make more serious strides in our robot and strategy, we wish to start passing down knowledge to our new recruits. Today, we are going to continue prototyping with grabbers and various linear slide kits and we need to discuss strategy and organization for this season.

### Today's Meet Log

• Robot strategy discussion
• Today we have discussed more about what we want our strategy to look like. An option we are heavily considering is having a non-moving robot, in the sense that our robot is stationary and all game actions are performed using extensions from the robot, using linear slides, etc. We have discussed what game rules we need to consider, like what "parking" consists of during autonomous. For further information, see (E-34, Another Design Bites the Dust).
• Chassis brainstorming
• We discussed the chassis design we plan to use this season, and we decided experiment with the BigWheel chassis we build this summer. For more details on this discussion, see (E-23, Chassis Brainstorming).
• Sorter prototyping
• We have continued prototyping various grabbing mechanisms with sorting ability, one passive and one active sorter. The passive version we modeled in Creo and printed before practice, and the active was modeled using Legos! Our new recruits have been helping us prototype also, as we have been making a version 2 for the active model.
Passive model
Active model
• New chop saw!
• Some of the materials we are working with require power tools that we don't have or were damaged by rain. One of the linear slide kits we are working with is stainless steel, which requires a chop saw which we didn't have. We made a trip to Home Depot and bought one.
Chopsaw in action

• Finishing field assembly
• Our new recruits finished up the field today. They ran into some problems along the way, including difficulty with putting on the top part of the lander, improper placement of the wing nuts, alignment of the lander in the foam tiles, and more but were able to overcome these difficulties and yielding a field for practice.
Our freshman recruits!
• Linear slide assembly
• Evan and Janavi finished assembling the linear slides they were working on last week. As we build a chassis (or a wheel-less chassis) we are going to try both types to see how the weight, strength, friction, string tension, and other factors affect our gameplay. A side-by-side comparison of our linear slides cam be found at (E-61, Selecting Linear Slides)

Battle of the Slides
• Team marker
• Karina narrowed down the ideas for a marker and she, with Kenna, has began building it. More about our marker can be found at (E-33, Team Marker Fun).
• Open CV and our CNN
• While we are waiting to begin code, we are testing many algorithms in Open CV, so we can accurately and consistently detect field minerals. These algorithms consider shape and color to map points to predict the location of the minerals. While developing Open CV, we have begun the development of a Convolutional Neural Network. Detail of our CNN training can be found at (E-22, CNN Training).
• Location sensor
• Today, Justin worked on making the location sensor (our fail-safe in case our encoders fail) smaller and more lightweight to help us meet with this year's size requirements (something we have had trouble with in the past).
• Chassis testing
• We tested the different chassis we build this summer on the field to see how they interact with the terrain (aka the crater). We found that Big Wheel was too long and didn't go over the crater at all unless it was backwards and got a running start. Garchomp (with Mechanums) went over the craters fine.

### Today's Member Work Log

 Team Members Task Start Time Duration Karina Robot build and team marker design 2:00 4 hrs Abhi Open CV and build 2:00 4 hrs Evan Build 2:00 4 hrs Charlotte Blog and brainstorming 2:00 4 hrs Ethan Working on blog 2:00 4 hrs Kenna Robot build 2:00 4 hrs Justin Build and field assembly 2:00 4 hrs Janavi Build 2:00 4 hrs Arjun Code and blog 2:00 4 hrs

# Autonomous Path Planning

Autonomous Path Planning By Abhi

With the high point potential available in this year's autonomous it is essential to create autonomous paths right now. This year's auto is more complicated due to potential collisions with alliance partners in addition to an unknown period of time spend delatching from the lander. To address both these concerns, I developed 4 autonomous paths we will investigate with to use during competition.

When making auto paths, there are some things to consider. One, the field is the exact same for both red and blue alliance, meaning we don't need to rewrite the code to act on the other side of the field. Second, we have to account for our alliance partner's autonomous if they have one and need to adapt to their path so we don't crash them. Third, we have to avoid the other alliance's bots to avoid penalties. There are no explicit boundaries this year for auto but if we somehow interrupt the opponent's auto we get heavily penalized. Now, with these in mind, lets look at these paths.

This path plan is the simplest of all autonomi. I assume that our alliance partner has an autonomous and our robot only takes care of half the functions. It starts with a simple detaching from the lander, sampling the proper mineral, deploying the team marker, and parking in the crater. The reason I chose the opposite crater instead of the one on our nearside was that it was shorter distance and less chance to mess with our alliance partner. The issue with this plan is that it may interfere with the opponent's autonomous but if we drive strategically hugging the wall, we shouldn't have issues.

This path is also a "simple" path but is obviously complicated. The issue is that the team marker depot is not on the same side as the lander, forcing us to drive all the way down and back to park in the crater. I could also change this one to go to the opposite crater but that may interfere with our alliance partner's code.

This is one of the autonomi that assumes our alliance partners don't have an autonomous and is built for multi-functionality. The time restriction makes this autonomous unlikely but it is still nice to plan out a path for it.

This is also one of the autonomi that assumes our alliance partners don't have an autonomous. This is the simpler one of the methods but still has the same restrictions

### Next Steps

Although its great to think these paths will actually work out in the end, we might need to change them a lot. With potential collisions with alliance partners and opponents, we might need a drop down menu of sorts on the driver station that can let us put together a lot of different pieces so we can pick and choose the auto plan. Maybe we could even draw out the path in init. All this is only at the speculation stage right now.

# Hanging Hook Prototype

Hanging Hook Prototype By Abhi, Ethan, Justin, and Janavi

### Task: Design a hook for pulling the robot on the lander

To get a head-start on latching and delatching from the lander during autonomous, we got a head start and made some hook prototypes. If your robot can just do these two things, you can score 80 points. When making this hook, it needs to be modular enough to not require much accuracy but also needs to be strong enough to hold 42 pounds. This hook works just that way.

We designed this hook to have a slanted top to glide the robot into position if we aren't in the right place, making it very modular. In addition, we 3D printed this hook with ~80% infill in nylon after designing in PTC Creo. First, we tested it by hanging ~20 lbs of material off of it for one minute. This worked, but a little too well. While the nylon piece remained undamaged, the metal bracket it was supported by bent at a ninety degree angle. So, we had to pursue further testing.

For our next test, we plan to hang a mass outside for a week. Dallas weather has been extreme lately, with a lot of rain, humidity, and heat. This will be the ultimate stress test; if one of our pieces can survive the outdoors, it can survive just about anything.

### Next Steps

We're probably going to have to reprint this to be a bit more fitting for our robot, but its a good start and it works great so far.

# Meeting Log

Meeting Log September 28, 2018 By Charlotte, Karina, Kenna, Janavi, Evan, Abhi, Justin, Ethan, and Arjun

### Meeting Log September 28, 2018

Coding lessons with new recruits

### Today's Meet Objectives

Since our overflow of new recruits, we have opened up two other teams 15373 and 15375, which Iron Reign will mentor and lead along with our mentorship of 3732 Imperial Robotics, who has also received new recruits. Today we plan to continue integrating them into FTC; we will begin teaching them the different expectations of an FTC team, including hard and soft skills such as coding and presenting to a panel of judges. In Iron Reign, we are going to continue prototyping various mechanisms we have designed. Also, we are going to get started with coding and autonomous.

### Today's Meet Log

• Mentoring
• This week, we had even more recruits join us today, so we decided to run through our Worlds presentation from last year to teach them about the judging process and our engineering process. We set their expectations for what competition day looks like, and what they need to focus on and maintain throughout the season, such as the engineering journal and outreach. We had a long discussion about subteams and we are going to let the recruits explore these subteams and decide for themselves what parts of FTC they wish to pursue.
Presentation to recruits.
• Linear slides
• Janavi continued working with linear slides, which we installed on a bare chassis as well as the hook Abhi designed and printed. Near the end of practice we tested the slide and we found that it worked pretty well but we need additional tests before we can determine whether it will ba a viable option for our robot. To see more information on our linear slides, see (E-,).
• Secret project
• Evan worked on a secret project, details will be written about in future blog posts. See (E-34, Another Design Bites the Dust).
• Team marker
• Karina continued to work on our team marker. Last time we decided on the design we want to use, and she had put the idea into reality today.
Ducky incarcerated
• Modeling
• Justin 3D modeled and printed wheel mounts for churros and hex shafts.
Justin modeling
• Replay autonomous and code mentoring
• Over the summer, we worked on a new replay autonomous system where rather than coding an autonomous, testing it, then fixing it, we drive the robot in our intended path and that path is automatically recorded in the code. This year, we don't think that system will work, with the heavy emphasis on computer vision and the unreliable positioning of the robot after it drops off the hook on the rover. Also, today we worked with the recruits that demonstrated interest in coding. Abhi gave them a lesson and let them create their very first autonomous program by themselves (but with his guidance of course).

### Today's Member Work Log

 Team Members Task Start Time Duration Karina Team marker build 2:00 4 hrs Abhi Coding and teaching 2:00 4 hrs Evan Robot build 2:00 4 hrs Charlotte Blog and organization 2:00 4 hrs Ethan Working on blog 2:00 4 hrs Kenna Robot build 2:00 4 hrs Justin 3D Modeling 2:00 4 hrs Janavi Robot build 2:00 4 hrs

# BigWheel Chassis

BigWheel Chassis By Evan

### Task: Work on a possible chassis

We've been toying around with the idea of using BigWheel, our Summer Chassis Research Project bot, in this year's competition with a few modifications. The idea for this robot is that it has a collection system that extends into the crater, and folds up on top of the robot. It reaches in with the collection arm, and grabs the blocks/glyphs, drives backwards and flips vertically using the drive wheels as a point of rotation. Here’s a basic sketch of what that looks like.

The way this will be achieved is with a spring loaded lever connected to the omni wheel that makes up the holy trinity of wheels. So far I have pieced together the arm that reaches into the pit, which is powered by two NeverRest 60s and geared in a two to one ratio to significantly increase the torque. Between the two arm I plan for a horizontal beater bar to intake blocks and a slide attached to a servo to separate blocks and balls based on their size. The idea is to have a way of sorting based off of the physical shape rather than by digital sensing means. The more that can be done purely off the shape of the elements, the better.

### Next Steps

Next week, the team will have to make some serious progress since there will be more hands to build. My hope is that the lever will come about soon, even if in its most infant stage, and that some semblance of a functioning robot can be game tested in the next few weeks, just in time for a scrimmage and potentially an early qualifier.

# CNN Training Program

CNN Training Program By Arjun and Abhi

### Task: Designing a program to label training data for our Convolutional Neural Network

In order to use the captured training data, we need to label it by identifying the location of the gold mineral in it. We also need to normalize it by resizing the training images to a constant size, (320x240 pixels). While we could do this by hand, it would be a pain to do so. We would have to resize each individual picture, and then identify the coordinates of the center of the gold mineral, then create a file to store the resized image and coordinates.

Instead of doing this, we decided to write a program to do this for us. That way, we could just click on the gold mineral on the screen, and the program would do the resizing and coordinate-finding for us. Thus, the process of labeling the images will be much easier.

Throughout the weekend, I worked on this program. The end result is shown above.

### Next Steps

Now that the program has been developed, we need to actually use it to label the training images we have. Then, we can train the Convolutional Neural Network.

# Intake Sorter

Intake Sorter By Abhi

### Task: Design a sorter for the balls and blocks

To increase the efficiency of our robot, we looked into ways to passively sort minerals during intake and deposit. It is important to sort because it requires less precision under driver control allowing a faster and more efficient robot. Though bulky, we designed an initial design to sort the minerals.

When this piece is mounted and both blocks and balls are run over it, the balls run down the top and don't fall in the collector, but the blocks fall in the holes. We modeled this design in PTC Creo, then printed it in ABS.

### Next Steps

This design works but is large so we're going to have to find a smaller and simpler way to sort game pieces. In the future, we're going to minimize this and probably move to a smaller sorting mechanism.

# Designing Wheel Mounts

Designing Wheel Mounts By Justin

### Task: Create wheel mounts for our Mini-Mecanum chassis

Today, we modeled two possible designs for mini-mecanum wheel mounts. The purpose of the mounts is to hold a churro or hex shaft in place to mount mecanum wheels to. The first design was a 6cm by 6cm square with rounded edges that was 5mm thick. A hexagon was removed from the center to hold the churro that supports the mecanum wheel. This design, when printed on low infill, allowed the churro to rotate when enough force was applied. We modeled this design off of the wheel mounts on Kraken and Garchomp; the only differences are the size and material. Because we will be 3D printing these mounts, material efficiency is very important. This mount design used a lot of material to make a prototype, meaning a finished stable mount would need even more material to prevent the churro or hex shaft from slipping.

Taking these problems into account, we designed a different way to mount the wheels. The new version can mount underneath a REV Rail and hold the shaft or churro perpendicular to the rail. This design uses much less infill than the previous one because of how small the mount is, and because the REV Rail also acts as support to prevent the churro or shaft from spinning. The mount also allows the mini-mecanum wheels to be mounted as close to the frame as possible, which can help make the robot more compact. This design will allow us to easily mount mini-mecanums to our frame, while using minimal filament and taking up very little space.

### Next Steps

We need to build the full mini-mecanum robot to judge whether these designs will fully work.

# Designing the Corn Cob Aligner

Designing the Corn Cob Aligner By Ethan and Abhi

### Task: Design an aligner for the beater bar intake

The ice cube tray is 9 holes wide and each hole is 16.50mm wide and long. Using these measurements, we created an aligner that would cause the ice cube tray to roll into a cylinder.

We're designing an intake that will allow the robot to intake particles, and this is a major portion. This will allow us to increase the amount of friction put on the particles, allowing for a more secure grip.

However, this system has issues. First, we wanted the edges to still be mildly compliant, and this wheel filled out the edge rows to full depth, making them a little too tough. Plus, they made the silicone height too variable, so that we couldn't solely pick up the balls. So, we designed a second aligner with shorter spokes so that the edges would be fully compliant while still being held securely.

### Next Steps

We need to finish up the corn-cob beater bar, but after that we'll be able to start testing.

# Corn-Cob Intake

Corn-Cob Intake By Ethan and Abhi

### Task: Design an intake system unique for balls

Right now, we're working on a static-deposit system. The first part of this system is having an intake mechanism that passively differentiates the balls and cubes, reducing complexity of other parts of the design. Thus, we created the corn-cob intake.

First, we bought ice-cube trays. We wanted a compliant material that would grip the particles and be able to send them into a larger delivery mechanism.

Then, we designed a wheel which' spokes would fit into the holes on an ice cube tray, allowing the tray to stay static while still being compliant in a cylindrical shape. Then, we can put axle hubs through the center of the wheel, allowing us to mount the wheels on a hexagonal shaft. Then, we can mount a sprocket on that, allowing the bar to be rotated for intake. This bar is mounted at the height of the balls, not blocks, so we can passively sort the minerals in-action.

### Next Steps

We need to mount this on our robot and design a way to deliver the field elements. We're also going to go into more detail on the ice cube mounts in a later blog post.

# Team Marker Fun

Team Marker Fun By Karina

### Task: Create the Team Marker

Last week, we decided to take up the task of creating the team marker, a simple project that would surely be overlooked, but can score a significant amount of points. We wanted the marker to be meaningful to the Iron Reign, but also follow the team marker rules. To start, we made a list of ideas:

Last season, Ducky (as seen in idea #4) brought Iron Reign good luck whenever the drivers squeezed them, and so we knew that we wanted to incorporate Ducky into whatever the final product would be. Some team members suggested fusing together multiple rubber duckies to fit the dimensions in the rule book. I had a better idea. I thought, "Why not put Ducky in a box?" However, trapping Ducky in a box would prevent us from ever squishing Ducky again (as long as they are trapped in the box). But then an even better idea came up: "Why not put Ducky in a cage?" And so we got to work making a cage for Ducky, one that we could release them from or reach in to whenever we need a squish for good luck.

We cut two pieces of 3.5 inch x 3.5 inch polycarb to serve as the ceiling and floor of the cage. Then we used 8 standoffs, in pairs of two at each corner of the cage, to serve as the bars. To not waste anymore standoffs, we used zipties as the cage bars. Additionally, the flexibility of the zipties allow us to squeeze Ducky out of the cage from in between the bars. In the end, Ducky looked like the most happy prisoner we've ever seen:

### Next Steps

With the team marker built, we need to test how well it does its job (staying in one piece for the duration of a match hopefully). It's survived many nights now in the our coach's house, which is no small feat, with all the children running about and constantly misplacing things. Once we have an intake system working for the minerals, we will need to test how compatible it is with Ducky in a Cage. Lastly, we need to decorate Ducky's cage, including our team's number (6832).

# Another Design Bites the Dust

Another Design Bites the Dust By Ethan

### Task: Discuss a new rule change

At one point, we were thinking about creating a "mining facility" robot that stays static within the crater and delivers the blocks into the mining depot. In our eyes, it was legal as it would hold as many blocks as possible inside the crater but only deliver two at a time outside. It would be super-efficient as we would be able to stay within the crater, and not need to move.

However, fate has struck. Earlier this week, we received this message:

The rule limiting control/possession limits of minerals has been updated to indicate that robots may _temporarily_ hold more than 2 minerals in the crater, but must shed any excess over prior to performing any other gameplay activities (which would include scoring).
says that "Robots In a Crater are not eligible to Score Minerals". Per the definitions of "In" and "Crater", if _any_ portion of a Robot is in the vertical area above the crater (extending from the field walls to the outside edge of the Crater Rim), then scoring a Mineral results in a Major Penalty.
says that Robots may not obstruct another Robot's path of travel in the area between the Lander and a Crater for more than 5 seconds.

This means that we couldn't do a static mining facility as we cannot score within the crater. Since we'd have a portion of the robot always in the crater, the existence of our robot would be a major penalty.

### Next Steps

So, we need to rethink our robot. We still want to create a semi-static robot, but we need to redesign the intake portion.

# Labelling Minerals - CNN

Labelling Minerals - CNN By Arjun and Abhi

### Task: Label training images to train a Neural Network

Now that we have software to make labeling the training data easier, we have to actually use it to label the training images. Abhi and I split up our training data into two halves, and we each labeled one half. Then, when we had completed the labeling, we recombined the images. The images we labeled are publicly available at https://github.com/arjvik/RoverRuckusTrainingData.

### Next Steps

We need to actually write a Convolutional Neural Network using the training data we collected.

# Meeting Log

Meeting Log October 06, 2018 By Charlotte, Kenna, Janavi, Ethan, and Arjun

### Meeting Log October 06, 2018

Code Testing with Arjun

### Today's Meet Objectives

We set up some tables with FTC Starter Kits for our new recruits so we can give them an introduction to building with REV parts. We want to continue research & design and build for Iron Reign. There is a scrimmage coming up in a few weeks, so we want to have a working chassis by then.

### Today's Meet Log

• Chassis build
• Kenna and Janavi worked on a chassis. We hope to mount the linear slides we completed last time onto this chassis and hopefully use it for our first scrimmage. We had a frame for the chassis done last time, and this time we added motors and one of four wheels. Hopefully, the chassis will be complete by next week and then we can run some test to determine whether or not it will be a viable chassis for competition use. If we deem that it is worthy, there are a few problems we need to fix before competition day. Notably, the chassis doesn't fit within the sizing cube, as it measures 17 in x 18 and 1/16th in. Our chassis decision process can be found at (E-16, Choosing Drive Train).

Kenna with the chassis frame (pre-motored)

Kenna and Janavi installing the motors
• Engineering journal discussion
• We discussed what we want to improve in our engineering notebook this year. In previous years, one of our greatest weaknesses has been the lack of mathematical analysis in our blog posts, so this year we are going to focus on doing more parts testing and incorporate statistics and physics from those tests into our blog posts.
• Intake prototyping and design
• Ethan has been working on prototyping with grabbers. Abhi designed and printed parts to mount our "corn on the cob" material, and Ethan put it together and made a small frame to put it on so we can test it. To see more about the intake aligner, see (E-31, Designing the Corn Cob Aligner). To see more about "corn on the cob," see (E-32, Corn-Cob Intake).

Ethan working on the blog

Ethan with the "corn on the cob"
• Gantt Chart
• Today, I made some real progress on our team "Gantt" chart. We hope to utilize such a chart in order to improve team organization and structure. Hopefully, this will prevent certain subteams from falling behind and we will not be rushed right before competitions as that has happened a lot historically.
• Code testing and CNN training
• Once he updated the FTC app, Arjun he tested our code with the new update on Kraken, our robot from last year. He also took 72 pictures of the minerals for training of a convolutional neural network. He began compiling those images and will work on the neural network in the coming weeks. See more about our CNN training process in (E-21, CNN Training)

### Today's Member Work Log

 Team Members Task Start Time Duration Charlotte Blog and organization 2:00 4 hrs Ethan Working on blog 2:00 4 hrs Kenna Robot build 2:00 4 hrs Janavi Robot build 2:00 4 hrs Arjun Code updates 2:00 4 hrs

# Upgrading to FTC SDK version 4.0

Upgrading to FTC SDK version 4.0 By Arjun

FTC recently released version 4.0 of their SDK, with initial support for external cameras, better PIDF motor control, improved wireless connectivity, new sensors, and other general improvements. Our code was based on last year's SDK version 3.7, so we needed to merge the new SDK with our repository.

The merge was slightly difficult, as there were some issues with the Gradle build system. However, after a little fiddling with the configuration, as well as fixing some errors in the internal code we changed, we were able to successfully merge the new SDK.

After the merge, we tested that our code still worked on Kraken, last year's competition robot. It ran with no problems.

# Mining Base 2.0

Mining Base 2.0 By Ethan

### Task: Rethink our static robot idea

So, our dream this year is to create a static robot. Last week, we found out about a rule change that would prevent our mining robot from staying within the crater. Naturally, we found a way around this, leading us to the Mining Base 2.0.

The robot will be fixed under the lander's hooks, and have a horizontal and vertical linear slide attached to it. The horizontal linear slide would reach over the crater walls and pick up the silver balls, and shoot them up towards the lander. On the lander, our vertical linear slide would create a backboard that would allow the balls to fall into the lander. This wouldn't violate the rules as we wouldn't be in the crater. And, it would give us the benefit of having an extremely high-scoring robot.

### Next Steps

We need to start on the designs of this robot, but to do this, we first need to create a working chassis.

# Project Management

Project Management By Charlotte

### Task: Improve Iron Reign's team organization and time management

Iron Reign sometimes struggles with our team organization and time management. There have been many instances where we have fallen behind in different subteams due to this lack of organization. This year, in order to tackle this downfall, we are going to put an emphasis on project management.

We started a project in a program called Team Gantt. We learned how to use this program from watching the many tutorials in the program and by trial and error. In our project, we have made task groups that represent our subteams, such as build, code, etc. You can see this in the image above, but I did not include the whole chart to not expose any team secrets. A project manager will be in charge of keeping these subteams on track with the chart, and will update it accordingly along with periodic meetings regarding the chart and our progress. Hopefully, this will really help us in our team organization so that we don't fall behind this season.

### Next Steps

Continue the use of our Gantt chart in order to improve our organization and give us a big-picture view of our progress for the rest of the season.

# BigWheel+

BigWheel+ By Evan

### Task: Continue work on BigWheel

BigWheel has gone through a few major changes. First and foremost, it now has a flipper arm, AKA Superman. Since the robot itself is the lift mechanism, we had to put a lot of work into Superman's design. Right now it is a 10 inch REV rail attached to two 125-tooth gears for redundancy, with a custom 3D printed mount housing an pair of omniwheels on the other end. On the motors, we have two 15-tooth gears, resulting in a 3:25 gear ratio. This gives us a ridiculous amount of torque that lifts the robot up smoothly. On top of the flipper, we’ve added extra supports on the arm mounts, as when we went to the Hendricks scrimmage, we found that the two sides were out of alignment, and one was bending more forward than the other, making the arm bend unevenly to one side and throwing the whole robot out of alignment.

The next step is to strengthen the arm itself, as the two sides have a tendency to want to do their own things, mainly the side with the intake motor mounted to it. Since the supports have been put in though, Bigwheel has been functioning much better, and the arm no longer flops to one side. General wire management has also taken place, as we'd dealt with wires getting stuck in the gears.

### Next Steps

Bigwheel was built on a bit of a shabby base, mostly being made of a piece of polycarb and some aluminum bars, and not giving much in terms of change. We’ve cut here and there, drilled a few holes, unattached and re-attached a couple of things, but in all it’s a very stiff robot, and doesn’t lend itself to fluidity of design. That’s why we plan on making a second version of this base, hopefully with thinner polycarb and more secure sides that have been welded together but can be removed more easily. The exact design is still being modeled, but we have a direction to jump off from, and I believe we can make that leap to a better robot.

# Developing a CNN

Developing a CNN By Arjun and Abhi

### Task: Begin developing a Convolutional Neural Network using TensorFlow and Python

Now that we have gathered and labeled our training data, we began writing our Convolutional Neural Network. Since Abhi had used Python and TensorFlow to write a neural network in the past during his visit to MIT over the summer, we decided to do the same now.

After running our model, however, we noticed that it was not very accurate. Though we knew that was due to a bad choice of layer structure or hyperparameters, we were not able to determine the exact cause. (Hyperparameters are special parameters that need to be just right for the neural network to do well. If they are off, the neural network will not work well.) We fiddled with many of the hyperparameters and layer structure options, but were unable to fix the inaccuracy levels.

  1 2 3 4 5 6 7 8 9 10 11 model = Sequential() model.add(Conv2D(64, activation="relu", input_shape=(n_rows, n_cols, 1), kernel_size=(3,3))) model.add(Conv2D(32, activation="relu", kernel_size=(3,3))) model.add(MaxPooling2D(pool_size=(8, 8), padding="same")) model.add(Conv2D(8, activation="tanh", kernel_size=(3,3))) model.add(MaxPooling2D(pool_size=(8, 8), padding="same")) model.add(Conv2D(4, activation="relu", kernel_size=(3,3))) model.add(Conv2D(4, activation="tanh", kernel_size=(1,1))) model.add(Flatten()) model.add(Dense(2, activation="linear")) model.summary() 

### Next Steps

We have not fully given up, though. We plan to keep attempting to improve the accuracy of our neural network model.

# Meeting Log

Meeting Log October 13, 2018 By Charlotte, Janavi, Ethan, Arjun, Abhi, Justin, and Karina

### Meeting Log October 13, 2018

Sumo bots at SEM STEM Spark

### Today's Meet Objectives

Today we are taking part in a massive outreach event to teach STEM to girls all over North Dallas: SEM STEM Spark. However, we do have competitions/scrimmages coming up really soon, so we wish to get some substantial building done. See more about the event at (T-22, SEM STEM Spark).

### Today's Meet Log

• Chassis build
• We scrapped the chassis we worked on last meeting because of it lack of mounting points and poor assembly. Janavi started with just some extrusion rails and mounted some motors and wheels for a new new chassis. Hopefully we will have a working chassis by the time of the scrimmage.
• CNN Training
• Arjun continued to work on a convolution neural network, which, once the network is complete, we will compare with Open CV. We have used Open CV for our computer vision algorithms for a couple of years, but we are now looking into other options to see if CNN will be a more accurate method of differentiating between field elements. A summary of our vision decisions can be found at (E-81, Vision Summary)
• SEM STEM Spark outreach
• Besides working on the chassis and a CNN, most of us taught and shared our passion for STEM at the event. The event was 10 hours long, so it was a long haul, but we had a really great time and the girls did too.

### Today's Member Work Log

 Team Members Task Start Time Duration Charlotte Outreach 8:00 10 hrs Ethan Outreach 8:00 10 hrs Janavi Build 8:00 10 hrs Arjun Convolution Neural Network 8:00 10 hrs Abhi Outreach 8:00 10 hrs Karina Outreach 8:00 10 hrs Justin Outreach 8:00 10 hrs

# Mini Mecanum Chassis

Mini Mecanum Chassis By Janavi and Justin

Over the summer, we designed many robots for the North Texas Chassis Project, including one based off of last year's Worlds robot, Kraken. The robot chassis had 6" mechanums. But, based on what we know about this years challenge we have decided that this chassis does not utilize the 18-inch cube effectively.

We have chosen to design a chassis that is similar in function to Kraken, but smaller in size with 4" mecanum wheels.

Our plan is to design a low-lying 6" x 6" robot, a marked difference from the usual 18". However, this new design means that many of our 3D printed parts are unusable on this robot; for example, our former wheel mounts are much too large for the new robot and wheels, as well as their corresponding axles.

These bearings are hexagonal, requiring a new wheel mount design.

Justin first designed the axle plate below to solve this, but it raised the robot off the ground quite a bit, risking debris becoming stuck under the bot. As well, it was flimsy - it was mounted too far from the robot. We went back to the drawing board and brainstormed various methods we could use to attach the axle the frame in a more secure way; we found that we use a pillow block design would save space, while also having a lower-lying robot. This design worked out beautifully, leading to the design we are currently using.

The axles and wheels aren’t the only new thing about our robot: we've switched to NeverRest 20s in lieu of our normal 40s and 60s. This is another reason that we wanted to create such a minute robot. The gear ratio combined with the size will make this robot a speed demon on the field and allows us to dart between the minerals and the depositing location quickly.

### Next Steps

In the upcoming weeks we will continue to tinker with this chassis design by adding a linear side and our gathering mechanism, and hopefully, we will be able to demonstrate it at the scrimmage next week.

# Rewriting CNN

Rewriting CNN By Arjun and Abhi

### Task: Begin rewriting the Convolutional Neural Network using Java and DL4J

While we were using Python and TensorFlow to train our convolutional neural network, we decided to attempt writing this in Java, as the code for our robot is entirely in Java, and before we can use our neural network, it must be written in Java.

We also decided to try using DL4J, a competing library to TensorFlow, to write our neural network, to determine if it was easier to write a neural network using DL4J or TensorFlow. We found that both DL4J and TensorFlow were similarly easy to use, and while each had a different style, code written using both were equally easy to read and maintain.

  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 37 38 39 40 41 java //Download dataset DataDownloader downloader = new DataDownloader(); File rootDir = downloader.downloadFilesFromGit("https://github.com/arjvik/RoverRuckusTrainingData.git", "data/RoverRuckusTrainingData", "TrainingData"); //Read in dataset DataSetIterator iterator = new CustomDataSetIterator(rootDir, 1); //Normalization DataNormalization scaler = new ImagePreProcessingScaler(0, 1); scaler.fit(iterator); iterator.setPreProcessor(scaler); //Read in test dataset DataSetIterator testIterator = new CustomDataSetIterator(new File(rootDir, "Test"), 1); //Test Normalization DataNormalization testScaler = new ImagePreProcessingScaler(0, 1); testScaler.fit(testIterator); testIterator.setPreProcessor(testScaler); //Layer Configuration MultiLayerConfiguration conf = new NeuralNetConfiguration.Builder() .seed(SEED) .l2(0.005) .weightInit(WeightInit.XAVIER) .list() .layer(0, new ConvolutionLayer.Builder() .nIn(1) .kernelSize(3, 3) .stride(1, 1) .activation(Activation.RELU) .build()) .layer(1, new ConvolutionLayer.Builder() .nIn(1) .kernelSize(3, 3) .stride(1, 1) .activation(Activation.RELU) .build()) /* ...more layer code... */ .build(); 

### Next Steps

We still need to attempt to to fix the inaccuracy in the predictions made by our neural network.

# Intake Update

Intake Update By Ethan, Abhi, Justin, and Kenna

### Task: Update the intake for the new robot size

We created the corn-cob intake a few weeks ago. Unfortunately, it was a little too big for the Minichassis, so we had to downsize. So, we designed Intake Two. Continuing our history of using kitchen materials to create robot parts, we attached two silicone oven mitts to a beater bar equipped with Iron Reign's REVolution system. Then, we attached a REV Core Hex Motor to the design, then added a 2:1 gear ratio to increase the speed, as the motor wasn't exactly what we wanted.

Then, we attached our new passive sorting system. Instead of being the old, bulky sorting system, the new system is just three side-by-side bars spaces 68mm apart with tilted wings to move blocks upwards. The 68mm number is important - the size of a gold block. This allows the balls to be struck and fly upwards into the intake while sliding the blocks through the system.

### Next Steps

We need to attach this to the robot to test intake. The most likely way this'll be done is through a pivot over the walls of the crater from the top of the robot.

# Meeting Log

Meeting Log October 20, 2018 By Charlotte, Kenna, Janavi, Ethan, Arjun, Justin, and Abhi

### Meeting Log October 20, 2018

Juggling the minerals

### Today's Meet Objectives

Our first scrimmage is next weekend, so we need to complete our chassis and some sort of intake system. Every member needs to take on their own portion of the robot so we can divide and conquer to end today's meeting with a working robot.

### Today's Meet Log

• Mini-Mech chassis build
• Finally, we have a chassis. We used small mechanum wheels and a small rectangular frame which is very unusual for Iron Reign with our history of 18 in x 18 in robots. The chassis that Janavi build last weekend during the outreach event was a square, but we needed to make it rectangular to make room for motors. See more on mini-mech at (E-42, Mini Mechanum Chassis).
• Linear slide build
• Janavi and Justin worked on the linear slides that Janavi has been working on for a few weeks. Before, we had tested and mounted the slide to an existing chassis, but there were some improvements to be made. They changed the length of the linear slide from using 18 in rails to 12 in rails and added stops so that the slide don't slide out of each other. They also strung the slides so that they can extend and retract depending on the direction of rotation of the wheels.

Janavi, Justin, and some slides
• Code mentorship
• Arjun worked with a few members from Iron Star and Iron Core so that they could start programs for the robots they have been working on. A few weeks ago, Abhi gave them an introduction to coding, but Arjun helped them from the very beginning of making a new project and writing their first lines of code. Iron Reign has been utilizing GitHub for many years and we have found it very helpful, so we helped the other teams set up their own GitHub repositories and taught them how to use it.

Arjun and the phone mount

Teaching freshmen GitHub
• Intake system build
• Ethan and Abhi worked on our intake system. We are using silicone mats for kitchen counters to launch field elements into our intake system. The minerals then are filtered through 3 bars, each space by 68 mm so that balls roll over and cubes fall in. They completed the intake mechanism, but their greatest challenge is fine tuning the sorting bars and finding a way to mount it onto the chassis. Eventually, we wish to make the system pivotable, but for now we mounted it to the chassis so that it is stationary. Details about this intake system can be found at (E-44, Intake Update).

Intake mechanism with red silicon mats

### Today's Member Work Log

 Team Members Task Start Time Duration Charlotte Blog and organization 2:00 4 hrs Ethan Working on blog and intake build 2:00 4 hrs Kenna Robot build 2:00 4 hrs Janavi Linear slide and chassis build 2:00 4 hrs Arjun Build and mentoring 2:00 4 hrs Karina Robot Build 2:00 4 hrs Abhi Intake Build 2:00 4 hrs

# Off-Schedule Meeting Log

Off-Schedule Meeting Log October-2 23-2, 2018-2 to October 23, 2018 By Ethan, Karina, Charlotte, Kenna, Arjun, and Evan

### Meeting Log October 21 to October 23, 2018

Iron Reign will be attending a scrimmage on Saturday, but to attend a scrimmage, you usually have to have a working robot. As of Saturday, we did not. So, a few of our members elected to come in on Saturday to do some last minute robot additions.

• Attached lift
• We've had a linear slide that we've been meaning to hook up to the robot for awhile, and we finally did it Saturday. We mounted it to the front of the robot, as it was the easiest access point, then mounted a motor and pulley on the side to extend it. It worked - and then it didn't - as it tangled itself inside the motor, necessitating a redesign.
Then we realized a more pressing issue. Since torque is equal to force * arm length (T=FR), and the force on our robot is only the force due to gravity (F=mg), we had a torque on the lift equal to T=mgR. Then, as the lift was mounted at the very end, the torque on the arm was at its absolute maximum. And, while we're confident in our building ability, we're not that confident. So, we realized that we'd have to move the lift closer to the middle to minimize torque.
• Finished intake
• On Saturday, we worked on the red-silicone intake system, but there were still issues. We used too-long screws to mount the motor that cut into the sprocket, we mounted the fins a little to far out so that the silicone was running into them and losing energy, and we didn't have a way to mount it. First, we replaced the 15mm M3 screws with 8mm ones, ensuring that there would be no further collision. Then, we removed the beams the fins were mounted on and replaced them with a simple crossbar the we directly mounted the fins to. That way, we could adjust all of the fins at once instead of individually cutting each beam.
• Second stage
• Our robot is a little on the small side for Iron Reign. To mitigate that, we planned to add a second stage to the robot for support and to hold components like the second REV hub. So, we started on that, cutting the standoffs, and attaching one side completely so that we could use it as a proto-phone-mount.

• Moved lift
• To minimize torque, we moved the lift to the center of the robot. Now, this won't eliminate the torque - one side of the robot is much heavier than the other, but it makes it much more manageable.
• Mounted intake
• To have a functional robot, we have to have an intake *on the robot*. We had an intake, but it certainly wasn't anywhere close to being on the robot. So, we mounted a Core Hex Motor to the inside of our robot, attached a gear to our robot then bolted a second gear to our intake. Then, we attached the gear to a churro rail mounted on the robot and moved the motor to where the gears coincided. Originally, we planned to use a 30->90 gear system for a 1:3 gear ratio for a calculated 9.6 Newton-meters of torque, but this systed wouldn't fit within the size constraints, so we had to settle for a 1:1 ratio at 3.2 N*m.
• Mounted 2nd arm
• On our other robot, Bigwheel, we mounted the 2nd arm for a future beater bar. Unlike most of our robots, this one is mostly off-the-shelf, with some additional Textrix parts and a REV hub.

• Finished 2nd stage
• To be able to support our additional motors, we had to add a second REV hub. And, to do that, we had to finish the 2nd stage. This wasn't that difficult, all we had to do was attach a standard piece of REV extrusion to the remaining standoffs, then add a REV hub mount, then mount the actual hub.
• Reinforced lift
• Our lift is a little bit wobbly laterally, so we took steps to fix this. We attached a small piece of REV rail to the second stage from the lift to minimize wobbling. This still needs to be worked on, as the rail isn't mounted well, but we'll burn that bridge when we get to it.
• Strung lift
• Since our lift needs to extend and retract reliably, we have to use a double-pulley system. So, we strung upwards normally, but then attached another string to a higher up pulley that could pull the whole system back down.
• Replaced lift motor
• Our old pulley-motor was an AndyMark Neverrest 60. Now, we have nothing against these motors, but we wanted something that would be easier to connect to the REV hub. So, we replaced it with a HD Hex Motor with a 40:1 gearbox. This actually increased the torque by a negligible amount (from 4.186 N*m to 4.2 N*m), and was a more convenient change.
• Originally, we cut a box template out of polycarb that was the exact size of two silver particles. Unfortunately, we couldn't find a heat gun, so we had to go back to cardboard.
• We added the corn-cob intake from a few weeks ago onto this robot so that it can get both blocks and balls from over the crater wall.

Now, in theory, we have a competition-ready robot.

### Next Steps

We still need to program our robot and fix any gremlins that pop up; this will happen at the Friday meet.

# DISD Scrimmage at Hedrick MS

DISD Scrimmage at Hedrick MS By Charlotte, Janavi, Ethan, Evan, Justin, Karina, and Abhi

### Task: Compete at the Hedrick MS DISD Scrimmage

Today, Iron Reign competed in the DISD scrimmage at Hedrick Middle School. This was the first scrimmage of the year, so experienced teams and rookie teams alike struggled to get a working robot on the field. We go to this scrimmage every year, and it helps us gage just how much needs to be done to have a qualifier-ready robot. This year, that is a lot. We actually had two robots relatively pieced together, a main chassis and a backup, but we didn't account for many different problems that rendered them inoperable. In the case of the backup robot, the linear slide fell apart easily and was threaded so that it could only extend, and not retract. In the case of the actual robot, most of our problems stemmed from the intake system. Since we built it so recently, we were never able to write any code until in the final few days of preparation. We weren't able to debug the code and it has caused many complications in our robot. Our drive train also had many issues which we have been trying to fix and fine tune.

Due to these many issues, we did not compete for most of our matches. We spent a lot of time working on our bots and talking to other teams about their progress and plans for the season, as well as see all of the interesting ideas they have put together in fruition in a game setting. In the match we did compete in, we did very badly due to driver error and mechanical errors in the drive train.

# BigWheel Arm

BigWheel Arm By Evan

### Task: Design an arm for BigWheel

Bigwheel’s intake arm is one of the most important parts of the robot. Since our scrimmage, we have learned how to make this arm much more efficient, starting with some supports. The original intake arm was made of two scrap Tetrix rails. The result of this was that the two sides of the arm would be out of sync, creating a twist in the arm that caused it to move oddly. Thus, it has been stabilized with cross beam REV rails.

The next upgrade on the arm is going to be the box to hold the minerals. Right now it’s just a cardboard prototype and we need to move to the next version. After a bit of debate, we decided to craft it out of polycarb. The reason polycarb was not our immediate solution is because it’s unfortunately quite heavy, and instead the first thing we came to think of was thin plywood and duct tape. Thin slices of plywood would be taped together to create a fabric like box that still had form. This idea still lent itself to breakage, and we next went to a design using a thin plastic sheet, the same kind of plastic that is used inside milk cartons. The only issue is that it’s super weak and doesn’t form well, so we would have to build a frame for it, much like the plywood and tape.

### Next Steps

Right now we’re toying around with the idea of an arm that not only flips out but also extends using a gear and tooth track made from Tetrix parts of days gone by. The reason for this is to gain a little extra height that we were lacking before in the robot and a little more flexibility when we grab minerals from the crater. To do this I had to take apart the arm from our first ever FTC robot, and use the toothed track and gear plus the extra long tetrix bars to create the slides. So far the slides are surprisingly smooth and we have high hopes for the future of the arm.

# Full Circle

Full Circle By Evan

### A reflection on my time at Iron Reign

In 2012 I began competing in FTC. That year our team built a robot with a giant central arm on top of a six wheeled drivetrain that sported a ring bucket that the rings would slot into one or two at a time. The idea was that we would go bit by bit, slowly moving the rings onto the rack in the middle. This was a mediocre idea in theory, but an even worse one in practice. I think in that entire season, we only were able to score one ring, and it was when I was by myself on a practice field before a match. The whole season had led up until that moment. It was the year I learned how to wire things, how to solder wires, how to use a bandsaw, a table saw, a miter saw, and how to really think about the real world applications of what I was doing. When I scored that ring, I was so happy. I told the whole team because this is what we had been trying to do for three months without success. We never scored another ring that season, despite being in first or second place at our qualifier (which is really just a testament to how heavily you can be carried in FTC). Since then i’ve worked on, designed, and built numerous competition robots, making a smooth transition from FLL to FTC, and i’ve been there for basically every major moment in our team’s history, from the very first meeting at the Virani household to our trip to the World championship competition in Houston where we won the Motivate award. I felt the same walking up on that stage and accepting the motivate with my team as I did back in 2012 scoring that one ring. That feeling of success and pride in my work. That’s why I keep doing FTC.

I say all of this because today I had to take apart the arm of the first robot I ever built, and I thought it was a little poetic how I was using the robot I helped build in the my first season of FTC as part of the robot in my last season of FTC. It was weird. I don’t know. It was one of those rare full circle moments that you only ever get a few of and half the time you don’t even recognize them when they’re happening and never really get to appreciate them. It really just made me think back on all my years of robotics.

# Meeting Log

Meeting Log November 03, 2018 By Ethan, Charlotte, Evan, Janavi, Kenna, Karina, Justin, Arjun, Abhi, and Bhanaviya

### Today's Meet Objectives

So, we have one week before our first tournament. This isn't great. As you can see on our last blog post, we didn't do amazingly at the scrimmage. So, we have a lot of work to do.

### Today's Meet Log

First and foremost, we have to work on our presentation. So, we did an hour-long presentation runthrough to ensure all team members had the content down.

Also necessary for a good tournament is the journal. We've had a consistent 10-20 post backlog since the season started, and we've finally started cutting into it. At my current count, we're down to 7 posts left. So, we're making considerable progress on this front. Ethan already finished our strategic plan earlier this week, so all we have left is to write the blurbs and retag our posts, something we'll do on Monday.

Finally, in order to compete, we have to have a robot. Now, we have a robot, but it isn't really working. So, Evan and Karina worked on mounting an intake system, as well as reinforcing the center lever. This will ensure that the robot can actually score by the tournament.

On the code side, Abhi found the coefficients for PID so that he can start autonomous. As well, he started merging SDK 4.2 with our 15k-line base of legacy code so that we can take advantage of TensorFlow. On that note, we discovered that SDK 4.2 comes with mineral detection out of the box with TensorFlow - something that we've been working on since kickoff.

Finally, we have some good news. Iron Reign has official adopted its first new member of the season: Bhanaviya Venkat. Stay tuned for her first blog post later this week.

### Today's Work Log

 Team Members Task Start Time Duration Ethan Presentation\Journal 2:00 4 hrs Charlotte Blog Backlog 2:00 4 hrs Kenna Blog Backlog 2:00 4 hrs Janavi BigWheel Arm 2:00 4 hrs Arjun Blog Backlog 2:00 4 hrs Karina BigWheel 2:00 4 hrs Abhi Autonomous 2:00 4 hrs Evan Blog Backlog 2:00 4 hrs Justin 3D Modelling 2:00 4 hrs Bhanviya Onboarding 2:00 4 hrs

# Pose BigWheel

Pose BigWheel By Abhi

### Task: New Pose for Big Wheel robot

Historically, Iron Reign has used a class called "Pose" to control all the hardware mapping of our robot instead of putting it directly into our opmodes. This has created cleaner code and smoother integration with our crazy functions. However, we used the same Pose for the past two years since both had an almost identical drive base. Since there wasn't a viable differential drive Pose in the past, I made a new one using inspiration from the mecanum one. Pose will be used from this point onwards in our code to setup.

We start with initializing everything including PID constants and all our motors/sensors. I will skip all this for this post since this is repetitive in all team code.

In the init, I made the hardware mapping for the motors we have on BigWheel right now. Other functions will come in later.

Here is where a lot of the work happens. This is what allows our robot to move accurately using IMU and encoder values.

There are a lot of other methods beyond these but there is just a lot of technical math behind them with trigonometry. I won't bore you with the details but our code is open source so you can find the necessary help if you just look at our github!

# Torque Calculations

Torque Calculations By Karina

### Task: Calculate the torque needed to lift chassis

After seeing how well the robots that could latch onto the lander performed at the scrimmage, Iron Reign knew that we had to be able to score these points. We originally tried lifting with a linear slide system on MiniMech, but it was not strong or sturdy enough for the small chassis, and would definitely not be a functional system on BigWheel in time for competition. And so we thought why not use this opportunity to *flex* on the other teams with an alternative design? An idea was born.

We decided we would latch onto the lander using the same arm used for intake, and then pivot the main body of BigWheel up off of the ground about an "elbow joint", much like how humans do bicep curls. To do so, our motors would need to have enough torque to be able to lift the loaded chassis off the ground once the arm hooked onto the latch. First, we measured the mass of BigWheel. Then we found where the center of mass was located. The distance from the pivot point to the center of mass became our lever arm, also known as the radius.

Calculating torque required knowing the forces acting on BigWheel at its center of mass. In this case, there was only the force due to gravity (F = mg). Before we could plug BigWheel's mass into the equation, we converted to units of kilograms (kg), and then used the value to find the newtons of force that would oppose the upward motion:

Finally, we plugged the force and radius into the torque equation:

### Next Steps

The next step is to test which gear train will output this torque value based on the motors used and the gear ratio.

# Linear Slide Lift

Linear Slide Lift By Janavi

### Task: Design a lift for MiniChassis

For extension both into the crater and lifting our robot up to the crater we have decided test a linear slide system. We plan to utilize linear slide system for both vertical and horizontal extension on MiniMech.

Horizontal Extension Goals

• Long Enough to reach Crater from distance
• We need to determine how many stages we need

Vertical Extension Goals

• Long Enough to reach lander
• Strong enough to support robot weight

When designing a lift we need to determine the optimal gear ratio to allow our lift system to lift the robot but still do it relatively fast. Realistically looking at the aluminum parts we are using we plan for the robot to be around 35 lbs. We also know that the lander is 22 inches above the ground and we plan for the linear slide to extend to 14 inches off the ground This would mean that the point of rotation for our hook mechanism would be 22 inches - 14 inches = 7 inches below the latch on the lander.

We plan to use REV 40:1 motors that have 594.7 oz*in. Now using these calculations we can determine our needed gear ratio.

This gear ratio of 6.6 means that for our robot we need a motor to gear ratio that needs around seven rotations of the motor to provide one rotation of the hook.

We knew the max weight of the robot would be around 20 pounds since the total weight of all the parts in the kit is less than 20 pounds. The point of rotation for the hook would be around 5.5 inches below the lander latch. This is because the bottom of the hook is around 22 inches above the ground and the point of rotation will be around 16.5 inches off the ground so that we can account for space for a gear while staying within the 18 inch box. Below is the torque calculation.

# RIP CNN

RIP CNN By Abhi

### Task: Farewell Iron Reign's CNN

FTC released new code to support Tensorflow and automatically detect minerals with the model they trained. Unfortunately, all of our CNN work was undercut by this update. The silver lining is that we have done enough research into how CNN's work and it will allow us to understand the mind of the FTC app better. In addition, we may retrain this model if we feel it doesn't work well. But now, it is time to bid farewell to our CNN.

### Next Steps

From this point, we will further analyze the CNN to determine its ability to detect the minerals. At the same time, we will also look into OpenCV detection.

Today, we built mounts to attach both types of intake to the rack; the rack-and-pinion corncob intake and the red-flapped intake. We also created a new way of mounting the arm to the chassis. The idea is that since it’s attached to the rack and pinion track, it reaches high enough for the robot to put the minerals in the lander. We made the arm with a 12-86 gear ratio. Our next plan is to create the mount, minimizing the size of the arm.

The final addition is a tail for the robot to be able to stop itself from flipping backwards, something that is a very real danger of the design. It will probably be made of polycarb with aluminum or steel support on either side, just in case the polycarb is not enough to support the push of the robot. Part of this process will involve some code tuning so that the robot stops itself, but the tail is necessary as a preventative measure.

### Next Steps

There’s still a lot of stuff we will have to do to prepare the robot physically for the competition this Saturday, but I believe it will get done.

Conrad Qualifier By Ethan, Charlotte, Karina, Janavi, Bhanaviya, Abhi, Arjun, Evan, and Justin

Right off of a mortifying experience at the Hendricks MS Scrimmage, in which we got the worst score at the tournament (and in the one match we did participate in, our robot broke) we walked in on shaky ground. In the week leading up to the tournament, Iron Reign worked hard, with 35 commits to the blog, and countless changes to our robot.

##### Inspection

Our robot fit well inside the sizing cube. However, we were warned for our rats' nest of wiring at the base of our robot, as well as the fact that our metal-frame base had sharp corners.

##### Presentation

We walked in, and started off out strong. Half of a good presentation is the energy, and we had more energy than some of our other presentations last year. Unfortunately, that energy petered out as we stuttered and tripped over ourselves. We got our information across, but not as well as we should have, and we didn't have enough time for questioning.

##### Robot Game

We didn't really have a working robot, but we tried our best. Unfortunately, our best wasn't great.

###### Match 1

We lost, 33-135. We deployed the wrong autonomous and couldn't drive - a total wash.

###### Match 6

We lost, 15-70. Our robot's linear slide seized up, bringing our robot outside of sizing limits, so we had to sit out the match as we hacksawed through our intake.

###### Match 11

We lost, 47-122. Our autonomous worked! (but our team marker didn't deploy).

###### Match 13

We lost, 65-196. Our robot didn't work, we just drove ourselves around aimlessly.

###### Match 15

We lost, 10-167. This time, none of our robots worked!

In summary, a disappointing result.

###### 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 five separate groups of judges come up to us and ask us about *every* component of our team, from business, to volunteering, to code, to design. 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 five separate groups of judges come up to us and ask us about *every* component of our team, from business, to volunteering, to code, to design.

In the ceremony, every single member of SEM Robotics waited. Iron Star had been the 4th alliance captain; Iron Core had demonstrated gracious professionalism; Iron Reign had multiple in-depth discussions with judges; Imperial had an exceptional journal. We watched each team get nominated for awards, but only that, and fall short. In particular, Iron Reign was nominated for every award but Innovate. 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 don't want to completely embarrass ourselves.

# Code Post-Mortem after Conrad Qualifier

Code Post-Mortem after Conrad Qualifier By Arjun and Abhi

Iron Reign has been working hard on our robot, but despite that, we did not perform well owing to our autonomous performance.

Our autonomous plan was fairly simple: perform sampling, deploy the team marker, then drive to the crater to park. We planned to use the built-in TensorFlow object detection for our sampling, and thus assumed that our autonomous would be fairly easy.

On Thursday, I worked on writing a class to help us detect the location of the gold mineral using the built-in TensorFlow object detection. While testing this class, I noticed that it produced an error rather than outputting the location of the gold mineral. This error was not diagnosed until the morning of the competition.

On Friday, Abhi worked on writing code for the driving part of the autonomous. He wrote three different autonomous routines, one for each position of the gold mineral. His code did not select the routine to use yet, leaving it open for us to connect to the TensorFlow class to determine which position the gold mineral was.

On Saturday, the morning of the competition, we debugged the TensorFlow class that was written earlier and determined the cause of the error. We had misused the API for the TensorFlow object detection, and after we corrected that, our code didn't spit out an error anymore. Then, we realized that TensorFlow only worked at certain camera positions and angles. We then had to adjust the position of our robot on the field, so that we could.

Our code failure was mostly due to the fact that we only started working on our autonomous two days before the competition. Next time, we plan to make our autonomous an integral part of our robot, and focus on it much earlier.

### Next Steps:

We spend more time focusing on code and autonomous, to ensure that we enter our next competition with a fully working autonomous.

# Materials Testing Planning

Materials Testing Planning By Ethan

### Task: Design a lab to test nylon properties

So, Iron Reign is used to using off-the-shelf materials on our robot: silicone oven gloves, ice cube trays, nylon 3D-printed parts, and more. But, we've never actually done a thorough investigation on the durability and efficacy of these parts. Because of this, we've had some high-profile failures: our silicone blocks breaking on contact with beacons in RES-Q, our nylon sprockets wearing down in Relic Recovery, our gears grinding down in Rover Ruckus. So, we're going to do an investigation of various materials to find their on-robot properties.

#### Nylon Testing

A majority of the 3D-printed parts on BigWheel are nylon - we find it to be stronger than any other material save ABS, but much less prone to shattering. Still, we still deal with a substantial amount of wear, and we want to find the conditions under which damage happens.

So, to start, we are printing a 4.5" x 1.5" block with a thickness of 4mm with an infill of 60% out of nylon. We chose these values as our average part is about 4mm thick, and our high-strength nylon pieces are about 60% infill. Then, we are going to test it under a variety on conditions meant to simulate stressful operation. As well, we're going to measure other values such as coefficient of friction using angle calculations.

#### Silicone Testing

Similarly, we use the silicone oven mitts on our intake; we find that they grip the particles pretty well. 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 video-analysis. In addition, we wish to test the coefficient of friction of the mitts to see if a better material can be found.

### Next Steps

We are going to perform these labs so that we can compare the constants we receive to commonly accepted constants to test our accuracy.

# Conrad Qualifier Post Mortem - Short Term

Conrad Qualifier Post Mortem - Short Term By Ethan, Bhanaviya, Janavi, Charlotte, Kenna, Arjun, Justin, Janavi, Karina, and Abhi

Iron Reign didn't necessarily have the best time at Conrad. As shown in last week's tournament post, the day had its ups and downs. Even though it was a successful tournament overall, there's much that we could do better.

#### Problems:

##### The Robot

First, the robot didn't perform well. So, we're beginning our analysis from the mindset that everything must be changed.

• The Intake
• The intake itself had a multitude of problems. First and foremost, we actually didn't have a way to contain the particles from the intake. Being that Rover Ruckus' primary way of scoring is by depositing the particles into the lander, this was a pretty big oversight. To solve this, we plan to add a catcher at the bottom of the intake using this template.

As well, our linear slide locked up in the middle of the tournament, preventing our intake from extending. Now, we have latches that keep the intake from retracting without human assistance.

• Superman Arm
• This impressed the judges a lot and was one of the more reliable parts of our robot. However, there were still issues. First and foremost, the arm became misaligned so that the gears began to grind during the judging presentation. This was an easy fix - we just adjusted a set screw - but we need a more rigorous solution. Right now, we're considering metal gears instead.

##### The Presentation\Judging

We didn't have much practice with our presentation. Some of the more major issues were slide order (~5 second gaps between people talking, stuttering due to unfamiliarity with content, and energy (a majority of the members present had held an all-nighter so we weren't really awake).

We plan to revamp our presentation, adding to the story of BigWheel's development. Plus, we'll have all of our members in the next presentation, which'll be a major help. We need to do more practice, but that's a given.

Another thing that we fell short on was the Innovate Award (the only award that we weren't mentioned for). A good portion of this is that the Innovate Award rubric emphasizes that the robot needs to work; ours really didn't. However, we need to take a retrospective look at our mechanism insofar that we need to show our difference between us and other robots.

##### Programming

Despite our all-nighter and prior large codebase, we were pretty short on workable code. So, while our driving worked, not much else did. We had an theoretical autonomous, but it remained only that.

Next, we need to work on our Pose class (the one that determines the position of the robot on the field). From there, we need to add autonomous enhancements, allowing us to drive a little better. The most efficient use of our time could be put toward raising our robot to score and latch, as well as TensorFlow recognition of the minerals.

# Meeting Log

Meeting Log November 17, 2018 By Charlotte, Karina, Kenna, Janavi, Evan, Justin, Ethan, Arjun, Bhanaviya, and Abhi

### Meeting Log November 17, 2018

Evan working on the robot!

### Today's Meet Objectives

We are going to discuss multiple facets of our team (presentation, engineering journal, organization, etc) with alumni Jayesh and Lin. What we hope to gain out of our conversation is an outside perspective. In addition to this conversation we wish to continue in our reflection of the tournament last weekend and preparation for our next tournament.

### Today's Meet Log

• Organization
• Karina and Janavi spent a large portion of practice organizing all of our parts and tools. They organized our drawers, carts, and tent. Organization has historically been a weak spot for Iron Reign, so this year we really want to crack down on that problem, as discussed in (T-13, Organization!).
• Superman arm and wire organization
• Evan, Kenna, Janavi, and Karina were all making improvements on our robot, notably working on problems we found at the tournament last week. These problems mostly dealt with wire organization and our superman arm. Analysis on why the superman arm broke can be found at (E-63, Code Issues Break the Superman Arm). More about how we fixed these issues can be found at (E-65, Arm Repairs).
• Blogging mentoring
• Also, Bhanaviya is learning to make blog posts. We showed her our blog post guides and answered any questions she had. Expect to hear from her soon.
• Alumni Meeting and Feedback
• The main focus of today's meeting was speaking to our alumni Jayesh and Lin who are both in their sophomore of college. They were both founding members of Iron Reign, they were in their senior year the first time we went to supers. More details on this meeting and our post-mortem can be found at (T-27, Conrad Qualifier Post Mortem - Short Term).
• Presentation feedback
• First we discussed our presentation lacked energy and enthusiasm, which is a common problem in our presentations. We have great enthusiasm for our work and progress, but we have trouble expressing it on early morning competition days. This could also be improved by lots and lots of practice, so we don't ever have to focus on our memorization, rather focusing on the expression of our passion for robotics.
• Engineering journal feedback
• Also, they provided insight on our engineering journal, which they said needs more cohesiveness between posts. This takes the form of adding links to older blog posts that reference future ones after we have written them.
• Mentorship feedback
• Finally, we discussed the new teams we have started, Iron Core and Iron Star, and asked for their advice on how to approach mentoring the new recruits. They told us that rather than waiting for them to seek us out, we need to seek them out, as many of the recruits don't have the confidence to approach us, since many of our team members are upperclassmen. We want to let them know that Iron Reign is here to help them in any way possible and to make our workspace one of collaboration and the transfer of ideas through the teams and grade levels.

### Today's Member Work Log

 Team Members Task Start Time Duration Karina Organization and Build 2:00 4 hrs Abhi Conversation 2:00 4 hrs Evan Robot build 2:00 4 hrs Charlotte Blog and organization 2:00 4 hrs Ethan Working on blog 2:00 4 hrs Kenna Robot build 2:00 4 hrs Justin 3D Modeling 2:00 4 hrs Janavi Organization and build 2:00 4 hrs Bhanaviya Learning to Blog 2:00 4 hrs

# Chassis Mark Two Planning

Chassis Mark Two Planning By Ethan

### Task: Plan a new BigWheel chassis

Our next tournament is a while away, in about two months. So, we have a little bit of time to redesign. And, our current chassis has plenty of faults.

Our original BigWheel base.

First and foremost, our chassis was built for a testing competition, not to be a full fledged competition robot. As such, it's a little lacking in features that would be normal on such a robot such as mounting points for other components, durability, and free space. So, we need a redesign that allows for greater modularity and functionality.

We're starting from the ground up; our current base is a square metal frame with a polycarb bottom. While this is a good start, it has some issues: the base seems to be a little wobbly due to the polycarb, there's only one level of construction, so our motor mounts, REV hubs, and supports compete for space, and we have to add all the counting points ourselves.

The main way to prevent the wobbliness is by replacing the polycarb with something sturdier, as well as not having everything simply bolted together. Thus, we're going to dive headfirst into the next step - welding. We plan to cut a base out of aluminum as well as four side plates to create a dish-like shape. Then, we plan to TIG weld these plates together (TIG welding uses a tungsten electrode in contact with two separate metal plates in combination with a filler metal that melts and joins the two plates together).

Basic design for the newest version of BigWheel.

### Next Steps

We plan to cut the aluminium next week, and TIG weld the pieces together the week after that. We're beginning to train a few of our members on TIG welding and we already have some of the safety equipment to do so.

# Conrad Qualifier Post Mortem - Long Term

Conrad Qualifier Post Mortem - Long Term By Ethan

### What could have gone better?

This is a document for analyzing what we can do better, not just what went wrong at the Conrad qualifier. The format of this will be in issue > solution format.

#### Prep

• Lack of tools and parts
• Pack tools the week before - involves better organization overall
• Bring failsafes & extra parts - prevents costly errors
• Little presentation practice
• Cut down powerpoint - optimally 8 minutes
• More practice - seamless transition
• Order - we need to tell a story
• Journal prep
• Same issue - we need to organize the journal to tell a story
• Lack of images - backdate images in blog posts
• Lack of diagrams - explanatory
• Lack of continuity - link posts together to show how components of team have changed
• Need to write real control award

#### Programming

• Autonomous
• No autonomous - need to have functional autonomous
• TeleOp
• Robot easily breaks - need to create presets to prevent

#### Build

• Lift
• Lift linear slide broke - need to redesign with new linear slides
• Intake
• Intake did not actually move - need to reattach motors

#### Other

• Presentation
• Map slides to articles in journal
• Review judging rubrics

# C.A.R.T. Bot Side Shields

C.A.R.T. Bot Side Shields By Ethan

### Task: Design sideshields for the Townview Tournament

Iron Reign takes pride in the Townview Tournament; we really enjoy making it a great experience for everyone. One small way we plan to improve the tournament is to turn our MXP into a robot repair shop for broken robots. In addition to this, we're turning CART Bot into an ambulance to carry broken bots that need repair. To do so, we're wiring a flashing light to the cart, as well as printing giant sideshields on either side. The shields are above.

# Friction Coefficient and Energy

Friction Coefficient and Energy By Ethan

### Task: Measure the coefficient of friction of our oven mitt intake

We want to measure various constants of materials on our robot. Earlier this season, we found that a nylon-mitt collision on our intake sapped the rotational energy of our intake. But, that was just a build error, easily fixable. But now, we plan to measure the energy lost from particle-mitt collisions, and the first part of this is to find the coefficient of friction of the silicone mitts.

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

From these calculations, we determined that the only factor to measure to determine the coefficient of friction between blocks and the mitts is the angle of incline. Therefore, we created a simple device to measure the angle at which slippage begins to occur.

The angle was about 27 degrees, so the coefficient of friction is equal to arctan(27)=0.44. This is a pretty good coefficient of friction, meaning that the intake is very efficient in bringing the particles in, but it also means that the intake loses more energy on collision.

### Next Steps

We need to measure further constants such as stretch and wear of nylon. To do so, we're printing a simple testing nylon block.

# Meeting Log

Meeting Log December 01, 2018 By Charlotte, Ethan, Kenna, Evan, Abhi, Justin, and Bhanaviya

### Today's Meet Objectives

We plan to prepare for a few events coming up, the tournament we are going to host at Townview and our presentation to the Dallas Personal Robotics Group. As well, we plan to continue building our robot and improve on the superman arm in preparation for our next competition in January.

### Today's Meet Log

• Hosting a qualifier
• The Townview qualifier is coming up in just a few weeks, and we are starting to make preparations. Ethan is making a wrap for Cart Bot that emulates an ambulance, so we can stock the cart with tools and drive it around to help teams during the competition.

Ethan designing
• Robot materials testing
• This year, we want to continue our materials testing in order to ensure our robot is efficient. Here is Ethan performing one of these tests, measuring the friction of different materials we might use for an intake system. Further information on the tests can be found at (E-59, Friction Coefficient and Energy).

Materials friction testing

• Justin kept working on the 3D model, which is essential to complete as we are trying to improve the various systems on our robot, especially the Superman arm and other complicated mechanisms.
• Blog training
• A universal responsibility for Iron Reign members is writing blog posts. We taught Bhanaviya how to use GitHub and Notepad ++ so that she can write her own blog posts and post them to the blog.
• DPRG prep
• Abhi is preparing a demo in preparation for our meeting with the Dallas Personal Robotics Group (DPRG). We are going to show off our robot's computer vision capabilities and the strides we have made to train our own neural network. We expect to receive a lot of specific questions about this. Our presentation will be an hour long. To see how our presentation went, read (T-31, Presenting to the DPRG).

### Today's Work Log

 Team Members Task Start Time Duration Abhi Code 2:00 4 Ethan Blog & Testing 2:00 4 Evan Build 2:00 4 Charlotte Blog 2:00 4 Bhanaviya Blog 2:00 4 Karina Build 2:00 4 Justin Modelling 2:00 4 Kenna Social Media 2:00 4

# Selecting Lift System

Selecting Lift System By Janavi

### Objective: Determine the type of lift system will allow us to delatch and reach the lander

In our past post Choosing Drive Train we decided that we will use the chassis BigWheel. After deciding the base we need to now think about the lift system that we want to use to allow us to both deposit into the lander and latch onto it. Evan and I have been experimenting with linear slides to use for our lift. I have been working on a REV linear slide lift system as referenced in the post "Linear Slide Lift". Evan has been working on a separate ball bearing linear slide. As well as these two options we are looking into past linear slides and ones that we have seen teams use in past challenges. We need to determine which of the linear slides works best based on the game requirements this season

##### Linear slides needs according to game
• Lift and lower robot from latch on lander
• Extend out to Crater from distance to collect minerals
• Extend out vertically to lander to deposit minerals

##### What we want our linear slide to have
• Light Weight
• Bidirectional (Able to collect from crater and deposit)
• Speed
• Sturdy
• Easy to fix and maintain in case of emergency
• Small in size
• Extend out to around 5 ft in height

##### Linear Slide Options
• Ball Bearing Lift
• Heavy
• Smooth
• Reliable
• Never used the before
• Drawer Slides
• Heavy
• Low cost
• Unwieldy
• Familiar as we used them last year
• REV Linear Slides
• Light Weight
• Not very reliable
• Familiar

### Next Steps

We need to select the best linear lift system for our chassis based on the requirements we set above.

# Linear Nylon Strength Test

Linear Nylon Strength Test By Ethan

### Task: Measure linear nylon wear

We've had some issues with our nylon sprockets, mainly through excessive wear and tear. So, we want to test what circumstances cause what deformation.

##### Linear Deformation

This one was simple. We printed this block with 60% infill (the highest infill we tend to use), measured its length (3.75") and hung one end from our deck. On the other end, we inserted a bar and attached 180 lbs of mass to it, then we measured its new length (3.8"). Thus, the constant of deformation is [weight]/[change in length] = 650 kg/cm. This demonstrates that linear transformation isn't Iron Reign's issue, as the highest possible weight put on any nylon piece on our robot is ~27 lbs/12.25kg.

However, there is other damage. After testing, we found internal damage in the nylon from where it was hanging.

### Next Steps

Next, we need to test the rotational damage that nylon incurs through friction. We plan to design a simple rotational sprocket and run it on a motor for a set amount of time and measure the wear to determine wear per unit time.

# Code Issues Break the Superman Arm

Code Issues Break the Superman Arm By Abhi

### Task: Analyze the code issues that led to our robot breaking

After constant use, our robot's Superman arm broke. At this point, it is important to analyze our failures. This error was not because of a build issue but rather a code and driver control issue.

When testing, we always heard the gears grinding some times and we thought it wasn't an issue. There were instances like once when we accidentally made the robot stand up under a table. Other times, the robot would press the arm down into the foam and keep pushing when it couldn't really keep going, leading to grinding.

Not only did the arm break but also the Superman mechanism. This broke mainly because we didn't set proper ranges of motion of the arm and the gears would grind when there was interference. Because of the damage, we can't use the existing gears.

### Next Steps

We intend to gang up the gears and make the mesh stronger to fix the build side of things. In the code, I already added the software limits to motion so we don't have those problems anymore.

# Arm Repairs

Arm Repairs By Evan and Abhi

### Task: Fix elbow and Superman

This is a follow up to Post E-64, Code Issues Break the Superman Arm. We made some hustles and got them fixed. We reinforced Superman by ganging up multiple gears (as seen above) and repeated a similar process with the elbow arms. Hopefully this will make BigWheel more secure, especially with software limits in the code.

# Rotational Nylon Wear Test

Rotational Nylon Wear Test By Ethan

### Task: Test the amount of wear on a moving nylon part over time

After our last tournament, we noticed several 3D-printed sprockets that had worn down significantly. So, we wanted to measure how much wear one of our nylon sprockets takes per second.

First, we printed out a model of one of the REV sprockets, using the STEP file here. We printed it with ~45% infill, our average for sprockets and other parts. Then, we attached a REV Core motor to an extrusion, then mounted the nylon sprocket on the other side. Then, we measured the length on one of the teeth. We ran the motor for 1:05:45, and then measured the length afterwards.

So, the tooth length before was 5.3mm, and after, it was 5.23mm, for a difference of 0.07mm. Then, we ran the system for 1:05:45. This results in a wear rate of 1.77*10^5 mm/sec. So, given that we use our robot for about an hour, cumulatively, in a tournament, 0.0638mm, or 1.2% of the sprocket. This is enough to be noticeable under loose-chain conditions and indicates that we should keep extra sprockets at tournaments so that we can do a quick replacement if needed.

### Next Steps

We plan to perform more materials testing in the future; in particular, we'd like to determine the wear rate of the regular REV sprockets as well, but this requires a more rigorous experiment.

# Selecting Intake System

Selecting Intake System By Janavi

### Objective: Determine the type of intake system that will allow us to efficiently obtain and deposit minerals within the lander

In our post "Selecting Lift System" we decided that the linear slide system that we will use is the MGN12H rails also referenced to as the Ball-Bearing slides. These slides while heavy provide the smoothest option. now that we have chosen the Lift system we need to determine the intake system that will allow us to take in two minerals and deposit them in the most efficient way possible. Throughout this season already we have been experimenting with different types of intake systems as seen in posts like "Pool noodle intake" and "Selective Intake" and "Scoring Mechanism"

##### Intake System needs according to game
• Collect only two minerals
• Sort between silver and gold minerals

##### What we want our linear slide to have
• Light Weight
• Speed of intake mechanism
• Sturdy
• Easy to fix and maintain in case of emergency
• Small in size

### Passive Deposit vs Passive Intake

 Pros Cons Passive Deposit Faster intake Could be unreliable if not positioned correctly Passive Intake More accurate Harder to intake and therefore we score less

### Intake Mechanism Material / Shape

 Pros Cons Ice Cube Tray Compliant and smooth Not a far reach Surgical Tubing Farther reach Possibility of missing minerals due to sporadic behavior of surgical tubing Pot holder Brings in minerals Not far reach and too compliant Octopuckers ( from last year's season ) Experience with using material Too stiff and not far enough reach

# End of TIG Welding

End of TIG Welding By Evan

### Task: Detail TIG welding plans and why they failed

At the beginning of the season, we saw that our robot base was not as well crafted as we originally thought it to be. While we have worked to correct it over the season, it’s still not what we wish to see in a functional robot, and we came up with the idea of making the frame from light aluminum instead of the polycarb, and fix it with TIG welding.

It seemed like a good idea at the time, but there were many other problems on the robot more important than a new base. So we pushed the TIG plan to the side, in lieu of correcting other issues like the lift and the intake. While we won’t completely throw the idea out, it will be a while before we begin to start the project. Also hindering us is the amperage output of the home, which is too low to run the TIG welder off of. Until we get additional amperage to the house, our plans will be on hold but not forgotten.

# The Return of BatteryBox

The Return of BatteryBox By Ethan

### Task: Create a charging station for our phones and batteries

A long time ago, in a land far, far away, Iron Reign once had a battery box. This was a fabled land, where all batteries remained charged and phones roamed the land, happy and content with their engorged batteries. But, this land was neglected, with the meadows of electricity growing dim, the plastic of the land cracking and scattering to the four corners of the Earth, and those who found their home there lost to the void.

We have a problem keeping our phones charged at tournaments and in practice. So, we made a simple battery box to fix it. We used an old REV container and cut some spare wood to create dividers, cut a hole for a surge protector, and we were a go.

### Next Steps

Iron Reign really needs to work on its organization in general, and this was just one way to stem the tide of entropy. We need to revitalize our tournament kits of tools next.

# BigWheel Arm Locks

BigWheel Arm Locks By Evan

### Task: Create locks to keep BigWheel's intake arms in an extended position

An important part of this year's challenge is scoring minerals in the lander. Additionally, our upright elbow cannot raise the scoring mechanism to the lip of the lander alone. Thus, we had to create a way to get those additional inches to score.

First, we tried a REV linear slide design. This worked, but barely. It repeatedly got stuck, at one point even needing to be sawed apart at a tournament due to its inoperability. So, we switched to a new brand of linear slides, the MGN12H with 12mm steel rails. But, since we were no longer using REV, we needed a new design to keep the arms in the extended position.

The new design relies on gravity. When the robot is on the lander in the hanging position, it will stay within the sizing cube. However, as it descends, the linear slides will glide upward, staying attached to the lander until the robot contacts the mat. And, as the slide finishes moving, it will move over a triangular piece of polycarb such that it is easy for the slide to move up, but near impossible to reverse its direction. This will ensure that the robot's arm stays extended.

### Next Steps

We need to reattach the mounting point for hanging in order for this system to work.

# Scoring Mechanism

Scoring Mechanism By Janavi and Abhi

### Task: Create a way to hold minerals

We now have a lift and an intake system, but we're missing a way to hold onto and deposit the minerals after intake. To achieve this, we created a prototype.

We wanted to create a box-like shape that can be attached to a moving axle to hold the minerals when lowered. When the lift is up in the air, the axle can rotate to lower the box and let the minerals fall into the depot. We tested out multiple designs but we ended up having to nix that as there was no way to get the minerals out of the box once they were in.

Our second design was a sloped shape: just steep enough to hold onto the balls but not so steep that the balls couldn’t escape. To create this shape, we decided to have a rectangle attached to an axle able to hold the minerals when down and deposit the minerals when spun. We created multiple variations with different sizes as can be seen in the drawing below. We eventually settled on was design B, a square that was 155 cm by 155 cm.

We decided to not use design A as it was simply too large and continuously hit against the edge of the rail. We progressed to a smaller size of 155 mm by 155 mm (design B) that worked well. We attempted another design of two separate backs as two separate channels for the minerals (Design C). However, we decided this wasn't a very good design because there was an increased chance of the ball getting stuck in between the channels, causing either a penalty or a decrease in the number of balls we can control.

After creating the back of our holder, we realized that we needed to elevate it off the back of the rails at an angle. It was the only way to hold the balls and allow them to come down a ramp when the axle is spun. We decided that the best way to achieve this was through two wing-like triangles on the side that we could bend to ensure the minerals couldn’t escape out the side. We went through multiple designs as can be seen below

At first, we attempted to attach two right angle triangles with 155mm acting as a leg of the triangle. We varied this design by increasing the angle of the slope so that the balls would be held at an angle that allows them to not slip. But, after creating this design out of cardboard and attaching it to the axle, we saw that the sharp angle interfered with the beater bar. To amend this, we changed the triangle attached to the end of the rectangle to have the 155 mm side be the hypotenuse of the triangle. Again, we varied the design in the steepness of the triangle. Through this, we determined that a slope of around 30 degrees was the best design.

After finalizing our design, creating it out of cardboard, and attaching it to our robot, we cut the piece out of polycarb. We bent the side triangle using heat and drilled in the holes to attach the axle with.

### Next Steps

Although this design works well, we want to continue to change and improve upon it. For example, the next way we can improve the design is by changing the way that the polycarb is attached to the axle through a 3-D printed attachment.

# Meeting Log

Meeting Log December 22, 2018 By Charlotte, Ethan, Janavi, Bhanaviya, Evan, Arjun, and Abhi

### Today's Meet Objectives

Our goals for today include a battery box, repair and improvement of our intake system, and organization.

### Today's Meet Log

• Intake redesign
• On the robot, we are resizing the intake system as a whole so that it folds in completely and fits within the 18 by 18 sizing requirement. Our biggest focus today was on our intake system, notably building a system that deposits the minerals. We plan to create the system out of polycarb, but first we are prototyping with cardboard. There are two versions we have prototyped so far, as you can see below.

Version 1: too wide and the triangle flaps were improperly cut so the edges interfere with the intake

Version 2: fixes problems above, with the hypotenuse of the triangular flaps on the main part of the carrier
• Tournament organization
• Ethan made a battery box out of an orange REV starter kit and sawed some wood to fit snuggly in order to have some dividers. Finally we drilled a hole in the side for the power strip cord.
• Neural network training
• Arjun is working on our neural network for which we need to capture more training data. He is creating a program that will have the robot take pictures & capture the data we need as it drives. We had a bare-bones autonomous for the qualifier, so over the break we want to revamp our autonomous so that we can incorporate the neural network we are training more effectively. To see more about our vision training, see (E-28, CNN Training Program).

### Today's Member Work Log

 Team Members Task Start Time Duration Arjun Neural network data collection 2:00 1 Janavi Prototyping 2:00 1 Bhanaviya Prototyping 2:00 1 Ethan Blog 2:00 1 Evan Build & Prototyping 2:00 1 Charlotte Blog 2:00 1 Abhi Prototyping 2:00 1

# Creating Side-Latches

Creating Side-Latches By Evan

### Task: Allow the robot's arms to stand on their own

The issue with the lift is that many of the pieces that need to be made require specificity that’s hard to obtain using aluminum parts, so we chose polycarb. The key to making these specialized parts is a small butane torch held at just the right distance. Run the torch back and forth across the part where you want to bend, in the pattern of the bend you’re trying to achieve, watching closely for the first air pocket. Once you’ve spotted it, bend it. For tight, right angle bends, press the piece of polycarb against a hard surface until the right angle is achieved. If there’s an issue in your bend, simply heat it up again. This, however, weakens the piece so try not to do it on pieces that need to bare a load. We had to bend a complex piece, and while, it doesn’t look super complex in the picture, it had very precise requirements so that everything could slide together in unison. The part we made went in between the two linear slides on the arms to the 3d printed latch we created, and worked very smoothly. While polycarb is not the best at retaining strength over distance, it’s worked well in this instance.

### Next Steps:

The next stage for this will be to make these brackets out of steel once we have access to the forge. This will result in a new, stronger version, which will hopefully eliminate a potential point of failure in our current robot.

# Meeting Log - Dec. 19, 2018

Meeting Log - Dec. 19, 2018 December 29, 2018 By Ethan, Evan, Janavi, Karina, Abhi, and Arjun

### Meeting Log December 29, 2018

Hello and welcome to the Iron Reign Holiday meet. We've got a few meet objectives today, namely:

• Autonomous
• BigWheel Side Plates
• PowerPoint Revisions
• Blog Post Backlog
• Tent Cleanup
These aren't all super-top priorities for us, but they all need to get done. And, as we're working with a skeleton crew, we might as well.

So, first, Janavi, Abhi, and Ethan cleaned the tent, preparing it for autonomous testing. To do so, they got some freshmen to take up their robot parts as they cleaned and organized the field. We were missing a surprising number of tiles, so we had to replace them. As well, the recent rain had weakened the wood lying underneath. We're not going to do anything to fix this right now, but we really should.

Next, we did PowerPoint revisions. Our presentations have always run over the 15 minute time limit, and we really need to fix it. As well, we want to change our presentation order such that we start off with the weakest award (motivate) and end on a strong note. We deleted about 5 slides, added 1, updated the Townview Tournament slide, and fixed some typos. We figure that this'll cut down our time and streamline the process.

In the meantime, Ethan updated old blog posts and fixed broken images on the blog. Some examples of this are the Superman Arm's breakage, the old shields, Friction Test, and Battery Box posts. This took a significant amount of time.

Finally, we had to cut new shields for the robot arms. These prevent the arms from moving back downward, allowing our robot to score in the lander. Evan measured these and melted them today, and plans to cut them next practice.

# Refactoring Vision Code

Refactoring Vision Code By Arjun

Iron Reign has been working on multiple vision pipelines, including TensorFlow, OpenCV, and a home-grown Convolutional Neural Network. Until now, all our code assumed that we only used TensorFlow, and we wanted to be able to switch out vision implementations quickly. As such, we decided to abstract away the actual vision pipeline used, which allows us to be able to choose between vision implementations at runtime.

We did this by creating a java interface, VisionProvider, seen below. We then made our TensorFlowIntegration class (our code for detecting mineral positions using TensorFlow) implement VisionProvider.

Next, we changed our opmode to use the new VisionProvider interface. We added code to allow us to switch vision implementations using the left button on the dpad.

Our code for VisionProvider is shown below.

 1 2 3 4 5 6 public interface VisionProvider { public void initializeVision(HardwareMap hardwareMap, Telemetry telemetry); public void shutdownVision(); public GoldPos detect(); }  

These methods are implemented in the integration classes.
Our new code for TensorflowIntegration is shown below:

  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 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 public class TensorflowIntegration implements VisionProvider { private static final String TFOD_MODEL_ASSET = "RoverRuckus.tflite"; private static final String LABEL_GOLD_MINERAL = "Gold Mineral"; private static final String LABEL_SILVER_MINERAL = "Silver Mineral"; private List cacheRecognitions = null; /** * {@link #vuforia} is the variable we will use to store our instance of the Vuforia * localization engine. */ private VuforiaLocalizer vuforia; /** * {@link #tfod} is the variable we will use to store our instance of the Tensor Flow Object * Detection engine. */ public TFObjectDetector tfod; /** * Initialize the Vuforia localization engine. */ public void initVuforia() { /* * Configure Vuforia by creating a Parameter object, and passing it to the Vuforia engine. */ VuforiaLocalizer.Parameters parameters = new VuforiaLocalizer.Parameters(); parameters.vuforiaLicenseKey = RC.VUFORIA_LICENSE_KEY; ; parameters.cameraDirection = CameraDirection.FRONT; // Instantiate the Vuforia engine vuforia = ClassFactory.getInstance().createVuforia(parameters); } /** * Initialize the Tensor Flow Object Detection engine. */ private void initTfod(HardwareMap hardwareMap) { int tfodMonitorViewId = hardwareMap.appContext.getResources().getIdentifier( "tfodMonitorViewId", "id", hardwareMap.appContext.getPackageName()); TFObjectDetector.Parameters tfodParameters = new TFObjectDetector.Parameters(tfodMonitorViewId); tfod = ClassFactory.getInstance().createTFObjectDetector(tfodParameters, vuforia); tfod.loadModelFromAsset(TFOD_MODEL_ASSET, LABEL_GOLD_MINERAL, LABEL_SILVER_MINERAL); } @Override public void initializeVision(HardwareMap hardwareMap, Telemetry telemetry) { initVuforia(); if (ClassFactory.getInstance().canCreateTFObjectDetector()) { initTfod(hardwareMap); } else { telemetry.addData("Sorry!", "This device is not compatible with TFOD"); } if (tfod != null) { tfod.activate(); } } @Override public void shutdownVision() { if (tfod != null) { tfod.shutdown(); } } @Override public GoldPos detect() { List updatedRecognitions = tfod.getUpdatedRecognitions(); if (updatedRecognitions != null) { cacheRecognitions = updatedRecognitions; } if (cacheRecognitions.size() == 3) { int goldMineralX = -1; int silverMineral1X = -1; int silverMineral2X = -1; for (Recognition recognition : cacheRecognitions) { if (recognition.getLabel().equals(LABEL_GOLD_MINERAL)) { goldMineralX = (int) recognition.getLeft(); } else if (silverMineral1X == -1) { silverMineral1X = (int) recognition.getLeft(); } else { silverMineral2X = (int) recognition.getLeft(); } } if (goldMineralX != -1 && silverMineral1X != -1 && silverMineral2X != -1) if (goldMineralX < silverMineral1X && goldMineralX < silverMineral2X) { return GoldPos.LEFT; } else if (goldMineralX > silverMineral1X && goldMineralX > silverMineral2X) { return GoldPos.RIGHT; } else { return GoldPos.MIDDLE; } } return GoldPos.NONE_FOUND; } } 

### Next Steps

We need to implement detection using OpenCV, and make our class conform to VisionProvider, so that we can easily swap it out for TensorflowIntegration.

We also need to do the same using our Convolutional Neural Network.

Finally, it might be beneficial to have a dummy implementation that always “detects” the gold as being in the middle, so that if we know that all our vision implementations are failing, we can use this dummy one to prevent our autonomous from failing.

# OpenCV Support

OpenCV Support By Arjun

We recently refactored our vision code to allow us to easily swap out vision implementations. We had already implemented TensorFlow, but we hadn't implemented code for using OpenCV instead of TensorFlow. Using the GRIP pipeline we designed earlier, we wrote a class called OpenCVIntegration, which implements VisionProvider. This new class allows us to use OpenCV instead of TensorFlow for our vision implementation.
Our code for OpenCVIntegration is shown below.

  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 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 public class OpenCVIntegration implements VisionProvider { private VuforiaLocalizer vuforia; private Queue q; private int state = -3; private Mat mat; private List contours; private Point lowest; private void initVuforia() { VuforiaLocalizer.Parameters parameters = new VuforiaLocalizer.Parameters(); parameters.vuforiaLicenseKey = RC.VUFORIA_LICENSE_KEY; parameters.cameraDirection = VuforiaLocalizer.CameraDirection.FRONT; vuforia = ClassFactory.getInstance().createVuforia(parameters); } public void initializeVision(HardwareMap hardwareMap, Telemetry telemetry) { initVuforia(); q = vuforia.getFrameQueue(); state = -2; } public void shutdownVision() {} public GoldPos detect() { if (state == -2) { if (q.isEmpty()) return GoldPos.HOLD_STATE; VuforiaLocalizer.CloseableFrame frame = q.poll(); Image img = VisionUtils.getImageFromFrame(frame, PIXEL_FORMAT.RGB565); Bitmap bm = Bitmap.createBitmap(img.getWidth(), img.getHeight(), Bitmap.Config.RGB_565); bm.copyPixelsFromBuffer(img.getPixels()); mat = VisionUtils.bitmapToMat(bm, CvType.CV_8UC3); } else if (state == -1) { RoverRuckusGripPipeline pipeline = new RoverRuckusGripPipeline(); pipeline.process(mat); contours = pipeline.filterContoursOutput(); } else if (state == 0) { if (contours.size() == 0) return GoldPos.NONE_FOUND; lowest = centroidish(contours.get(0)); } else if (state < contours.size()) { Point centroid = centroidish(contours.get(state)); if (lowest.y > centroid.y) lowest = centroid; } else if (state == contours.size()) { if (lowest.x < 320d / 3) return GoldPos.LEFT; else if (lowest.x < 640d / 3) return GoldPos.MIDDLE; else return GoldPos.RIGHT; } else { return GoldPos.ERROR2; } state++; return GoldPos.HOLD_STATE; } private static Point centroidish(MatOfPoint matOfPoint) { Rect br = Imgproc.boundingRect(matOfPoint); return new Point(br.x + br.width/2,br.y + br.height/2); } }public class OpenCVIntegration implements VisionProvider { private VuforiaLocalizer vuforia; private Queue q; private int state = -3; private Mat mat; private List contours; private Point lowest; private void initVuforia() { VuforiaLocalizer.Parameters parameters = new VuforiaLocalizer.Parameters(); parameters.vuforiaLicenseKey = RC.VUFORIA_LICENSE_KEY; parameters.cameraDirection = VuforiaLocalizer.CameraDirection.FRONT; vuforia = ClassFactory.getInstance().createVuforia(parameters); } public void initializeVision(HardwareMap hardwareMap, Telemetry telemetry) { initVuforia(); q = vuforia.getFrameQueue(); state = -2; } public void shutdownVision() {} public GoldPos detect() { if (state == -2) { if (q.isEmpty()) return GoldPos.HOLD_STATE; VuforiaLocalizer.CloseableFrame frame = q.poll(); Image img = VisionUtils.getImageFromFrame(frame, PIXEL_FORMAT.RGB565); Bitmap bm = Bitmap.createBitmap(img.getWidth(), img.getHeight(), Bitmap.Config.RGB_565); bm.copyPixelsFromBuffer(img.getPixels()); mat = VisionUtils.bitmapToMat(bm, CvType.CV_8UC3); } else if (state == -1) { RoverRuckusGripPipeline pipeline = new RoverRuckusGripPipeline(); pipeline.process(mat); contours = pipeline.filterContoursOutput(); } else if (state == 0) { if (contours.size() == 0) return GoldPos.NONE_FOUND; lowest = centroidish(contours.get(0)); } else if (state < contours.size()) { Point centroid = centroidish(contours.get(state)); if (lowest.y > centroid.y) lowest = centroid; } else if (state == contours.size()) { if (lowest.x < 320d / 3) return GoldPos.LEFT; else if (lowest.x < 640d / 3) return GoldPos.MIDDLE; else return GoldPos.RIGHT; } else { return GoldPos.ERROR2; } state++; return GoldPos.HOLD_STATE; } private static Point centroidish(MatOfPoint matOfPoint) { Rect br = Imgproc.boundingRect(matOfPoint); return new Point(br.x + br.width/2,br.y + br.height/2); } } 

# Teammember Statistics Update

Teammember Statistics Update By Ethan

### Task: Look at the commitment changes over time of our team

It's a new year! And, with this new year comes new tournaments, new experiences, new projects, and more. But, to grow, one must reflect. Iron Reign's had a pretty big year, from going to Worlds to the prospect of a new MXP. And, while we can't analyze every possible aspect of the team, we can look at our stats page and differences from last year to this year.

We aren't amazing at keeping an archive of our team hours and such, so I had to pull these statistics from archive.org. The first archived version of the page in 2018 was from Feb. 14.

As of today, our stats page displays this.

Finally, the statistics page at the beginning of the season looked like this.

And, the differences between each are below.

### Next Steps

Iron Reign wishes y'all a Happy New Year! We wish to see progress among us all in these coming months.

# Off-Schedule Meeting Log, Winter Edition

Off-Schedule Meeting Log, Winter Edition January 03, 2019 By Ethan, Evan, Karina, Abhi, and Arjun

### Meeting Log (Week of)January 03, 2019

We have quite a few tasks this week, including:

• Latch design

• We've had an idea for a latch for a while. We started with the simple hook pictured below, but it was just that, a start. We want to move on to bigger and better things. So, we designed a new version, displayed below the hook.

This version uses two of the above gears to form the latch. Then, as the robot shifts, the latch becomes undone, allowing the robot to gently fall upon the ground.
• Latch attachment

• So, just having a design isn't enough, it actually has to be implemented. So, Evan cut some attachment points that also function as linear slide stoppers as detailed in our last post.

Then, we attached the latching system to the attachment posts on each side, mounting the latching system as seen here.

• Fixing superman and wheels

• While Karina was testing our robot, BigWheel suddenly began to lose friction, stranding itself in the middle of the field. It would only operate if more weight was put upon it. We haven't determined the reason yet; it could be that the temperature caused some strange material effect, but the new linear slides could also have shifted the weight distribution of the robot away from the main wheels. In addition, the Superman arm failed to work. We've narrowed it down to a code issue, but beyond that, we're scratching our heads.

Karina putting weight on the robot

• End\Beginning of year review

• Iron Reign has a tradition of reviewing the performance of the past year; this year I chose to begin it using numbers. I went back in the archives and used the stats page to count contributions from team members. This post can be found here.
• TensorFlow & OpenCV testing

• We still need to fully implement gold/silver particle detection, as well as the rest of our autonomous. To begin on this long, arduous process, Abhi and Arjun worked from home to begin vision integration. At the current point, the program detects gold most of the time. We are experiencing a bug in that the telemetry isn't detected.

# Debug OpenCV Errors

Debug OpenCV Errors By Arjun

### Task: Use black magic to fix errors in our code

We implemented OpenCV support in our code, but we hadn’t tested it until now. Upon testing, we realized it didn't work.

The first problem we found was that Vuforia wasn’t reading in our frames. The queue which holds Vuforia frames was always empty. After making lots of small changes, we realized that this was due to not initializing our Vuforia correctly. After fixing this, we got a new error.

The error message changed, meaning that we fixed one problem, but there was another problem hiding behind it. The new error we found was that our code was unable to access the native OpenCV libraries, namely it could not link to libopencv_java320.so. Unfortunately, we could not debug this any further.

### Next Steps

We need to continue debugging this problem and find the root cause of it.

# Modeling Slide Barriers

Modeling Slide Barriers By Kenna

### Task: Create barriers to prevent the linear slide from falling

Recently, we added polycarb barriers to our linear slide system. They were created as a temporary measure by bending the polycarb with a blow torch and are less exact than we would like.

I originally tried to overlap 3 rectangles, and Creo didn't register it as an enclosed shape and wouldn't extrude. For any geometric shapes you want to extrude, constructed lines in sketch mode make it much easier. They ensure that everything is perpendicular, but also that your shape will still enclose so you can extrude it. Armed with constructed lines, Our models printed in roughly 30 minutes using nylon on a Taz printer.

### Next Steps

Though nylon has its many uses, it's still not as strong as polycarb. We're looking into whether or not the printed version will withstand the slide system. Perhaps, we may need to pursue a different material or a more exact method of creating polycarb barriers. Any posts continuing this thread will be linked here.

# Meeting Log

Meeting Log By Bhanaviya, Charlotte, Kenna, Evan, Arjun, Ethan, Janavi, Karina, Austin, Lin, Jayesh, and Omar
Meeting Log January 05, 2019 Today's Meet Objectives

Today's goals include lowering the latch on Superman so that it becomes more hook-friendly, taking a team picture, and re-assigning presentation slides.

### Today's Meet Log

• Fix latch system
• On the robot, Evan lowered the latch system so that the system would be compatible for the hanging task. After the latch system was lowered, bolts on both sides of the lift system had to be moved so that they would align with one another. See more latch updates at (E-82, Latch Model).
• Add vision functionality to autonomous
• In terms of code, Arjun is working on using internal Tensorflow Object Detection code to grab frames for the autonomous to avoid any bugs in the custom code he has written so far. Additionally, he is working on ensuring accuracy in the output of the OpenCV pipeline so that it will consistently sample correctly.
• Presentation feedback from judges
• With the alums as our judges, we did a thorough presentation run-through. A critique that persisted from our "judges" was that we weren't as enthusiastic as we could have been. So, we decided that a better way to convey our energy was by finding out a way in which we stood out from other competing teams. One way for us to stand out was the back-and-forth debate between Karina and Evan on Mini Mech vs Big Wheel. Since that interaction effectively conveyed both the iterative nature of Iron Reign's engineering process as well as our team's quirks as a whole. In the future we are going to do many run-throughs to make the presentation informative and crisp.
• Team picture
• And last but not least, we took a suitable team picture for our journal - this one encompassing both current and old members of the team.

# Latch Model

Latch Model By Abhi and Justin

### Task: Model and print the Latch

Early in the season, we made a hook, Although it was durable, it required a higher amount of precision than we would have liked to have, especially in the rushed last seconds of the endgame. As a result, we designed a latch that is completely 3D printed and placed it on the robot.

This is the general model of it fit together (excluding left panel). The panels in the front are there to guide the latch into place when extending upwards from the ground.

This wheel represents what actually does the latching. When sliding upwards, there are two wheels that twirl in opposite directions and slot into the lander bracket. We attached a smaller piece to this to tension with a rubber band allowing us to move up into the bracket but not back down.

### Next Steps

We actually mounted this onto the robot and it seems to hold its own weight. However, the mounting was done very weirdly so we need to find a definite place for this system before we use it in auto or end game.

# Vision Summary

Vision Summary By Arjun and Abhi

### Task: Reflect on our vision development

One of our priorities this season was our autonomous, as a perfect autonomous could score us a considerable amount of points. A large portion of these points come from sampling, so that was one of our main focuses within autonomous. Throughout the season, we developed a few different approaches to sampling.

Early on in the season, we began experimenting with using a Convolutional Neural Network to detect the location of the gold mineral. A Convolutional Neural Network, or CNN, is a machine learning algorithm that uses multiple layers which "vote" on what the output should be based on the output of previous layers. We developed a tool to label training images for use in training a CNN, publicly available at https://github.com/arjvik/MineralLabler. We then began training a CNN with the training data we labeled. However, our CNN was unable to reach a high accuracy level, despite us spending lots of time tuning it. A large part of this came to our lack of training data. We haven't given up on it, though, and we hope to improve this approach in the coming weeks.

We then turned to other alternatives. At this time, the built-in TensorFlow Object Detection code was released in the FTC SDK. We tried out TensorFlow, but we were unable to use it reliably. Our testing revealed that the detection provided by TensorFlow was not always able to detect the location of the gold mineral. We attempted to modify some of the parameters, however, since only the trained model was provided to us by FIRST, we were unable to increase its accuracy. We are currently looking to see if we can detect the sampling order even if we only detect some of the sampling minerals. We still have code to use TensorFlow on our robot, but it is only one of a few different vision backends available for selection during runtime.

Another alternative vision framework we tried was OpenCV. OpenCV is a collection of vision processing algorithms which can be combined to form powerful pipelines. OpenCV pipelines perform sequential transformations on their input image, until it ends up in a desired form, such as a set of contours or boundaries of all minerals detected in the image. We developed an OpenCV pipeline to find the center of the gold mineral given an image of the sampling order. To create our pipeline, we used a tool called GRIP, which allows us to visualize and tune our pipeline. However, since we have found that bad lighting conditions greatly influence the quality of detection, we hope to add LED lights to the top of our phone mount so we can get consistent lighting on the field, hopefully further increasing our performance in dark field conditions.

Since we wanted to be able to switch easily between these vision backends, we decided to write a modular framework which allows us to swap out vision implementations with ease. As such, we are now able to choose which vision backend we would like to use during the match, with just a single button press. Because of this, we can also work in parallel on all of the vision backends.

Another abstraction we made was the ability to switch between different viewpoints, or cameras. This allows us to decide at runtime which viewpoint we wish to use, either the front/back camera of the phone, or external webcam. Of course, while there is no good reason to change this during competition (hopefully by then the placement of the phone and webcam on the robot will be finalized), it is extremely useful during the development of the robot, because we don't have everything about our robot finalized.

Summary of what we have done:
• Designed a convolutional neural network to perform sampling.
• Tested out the provided TensorFlow model for sampling.
• Developed an OpenCV pipeline to perform sampling.
• Created a framework to switch between different Vision Providers at runtime.
• Created a framework to switch between different camera viewpoints at runtime.

### Next Steps

We would like to continue improving on and testing our vision software so that we can reliably sample during our autonomous.

# Minor Code Change

Minor Code Change By Karina

### Task: Save Bigwheel from self destruction

The other day, when running through Bigwheel's controls, we came across an error in the code. The motors on the elbow did not have min and max values for its range of motion, causing the gears to grind in non-optimal conditions. Needless to say, Iron Reign has gone through a few gears already. Adding stops in the code was simple enough:

Testing the code revealed immediate success. we went through the full range of motion and no further grinding occurred.

### Next Steps

Going forward, we will continue to debug code through drive practice.

# Meeting Log

Meeting Log January 12, 2019 By Charlotte, Kenna, Karina, Evan, Justin, Abhi, Ethan, Arjun, and Janavi

### Today's Meet Objectives

Today our goals include presentation practice, autonomous testing and fine tuning, and build changes from the newest update of the latch to replacing our REV rails with carbon fiber tubing.

Presentation practice

### Today's Meet Log

• Presentation practice
• With the competition a week away, we are practicing our presentation frequently. Last time we presented, we were a bit all over the place; we talked over each other and stuttered quite a bit. This practice is to minimize these mistakes and finish our presentation in an appropriate amount of time, so we can answer questions.
• Latch update
• We finished up the design and print for version 2 of the latch system, and Janavi assembled it. The 2nd version changes the stopping mechanism; the bearings are now in the mount rather than in the actual sprockets. More details on this version of the latch can be found at (E-93, Latch Updates).

Janavi & the latch
• Lift redesign
• Evan and Karina worked on reattaching/realigning the belt drive for the lift. It would go off in unintended angles, the process went smoothly except for the fact that we are going to need to tighen the zip ties by replacing them frequently. See more on the belt drive at (E-87, Belt Drive).
• Carbon fiber redesign
• The REV rails for our intake system are quite heavy, so we are building a new intake with its old components and carbon fiber tubing instead of REV rails. Justin designed and started a print for a perpendicular mounting bracket for the carbon fiber tubes.

Justin modelling
• Mineral storage
• To add to the new intake system, Evan is making a new box to store minerals out of polycarb.
• Autonomous and vision
• Arjun tested and fine-tuned our computer vision. This vision uses Open CV, taking inspiration from the published pipeline and Doge CV. The vision is working well, so he is integrating it into the autonomous program that Abhi created. Karina and Arjun have been working diligently to test this autonomous so that it is in working condition for the next competition.
• Side shield design
• Ethan began the design for side shields, which we are planning to cut out using a laser cutter that is stored in our school's engineering classroom. To see more on the design process of the side shields, see (E-87, Designing Side Shields).

### Today's Member Work Log

 Team Members Task Start Time Duration Charlotte Blog 2:00 4 Janavi Build 2:00 4 Ethan Blog 2:00 4 Evan/td> Build 2:00 4 Abhi Code & Testing 2:00 4 Arjun Code & Testing 2:00 4 Karina Build & Testing 2:00 4 Justin Modelling 2:00 4 Kenna Proofreading 2:00 4

# Belt Drive

Belt Drive By Evan and Karina

### Task: Install a belt lift on our robot for depositing

The most recent addition to BigWheel has been the addition of a belt drive lift on either side of the linear slides. We chose a belt lift over a string and pulley lift because it is a much more secure, closed system, and doesn’t require stringing. For these reasons, we switched to belt drive. While more complicated to build, it requires no spool, only tension, no knots, and is super smooth in its motion. Our current design relies on the same time of belt drive used on 3D printers, something that we as a team are familiar with. The issues that come with using a belt drive lift include a more complicated setup and a more difficult time to repair in the pit, a lower ability to bear weight due to slippage of the teeth, and difficulties in tensioning.

### Next Steps

So far the belt drive has experienced a bit of slippage, but with the intake redesign we are just about to start on, it should have a better time lifting the intake.

# Designing Side Shields

Designing Side Shields By Ethan

### Task: Create side shields for BigWheel

Iron Reign has access to an Epilog Mini laser-cutter through our school, so we decided to use it to create side shields to protect our robot during defensive play, display our team numbers, and prevent wire entanglement

We created our original design in Illustrator. The canvas size was 12"x18", ensuring that our design stayed within the size limits. Then, we found the side height of our robot's wheel hubs (1.3") for later use. The original design, above, was inspired by 1960s teardrop campers.

The Epilog Mini is a CO2 laser cutter, which means that it can cut acrylic, cardboard, and wood. We don't keep our robot at school, which meant that we had to make a test cut at school. We had a variety of issues, our first print cut way too small, about 8.5"x11" when it should've been 17"x8". Our next cut caught on fire, burning in the machine as I tried to put it out without water. Our final test was successful, producing the cutout below.

But, when fit to the robot, issues became apparent. It was barely scraping the size limit, and while it fit over the wheel mounts, it failed to match the shape of the wheel. And, the shield grazed the ground, meaning that any rotation from the Superman arm would damage it or the arm. So, we created a second, smaller design and cut it using wood, resulting in a final design.

# Selective Intake

Selective Intake By Evan

### Task: Design a new sorting mechanism for gold and silver particles

The differentiation between the different shapes of minerals has been something we’ve been thinking about since day one. At the time we designed a box that allowed us to sort out blocks and balls by size, but weren't able to implement it. Our original selective intake only accepted balls so we only have to go to the one loading area, but our new design allows us to deliver both blocks and balls to their respected containers. It wasn’t implemented earlier because the robot just wasn’t tall enough. With our new belt drive, It’s possible to do.

This we decrease the difficulty of TeleOp for the drivers by increasing the speed of deposit while decreasing accuracy needed. The selective intake also has a door built into it, which holds back the minerals until we’re ready to deposit. Gravity does the rest of the work, letting the balls fall down into a brachistochrone, and letting the cubes fall through.

The other thing that we wanted to do was to have this process be almost completely mechanical, taking more stress off the drivers. The gate is released when a lever is pushed in and translated to a quicker motion with a pair of gears at a 2:1 ratio allowing for an easy deposit. The frame of the intake is made out of polycarb, bent with the sheet bender and cut into the correct form with the bandsaw.

The intake also uses our ice cube design from earlier in the season. It is compliant and with its new 3D-printed supports (Ninjaflex, 20% infill), it will be much more effective than the previous intake. This time, instead of stapling the thing together, we are sewing it shut, which should hopefully negate any problems the previous version had, such as coming apart where the two sides met. The intake will be offset a little from the ice tray intake to allow for as much grabbing action as possible.

### Next Steps

Now we must allow the drive team as much time to practice with it as possible.

# Pool Noodle Intake

Pool Noodle Intake By Evan

### Task: Design a quick intake for the robot before competition

The night before our final qualifier, we decided that the intake system on the robot was not up to our standards. To fix this issue, we poked some holes in a pool noodle, and put surgical tubing through it. While this was a quick and semi effective fix, it did have some problems, mostly due to the rushed nature of its construction. The tubing slid back and forth, and the noodle itself was slightly offset from the depositing box, causing it to be a little off. It could only be remedied by taping all the surgical tubing together, allowing it to grip the minerals better and allow for a smoother intake. The other big issue with this version of the intake was that the depositing mechanism was imprecise and required very accurate driver control and a little bit of luck.

### Next Steps

This isn't a permanent solution, but we need to have something simple so that we can intake the gold and silver particles at the tournament. We plan to replace this with the actual corn on the cob intake after the competition.

# Wylie East Qualifier 2019

Wylie East Qualifier 2019 By Ethan, Charlotte, Janavi, Evan, Abhi, Arjun, Karina, and Justin

### Task: Compete at Wylie East

Wylie East was Iron Reign's second qualifier of the year. Having qualified at the first one, we planned to use the tournament as an opportunity to practice the presentation and driver practice, as well as check up on other teams' progress. We didn't have a working robot going in - we had found that our latch was one-time-use only the night before, we had recently swapped intakes due to weight, and our autonomous was non-existent.

#### Judging

Unlike last tournament, we had actually done presentation practice, cleaned out the judging box, and revamped the presentation. We were missing a member, but we had already reassigned their slides well in advance so that people would practice them.

And, our practice paid off. We had pretty seamless transitions, we had a good energy that the judges enjoyed, and our robot demo went really well. We got our content across, and even better, we finished way under 15 minutes so that the judges could ask us questions (even though they didn't have many to ask).

Later, we had one group of judges come up to greet us. They mainly asked about our robot and its various functions and design choices. Our robot wasn't there, so we had to rely on old prototypes.

#### Inspection

Our robot passed field and robot inspection with flying colors and no reprimands, probably the first time that this has ever happened for Iron Reign.

#### Robot Game

Like above, we really didn't have a perfectly working robot. But, we performed much better than past tournaments due to improvements.

###### Match 1

For the first time in Iron Reign history, we tied, 211-211. Our autonomous sampled and we parked, and we were able to latch in the endgame, so it was a pretty good match all around.

###### Match 2

We lost the next match, 134-85. Our partner's robot shut down, so we couldn't keep up with the opponent. Our auto worked though, as well as latching.

###### Match 3

We lost this match, 102-237. This time, our autonomous didn't work, as our team marker fell off and knocked us off our path.

###### Match 4

We lost, 123-139. Again, our autonomous workde fine, everything else just failed.

###### Match 5

We lost, 122-154. Everything was going smoothly, but our alliance was blown out of the water during particle scoring.

##### After Judging and Awards

We weren't picked for an alliance, so we had to wait for awards. And, we ended with three awards: 1st Connect, 2nd Innovate, and 2nd Motivate. We were ineligible for Inspire due to our prior performance, but we don't believe we would have won it - the head judge stated that this was the closest tournament to regionals that we would get, so there was plenty of tough competition.

After the awards ceremony, we came up to the fields to help clean and talk to referees. There, we were told something that we enjoyed; one of the refs told us that Iron Reign was one of the nicest and most graciously professional teams they had dealt with this season. We really liked to hear that, and it meant a lot. Also, we were told by another observer that we needed to make what our robot did more clear in the presentation, a point that we'll expand upon in the post-mortem.

### Next Steps

See post-mortem.

# Competition Day Code

Competition Day Code By Abhi and Arjun

While at the Wylie quaiifier, we had to make many changes because our robot broke the night before.

First thing that happened was that the belt code was added. Previously, we had relied on gravity and the polycarb locks we had on the slides but we quickly realized that the slides needed to articulate in order to preserve Superman. As a result, we added the belts into our collector class and used the encoders to power them.

Next, we added manual overrides for all functions of our robot. Simply due to lack of time, we didn't add any presets and we focused on making the robot functional enough for competition. During competition, Karina was able to latch during endgame with purely the manual overrides.

Finally, we did auto path tuning. We ended up using an OpenCV pipeline and we were accurately able to detect the gold mineral at all times. However, our practice field wasn't setup to the exact specifications needed so we spent the majority the day at the Wylie practice field tuning depot side auto (by the end of the day it worked almost perfectly every time.

### Next Steps

We were lucky to have qualified early in the season we could make room for mistakes such as this. However, it will be hard to sustain this, so we must implement build freezes in the future.

# Meeting Log

Meeting Log January 26, 2019 By Charlotte, Kenna, Ethan, Justin, Arjun, Abhi, and Bhanaviya

### Today's Meet Objectives

We are going to use our experience from last week to guide our improvement until Regionals. Today we are going to discuss what these improvements exactly entail and outline a timeline for when we need to accomplish these improvements in order to allow adequate time to dedicate to autonomous code and drivers' practice.

### Today's Meet Log

• Robot repairs
• There were some problems with our motors: one of the axle hubs is stripped. Though we attempted to replace the axle hubs, Iron Star and Iron Core took brought most of the tools that we need to their competition.

Karina and the robot
• We did a lot of last minute code changes during the competition. Abhi and Arjun cleaned it up and removed legacy code. Autosetup in autonomous, autonomous that works for all sides of the lander, was ditched a long time ago as it was not reliable by the time we needed to test before competition. Now that we have some time before regionals, we are bringing autosetup back. We are taking all of the code we made from scratch during the competition and integrating it into autosetup, which we hope to have ready soon to start driving practice as soon as possible.

Coders
• Robot model changes
• Justin worked on the robot model. We've made lots of changes on the robot in the past month, so besides the changes that we tested on our model, it needed a couple of updates; the upgraded deposit and reinforced Superman arm. The finished robot model for BigWheel can be found at (E-107, Bigwheel Model).

• Ethan worked on the Wylie post and the postmortem, which can be found at (T-38, Wylie East Postmortem).

# Wylie East Postmortem

Wylie East Postmortem By Ethan, Janavi, Charlotte, Karina, Abhi, Justin, Kenna, Arjun, and Bhanaviya

### Task: Analyze what went wrong at Wylie

We performed well at Wylie, comparatively speaking. But, there's always room for improvement.

#### Problems:

##### The Robot & Code

• Latch
• So our first major issue was the latch. We had put together the latch the week before the tournament and tested it the night before, finding that the bearings fell out of the nylon backing under the pressure of lifting the robot. Effectively, this meant that we could only use the latch once per match as we had to reset the bearings after each use. So, we're pursuing two avenues to fix this: cut the latch in aluminum or completely redesign the latch.
• Presets & Limits
• Another issue that occurred was that the robot kept on injuring itself. It repeatedly overextended the Superman arm, causing its gears to disengage and strip. The same happened for the intake elbow - we didn't have limits set in so it would move too much and break. And with the belt arms, we stretched the belts out because we didn't have limits created.
• TeleOp Helplessness
• Another issue was that our robot didn't function well between autonomous and endgame. Our intake was recently created, and as a result, we felt it better to not attempt to score minerals. We're working on a new intake for this, some combination of our old corn-cob intake but without the Tetrix pieces that made it so heavy.

##### Preparation, Presenation & Judging

• Prep
• We didn't pack for this tournament and as a result, we didn't have any nuts or bolts, a pretty big oversight. From now on we plan to set up boxes to bring for the week before.
• Practice
• Our presentation was better this time. Still, we didn't get enough practice. There were a few long pauses between people and we skipped a couple of slides. The only way to fix lack of practice is more practice.
• Energy
• We always need energy, it's what draws people in and gets judges to remember our presentation. Currently, we do a mini-debate within the presentation over our design choices but we plan to improve this and make it more point-by-point. In the same vein, we need to be louder.

##### Pit Conduct & Misc

• Prep Scouting Sheet
• We need to make a scouting sheet for the tournament ahead of time with past performance. As well, we need to make a second sheet prefilled with team names for the day of. This would just reduce the amount of time spent to prepare at the tournament and transfer it to weeks-before prep.
• Focus in pits
• A consistent issue for Iron Reign is focus. People'll do their homework and things that aren't necessarily related to robotics in the pits and we need to stop; it always looks better to be focused when judges come around. We're still thinking of ideas to stop this.

Latch Updates By Justin, Abhi, and Ben

Our first attempt at a latch was made out of flat metal L brackets that would slide into the hook, but they slid off under any stress. We decided to make a latch with a ratchet and sprocket system. The easiest way to accomplish this was to 3d print it. There are two sprockets and the lander hook will slide in between them. This causes the sprockets to rotate and then lock, allowing the latch to support the weight of the robot. To disengage, the driver just needs to move the ratchet up and over the hook. The picture of the model shows our change in design because the right sprocket is mounted to a bearing in mount, while the left side has the bearing in the sprocket.

The purpose of our new latch is to increase the speed of latching. The latch requires one direction of motion to fully engage it, making it perfect for autonomous. The latch also has room for error because the funnel shape of the fron plates guides the hook into the sprockets.

### Issues

• bearings pop out under stress(fixed by moving bearings from sprocket mount to sprockets)
• whole subsystem bends under stress(fixed by mounting the latch to aluminum instead of polycarb)
• difficulty turning ratchet(fixed by trimming pieces)
• Still not strong enough to support weight of robot in a match
• Hard to get close enough to lander to engage ratchet
• ### Next Steps

We need to either strengthen our current design or find a better alternative.

### Task: Consider what needs to be done before regionals

Engineering Notebook:

• Fix old posts, add calculations and reasons why
• Intake posts
• Backdate prototypes
• Latch System
• Superman - how we figure out what height to raise it
• Which wheels we used based on friction
• Which motors and why ( gear ratios and speed)
• Gear ratio of superman
• Linear slide vs new slides - how they work differently
• Belt system
•
• Fix timeline
• Update posters
• Write posts about last minute things
• Belts
• Autonomous
• Tournament
• Post mortem
• Create a research-like poster with all of iron reigns calculations on it
• Create a robot manual using 3D model renders
• Torque values, what it does, all that stuff

Build:

• Aluminum latch
• Create 3D model
• Cut at makerspace
• Intake redesign
• Mount red intake onto carbon fiber
• Attach to robot
• Front “block”
• Create 3D model
• Machine out of aluminum
• Side shields
• Fix some design problems
• Remove points
• Recut with thicker acrylic
• Mount LEDs underneath
• Update 3D model
• Update intake

Code:

• Auto path for crater side
• Vision after path is complete
• Auto path for depot side double-sample
• Vision after path is complete
• Auto path for crater side double-sample
• Vision after path is complete
• Find presets for Superman and elbow
• Endgame mode creation
• openCV detection of latch
• Auto-latching and delatching
• Autoscore during teleop

Other:

• Driver practice
• Make project management charts accessible
• Print posters
• Make banner
• Print banner
• Ensure we have tent parts
• Tent design
• Check amount of space
• Trophy display
• Fairy lights
• Organization + tool cart
• Hats
• Scouting Sheet
• Tokens
• Test design
• Cut many
• Are we bringing things to handout?
• Tokens to hand out ( laser cut)

# Superman Calculations

Superman Calculations By Ethan

### Task: Calculate torque and other values of the Superman arm on our robot

We want to have our robot completely replicable through the journal. So, we found it necessary to include the power calculations of various subsystems on our robot.

##### Superman Arm

The Superman arm uses two REV Core Hex motors to lift the robot upward, outputting a base 125 RPM and 6.4 Newton-meters of torque. Then, we have 15-tooth gears attached to the motors, which in turn connect to 125-tooth gears for a gear ratio of 10.4:1. Using the torque calculation WheelT=MotorT*(output/input), we find that the total torque exerted downward by the arm is 66.6 N*m.

Then, given that the arm is .304 meters long, the upwards force produced by the Superman arm is 20.29968 Newtons. The robot itself weighs about 20 pounds, or 89 Newtons. But, since the robot is moving around its center axis, we can neglect the lower half of the robot that touches the ground with the wheels, reducing our load to 44.5 Newtons. Then, taking the integral of force with respect to the radius measured from the Superman arm, we integrate the equation force=(force at top/radius to top)*radius=292.763r. Using the limits defined by the distance to the edge of the robot (0 to .152 meters), the downward torque created by gravity is 3.38 N*m. Modeling the robot as a single point, we get this diagram.

But, the robot doesn't always operate at optimal load. For example, when the robot is at maximum extension, there are about 60N of load above the center arm and the center arm itself is extended 18 inches, or .4572 meters. Performing the same integral as before with the new limits (0, .4572+.152=.6092), we find that the maximum possible downward torque exerted on the arm is 54.33 N*m, resulting in a net torque of 12.7 N*m upward. Superman can still raise the robot upward, but much slower and with a much greater probability of gear slippage. At these torque levels, the plastic teeth of the gears slip if they're not perfectly aligned.

Given that the gears are composed of Acetal (Delrin/POM), that the area of one tooth is (.00104 meters * .011 meters = 0.00001144 m^2), that the arm produces 66.6 N*m * .152 m = 10.12 Newtons of force, and the Delrin/POM deformation chart, we can find that the pressure on *one* tooth of the gear is P=F/A=10.12/.00001144=884615.38 Pascals or .88461538 MPa. And, consulting the Delrin/POM deformation chart below, using the long-term line for an hour of use, we retrieve a stress of ~.5%, meaning that the teeth of the gears deform by .5% per hour of use. This alone explains our gear slippage under high loads; as the pressure on a tooth increases, they cause more deformation, which in turn results less area contact between the teeth of the gears, which results in more stress, causing a negative feedback loop.

However, this alone doesn't explain the stripping of the gears - the gears would only deform by .0572 uM; more analysis is required. When we inspected the superman gears more closely, we found that the gears barely interlocked - maybe 1% of the gears were touching. When we go back to the pressure equation, we find that this increases the pressure on each tooth to 88 MPa. Under the short-term compression curve below, we find the strain is about 5%, or 10x the strain. This results in a deformation of about 5uM, but the contact area itself is only 104 uM, so under these loads it causes an appreciable effect.

This leads us to the natural conclusion to solve this issue - the gears must be held tighter to increase the contact area and decrease stripping. To do this, we're starting to design a gear holder, which will be detailed soon.

# Gearkeepers

Gearkeepers By Jose and Evan

### Task: Create and install gearkeepers to reduce slippage

We need to install gearkeepers on the Superman arm to prevent gear skippage which damages gears over time. We designed a simple rectangle in PTC Creo and cut holes to fit bearings, 3D-printed them, and attached them.

Now it was time to test for gear skippage. Unfortunately, we had one or two gear skips with every attempt of rotating the wheel mount. We tried using string to see if tensioning the gear holders would work but that also failed.

We went back to the drawing board and checked for a sizing error. To calculate this we take the module of the gear and multiply it by the amount of teeth the gear has, then dividing by two to get the gear's radius. We do this for both gears and add them together. The module of the REV plastic gears is 0.75. This resulted to be (15×0.75/2)+(125×0.75/2) or 52.5 mm. And the original gear holders were 53 mm long, a slight error but at least we found the reason for error. We also noticed that there was some give in the plastic inserts for the REV bearings so we decided to tighten it down to 52mm.

We changed the length of the inside of the gear holders from 53mm to 52mm and 3D printed them. This resulted in a complete fit where the gears were firmly engaged.

### Next Steps

This is good for now but in the future, we need to watch the nylon of the gearkeepers for wear and tear as well as stretching - even a millimeter will allow the gears to slip.

# Intake Omnis

Intake Omnis By Ben

We need to add omniwheels to the intake arm to allow the arm to rest on the ground, while still maintaining the necessary height for collecting the minerals. If the height is too low, the minerals wouldn't be able to move through the intake. If the intake was too high, it wouldn't be able to grip onto the minerals and pull them through. We decided to use omnidirectional wheels as they would allow us to drive forward and backwards with the arm extended.Our first challenge was finding space on the intake arm to attach the wheels. We had a few options:

• Attach the wheels parallel to the arm
• To do this, we would have to have a "u" shaped component, which we could mount off of a threaded extrusion, then attach that to the servo mount.
• Mount the wheel perpendicular to the arm
• This would give the same degree of maneuverability. To attach this, we would have to use an elbow bracket and attach that to an extrusion at a 90° angle.
Both of these present a similar challenge, leaving enough room for the intake to function properly. With about 2.5in. to work with, we mounted the wheel perpendicular with a 1.75 in. extrusion. We threaded the extrusion and used an elbow bracket to mount the wheel; this ensures the strength of the wheel. This left about 0.5in. between the wheel and the "corn on the cob" intake.

### Next Steps

Our next steps are to perform testing on the wheels to determine if they are durable and low enough, and improve the performance of the robot. One issue that may arise is rubbing against the gears, as they may shift over prolonged usage, along with twisting of the extrusion.

# Mechanical Depositing

Mechanical Depositing By Evan

### Task: Create a mechanical deposit for our selective deposit

To relieve driver stress, we decided to put a mechanical release mechanism that would drop the minerals into the passive sorter to then further deposit them. The lever that activated the release mechanism was made of thick wire attached to a small gearbox that reversed the direction of rotation for the release gate. The lever activated the gearbox when it was pushed into the side of the lander. This created some issues that ultimately killed the mechanical release, such as a balance of tension that would never work out. We had to balance the tension of the rubber bands with the weight of the minerals while also accounting for the fact that the lever had to be pushed without our entire passive sorter being pushed beyond 180 degrees up and down.

Because of the difficulty in implementing this, we instead switched over to a servo which now powers the release gate. While short-lived, it was a good test of the limits of our intake system, and we will be improving on it in the coming days.

### Next Steps

We need to attach a servo to the intake with a correct mounting position to allow at-will depositing. We plan to do this with a inward-mounted servo which will then be connected to the REV hub through a wire protector, allowing us to place a servo high on the robot without worrying about the wires getting stuck in the gears and cut like before.

# Latch V.3.5 Assembly

Latch V.3.5 Assembly By Ben

### Task: Assemble the V.3.5 latch and attach to the robot

We assembled the fourth version of the latch today. Some of the improvements on this latch include using bigger bearings and thrust bearings inside. This latch is designed to be stronger and more reliable. After cleaning the parts and trimming some edges, we assembled the pieces. Upon assembly, we discovered an issue: the gears required a different amount of pressure to catch the lock. If left untreated, it could result in the robot falling off the hook. We determined the root of this problem was that the locking mechanism on the right gear was shorter than the left. To fix this, we trimmed a few millimeters off the piece that provides tension on the left gear to match that of the right gear.

Latch attached to polycarbonate brackets.

### Next Steps

We will need to perform various tests on the latch to determine if the height is correct, if the latch can support the robot, ease of latching and unlatching, and consistency. We plan to test our robot this Saturday at the DISD STEM Expo, which will provide an opportunity to practice latching.

# Fixing Mineral Dropper Components

Fixing Mineral Dropper Components By Jose and Evan

### Task: Fix any issues with the mineral dropper

At the STEM expo we saw a clear issue with the mineral dropper: it is very poorly geared and doesn't deposit minerals well. A quick look at the gear configuration revealed that the gears were attached in a poor manner such that there was a lot of gear skippage. To remedy this, we attached a gear-box to the dropper to keep the gears interlocked.

The way the mineral dropper works is by having a wire attached to the shaft that turns the release be pushed when the robot hits the lander. The wire is attached with a portion of a gear custom cut for the job.

We need to upgrade to a thicker wire for more reliable shaft rotations. After doing so we needed a different wire holder and we chose a REV wheel. After cutting it and drilling bigger holes to accommodate the new wire we needed to attach it all to the shaft for the mineral release.

### Next Steps

We need to finish bending the wire and test its ability to open the mineral release when contacting the lander.

# Meeting Log

Meeting Log February 02, 2019 By Charlotte, Kenna, Ethan, Bhanaviya, Jose, Ben, Evan, and Janavi

### Meeting Log February 02, 2019

Bhanaviya working on the blog

### Today's Meet Objectives

The DISD STEM Expo took place today. While incredibly rewarding, the experience was tiring, so only a few members made it back for the meeting that took place afterwards. This log will include our objectives and accomplishments from the meetings we held throughout the week after school which include build changes to the depositor, some calculations for analysis various parts of the robot, and preparation for our pit setup at regionals.

### Today's Meet Log

• Design posters
• To display this year's accomplishments, we plan to create posters for the pit. The research poster will include a few projects we have done this year including our friction tests, materials test, and torque/gear ratios calculations as well as calculations for the elbow, wheels, and other vital parts on our robot. We will also have outreach posters and a timeline of our robot design. Janavi has been designing these posters based on the journal entries we have made about the tests.

Ethan and the research poster
• Design passively-sorting deposit
• Evan has been working on a mechanical depositor for minerals in the lander. We want to utilize a mechanical part to remove burden from the driver, who also has to worry about alignment with the lander as well as control of the arm. This also removes burden from our coders, who have many goals to accomplish before we will be ready for regionals. Once the initial depositor was built, we did some tests during the STEM Expo, as we had a field set up outside the MXP to show off our robots to all of the kids coming through the booth. The depositor, unfortunately, did not perform very well. The biggest problem stemmed from the elastics that enabled it to be entirely mechanical. If the elastics are too tight, it would not bend enough to let the minerals fall out of the little trap door. If the elastics are too loose, the trap door won't be sturdy enough to hold the minerals in before depositing. We are looking for other options now, and we are most likely going to opt for replacing the elastics with a driver-controlled servo. This will put more of a burden on the drivers unless the coders find the time to program sensors for depositing. Either way, we need more driving practice which we hope to accomplish in the next two weeks before regionals.

### Today's Work Log

The picture above is a representation of our work today. After making sure all the manual drive controls were working, Karina found the positions she preferred for intake, deposit, and latch. Taking these encoder values from telemetry, we created new methods for the robot to run to those positions. As a result, the robot was very functional. We could latch onto the lander in 10 seconds (a much faster endgame than we had ever done).

### Next Steps

The code is still a little messy so we will have to do further testing before any competition.

# Drive Testing at STEM Expo

Drive Testing at STEM Expo By Ben and Abhi

### Task: Test robot performance at the STEM Expo to inspire younger kids and practice

An FLL team gathered around Iron Reign’s robot

We had the privilege of being a vendor and representing SEM at DISD's STEM Expo this weekend. Thousands of people cycled throughout our area during the day, so we had the opportunity to show off our robot to many people. Some of these people include FLL and VEX IQ teams, along with Best Buy volunteers. Our goal was to get kids excited about STEM and robotics, along with getting some robot practice in. We will be trying out the new latch, new presets, and prospective drivers.

As soon as we started driving, we noticed a few issues. One of these being the belt drive repeatedly slipping. This may be a result of the belt loosening, the drive gear accelerating too quickly, heavy intake arm, or the preset causes the drive gear to keep operating, even when the arm is fully extended. We also struggled with keeping the intake box out of the way and prevent it from twisting around the “corn on the cob” intake. We will solve this by fastening the rubber band that was supposed to keep it in place. This; however, wasn’t our only intake problem. Once 2 minerals had been grabbed, they would usually fall out the intake box after lifting the arm. The intake box would turn vertical, making it easier for the minerals to shift out. This was especially an issue when trying to deposit the minerals, we would make several sudden movements, causing the arm to swing and minerals to fall out. A possible solution to this is adding a barrier between the floor of the intake box and the top of the box. This would allow for more freedom, as we could move faster without worry of losing minerals.

### Next Steps

It will take a lot more practice to master latching and collecting, and even general driving. We will need to code better presets and either design a better collection box, or fix the existing one. Drivers will also have to be selected, which we will do by running several trials for each member and determining who is best at latching, scoring, and control.

# Latch 2.0 - Forged in Flame

Latch 2.0 - Forged in Flame By Evan

### Task: Design a new latch for hanging

Our latching system is too complicated to use quickly; it requires too much reliance on driver control and becomes jammed. So, we forged an iron hook to replace it. We started by taking an 8mm iron rod and placing it into the forge that we have, heating it up and bending it into shape over the course of an hour. We made a wire model for the hook, and then slowly and patiently formed the hook out of the rod. Then, to make an easy-to-drill connection point, we heated a section up until it was white hot and then used a punch to create a flat part that we then drilled into afterward.

To create a mount, we took a length of steel and used an oxy-acetylene torch to heat up the areas we wanted to bend. Once this was done, we went about attaching the hook to the mount. We did this by finding the center of the mount, drilling it out, and pushing a bolt through it, surrounding all sides with washers. We then mounted a servo next to the hook and attached it with a piece of wire, which was secured to the hook by two notches cut out of either side of the tail of the hook. Later, after finding the wire to be too flimsy, we attached the two together with a strip of polycarb. It works well, allowing us to mount and dismount much easier than we would have hoped for with our last latch. While the last latch was purely passive and required no electrical components, this one gives us much more control in how we latch and delatch.

# Meeting Log

Meeting Log By Charlotte, Evan, Ethan, Kenna, Karina, Abhi, Arjun, Ben, Jose, Janavi, and Bhanaviya
Meeting Log February 09, 2019

### Today's Meet Objectives

Today we participated at a scrimmage held at Woodrow Wilson High School. This was a fantastic opportunity to get some driver practice in real, timed games and adjust for issues.

### Today's Meet Log

• Hook implementation
• Since we have made a few changes to the robot, such as adding a servo to our previously mechanical output mechanism, we evaluated how well they worked. We wired the servo and fixed the wiring from the arm that got tangled in the motor using a wire router to take control of this issue. As well, we began auto tuning for the new hook.

Fire from the forge from crafting the hook

The burning metal being bent into our hook
• Driver practice
• When we weren't making changes on the robot, we were practicing driving. Some difficulties we faced included getting stuck in the crater because of our arm and the disconnection of our hook from the servo horn due to our attachment with zipties. When we got back to the house, we began changes to fix these issues by creating a replacement for the zipties out of polycarb and working on presets to improve the balance of the robot.

# Woodrow Wilson Scrimmage

Woodrow Wilson Scrimmage By Bhanaviya, Charlotte, Janavi, Kenna, Karina, Evan, Abhi, Jose, Ben B, and Arjun

### Task: Compete at the Woodrow Wilson Scrimmage with Woodrow teams

This past Saturday, Iron Reign competed in the Woodrow Wilson Scrimmage. To ensure that the wiring did not become tangled when the robot moved around, we added an ABS cable-carrier to the arm of the robot.

Overall, Iron Reign was able to establish a semi-stable deposit scoring game-plan in the match. Since we haven’t focused on practicing game play in a while, this scrimmage gave us an opportunity to pin-point build and code issues, as well as get a clearer idea of what our strategy for regionals needed to look like.

### Next Steps

We are incredibly thankful for Woodrow Wilson and their teams for hosting us, as well running such an effective scrimmage. The opportunity to connect with other teams in our region has given a clearer idea of what we can learn from the teams around us to improve our overall team presence.

# Bigwheel Model

Bigwheel Model By Justin

### Task: Design and update the Bigwheel Model

We are updating our bigwheel model to represent our current robot. We had a model of just the chassis from the chassis study, so we are currently adding all of the changes we made throughout the season.

### Completed Changes

• Modeled the linear slide lift
• Modeled superman arm
• ### Future Changes

The lift has been changed recently so the model needs to be updated. The main problem with this is that the new slides are not standard parts, so there are no accurate CAD files. This means we have to custom model our new slides to maintain accuracy with our model. The motor placement on the chassis needs to be fixed because we the measurements were estimates. There are many small 3d printed parts that need to be added to the robot, as well as our new ratchet latch.

### Next Steps

We need to work on future changes and get our model up to date with our robot so we can start conceptualizing new subsystems.

### Task: Fix some issues on BigWheel before the build freeze

We made more secure way of activating our hook, so we switched our piece of wire attaching the servo to the hook with a much stronger and less likely to bend strip of polycarb, which greatly improved the reliability of the hook.

As well, we limited the back and forth motion of our slides at their attaching points. I achieved this by inserting a small piece of drywall sandpaper in between the stages of the slides. Hopefully, the added friction will create a stronger hold between the stages fo the slide.

Next, we ground down a bolt to more securely attach the servo horn to the servo since it’s a REV hex shaft to servo adapter and the bolts we had didn’t fit inside well enough. Once that was done, we changed the ratio between the belt drive pulleys, going from a 1:1 (36 teeth to 36 teeth) to a 5:3 (60 teeth to 36 teeth) by increasing the size of the pulley at the motor. This should increase the quickness of our lift and hopefully let us squeeze a few more mineral pick up and depositing cycles in.

### Next Steps

It's time to turn the robot over to the coders and drivers, so there won't be many changes after this,

# Pulley Spacers

Pulley Spacers By Ethan

### Task: Design and implement pulley spacers to prevent belt interference

We had an issue where the belts that allowed our arm to slide upward were misaligned, resulting in the belts frequently slipping. We narrowed the slippage down to a single point, at this pulley.

We had to create a new spacer to keep that section of the belt inline with the rest. As usual, we took measurements and replicated them in Creo. It had to be about 3.5 centimeters long, the same width of the metal plate. The depth of the indentation to attach to the linear slide is about 0.75 centimeters and the diameter of the M3 holes 3 millimeters. With these measurements, we designed the piece and printed it in 60% infill nylon, strong enough to withstand the weight of the linear slides. This is what version one looks like:

However, this version's holes were too far down, allowing the toothed sections of the belts to interact and jam. So, we decreased the height of the bottom pulley-holes so that the middle section of the belt would slider higher up, preventing interference. This resulted in the final version seen at the top of the article.

### Next Steps

We still have to fully test these spacers, but we can't do a full test until we fix the gears supporting the elbows, which will be detailed in another post.

# Robot Issues - Gear Grinding

Robot Issues - Gear Grinding By Ethan

### Task: Analyze the issues with the elbow arm of our robot

The elbow arm of the robot is what allows us to rotate the arm of our robot - the linear slides what hold the intake. Recently, while doing some drive testing, we found that the elbow wasn't acting as it should. When we took a closer look at it, we realized that the metal gears had started to destroy each other.

Before installing new gears and just having the same thing happen again, we wanted to analyze why this was happening. Remembering that pressure is equal to force divided by area, we noticed that the gears weren't fully interlocking, reducing the area for force to act on. And, the teeth of these gears are minuscule things, so the pressure on each one is immense, even more so with the full torque of the extended linear slide behind them. And, while these aluminum gears may not bend that well, under these immense pressures, they sure can break since hardness and brittleness trade off. And, even then, with high pressure and frequent use, they can still easily grind down, resulting in this scene:

But, that's not all. When we tried to run the elbow, we realized that the motor shaft themselves were out of alignment. This is hard to capture in a single picture, but this manifested itself as a sort of wobble when the motor was repeatedly run. With full, non-ground gears, this would probably be fine, but the moving shaft reduced the area of interaction between gears, contributing to the gear-dust all over our robot. Finally, as the gears were reduced to almost nothing, this wobble made it so the gears wouldn't interact at all.

The solution to this is complicated, as we only have one set of spare gears. If we had more, we would be able to replace them as needed, but currently, we couldn't guarantee that they wouldn't give out at regionals. First, we need to replace the motors, as any wobbliness reduces the area of interaction between gears, which increases the pressure on the teeth accordingly. Then, we need to create gearkeepers to hold the gears to maximum contact. We've created gearkeepers before under the same circumstances for the arm that lifts our robot up (we had a similar gear-stripping scenario), but this may not be enough alone. First, we use metal gears on the elbow, which have smaller teeth area-wise than the plastic ones elsewhere. Plus, the gearkeeper design below doesn't compensate for any later wobbliness that may occur and may wear out itself, as its essentially a nylon strap between two shafts. So, we need to design a gearkeeper that doesn't only attach from shaft to shaft but shaft-shaft-robot, as this would prevent the pesky wobbliness and decrease tooth pressure as much as possible.

### Next Steps

We've forwarded this analysis to the modeling team, who will produce a print later this week so that we can bring our robot back up to snuff.

# Research Poster

Research Poster By Janavi and Ethan

### Task:Create a Poster amalgamating all of our math

Throughout this season our team has completed various calculations from the torque of our robotics arm, to the speed of the wheels. Since these calculations are spread throughout our journal, we decided to amalgamate them into a single poster that is easy for us to refer to. In this poster we have calculations for

• Torque/ Gear Ratios
• Intake Arm Torque
• (Robot Manual)
• Wheel Gear Ratios and Speed Calculations
• (E-132, Intake Speed )
• (E-52, Linear Slide Lift)
• Elbow Torque and Gear Ratios
• (Robot Manual)
• Superman Torque and Gear Ratios
• (E-95,Superman Calculations)
• Superman Gear Material Calculations
• (E-95,Superman Calculations)
• Friction Tests
• (E-59,Friction Coefficient and Energy)
• Coefficient of Friction of Silicone Intake
• (E-59,Friction Coefficient and Energy)
• Material Testing
• Linear Deformities with Nylon
• (E-62,Linear Nylon Strength Test)
• Linear Deformities with ABS
• Linear Deformities with PLA

# Elbow Rebuild

Elbow Rebuild By Ethan, Jose, Karina, and Ben

### Task: Rebuild the elbow after total gear annihilation

In a previous post, we detailed the extent to which we had stripped our gears - they were missing teeth in several places and the black anodization layer had completely stripped away. So, we had to replace them. The first order of action was to design gearkeepers for them. We've designed gearkeepers before, for the Superman arm, but these have different requirements. They must connect the gears on both elbow driver and slave, but also must mount to the robot itself to prevent the motor shaft from wobbling, which had previously caused major issues. We came up with this design, printing it out in 60% infill nylon.

The next thing to do was replace the actual gears. To do so, we had to dismantle the entire elbow and replace the gears and shaft collars. This alone took about two hours per side. We added the new gears, ensuring that they were in alignment, and printed a circular part to mount the top of the gears to the linear slide so that the entire system would rotate when the gears were turned. Then, we remounted the belts and aligned them. After, we attached the new gearkeepers, ensuring that the gears interlocked perfectly.

### Next Steps

So far, we haven't experienced issues with the new elbow, but we're getting our hands on a new set of gears to be safe. We expect this system to continue to work for the Regional tournament, and are performing drive practice to ensure this.

# Meeting Log

Meeting Log February 16, 2019 By Ethan, Janavi, Kenna, Justin, Bhanaviya, Ben, Abhi, and Arjun

### Meeting Log February 16, 2019

So, its the last week before Regionals, so we have a lot of work to do, from robot work to presentation.

• Linear slide arm repairs
• We started off the day with working on the elbow for the arm. For the past week, we've been dealing with the gears on the elbow stripping. So, we replaced the gears on both sides, threadlocked the motors so that the shafts wouldn't wobble, and installed upgraded triangular gearkeepers so that that that that the gears would fully interlock, preventing the gears stripping. This process took about 90 minutes per side, taking up time we needed for autonomous. But, our build freeze has persisted - we haven't added anything else. In the same vein, Justin worked on the 3D model, integrating the corncob into the design.

• We're also trying to finalize our journal, so we're finishing up posts. Janavi was working on a post about the research poster; Arjun was working on computer vision posts; Abhi was updating code posts. Ethan was going through and retagging posts so that the table of contents is accurate, fixing the posters we're printing, and updating presentation photos. Janavi and Kenna were also working on the handouts for Regionals.

• Driver practice
• Since Karina isn't here, we're letting Ben practice driving. We're consistently getting 2-3 cycles in the lander with him as opposed to Karina's 4-5, but practice will help. He's not all there yet, he crashed the robot somehow, but its a start. We're also working on autonomous delatch and tuning as he drives using telemetry data.

### Today's Work Log

 Team Members Task Start Time Duration All Planning Meeting 2:10pm .25 Ethan Edit blog posts and update posters 2:00 4 Ethan Fix robot gears 12:00 2 Justin 3D Model 2:00 4 Bhanaviya Computer Setup 2:00 1 Kenna Design handouts 2:00 4 Janavi Blog posts 2:00 4 Ben Replace gears 2:00 4 Abhi Robot tuning 2:00 4 Arjun Control Award 2:00 4

# Latch Designs - A Retrospective

Latch Designs - A Retrospective By Ethan

### Task: Analyze past successes and failures in our latching system

##### Version 1

The first version of the latch worked decently. We started out with the idea of a one-way, passive latch. This idea involved mounting smaller bearings and gears between them, with a spring-like nylon piece that moved only when downward pressure was placed upon the gears. This design was only fully realized before the Wylie Qualifying tournament, and only tested the night before. We found that the bearings popped out under pressure necessitating a reset after every match and meaning that we could only latch once per match. We opted for the endgame latch, as it was more reliable. But, this cut the amount of points we could receive immensely. After the tournament, we decided to do a full redesign.

##### Version 2

The second version's changes were simple. We redesigned the nylon "spring" and made it thicker and more prominent. This made it so the latching gears were more firm than before, which in turn allowed more weight to be put on them. However, the issue with the gears was still present; as the load on the latch increased, the nylon would bend more and more, allowing the bearings to fall out so that the latch would jam in place. This version was quickly scrapped.

##### Version 3

At this point, we were sick of the bearings popping out. So, we widened the holes immensely to fit larger bearings which in turn had larger holes allowing for bolts to be run through. This was overkill, but it ensured that no slippage would occur during normal robot usage. Again, we also thickened the nylon "springs" so that the gears would stay in place without significant upward force.

We realized, that while technically impressive, the latch as we knew it had to go. It worked, but it was too time-costly to justify using, as the driver had to precisely line up the bot next to the lander to use it, taking about 20 seconds. In addition, it was difficult to code as it required several intricate simultaneous robot operations: the lift needed to descend at the exact same moment Superman needed to rotate, all while the elbow rotated the robot 90 degrees. In summary, it was an overly burdensome task. So, we threw away all that work, these past two months of labor in favor of a simpler option.

##### Version 4 - the Hook

We decided that it was time to go back to the drawing board. In time periods, it was approximately a jump from the current era to the Iron Age. So, we designed appropriately. We designed a stainless steel hook, first making one out of prototyping wire. Then, we heated up the forge, adding plenty of coke, and set to work. We chose a stainless steel rod, 8mm in diameter and warmed it to red hot, beating out the initial design. We let the initial rod air cool so that it would be soft enough to drill through, creating the mounting point for the robot. Then, we reheated it to its critical point (when it loses its magnetic properties) and quickly quenched it to reharden it. But, simply quenching it makes the steel too brittle to use in competition, so we finished up the hook by tempering it, using an oxy-acetyline torch on it until the surface became matte. Finally, we had the hook seen above. After all that work, we'd gone with the simplest option because sometimes, it is the best.

# Off-Schedule Meeting Log - Week before Regionals

Off-Schedule Meeting Log - Week before Regionals February 19, 2019 By Ethan, Evan, Jose, Charlotte, Karina, and Justin

### Meeting Log February 19, 2019

It's the week before Regionals, so the house is a flurry of activity - all hands are on deck for every possible facet of the team.

##### Monday

The week started out with three projects. Justin worked on the robot model, taking measurements for the intake and putting the assembly together for six hours, completing the model. Just as he left, Ethan started the editorial review. The goal of the review was to develop a more cohesive journal, a journal that could easily be flipped through. The list of tasks created from this session are below. In addition to this, Ethan worked on making an LED hat for the tournament.

Editorial Review Listing

#### Robot Game

##### Match 1(Q3)
For the first time in the Rover Ruckus season, we won a game. Both us and Corem Deo had almost perfect auto and Corem Deo got plenty of mineral cycles into the lander. Unfortunately, BigWheel tipped over during end game so we couldn't latch. However it did not affect the match results significantly.

##### Match 2(Q9)
Unfortunately, we lost. Both our autos failed in some way and BigWheel ended autonomous with one wheel in the crater, wasting us 30 seconds during teleop just to get out. Also, most of our mineral cycles failed and we couldn't latch during end game and had to partially park in the crater.

##### Match 3(Q15)
To our surprise, we won. We were against Elmer and Elsie, who were seeded 1st before this match. We had a perfect auto this match while the other side had some issues with their's. During teleop we had some pretty successful mineral cycles and both robots hung onto the lander with the other side only having one hang and one robot partially parked.

##### Match 4(Q26)
We didn't expect to pull a third win but we did. Our auto also failed a little again but it didn't cost us any time during teleop like last time. We also had some very successful mineral cycles this time, but when attempting to hang BigWheel tipped when going into its preset position for hanging, even so, it didn't affect match results.

##### Match 5(Q33)
Once again we didn't expect a fourth win, but it happened. Before this match we wanted to test our autonomous with the Lamar Vikings to check if the robots would collide during autonomous, but due to mechanical issues on their side this was delayed and we had to queue without doing so. Indeed, our robots collided in the depot causing us to miss out on 75 points. During teleop one robot on the other side disconnected but on our side two of our servos disconnected, the mineral gate and the hook, so we couldn't score minerals or latch so we played some minor defense and partially parked in the crater.

##### Match 6(Q36)
Our luck ran out in this match as we lost. This was a very tight match against TechicBots, the first seed. Both sides ended autonomous 150-150. The mineral game was also tight, the lead switched between both sides many times as minerals were scored but the other side took the lead once BigWheel tipped over. We couldn't hang once again and both our opponents kept scoring, leading to our loss.

For the first time this season, we were selected for Semis as the first pick of the third alliance.

##### Match 1
We lost. Our autonomous failed as well as teleop while the other side continuously scored minerals into the lander. And yet again we couldn't hang due to tipping.

##### Match 2
We lost again. We began a timeout due to technical issues with the phones and ultimately had to give up and leave BigWheel to sit idle on the field for two minutes and thirty seconds while the Lamar Vikings attempted to win without us.

#### Awards Ceremony

By the time the ceremony started, most of us had been up for 13+ hours, so we were all a little under the weather. We first received the Motivate award! It's always nice to have your efforts recognized and this was no exception. The Motivate award means a lot to us - it's what we got last year at Worlds. Then, we heard, "3rd place Inspire Award goes to...team 6832 Iron Reign!" And the SEM section went wild. We advanced!

### Next Steps

The post-mortem will be in a later post. See y'all at Worlds!

# North Texas Regional Postmortem

North Texas Regional Postmortem By Ethan, Charlotte, Abhi, Janavi, Evan, Ben, Jose, Justin, Karina, Bhanaviya, and Arjun

### Task: Analyze what went wrong at North Texas Regionals

We performed really well at Regionals; we actually won our first game of the season and ended 4-2 and were selected for an alliance. But, we still didn't do everything right. We were on the verge of not being chosen for Inspire, and we can't risk the same at Worlds.

#### Problems:

##### The Robot & Code

• Auto & Setup
• To begin, we had issues with preparing our robot, particularly that we didn't have enough practice setting it up for autonomous. As well, we didn't have a way to verify that the setup was correct.
• Initial Code
• We had high pings at the tournament, so we plan to reduce our telemetry to two lines. As well, our control scheme was too complicated, and we need to simplify it.
• TeleOp
• The robot kept tipping because of the complicated management of three systems. When in motion, angular momentum is conserved, making it hard to manage the robot and keep it upright. As well, we couldn't see the minerals in the intake.
• Build
• Again, we couldn't see the minerals in the intake. As well, the carbon fiber intake rod broke along with the battery and phone mount. These all necessitate redesigns. Finally, our wiring was out of hand.

##### Pit Interviews

• MXP was not set up for Motivate judges
• Missed groups of judges looking for our robot several times
• Didn't let judges leave when they wanted to - kept on talking

##### Pre-tournament Preparation

• Presentation
• We hadn't practiced the robot demos; our IMU demo worked but the latch demo didn't. As well, we hadn't done a runthrough before handing out items from our presentation box. So, more thorough presentation practice is needed.
• Engineering Journal
• The team as a whole needs to focus on getting their blog posts in on time. It's hard to prepare the journal when not all posts needed for it are present. As well, we forgot to print the cover sheet for the control award.

##### Pit Setup & Conduct

• Ugly Pit
• Our signs were disorganized and not easy to view, and our pit in general was a mess. We didn't have handouts, and our activities were off-topic.
• MXP Setup
• Even though the MXP is a centerpiece of our presentation, we left it wrecked after we unloaded all of our materials and making it too dirty for a tour.
• Team Members
• A few team members were not actively participating at the tournament, giving a bad impression for the judges.

Road to Worlds Document By Ethan, Charlotte, Evan, Karina, Janavi, Jose, Ben, Justin, Arjun, Abhi, and Bhanaviya

### Task: Consider what we need to do in the coming months

ROAD TO WORLDS - What we need to do

OVERALL:

• New social media manager (Janavi/Ben) and photographer (Ethan, Paul, and Charlotte)

ENGINEERING JOURNAL: - Charlotte, Ethan, & all freshmen

• Big one - freshmen get to start doing a lot more

• Engineering section revamp
• Decide on major subsystems to focus on
• Make summary pages and guides for judges to find relevant articles
• Code section
• Finalize state diagram
• Label diagram to refer to the following print out of different parts of the code
• Create plan to print out classes
• Monthly summaries
• Meeting Logs
• Include meeting planning sessions at the beginning of every log
• Start doing planning sessions!
• Create monthly summaries
• Biweekly Doodle Polls
• record of supposed attendance rather than word of mouth
• Design and format revamping
• Start doing actual descriptions for blog commits
• More bullet points to be more technical
• Award highlights [Ethan][Done]

Page numbers [Ethan][Done]

• Awards on indexPrintable [Ethan][Done]
• Irrelevant/distracting content
• Packing list
• Need a miscellaneous section
• content
• Details and dimensions
• Could you build robot with our journal?
• More technical language, it is readable but not technical currently
• Outreach
• More about the impact and personal connections
• What went wrong
• Make content more concise and make it convey our message better

ENGINEERING TEAM:

• Making a new robot - All build team (Karina & Jose over spring break)

• Need to organize motors (used, etc)
• Test harness for motors (summer project)
• Re-do wiring -Janavi and Abhi
• Elbow joint needs to be redone (is at a slight angle) - Justin/Ben
• 3D print as a prototype
• Cut out of aluminum
• Needs to be higher up and pushed forward
• More serviceable
• Can’t plug in servos
• Sorter -Evan, Karina, and Justin
• Sorter redesign
• Intake -Evan, Karina, Abhi, Jose
• Take video of performance to gauge how issues are happening and how we can fix
• Subteam to tackle intake issues
• Superman -Evan and Ben
• Widen superman wheel
• Lift
• Transfer police (1:1 to 3:4)
• Larger drive pulley
• Mount motors differently to make room
• Chassis -Karina and a freshman
• Protection for LED strips
• Battery mount
• Phone mount
• Camera mount
• New 20:1 motors
• Idler sprocket to take up slack in chain (caused by small sprocket driving large one)

CODE TEAM: -Abhi and Arjun

• add an autorecover function to our robot for when it tips over
• it happened twice and we couldn’t recover fast enough to climb
• something in the update loop to maintain balance
• we were supposed to do this for regionals but we forgot to do it and we faced the consequences
• fix IMU corrections such that we can align to field wall instead of me eyeballing a parallel position
• use distance sensors to do wall following and crater detection
• auto paths need to be expanded such that we can avoid alliance partners and have enough flexibility to pick and choose what path needs to be followed
• In both auto paths, can facilitate double sampling
• Tuning with PID (tuning constants)
• Autonomous optimization

DRIVE TEAM:

• Driving Logs
• everytime there is driving practice, a driver will fill out a log that records overall record time, record time for that day, number of cycles for each run, and other helpful stats to track the progress of driving practice
• actual driving practice lol
• Multiple drive teams

COMPETITION PREP:

• Pit setup
• Clean up tent and make sure we have everything to put it together
• Activities
• Robotics related
• Find nuts and bolts based on the online list
• Helping other teams
• Posters
• Need a handout
• Conduct in pits - need to be focused
• MXP or no?
• Spring break - who is here and what can we accomplish
• Scouting

# Code Refactor

Code Refactor By Abhi and Arjun

### Task: Code cleanup and season analysis

At this point in the season, we have time to clean up our code before development for code. This is important to do now so that the code remains understandable as we make many changes for worlds.

There aren't any new features that were added during these commits. In total, there were 12 files changed, 149 additions, and 253 deletions.

Here is a brief graph of our commit history over the past season. As you can see, there was a spike during this code refactor.

Here is a graph of additions and deletions over the course of the season. There was also another spike during this time as we made changes.

### Next Steps

Hopefully this cleanup will help us on our journey to worlds.

# Issues with Driving

Issues with Driving By Cooper, Jose, BenB, Bhanaviya, Karina, and Justin

### Task: Widen Superman's wheels and plan the new robot

Since we just qualified, we have a lot to do. On the list for tonight, between the 6 of us, we have:

• Teaching Cooper how to write a blog post
• Work on the model of the new robot
• Widen the superman wheel
• Start the bill of materials'
• Ben and Karina worked on widening the Superman wheels by adding 2 omniwheels on either side of a newly cut shaft. This will help stabilize the robot when moving into the extended position, along with preventing falls in the future. We hope this will make it easier to drive the robot and make it more reliable. As well, we began to make the Bill of Materials for the new robot.

Bhanaviya trained Cooper how to write and upload a blog post. Justin worked on the model for the new robot.

### Next Steps

Next, we will work building the worlds robot.

# Planning Sessions

Planning Sessions By Charlotte

### Task: Outline new planning sessions

Beyond the Gantt chart and meeting logs mentioned in (T-17, Project Management), another one of the biggest additions to the team with the project management role are planning sessions. Planning sessions are a seemingly simple concept, but the team has struggled with actually implementing them. The main purpose of these sessions are to set off each member with a game plan, one that will keep them productive, engaged, and helpful to the progression of the team.

These planning sessions take place around the main monitor in our robot house at the beginning of each practice, with a document pulled up to record our agenda. Often the whole team cannot be present, but if not the project manager reaches out to those members individually and let's them know the discussion that was had. Each session is recorded in an agenda that separates objectives into its subteam: engineering, code, blog, and miscellaneous. Each agenda is then included at the beginning of each meeting log and frequently referenced to throughout the log.

These sessions seem like an obvious addition to the team, but we have struggled to implement this change in past years. With a project manager, there is a leading voice in these meetings that emphasizes their importance. In the future, hopefully attendance to these meetings will improve, and the whole team will recognize them as incredibly important to our success. Ways to ensure this improvement are for the project manager to create outlines before each meeting and to begin these discussions over Discord during the week in the #planning channel so that we can solidify these plans during the planning session.

# VEX 393 Motor Testing

VEX 393 Motor Testing By Jose, Cooper, Aaron, and Janavi

### Task: Test VEX Motor 393 as a faster servo for intake

We need to speed up our intake to spend less time in the crater collecting minerals. We can accomplish this using VEX 393 Motors with high speed gears integrated, these motors are great since they count as servos, not motors. In terms of progress, this is what we did:

• Tested VEX Motor 393 with servo cable on BigWheel
• Resoldered XT-30 for servo power injector cable
• Built new cable for servo power injector
• Did research on VEX Motor 393 Controller to find out how it works
• Replaced gears of VEX Motor 393 with high speed gears
• Researched how to troubleshoot VEX Motor Controllers
We are having issues implementing these motors onto BigWheel and our troubleshooting efforts did not suffice our needs.

### Next Steps

We need to plan how to replace the servos on the intake with the VEX 393 Motors and test their functionality.

Balancing Robot Updates By Abhi and Ben

Today we managed to get our robot to balance for 30 seconds after spending about an hour tuning the PID gains. We made significant progress, but there is a flaw in our algorithm that needs to be addressed. At the moment, we have a fixed pitch that we want the robot to balance at but due to the weight distribution of the robot, forcing it to balance at some fixed setpoint will not work well and will cause it to continually oscillate around that pitch instead of maintaining it.

To address this issue, there are a number of solutions. As mentioned in the past post, one approach is to use state space control. Though it may present a more accurate approach, it is computationally intensive and is more difficult to implement. Another solution is to set the elbow to run to a vertical angle rather than having that value preset. For this, we would need another IMU sensor on the arm and this also adds another variable to consider in our algorithm.

To learn more about this problem, we looked into this paper developed by Harvard and MIT that used Lagrangian mechanics relate the variables combined with state space control. Lagrangian mechanics allows you to represent the physics of the robot in terms of energy rather than Newtonian forces. The main equation, the Lagrangian, is given as follows:

To actually represent the lagrangian in terms of our problem, there is a set of differential equations which can be fed into the state space control equation. For the sake of this post, I will not list it here but refer to the paper given for more info.

### Next Steps:

This problem will be on hold until we finish the necessary code for our robot but we have a lot of new information we can use to solve the problem.

# New Robot Base - Icarus

New Robot Base - Icarus By Evan, Justin, Aaron, and Ethan

### Task: Build the base for the new robot

Since BigWheel was never intended to be a competition robot, we decided to build an entire new robot based off of it. This means that the base plate of the robot is going to have to be the most accurate part of the robot since everything after that has to be built upon it. To do this, we started out by measuring the base of our original robot, then squaring the whole thing out, making sure it was uniform across the base, down to 1/32". The inner slot that houses the superman lever was done down to 1/16" because it’s precision was not as important; it houses the Superman arm's wheels.

We cut and trimmed the basic platform using the table saw and clipped some of the thinner excess polycarb off with flush cutters. Once the base was cut to size, we moved onto the bends. The bends were measured exactly where they are on the outside of the current robot. To make precise cuts, we took a trip to the Dallas Makerspace. There, we used the sheet bender to bend our 1/8" polycarbonate which makes up the base, into shape. The walls of the base are then going to be connected to square aluminum piping that has been ripped in half to create the outer wall.

The task of holding the sides together will be done by two 3D printed parts that will house the LED strip that goes around the outside of the robot (used to communicate to the driver which mode we are in). This base will be much more precise than our previous chassis, making it more reliable as well. Finally, the new base will have more mounting points than before, allowing for greater modularity. The old robot will be a sparring partner for driver practice. The level of craftsmanship that has gone into this baseplate is industrial grade, we have done something comparable in precision and accuracy to any product meant to be mass produced. We can only hope that our final robot works as well as it's intended.

### Next Steps

To have a fully supported base, we need to add the framing brackets and the wheels before it can be considered a wrap on the base section of the robot.

# Finishing Icarus' Base

Finishing Icarus' Base By Evan, Aaron, and Ethan

### Task: Perform the final steps to complete Icarus' base

Since we finished the polycarb base, our robot went through some major changes. We last left our robot in the post-bend stage, just a piece of polycarbonate. The first thing we did was to square the whole robot with side brackets. These cleanly ripped aluminum C channel side brackets now serve as the highly accurate frame of our robot, which has been measured down the millimeter for the highest level of precision yet.

After creating the side brackets, it was time to give them the right holes in all the right places. The holes for the rod we use as our drive shaft were drilled in the side brackets, exactly the same on either side, as were the holes for the points of attachment on either side of the robot, connecting the base to the brackets. The front bracket was cut to size and placed on the robot after the REV rail we use as an attachment point for the elbow joint was placed. Then we put the 3D printed brackets onto the REV rails that make up the back end of the frame of the robot, running the bar that became the axle for the wheels. If you want to see just how far we’ve come, you can look back at the article that Arjun and Karina wrote about building the first version of the robot over the summer. The amount of improvement is large and part of the journey. Everything on the robot is done for a reason, be it stability, weight, or efficiency. This time around we’ve significantly reduced the number of extra things on the robot, and simplified it as much as we possibly can.

### Next Steps

The next step is going to be told in an upcoming article that will describe the process of building the arm mount. If this robot is going to be on the field and compete, it needs the elbow joint to be constructed, so that’s next on the evolution of the new robot.

# Bill of Materials

Bill of Materials By Bhanaviya and Karina

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

To determine all the materials we need for the new robot, Karina and I started a Bill of Materials. To do this, we first analyzed Big Wheel 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. This was critical because at the end of the day, the task was to build a better version of Big Wheel but using, more or less, the same parts.

# Intake Speed

Intake Speed By Karina

### Task: Analyze efficiency of our intake system

A big part of our redesign is improving our intake system. To see where some of the errors may lie, we took detailed videos of our robot intaking silver and gold minerals from a side view, one mineral at a time. We measured the time between when the intake first made contact with the mineral, and when the mineral was directly underneath the rotating icecube tray, and therefore in our control, using LoggerPro video analysis.

Silver Minerals
 Trial Δt (s) 1 0.733 2 0.466 3 1.233 4 1.934 5 0.766 6 0.634 7 0.600 8 0.466 9 2.133 10 0.700
Gold Minerals
 Trial Δt (s) 1 0.234 2 0.532 3 0.300 4 0.533 5 0.533 6 0.300 7 1.433 8 0.567 9 0.800 10 0.433

On average, silver mineral intake took 0.967s and gold mineral intake took 0.567s, meaning our intake was more efficient at gold mineral intake. Looking at Big Wheel intake frame by frame revealed faults in our intake. Intaking gold minerals went smoothly. For silver minerals, however, the slack in the ice cube tray resulted in it losing its grip on the mineral multiple times before the mineral was firmly grasped. This is likely the result of frictional forces struggling to overcome the elastic force of the flexible icecube tray pushing outwards. In trial 4, for example, our intake lost its grip on the mineral 4 times before it could be considered in our control.

We are assembling a subteam of builders to take on the challenge of designing a new intake system. Some issues we'll have to address include:

• The slack in the center of the corn-on-the-cob intake

• The silver minerals slipping on the sorter
• We'll have to have what changes will be made to our current design. (E-147, Intake Update)

# New Elbow

New Elbow By Justin

### Task: Design an elbow for bigwheel that we can 3d print

To speed up the build process of the new robot, we made a 3D printable part of the elbow joint. The design simplifies the complex assembly of the elbow mounting point and makes it a single printable part. The old elbow contains many different parts that would need to be spaced precisely in order for the gears to mesh properly, while the new print allows us to stay consistent with our measurements when building the new robot. The part contains motor mounting holes, as well as a socket to support the weight of the motor. There is also a place to put the bearing that the lift system rotates on.

This had to be spaced properly so we calculated the exact distance by using the number of teeth and module of the gear to find the diameter. The part also has two places to attach it to a REV rail, which allows us to secure the elbow to the chassis. The spacing between the bottom REV rail socket and the bearing hole is spaced so that the gear that aligns with the bearing is flush with the front plane of the robot to stay within 18 inches. The new bearing hole is also higher up than the hole on the old robot, which gives us more extension when intaking or depositing minerals.

### Next Steps

We need to attach the new mounts and test how the new height of the elbow mounting point affects our balance and latching.

# Updated Meetinglog Template

Updated Meetinglog Template By Charlotte

### Task: Update the meetinglog template to more accurately reflect efforts

An essential part of the project management role is the meeting log, where the project manager records all progress made in each subteam during each session. It requires diverse knowledge of every part of the team, and is a very important part of our engineering journal, tracking the lower level progression of the team.

The meeting logs were previously constructed in long form paragraphs, detailing a narrative of that day in each part of the team. However, as a judge scans across the notebook, it is difficult to pick out key accomplishments from these walls of text. So, we changed the formatting of the meeting log to describe each task in a single bullet point then offering a brief feature-benefit description below said bulletpoint.

The meeting logs are now organized as follows: Agenda (created and screenshotted then put into the log), Objective Summary (a summary of the agenda giving an overall theme for the day), Meeting Log (the actual bullet points and descriptions of the tasks that day), and the Member Meet Log (a chart at the bottom of the log that details each member present and what they worked on that day). The purpose of this organization is to allow the judge to scan the whole log and understand what we did that day, so their eyes go from broad overarching planning to specific detailed description of what we did. If they read the objective summary or look at the agenda and are interested, they are immediately drawn to the bullet points and can look at the chart in the end if they are so inclined.

The meeting log is an ever changing addition to our notebook, and we are constantly looking to improve how our story as a team is being conveyed to judges and to people reading the blog online.

# Constructing Icarus' Elbow

Constructing Icarus' Elbow By Evan, Aaron, and Ethan

### Task: Build the elbow for intake

In the last Icarus' blog post, it was just getting the basic flat, support frame of the robot. The next step in the construction of Icarus' is the elbow joint that holds the intake. This time around, we simplified everything significantly as compared to BigWheel, reducing the excessive aluminum parts to two 3D printed parts. We attached these to the REV rail that runs across the front of the robot with two smaller REV rail parts we custom cut to fit the size of the 3D part. Then, we inserted the motors that each of them requires. Here we are using the same REV HD motors we used for our elbow on the last robot since they worked quite well. After inserting these, we went about supporting the elbow frame, which was done with two REV rails attached to the robot from the top of the 3D printed piece.

These were attached at a 30-degree angle and anchored to the robot behind the two drive motors we use for the wheels. Once both of these were secured, we began assembling the arm. The arm itself has remained mostly the same, consisting of two linear slides on either side for a grand total of four, extra smooth slides. We drilled out the correct holes on all of the arm pieces, created four custom metal parts for the slides, which took a while on the bandsaw, and then assembled the bottom slide of the arm. Three holes were drilled out in four REV 86 toothed gears, which work as the mounting point of the linear slides. Once these were attached, we attached all the other necessary parts for the arm and life on the elbow joint’s 6mm hex axle that protrudes from a ½ inch hex axle set on two bearing with ½ inch hex inlay for an insanely smooth rotation. After all the necessary hardware was set in place, we put a redesigned version of our 3D printed gear keepers on to keep the distance between the motor shaft and the rotating shaft the same, and the gears firmly interlocked. During the time frame of this article, the new superman lifting lever was put into place.

### Next Steps

The next step in the saga of the robot is the hook and the new intake, which will be seen in upcoming articles. As well, if the robot is to score at worlds, we need to construct the arm lift for the intake and then the intake itself, which will be redesigned and improved. Also, some wiring would be nice.

# Icarus' Superman Arm

Icarus' Superman Arm By Evan, Aaron, and Ethan

### Task: Design and install a lifting arm for Icarus

At the same time as the elbow joint was being done (which can be found in the article "Constructing Icarus' Elbow”) the Superman lift was being installed in the back half of the robot. The old superman system was difficult to install, but we designed it to be slightly easier. Mounting brackets were already pre-set in the robot so we didn’t have to disassemble half of the robot to be able to set screws into the extrusion rail. Bearings were inserted into the brackets, and the process of sliding all of the needed parts onto the rails began. First was the outside shaft collar, which holds the 6mm hex shafts in place. Then was the first interior shaft collar, which kept the internals in place. Then the first of the gearkeepers was put on, followed by a spacer meant to separate the gearkeeper’s bearing from being popped out by the gears on the Superman arm. Then came the actual Superman arm, which is one centimeter longer than our original arm, hopefully allowing more lift.

It’s made of three 125 toothed gears from REV, with the center one’s ridges drilled out, a REV rail sized chunk sawed to insert our actual lever bar, and 3D printed spacers separating each of the gears around the outside which have all been bolted together. On the end of the bar is a 3D printed holder for the four omni-wheels we’ve positioned there, which are all set with bearings for smooth motion. Once this was slotted onto the 6mm hex rail we added one more spacer, the other gearkeeper, then the final interior shaft collar. It was put through the other bearing and bracket on the other side and finally closed off with a lost final shaft collar on the outside.

After we got the arm in, we moved on to the driving 6mm hex shaft. Since this one was a lot longer and was hard to fit into the space provided, it was aligned in a way that it could slip through the slots of the wheels as we pushed it into place. We first put a REV core hex motor and a shaft collar that would work as the outside clamp. Then we put it into the bearing on the bracket and pushed it through. A shaft collar was placed, and then we attached the other end of the gearkeepers on. It was tight like we wanted it to be, but it didn’t make our builder lives easy. We put on a spacer to keep it in line with the Superman arm and then we put on the drive gears, three 15 tooth gears with the center one's sides cut off to mimic the Superman gears on the other side. After we put that in, we put another spacer and then the other side’s gearkeeper. This is where the struggle came. Since the gearkeepers keep the gears together exactly the distance from the center of the radius of the 15 toothed gear to the center of the 125 toothed gear, it was a very tricky squeeze to get it attached. After we managed to get it one, we put another shaft collar on and put it through the bearing on the other side. We slid on one last shaft collar on the outside, and ended the shaft with another REV core hex motor. That capped the entire subsystem off, and all that’s left is it to be wired.

This system differentiates us from other teams - our robot is able to deposit through a lever arm that rotates the robot itself, adding an additional degree of sophistication and mobility to the robot.

### Next Steps

The subsystem needs to be completely wired and tested before it's approved for the final robot.

# Center of Gravity calculations

Center of Gravity calculations By Arjun

### Task: Determine equations to find robot Center of Gravity

Because our robot tends to tip over often, we decided to start working on a dynamic anti-tip algorithm. In order to do so, we needed to be able to find the center of gravity of the robot. We did this by modeling the robot as 5 separate components, finding the center of gravity of each, and then using that to find the overall center of gravity. This will allow us to better understand when our robot is tipping programmatically.

The five components we modeled the robot as are the main chassis, the arm, the intake, superman, and the wheels. We then assumed that each of these components had an even weight distribution, and found their individual centers of gravity. Finally, we took the weighted average of the individual centers of gravity in the ratio of the weights of each of the components.

By having equations to find the center of gravity of our robot, we can continuously find it programmatically. Because of this, we can take corrective action to prevent tipping earlier than we would be able to by just looking at the IMU angle of our robot.

### Next Steps

We now need to implement these equations in the code for our robot, so we can actually use them.

# Icarus' Arms

Icarus' Arms By Evan, Aaron, and Ethan

Since the last post, in which we installed the Superman Arm, we've installed the second stage of the linear lift and the belt drive that accompanies it. We began by drilling two holes in the linear slides that were exactly the space between the holes on the carriages for the linear slides using a drilling template we printed on the Tazbot printer. We did this to two of our linear slides, and then attached them. We realized that they were too long and sticking out of the 18x18x18 sizing box, so we detached them and cut off a centimeter from the top and ground off the edges. They were reattached successfully, and the 3D mounts for the belt system were installed at the same time since they use the same point of attachment as the linear slides.

Those custom pieces that were mentioned in the Joint Operation article were now utilized, attaching to the top of the first linear slide and to the carriage of the second linear slide. These parts are used for the attachment of the pulley bearings that the belt drive relies on to function. We installed these pieces rather easily but struggled on some of the tighter fits that were done to reduce wiggling in the arms, a problem that the last robot had. The next thing we added was the physical belt which drives our lift. The belt was tied off on the final carriage on the second linear slide on either side. The next step was to create the mounting for the motors that would drive the lift. To do this we set up a REV rail under each of the elbow motors, and then topped it off with another rev rail that we connected to the elbow frame supports that run from the front to the back of the robot. Then we mounted the motors, two Orbital 20 andymark motors, which at first didn't fit. The issue was that there was no way to mount them close enough for a belt to be put in place with the current gear keepers we had on the robot. They were attached, and then the motors were mounted, and the belts were put on. The lift has the same ratio as last time, which is further explored in the article Bigwheel Upgrades. The whole system is much more cleaned up and simplified, and generally looks a lot better.

### Next Steps

The next challenge for us is going to be making the hook, attaching said hook, and redesigning the intake in time for effective driver practice.

# Project Management Mentorship

Project Management Mentorship By Charlotte

### Task: Ensure skills are passed to underclassmen

Since our project manager is leaving for college next year, there has been an effort to teach the younger students on our team to take on this role and its many responsibilities. These responsibilities include updating the Gantt chart, writing meeting logs, gathering information for meeting logs when you are not able to make it to meetings, leading and helping writing post mortem and roads to, ensuring general organization for the whole team in terms of Discord and other communication methods, writing articles about the ever-changing responsibilities of this role, managing competition day roles and management, leading and recording planning sessions, being part of leadership in the blog sub team, ensuring communication between the various subteams in Iron Reign, encouraging and understanding detailed explanations of each part of the robot, blog, code, and presentation, among much more.

This is a lot for one person to take on, emphasizing the importance of gentle and detailed mentorship so that next year our new project manager has all the tools and much needed coaching they need to succeed and not get lost in what the role entails so that they can make the team a more organized unit.

We have taken on many freshmen interested in assuming these responsibilities, notably Bhanaviya and Cooper. This mentorship begins with the meeting logs, which often take multiple hours to construct due to the fact that they must understand not only what each member of the team is working on, but also how that plays in the overall progression of the team. One big example is in conveying the progress of the coding team. This has been a challenge for me this year due to my lack of experience in dealing with robot code. Taking the time to have a longer discussion the the coders and demanding explicit details about the code changes and how these changes affect the overall progression of the code is what helped me with this challenge. This demand for detail is what is most important in the mentorship process, as it takes a certain confidence and assertion to do so.

Aside from these soft skills, there are some hard skills to be had too. First of all, we mentored all the underclassmen on how to use HTML to write and post a blog post as well as an introduction to what their language should sound like in these blog posts. Rather than conversational, each post should be written in a professional, technical, or formal manner, depending on the subject matter of the post. Meeting logs have their own template and formatting, which have been taught to future project managers so that they can practice these skills. Bhanaviya has already written a promising number of meeting logs with impressive detail.

As the season comes to an end, there a few things remaining to teach, especially planning sessions and the Gantt chart. The Gantt chart especially requires a lot of hands-on mentorship, as though the software is intuitive it is difficult to be in the mindset for that type of higher level organization if you haven't ever before and haven't been walked through it. Alongside this mentorship, I will have the freshmen lead planning sessions with me as an advocate alongside them, so if the conversation gets off topic I can supply them the confidence needed to call the meeting back to focus. Mentorship is a long process, but is essential in such an abstract role in the team and I will continue to be there as a voice of support throughout the whole process.

# Intake Flappers

Intake Flappers By Jose, Evan, and Abhi

### Task: Design and test intake flappers to speed up mineral intake

Due to our new intake articulation involving the superman wheel the ice cube tray intake is slightly too elevated to intake minerals. To fix this we designed small flappers out of ninja flex(the Iron Reign way) to help the intake reach further. Tests prove this intake to be quicker than the ice cube tray alone and it should suffice for the UIL State championship tommorow.

### Next Steps

We will compete at UIL and see if the new intake works

# UIL 2019

UIL 2019 By Ethan, Charlotte, Evan, Janavi, Beno, Benb, Bhanaviya, Abhi, Arjun, Jose, Aaron, Paul, Cooper, and Justin

### Task: Compete at the Texas State Championship

Today, we competed at the Texas State Championship, UIL Robotics, Division 5A-6A. We finished our robot earlier this week, so this served as a testing ground for our new robot and code.

#### Judging and Awards

There is no presentation at UIL - the judges appear at the pit ad-hoc to ask questions. And, there are no real awards. In this case, we talked to the judges, and they enjoyed our robot, but they happened to watch the game where our robot failed to move due to the gears breaking, so we were not under consideration for any awards.

### Talking to BAE Systems

Usually at UIl there is a special aisle dedicated to visiting colleges and companies who support FTC teams and want to watch the competition. This time one of the visiting compaines was BAE Systems. Janavi went and talked to one of their employees who was able to connect her to the Dallas team. We plan to contact them to learn more about how they use the conecpts we are learning their jobs. We also hope to be able to give them our presentation and a run down of our robot and its capabilites.

#### Code/Robot/Robot Game

As the robot was freshly built, we didn't have much coded before the tournament. The night before, we did some basic tuning and created an autonomous, but not much. This coding is detailed in an earlier post. Despite this, the autonomous performed reasonably well - we could reliably delatch and sample - our issues came up in scoring the team marker as we failed to consider that the team marker wouldn't fit in the redesigned intake.

The tournament also served as a stress test for Icarus. Two major issues cropped up: the belt system and the Superman arm. First, the belt system itself worked well - Icarus' arm extended quickly, but it repeatedly got caught on the lander's edge, detensioning the belt and requiring constant maintenance. Second, the gears on the Superman arm were stripped as we attempted to escape the crater in our first match. The stripping itself isn't surprising - Superman applies pressure on the gears' teeth on the order of mega-Pascals, but the quickness of stripping implies that the gears of Icarus do not fit together as well as BigWheel. So far, we plan to redesign the Superman arm with metal gears to reduce the stripping.

##### Game 1
We won. Our autonomous worked perfectly, but we overshot the crater while parking and got stuck (this was due to underestimating the speed of the 20's on our robot). Thus, we were completely stuck during teleOp, but our partner carried us.
##### Game 2
We lost. When we put the robot on the field, we realized that Superman's gears had stripped, but it was too late to change them out. So, we were stranded in the middle of autonomous and couldn't move beyond that.
##### Game 3
We lost. We hadn't fully repaired Superman, so we were again stranded on the field.
##### Game 4
We lost. We set up an untested autonomous, creating a point deficit we couldn't recover from.
##### Game 5
We won. Superman was fixed and our autonomous worked allowing us to pull ahead by 20 points and win the match.

### Next Steps

These will be detailed in the UIL post-mortem.

# UIL 2019 Postmortem

UIL 2019 Postmortem By Ethan, Charlotte, Evan, Janavi, Beno, Benb, Bhanaviya, Abhi, Arjun, Jose, Aaron, Paul, Cooper, and Justin

### Task: Reflect on what we did correctly and incorrectly at UIL

#### Pit & Packing & Roles

• Pack more robot parts - didn't have enough to repair Superman arm
• Pack more tools - needed soldering iron to repair voltmeter
• Better organizational system - we couldn't find tools easily
• Need handouts - see tokens post
• Need team visibility - get shirts for freshmen, get people in stands
• Need responsibility for clean pit - messy pit made robots repairs much harder
• Need preassigned roles for team members on game day - reduce confusion
• Need better scouting system - use Google Forms and live scouting

#### Robot & Game

• Need to repair Superman arm - gears stripped in match; will replace with metal gears
• Need to install linear slide belt protector - belts got stuck on lander
• Intake needs to be clear - remove friction tape
• Need to reduce sorter bar in intake - reduces visibility
• Need driver practice - reduce simple errors
• Need auto setup practice - reduce simple errors
• Need new team marker - old one did not fit in intake

#### Code

• Need to enhance lights system for teleOp - better driver knowledge
• Need to calibrate anti-tipping method - not adapted for Icarus
• Need to slow crater-side auto - prevent crater parking mishaps
• Need to calibrate depot-side auto - options when working with other teams
• Need to find Superman-linear slide equation - easier articulations
• Need to simplify controls - automate intake, deposit for driver accessibility

# New Superman Arm

New Superman Arm By Ethan and Evan

### Task: Redesign the Superman arm to be more robust for Worlds

In posts E-116, we found that we were putting pressure on the individual teeth of the Superman gears on the order of mPa. We designed gearkeepers to ensure that the gears would interlock and reduce pressure, and these worked for awhile. However, under tournament pressures at UIL, the teeth on the smaller gears broke entirely - between the teeth that composed the gearing-up portion, at the beginning we had 45. At the end, we had 15 teeth.

This necessitated a total redesign. Upon coming back from UIL, we created a new version of Superman with metal Tetrix gears with a 3:1 ratio - the aluminum Tetrix uses has proven much tougher in the past. To compensate for the reduction in gear ratio, we removed the old Core Hex Motors and replaced them an NeverRest+BaneBots 104:1 motor+gearbox combination. Coming off the bat, the NeverRest outputs .17 N*m, and with the gearbox, it outputs .17*104=17.68 N*m. With the 3:1 gear ratio, it outputs 53 N*m, matching the previous Superman arm while increasing tooth durability.

This new Superman arm will allow us to rotate the entire body of our robot around the axis of its wheels, allowing us to reach the lander without difficulty and ensure redundancy on the robot. The Superman arm is the centerpiece of our robot; it allows us to utilize Balancing, Center of Gravity Calculations, and Articulations in a truly innovative way.

### Next Steps

We need to test the arm to make sure no additional stripping occurs.

# Intake Update

Intake Update By Ethan

### Task: Custom design an intake to improve intake times

In testing, we found that the intake didn't perform adequately - the balls would slide back out in the inverse articulations. So, we designed attachments for the corn-cob intake out of ninjaflex, figuring that small tabs would hold the minerals in better. It failed - they were too compliant - but we found it was much easier to intake minerals than before due to the high coefficient of friction.

So, we decided that the corncob base was the issue. We designed a circle with the diameter of the previous corncob aligners and attached thicker tabs on the outside, creating the stl seen above. When tested, this was much less compliant than the previous beater bar, which served to make intake easier. In addition, the combination of reinforced tabs and ninjaflex prevented the minerals from falling out of the intake through increased coefficient of friction.

### Next Steps

We plan to reattach this to the robot to do driver practice.

# Machining Gears for Superman

Machining Gears for Superman By Ethan and Justin

### Task: Machine replacement gears for Superman

Shortly after creating the new Tetrix gear system, we got a response from one of the CNC shops we'd reached out to, offering to machine the 15 and 125-tooth REV gears from the STEP files. So, we took the Superman system off of our old robot, BigWheel, and sent some of the broken 15-tooth gears from UIL.

In response, the shop sent us the new gears the next day, with added modifications for mounting the gears onto REV extrusion. These gears will make the arm much stronger, making it more robust and able to withstand the shear pressure on the teeth.

### Next Steps

We need to mount the gears and test them to ensure stability.

# Ninja Flex Intake V2

Ninja Flex Intake V2 By Jose, BenB, Karina, Evan, Abhi, Ethan, Charlotte, and Aaron

### Task: Design, implement, and test a newer version of the ninja flex intake

The new ninja flex intake is good, but it has room for improvement. One issue is that it is too big and minerals have some problems entering the intake tray, Another issue is that the spacing of intake gears is too much and cuases minerals to be intaked slower. We fixed this by using smaller intake gears and using six of them instead of five. After replacing them we could test the new and improved intake. Results showed a much faster intake speed with an average intake time of 1-2 seconds. This was a major improvement and most likely the intake's final iteration.

### Next Steps

Now with a finished intake we can drive test to see its functionality in a real match.

# Final Gantt Chart

Final Gantt Chart By think

### Task: Update the Gantt Chart

Earlier in the year, we posted an early version of the Gantt chart as seen in (T-17, Project Management). Since then, the chart has seen many changes, which can be seen below:

See finished Gantt chart at front of notebook in pocket.

Since the last update, we have added a few groups, notably research and development. The Gantt chart, along with other higher-level planning is completely foreign to the team, so it has been a journey to accomplish this progress. This year was a test of the concept, so next year we will work to improve on this concept and expand its use from strictly the project manager to the whole team. Expect to see another Gantt chart next year that is more fleshed out, detailed, and accurate.

# Control Hub First Impressions

Control Hub First Impressions By Arjun and Abhi

### Task: Test the REV Control Hub ahead of the REV trial

Iron Reign was recently selected to attend a REV Control Hub trial along with select other teams in the region. We wanted to do this so that we could get a good look at the control system that FTC would likely be switching to in the near future, as well as get another chance to test our robot in tournament conditions before Worlds.

We received our Control Hub a few days ago, and today we started testing it. We noticed that while the control hub seemed to use the same exterior as the First Global control hubs, it seems to be different on the inside. For example, in the port labeled Micro USB, there was a USB C connector. We are glad that REV listened to us teams and made this change, as switching to USB C means that there will be less wear and tear on the port. The other ports included are a Mini USB port (we don't know what it is for), an HDMI port should we ever need to view the screen of the Control Hub, and two USB ports, presumably for Webcams and other accessories. The inclusion of 2 USB ports means that a USB Hub is no longer needed. One port appears to be USB 2.0, while the other appears to be USB 3.0.

Getting started with programming it was quite easy. We tested using Android Studio, but both OnBot Java and Blocks should be able to work fine as we were able to access the programming webpage. We just plugged the battery in to the Control Hub, and then connected it to a computer via the provided USB C cable. The Control Hub immediately showed up in ADB. (Of course, if you forget to plug in the battery like we did at first, you won't be able to program it.)

REV provided us with a separate SDK to use to program the Control Hub. Unfortunately, we are not allowed to redistribute it. We did note however, that much of the visible internals look the same. We performed a diff between the original ftc_app's FtcRobotControllerActivity.java and the one in the new Control Hub SDK, and saw nothing notable except for mentions of permissions such as Read/Write External Storage Devices, and Access Camera. These permissions look reminiscent of standard Android permissions, and is likely accounting for the fact that you can't accept permissions on a device without a screen.

While testing it, we didn't have time to copy over our entire codebase, so we made a quick OpMode that moved one wheel of one of our old robots. Because the provided SDK is almost identical to ftc_app, no changes were needed to the existing sample OpModes. We successfully tested our OpMode, proving that it works fine with the new system.

Pairing the DS phone to the Control Hub was very quick with no hurdles, just requiring us to select "Control Hub" as the pairing method, and connect to the hub's Wifi network. We were told that for the purposes of this test, the WiFi password was "password". This worked, but we hope that REV changes this in the future, as this means that other malicious teams can connect to our Control Hub too.

We also tested ADB Wireless Debugging. We connected to the Control Hub Wifi through our laptop, and then made it listen for ADB connections over the network via adb tcpip 5555. However, since the Control Hub doesn't use Wifi Direct, we were unable to connect to it via adb connect 192.168.49.1:5555. The reason for this is that the ip address 192.168.49.1 is used mainly by devices for Wifi Direct. We saw that our Control Hub used 192.168.43.1 instead (using the ip route command on Linux, or ipconfig if you are on Windows). We aren't sure if the address 192.168.43.1 is the same for all Control Hubs, or if it is different per control hub. After finding this ip address, we connected via adb connect 192.168.43.1:5555. ADB worked as expected following that command.

### Next Steps

Overall, our testing was a success. We hope to perform further testing before we attend the REV test on Saturday. We would like to test using Webcams, OpenCV, libraries such as FtcDashboard, and more.

We will be posting a form where you can let us know about things you would like us to test. Stay tuned for that!

# Project Management Post-Mortem

Project Management Post-Mortem By Charlotte

### Task: Evaluate the Project Manager position

This year, I started the role of project manager, and there have certainly been plenty of growing pains. Iron Reign had previously learned to embrace chaos, frequently pulling all nighters and fumbling to finish each part of the robot in a timely manner. In this post, I will discuss all of the different aspects to being a project manager on Iron Reign so that we can continue to improve on our organization. The main focus will be the meeting logs, planning sessions, and the Gantt chart.

• Meeting Logs
• This year we have completely changed meeting logs. We changed the format to using bullet points rather than long-form, and the way they are told to using feature-benefit language. Feature-benefit describes the what (taking up 2/3rds of the description) followed by the why (taking up 1/3rd of the description). These descriptions are incredibly important to concisely portray our progression to the judges.
• Planning sessions
• In previous years, we have had trouble implementing these planning sessions effectively and we still have this difficulty. When there is no project manager present, they don't occur at all and must be supplemented with discussion in the Discord. They have been very helpful in constructing agendas in meeting logs, but next year we are going to push the need for these sessions even more. They make sure that every member has a task to accomplish during the meeting and help remove the pull of distractions. In mentoring the freshmen, hopefully these needs will be met.
• Gantt chart
• The Gantt chart has been the most difficult factor of project management to implement. The higher-level organizational mindset required is one difficult to acquire without any close mentorship. Our Gantt chart has seen many changes, especially earlier in the seasom, but dropped off nearing the end of the season due to other responsibilities. Next year, the most important improvement would be to involve other team members in the creation of the chart a lot more than this year. This would help the chart accomplish higher detail and accuracy as well as allow it to be helpful and references by not only the project manager, but the whole team. They will be implemented into the planning sessions

Next year, there are quite a few improvements to be seen in this role. This was the first year and going in with no previous experience and with the team not used to such a role has been a challenge. Hopefully, most of the mistakes to be made have already been made, and the project manager role in the team can be seen as important to the organization and overall well-being of the team. It requires intense dedication, confidence, and organization, which I have tried my hardest to provide this year, but I have faith that with the amazing abilities of our team, we will improve our organization and project management for years to come.

# Modelling a Points System

Modelling a Points System By Bhanaviya and Karina

### Task: Model a points system for the Skystone Challenge

A couple hours ago, Iron Reign attended the reveal for the 2019-2020 FTC game - SKYSTONE. Since we intend to build a robot within the frame of this weekend, a points system will allow us to identify what specific parts of the challenge we'd need to solve first. It will also serve as a calculating tool for when we begin drive-testing.

The points system identifies every aspect of the autonomous, tele-op, and endgame respectively. By plugging in values for each aspect, we will be able to see how many points we will score in total within the frame of one round. Essentially, it is a scoring system but will prove useful for when we start looking for build and code specifics on our robot. It will also allow us to more effectively document our drive-testing, something which we are notorious for neglecting in the past.

### Next Steps

Once we have a working prototype, we will begin using the points system during drive practice. Since our Robot in 2 Days bot won't by any means be our final design in the weeks leading up to out first qualifier, the points system will come in handy when planning out multiple robot designs. It will serve as an effective tool to help us prioritize our engineering decisions.

# Aaron’s Super Cool Gripper That Works 100% Of The Time

Aaron’s Super Cool Gripper That Works 100% Of The Time By Aaron

### Task: Prototyping a rolling gripper

During the 2 day robot challenge, one of the gripper designs that we built on the first day was Aaron’s Super Cool Gripper That Works 100% Of The Time. While it did work most of the time, it was a bit too bulky to be implemented effectively in the two day period we had.

The way it worked is by using the flexibility of the ninja flex rollers that we designed last year to slip over the stones, then because of the rubbery ninja flex material, griped on to the stone. Each roller was attached to a servo, allowing us to deposit the stone and rotate it into the orientation we desired.

### Next Steps

Although the design isn’t near ready to be implemented, it did experiment with the idea of being able to rotate the stone while depositing. Not only that, but it was hinged at the very center on two axis of rotation, allowing for auto stabilization.

# Wheel Gripper

Wheel Gripper By Jose and Trey

### Task: Design an intake for the stones based on wheels

Initial Design: Rolling Intake

The first idea we came up with for gripper designs during our Robot in 2 Days (Ri2D) challenge was a rolling intake with the wheels coming from the top and spinning to intake the stone. Since the wheels needed to spin they were placed on shafts which required two extrusions since the pillow bracket for them needs to be threaded on the ends of them to make this design compact.This design was rejected since we want to use the minimal amount of servos as possible and we came up with a more compact design that requires only one servo instead of two(one for each wheel).

Final Design: Gripper Wheels

This design involves two wheels attached to extrusions, one is idle and can't pivot while the other can be rotated in place by a servo. Once its grip was tested we saw that the wheels spinning was a problem. To fix this, the wheels where attached directly onto the extrusions this time and to enhance their grip, a rubber band was added to default the wheels' position as closed. A servo was added to the end of the main extrusion with a servo horn and polycarb beam to rotate the non-idle wheel back to release the stone in its grip. Finally, since drivers aren't perfect, a stabilizer made out of polycarb was placed in the middle of the gripper so it will always move towards the middle of the stones, in between the stubs. At first this was off by 90 degrees, but this was fixed shortly after.

### Next Steps

We will have to implement this onto the Ri2D bot and run tests to compare this gripper against our others.

# Rack and Pinion Gripper

Rack and Pinion Gripper By Cooper and Aaron

### Task: Build a gripper system for the 2019-2020 Skystone Challenge

The rack-and-pinion gripper system is one of the 4 gripper systems we built this weekend for our Robot in 2 Days project. Since we’ve never used a rack-and-pinion system before, we realized that it would be a creative idea to start off the new season. Going for simplicity, we made a box such that we could fit 2 racks going in opposite directions, having the pinion in the middle. We constructed the racks with standard rev rails attached to the box with a rev standard linear slide piece and attached tetrix rack gears on the opposite side with double sided tape. Then the pinon was a rev standard gear attached to a rail on the back. The plan was such that when the pinion was turned the two grippers will move outwards and inwards to grasp the stones.

After that, the actual grippers went through 2 iterations. The first was a straight, flat bladed polycarb sheet attached to the rack. We tried this, but it turned out that did not provide enough friction. The second iteration was a slight variation, where we bent the arms and added rubber foam to the end. This saw some success.

### Next Steps

Overall, the system was very solid and worked reliably, and could be used in conjunction with a gimbal to make a well performing arm, but that didn't save it. For our weekend build, the rack-and-pinion is too incompatible with our chassis to be implemented in time - but as FrankenDroid (our new robot!) is not the final iteration of our competition robot, the rack-and-pinion gripper system will act as a prototype for any changes we choose to make to our gripper system as the season progresses.

# Parallel Gripper

Parallel Gripper By Ben

### Task: Prototype a parallel gripper

While there are many different solutions and gripper designs, one of the most common is the parallel gripper. The purpose of a parallel gripper is to grip objects, in our case stones, parallel to the object instead of at an angle. Since this was a rational idea to start off with, this was one of the gripper designs we experimented with in the duration of our Robot in 2 Days challenge.

A parallel gripper would allow us to grip the stones more effectively, as it would grip with more surface area. Theoretically, these grippers work by having 4 bars/connectors which are all the same length. When they close, they close parallel.

After building the gripper, we tested it with the stones. While it did an okay job at gripping, due to the fact that we didn't use any gripping material, it slipped a few times. Another issue we encountered was that it would be difficult to flip a stone if needed, which is a task other designs could perform.

### Next Steps

If we decide to pursue the parallel gripper system, we would have to figure out a way to flip a stone so we could stack it, along with improving the grip.

# Robot in 2 Days Grippers Comparison

Robot in 2 Days Grippers Comparison By Jose and Bhanaviya

### Task: Analyze all our grippers from the Robot in 2 Days challenge

During the making of our Ri2D we prototyped and designed several gripper designs to collect stones. These designs varied in the method of manipulating the stone, how many servos they required and how compact they are. All of these gripper designs have their own post describing them in detail, but this article summarizes all of these grippers as a way to help us with future gripper designs.

### 1) Wheel Intake

This idea was though of but never built since the design was to have wheels at about ground level to spin and therefore intake the block, the problem being that this would disrupt the other blocks in the quarry since it intaked the block from its short side.

### 2) Wheel Gripper

This design was to use wheels as grip since they have good friction, one set of wheels is stationary and the other set can open and close via a servo. Not compact, but required only one servo and had great grip on the stone. This was ultimately the design we ended up using in our final Robot in 2 Days bot, Frankendroid,since it was efficient in maneuvering and controlling stones and served as a good design for a quick, 2 days old robot.

### 3) Aaron's Super Cool Gripper That Works 100% of The Time

This design used 3-D printed wheels made of ninja flex that spun to intake the block, like the wheel gripper just not in a set position and it grabbed stones from above. This design was huge and required two servos as well as not having much grip.

### 4) Rack and Pinion Gripper

This design involved a rack and pinion closing some polycarbonate sheets to grip the stone. The polycarb sheets had foam for grip, but this was still not enough to even lift the stone, so an actual motor would be required.

### 5) Parallel Gripper

This design was to use a parallel grabber with some material for grip as an alternative to the rack and pinion design. Unfortunately, the parallel grabber wasn’t built correctly thus not parallel.

### Next Steps

With all of our gripper designs from the Robot in 2 Days Challenge documented, we can now analyze how best we can improve these designs for future gripper iterations, as well as the potential of these designs to be combined to create an entirely new design. Currently, we are leaning towards using the gripper with Ninjaflex gears, which is the 3rd design in this article, once we've fine-tuned Frankendroid's design. We think a rolling intake will work well on our robot so this design is consistent with our idea to use the wheel gripper at present.

# P.A.U.L

P.A.U.L By Aaron

### Task: Design a new intake system

The Pivoting Accelerated User-friendly Locker

After the end of the two day robot build, we had come up with two main gripper designs. One was consistent, however heavy and large, (Wheel Gripper) and one was lighter but wasn’t quite as versatile or controllable (Aaron's Super Cool gripper That Worked 100% of the Time). P.A.U.L (Pivoting Accelerated User-friendly Locker) is the best of both worlds. It’s made out of polycarb so it’s light and somewhat flexible, and its easily controlled by a servo.

P.A.U.L was originally designed with a hole in the top where a servo could push a small polycarb rod straight down, pushing the stone out of the grasp of P.A.U.L. This might have worked, however we decided that it would most likely be more efficient and easily controllable if we switched to some sort of pivoting mechanism where one side of Paul could be controlled by a servo. The way that works is by fixing one side to an axle that is attached to a gear. That gear is then controlled by the servo on top of P.A.U.L.

### Next steps:

In the future we plan to test different gear ratios, that way we could figure out the perfect ratio of torque to speed. We want a good amount of torque that way we can grip the stones tightly and securely so they don’t fall out while being jostled around on the field, however in this years challenge speed is going to be very important.

### Task: Design a concept for a circular chassis

Concept of circular chassis

A challenge we face this year is running into other robots. Last year, it was possible to easily get around other robots; however, this year it will be difficult to get around other robots, as there will be a lot more cross traffic in the building zone.

Our solution to this is designing a circular chassis. This will allow us to brush other robots without getting caught. With this, we would be able to move quicker and accurately. We will construct a 17.5in circular chassis. It will be driven by 2 8-in wheels (ironton 8in. Solid Rubber Spoked Poly Wheel) with 2 sets of 4-60mm omni-directional wheels on the front and back of the robot for stabilization.

### Next Steps

Our next steps are to begin construction of the circular chassis, which has now been named TomBot, after our coach's cat - Tom the Cat. We will begin construction of TomBot by creating a circular template, which will be 17.5in in diameter. We will then trace that shape onto a polycarbonate sheet and cut it out.

# Auto Path 1

Auto Path 1 By Karina and Jose

### Task: Lay out our robot's path for autonomous

To kick off our autonomous programming, Iron Reign created our first version autonomous path plan. We begin, like all robots, in the the loading stone, its back to the field wall and with our intake arm upwards. We approach the line-up of stones and deploy the arm to its intake state over the last stone. At the same time, we have the wheels of the gripper rotating for a few seconds. The, we back up directly. Using IMU, our robot rotates 90 degrees, and then crosses underneath the skybridge to the building zone. About 1 foot past the end of the foundation closest to the bridges, we rotate again to the right and then deposit our stone. Afterwards, we retract the intake arm, back up, and then park underneath the skybridge.

### Next steps: Improving autonomous by testing

The autonomous we have now is very simple, but this is only our first version. There are multiple steps that can be taken to increase the amount of points we score during autonomous.

In testing, I've noticed that (depending on how successfully we initialize our robot) the stone we pick up during autonomous sometimes drags on the ground. This creates a resistive force that is not healthy of our intake arm, which is mounted on the robot by a singular axle. To fix this, we can add code to slightly raise the arm before we began moving.

Eventually, when multiple teams on an alliance have an autonomous program, our own path will need to account for possible collisions. It will be strategic to have multiple autonomous paths, where one retrieves stones and places them on the foundation, while the other robot positions itself to push/drag the foundation to the depot.

Also, our autonomous path is geared toward being precise, but going forward into the season, we will need to intake and place more stones if we want to be competitive. As well, we will need to use robot vision to identify the skystone, and transport that stone to the foundation, since this earns more points.

# Driving at the Hedrick Scrimmage

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

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.

# Updating TomBot's model

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.

# Stub Gripper

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.

# Gripper Iterations Summary

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.

# Logarithmic Spiral Design

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.

# Morph Chart

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.

# Night Before Competition Build

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

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

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.

# Build Post-Mortem

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

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

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.

# Swivel Mount

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

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.

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

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

# Bill of Materials

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.

# Short-term Post-Mortem Talks

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

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

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

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.

# Materials Test Planning

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

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

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

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.

# Last Coding Session of the Decade

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.

# Control Mapping v2

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

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.

# Modeling TomBot Articulations

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

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

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.

# Testing Two Drivers

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

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

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.

# Finger Gripper Morph Chart

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

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

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.

# Auto Developments at the STEM Expo

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.

# UME Prep Qualifier Cumulative Post-Mortem

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.

# Updated Bill of Materials

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.

# Friction Coefficient and Energy

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

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

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.

# Final Weekend Before Regionals - Meeting Log

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.

# Research Poster

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

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

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

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.

# Meeting Log Post Regionals

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

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

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.

# Modelling an Equation for Forward Speeds of a Ring

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.

# Proteus' model

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.

# Updating Proteus' model

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

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.

# Iterate Trajectory Calculations in Preparation for DPRG Meet

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

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.

# Correcting the Trajectory Calculations Equations

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

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

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

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

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.

# DPRG Virtual Meeting 2/9

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

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

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.

# Accounting For Initial Height

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

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

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

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

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

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

### Next Steps

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

# Adding Margins Of Error To Desmos

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.

# Morph Chart

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

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.