Last week at the FIRST Tech Challenge (FTC) Robotics World Championship in Houston, Team 6832, Iron Reign, from the School of Science and Engineering in Dallas ISD earned the Motivate award which ranks them at the top in the outreach category.

Each of the 5,200 active robotics teams this year is expected and encouraged to share their passion for robotics and all things Science, Technology, Engineering and Math (STEM) with younger students who haven't had the same opportunities. One hundred and twenty eight of these teams from around the world earned spots at this championship, including teams from the USA, Canada, Mexico, South America, the Middle East, the Pacific Rim and China. Iron Reign received this recognition for their work in creating, operating and sustaining the Mobile Tech eXPerience, an RV that they converted to a mobile STEM lab in order to support the work of Big Thought and the Dallas City of Learning Initiative.

On board the vehicle, students can learn to program one of sixteen sumo robots, design 3D objects and print them on one of the four 3D printers, learn to program in Scratch or create virtual worlds in Minecraft. The robotics team converted the vehicle and helped run the pilot program in summer 2016. This school year their goal has been to help Big Thought sustain the vehicle by continuing to support deployments, improve the curriculum and simply "make it loud." And now Big Thought is taking vehicle operations year-round. With this vehicle and accomplished instructors, Big Thought is bringing STEM exposure into under-served neighborhoods to help young students think of themselves as future engineers, scientists or technologists. This year alone the team has contributed 680 hours supporting 15 deployments of the vehicle to neighborhoods and large events. They've taught or spoken with over 3,400 students or parents at these events, and they've shared curriculum and the story of the vehicle nationwide by participating at the National Science Teachers Association STEM Expo.

This video will tell you more about the MXP from the perspective of the team members:

In the robot game the team finished 26 of 64 teams in their division, a good showing for a first-time Worlds team with a new young drive team. And Dr. Woodie Flowers, lead mentor of FIRST and Professor Emeritus at MIT signed and kissed our robot:

The team is fully appreciative of all of the support they've received this year. Special mention goes to Big Thought, Jeff Marx and Joe Schelanko of the Dallas ISD STEM Department, the SEM PTSA, the School of Science and Engineering staff and our advisor Calvin Boykin, Principal Andrew Palacios, Executive Director Tiffany Huitt and the tireless parents of all team members.

Please see the team website for more information. The team will be going to the UIL State Championship in Austin on May 18. Finally, here is our robot reveal:

Task: Speak to 200 prospective recruits about Iron Reign

Today, we attended the Science and Engineering Magnet's annual freshman orientation. All prospective students are required to attend.

Since more than half of our team are going to graduating next year, we're already thinking about the 2019-2020 season. We want to start members early so we can ensure an effective transfer of knowledge between our rising juniors and new teammates. The best way to learn is through hands-on experience that this coming season could give them. This means that the recruiting season starts here and now.

We drove it through the crowd and spoke to over 20 families about our work in FTC, the robot, competition, and more. There were many kids who were very interested in FTC. We answered much more specific questions with them, like what the time commitment is, why we chose specific parts, etc. It was great to see such enthusiasm for STEM at such a young age! At one point, they started giving us building suggestions like where to add support bars.

Overall, the event was a big success. We made lots of meaningful connections with incoming students and have some prospective members. We look forward to attending next year and maybe welcoming some new teammates.

You can watch a short video of the event here

Task: Build a Chassis

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.

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.

Task: Get Funding from Mark Cuban

At the World Championship this year, Dean Kamen, the founder of FIRST, talked about getting celebrity involvement in the robotics program. Very few celebrities support FIRST (will.i.am being the biggest) and will.i.am. sent a request through Kamen to all teams to reach out to close by celebrities to get them involved in FIRST. As I sat in the crowd at Minute Maid Park, Kamen's words stuck with me on my journey home. I thought about how cool it would be to have celebrities support Iron Reign. However, I had no idea who to contact.

Still on the quest, I sat down to watch TV one day. As I scrolled through the channels, I found Shark Tank (one of my favorite shows). Then it hit me: I wanted Mark Cuban, a Dallas native, to support Iron Reign.

Mark Cuban, investor on Shark Tank and the owner of the Dallas Mavericks, has been very important to Dallas. I decided to reach out to him to see if he would be willing to support us. I asked people at school if anyone knew Cuban or knew people who knew him. Luckily, my friend's father went to the same gym as him! Through my friend (Amanda), I reached out to Cuban. I drafted an email which would be sent through Amanda to Cuban.

Next Steps:

Now all I can do is wait for a reply!

Task: Reply to Cuban

After sending a small email to Cuban, he replied very soon asking for more details (shown above)! With this, I felt more confident I could make things happen. In my following email, I provided more details explaining the FTC program, from last year's challenge (Relic Recovery) to the work we have done for Dallas. I also asked to present to Cuban about the team since Iron Reign tends to get information across best through presentations.

Next Steps:

Once again, it's time to wait for a reply!

Task: Explain Iron Reign

Once again, we got a positive response from Cuban! Unfortunately, we couldn't meet in person but I was still pursuing the sponsor path. For the next message, I decided to get some other members of the team on the project. Since this was our one shot to convince him, I drafted a much longer sponsor email, inspired by older emails to our sponsors. In this email, we provided specifics into what we can do with Cuban's support. With a monetary donation, we will either spend money on robot parts or save it to act as a seed donation for kick-starting a non-profit organization for Iron Reign. Since we are somewhat limited in our monetary abilities due to DISD "red tape", we wanted to develop this organization to better fund our team for years to come. Explaining all these details, our email came to a close. However, I still wanted for Cuban to "meet" the members of the team. From this stance, I decided that making a video from our team members would do the job. After some quick script writing, we developed the video shown below!

Next Steps:

Again, we wait for a reply!

In this post, I would like to thank Mr. Cuban for supporting Iron Reign. Today, we received a message from Mark Cuban's assistant stating that he would be contributing $2500 to Iron Reign. There is no end to how much this helps our team for the following season.

FIRST is an organization dedicated to promoting young minds in STEM. However, to participate in the program (specifically the Tech Challenge), many materials are needed. A successful team often needs funding to sustain itself for years to come. Mr. Cuban has allowed Iron Reign to actualize this through his support. With his help, we hope to continue to influence young children through our outreach and build better robots. Hopefully, we can return to the World Championship and bring Mr. Cuban to the greatness of FIRST.

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.

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.

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

Task: Present at the Dallas Love Field for the DCOL Turn Up! Event

Every year, the Frontiers of Flight Museum hosts Turn Up!, an event where kids can learn about science and math. Once again, we brought the MXP equipped with 3D printers, Lego sumobots, and our world class FTC robot, Kraken. We ran the sumobots on a table outside of the MXP and 3D printing inside. We also demoed Kraken and Argos, which were great attention grabbers to get kids interested in the MXP. The kids enjoyed programming the Lego sumobots and battling them against each other, as well as creating their very own customized 3D printed key chain. The 3D printers were very busy this year so we had to create extra space outside of the MXP for more laptops with the 3D printing software.

We drove Kraken around the exhibition room and talked to many interested parents about the joy of robotics. While we talked to the parents, someone driving the robot would showcase the capabilities of Kraken by bringing kids glyphs and shaking hands with the relic arm. Kraken was great for showing families what FTC is about. We also had Argos for display but the steering was broken so we didn't drive it. Around 1100 people turned up to the event and we talked to most of them about what we do here at Iron Reign. Turn Up was a great opportunity to introduce kids to the world of STEM and robotics and we hope to have more opportunities like this in the future.

Task: Discuss Iron Reign's Awards Strategy for the Upcoming Season

FTC is undergoing a series of changes next year that will most likely negatively impact Iron Reign's ability to advance to further levels. Given that there are about 5,400 teams in FTC for the 2017-2018 season and 256 teams advance to worlds, 4.7% of teams advanced to worlds this year. Next year however, the amount of teams will increase, but the amount of domestic teams advancing to worlds will stay the same. Effectively, the percentage of teams advancing to Worlds will decrease, so that some regions may lose advancement spots.

The best plan to advance is still a dual focus on awards and game. So, we need to up our game. Talking about our RV, while still impressive, has lost its luster with Dallas-area judges. We're still using the RV, and doing our normal outreach, but we plan to aggressively pursue business and engineering contacts. We've already received around $5,000 from individual donors, and received a separate $2,500 grant from Mark Cuban. In addition, members of our team are working at companies such as Verizon, ESi, Abbott, Parkland, and more; all the while gaining contacts in those industries.

We have our work cut out for us, this year will be additionally challenging, losing one of our coders and one builder. We're training people in the skillsets that we're losing out over the summer, and we're also seeking FRC teams to mentor (we want to flip the traditional dichotomy of FRC teams training FTC teams on its head). We really want to get to Worlds this year - its the last year that any of the original members are on the team, and we want to go out with a bang.

Next Steps

• Seek further business and engineering connections
• Extend assistance for FIRST outreach
• Continue team training
• Continue RV outreach
• Seek continued grants from TWC and other TX sponsors

Task: Refurbish an Apple II CNC Mill and Lathe Set

We were helping our school's FRC team clean out their parts closet, which hadn't been cleaned in 10-ish years. Under the layers and layers of FRC junk, we found an Apple II-operated Patterson/Paxton CNC Milling Set. These were meant to run off of a long-since-gone Apple II in a classroom setting. But, it had long been auctioned off, leaving the set useless. But, Iron Reign, as a collective of hoarders, decided to bring these machines over to the house to refurbish.

The first idea we looked at was emulating the Apple II with an Arduino, as seen here. However, this implementation didn't have the response rate needed for an accurate CNC machine, so we scrapped it. Then, we found this post. The problem that people mainly encounter is that, for some strange reason, Paxton\Patterson used a proprietary parallel port pinout, and deviating from that pinout (read: using a standard parallel cord) would fry the optidriver board in the machine. So, we bought a ethernet-to-parallel port jumper box (UC300eth).

We then sliced a parallel cable in half, and rewired the wires to the pins, treating the left column of that of the port numbers on the board and the right as the pin numbers of the cables.

We then made a power supply for the UC300eth. We attempted to use a 10V DC power supply, and use a voltage splitter. Unfortunately, the power spiked, and probably fried the UC300.

Next Steps

We need to buy a new UC300 board and hook it up to a laptop with Mach3 to test the power.

Task: Recruit members for the upcoming robotics season

At the end of last season, we had two members graduate, Austin and Tycho. Their upcoming "goodbye" posts will be posted here, the same as last year. So, we wanted to recruit at least one member to replace them. Recruitment methods that we had used in the past, such as posters and Townview recruitment seminars, had failed to gain any meaningful recruitment. So, we fell back on our secondary, having individual team members submit possible recruits, as well as recruiting from our JV team. This year, we already have Justin. Last year, we had Kenna and Abhi as a submitted recruit. The year before, we had Janavi and Austin.

These prospective recruits are required to fill out a Google Form on our website, titled signup. We had this post stickied for the better part of last year. Of all the people who were asked to fill out this form, we had three people respond, with a fourth potential recruit being the younger sibling of our leaving members. Our current step is vetting the current recruits - we have two interested in coding, one in building, and one no-show. We're giving the recruits tasks to weed them out, the ones that are less experienced will be shunted back into our JV team.

Next Steps

We will recruit 1-3 members out of these recruits and teach them the other aspects that they don't have experience in: writing, code, tools, etc.

Task: Present at the J. Erik Jonsson Public Library

This Saturday, we drove down to the J. Erik Jonsson library to present at the Dallas City of Learning Discovery Fair. We brought our sumo-bot equipment to the library, as well as a few of our new and old bots, such as cartbot (a mobile air cannon), bigwheel (a new testing robot), and Kraken (our Worlds robot).

We presented for about 4 hours, talking to about 190 kids. We had multiple parents interested in starting FLL teams, and many other children entertained by our new mobile cannon.

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.

Task: Reach out to the community and spread the magic of robotics

Iron Reign had a great time today at the Frontiers of Flight Museum for the 2018 Moon Day. We demoed three of our robots today: Argos, Kraken, and Big Boi. Kids were very interested in watching our robots drive. Big Boi was a fan-favorite because of its speed and the attached can launcher. Kids were also given the opportunity to drive Argos around. We were also able to interest kids in FTC when we explained Kraken, our robot from the previous season and demonstrated how it could pick up glyphs. In total, we spoke to approximately 200 individuals.

Besides driving our finished robots, we made progress on Garchomp, another robot with mecanum drive serving as a replica for Kraken. We explained our design to people and why we like the mecanum drive so much. Many parents were interested in getting their children involved in a robotics team because they could see the build process at its middle stages in Garchomp and as well as the finished product in Kraken.

Next Steps

Here at Iron Reign, we value the community's interest in robotics. We will continue to make ourselves and our robots accessible to the community at future outreach event, and we will also encourage kids to get involved in STEM.

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

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.

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.

Task: Present about STEM to new freshmen at SEM

Today Iron Reign presented at the New Student Orientation (NEST) camp at our school, SEM. All incoming freshman were there. We had two sessions, one with 3D modeling, and another with sumo-bots. We also drove around two of our robots from last year, Kraken and Argos. We gave the freshmen chances to drive around these robots. Most of the students were very interested in our presentation, and a few even signed up to join Iron Reign because of it. We spoke with around 160 students.

Next Steps

Here at Iron Reign, we value the community's interest in robotics, especially the students at our school. We will continue to make ourselves and our robots accessible to the community at future outreach events, and we will also encourage kids to get involved in STEM. We hope to recruit many of the students who were interested in robotics from our meeting.

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.

Task: Receive a grant from Best Buy for continued MXP operation

Last year, we received a $10,000 award to continue our RV operations, cover staffing costs, and pay for additional technology\repairs. This year, we received another grant of $10,000 for the same reason. This is another stepping stone in keeping Iron Reign and BigThought's MXP program sustainable for another year. In addition, any donation amount encourages more donations in a kind-of snowball effect.

Next Steps

We will continue to seek out grants for not only the MXP, but also so that our team can remain sustainable for years to come.

Task: Present at the Dallas Back to School Fair at O.W. Holmes

Today we brought the MXP over to O.W. Holmes Academy in South Oak Cliff for our usual presentation. We spoke to about 130 children, doing our usual sumobots and 3D printing sessions.

Next Steps

We have a few more outreach events before our season goes into full swing, so we need to get in touch with as many people as possible.

Task: Build the Chassis

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

Next Steps

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

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.

Hopefully, you're here because you heard our announcement or saw our flyers. Even if not, welcome! We are team 6832 Iron Reign Robotics. We've been a FIRST team since 2010 and currently compete in FIRST Tech Challenge. Some have been on the team for a few months, others over half their lives. We design, build, and code robots, but we also spend a lot of our time on the MXP. We won the Motivate Award at the World Championships for the creation and sustainment of the MXP. On our team you will learn practical skills, like how to solder programming wires, and soft skills, like how to present to a panel of judges.

If you are interested, please fill out our form for potential members. We are also having an interest meeting at Townview Magnet Center on August 30th in room 363. Feel free to explore our blog or learn more about us.

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.

Task: Discuss potential support from MIT

In a previous post, I mentioned how the knowledge I gained in machine learning at MIT could help the team. But another way our team could be helped is with mentor involvement from MIT. I couldn't have done the research I did at MIT without the help of my amazing instructors. I wanted to bring them on board the Iron Reign way so they could also teach the rest of the team how to be awesome and help us grow. Currently, Iron Reign is speaking with two of my instructors.

Lyle Lalunio (leftmost in image) is a freshman at the University of California at Berkley. He was an intern this past summer at MIT as part of the Laboratory of Computational Physiology and also the Medlytics program. He is proficient in numerous programming languages including Java and Python. He is pursuing computer science in college but is also interested in the medical applications of the science. Lyle has been an incredible mentor for myself and my teams during my month, inspiring me to invite him to the team.

Dr. Danelle Shah (2nd from left in image) is a Technical Staff member in Lincoln Laboratory’s Intelligence and Decision Technologies group. Her most recent research has focused on the detection, representation and characterization of human networks by leveraging natural language processing and graph analytics. Dr. Shah earned her Ph.D. in Mechanical Engineering from Cornell University, where she developed algorithms to facilitate natural and robust human-robot interaction. Dr. Shah has also left a great impact on my life and has a background in robotic algorithms, inspiring me to invite her to the team.

Next Steps

Continue discussion with mentors about potentially joining Iron Reign.

Iron Reign Clutter

One of Iron Reign's greatest weaknesses is the organization of our physical space. It is rare that our workspace is free of clutter, and it is always difficult to find tools or parts that we need. We often joke that when we put an item down it goes in a "black hole," and you won't be able to find it again. This summer, however, we have made a system to tackle this problem and this season we hope to maintain it. We cleared out the front room and set up some shelves and got to organizing. For anyone looking for certain tools or who doesn't know where to put a tool they just found or used, use the article for reference.

This is subject to change, but as we begin the season, here is the current shelf organization:

In the tall black set of drawers, you can find these tools and parts:

In the silver drawers on the right side, you can find these tools and parts:

In the colorful drawers on the left, you can find these tools and parts:

We have a long way to go, and we need to put organize these drawers even more and maybe soon label them. If anyone has any questions ask Evan or me (or Tycho if he's home), and make sure you put things back after you use them!

Task: Recruit new members for the 2018-19 season

Last year, Iron Reign lost two members, so we're only looking for 2-3 members to replace them and their particular skillsets. However, our sister team, Imperial Robotics (3734) lost nine members. So, we decided to host a recruitment session at our school to find interested freshmen.

We put up posters around the school, and got a healthy crowd - 30 people. We talked about Iron Reign's history, needed levels of commitment for various teams, and what the average person will do on the team. We also answered questions about the team from the crowd. Of those people who attended, 17 signed up for a testing session next week, including two former members of Iron Reign, Alisa and Trace.

Next Steps

We will hold training sessions to assess each potential members skills, then divy them up with Imperial Robotics.

Task: Present about Garchomp

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.

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

Task: Present about Worlds to new teams

This was our last presentation in a series of presentations in conjunction with teams from around Texas for new and returning teams in the North Texas region. This particular presentation was about strategies in awards and the game, as well as general thoughts about FTC and Worlds.

Presentation

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

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.

Task: Attend the North Texas FTC Kickoff

Today, we went to the Rover Ruckus kickoff! This year's main challenge is getting blocks (gold) and balls (silver) into the main lander. The other side challenges, in order of hardness, are hanging, parking, and placing the team marker. The main upside of all of this means that it is theoretically possible to perform every single function on the field with the same mechanism.

The main non-robot game changes are the elimination of Supers, the standardization of awards, and Worlds spot changes. The one that particularly piqued our interest was the award standardization. Historically, there have been huge disparities between the awards in North Texas and the awards at Worlds. For example, in North Texas, we continually won the Connect Award for our outreach (while in the rubric, it was the award for connecting with engineers). But, at Worlds, we won the Motivate Award instead.

Next Steps

We will do a brainstorming session to figure out are design paths for the next few weeks. In addition, we need to complete sorting of the new members.

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.

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.

Task: Determine the best Rover Ruckus strategies

Task: Analyze the game

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

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.

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 September 15, 2018

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

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.

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.

Task: Brainstorm chassis designs

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.

Proposed Additions

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 September 22, 2018

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

Task: Map Autonomous paths

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.

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 September 28, 2018

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

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.

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.

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.

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.

Task: Detail the grant awards that Iron Reign and its associated teams received ($11k)

So, Iron Reign is currently training an influx of new members - so much that we've started two new teams: Iron Star Robotics and Iron Core. Of course, with this programmatic growth comes plenty of growing pains. A major part of that is finding funding for new teams. In that regard, Iron Reign applied for grants for itself as well as for its other 3 feeder teams. Namely, we applied for the TWC grant(s) and the FIRST in Texas Rookie Grant (sponsored by DEKA) for the new teams.

Today we reaped our results: we received $525 in funding for Iron Reign and Imperial and $1,525 for Iron Star and Iron Core from the Texas Workforce Commission, as well as $1,000 for Iron Star and Iron Core from DEKA. In addition, we've currently received $4,000 from the DISD STEM Department and $2,500 from Mark Cuban, for a cumulative total of $11,400 raised this season.

Next Steps

Even though this is a hefty amount of money - one of the largest hauls made by Iron Reign - it still isn't satisfactory. We now have two more teams, increasing Iron Reign's expenses and stretching simple resources such as 8mm M3s thin. So, we will always be seeking more funding.

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.

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.

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

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.

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 October 06, 2018

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

Task: Upgrade our code to the latest version of the FTC SDK

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.

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.

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.

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.

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 October 13, 2018

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

Today's Member Work Log

Task: Plan for 30+ influx of team members

So, as we've stated in prior posts, this year has been a successful year for recruitment. We have had 30 total signups, up from -5 last year. This wave of new recruits means that the Iron Reign family must grow. So, in addition to Iron Reign and Imperial Robotics, we are introducing TWO new teams to North Texas and the Iron Reign family.

To accommodate this influx, we are changing the organizational structure of SEM Robotics a tad. Iron Reign will remain the varsity team, and as such, will be responsible for tutoring and assisting the other teams, as well as other organizational decisions. Then, Imperial will now be the JV team, and be the intermediate training ground. You can see their efforts over at https://imperialrobotics.github.io/. Finally, we have the two new additions: Iron Star Robotics and Iron Core. Iron Star Robotics is a self-formed, co-op team of motivated freshmen; the other is a more lax training team.

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

Next Steps

We will tutor the new teams and identify the promising recruits. For ongoing tournaments and eliminations, we will recompose new teams of the most promising members.

Task: Prepare for and set up SEM STEM Spark

The National Honor Society at our home school, the Science and Engineering Magnet, has been working hard to prepare for the upcoming SEM STEM Spark event for middle school girls in North Dallas that they have been planning for since last May. A few of our very own members are members and leadership in NHS and have been working to include our robotics outreach as a featured activity as well as working with other activities we are passionate about, such as chemistry and environmental science.

In the past few weeks, we have confirmed a spot for our outreach in the event and have been trying to recruit middle schools girls to attend the event. A few members even visited the middle schools they attended and spoke to their old science teachers to share information about the event and hand out fliers. Due to some complications, we weren't able to get registration for the event up until a week before, so recruitment has been a struggle and is very time sensitive. Our numbers are increasing quickly though, so we have hope that the event is going to be a success.

The event is tomorrow, and today we spent a few hours setting up. On our day off, we went to our school and organized all of the materials we collected as donations along with those we bought with our own funds. We ran through each activity to ensure that they would fit in the allotted time frames. Everything seems to be running smoothly and we are ready for the event tomorrow. Fingers crossed! :)

Next Steps

We are very excited to run this event and have learned a lot from the work we have put into organizing it.

Task: Volunteer at SEM STEM Spark, a girls-in-STEM event

For the past year, members of Iron Reign have been planning this event and getting approval. For those not-in-the-know, this event is a women-only STEM event with a guest panel and four different stations: environmental science, chemistry, engineering, and robotics. Iron Reign members had a hand in planning and assisting with 3/4 of these, as well as general logistics. However, most of this is detailed in prior posts - this post is for the actual event.

Today, we talked to 140 girls in groups of 12-18, allowing us to be able to focus more intensely in our sessions and get more done. We taught them the 3D-printing program and sumobots. Finally, we had a member present as a panel member as a woman in STEM.

Next Steps

This event was a great success, and we plan to do more like these in the future. At the moment, we have a date set in March for a second event with entirely new activities.

Task: Present about Iron Reign to 120 prospective members

Today, we went to the Travis H.S. Night to talk to prospective freshmen about our robotics team. The format of the night was this: four twenty-five minute periods, with twenty minutes about SEM and five minutes about robotics. To fit this time schedule, we condensed our usual recruitment presentation down to five minutes while also demoing our former Worlds robot, Kraken. We mainly talked about the main points of FTC: being well rounded, the emphasis on writing, business, and the like. Then, we answered questions from the audience for the rest of the time. Overall, we presented to about 120 parents and students.

Next Steps

We plan to hold more presentations and outreach events in the future. We've already stepped our recruitment game up, so events like these are crucial.

Task:

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.

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.

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.

Task: Plan for major grant to fund replacement of MXP ($150k)

First, for a brief backstory: Iron Reign built the MXP - or Mobile Learning Lab - two seasons ago so that we could do outreach to underserved areas within our community. To do this, we partnered with BigThought, who received grants for laptops and technology aboard the vehicle. We spent that entire summer renovating an old 90's RV so that it could become the Mobile Learning Lab. Then, last season, we presented at the National Science Teachers' Association in Kississimee, Florida, where we talked to educators in five other cities to start their own similar programs.

Now, let's return to the present season. As of today, BigThought is receiving $150k in funding to create a second Mobile Learning Lab. This funding is all-inclusive: the RV and technology aboard. As far as we know, this is the single largest fundraising haul any FTC team has ever received. Now, let me be clear, this is not funding to team costs such as registration and parts, but rather a larger-scale programmatic fund to continue and increase Iron Reign's outreach frequency. Luckily for us, we've secured a lot of funding this season already through Mark Cuban, individual donors, and FIRST in Texas grants.

Now, here comes the less-so-good news. Even though $150k is a monumental sum of money, it still falls short of the cost of a new MXP, by about $100k. However, the guarantee of over half of the necessary funding makes it much more likely that the additional funds will be secured to purchase the brand-new vehicle.

Next Steps

So the next steps are obviously to work with BigThought to find the additional $100k, but this is still huge - we may have broken a fundraising record. And besides that, this is what Iron Reign has always worked for: the platonic ideal of outreach. We have the ability to expand our program, make it more comprehensive, and make it sustainable on it's own merit.

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.

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 October 20, 2018

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

Today's Member Work Log

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.

Sunday Tasks

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

Monday Tasks

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

Tuesday Tasks

• 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.
• Added scoring box
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.
• Added intake bar
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.

Before

After

Next Steps

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

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.

Presenting to Leadership Dallas Class of 2019

Today, we presented to the Leadership Dallas program, run by the Dallas Chamber of Commerce, to fundraise for Iron Reign and BigThought's Mobile Learning Lab program to cover the remaining $100k gap as well as our school programs.

There were 2 groups of about 10 people who learned about Iron Reign & FTC and toured SEM (Science Engineering Magnet) & its classes. There were employees from Big Thought, Uber, Turner Construction, Ernst & Young, and Channel 8 News. We'd especially like to name Stephanie from Channel 8 and Ryan Dyer for helping us get a website visit from Antartica. We'd been working on having a visit from all 7 continents for all of last year, and it finally came true!

After that, they got a tour of a deployment-ready MXP, full of laptops, 3D printers, EV3's, and teaching monitors. They were very interested in our SEM education and how it ties into what we are able to do as a part of Iron Reign and FTC. We discussed using our physics experience to conduct experiments for the materials we use on our robot, and SEM's freshmen Java class to do IMU coding.

We all loved how enthusiastic they were about improving Dallas and learning more about robotics in a high school education. It was a huge opportunity for us to spread STEM and FIRST to the Dallas community, and we hope to do so again in the future.

Next Steps

We were lucky enough to talk to Leandre Johns of Uber about what the opportunities they could offer our team and our community in helping underserved communities learn about STEM.

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.

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 November 03, 2018

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

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!

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.

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.

Next Steps

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.

Task: Get BigWheel ready for the tournament

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.

Our deepest thanks to all volunteers!

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

Calling All Volunteers

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

Our deepest thanks to all volunteers!

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

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

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

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

How to sign up as a volunteer

FIRST is the governing body of these competitions and they have a volunteer sign up system so that we can assure that all roles are filled by vetted volunteers. We are trying to get all volunteers processed through this system. It does involve creating a FIRST account if you have not previously done so. If you have any issues or are finding the process burdensome, please use our contact form for assistance.

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

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

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

All our Thanks,

Karim Virani and Cathy Lux

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

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

We plan to end the tournament by 5pm, but events can run long. All volunteers are encouraged to stay until the end of the tournament, but it's not required if your role is completed earlier in the day.

Task: Compete at the N. TX Conrad Qualifier

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.

This weekend, SEM sent four teams to the first qualifying tournament of the FTC Robotics Rover Ruckus 2018-2019 season. Iron Reign won the top award (Inspire) and advanced. For reference, Iron Reign is last year's FTC World Championship Motivate Award winner and is the "varsity" team of the SEM Robotics organization.

Imperial Robotics was a finalist for the Think Award due to the excellence of their engineering journal.

Our two new rookie teams beat back tough odds from a field of seasoned teams. Iron Star became the 4th alliance captain in the playoff rounds.

Iron Core was publicly invited to join the 3rd alliance in the playoffs, but graciously declined because they had a new fault in their robot and didn't want to drag the alliance down just to get into the playoffs. This was a highly laudable moment at the tournament and demonstrates the highest level of sportsmanship. FTC is about so much more than the robot, and no team emphasized that more then Iron Core.

Task: Analyze code failure at Conrad Qualifier

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.

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.

Task: Analyze what went wrong at Conrad

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 November 17, 2018

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

Task: Mentor a middle school team at the RMS Qualifier

Earlier today, I attended the Rice Middle School Qualifier in order to mentor my middle school team, SchimRobots, as an alumnus. Last year, when I was a member of SchimRobots, we had qualified to regionals by attaining 3rd Place Inspire Award in a qualifier. Since the Inspire Award had a heavy focus on a team’s engineering notebook, I decided to help out by looking through their journal. The way 12900 operates is through units; there is a unit specifically dedicated to the engineering notebook, and the members in that unit are the ones who work on the notebook. However, as I’ve learned thus far, because different members are equipped with different skill sets, it is more effective for each member to record their personal experiences within the team, rather than for a smaller group to carry the entire load.

SchimRobots Team Overview

That was the first takeaway that I decided to pass on. The second was that all ideas, regardless of potential, must be recorded. The purpose of the journal is to document all ideas, despite their success rate. This documentation showcases how iterative a team’s thinking can be when attempting to solve a problem. Because an iterative process helps portray a team’s “journey” in overcoming a challenge, dedicating a portion of an entry to any idea a team considered implementing is an effective strategy in making one’s journal as thorough as possible.

At the end of the day, we discussed the possibility of another meet-up, this one with more experienced members of Iron Reign to mentor the middle-school team, prior to their second qualifier.

Next Steps

The next step is to consider, with the rest of Iron Reign, the feasibility of organizing another mentoring session, taking into account where and how much help SchimRobots needs, and where and how much Iron Reign can offer.

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.

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

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.

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

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.

Task: Set up an outline as to how the DPRG Presentation will operate

Next Saturday, December 8th, Iron Reign will be giving its judging presentation to members from the Dallas Personal Robotics Group. Our primary purpose from this visit is to gain feedback from engineers in the community on our presentation. The presentation is anticipated to go beyond 15 minutes, so that we can introduce our potential ideas for the near-future, and so that DPRG can ask us more technical questions, that may not have arose from our presentation. Here's our anticipated agenda:

Next Steps

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 December 01, 2018

Today's Meet Objectives

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
• Model updates
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

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.

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.

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.

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.

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.

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

We reached out to the Dallas Personal Robotics Group to present - we've presented to them in the past about gyros - this was actually our biggest numerical outreach of the season back in the day. This year, we wanted to present again on computer vision, as this is something that they were very interested in, but we also wanted to give our actual presentation as practice for our next tournament. However, after we reached out to them, other Dallas-area groups joined in, such as Computer Visionaries. So, our presentation was advertised all over Dallas Meetup groups, but the main one was here.

The initial agenda is hosted on our website, but a quick summary is: a rundown of Worlds, our usual presentation, and our vision presentation. Our presentation went well - it was our usual tournament one for judges - we just took more time for the presentation, went on diatribes, told stories, and the like, and generally made it more entertaining. We answered questions on everything: code, building, outreach, and more. We're going to upload the video here soon. We also asked for feedback from the listeners.

The main feedback we received for the presentation was to make our awards points more clear. For vision, we were told that we should take a look at Google's foray into computer vision.

Then, we moved on to the vision presentation, the reason why everyone was there. Again, we'll upload a video of the presentation, and attach the presentation slides below. But, a quick summary of the presentation is that we covered OpenCV and VuForia first, then moved on to TensorFlow and CNN. This is where everyone became really became interested and asked questions. We also got a lot of advice, mainly on training the neural network. The presentation is here.

Task: Present to the Dallas Personal Robotics Group about computer vision

We presented to the DPRG about our computer vision, touching on subjects including OpenCV, Vuforia, TensorFlow, and training our own Convolutional Neural Network. Everyone we presented to was very interested in our work, and they asked us many questions. We also received quite a few suggestions on ways we could improve the performance of our vision solutions. The presentation can be seen below.

Next Steps

We plan to research what they suggested, such as retraining our neural networks and reusing our old training images.

Task: Help teams at the Townview Tournament

On Saturday, December 15, Iron Reign hosted 30 teams at the Townview Qualifier tournament. As a part of hosting the tournament, we wanted to ensure that all teams were able to compete at the best of their ability. As such, we made sure that we helped teams who needed our assistance.

One such team was PiGuardians, team 14787. They had no code (except for the example teleop), and their programmer was unable to make the tournament due to a conflict. Without our help, they would not have been able to do anything more than be a pushbot. Iron Reign wanted to make sure that they were not excluded, so we assigned a programmer to help them out.

We helped them write a teleop program so that they could participate in matches. We also helped them write an autonomous, using the replay program we designed over the summer to make developing an autonomous easier. With our help, they went from being a pushbot to having a full-blown autonomous.

PiGuardians was extremely grateful for our help to them. They promised to reach out to us if they ever needed any help in the future.

Task: Run the Townview Tournament

On Saturday, December 15, Iron Reign hosted 30 teams at the Townview Magnet Center, our home school's campus. This entry serves more as a description as to how we got to the point of hosting the qualifier and what to consider when hosting one.

First, for a tournament, you need a lot of volunteers of varied ages. Frankly, you need a good amount of younger kids for jobs such as queuing and judge assistance - this makes the tournament run much more smoothly. We had about 10 queuers throughout the day, and while this may seem excessive, we started out the day with a +10 minute surplus and kept every single match on schedule.

There still needs to be adult volunteers. We had 2 judges per room with five rooms, as well as 6 referees. All of these must be adults. And, we had to recruit from a diverse set of groups to cover our bases - we recruited people from the Dallas Chamber of Commerce meeting, the Dallas Personal Robotics Group, prior FTC tournaments, alumni, teachers from our school, and even our own families. It's hard to get enough judges for a large tournament, so this process had to start early.

The second item that we'd like to emphasize is the need to make everything accessible by teams. Being an FTC team ourselves, we wanted to make this tournament easier for others. So, we kept a spreadsheet with inspection results on a screen in the pits so that teams could be updated, made pit maps so teams could find one another, and built a practice field a decent distance away from the others for practice. In this, we hoped to take some stress off of teams.

On the same topic of helping teams, we had volunteers assigned to help fix robots and to assist with code, as well as putting the Mobile Learning Lab in workshop mode for teams who needed it. Iron Reign has been stuck in bad situations countless times, and we wanted to return the favor to those who helped us.

Finally, we'd like to thank all of our volunteers for being there. It was a hard, long day, but it was worth it, and we'd just like to extend our gratitude. We'd like to thank DISD STEM for providing food for volunteers and Townview Magnet Center for letting us host the qualifier here. Finally, we'd like to give a huge shout-out to our coach, Karim Virani, for doing the logistics of this tournament.

Next Steps

We're going to write up a few other posts about interacting with judges, supporting teams, and a postmortem on the tournament. We've got a lot to do over the break, and this was just the kickoff for it.

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

Intake Mechanism Material / Shape

Task: Visit REV headquarters and learn more about the engineering process

Today, a group of Iron Reign, Core, and Star members ventured down to the REV headquarters in Dallas. REV is a Dallas-based FTC+FRC parts company that produces their items at an accessible cost for all teams. All the SEM Robotics teams use REV, their parts are easy to use while still giving the ability to create technically impressive mechanisms. So, we were elated when we had the opportunity to visit them.

We started out with a tour, seeing the workshop in which they host their FRC teams - with RoboGreg inviting some of our members to apply to the new FRC team. Then, we saw the rest of the warehouse. Stretching infinitely towards the ceiling were rows and rows of REV parts in every variety imaginable with a center island of organized bins of parts. The last thing we were able to see on the first floor was the recording studio that REV's working on so that they can record tutorial videos.

We can't talk about everything we saw on the second floor, as some of it may not actually be released yet, but we can tell you of the Wonderland-like nature of it. As we walked in, we were met by a room dedicated to testing electronics. Iron Reign is accustomed to soldering on the floor or a hastily improvised bench or whatever clear space there is on the kitchen table, so this alone was enough for us to long to use it. And then, we were met by the 3D-printing room. You see, REV has two normal nylon printers that Iron Reign has plenty of experience with - been there, done that - but they also had a resin printer. We've never had the luck to see a resin printer in real life, only in far away youtube videos and whispers of whispers. In this alone, we were extremely jealous. Finally, we got to meet the engineers and have a general discussion with RoboGreg and David.

First, we got to learn about REV's design process. First, we learned about their revision process. They begin with a general idea, a goal that they want to achieve. Then, they create a small prototype with the tools they have at their home base if they can - after all, they have a reflow over, laser cutter, resin printers, and more we probably didn't get to see. From there, they send out their design for a small batch from a given manufacturer, just enough for testing. From there, they identify faults, fix them, and send for the next iteration, and so on. They end up with a finished product that, at the very least, has no physical/hardware faults; this is important as their philosophy is to give affordable parts to academic programs, and if they release faulty parts, they harm their customers. We learned a lot about the importance of a central design philosophy - something Iron Reign lacks. REV's is twofold: to make their parts affordable for those who normally wouldn't have access and to make their parts accessible for teams of all skill levels.

Finally, we got to the part in which we presented to RoboGreg and the rest of the engineers. Last year for Kraken, we designed a system called REVolution, which, when printed, allowed any team to turn REV extrusions into shafts. We felt that it made robots easier to build, so we presented it and asked for feedback. They were impressed by Kraken and liked the way in which it was implemented. Then, we learned some things about high-level design. First, an idea doesn't mean anything as long as it's just that, an idea. What differentiates those who do from those who don't is their vision and process to realize their ideas. In REVolution, we had done this. But, then we learned about a little system called Cost-Benefit analysis. As macroeconomics states, if a person chooses to make one choice, they inherently lose out on another, even if it isn't realized. In our case, it was this: if REV chose to produce the REVolution system, naturally, there would be other products that go neglected. And, one has to consider how a new parts system fits with the other parts; if REvolution were made real, one would have to create a whole extra parts library while still maintaining other similar rotation systems, increasing the work. It's not that REVolution is a bad system, its just that it could present too much of a tradeoff. In RoboGreg's words, this is "reality-based creativity."

We also asked some questions about things that Iron Reign wants to use; for example, where we could get access to a metal-3D-printer. We were informed that a local company down the road from REV, MLC CAD, was likely to provide this service for Iron Reign if requested. We asked for criticism of the REVolution system, learning that under normal operating speeds and temperatures, that nylon has the tendency to fuse with itself and that if possible, we should switch to a material such as Amphora.

We also presented BigWheel, this year's robot. We had some difficulties setting it up, but overall, they were impressed. The one point that we heard was that, when extended, BigWheel has a very high center of gravity, making it prone to tipping. We've considered it in the past, but really noticed it when it nearly hit someone rising up.

Next Steps

We learned so much here, and we'd like to give a huge thanks to RoboGreg and REV for giving us a tour. We want to implement the changes to our engineering process that we learned, and we're going to fix up BigWheel to solve its current in-presentation issues.

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.

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.

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.

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 December 22, 2018

Today's Meet Objectives

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

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

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.

Task: Refactor Vision Code

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

Task: Add OpenCV support to vision pipeline

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<VuforiaLocalizer.CloseableFrame> q;
    private int state = -3;
    private Mat mat;
    private List<MatOfPoint> 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<VuforiaLocalizer.CloseableFrame> q;
    private int state = -3;
    private Mat mat;
    private List<MatOfPoint> 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);
    }
}

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.

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.

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.

Task: Map and code auto for depot side start

Today, we implemented our first autonomous path. Since we we still didn't have a complete vision software, we made these manually so we can integrate vision without issues. Here are videos of all of the paths. For the sake of debugging the bot stops after turning towards the crater but in reality it will drive and park in the far crater. These paths will help us score highly during autonomous.

Center

Left

Right

Next Steps

We will get vision integrated into the paths.

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.

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.

Task: Get ready for Regionals

Regionals is coming up, and there are some driving issues that need to be addressed. Going back to November, one notable issue we had at the Conrad qualifier was the lack of friction between Bigwheel's wheels and the field tiles. There was not enough weight resting on the wheels, which made it hard to move suddenly.

Since then many changes have been made to Bigwheel in terms of the lift. For starters, we switched out the REV extrusion linear slide for the MGN12H linear slide. We have also added more components to intake and carry minerals. These steps have fixed the previous issue if we keep the lift at a position not exceeding ~70 degrees while moving, but having added a lot of weight to the end of the slide makes rotating around the elbow joint of Bigwheel problematic. As you can see below, Bigwheel's chassis is not heavy enough to stay grounded when deploying the arm (and so I had to step on the back end of Bigwheel like a fool).

Another issue I encountered during driver practice was trying to deposit minerals in the lander. By "having issues" I mean I couldn't. Superman broke as soon as I tried going into the up position, and this mechanism was intended to raise Bigwheel enough so that is would reach the lander. Regardless of Superman's condition, the container for the minerals was still loose and not attached to the servo. Consequently, I could not rotate the lift past the vertical without dropping the minerals I had collected.

Next Steps

To run a full practice match, Superman and the container will need to be fixed, as well as the weight issue. Meanwhile, I will practice getting minerals out of the crater.

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.

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.

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 January 12, 2019

Today's Meet Objectives

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

Task: Detail last-minute code changes to autonomous

It is almost time for competition and with that comes a super duper autonomous. For the past couple of weeks and today, we focused on making our depot side work consistently. Because our robot wasn't fully built, we couldn't do auto-delatching. Today, we integrated our vision pipelines into the auto and tested all the paths with vision. They seemed to work at home base but the field we have isn't built to exact specifications.

Next Steps

At Wylie, we will have to tune auto paths to adjust from our field's discrepancies.

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.

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.

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.

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.

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.

Task: Update our code

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.

Task: Design tokens to hand out at the North Texas Regional

We recently taught ourselves how to use the laser-cutter. Now that we've gone mad with power, we've decided to make little handouts for other teams. We plan to cut these on wood, with vector cutting around the edges and raster engraving for the logo and text.

Next Steps

We're really excited to go to regionals and good luck to whichever team is reading this!

This Saturday our two all-freshmen rookie FTC Robotics teams took it up a notch at their last qualifier tournament of the season. Iron Core was 5th place of 30 in robot performance and made it into the playoff rounds, but were then eliminated by the highest scoring team in our region. Iron Star also made it into the playoffs and then advanced upon receiving 2nd place Inspire Award along with the Control Award.

Iron Core: Mahesh Natamai, Ben Bruick, Jose Lomeli, Samuel Adler, Ephraim Sun (not present)

Iron Star: Katelyn Cumplido, Harish Jai Ganesh, Benjamin Oommen, Shawn Halimman, Aaron Daane, Evan Branson, Paul Lea, Beau Aveton, Cooper Clem (not present)

Iron Star joins our veteran teams Imperial Robotics who advanced on Jan 19th and Iron Reign who advanced in November and double-qualified on Jan 19th. Please congratulate our team members - we are the only school in the region with 3 advancing teams and it's unusual for a rookie team to advance. The Regional Championship will be held February 23rd at Wylie East High School. Five or six teams will advance from there to represent our region at the FTC World Championship in April.

This coming Saturday, February 2nd, is the Dallas ISD STEM Expo. Our teams will be there representing SEM and teaching younger students how to program simple sumo robots and how to use 3D printers. Come see us at the Dallas City of Learning exhibit where our teams will also be demonstrating their advancing robots and staffing the Mobile STEM lab that Iron Reign built. Tickets are free but you need to register: here.

Meeting Log January 26, 2019

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
• Code updates
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).



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

Today's Work Log

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

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.

Task: Update the latch

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

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
• Latch = bad
• 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
• Add flourishes
• Recut with thicker acrylic
• Mount LEDs underneath
• Update 3D model
• Add motors, gears
• 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
• Create design in illustrator
• Test design
• Cut many
• Are we bringing things to handout?
• Tokens to hand out ( laser cut)
• Business Cards

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.

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.

Task: Add omnidirectional wheels to intake arm

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.

Image of wheel attached to intake arm

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.

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.

Task: Plan for the DISD STEM Expo

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

As part of the exhibit, we will have events similar to those hosted as part of STEM Spark! This includes the LEGO Mindstorm Sumo Robots Event as well as our 3D Printing Keychains activity.

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

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.

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.

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 February 02, 2019

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

Task: Present at the DISD STEM Expo

DISD STEM Expo has been our busiest event this year. Overall, we met with over 1000 participants for both the 3D Printing event and the Sumo-Robots station. Despite the fact that this was a first-time event for many of the members helping out, STEM Expo ran smoothly. The purpose of this event is to spread STEM programs to students in the Dallas area who otherwise would have no access.

We started out by setting up the MXP and the EV3 robots. After ensuring that the MXP was stocked up with laptops and 3D printers, we set up sumo mats, laptops and LEGO Mindstorm Robots in tables outside the vehicle. All the freshmen were given a quick crash-course on how to run the Sumo-Robots session, while the seniors ensured that all of the FTC robots were demo-ready.

Since the participants were of varying ages, one of our biggest challenges was trying to convey the message of actually coding the robot across a variety of audiences. We learned earlier on that the best way to teach younger audiences how to code the robots was by letting them test out each block of code, so that they could get a sense of what they were trying to accomplish.

We also had a few connect opportunities. Best Buy (Geek Squad) representatives boarded the RV to ask about our program. Our MXP is funded by Best Buy - we received a $10k grant from them earlier this season - and this was a great opportunity to talk to them again. We spoke about the history of the MXP program, what it currently does, and our plans to create a new MXP with the $150k in funding that BigThought received as well as our need for an additional $100k. Also present at the STEM Expo were several Microsoft employees. We've worked at Microsoft events before, most notably YouthSpark, and they've contributed to the MXP program, so we talked to them again over the same topics, trying to garner up support for the new MXP.

Next Steps

Our booth could not have operated as smooth as it did without BigThought, for helping us staff and maintain the MXP, and DISD for giving us the opportunity to introduce FIRST to such a large audience. As hectic as it was trying to teach block programming and 3D modeling to students with little to no technical experience, the event ran much more systematically than we could have expected. It was energizing to see children excitedly “battle” their robots, and to see them walk away, waving a 3D-printed keychain. We are incredibly thankful for having been able to interact with the next generation of engineers, and giving them a platform to see robotics as a comprehensible concept.

Task: DISD STEM EXPO

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.

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

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.

Demonstrating intake arm for FLL kids

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.

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.

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.

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

Task: Design a state machine class to make autonomous easier

In the past our autonomous routines were tedious and difficult to change. Adding one step to the beginning of an autonomous would require changing the indexes of every single step afterwards, which could take a long time depending on the size of the routine. In addition, simple typos could go undetected, and cause lots of problems. Finally, there was so much repetitive code, making our routines over 400 lines long.

In order to remedy this, we decided to create a state machine class that takes care of the repetitive parts of our autonomous code. We created a StateMachine class, which allows us to build autonomous routines as sequences of "states", or individual steps. This new state machine system makes autonomous routines much easier to code and tune, as well as removing the possibility for small bugs. We also were able to shorten our code by converting it to the new system, reducing each routine from over 400 lines to approximately 30 lines.

Internally, StateMachine uses instances of the functional interface State (or some of its subclasses, SingleState for states that only need to be run once, TimedState, for states that are run on a timer, or MineralState, for states that do different things depending on the sampling order). Using a functional interface lets us use lambdas, which further reduce the length of our code. When it is executed, the state machine takes the current state and runs it. If the state is finished, the current state index (stored in a class called Stage) is incremented, and a state switch action is run, which stops all motors.

Here is an autonomous routine which has been converted to the new system:

private StateMachine auto_depotSample = getStateMachine(autoStage)
            .addNestedStateMachine(auto_setup) //common states to all autonomous
            .addMineralState(mineralStateProvider, //turn to mineral, depending on mineral
                    () -> robot.rotateIMU(39, TURN_TIME), //turn left
                    () -> true, //don't turn if mineral is in the middle
                    () -> robot.rotateIMU(321, TURN_TIME)) //turn right
            .addMineralState(mineralStateProvider, //move to mineral
                    () -> robot.driveForward(true, .604, DRIVE_POWER), //move more on the sides
                    () -> robot.driveForward(true, .47, DRIVE_POWER), //move less in the middle
                    () -> robot.driveForward(true, .604, DRIVE_POWER))
            .addMineralState(mineralStateProvider, //turn to depot
                    () -> robot.rotateIMU(345, TURN_TIME),
                    () -> true,
                    () -> robot.rotateIMU(15, TURN_TIME))
            .addMineralState(mineralStateProvider, //move to depot
                    () -> robot.driveForward(true, .880, DRIVE_POWER),
                    () -> robot.driveForward(true, .762, DRIVE_POWER),
                    () -> robot.driveForward(true, .890, DRIVE_POWER))
            .addTimedState(4, //turn on intake for 4 seconds
                    () -> robot.collector.eject(),
                    () -> robot.collector.stopIntake())
            .build();

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

Future Changes

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,

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.

Task: Map and test controls

With regionals being a week away, the robot needs to be in drive testing phase. So, we started out by mapping out controls as depicted above.

Upon testing the controls, we realized that when the robot went into Superman-mode, it collapsed due to the lopsided structure of the base since the presets were not as accurate as they could be. The robot had trouble trying to find the right position when attempting to deposit and intake minerals.

After we found a preset for the intake mechanism, we had to test it out to ensure that the arm extended far enough to sample. Our second task was ensuring that the robot could go into superman while still moving forward. To do this, we had to find the position which allowed the smaller wheel at the base of the robot to move forward while the robot was in motion.

Next Steps

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.

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

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 February 16, 2019

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

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.

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

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.

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

• Unbury $150k grant post, make title "major grant to fund replacement of vehicle" + fix receiving + remove last sentence
• Add Ben, Jose headshots to organization slide
• Replace townview qualifier photo
• Add Microsoft section to stem expo post
• Add motivate tag, remove connect from drive testing at stem expo
• Remove all motivate from connect table of contents
• Bold totals in the iron reign grants post
• Fix pulley spacers image
• Fix broken image last meetinglog
• Remove connect posts from motivate table
• Add to stem spark post
• Post summary of motivate and connect 2x
• Add letters to presentation tabs to indicate award
• Change decisions to priorities in presentation
• Remove center photo collector system in presentation
• Delete slide 38 with wordcloud in presentation
• Remove what we need help with slide
• Make text bigger on Connect summary slide, add totals in title in red
• Update journal summary
• Make a latch retrospective post
• Post about rebuilding elbow
• Fix Woodrow Code blog post
• Add articulation and drive enhancement posts
• Make post about bearings in linear slide

Tuesday

• Battery Mount
Evan worked on a battery mount for the robot. While drive testing, we had found that the battery and camera would fall out under extreme conditions, so we decided to create a new one. Evan cut battery "corners" out of polycarb and mounted them together, ensuring that the battery would stay static in every match.
• Editorial Review 2
Ethan wrote new posts on the history of the latch, the rebuilding of the elbow, connect and motivate summaries, and fixed the above issues from the editorial review. In addition, we rewrote the summary, as we found that it would be heavily considered in Regional judging. Charlotte uploaded old meeting logs.
• Driver Practice
Karina, Justin, and Jose practiced driving the robot. We discovered that the robot latches extremely well with the new hook and that the autonomous delatch works. We also tested the articulation, or poses, of our robot. The only issue that popped up was when the robot moves into deposit mode, it tips toward the side with linear slides, but Karina discovered that if she drives the robot forward at the same time, she can ram the robot into the correct position. Karina got to 4-5 cycles per match with the new updates. This practice was a way to test the strength of our robt - we've had our robot break under stressful situations previously - and this time nothing broke. The biggest issue was that a servo wire on our intake came unplugged, but even with that, our robot still worked.
• Model Articulation
Justin took the last measurements for the model of our robot, then started to take pictures of the articulations we made in the code.
• Hat
We finished the light-up LED hat.

Wednesday

• Driver Practice and Autonomous
Karina and Abhi worked on the robot. Karina gave advice for improving our robot's articulations to Abhi, who proceeded to fix the code for better driver practice. Abhi also worked on delatch in autonomous, reversing the autonomous driver enhancement code and taking data from Karina's testing. We discovered one new issue with our robot, that the gearkeepers for Superman pop out of alignment after about 100 uses. All we need to do is realign them, and they'll be back to full functionality.
• Control Award
Arjun continued writing the Control Award submission, adding in the new articulations and poses of the driver enhancements. Janavi created state diagrams for the code to add to the submission.

Task: Summary of all Big Wheel movements

In our motion, our robot shifts multiple major subsystems (the elbow and Superman) that make it difficult to keep the robot from tipping. Therefore, through driver practice, we determined the 5 major deployment modes that would make it easier for the driver to transition from mode to mode. Each articulation is necessary to maintain the robot's center of gravity as its mode of operation shifts.

The position seen above is called "safe drive". During normal match play, our drivers can go to this position to navigate the field quickly and with the arm out of the way.

When the driver control period starts, we normally navigate to the crater then enter the intake position shown above. From this position, we can safely pick up minerals from the crater.

From the intake position, the robot goes to safe drive to fix the weight balance then goes to the deposit position shown above. The arm can still extend upwards above the lander and our automatic sorter can place the minerals appropriately.

During the end game, we enter a latchable position where our hook can easily slide into the latch. After hooked on, our robot can slightly lift itself off the ground to hook.

At the beginning of the match, we can completely close the arm and superman to fit in sizing cube and latch on the lander.

As you can see, there is a lot of articulations that need to work together during the course of the match. By putting this info in a state machine, we can easily toggle between articulations. Refer to our code snippets for more details.

Next Steps

At this point, we have 4 cycles in 1 minute 30 seconds. By adding some upgrades to the articulations using our new distance sensors, we hope to speed this up even more.

Task: Tweaking ftc_app to allow us to drive robots without a Driver Station phone

As you already know, Iron Reign has a mechanized cart called Cartbot that we bring to competitions. We used the FTC control system to build it, so we could gain experience. However, this has one issue: we can only use one pair of Robot Controller and Driver Station phones at a competition, because of WiFi interference problems.

To avoid this pitfall, we decided to tweak the ftc_app our team uses to allow us to plug in a controller directly into the Robot Controller. This cuts out the need for a Driver Station phone, which means that we can drive around Cartbot without worrying about breaking any rules.

Another use for this tweak could be for testing, since with this new system we don't need a Driver Station when we are testing our tele-op.

As of now this modification lives in a separate branch of our code, since we don't know how it may affect our match code. We hope to merge this later once we confirm it doesn't cause any issues.

Task: Finish the Bigwheel model

Updating the Bigwheel model to the robot’s current configuration was a challenge. The new linear slides are not standard parts, so we had to model them from scratch. There was some cleaning up that was needed on the drivetrain of the model. This was mainly attaching floating motors to motor mounts and axles to bearings. These were mainly cosmetic changes, but they help define the purpose of the different parts of the drivetrain. We also updated the intake assembly to our current ice cube tray intake. The structure of the intake was easy to model but the ice cube tray gave us some trouble with its unique shape and pattern. The ratchet latching system was a failure, so a new hook model was needed. The main issue with this was that we custom forged our new hook, so there was some difficulty in getting the model to accurately represent the capabilities of the hook. Another challenge was the mineral storage system. This is made from polycarb pieces and has many unique pieces, so arranging the pieces to accurately show the flow of minerals was difficult.

In addition to updating the model, we also learned how to show the different movements of the robot with the model. Mechanical constraints were added to allow certain parts to slide or rotate. The one problem we had with this was that there were no limitations to how far something could slide or rotate, so many parts of the model would disconnect and be left floating. After some research, a solution was found. Zero points were created for each moving part and minimum and maximum movement limits were added. Some parts that now can move on the robot are the wheels, superman arm, hook, and linear slides. This allows us to not only show the movement of the robot, but also the limitations of its parts, which can help us visualize new solutions to our remaining problems.

Next Steps

Our next step is to wait for more build changes, so we can keep updating the model. Another addition we might make is making stress maps of the robot in different configurations to see where parts might fail. This has been an ongoing challenge of keeping the model accurate when the robot gets updated or rebuilt, and now we finally have a finished model and ready robot for regionals.

How to tweak ftc_app to allow you to drive robots without a Driver Station phone:

A lot of teams have been asking about how we were able to tweak our code to allow us to drive robots without a Driver Station. We posted about this earlier in the post titled Cart Hack, but now we are going to show you how to do this.

First, we have to add code to FtcRobotControllerActivity to allow it to handle any joystick events. We do this by adding the following lines to the bottom of the class (still above the last closing bracket).

This lets us handle gamepad events in the activity. Then, we create the following class in the same folder as FtcRobotControllerActivity. This lets us access the RC phone's gamepad in our OpModes.

Finally, in any of our OpModes where we wish to use the RC's gamepads, we add the following static import to the top of our code (under the other import statements).

Now, wherever we want to use the RC phone's gamepad, we use gamepadRC wherever we would be using gamepad1 normally.

In order to actually connect a gamepad to the RC phone, along with the REV Hub (or Modern Robotics equivalent), we need to use a USB hub. You connect the USB hub into the OTG cable (which is then plugged into the phone), and plug both the gamepad and REV hub into the USB hub. You do not need to use a powered hub for this, any regular USB hub will work. This is the same type of USB hub that you would use if you wanted to plug two gamepads into the driver station.

That's all! We hope that this guide will help you replicate what we have done with our Robot Controller app to help make robot development easier!

Task: Compete at the North Texas Regional Tournament

Preparation

Unlike other tournaments, we started packing before morning. We packed as if we were going out of state, bringing a bandsaw, all-new charging box, every replacement part imaginable, and a printer which would ultimately come in handy later. We relied on a packing list created by Janavi, detailed below.

Because of this, we got to Wylie on time, turned in our notebooks, had the team rosters printed out, and were able to start right away.

Inspection

Breaking our all-season streak, we failed our first inspection, cited for our unruly cable management. So, we made a hasty retreat back to the pits and zip-tied the cables together and rethreaded our intake servo wires through the cable guards, then brought it back to inspection. We passed, but we were warned about possible size issues with the team marker. But, looking at RG02, we realized that it wasn't a major concern.

Judging

The main issue this time was not speed or knowledge but simple enthusiasm - it just felt off and a little uncharismatic. However, we received three separate pit visits for what we believer were Motivate, Connect, and Innovate. In particular, we were able to get the Motivate judges out to see the MXP and talk about expanding the program while keeping it sustainable. The Innovate judges focused on the Superman mechanism, as it's fairly unique, and we fielded questions about the design process. In Connect, we also talked about the MXP and its $150k grant largely because of our efforts.

Robot Game

Match 1(Q3)

Match 2(Q9)

Match 3(Q15)

Match 4(Q26)

Match 5(Q33)

Match 6(Q36)

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

Match 1

Match 2

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!

On Febuary 23, 2019, SEM Robotics sent three teams to the fifty two team North Texas Regional Championship, the largest showing of any school.

Left to right: Jose Lomeli, Arjun Vikram, Abhijit Bhattaru, Ben Bruick, Bhanaviya Venkat, Evan Daane, Karina Lara, Charlotte Leakey, Jana Chadha, Kenna Tanaka, Justin Bonsell and Ethan Helfman

Iron Reign, SEM's varsity team, won 1st place Motivate award and 3rd place Inspire, advancing them to both the State UIL and Worlds Championships in April. The Motivate award recognizes teams who demonstrate exceptional community service, and in this case, was for Iron Reign's continued expansion of the Mobile Learning Lab program. In addition, the Inspire award is given to teams who represent the spirit of the FIRST program: outstanding not only in robot game, but also engineering processes, connecting with professionals, innovative designs and supporting other teams.

Individually, Karina Lara and Justin Bonsell were recognized as FIRST Dean's List Semi-Finalists. Named after FIRST Founder Dean Kamen, inventor of the Segway and the portable dialysis machine, Dean's List students are considered leaders in their community who exemplify the ideals of FIRST while achieving technical excellence. Karina Lara was then announced as one of four Dean's List Finalists who will go on the represent North Texas at the FTC World Championship.

Imperial Robotics, our other veteran team, medaled when they made it to the final round of the Regional Championship through their exceptional robot performance, only losing by a thin margin in the last match. If another advancing team can't go to Worlds, Imperial will be the next team to advance.

Members included: Trey Davis, Samuel Adler, Rohit Shankar, Christian Saldana, Hudson Shields and Blaine Wells (not shown)

All-freshman team Iron Star performed with distinction. Not only did they earn a spot at the Regional Championship as a rookie team, they also demonstrated coolness under stress as they experienced persistent issues with robot disconnections. They never stopped trying to get the robot back online, stayed professional throughout the tournament and gained valuable experience that will help them elevate to veteran teams next year. Members included: Katelyn Cumplido, Shawn Halimman, Evan Branson, Paul Lea, Aaron Daane, Beau Aveton, Cooper Clem, Harish Jai Ganesh, and Benjamin Oommen.

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

Meeting Log March 02, 2019

Today's Meet Objectives

Since we qualified for worlds, we are using today as an opportunity to start our Road to Worlds, as the discussions we have today will shape our progress for the next 8 weeks. We plan to start today with a post-mortem discussion regarding our previous competition, and then we will proceed to evaluate our strengths and shortcomings throughout the post-mortem. These lessons will shape our Road to Worlds document, a guide that outlines our major objectives within every subteam of Iron Reign.

Today's Work Log

• 15 minute cleaning/organization session
• Planning session
• Post-mortem
A post-mortem follows every major competition we attend, so that we can put into words and learn from our successes and failures in a constructive environment. We spent most of our meeting today reflecting on last week's regional competition with topics including robot performance, pit conduct, and preparation, and our detailed post-mortem can be found at (E-118, North Texas Regional Postmortem). Skype call with Jayesh
• Presentation post-mortem
We discussed (on a Skype call) our presentation with one of our alumni, Jayesh, who gave us guidance and feedback based on a video we took of our presentation at regionals so that we can improve our presentation in the coming weeks.
• Road to Worlds
Following our post-mortem discussion, we booted up our road to worlds doc and began our discussion as to how we will accomplish everything we need to in 8 weeks. Our Road to Worlds document will help increase focus and productivity so we don't lag behind in our progess. See our Road to Worlds at (E-119, Road to Worlds 2019).
• Further planning
If we are going to accomplish what we set out to, it is going to require immense commitment and higher-level planning. We need to decide how we are going to spend spring break, and with a Doodle poll that indicates participation for the next two weeks, we can plan accordingly. We may not have many builders, so hopefully we can do drive practice.

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.

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?
• CAD models
• 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)
• CAD Model

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

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.

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:

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.

Meeting Log March 08, 2019

Friday

• Widen Superman
Cooper and Ben O widened our Superman wheel from one omni wheel to two. This will improve our robots ability to turn and balance, as just one wheel would dig into the foam tiles due to a smaller surface area and make it more difficult for the robot to turn. Having two wheels increases this surface area, making driving easier.
• Bill of Materials
Karina and Bhanaviya started a bill of materials, which lists each part of our robot and where they are from. The purpose of this bill is to make it easier for the builders to build our second robot as they can easily access the source of each part. See the bill of materials at (E-131, Bill of Materials).
• Learning to blog
Cooper learned to use the blog, and because he worked on the journal on his old team, hopes to apply these skills extensively in the future.

Tuesday

• Reverse articulations
Abhi and Ben O worked on reverse articulations, which allows the robot to position itself in ways that makes mineral collection more efficient. See more on reverse articulations at (E-139, Reverse Articulations).
• Drive practice
Karina got in some driver practice, which is going to be increasingly important as we get closer to UIL and Worlds.

Wednesday

• New VEX motors
Jose and Aaron opened up and started testing new VEX 393 motors. We are considering these motors because they are technically counted as servos and could help our intake perform more efficiently. See more at (E-124, VEX 393 Motor Testing).
• Wiring
The freshmen got experience with soldering. They did some wire gender changes for our servo power injector.
• Email Diversity Director
Janavi drafted an email to the diversity director at Worlds to get information about bringing the MXP to Worlds. We would like to share our outreach pursuits to other teams at Worlds as an example of a Motivate team.

Thursday

• Elbow model
Justin worked on the elbow redesign, which we are modeling to combine many intricate parts on our current robot to one, more serviceable and sturdy part on the robot. We finished the model and began its print. See more at (E-136, New Elbow).
• Intake prototyping
As we are in the process of redesigning our intake to be more efficient for worlds, we are making many prototypes. Since we are planning to design the new robot where the elbow can flip in both ways for intaking, we need an intake that works when flipped both ways. Aaron prototyped an intake mechanism that rotates while keeping the sorter oriented correctly as proof of concept.
• Finalize and send email to Diversity Director at Worlds about MXP

Friday

• Work on robot model
• Balancing adjustments
With our new reverse articulations, Abhi and Ben O have been tuning the PID constants in our code to improve our robot's balance, as each articulation has its own center of gravity.
• Restock polycarbonate

Localization

A feature that is essential to many advanced autonomous sequences is the ability to know the robots absolute location (x position, y position, heading). For our localization, we determine the robots position relative to the fields coordinate frame. To track our position, we use encoders (to determine displacement) and a gyro (to determine heading).

Our robots translational velocity can be determined by seeing how our encoder counts change over time. Heading velocity is simply how our angle changes in time. Thus, our actual velocity can be represented by the following equation.

Integrating that to find our position yields

Using this new equation, can obtain the robots updated x and y coordinates.

Task: Present to the Dallas Personal Robotics Group about FTC app and our modifications

Today we had 2 goals: present the FTC control system and allow everyone in the room to create their own FTC app to deploy to our robot. In the beginning of our presentation, we had a slideshow to show the overview of FTC as well as our progress this season since they last saw us. After this, I went through the process of creating a working opmode for our robot, Iron Reign style. The presentation is given below.

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.

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

Next Steps

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

Initial Work on Balancing Robot

Since our robot has two wheels and a long arm, we decided to take on an interesting problem: balancing our robot on two wheels as do modern hoverboards and Segways. Though the problem had already been solved by others, we tried our own approach.

We first tried a PID control loop approach as we had traditionally been accustomed to that model for our autonomous and such. However, this served as a large challenge as lag in loop times didn't give us the sensitivity that was necessary. However, we tried to optimize this model.

Next time we will continue fine tuning the gains, and use a graph plotting our current pitch versus the desired pitch to determine how we should tweak the gains to smoothly reach the setpoint. Another factor we need to account for is the varying loop times, and multiply these loop times into a pid calculations to ensure consistency. In addition, we may try to implement state space control to control this balancing instead of PID.

Task: Recieve a grant for the Iron Reign program

Iron Reign has received $1,000 from FIRST in Texas for tournament fees and robot parts. This will go a long way for our team, as DISD STEM has already stepped in to cover the Worlds' fees, which in turn allows us to use these funds for future seasons if needed.

Meeting Log March 16, 2019

Today's Meet Objectives

Agenda

Objective Summary

Our main objectives for today are to gather and assemble the parts and subsystems needed to construct our new robot as well as continue the improvement of our robot's balance programmatically.

Today's Work Log

• Beginning of new robot build
Aaron and Justin began working on our new competition robot. Justin designed and cut a polycarb base and Aaron assembled the elbow piece and both wheels. The polycarb base will be the structure of the robot, connecting all of the subsystems together.
• PID Tuning and Reverse Articulations
Abhi and Ben O have been tuning PID gains for autonomous and the presentation of our robot. Today, we focused on balancing our robot while the intake is fully expanded and the chassis is vertical without superman. This task is extremely complex considering the tiny balancing point and the height of the center of mass when the robot is extended in such a way. Also, since adjustments to our elbow, we are in the process of creating new reverse articulations. These allow the elbow to bend in the opposite direction as before to remove burden on our drivers. Abhi balancing robot before PID adjustments
• Bill of Materials
Bhanaviya and Karina continued to work on a bill of materials, which can be found at (E-131, Bill of Materials). This is a continuation of progress made during spring break, and such a record will make it easier to build our second robot, as builders will have easy access to each part we need and where to aquire such an item.
• BigWheel cutaways
Ethan made some cutaways using PTC Creo and Autodesk and our robot model, which required him to convert the file to .dxf in a certain articulation and then into an Illustrator file. This will allow us to better illustrate and document the design of the robot. Cutaway of BigWheel in Illustrator
• Intake analysis
Karina took some videos of our intake system to analyze its efficiency. Notably, we want to measure the time it takes a mineral to travel through our corn-on-the-cob intake and thus determine the lag that occurs in this process. This will guide our redesign of our intake mechanism. In the next week we will perform this analysis, which can be found at (E-132, Intake Speed).

Today's Member Work Log

Updates on Balancing Robot

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.

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.

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.

Meeting Log March 20, 2019

Today's Meet Objectives

Objective Summary

We plan to build the base of the chassis for the new robot, mainly by aligning the new REV rails with the polycarb base build last meeting.

Today's Work Log

• Layout the base of the new chassis
Karina, Justin and Evan measured and cut out rails for the new robot. Designing a new layout was a matter of deciding the REV Hub placement so that it did not interfere with the elbow motion. Since the chassis base holds all the subsystems together, it needs to be laid out such that all the rail and bolt alignments are able to support the structure of the robot.

• Mark and drill holes for new corners and rev rails
Justin worked on creating new corner pieces for the new chassis. These were larger and more rounded in order to create a stabler base. Additionally, they had more holes drilled into them in order to be compatible for the c-channel. The holes also serve as a means for supporting the LED Strip. Karina and Evan also drilled the new REV rails so that they would align with the new chassis.




• Replace gear sprockets
In order to switch from 60 to 1 standard gear boxes to 20 to 1 orbital motors, we replaced the gear sprockets with larger ones. This is because the new motors are much more robust and as such it would be ideal to employ the use of larger gear sprockets capable of supporting the motors' weight.

Today's Work Log

Meeting Log March 22, 2019

Today's Meet Objectives

Agenda

Objective Summary

Over the course of today’s meet, we plan to create new axle pieces for the big wheels of the new robot, calculate torque for Superman, improve articulations, and create a reveal video for Mini Mech.

Today's Work Log

• Create new axle-holders
Cooper and Ben B worked on creating new axle for the big wheels of the new chassis. Since we replaced gear keepers last meet, we will need to have axle pieces that can support the weight of the new gear keepers and the wheel. Ben worked on soldering the pieces while Cooper helped ensure that the pieces had enough room to be mounted on the chassis.

• Improve articulations
Abhi, Arjun and Ben O worked on merging all of the Pull Requests that they have made over the past few weeks, ensuring that they work together with each other and the existing code base. They also refactored our Articulation code to make it easier to use and understand. Additionally, they added support for State Space Controllers. State Space Controllers are advanced control loops which perform complex linear algebra over input matrices to find outputs. These can be used to make our articulations more efficient, as well as help with balancing on two wheels.

• Calculate torque for Big Wheel 2.0
Janavi worked on calculating torque for the different subsystems of the new robot. Since Superman has had some balancing issues in the past, calculating torque and understanding its degrees of freedom will enable us to ensure that its center of gravity is stable. She also calculated the torque for the lift to ensure that the linear slides don’t extend too far out and cause the robot to tip over.

• Create a reveal video for mini-mech
Paul created a reveal video for Mini-Mech. Since Mini-Mech played an essential role in us choosing our wheels and chassis design, it was only ideal to acknowledge its existence with a reveal video of its own. This video will also come in handy when attempting to see just how out iterative our design process has been.

Today's Work Log

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.

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.

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.

Next Steps: Redesign Intake Mechanism

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)

Meeting Log March 23, 2019

Today's Meet Objectives

Agenda

Objective Summary

Today, our main goal is to finish the chassis of our new robot, as well as identifying and fixing the error in our code that stops the OP mode that lets the intake extend into the crater.

Today's Work Log

• New robot chassis build
Justin, Ben B, and Jose installed the axle mounts (which have finished printing and being welded) and the second wheel). We installed the drive motors, fully assembled, and put together the drive change. Our chassis is complete except for the Superman arm, as those parts we started printing today. The print broke because the printer was on the wrong setting, rather than setting a base, the print pulled up. The new print should be finished in time to do the assembly of superman during the week. Chassis before installation of drive motors Ben B cutting the main drive shaft
• Sorter assembly for old BigWheel
In order to do drive practice with our old robot, Aaron and Cooper did some fixes to the intake for it to be functional again. While this is not the sorter we will use on our new BigWheel, so we can get some much-needed drive practice next week. Cooper with the sorter pre-assembly
• Identify and fix code error
The code team has been trying to identify a code error since yesterday so that they can continue fine-tuning autonomous and the robot won't malfunction while deploying in the crater. We also need this part of the code to work for drive practice that we hope to get next week. After some thorough searching, they found the error to stem from a missing break function that was supposed to occur between the case for deploying and for reverse driving. Arjun looking for the error
• Robot manual and team summary
Ethan worked on the robot manual, which is a brief but incredibly detailed guide of the subsystems on our robot. This will be put in our journal for the judges to read. We also updated the team summary to make it more concise so it is more easily digestible for the judges. Finally, we made a fold out for our journal to show the judges our outreach in a succinct manner.

Today's Member Work Log

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.

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.

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.

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.

Meeting Log March 28, 2019

Today's Meet Objectives

Objective Summary

Fix camera mount, attach lift motors, make custom cables for the drive motors, and forge the hook

Today's Work Log

• Fix camera mount on BigWheel
We've had a problem for while where the camera on BigWheel gets loose, and falls out. Cooper decided that a clamp, like the one we had before, just better executed. Cut out of a spare piece of 4 mm Polycarb, and tightened by a m3 screw, it holds the camera in place without even the slightest wiggle. This will help keep our vision more consistent.
• Mounting elbow motor
Evan in the time being mounted the lift elbow motors on Icarus. This means we can start to make the arms.
• Make custom Cables for Icarus drive motors
Cooper worked on cutting down the motor cables of the Andy mark motors used for driving. This will help keep clutter down from how bad it was on BigWheel
• Forging new hook
Evan and Cooper worked on forging a new hook. It took two iterations, as the first became brittle and snapped, but the second one was fine. This new hook will go on Icarus, and will allow us to practice sooner

Task: Implement dual robot code

With the birth of Icarus came a new job for the programmers: supporting both Bigwheel and Icarus. We needed the code to work both ways because new logic could be developed on bigwheel while the builders completed Icarus.

This was done by simply creating an Enum for the robot type and feeding it into PoseBigWheel initialization. This value was fed into all the subsystems so they could be initialized properly. During init, we could now select the robot type and test with it. The change to the init loop is shown below.

Next Steps

After testing, it appears that our logic is functional for now. Coders can now further devlop our base without Icarus.

Task: Summary of Icarus Movements

In post E-116, I showed all the big wheel articulations. As we shifted our robot to Icarus, we decided to change to a new set of articulations as they would work better to maintain the center of gravity of our robot. Once again, we made 5 major deployment modes. Each articulation is necessary to maintain the robot's center of gravity as its mode of operation shifts.

The position seen above is called "safe drive". During normal match play, our drivers can go to this position to navigate the field quickly and with the arm out of the way. In addition, we use this articulation as we approach the lander to deposit.

When the driver control period starts, we normally navigate to the crater then enter the intake position shown above. From this position, we can safely pick up minerals from the crater. Note that there are two articulations shown here. These show the intake position both contracted and extended during intake.

During the end game, we enter a latchable position where our hook can easily slide into the latch. After hooked on, our robot can slightly lift itself off the ground to hook. This is the same articulation as before.

At the beginning of the match, we can completely close the arm and superman to fit in sizing cube and latch on the lander. This is the same articulation as before.

These articulations were integrated into our control loop just as before. This allowed smooth integration

Next Steps

As the final build of Icarus is completed, we can test these articulations and their implications.

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.

Task: Install intake arms

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.

Task: Connect the hook to a servo

When attaching the hook to the servo, it was very important that the configuration gave the hook its widest possible range of motion. The open position needed to as far back retracted as possible for an easier lander dismount, and the closed position had to be closed enough so that our robot would not fall off the lander in competition.

The hook was forged prior to its attachment, of course, so the mechanism had to account for the overextension of the end opposite the hook past the horizontal. To solve this problem, a L-bracket was mounted onto the end of the hook.

The closed position was easier. The servo rotated approximately 180 degrees (its full range of motion being from 899 to 2100) into the closed position.

Next Steps: Intake

Now that the hook system is completed, all that's left is to test it and then mount the intake.

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.

Task: Wire Icarus to be functional and move utilizing code

With the construction of Icarus nearing completion we need to start connecting wires from the motors and servos to the REV Expansion Hubs before it becomes impossible to do so.

• As soon as the expansion hub were placed on the chassis, servo wire extenders were connected before anything blocked us from doing so
• We used custom sized wires to avoid a mess of wires that were way too long
• We connected all the motors and servos in the same configuration as we had on BigWheel to keep everything consistent and make coding Icarus easier

Despite our preemptive measure we encountered several problems when testing Icarus using tele-op control:

• The polarities on the wires were reversed and this couldn't be fixed in code as the encoder values would be affected by this
• There was a lot more lag than usual on Icarus, this affected the intake arm as its movement is time-based
• The speed of the wheels were a lot faster now that we are using a different gear ratio and motor, however unlike the other problems, this can be fixed in code

Next Steps

We need to reverse the polarities on all the motor cables and try the fix the lag and speed issue with code.

Task: Plan the next stage of the MXP

In post B-7, we announced that BigThought received $150k on our behalf for the creation of a new MXP. Now, we've created a tentative floorplan for the new RV. The new RV will have these programs\features:

• Voice recording booth
• Green-screen - recording video
• 3D printers - keychains
• Laptops - 3D printing, EV3 coding
• EV3s - sumo bots

As well, the new RV will have two new slideouts, allowing for 20+ children to board safely. As well, the RV will be extended by 5', allowing for more space and a dedicated area to hold equipment.

Next Steps

Next, we need to create a full 3D model of the new MXP to send back to BigThought.

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

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

Game 2

Game 3

Game 4

Game 5

Next Steps

These will be detailed in the UIL post-mortem.

Task: Help Mechanicats, the other DISD team, debug their code

Competition is always stressful for everyone. There's so much that can go wrong, and when something does, it feels like all your hard work has gone to waste. We know first hand how it feels when something breaks. That's why we volunteered to help out Mechanicats when there was an announcement over the intercom that a team needed help with vision.

Mechanicats were having some trouble with their vision code. They told us they were able to sample correctly when they were on depot-side, but when they were on crater-side, they were unable to correctly identify the position of the gold mineral. We talked to them and helped them debug their code, and after a bit of testing, we were able to identify the problem for them.

The issue was that the TensorFlow detector they were using was returning null when it had already been called before because it expected client code to cache the objects it returned. This meant that when there were lots of minerals in the background, the detector would reuse the same objects to be more efficient. Mechanicats did not realize this, and thus since they were not caching the response of the detector, when they were on crater side they were unable to detect minerals.

After we fixed this issue for them with a few simple lines of code, we helped them exhaustively test it to ensure that it worked correctly. Mechanicats was extremely grateful for our help.

Task: Update code to get ready for UIL

It's competition time again, and with that means updating our code. We have made quite a few changes to our robot in the past few weeks, and so we needed to update our code to reflect those changes.

Unfortunately, because the robot build was completed very late, we did not have much time to code. That meant that we not only needed to stay at the UIL event center until the minute it closed to use their practice field (we were literally the last team in the FTC pits), we also needed to pull a late-nighter and stay up from 11 pm to 4 am coding.

One of our main priorities was autonomous. We decided early on to focus on our crater-side autonomous, because in our experience, most teams who only had one autonomous chose depot-side because it was easier to code.

Unfortunately, we were quite wrong about that. We were forced to run our untested depot-side auto multiple times throughout the course of the day, and it caused us many headaches. Because of it, we missampled, got stuck in the crater, and tipped over in some of our matches where we were forced to run depot-side. Towards the end of the competition, we tried to quickly hack together a better depot-side autonomous, but we ran out of time to do so.

Some of the changes we made to our crater-side auto were:

• Updating to use our new reverse articulations
• Moving vision detection during the de-latch sequence
• Speeding up our autonomous by replacing driving with belt extensions
• Sampling using the belt extensions instead of driving to prevent accidental missamples
• Using PID for all turns to improve accuracy

We also made some enhancements to teleop. We added a system to correct the elbow angle in accordance to the belt extensions so that we don't fall over during intake when drivers adjust the belts. We also performed more tuning to our articulations to make them easier to use.

Finally, we added support for the LEDs to the code. After attaching the Blinkin LED controller late Friday night, we included LED color changes in the code. We use them to signal to drivers what mode we are in, and to indicate when our robot is ready to go.

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

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.

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.

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.