Please help support our team! $40 buys a motor, $55 buys a new battery, $150 adds controllers and sensors, $500 pays tournament fees, $750 upgrades our chassis

Iron Reign

Welcome to Iron Reign at Dallas ISD's Science and Engineering Magnet

Iron Reign earns FTC World Championship Motivate Award

22 Apr 2018

Iron Reign earns FTC World Championship Motivate Award

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.


Top Row: Justin Bonsell, Christian Saldana, Charlotte Leakey, Tycho Virani, Evan Daane, Austin Davis
Bottom: Janavi Chadha, Kenna Tanaka, Abhijit Bhattaru, Karina Lara and Ethan Helfman
coached by Karim Virani, Cathy Lux and Calvin Boykin

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:

School of Science and Engineering Freshman Orientation

26 Apr 2018

School of Science and Engineering Freshman Orientation By Austin and Shaggy

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

Finishing the Chassis

29 Apr 2018

Finishing the Chassis By Kenna and Janavi

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.

UIL 2018

18 May 2018

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

Task: Attend the 2018 UIL Robotics Competition

Background

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

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

The Night Before

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

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

The Day Of

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

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

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

Robot Performance

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

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

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

The UIL Difference

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

Next Steps

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

Contacting Mark Cuban

23 May 2018

Contacting Mark Cuban By Abhi

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!

Response from Mark Cuban

24 May 2018

Response from Mark Cuban By Abhi

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!

Conversing with Mark Cuban

26 May 2018

Conversing with Mark Cuban By Abhi, Ethan, Janavi, Christian, Kenna, and Charlotte

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!

Iron Reign sponsored by Mark Cuban

01 Jun 2018

Iron Reign sponsored by Mark Cuban By Abhi

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.

Swerve Drive Experiment

02 Jun 2018

Swerve Drive Experiment By Abhi

Task: Consider a Swerve Drive base

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

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

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

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

Next Steps

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

Swerve Drive Prototype

09 Jun 2018

Swerve Drive Prototype By Abhi and Christian

Task: Build a Swerve Drive base

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

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

Next Steps

Consider and prototype other chassis designs until Rover Ruckus begins.

Big Wheel Ideas

23 Jun 2018

Big Wheel Ideas By Janavi

Task: Create a Unique Chassis

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

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

Next Steps

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

Turn Up! at Dallas Love Field

23 Jun 2018

Turn Up! at Dallas Love Field By Justin, Ethan, Charlotte, Kenna, Abhi, and Evan

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.

2018-19 Connect and Outreach Strategy

30 Jun 2018

2018-19 Connect and Outreach Strategy By Ethan

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

CNC Machine Rehab 1

01 Jul 2018

CNC Machine Rehab 1 By Ethan and Charlotte

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.

2018-2019 Recruitment

14 Jul 2018

2018-2019 Recruitment By Ethan

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.

Central Public Library Outreach Event

14 Jul 2018

Central Public Library Outreach Event By Ethan, Kenna, Charlotte, and Evan

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.

Position Tracking

18 Jul 2018

Position Tracking By Abhi

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

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

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

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

Next Steps

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

Moon Day 2018

21 Jul 2018

Moon Day 2018 By Karina, Ethan, Janavi, and Charlotte

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.

Chassis Flyer

22 Jul 2018

Chassis Flyer By Ethan

Kraken

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

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

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

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

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

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

BigWheel

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

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

Garchomp

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

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

Summer Chassis Project - July Meeting

22 Jul 2018

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

Task: Compare & Collaborate on Chassis

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

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

Austin Lui of Technicbots gets their chassis ready for testing.

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

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

Connor Mihelic of EFFoRT adds some finishing touches.

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


Terri and Grant Richards of Schim Robotics.

Next Steps

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

Replay Autonomous

28 Jul 2018

Replay Autonomous By Arjun

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

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

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

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

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

Next Steps

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

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

SEM Nest Outreach

02 Aug 2018

SEM Nest Outreach By Arjun

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.

C.A.R.T. Bot Summer Project

12 Aug 2018

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

Task: Enhance our robot-building skills

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

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

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

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

Next Steps

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

Best Buy Grant

14 Aug 2018

Best Buy Grant By Ethan

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.

Dallas Back to School Fair

18 Aug 2018

Dallas Back to School Fair By Ethan and Kenna

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.

Adjusting Garchomp's Chains

18 Aug 2018

Adjusting Garchomp's Chains By Janavi and Kenna

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
Due to our tests we discovered that our wheels were running at different speeds, meaning that our robot constantly moved in circles. After checking that the motors were working, we discovered that it was our encoder cables that were plugged in wrong. After that, Garchomp began to run smoothly.

Next Steps

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

My Summer at MIT

19 Aug 2018

My Summer at MIT By Abhi

Task: Spend a Summer at MIT

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

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

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

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

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

Next Steps

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

Hey New Members!

20 Aug 2018

Hey New Members! By Kenna

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.

BigWheel CAD

21 Aug 2018

BigWheel CAD By Ethan

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.

Mentor Involvement from MIT

25 Aug 2018

Mentor Involvement from MIT By Abhi

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.

Organization!

25 Aug 2018

Organization! August 25, 2018 By Charlotte

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:


  • Top half:
  • Omni Wheels (on the very top)
  • Drill Bits
  • Dremel & Exacto knives
  • Wrenches
  • Screwdrivers
  • Allen Wrenches

  • Bottom half:
  • Servos
  • Torque wrench
  • Bolt cutters
  • Tap & Dice set
  • Extension Cords

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


  • On the very top, you can find miscellaneous electronics.
  • Left Side:
  • Pliers
  • Sprockets
  • Motors
  • More motors

  • Right side:
  • Measurement tools & testers
  • USB Adapters (OTG cables)
  • Hardware (screws, bolts, nuts)
  • Wire
  • Zip-Ties

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

  • Left side:
  • Mini USB cables
  • Old motor/servo controllers
  • Nuts
  • More mini & micro USB cables
  • Shaft collars
  • Servo cables

  • Middle:
  • Motor mounts
  • Chains
  • Bevel gears
  • Tubing
  • Fabric paint
  • Adhesives
  • Grease
  • REV hardware

  • Right side:
  • Brackets
  • Springs
  • Files
  • Measurement Devices
  • Sandpaper
  • Hand Drills
  • Dremel Kits
  • Rubber Bands

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

    2018-19 Recruitment

    30 Aug 2018

    2018-19 Recruitment By Ethan, Kenna, Charlotte, Janavi, Abhi, and Arjun

    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.

    Bigwheel Presentation

    03 Sep 2018

    Bigwheel Presentation By Arjun and Karina

    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.

    Garchomp Presentation

    03 Sep 2018

    Garchomp Presentation By Janavi and Kenna

    Task: Present in the Inviational Presentation Series

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

    Presentation

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

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

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

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

    North Texas Invitational Presentation Series - Worlds

    03 Sep 2018

    North Texas Invitational Presentation Series - Worlds By Ethan, Abhi, Janavi, Kenna, Charlotte, Evan, Karina, and Justin

    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

    Post Kickoff Meeting

    08 Sep 2018

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

    Meeting Log September 08, 2018

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

    Today's Meet Objectives

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

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

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

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

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

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

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

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

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

    Today's Work Log

    Team MembersTaskStart TimeDuration
    KarinaWorking on blog2:004 hrs
    AbhiAutonomous planning2:004 hrs
    EvanRobot brainstorming2:004 hrs
    CharlotteRobot brainstorming2:004 hrs
    EthanWorking on blog2:004 hrs
    KennaCleaning tent2:004 hrs

    Rover Ruckus Brainstorming & Initial Thoughts

    08 Sep 2018

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

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

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

    Building

    • A One-way Intake System

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

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

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

    Journal

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

    Programming

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

    Next Steps

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

    2018 Kickoff

    08 Sep 2018

    2018 Kickoff By Ethan, Evan, Kenna, Charlotte, Abhi, Justin, Karina, and Arjun

    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.

    Testing Intakes

    09 Sep 2018

    Testing Intakes By Ethan and Evan

    Task: Design a prototype intake system

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

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

    Next Steps

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

    Rover Ruckus Strategy

    10 Sep 2018

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

    Task: Determine the best Rover Ruckus strategies

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

    Choosing Drive Train

    12 Sep 2018

    Choosing Drive Train By Janavi

    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

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

    Selecting Wheels

    12 Sep 2018

    Selecting Wheels By Janavi

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

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

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

    Brainstorming Two

    15 Sep 2018

    Brainstorming Two By Evan, Abhi, and Janavi

    Task: Have a 2nd brainstorming session

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

    Intake System 3 - TSA Bag Scanner

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

    Intake System 4 - Big Clamp

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

    Lift 2 - Thruster

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

    Next Steps

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

    Meeting Log

    15 Sep 2018

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

    Meeting Log September 15, 2018

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

    Today's Meet Objectives

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

    Today's Meet Log

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

    Today's Member Work Log

    Team MembersTaskStart TimeDuration
    KarinaRobot build and team marker design2:004 hrs
    AbhiOpen CV2:004 hrs
    EvanPrototyping2:004 hrs
    CharlotteBlog and brainstorming2:004 hrs
    EthanWorking on blog2:004 hrs
    KennaRobot build2:004 hrs
    JustinField assembly2:004 hrs
    JanaviPrototyping2:004 hrs

    Vision Discussion

    15 Sep 2018

    Vision Discussion By Arjun and Abhi

    Task: Consider potential vision approaches for sampling

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

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

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

    Next Steps

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

    CNN Training

    22 Sep 2018

    CNN Training By Arjun and Abhi

    Task: Capture training data for a Convolutional Neural Network

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

    Next Steps

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

    Chassis Brainstorming

    22 Sep 2018

    Chassis Brainstorming By Ethan and Evan

    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

    22 Sep 2018

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

    Meeting Log September 22, 2018

    Home Depot Trip!

    Today's Meet Objectives

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

    Today's Meet Log

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

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

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

    Today's Member Work Log

    Team MembersTaskStart TimeDuration
    KarinaRobot build and team marker design2:004 hrs
    AbhiOpen CV and build2:004 hrs
    EvanBuild2:004 hrs
    CharlotteBlog and brainstorming2:004 hrs
    EthanWorking on blog2:004 hrs
    KennaRobot build2:004 hrs
    JustinBuild and field assembly2:004 hrs
    JanaviBuild2:004 hrs
    ArjunCode and blog2:004 hrs

    Autonomous Path Planning

    26 Sep 2018

    Autonomous Path Planning By Abhi

    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.

    Hanging Hook Prototype

    26 Sep 2018

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

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

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

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

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

    Next Steps

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

    Meeting Log

    28 Sep 2018

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

    Meeting Log September 28, 2018

    Coding lessons with new recruits

    Today's Meet Objectives

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

    Today's Meet Log

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

      Today's Member Work Log

      Team MembersTaskStart TimeDuration
      KarinaTeam marker build2:004 hrs
      AbhiCoding and teaching2:004 hrs
      EvanRobot build2:004 hrs
      CharlotteBlog and organization2:004 hrs
      EthanWorking on blog2:004 hrs
      KennaRobot build2:004 hrs
      Justin3D Modeling2:004 hrs
      JanaviRobot build2:004 hrs

    BigWheel Chassis

    29 Sep 2018

    BigWheel Chassis By Evan

    Task: Work on a possible chassis

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

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

    Next Steps

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

    CNN Training Program

    29 Sep 2018

    CNN Training Program By Arjun and Abhi

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

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

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

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

    Next Steps

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

    Intake Sorter

    29 Sep 2018

    Intake Sorter By Abhi

    Task: Design a sorter for the balls and blocks

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

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

    Next Steps

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

    Designing Wheel Mounts

    29 Sep 2018

    Designing Wheel Mounts By Justin

    Task: Create wheel mounts for our Mini-Mecanum chassis

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

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


    Next Steps

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

    Iron Reign Grants!

    30 Sep 2018

    Iron Reign Grants! By Ethan

    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.

    Designing the Corn Cob Aligner

    05 Oct 2018

    Designing the Corn Cob Aligner By Ethan and Abhi

    Task: Design an aligner for the beater bar intake

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

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

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

    Next Steps

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

    Corn-Cob Intake

    06 Oct 2018

    Corn-Cob Intake By Ethan and Abhi

    Task: Design an intake system unique for balls

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

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

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

    Next Steps

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

    Team Marker Fun

    06 Oct 2018

    Team Marker Fun By Karina

    Task: Create the Team Marker

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

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

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

    Next Steps

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

    Another Design Bites the Dust

    06 Oct 2018

    Another Design Bites the Dust By Ethan

    Task: Discuss a new rule change

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

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

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

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

    Next Steps

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

    Labelling Minerals - CNN

    06 Oct 2018

    Labelling Minerals - CNN By Arjun and Abhi

    Task: Label training images to train a Neural Network

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

    Next Steps

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

    Meeting Log

    06 Oct 2018

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

    Meeting Log October 06, 2018

    Code Testing with Arjun

    Today's Meet Objectives

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

    Today's Meet Log

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

      Kenna with the chassis frame (pre-motored)

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

      Ethan working on the blog

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

    Today's Member Work Log

    Team MembersTaskStart TimeDuration
    CharlotteBlog and organization2:004 hrs
    EthanWorking on blog2:004 hrs
    KennaRobot build2:004 hrs
    JanaviRobot build2:004 hrs
    ArjunCode updates2:004 hrs

    Upgrading to FTC SDK version 4.0

    06 Oct 2018

    Upgrading to FTC SDK version 4.0 By Arjun

    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.

    Mining Base 2.0

    07 Oct 2018

    Mining Base 2.0 By Ethan

    Task: Rethink our static robot idea

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

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

    Next Steps

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

    Project Management

    10 Oct 2018

    Project Management By Charlotte

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

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

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

    Next Steps

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

    BigWheel+

    13 Oct 2018

    BigWheel+ By Evan

    Task: Continue work on BigWheel

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

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

    Next Steps

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

    Developing a CNN

    13 Oct 2018

    Developing a CNN By Arjun and Abhi

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

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

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

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

    Next Steps

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

    Meeting Log

    13 Oct 2018

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

    Meeting Log October 13, 2018

    Sumo bots at SEM STEM Spark

    Today's Meet Objectives

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

    Today's Meet Log

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

    Today's Member Work Log

    Team MembersTaskStart TimeDuration
    CharlotteOutreach8:0010 hrs
    EthanOutreach8:0010 hrs
    JanaviBuild8:0010 hrs
    ArjunConvolution Neural Network8:0010 hrs
    AbhiOutreach8:0010 hrs
    KarinaOutreach8:0010 hrs
    JustinOutreach8:0010 hrs

    Recruitment Update

    13 Oct 2018

    Recruitment Update By Ethan

    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.

    SEM STEM Spark Preparation

    13 Oct 2018

    SEM STEM Spark Preparation By Charlotte, Ethan, Janavi, Abhi, Karina, and Justin

    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.

    SEM STEM Spark

    13 Oct 2018

    SEM STEM Spark By Ethan, Charlotte, Janavi, Abhi, Karina, Justin, Bhanaviya, and Alisa

    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.

    Travis High School Night

    16 Oct 2018

    Travis High School Night By Ethan, Evan, Kenna, Charlotte, and Karina

    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.

    Mini Mecanum Chassis

    19 Oct 2018

    Mini Mecanum Chassis By Janavi and Justin

    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.

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

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

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

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

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

    Next Steps

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

    MXP Expansion - $150,000 Grant

    20 Oct 2018

    MXP Expansion - $150,000 Grant By Ethan

    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.

    Rewriting CNN

    20 Oct 2018

    Rewriting CNN By Arjun and Abhi

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

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

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

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    java
    		//Download dataset
    		DataDownloader downloader = new DataDownloader();
    		File rootDir = downloader.downloadFilesFromGit("https://github.com/arjvik/RoverRuckusTrainingData.git", "data/RoverRuckusTrainingData", "TrainingData");
    		
    		//Read in dataset
    		DataSetIterator iterator = new CustomDataSetIterator(rootDir, 1);
    		
    		//Normalization
    		DataNormalization scaler = new ImagePreProcessingScaler(0, 1);
    		scaler.fit(iterator);
    		iterator.setPreProcessor(scaler);
    		
    		//Read in test dataset
    		DataSetIterator testIterator = new CustomDataSetIterator(new File(rootDir, "Test"), 1);
    			
    		//Test Normalization
    		DataNormalization testScaler = new ImagePreProcessingScaler(0, 1);
    		testScaler.fit(testIterator);
    		testIterator.setPreProcessor(testScaler);
    		
    		//Layer Configuration
    		MultiLayerConfiguration conf = new NeuralNetConfiguration.Builder()
    				.seed(SEED)
    				.l2(0.005)
    				.weightInit(WeightInit.XAVIER)
    				.list()
    				.layer(0, new ConvolutionLayer.Builder()
    						.nIn(1)
    						.kernelSize(3, 3)
    						.stride(1, 1)
    						.activation(Activation.RELU)
    						.build())
    				.layer(1, new ConvolutionLayer.Builder()
    						.nIn(1)
    						.kernelSize(3, 3)
    						.stride(1, 1)
    						.activation(Activation.RELU)
    						.build())
    				/* ...more layer code... */
    				.build();
    

    Next Steps

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

    Intake Update

    20 Oct 2018

    Intake Update By Ethan, Abhi, Justin, and Kenna

    Task: Update the intake for the new robot size

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

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

    Next Steps

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

    Meeting Log

    20 Oct 2018

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

    Meeting Log October 20, 2018

    Juggling the minerals

    Today's Meet Objectives

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

    Today's Meet Log

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

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

    Arjun and the phone mount

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

    Intake mechanism with red silicon mats

    Today's Member Work Log

    Team MembersTaskStart TimeDuration
    CharlotteBlog and organization2:004 hrs
    EthanWorking on blog and intake build2:004 hrs
    KennaRobot build2:004 hrs
    JanaviLinear slide and chassis build2:004 hrs
    ArjunBuild and mentoring2:004 hrs
    KarinaRobot Build2:004 hrs
    AbhiIntake Build2:004 hrs

    Off-Schedule Meeting Log

    23 Oct 2018

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

    Meeting Log October 21 to October 23, 2018

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

    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.

    DISD Scrimmage at Hedrick MS

    27 Oct 2018

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

    Task: Compete at the Hedrick MS DISD Scrimmage

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

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

    Dallas Chamber Leadership Council

    30 Oct 2018

    Dallas Chamber Leadership Council By Kenna, Janavi, Abhi, and Ethan

    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.

    BigWheel Arm

    02 Nov 2018

    BigWheel Arm By Evan

    Task: Design an arm for BigWheel

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

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

    Next Steps

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

    Full Circle

    02 Nov 2018

    Full Circle By Evan

    A reflection on my time at Iron Reign

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

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

    Meeting Log

    03 Nov 2018

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

    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

    Team MembersTaskStart TimeDuration
    EthanPresentation\Journal2:004 hrs
    CharlotteBlog Backlog2:004 hrs
    KennaBlog Backlog2:004 hrs
    JanaviBigWheel Arm2:004 hrs
    ArjunBlog Backlog2:004 hrs
    KarinaBigWheel2:004 hrs
    AbhiAutonomous2:004 hrs
    EvanBlog Backlog2:004 hrs
    Justin3D Modelling2:004 hrs
    BhanviyaOnboarding2:004 hrs

    Pose BigWheel

    03 Nov 2018

    Pose BigWheel By Abhi

    Task: New Pose for Big Wheel robot

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

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

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

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

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

    Torque Calculations

    03 Nov 2018

    Torque Calculations By Karina

    Task: Calculate the torque needed to lift chassis

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

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

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

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

    Next Steps

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

    Linear Slide Lift

    04 Nov 2018

    Linear Slide Lift By Janavi

    Task: Design a lift for MiniChassis

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

    Horizontal Extension Goals

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

    Vertical Extension Goals

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

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

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

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

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

    Next Steps

    RIP CNN

    04 Nov 2018

    RIP CNN By Abhi

    Task: Farewell Iron Reign's CNN

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

    Next Steps

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

    BigWheel Upgrades

    05 Nov 2018

    BigWheel Upgrades By Evan

    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.

    SEM Robotics Tournament

    07 Nov 2018

    SEM Robotics Tournament By Coach and Ethan

    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.

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

    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.

    Conrad Qualifier

    10 Nov 2018

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

    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.

    Inspire at Conrad Qualifier

    10 Nov 2018

    Inspire at Conrad Qualifier By Ethan

    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.

    Left to right: Janavi Chadha, Bhanaviya Venkat, Justin Bonsell, Abhijit Bhattaru, Charlotte Leakey, Karina Lara, Ethan Helfman, Evan Daane, Karim Virani. Not shown: Kenna Tanaka, Arjun Vikram and mentors Catherine Lux and Calvin Boykin.

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

    Hudson Shields, Alisa Lin, Blaine Wells, Christian Saldana, Rohit Shankar. Not shown: Thu Le, Jonathan Hamada.

    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.

    Left to right: Katelyn Cumplido, Shawn Halimman, Henry Le, Evan Branson, Paul Lea, Aaron Daane. Not shown: Beau Aveton, Cooper Clem, Harish Jai Ganesh, Benjamin Oommen.

    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.

    Left to right: Mahesh Natamai, Jose Lomeli, Ben Bruick, Samuel Adler, Ephraim Sun.

    Code Post-Mortem after Conrad Qualifier

    10 Nov 2018

    Code Post-Mortem after Conrad Qualifier By Arjun and Abhi

    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.

    Materials Testing Planning

    16 Nov 2018

    Materials Testing Planning By Ethan

    Task: Design a lab to test nylon properties

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

    Nylon Testing

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

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

    Silicone Testing

    Similarly, we use the silicone oven mitts on our intake; we find that they grip the particles pretty well. The main thing that we want to test is the amount of energy they have while rotating and then the amount of energy they lose upon collision. We plan to test this through video-analysis. In addition, we wish to test the coefficient of friction of the mitts to see if a better material can be found.

    Next Steps

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

    Conrad Qualifier Post Mortem - Short Term

    17 Nov 2018

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

    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

    17 Nov 2018

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

    Meeting Log November 17, 2018

    Evan working on the robot!

    Today's Meet Objectives

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

    Today's Meet Log

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

    Today's Member Work Log

    Team MembersTaskStart TimeDuration
    KarinaOrganization and Build2:004 hrs
    AbhiConversation2:004 hrs
    EvanRobot build2:004 hrs
    CharlotteBlog and organization2:004 hrs
    EthanWorking on blog2:004 hrs
    KennaRobot build2:004 hrs
    Justin3D Modeling2:004 hrs
    JanaviOrganization and build2:004 hrs
    BhanaviyaLearning to Blog2:004 hrs

    Mentoring SchimRobots at Rice MS Tournament

    17 Nov 2018

    Mentoring SchimRobots at Rice MS Tournament By Bhanaviya

    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.

    Chassis Mark Two Planning

    20 Nov 2018

    Chassis Mark Two Planning By Ethan

    Task: Plan a new BigWheel chassis

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

    Our original BigWheel base.

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

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

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

    Basic design for the newest version of BigWheel.

    Next Steps

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

    Conrad Qualifier Post Mortem - Long Term

    20 Nov 2018

    Conrad Qualifier Post Mortem - Long Term By Ethan

    What could have gone better?

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

    Prep

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

    Programming

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

    Build

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

    Other

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

    C.A.R.T. Bot Side Shields

    01 Dec 2018

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

    Task: Design sideshields for the Townview Tournament

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

    Agenda for Dallas Personal Robotics Group

    01 Dec 2018

    Agenda for Dallas Personal Robotics Group By Bhanaviya, Karina, Kenna, Ethan, Abhi, Evan, and Charlotte

    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:

    1. Before the presentation begins, we will play the challenge reveal for this year, so that DPRG gets a basic idea as to what mechanical and technical challenges we must overcome in this season.
    2. Members who were with the team during Worlds will give an overview of what the Worlds championship is like.
    3. We give our judging presentation. (Approximately 15 minutes)
    4. We provide a demo of our robot. This demo will be similar to what we provided to the judges during pit-visits.
    5. We discuss some of our more ambitious build ideas thus far, such as the Superman Subsystem, and potential ways to improve upon these ideas.
    6. Provide an introduction of our Android Studio Control System and discuss the operation of how Big Wheel performs autonomous, and other low-level behaviors based on remote control and telemetry.
    7. We will wrap-up by discussing our expectations for the rest of the season, and answer any other questions DPRG has for us.

    Next Steps

    We will present on Saturday before returning to the house for our regular practice.

    Friction Coefficient and Energy

    01 Dec 2018

    Friction Coefficient and Energy By Ethan

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

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

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

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

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

    Next Steps

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

    Meeting Log

    01 Dec 2018

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

    Meeting Log December 01, 2018

    Today's Meet Objectives

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

    Today's Meet Log

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

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

      Materials friction testing

    • 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 MembersTaskStart TimeDuration
      AbhiCode2:004
      EthanBlog & Testing2:004
      EvanBuild2:004
      CharlotteBlog2:004
      BhanaviyaBlog2:004
      KarinaBuild2:004
      JustinModelling2:004
      KennaSocial Media2:004

    Selecting Lift System

    01 Dec 2018

    Selecting Lift System By Janavi

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

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

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

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

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

    Next Steps

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

    Linear Nylon Strength Test

    02 Dec 2018

    Linear Nylon Strength Test By Ethan

    Task: Measure linear nylon wear

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

    Linear Deformation

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

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

    Next Steps

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

    Code Issues Break the Superman Arm

    02 Dec 2018

    Code Issues Break the Superman Arm By Abhi

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

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

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

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

    Next Steps

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

    Arm Repairs

    06 Dec 2018

    Arm Repairs By Evan and Abhi

    Task: Fix elbow and Superman

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

    Rotational Nylon Wear Test

    07 Dec 2018

    Rotational Nylon Wear Test By Ethan

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

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

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

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

    Next Steps

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

    Presenting to the DPRG

    08 Dec 2018

    Presenting to the DPRG By Ethan, Janavi, Charlotte, Arjun, Karina, Abhi, Evan, Bhanaviya, and Kenna

    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.

    DPRG Vision Presentation

    08 Dec 2018

    DPRG Vision Presentation By Arjun and Abhi

    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.

    Townview Qualifier 2018 - Setting Up

    14 Dec 2018

    Townview Qualifier 2018 - Setting Up By Bhanaviya, Ben, Karina, Kenna, Ethan, Evan, Charlotte, Justin, Janavi, Austin, and Jayesh
    Task: Prepare Townview for SEM's qualifier on December 15th

    On December 15th, Iron Reign is hosting an FTC qualifier at Townview Magnet Center with around 30 teams competing. For the past 2 weeks, robotics alums, current members of Iron Reign, Iron Star, Iron Core and Imperial Robotics have been signing up to be volunteers for the very event. By Friday, the day before the qualifier, all our positions were confirmed for the tournament. In addition to getting assigned for the qualifier, we also helped with field set-up. Two fields were set up on each side of the cafeteria, to accommodate for the influx of teams competing. A field was set up behind the cafeteria to act as a practice field for queuing teams. Speaking of queuing teams, 8 tables were set up behind each field for teams to queue in. A monitor was brought in from Mr Boykin's room to display the teams' scores over the course of the match. We helped ensure that enough chairs were set up for the audience members, and that each team had a table of its own to operate their last-minute-panicked-robot-surgery on. In order to delineate the difference between teams competing on the two different fields, we put red and blue tapes on each table, after putting up a plaque card representing the competing teams' numbers.

    After ensuring that the actual competition area was set-up, we worked on setting up the judging rooms for judging presentations. We cleared out chairs in 5 rooms on the first floor, and set up two tables at the end of each room for the judges. Each room was marked with a piece of paper to represent the judging room number.

    Once we were finished setting up, we left to the Virani house, to set up the MXP. The purpose of the MXP being present at the qualifier was to provide the competing teams an area to work with Iron Reign on their robots, in the event they needed assistance. After ensuring that the vehicle was in driveable state, we worked on setting up laptops in the MXP. Then, we stocked it with tools that competing teams could use when needed. Next Steps Be prepared to carry out our respective roles as volunteers the next day, and lead competing teams through judging, queuing, and matches.

    Helping PiGuardians with Code

    15 Dec 2018

    Helping PiGuardians with Code By Arjun

    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.

    Townview Qualifier 2018 - The Day Of

    15 Dec 2018

    Townview Qualifier 2018 - The Day Of By Ethan, Janavi, Evan, Abhi, Charlotte, Karina, Kenna, Arjun, Jayesh, and Bhanaviya

    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.

    Selecting Intake System

    20 Dec 2018

    Selecting Intake System By Janavi

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

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

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

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

    Passive Deposit vs Passive Intake

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

    Intake Mechanism Material / Shape

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

    REV Headquarters Visit

    21 Dec 2018

    REV Headquarters Visit By Ethan, Charlotte, Abhi, Bhanaviya, Evan, Karina, and Arjun

    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.

    End of TIG Welding

    21 Dec 2018

    End of TIG Welding By Evan

    Task: Detail TIG welding plans and why they failed

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

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

    The Return of BatteryBox

    22 Dec 2018

    The Return of BatteryBox By Ethan

    Task: Create a charging station for our phones and batteries

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

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

    Next Steps

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

    BigWheel Arm Locks

    22 Dec 2018

    BigWheel Arm Locks By Evan

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

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

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

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

    Next Steps

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

    Scoring Mechanism

    22 Dec 2018

    Scoring Mechanism By Janavi and Abhi

    Task: Create a way to hold minerals

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

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

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

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

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

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

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

    Next Steps

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

    Meeting Log

    22 Dec 2018

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

    Meeting Log December 22, 2018

    Today's Meet Objectives

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

    Today's Meet Log

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

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

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

      Today's Member Work Log

      Team MembersTaskStart TimeDuration
      ArjunNeural network data collection2:001
      JanaviPrototyping2:001
      BhanaviyaPrototyping2:001
      EthanBlog2:001
      EvanBuild & Prototyping2:001
      CharlotteBlog2:001
      AbhiPrototyping2:001

    Creating Side-Latches

    26 Dec 2018

    Creating Side-Latches By Evan

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

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

    Next Steps:

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

    Meeting Log - Dec. 19, 2018

    29 Dec 2018

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

    Meeting Log December 29, 2018

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

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

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

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

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

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

    Refactoring Vision Code

    29 Dec 2018

    Refactoring Vision Code By Arjun

    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.

    OpenCV Support

    31 Dec 2018

    OpenCV Support By Arjun

    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);
        }
    }
    

    Teammember Statistics Update

    01 Jan 2019

    Teammember Statistics Update By Ethan

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

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

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

    As of today, our stats page displays this.

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

    And, the differences between each are below.

    Next Steps

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

    Off-Schedule Meeting Log, Winter Edition

    03 Jan 2019

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

    Meeting Log (Week of)January 03, 2019

    We have quite a few tasks this week, including:

    • Latch design

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

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

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

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

    • Fixing superman and wheels

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


      Karina putting weight on the robot

    • End\Beginning of year review

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

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

    Debug OpenCV Errors

    03 Jan 2019

    Debug OpenCV Errors By Arjun

    Task: Use black magic to fix errors in our code

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

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

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

    Next Steps

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

    Auto Paths

    04 Jan 2019

    Auto Paths By Abhi

    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.

    Modeling Slide Barriers

    04 Jan 2019

    Modeling Slide Barriers By Kenna

    Task: Create barriers to prevent the linear slide from falling

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

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

    Next Steps

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

    Meeting Log

    05 Jan 2019

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

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

    Today's Meet Log

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

    Issues with Driving

    05 Jan 2019

    Issues with Driving By Karina

    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.

    Latch Model

    06 Jan 2019

    Latch Model By Abhi and Justin

    Task: Model and print the Latch

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

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

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

    Next Steps

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

    Vision Summary

    06 Jan 2019

    Vision Summary By Arjun and Abhi

    Task: Reflect on our vision development

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

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

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

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

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

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

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

    Next Steps

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

    Minor Code Change

    11 Jan 2019

    Minor Code Change By Karina

    Task: Save Bigwheel from self destruction

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

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

    Next Steps

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

    Meeting Log

    12 Jan 2019

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

    Meeting Log January 12, 2019

    Today's Meet Objectives

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

    Presentation practice

    Today's Meet Log

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

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

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

    Today's Member Work Log

    Team MembersTaskStart TimeDuration
    CharlotteBlog2:004
    JanaviBuild2:004
    EthanBlog2:004
    Evan/td>Build2:004
    AbhiCode & Testing2:004
    ArjunCode & Testing2:004
    KarinaBuild & Testing2:004
    JustinModelling2:004
    KennaProofreading2:004

    Code Updates

    13 Jan 2019

    Code Updates By Abhi and Arjun

    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.

    Belt Drive

    14 Jan 2019

    Belt Drive By Evan and Karina

    Task: Install a belt lift on our robot for depositing

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

    Next Steps

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

    Designing Side Shields

    14 Jan 2019

    Designing Side Shields By Ethan

    Task: Create side shields for BigWheel

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

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

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

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

    Selective Intake

    17 Jan 2019

    Selective Intake By Evan

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

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

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

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

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

    Next Steps

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

    Pool Noodle Intake

    18 Jan 2019

    Pool Noodle Intake By Evan

    Task: Design a quick intake for the robot before competition

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

    Next Steps

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

    Wylie East Qualifier 2019

    19 Jan 2019

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

    Task: Compete at Wylie East

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

    Judging

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

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

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

    Inspection

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

    Robot Game

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

    Match 1

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

    Match 2

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

    Match 3

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

    Match 4

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

    Match 5

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

    After Judging and Awards

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

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

    Next Steps

    See post-mortem.

    Competition Day Code

    19 Jan 2019

    Competition Day Code By Abhi and Arjun

    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.

    Tokens!

    23 Jan 2019

    Tokens! By Ethan

    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!

    Three SEM Robotics Teams have now advanced to the FTC North Texas Regional Championship!

    26 Jan 2019

    Three SEM Robotics Teams have now advanced to the FTC North Texas Regional Championship! By Ethan

    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

    26 Jan 2019

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

    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

    Team MembersTaskStart TimeDuration
    AllPlanning Meeting2:10pm.25
    CharlotteTask2:004
    KennaTask2:004
    JanaviTask2:004
    EthanTask2:004
    AbhiTask2:004
    ArjunTask2:004
    JustinTask2:004

    Wylie East Postmortem

    26 Jan 2019

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

    Task: Analyze what went wrong at Wylie

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

    Problems:

    The Robot & Code

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

    Preparation, Presenation & Judging

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

    Pit Conduct & Misc

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

    Latch Updates

    26 Jan 2019

    Latch Updates By Justin, Abhi, and Ben

    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

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

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

    Road to Regionals

    27 Jan 2019

    Road to Regionals By Ethan

    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

     

    Superman Calculations

    28 Jan 2019

    Superman Calculations By Ethan

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

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

    Superman Arm

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

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

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

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

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

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

    Gearkeepers

    29 Jan 2019

    Gearkeepers By Jose and Evan

    Task: Create and install gearkeepers to reduce slippage

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

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

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

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

    Next Steps

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

    Intake Omnis

    29 Jan 2019

    Intake Omnis By Ben

    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.
    Both of these present a similar challenge, leaving enough room for the intake to function properly. With about 2.5in. to work with, we mounted the wheel perpendicular with a 1.75 in. extrusion. We threaded the extrusion and used an elbow bracket to mount the wheel; this ensures the strength of the wheel. This left about 0.5in. between the wheel and the "corn on the cob" intake.

    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.

    Mechanical Depositing

    01 Feb 2019

    Mechanical Depositing By Evan

    Task: Create a mechanical deposit for our selective deposit

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

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

    Next Steps

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

    STEM Expo Preparation

    01 Feb 2019

    STEM Expo Preparation By Bhanaviya and Benb

    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.

    Latch V.3.5 Assembly

    01 Feb 2019

    Latch V.3.5 Assembly By Ben

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

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

    Latch attached to polycarbonate brackets.

    Next Steps

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

    Fixing Mineral Dropper Components

    02 Feb 2019

    Fixing Mineral Dropper Components By Jose and Evan

    Task: Fix any issues with the mineral dropper

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

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

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

    Next Steps

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

    Meeting Log

    02 Feb 2019

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

    Meeting Log February 02, 2019

    Bhanaviya working on the blog

    Today's Meet Objectives

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

    Today's Meet Log

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

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

    Today's Work Log

    Team MembersTaskStart TimeDuration
    CharlotteTask4:004
    KennaTask4:004
    EthanTask4:004
    BhanaviyaTask4:004
    BenTask4:004
    JoseTask4:004
    EvanTask4:004
    JanaviTask4:004

    DISD STEM Expo

    02 Feb 2019

    DISD STEM Expo By Bhanaviya, Ethan, Charlotte, Janavi, Evan, Abhi, Arjun, Kenna, Justin, Karina, Ben B, and Jose

    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.

    Code Updates

    02 Feb 2019

    Code Updates By Abhi

    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.

    Drive Testing at STEM Expo

    02 Feb 2019

    Drive Testing at STEM Expo By Ben and Abhi

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

    An FLL team gathered around Iron Reign’s robot

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

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

    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.

    Latch 2.0 - Forged in Flame

    06 Feb 2019

    Latch 2.0 - Forged in Flame By Evan

    Task: Design a new latch for hanging

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

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

    Meeting Log

    09 Feb 2019

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

    Today's Meet Objectives

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

    Today's Meet Log

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

      Fire from the forge from crafting the hook

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

    Woodrow Wilson Scrimmage

    09 Feb 2019

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

    Task: Compete at the Woodrow Wilson Scrimmage with Woodrow teams

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

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

    Next Steps

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

    Autonomous Non-Blocking State Machines

    09 Feb 2019

    Autonomous Non-Blocking State Machines By Arjun

    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();
    

    Bigwheel Model

    10 Feb 2019

    Bigwheel Model By Justin

    Task: Design and update the Bigwheel Model

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

    Completed Changes

  • Added current intake
  • Added sorting system
  • Modeled the linear slide lift
  • Modeled superman arm
  • Future Changes

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

    Next Steps

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

    BigWheel Upgrades

    10 Feb 2019

    BigWheel Upgrades By Evan

    Task: Fix some issues on BigWheel before the build freeze

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

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

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

    Next Steps

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

    Pulley Spacers

    13 Feb 2019

    Pulley Spacers By Ethan

    Task: Design and implement pulley spacers to prevent belt interference

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

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

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

    Next Steps

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

    Control Mapping

    14 Feb 2019

    Control Mapping By Bhanaviya, Abhi, Ben, and Karina

    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

    We plan to revisit the robot's balancing issue in the next meet and find the accurate presets to fix the problem.

    Robot Issues - Gear Grinding

    14 Feb 2019

    Robot Issues - Gear Grinding By Ethan

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

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

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

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

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

    Next Steps

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

    Research Poster

    15 Feb 2019

    Research Poster By Janavi and Ethan

    Task:Create a Poster amalgamating all of our math

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

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

    Elbow Rebuild

    16 Feb 2019

    Elbow Rebuild By Ethan, Jose, Karina, and Ben

    Task: Rebuild the elbow after total gear annihilation

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

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

    Next Steps

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

    Meeting Log

    16 Feb 2019

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

    Meeting Log February 16, 2019

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

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

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

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

    Today's Work Log

    Team MembersTaskStart TimeDuration
    AllPlanning Meeting2:10pm.25
    EthanEdit blog posts and update posters2:004
    EthanFix robot gears12:002
    Justin3D Model2:004
    BhanaviyaComputer Setup2:001
    KennaDesign handouts2:004
    JanaviBlog posts2:004
    BenReplace gears2:004
    AbhiRobot tuning2:004
    ArjunControl Award2:004

    Latch Designs - A Retrospective

    19 Feb 2019

    Latch Designs - A Retrospective By Ethan

    Task: Analyze past successes and failures in our latching system

    Version 1

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

    Version 2

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

    Version 3

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

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

    Version 4 - the Hook

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

    Off-Schedule Meeting Log - Week before Regionals

    19 Feb 2019

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

    Meeting Log February 19, 2019

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

    Monday

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

    Editorial Review Listing

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

    Big Wheel Articulations

    20 Feb 2019

    Big Wheel Articulations By Abhi

    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.

    Cart Hack

    20 Feb 2019

    Cart Hack By Arjun

    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.

    Up-to-Date Bigwheel Model

    21 Feb 2019

    Up-to-Date Bigwheel Model By Justin

    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 connect gamepads directly to RC phone without a DS phone

    21 Feb 2019

    How to connect gamepads directly to RC phone without a DS phone By Arjun

    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!

    Wylie Regionals 2019

    23 Feb 2019

    Wylie Regionals 2019 By Ethan, Charlotte, Evan, Kenna, Karina, Abhi, Arjun, Bhanaviya, Ben, Justin, Jose, and Janavi

    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)
    For the first time in the Rover Ruckus season, we won a game. Both us and Corem Deo had almost perfect auto and Corem Deo got plenty of mineral cycles into the lander. Unfortunately, BigWheel tipped over during end game so we couldn't latch. However it did not affect the match results significantly.

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

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

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

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

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

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

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

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

    Awards Ceremony

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

    Next Steps

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

    SEM FTC Robotics advances to State and Worlds Championships

    24 Feb 2019

    SEM FTC Robotics advances to State and Worlds Championships By Ethan

    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

    02 Mar 2019

    Meeting Log March 02, 2019 By Charlotte, Ethan, Evan, Justin, Karina, Janavi, Jose, Ben, Abhi, and Bhanaviya

    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.
    Team MembersTaskStart TimeDuration
    AllOrganization and Planning2:00pm.33
    AllPost-mortem & Road to Worlds2:20pm3.66

    North Texas Regional Postmortem

    02 Mar 2019

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

    Task: Analyze what went wrong at North Texas Regionals

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

    Problems:

    The Robot & Code

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

    Pit Interviews

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

    Pre-tournament Preparation

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

    Pit Setup & Conduct

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

    Road to Worlds Document

    02 Mar 2019

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

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

    ROAD TO WORLDS - What we need to do

     

    OVERALL:

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

     

    ENGINEERING JOURNAL: - Charlotte, Ethan, & all freshmen

     

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

     

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

    Page numbers [Ethan][Done]

        • Awards on indexPrintable [Ethan][Done]
      • Irrelevant/distracting content
        • Packing list
        • Need a miscellaneous section
          • content
      • Details and dimensions
        • Could you build robot with our journal?
        • 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

     

    Code Refactor

    08 Mar 2019

    Code Refactor By Abhi and Arjun

    Task: Code cleanup and season analysis

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

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

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

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

    Next Steps

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

    Issues with Driving

    08 Mar 2019

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

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

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

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

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

    Next Steps

    Next, we will work building the worlds robot.

    Off-Schedule Meeting Log - Spring Break

    08 Mar 2019

    Off-Schedule Meeting Log - Spring Break March 08, 2019 By Charlotte, Cooper, Karina, Bhanaviya, BenO, Abhi, Janavi, Jose, Aaron, and Arjun

    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

    09 Mar 2019

    Localization By Ben

    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.

    DPRG Visit 2.0

    10 Mar 2019

    DPRG Visit 2.0 By Abhi, Karina, Arjun, and BenO

    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.

    Planning Sessions

    10 Mar 2019

    Planning Sessions By Charlotte

    Task: Outline new planning sessions

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

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

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

    VEX 393 Motor Testing

    13 Mar 2019

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

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

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

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

    Next Steps

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

    Balancing Robot

    15 Mar 2019

    Balancing Robot By Abhi and Ben

    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.

    FIRST in Texas Grant

    16 Mar 2019

    FIRST in Texas Grant By Ethan

    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

    16 Mar 2019

    Meeting Log March 16, 2019 By Charlotte, Janavi, Aaron, Ethan, Justin, Bhanaviya, Beno, Abhi, and Karina

    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

    Team MembersTaskStart TimeDuration
    AllPlanning Meeting2:10pm.25
    AbhiPID tuning and articulations2:004
    Ben OPID tuning and articulations2:004
    EthanCutaways of BigWheel model2:004
    AaronSubsystem assemblies for new robot2:004
    CharlottePlanning and blog2:004
    BhanaviyaBill of materials2:004
    KarinaBill of Materials and intake analysis2:004
    JanaviBlog2:004
    JustinPolycarb base measurements and cut2:004

    Balancing Robot Updates

    16 Mar 2019

    Balancing Robot Updates By Abhi and Ben

    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.

    New Robot Base - Icarus

    19 Mar 2019

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

    Task: Build the base for the new robot

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

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

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

    Next Steps

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

    Finishing Icarus' Base

    20 Mar 2019

    Finishing Icarus' Base By Evan, Aaron, and Ethan

    Task: Perform the final steps to complete Icarus' base

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

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

    Next Steps

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

    Meeting Log

    20 Mar 2019

    Meeting Log March 20, 2019 By Bhanaviya, Karina, Evan, and Justin

    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

    < tr>
    Team Members Task Start Time DurationAll Planning Meeting 5:15 .15
    Karina Drilling REV rails and base layout 5:30 3
    Evan Drilling REV rails and base layout 5:30 3
    Justin Create new corner pieces 5:30 3
    Bhanaviya Replace gear sprockets and Meeting Log 5:30 3

    Meeting Log

    22 Mar 2019

    Meeting Log March 22, 2019 By Bhanaviya, Janavi, Abhi, Arjun, Ben O, Paul, Ben B, and Cooper

    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

    Team Members Task Start Time Duration
    All Planning Meeting 5:15 .15
    Janavi Calculate torque for new design 5:30 3
    Bhanaviya Meeting Log 5:30 3
    Abhi Improve articulations 5:30 3
    Arjun Improve articulations 5:30 3
    Ben O Improve articulations 5:30 3
    Cooper Create new axle-holders 5:30 3
    Ben B Create new axle-holders 5:30 3
    Paul Create mini-mech reveal video 5:30 3

    Bill of Materials

    23 Mar 2019

    Bill of Materials By Bhanaviya and Karina

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

    To determine all the materials we need for the new robot, Karina and I started a Bill of Materials. To do this, we first analyzed Big Wheel sub-system by sub-system. We determined the parts used for each sub-system and placed it into a spreadsheet. Upon doing this, we needed to get each part's exact measurements so that we could save time when trying to cut the new parts. Additionally, we needed the quantity of each part as well as which manufacturer it was from. This was critical because at the end of the day, the task was to build a better version of Big Wheel but using, more or less, the same parts.

    Intake Speed

    23 Mar 2019

    Intake Speed By Karina

    Task: Analyze efficiency of our intake system

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

    Silver Minerals
    TrialΔt (s)
    10.733
    20.466
    31.233
    41.934
    50.766
    60.634
    70.600
    80.466
    92.133
    100.700
    Gold Minerals
    TrialΔt (s)
    10.234
    20.532
    30.300
    40.533
    50.533
    60.300
    71.433
    80.567
    90.800
    100.433

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

    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

    23 Mar 2019

    Meeting Log March 23, 2019 By Charlotte, Ethan, Bhanaviya, Karina, Jose, Justin, BenB, BenO, Arjun, Cooper, Paul, Abhi, Janavi, and Aaron

    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

    Team MembersTaskStart TimeDuration
    AllPlanning Meeting2:10pm.25
    NameTask2:004

    New Elbow

    23 Mar 2019

    New Elbow By Justin

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

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

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

    Next Steps

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

    Updated Meetinglog Template

    23 Mar 2019

    Updated Meetinglog Template By Charlotte

    Task: Update the meetinglog template to more accurately reflect efforts

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

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

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

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

    Constructing Icarus' Elbow

    24 Mar 2019

    Constructing Icarus' Elbow By Evan, Aaron, and Ethan

    Task: Build the elbow for intake

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

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

    Next Steps

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

    Icarus' Superman Arm

    25 Mar 2019

    Icarus' Superman Arm By Evan, Aaron, and Ethan

    Task: Design and install a lifting arm for Icarus

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

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

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

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

    Next Steps

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

    Meeting Log

    28 Mar 2019

    Meeting Log March 28, 2019 By Cooper and Evan

    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

    Icarus Code Support

    29 Mar 2019

    Icarus Code Support By Abhi

    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.

    Reverse Articulations

    29 Mar 2019

    Reverse Articulations By Abhi

    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.

    Center of Gravity calculations

    30 Mar 2019

    Center of Gravity calculations By Arjun

    Task: Determine equations to find robot Center of Gravity

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

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

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

    Next Steps

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

    Icarus' Arms

    31 Mar 2019

    Icarus' Arms By Evan, Aaron, and Ethan

    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.

    Connecting the Hook to a Servo

    01 Apr 2019

    Connecting the Hook to a Servo By Karina

    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.

    Project Management Mentorship

    01 Apr 2019

    Project Management Mentorship By Charlotte

    Task: Ensure skills are passed to underclassmen

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

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

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

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

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

    Wiring Icarus

    01 Apr 2019

    Wiring Icarus By Jose, Abhi, Evan, and Aaron

    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.

    MXP Expansion

    02 Apr 2019

    MXP Expansion By Ethan

    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.

    Intake Flappers

    04 Apr 2019

    Intake Flappers By Jose, Evan, and Abhi

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

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

    Next Steps

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

    UIL 2019

    06 Apr 2019

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

    Task: Compete at the Texas State Championship

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

    Judging and Awards

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

    Talking to BAE Systems

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

    Code/Robot/Robot Game

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

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

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

    Next Steps

    These will be detailed in the UIL post-mortem.

    Assisting Mechanicats with Code

    06 Apr 2019

    Assisting Mechanicats with Code By Arjun

    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.

    Code updates at UIL

    06 Apr 2019

    Code updates at UIL By Arjun, Abhi, and Ben O

    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.

    UIL 2019 Postmortem

    07 Apr 2019

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

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

    Pit & Packing & Roles

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

    Robot & Game

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

    Code

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

    New Superman Arm

    07 Apr 2019

    New Superman Arm By Ethan and Evan

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

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

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

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

    Next Steps

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

    Intake Update

    08 Apr 2019

    Intake Update By Ethan

    Task: Custom design an intake to improve intake times

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

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

    Next Steps

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

    Machining Gears for Superman

    08 Apr 2019

    Machining Gears for Superman By Ethan and Justin

    Task: Machine replacement gears for Superman

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

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

    Next Steps

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

    Ninja Flex Intake V2

    09 Apr 2019

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

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

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

    Next Steps

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

    Final Gantt Chart

    10 Apr 2019

    Final Gantt Chart By think

    Task: Update the Gantt Chart

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

    See finished Gantt chart at front of notebook in pocket.

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

    Control Hub First Impressions

    10 Apr 2019

    Control Hub First Impressions By Arjun and Abhi

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

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

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

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

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

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

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

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

    Next Steps

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

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

    Auto Paths, Updated

    12 Apr 2019

    Auto Paths, Updated By Abhi

    Task: Reflect and develop auto paths

    It has been a very long time since we have reconsidered our auto paths. Between my last post and now, we have made numerous changes to both the hardware and the articulations. As a result, we should rethink the paths we used and optimize them for scoring. After testing multiple paths and observing other teams, I identified 3 auto paths we will try to perfect for championships.

    These two paths represent crater side auto. Earlier in the season, I drew one of the paths to do double sampling. However, because of the time necessary for our delatch sequence, I determined we simply don't have the time necessary to double sample. The left path above is a safe auto path that we had tested many times and used at UIL. However, it doesn't allow us to score the sampled mineral into the lander which would give us 5 extra points during auto. That's why we created a theoretical path seen on the right side that would deposit the team marker before sampling. This allows us to score the sampling mineral rather than just pushing it.

    This is the depot path I was thinking about. Though it looks very similar to the past auto path, there are some notable differences. After the robot delatches from the lander, the lift will simply extend into the depot rather than driving into it. This allows us to extend back and pick up the sampling mineral and score it. Then the robot can turn to the crater and park.

    Next Steps

    One of the crater paths is already coded. Our first priority is to get the depot auto functional for worlds. If we have time still remaining, we can try to do the second crater path.

    Meeting Log

    13 Apr 2019

    Meeting Log April 13, 2019 By Bhanaviya, Ethan, Janavi, Evan, Karina, Justin, Abhi, Jose, BenO, BenB, and Arjun

    Meeting Log April 13, 2019

    Compete at the REV Scrimmage and do final changes on our robot in build and code before Worlds.

    Today's Work Log

    picture of agenda
    • Change code presets
    • The code team worked on changing the presets for the hook-servo and the Superman arm to ensure that the hook was low enough to latch and so that superman is low enough to deposit minerals in the lander accurately. They also lowered the range of the intake so that our intake system can pick up more minerals without causing the robot to collapse from the pressure caused by the intake.

    • Get range of servos and lower the elbow shaft
    • The build team lowered the elbow shaft so that it was at the right level to latch and so that it was parallel to the mounting bar. They also used the servo tester to get the range of servos on the hook to ensure that the hook was able to latch on accurately. They also lowered the elbow shaft so that it was at the right level to latch and so that it was parallel to the mounting bar. They also used the servo tester to get the range of servos on the hook to ensure that the hook was able to latch on accurately. Subsequently, they attached the control hub in the place of the REV expansion hub and the phones.

    • Create a business card
    • Finally, we created a template for a new business card. It will be unvealed at Worlds.

    Today's Work Log

    Team MembersTaskStart TimeDuration
    AllPlanning Meeting2:10.10
    EthanBusiness Card2:002
    JanaviBusiness Card2:002
    EvanLower elbow shaft & Attach Control Hub2:002
    KarinaLower Elbow Shaft & Servo Range2:002
    JustinLower Elbow Shaft & Attach Control Hub 2:002
    AbhiCode Presets2:002
    JoseLower Ekbow Shaft & Attach Control Hub2:002
    Ben OCode Presets2:002
    Ben BLower Elbow Shaft & Servo Range2:002
    ArjunCode Presets2:002
    BhanaviyaLog & Business Card2:002

    REV Beta Test

    13 Apr 2019

    REV Beta Test By Bhanaviya, Ethan, Karina, Justin, Arjun, Jose, Benb, Janavi, Evan, Aaron, Abhi, and Beno

    Task: Test the new REV Control Hub at the REV Scrimmage

    Founders of REV working with our team

    REV recently updated the control hubs they've been providing to FIRST Global for the last two years. They are hoping to get them listed as an option for FTC teams next year and so they wanted to test them with a variety of teams. This latest version has a USB-C connector and some internal component improvements. These control hubs take the place of the REV Expansion Hub + Android Phone combo because they effectively have a quad core android device inside. This should make USB disconnects a thing of the past, though teams using machine vision will need to use an external webcam and that will still require good cable management. All the North Texas teams invited to the beta test were also invited to a scrimmage to drive their Rover Ruckus robots with the control hubs instead of phones.

    We had some initial setbacks due to pre-manufacturing issues with the beta unit we were sent. The control board was set to the wrong address and couldn't be used. Once we got it replaced, the primary robot functions worked well. The only exception was vision. Because we lost so much time we didn't quite finish our OpenCV integration so we couldn't test our mineral sampling vision pipeline. Unfortunately we had to turn in the beta unit at the end of the event so we couldn't profile its vision performance. We plan to do so when we get the newest control hubs in May or June. Despite the setbacks, we found that overall, the control hub made robot control more efficient. The driver control was pretty similar to that of the phones and expansion hubs, but it saved us time in trying to ensure that both the phones and expansion hubs worked. We enjoyed the experience of using control hubs, and we hope to use them next season if they are allowed.

    We are incredible grateful to REV for giving us the opportunity to test of the new control hubs as well as interact with other NTX teams before Worlds. This chance to test the control hub was not only a good opportunity to test the potential of our robot with new technology, but it also gave us the much-needed chance to drive-test in a match with other teams before Worlds.

    Project Management Post-Mortem

    15 Apr 2019

    Project Management Post-Mortem By Charlotte

    Task: Evaluate the Project Manager position

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

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

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

    Worlds Day 1

    18 Apr 2019

    Worlds Day 1 By Jose, Ethan, Charlotte, Janavi, Abhi, Evan, Karina, Justin, BenB, Bhanaviya, Cooper, Aaron, Arjun, and Paul

    Task: Set up our Worlds pit, complete inspection and judging, and compete in robot game matches

    Presentation

    Our presentation went well. We were able to get all of our information across effectively in a shorter amount of time as usual, but this led to more time for questions , which the judges had a lot of. Throughout questioning, we were able to hand off questions so that no individual member dominated the questioning time.

    One problem we had with the presentation was that the rooms were constructed within the competition hall with fabric, just like last year. This made it so that sound did not carry very well within the rooms, and that sound could carry over from other rooms, so the judges had difficulty hearing us at some points which was especially worse when we spoke too quickly. Despite this, we're confident that the majority of the information came across.

    Match 1(Q12)

    We lost 290-95. Our poor planning led to the drive team having phones with low batteries and being unable to play in the match and Rhoming Robots were unable to carry us in this 2v1 match.

    Worlds Day 2

    19 Apr 2019

    Worlds Day 2 By Jose, Ethan, Charlotte, Janavi, Abhi, Evan, Karina, Justin, BenB, Bhanaviya, Cooper, Aaron, Arjun, and Paul

    Task: Compete in more qualification matches

    Match 2(Q28)

    We lost 340-280. We had a flawless auto this time and followed with 9 far crater cycles and a latch. During the first cycle 3 gold minerals were scores at once with resulted in a 50 point penalty. If we had better visibility of the mineral tray this would have been avoided and the win margin would only have been 10 points.

    Match 3(Q52)

    We lost 322-242. Once again we had a complete auto including scoring the sampling mineral. This was followed by 6 far crater cycles but an attempt for a 7th cycle during end game resulted in a tip over for Icarus and neither us nor Masquerade could hang. If both robots would have hung we would have won by a small margin.

    Match 4(Q67)

    We lost 335-217. Due to technical issues Icarus was forced to be hung for about five minutes and this burnt out both elbow motors. This resulted in no autonomous and only about two cycles. We also had no hang and had to park in the crater. If we were allowed to delatch Icarus while the issues were being resolved we would have won by a large margin.

    Match 5(Q84)

    We lost 272-211. In between matches we were able to buy and replace the elbow motors but they had encoder issues which could not be resolved in time, this meant we had to run on only one elbow motor for this match. With this we were able to have a complete auto and 7 near crater cycles. There was no hang this time so we went for the crater instead. If we had both elbow motors functional we could have scored a few more cycles and hung which would have won us the match by a thin margin.

    Match 6(Q104)

    We [finally] won 315-160. At this point we still haven't fixed the encoder issue but we still pulled off a semi-complete auto since the team marker was not dropped and the sampling mineral was not moved enough to count. The cycles this time were mostly unsuccessful but we hung and Batteries Not Included had enough cycles to compensate and we managed to finally win a match.

    In between matches we took a trip with CartBot to the FLL pits to attract anyone interested in the next stage of FIRST(FTC). We told them they could come by our pit at any time for a in-depth presentation of our robot and about an hour later an FLL team, the Engigears, came to visit our pit. We were able to show them how complex FTC can get and showed them Icarus' capabilities and let some of them drive it around. They had a great experience and we hope they are now informed of FTC and pursue it come 7th grade.

    Worlds Day 3

    20 Apr 2019

    Worlds Day 3 By Jose, Ethan, Charlotte, Abhi, Evan, Karina, Justin, BenB, Bhanaviya, Cooper, Aaron, Arjun, and Paul

    Task: Compete in even more qualification matches

    Match 7(Q121)

    We won 292-280. With the elbow motors fixed we were ready for this match. We had a full auto and 5 successful but hang was not successful and we had to go for the crater again.

    Match 8(Q159)

    We won 240-185. Just as normal we had a complete auto but we were blocked from the crater by Tech Hogs(opponent). Once Tele-op started Icarus was tipped over after bumping into Tech Hogs. Although Icarus is designed to recover from any tip over, a sideways tip is nearly impossible to recover from, however Icarus' chassis was on the crater edge and after about 30 seconds of suspense Icarus recovered and received lots of cheering from the crowd. After this however we got tipped over again by Tech Hogs(whether it was intentional or accidental is yet to decided) and there was no crater edge to save us this time. Despite this RoboEclipse was able to carry the alliance to victory.

    Match 9(Q172)

    We won 370-108. We again had a full auto this time with a deposit of the sampling mineral. we had 6 successful far crater cycles but on the 7th the deposit articulation on Icarus was initiated too early and it tipped over and 20 seconds was not enough time to recover and hang. Even so, the lead we had was good enough to win us the match.

    Worlds Day 4

    21 Apr 2019

    Worlds Day 4 By Jose, Bhanaviya, BenB, Aaron, Cooper, Paul, Arjun, Justin, Karina, Ethan, Evan, Charlotte, and Abhi

    Task: Participate in Alliance Selection and attend the Award Ceremony

    Today was the last of the 2019 FTC World Championship and our first task of the day was to ask top-seeded teams if they thought we would be a good asset to their alliance for the play offs. We intrigued a few with our higher-than-average depot-side cycle time and hoped for the best during alliance selection. Unfortunately our 55th position probably made the alliance captains think again about who to pick.

    A while later followed the award ceremony, we went in with high hopes as we have received many pit interviews throughout the week. Our hopes came true as we heard "the finalists for the Collins Aerospace Innovate Award are ... ... team 6832". The whole team burst into happiness and joy as our unique robot design was recognized at the World Championship. We were finalists for the Innovate Award!

    Discover Summer Fair

    27 Apr 2019

    Discover Summer Fair By Bhanaviya, Ethan, Karina, and Jose

    Task: Teach kids how to program and 3D-model at the Discover Summer Fair

    Students drive-test their newly-programmed LEGO robots

    This Saturday was the Discover Summer Fair organized by the Dallas City of Learning. This was our very first Mobile Tech Xperience (MXP) event to kick off the start of our outreach efforts for the Skystone season. For background, the MXP is a robotics classroom on wheels that our robotics team uses to take to underserved areas around the Dallas region to teach the students we meet there about STEM and robotics. The vehicle is an old 90's RV that our team renovated around 3 summers ago and since then, the vehicle has been maintained by Big Thought, an educational non-profit organization who operates a program called Dallas City of Learning - the vendor for several of our outreach events. During today's event, we had a large turnout of about 500 participants for both the 3D printing station and the sumo robots programming challenge. The purpose of this event was for our team to introduce robotics-based activities like programming FLL robots and 3D-modelling keychains to students in the greater Dallas area who would have otherwise had no access to such activities.

    We started out by setting up the MXP and the EV3 LEGO Mindstorm robots. After ensuring that the MXP was stocked up with laptops and 3D printers, we set up sumo mats, laptops, and LEGO Mindstorms robots in tables outside the vehicle. We wanted to kick-off the first outreach event of the season by demoing our competition robot from the world championship, Icarus, so we had to make sure that Icarus was able to both balance and drive around.

    Between the four of us, there were so many participants that we had made the decision to teach them as a group to maximize efficiency. Making every step of the teaching process - whether it's block-programming a robot or modelling a keychain - as interactive and engaging as possible allowed us to easily communicate with large groups of participants.

    Next Steps

    Our station could not have run as smoothly as it did without the help of Big Thought for helping us staff and maintain the MXP, and for allowing us to introduce FIRST to so many young participants by giving us a booth at the fair. 3D-modelling and programming are, at the end of day, two important concepts encompassed within FIRST. Watching students who had little to no experience with robotics marvel at their keychain designs and their robots coming to life allowed us to see firsthand the impact we were hoping to make with our MXP events - to teach kids of all ages and all backgrounds that robotics was for everyone.

    DPRG RoboRama Prep

    10 May 2019

    DPRG RoboRama Prep By Jose and Paul

    Task: Prepare for the DPRG RoboRama Competition

    Tomorrow Iron Reign is to send out a team of two people to compete at the annual Dallas Personal Robotics Group (DPRG) RoboRama as well as demo Icarus, our competition robot. Our robot, fittingly name Iron Core(as homage to one of the freshmen teams in our robotics program), is to compete at the sumo wrestling portion of the competition.

    For reference, Dallas Personal Robotics Group is a Dallas-based robotics organization that holds mini robotics competitions, talks on the development of personal robotics, and has, on more than one occasion, given our team the opportunity to present to them about computer vision, and FIRST Tech Challenge in general.

    To prepare for the competition, we used an existing Lego EV3 sumo bot that we use for our outreach and Mobile Tech Xperience (MXP) events and modified it with a 3D printed plow. As for code, we took the existing program of going forward and turning and going backwards after detecting the edge of the ring. We modified this code by adding a sensor to detect nearby robot by spinning until they are found, once located Iron Core will go full force towards the target in hopes of winning.

    We also prepared Icarus for demonstration by tuning it as it has taken some damage from our previous competition. Some minor repairs were required but after just a few minutes Icarus was up and running again.

    Next Steps

    DPRG RoboRama Competition

    11 May 2019

    DPRG RoboRama Competition By Jose and Paul

    Task: Compete at the DPRG RoboRama and present Icarus

    Ready and prepared, our two man team came to compete at the Annual Dallas Personal Robotics Group's RoboRama.

    The first event was the sumo wrestling event, it featured a double elimination bracket and five teams total came to compete. In our first match we won, our robot seeking program served us well and eliminated the opposing robot on the first try. Unfortunately, we lost our second match after a long, agonizing battle the opposing robot had more torque than Iron Core and slowly pushed our pride and joy off the playing field. This 1-1 record scored us 3rd place for the event.

    Seeing the event, Quick Trip, a test for accurate movement over long distances, I(Jose) programmed a path for it during lunch. With no time to use a gyro sensor, the path was inaccurate, but this could be fixed with a specific starting position. We finished with a total of 4 points, placing us third.

    Along with competing we got to demo our competition robot for FTC, Icarus, to anyone interested, this included DPRG members and Girl Scout Troop #7711b. We demonstrated its capabilities including the articulations, our FTC season as well as show off "tall mode" which is Icarus with the Superman wheel activated completely and the arms extended completely. Overall most were impressed and appreciated the opportunity to see a functional robot.

    Meeting Log

    08 Jun 2019

    Meeting Log June 08, 2019 By Bhanaviya, Jose, Paul, Aaron, Ben, Evan, Trey, and Justin

    Meeting Log June 08, 2019

    Task: Prepare for the 2019-2020 Skystone season

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

    Recruitment

    With most of our upperclassmen graduating, the SEM Robotics program needs more members. As the varsity team in our program, we will be responsible for spreading the word about out program in our school - The School of Science and Engineering. This includes making posters, finding a suitable room to host an interest meeting, and planning a presentation to explain the commitments that come with being a part of a FIRST Tech Challenge Team.

    Prototyping leg-drive

    Just like Relic Recovery, we suspect that this year's game will be a stacking game (especially considering the fact that the phrase 'Together we RISE' was stressed in the teaser that was shown at the World Championship last season). A stacking game requires a relatively tall robot (by robot standards anyway), and a tall robot means a leg drive. Leg drive is an idea we've joked around with but summer is also the best possible time to test any impractical ideas. So, Aaron, Trey, Justin and Evan experimented with the leg drive system by prototyping leg propulsion with polycarb "legs". The polycarb pieces were drilled to form a rectangular shape which would extend and contract to propel the drive forwards. After creating the polycarb structures, they implemented rev rails and gears to "rev up" the leg drive system. It's still a prototype for now but it could be implemented into a chassis soon to test if the leg drive system can actually be made into a functioning model.

    Experimenting with grippers

    A good stacking bot also needs reliable grippers. Given our team's track record for exploring multiple build ideas at once, we figured that the new season would have us testing and innovating a good number of gripper systems. Fittingly, Jose and Ben tried out two different kinds of gripper systems. Jose prototyped a parallel gripper bar system. He used polycarb pieces to create the prototype. Two smaller vertical pieces of polycarb were attached onto a horizontal, larger strip to create the parallel gripper system. Ben implemented a loop gripper system onto a small base chassis with 2 omnis and 2 REV wheels. The loop gripper operates when the REV motor spins the gear sprocket attached to a carbon-fibre rod which causes the ziptied-loop to expand and contract accordingly.

    3D-Modelling and CAD Design

    Paul modeled a standard REV for leg drive. This past season, we have used this kind of bracket repeatedly - as such we decided to model it in the case that we choose to incorporate it in our design for the upcoming season. In the case we do decide to experiment with multiple drive trains and gripper systems once the new challenge is revealed, having stock of 3D printed parts would allow us to test out multiple ideas even if we don't have the actual part with us.

    Next Steps

    We've designed 3 prototypes over the course of today's meet so this gives us plenty to test over the next upcoming meetings. However, we are participating in several outreach events over the next few weeks so finding time for testing will be tricky. But if our speculations for a stacking game are correct, we think our build season has gotten off to a good start so far.

    Meeting Log

    08 Jun 2019

    Meeting Log June 08, 2019 By Bhanaviya, Jose, Anisha, Paul, Shawn, Trey, Justin, Aaron, Ben, Mahesh, and Cooper

    Talking Heads: Summary June 08, 2019

    Task: Prepare for the 2020-2021 Game Reveal season

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

    Recruitment

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

    Outreach

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

    3D-Modelling and CAD Design

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

    Next Steps

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

    Leg Drive Prototype

    15 Jun 2019

    Leg Drive Prototype By Jose

    Task: Prototype a Leg Drive for next year's (possible) stacking game

    Although most teams go for a traditional chassis, a different type may be needed for next season as speculations suggest a stacking game. A leg drive would be an apt idea to test out for such a game For this chassis, two motors spin their respective "leg" attached to a gear. The point is move the robot using the rotation of the legs rather than wheels. To test, I coded the leg bot using the basic Linear Op-Mode program. There were issues with the motors disconnecting when hitting the ground as their wires physically disconnected. To solve this I took more REV extrusions and attached them perpendicular to the legs, adding space between the ground and the motor. Despite this the leg bot still proves to be unstable.

    Next Steps

    There is a chance we'll have to scrap the design and start with a different one. Leg drive is an interesting idea but actually working with it will probably not be feasible in the near future, especially if the game is a stacking game, since those rely on speed.

    Frontiers Of Flight Museum Outreach

    22 Jun 2019

    Frontiers Of Flight Museum Outreach By Paul, Bhanaviya, Ethan, Justin, Jose, Benb, Janavi, Evan, Aaron, Abhi, and Evan

    Task: Motivate children in STEM fields at the Frontiers of Flight museum

    Janavi teaching kids how to build EV3 Robots

    Iron Reign went out to the Frontiers of Flight museum to promote STEM and robotics. We brought the MXP, and parked it in the main hangar where it garnered much attention from guests. At this event we instructed young children on basic block programming, 3D CAD modeling and EV3 robotics. We interacted with over 300 participants in this event.

    We brought Icarus and Cartbot as a demo of our team's capabilities and to help inspire the children present at the museum. Getting Icarus to work ended up being a whole ordeal, as there were a slew of bugs that had to be ironed out. Cartbot was equipped with our air cannon, to the great amusement of the kids.

    Discovery Faire at the Frontiers of Flight Museum Prep

    06 Jul 2019

    Discovery Faire at the Frontiers of Flight Museum Prep By Jose

    Task: Prepare everything for the Discovery Faire next week

    I(Jose) fixed the battery box and charged the robot phones and batteries so that we could charge Icarus before next Saturday. Next week, Iron Reign is doing a demo of Icarus at the Frontiers of Flight Museum, which will be our largest MXP event. After charging the batteries, I drive-tested Icarus. While it is still functional, it can't balance as well as it did back in Houston. However, some last minute code on the day of the event should be able to solve that.

    Next Steps

    While Icarus is still functional, it can't balance as well as it did back in Houston. However, some last minute code on the day of the event should be able to solve that.

    Discovery Faire at Central Library

    13 Jul 2019

    Discovery Faire at Central Library By Trey, Jose, Bhanaviya, Ethan, Janavi, Charlotte, Evan, and Aaron

    Task: Teach students how to block program and 3D model at the Discovery Faire @ Central Library

    On July 13th Iron Reign attended the 5th annual Dallas City of Learning Discovery Faire at the Central Library. This was our third MXP event where the 250+ kids had access to our 3D printers, Lego EV3 sumo robots, and our four demo robots.

    We demoed 4 of our robots including Icarus, Cart Bot, Kraken, and Argos. Cart Bot was by far the most popular with its can cannon. There were always kids around it, even when we were ready to pack up. Although Icarus had an issue with the superman, we were still able to get it working and show its features to anyone interested as well as Kraken and Argos.

    Over all, the discovery Faire exposed kids to robotics and inspired parents to invest in their child's extra curricular education, furthering the growth of interest in STEM of the community and guaranteeing a future with these kids at the front line. 3D modeling and programming are essential to any FIRST robotics team and by showing them the basics they are likely to explore more about the subject.

    Our booth could not have operated as smoothly as it did without BigThought, for helping us staff and maintain the MXP, and for giving us the opportunity to introduce FIRST to such a large audience. We’d also like to thank Fox 4 Local News for helping publicize our event by taking pictures of the event in progress. We are incredibly thankful for having been able to interact with the next generation of engineers, and giving them a platform to be introduced to FIRST.

    Moonday

    20 Jul 2019

    Moonday By Paul, Abhi, Charlotte, Justin, Janavi, Jayesh, Aaron, Evan, Ethan, and Karina

    Task: Reach out to the community and present at Moonday

    Iron Reign went to the Frontiers of Flight Museum again with the DPRG to represent FIRST and SEM during their 50th anniversary celebration of the Apollo moon landings. This was our 4th year presenting at Moonday, and we interacted with over 300 students from as ages as young as 3 to 14. At this event, we helped to spread the message of FIRST and promote STEM. Cartbot and Icarus were present, as well as 10 members of Iron Reign. During this event, we taught students on how to block-program an FLL EV3 robot and 3D-model a keychain, two skills that are very relevant to both FLL and FTC. The event started at 8 AM at Love Field airfield, where the museum is located, and ended at around 2 in the afternoon. We interacted with many parents and students, talking about robotics, STEM, FTC and FIRST.

    During the event, we shared a booth with the Dallas Personal Robotics Group(or DPRG, for short!). For the past 5 years, our team has presented several of our robot designs and articulations with DPRG, and earlier this summer, we competed in a robotics competition organized by DPRG. As such, we were excited to work with them again. Members of DPRG and the participants at Moonday enjoyed watching our Rover Ruckus competition robot, Icarus, in action.

    The motorized air cannon mounted on Cartbot was also used to great effect, much to the amusement of the younger children. Cartbot itself was also used to great effect to help demonstrate our teams engineering capabilities; driving it around the venue was also admittedly very entertaining for both the drivers and the driven.

    As the summer is drawing to a close, we are thankful to both Big Thought and the Frontiers of Flight Museum for the opportunity to once again present our robots, and to educate the next generations of engineers on robotics. We look forward to returning to these events next season as well!

    SEM Nest Camp

    31 Jul 2019

    SEM Nest Camp By Bhanaviya, Jose, and Paul

    Task: Introduce incoming freshmen to our robotics program

    SEM Freshmen interacting with our team

    Iron Reign was given the opportunity by our school, The School for the Science and Engineering Magnet, to introduce and present our robotics program to the school's incoming batch of freshmen. This event allowed us to share our achievements this past season, talk about what it means to be a FIRST Tech Challenge team, and emphasize Iron Reign being a team for the past decade. Through this event, we were even able to get some hopeful recruits on our sign-up page! We were able to demo both Cart-Bot and Icarus during Nest Camp.

    We also use this event as a chance to introduce our MXP program. In each session, we met with about 20-30 freshmen and we divided these groups such that one would learn to program EV3 robots and the other would learn to 3D-model keychains on the MXP vehicle. Since these are the two main activities encompassed within our MXP events, showcasing them to the freshmen allowed us to talk about our outreach events and exemplify that Iron Reign as a team focused on both robot-game as well as educating our community about STEM and FIRST.

    This event also allowed us to create a connect opportunity. Individuals from Boeing attended and spoke with us at our sessions here which allowed them to see our team in action at an outreach event as well a chance for them to learn about the MXP and our work in bringing STEM to our communities.

    Next Steps

    We are thankful to SEM for giving us the opportunity to present ourselves and the ideals of FIRST Tech Challenge to the next batch of engineers in the Class of 2023. We enjoyed the chance to meet the future members of Iron Reign and look forward to working with them soon.

    Mayor’s Back to School Fair

    02 Aug 2019

    Mayor’s Back to School Fair By Bhanaviya, Jose, and Ethan

    Task: Educate students at the Mayor’s Back to School Fair on robotics

    Students learning to model keychains

    Iron Reign was given the opportunity to present the MXP and its activities at the Mayor’s Back to School Fair. During this event we met with around 260 participants from ages 4 to 12 and were able to teach them about block-programming LEGO EV3 robots and on 3D-modelling keychains. The purpose of this event was to spread STEM programs to students in areas of Dallas were a STEM education was not as prominent.

    This is our fifth year at this event, and it has been our busiest one this season. Alongside our traditional MXP events, we were able to launch cans using the CANnon (pun-intended) to cartbot. Considering the crowd we had at the event, and that the MXP could only hold 10 participants per session, a can-launching cannon allowed us to ensure that participants were able to stay engaged while they waited to board the vehicle.

    During the event, we also met with a representative from the Dallas Innovative Alliance (DIA), a non-profit dedicated to supporting the execution of building Dallas into a city that leaves a legacy of innovation and sustainability for future generations. The representative we spoke with mentioned that the DIA was looking to collaborate with programs dedicated to bringing forth STEM in their communities like the MXP program. As such, we look forward to any future possibilities for working with the DIA.

    Throughout the event, we met several students asked us how they could join a robotics team of their own. Being able to educate such a large group of participants on FIRST and robotics was a gratifying experience for our team and as such, we'd like to thank the City of Dallas for giving us this opportunity. Our fifth year being a part of the Mayor’s Back to School Fair could not have gone smoother, and we look forward to returning again the next summer.

    Letters to Congressional Representatives

    03 Aug 2019

    Letters to Congressional Representatives By Bhanaviya, Jose, and Ethan

    Task: Reach out to congressional representatives in our area to improve the implementation of STEM-based legislation

    This past year at the world championship, the founder of FIRST, Dean Kamen, emphasized how much of an influence reaching out to congressional representatives could have on furthering STEM in a community. Drawing inspiration from Kamen’s speech at Minute Maid Park, where the closing ceremonies were held, we reached out to three congressional representatives in our region - Eddie Bernice Johnson, Colin Allred, and Kenny Marchant. We wrote to them about FIRST, Iron Reign’s achievements and our MXP program dedicated to sharing the lessons we have learnt within robotics to the rest of our community. Specifically, we wrote about bills H.R. Building Blocks of STEM Act and the H.R. STEM Opportunities Act of 2019, and how we as a team could improve our outreach programs to help with the passage and implementation of these bills. Both bills are dedicated to promoting STEM education and careers, with the second one narrowed in on promoting the progress of underrepresented groups in STEM.

    As a robotics team in a STEM school, we know how much our education has impacted us in how we function within the team. In a city like Dallas, where economic and racial disparities are large enough that not everyone has access to the same education that we do, we wanted to build upon our existing efforts to improve communal access to a STEM education. If we receive a response back, we hope for an opportunity to discuss these bills with said representatives to see how Iron Reign could further contribute towards bringing STEM to our communities through our MXP program.

    Sustainability Goals

    17 Aug 2019

    Sustainability Goals By Bhanaviya

    Task: Plan to support at least 3 teams for the incoming Skystone season

    One of the biggest challenges we will face this upcoming season is the fact that 6 of our members graduated just a month ago. This leaves a team of 7 underclassmen and two upperclassmen - a pretty significant difference to last season when these numbers were reversed. Luckily, all of us have had at least one year of experience on being in the SEM robotics program so we know what skills we need to learn to pick up where our seniors left off. These schools include build, programming, CAD modelling and journal. Filling in those niches will be difficult, and adding to this challenge is that our program currently consists of 2 teams - us and our sister team, Imperial Robotics. We also to support at least one freshmen team, Iron Core Robotics, one of the freshman teams in our program from last season. The only difference is that last year, the freshman teams were occupied by us for the better part of our freshmen year. Part of adapting to the new season includes the need for us to step up and mentor any new members similar to how we were mentored when we first joined the program. In order to expand our program, we also plan to hold another recruitment meeting like last year and put up posters around our school. The goal isn't to make our program as large as possible but rather to recruit enough members to keep it sustainable even after we've graduated.

    Next Steps

    We will talk to prospective members from our school on joining the SEM robotics program. Although 6 is a pretty big number of members to lose to graduation, we don't have any immediate plans to take on new members just yet. Our main goal recruitment-wise will be on expanding the overall robotics program, us, Imperial Robotics, Iron Core, and a potential second freshmen team. In order to expand our program, we also plan to hold another recruitment meeting like last year and put up posters around our school. The goal isn't to make our program as large as possible but rather to recruit enough members to keep it sustainable even after we've graduated.

    Fixing Mini-Mech

    23 Aug 2019

    Fixing Mini-Mech By Cooper

    Task: Fix Mini-Mech in time for the Skystone reveal

    In two weeks, Iron Reign is planning on building a robot in 2 days, based on the 2019-2020 Skystone Reveal Video. We've never really built a robot in that short span of a time, so we realized that preparing a suitable chassis ahead of time will make the challenge a lot easier as it gives us time to focus on specific subsystems and code. As such, I worked on fixing up Mini Mech, as it is a possible candidate for our robot in a weekend, due to its small size and maneuverability. Mini-Mech was our 4-wheeled, mecanum-drive,summer chassis project from the Rover Ruckus season, and it has consistently served as a solid prototype to test the early stages of our build and code. I started by testing the drive motors, and then tightening them down, since were really loose.

    Then, I worked on adding a control hub to the chassis. Since Iron Reign was one of the teams who took part in REV's beta test for the control hubs last season, and because we are one of the pilot teams for the REV Control Hub in the North-Texas Region, using a control hub on our first robot of the season will help set us up for our first qualifier, during which we hope to use a control hub.

    Next Steps

    With MiniMech fixed, we now have at least one chassis design to build our Robot in 2 Days off of.

    Online Planning Session

    31 Aug 2019

    Online Planning Session By Cooper, Trey, Bhanaviya, Ben, and Jose

    Task: Brainstorm current and future plans on a google docs and try to switch to Trello

    Tonight we set out to organize our thoughts and projects by laying them out on paper. We started out by listing major topics like 'presentation' and 'build'. From there we filled in with more specific things. Overall we had about 6 sections with 5-6 tasks each. This meant that we could easily import the information to Trello- a business organizing online service that Iron Reign tried to use last year. It failed due to the fact that we used it later in the season, so we hope by starting to use it earlier in the season this year will help. Now that we are using Trello, we can have it open such that people can always know what needs to be done.

    One of the most notable things about the list is that we finally put down solidly which chassis ideas we will be working on, which is Frankendroid (our Robot in 2 Days robot), the unnamed big mecanum chassis, and most interesting a round robot. Iron Reign has a penchant for employing out-of-the-box ideas. So we went as far from the box as we could this season and have decided to build a circular chassis.

    Next Steps

    If we can pull it off, a circular robot will be a pretty interesting chassis design-wise. Such a chassis will require careful planning, so we will need to use Trello to evaluate our next steps which will include modelling the chassis and its dimensions first before beginning its actual build.

    RIP Big Wheel

    01 Sep 2019

    RIP Big Wheel By Paul, Aaron, and Trey

    Task: Tear down BigWheel and harvest parts

    Big Wheel, Iron Reign’s first iteration of our Worlds competition robot Icarus, had been sitting outside in the tent for months and we needed parts for new robots - specifically for our Robot in 2 Days robot. Once the season reveal is released, Iron Reign plans to build a working robot within the weekend of the release. The need for parts was a pressing concern, so it was time for us to part with one of our oldest friends, BigWheel (Icarus, our worlds robot, was off the table because of sentimental value). So we went ahead and scrapped Big Wheel, taking the most important, valuable parts off first, like the bearing slides and arms, then we moved onto the chassis. We worked to break the robot down into parts that we could use on other bots, for this year’s challenge.

    We were able to get a lot of very useful parts off of big wheel, as most of the parts used on big wheel are the same parts that were used on Icarus, and this years challenge makes heavy use of the vertical reach and collapsibility of Icarus, and it makes sense to assume that many of the parts that were used on Icarus will come in handy this year. We hope to implement some of these parts to our Robot in 2 Days robot once the season reveal video is released.

    2019-20 Recruitment

    04 Sep 2019

    2019-20 Recruitment By BenB, Jose, Bhanaviya, Paul, Cooper, Karina, and Trey

    Task: Recruit new members for the 2019-20 season

    Today we held an interest meeting at our campus - Townview Magnet Center. Over 30 people of varying grade levels attended this session, including returning members from Imperial Robotics, Iron Star and Iron Core. Last year Iron Reign lost 6 members to graduation, and since we plan to support two other sister teams in addition to our own, this meeting allowed us to meet potential members to fill in for the skill-sets we lost.

    During the meeting, we talked about what it means to be an FTC team, and the difference between FTC and other robotics programs. We also went over Iron Reign's history as a team, and the different levels of organization within an FTC team such as outreach, build, programming, engineering notebook and presentation. Other topics such as the various time commitment levels for each individual team were also discussed.

    Next Steps

    We plan to invite all interested members to our practices as well as the season kick-off this upcoming Saturday and assign them teams depending on their prior experiences and team preferences.

    FTC Skystone Kickoff

    07 Sep 2019

    FTC Skystone Kickoff By Karina, Bhanaviya, Aaron, Jose, Ben B, Trey, and Cooper

    Task: Attend the kickoff event

    Today Iron Reign attended the FTC 2019-2020 season kickoff event at Williams High School. Team members and prospective members alike turned up to witness the unveiling of this season's challenge. As per usual, we were disappointed by the lack of water in the game, especially considering the amount of water seen leading up to the actual game reveal. Jokes aside, we are excited to tackle the Skystone challenge. You can see the reveal video below:

    (Our robot from Rover Ruckus, Icarus, is featured in the video at 1:10!) There were some things we took away from the conversation prior to the game reveal. For one, we will definitely be using the REV control hub instead of an expansion hub this season, given our bad experiences with OTG cables disconnecting in the past. We also made note of the change in the way tie breaker points are added. The total will be averaged per match played, which will decrease the amount of jumping around teams do in the live rankings.

    We also made some (fairly obvious) strategy decisions, such as the fact that we will not be doing offensive play because we cannot risk the associated penalties. Instead, we will focus on our robot's speed. We also plan to model our capstone after the shape of the stones to make it easier for an alliance partner to stack. Lastly, we will have to move the foundation in the direction that the smaller face of the stones points to minimize the possibility of it falling while maximizing efficiency. We could stack the stones in an alternating pattern, but we would have fewer layers supporting the capstone which would cost us points.

    Part of the reason we needed to brainstorm strategy decisions quickly is because for the first time, Iron Reign is attempting the Robot in 2 Days Challenge. The Robot in 2 Days is usually a challenge taken up by long-standing veteran teams or alumni of those teams wherein they attempt to (and succeed!) at building a functional, coded robot in 2 days after the reveal. We don't think we will have a robot capable of performing all tele-op and autonomous tasks by the end of the weekend but the goal is to build a solid robot that can accomplish at least one tele-op game challenge.

    Next Steps

    Now that we know what kinds of tasks we're facing, we'll be moving forward into the discussion-and-prototyping phase of our Robot in 2 Days challenge. Of course, we'd like to thank REV for giving us a stone! Having at least one game element will make it easier for us to test our subsystems as we attempt to build a robot in a weekend.

    Modelling a Points System

    07 Sep 2019

    Modelling a Points System By Bhanaviya and Karina

    Task: Model a points system for the Skystone Challenge

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

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

    Next Steps

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

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

    07 Sep 2019

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

    Task: Prototyping a rolling gripper

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

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

    Next Steps

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

    Wheel Gripper

    07 Sep 2019

    Wheel Gripper By Jose and Trey

    Task: Design an intake for the stones based on wheels

    Initial Design: Rolling Intake

    The first idea we came up with for gripper designs during our Robot in 2 Days (Ri2D) challenge was a rolling intake with the wheels coming from the top and spinning to intake the stone. Since the wheels needed to spin they were placed on shafts which required two extrusions since the pillow bracket for them needs to be threaded on the ends of them to make this design compact.This design was rejected since we want to use the minimal amount of servos as possible and we came up with a more compact design that requires only one servo instead of two(one for each wheel).

    Final Design: Gripper Wheels

    This design involves two wheels attached to extrusions, one is idle and can't pivot while the other can be rotated in place by a servo. Once its grip was tested we saw that the wheels spinning was a problem. To fix this, the wheels where attached directly onto the extrusions this time and to enhance their grip, a rubber band was added to default the wheels' position as closed. A servo was added to the end of the main extrusion with a servo horn and polycarb beam to rotate the non-idle wheel back to release the stone in its grip. Finally, since drivers aren't perfect, a stabilizer made out of polycarb was placed in the middle of the gripper so it will always move towards the middle of the stones, in between the stubs. At first this was off by 90 degrees, but this was fixed shortly after.

    Next Steps

    We will have to implement this onto the Ri2D bot and run tests to compare this gripper against our others.

    Robot in Two Days - Day One

    07 Sep 2019

    Robot in Two Days - Day One By Karina, Bhanaviya, Aaron, Jose, Ben, Trey, Cooper, Sam, Sterling, Beau, Mahesh, and Shawn

    Task: Build prototype subsystems that pick up the stone elements

    This season Iron Reign decided to take on the robot-in-two-days challenge. Given that our team had never done this before, and we are primarily a team of underclassmen, we knew we would have to be organized in our efforts and that we would probably reuse old chassis.

    First thing right after the kickoff, the team convened back at our meeting spot to brainstorm ideas for robot designs which you can see above. Among the ideas we discussed was a "cupbot" of sorts, a lot like the designs seen for last years' challenge, except it would be shaped after the tops of the stones. This idea didn't pan out, however, because it would only be able to pick up the stones in the upright orientation, which is not something we can count on. We also had a sub-team prototype a parallel gripper, but it was an unsuccessful build in that it could not actually pick up stones. We did proceed further into the building phase with two designs for a gripper system: a rack-and-pinion gripper and a rolling gripper. One sub-team started on the rack-and-pinion gripper project, while another sub-team started on the rolling gripper project, both of which have separate articles which you can read about in our blog.

    Besides the gripper systems, we also discussed what kind of drive train we wanted to use this year. When we were at the kickoff, we noticed that Icarus's chassis was ideal for moving underneath the skybridges, and so we considered using this chassis for our robot in two days challenge. We also had the MiniMech chassis available for reuse. In the end, we proceeded with the mini mech chassis, which a subteam tuned on day one of the two day build, since it would be easier to add a gripper to the next day, and this earlier in the season, we were prioritizing gripper speed, not traveling speed between the two areas of the field.

    All work and no play? Of course not! Here at Iron Reign we like to have safe and wholesome fun as we work, which we had the opportunity to do when we caught an ice-cream truck driving around the neighborhood. Look at us having such a chill time!

    Next Steps

    To finish the challenge tomorrow, we will complete our gripper builds, choose our best design, and then mount it onto the mini mecanum chassis.

    Rack and Pinion Gripper

    07 Sep 2019

    Rack and Pinion Gripper By Cooper and Aaron

    Task: Build a gripper system for the 2019-2020 Skystone Challenge

    The rack-and-pinion gripper system is one of the 4 gripper systems we built this weekend for our Robot in 2 Days project. Since we’ve never used a rack-and-pinion system before, we realized that it would be a creative idea to start off the new season. Going for simplicity, we made a box such that we could fit 2 racks going in opposite directions, having the pinion in the middle. We constructed the racks with standard rev rails attached to the box with a rev standard linear slide piece and attached tetrix rack gears on the opposite side with double sided tape. Then the pinon was a rev standard gear attached to a rail on the back. The plan was such that when the pinion was turned the two grippers will move outwards and inwards to grasp the stones.

    After that, the actual grippers went through 2 iterations. The first was a straight, flat bladed polycarb sheet attached to the rack. We tried this, but it turned out that did not provide enough friction. The second iteration was a slight variation, where we bent the arms and added rubber foam to the end. This saw some success.

    Next Steps

    Overall, the system was very solid and worked reliably, and could be used in conjunction with a gimbal to make a well performing arm, but that didn't save it. For our weekend build, the rack-and-pinion is too incompatible with our chassis to be implemented in time - but as FrankenDroid (our new robot!) is not the final iteration of our competition robot, the rack-and-pinion gripper system will act as a prototype for any changes we choose to make to our gripper system as the season progresses.

    Mentoring Rookie Team Wattever

    08 Sep 2019

    Mentoring Rookie Team Wattever By Aaron, Bhanaviya, Cooper, Jose, and Ben

    Task: Show team 16296 Wattever how we run our meets

    During our time participating in the robot in 2 days challenge, rookie FTC team 16296 Wattever (that's their name!) stopped by to take a look and get some advice from us. They were brand new to FTC, and came to us since we were a veteran team in the area. We enjoyed sharing with them our previous experiences and season highlights, as well as any and all steps a rookie team could take to ensure that they were ready to start competing in the Skystone season.

    We showed them what tools and materials they would need, skills they would acquire, and priorities that were vital to competing in FTC. Not only that, but we did some discussing of this years challenge, sharing some ideas that may have not come straight to mind. We told them our preferences for kits, parts manufacturers and what kind of projects a rookie team could partake in for the upcoming build season.

    Next Steps

    Overall, they were very enthusiastic about FTC and we were excited to help them out. We had fun introducing them to the gospel of FIRST and we look forward to collaborating with more such teams in our region as the season progresses.

    Parallel Gripper

    08 Sep 2019

    Parallel Gripper By Ben

    Task: Prototype a parallel gripper

    While there are many different solutions and gripper designs, one of the most common is the parallel gripper. The purpose of a parallel gripper is to grip objects, in our case stones, parallel to the object instead of at an angle. Since this was a rational idea to start off with, this was one of the gripper designs we experimented with in the duration of our Robot in 2 Days challenge.

    A parallel gripper would allow us to grip the stones more effectively, as it would grip with more surface area. Theoretically, these grippers work by having 4 bars/connectors which are all the same length. When they close, they close parallel.

    After building the gripper, we tested it with the stones. While it did an okay job at gripping, due to the fact that we didn't use any gripping material, it slipped a few times. Another issue we encountered was that it would be difficult to flip a stone if needed, which is a task other designs could perform.

    Next Steps

    If we decide to pursue the parallel gripper system, we would have to figure out a way to flip a stone so we could stack it, along with improving the grip.

    Ri2D Code

    08 Sep 2019

    Ri2D Code By Jose

    Task: Code a Basic TeleOp Code for the Ri2D bot using pre-existing classes and methods

    As the Ri2D bot nears completion, the need for TeleOp code becomes apparent to actually make it move. Since this robot is based of from MiniMech, a previous chassis design for Rover Rockus, the code was simply inserted into its existing class. To allow its subsystems to move and hold their position when they are not, methods for it to pose were used from the code for Icarus, our Rover Rockus robot. Most of the `PoseBigWheel` class wont be used for this robot, but that's fine since that is as simple as not using the methods not needed, done. The constructor for the `PoseBigWheel` class needed to be modified since there are different motors and servos used, this was easy as we just needed to remove anything we didn't need. Again, most stuff here won't be used, but as long as we don't delete any PIVs we should be fine.

    Once the code for robot posing is made to match the Ri2D bot, we need to implement it. To do this an instance of this class was instantiated in the `MiniMech` class. With that, we can now use methods of the `Crane` class(the one with robot posing) in the `MiniMech` class.

    Now it's time to use these methods from the `Crane` class. Since the elbow and slides are the same from Icarus we can apply these methods directly. These were simple if statements to detects a button press and set the appropriate motor moving using the posing code from the `Crane` class. Instead of using basic `setMotor` commands to get the motors going, pre-coded methods were used, we can now keep the motors in the position where they are placed in the same amount of complexity and with no previous knowledge of how to code robot poseing.

    Finally, we have to code the servos. Since the `Crane` class comes with code for two servos we can advantage of it since the Ri2D bot has only two servos. Although the code for this is a lot simpler since robot posing isn't required here, it is still nice to have values for the open and closed positions stored in a PIV in the `Crane` class if we ever have to change them later. A simple toggle feature was used so one button sets the servo to an open position when closed and vice versa.

    Next Steps

    We could on some robot articulations later on, but a basic TeleOp program is good for now.

    Robot in 2 Days - Day Two

    08 Sep 2019

    Robot in 2 Days - Day Two By Bhanaviya, Aaron, Cooper, Jose, Ben, and Paul

    Task: Finish Robot in 2 Days

    Since the reveal was released yesterday, Iron Reign embarked on a project to build a skystone-specific robot in 2 days. Yesterday was a planning ground, during which we began prototyping 4 robot grippers, and 2 chassis designs. With less than 24 hours to complete our robot, we started today off by getting build-specific decisions out of the way, so that we could narrow in on one robot design to code and work on.

    Of course, we couldn't settle on a decision without first finishing all 4 of our gripper designs. At the end, we had one gripper system that incorporated nylon gears, one that used regular wheels, one that used a rack-and-pinion system, and one that was a parallel gripper system. We decided to settle on the one using standard wheels that pivot to grip onto a skystone. While we haven't yet decided if this will be the same design we will work with in time for our first qualifier, it is a stable system for a robot in two days.

    As far as the chassis was concerned, we stuck to using Mini-Mech, our summer chassis project from the previous year. Since we added a control hub to Mini-Mech earlier in the week, all that had to be done was incorporate the gripper system onto its chassis, and program it to at the very least move and grip onto skystones. This was a lot of work that needed to be accomplished in 4 hours, but as full-fledged members of the Building A Robot The Night Before A Competition Club, working on a small time frame was nothing new to us. In the span of one practice, we finished implementing a working gripper system to Mini-Mech and coded it to move, grab and stack a skystone on the foundation top. We christened our creation FrankenDroid as a testament to this year's Star Wars-based theme and the fact that the robot was made from harvesting parts from our last years' robots, Big Wheel and Icarus.

    Next Steps

    While FrankenDroid's movements are far from being smooth, it is a start. Robot in 2 Days started off as a fun challenge for us - we did not expect to accomplish as much progress as we did in such a short span of time. As of now, we don't plan on using FrankenDroid as our competition robot - but it will be useful for drive-testing, and will serve as a prototype for any future iterations.

    Robot in 2 Days Grippers Comparison

    09 Sep 2019

    Robot in 2 Days Grippers Comparison By Jose and Bhanaviya

    Task: Analyze all our grippers from the Robot in 2 Days challenge

    During the making of our Ri2D we prototyped and designed several gripper designs to collect stones. These designs varied in the method of manipulating the stone, how many servos they required and how compact they are. All of these gripper designs have their own post describing them in detail, but this article summarizes all of these grippers as a way to help us with future gripper designs.

    1) Wheel Intake

    This idea was though of but never built since the design was to have wheels at about ground level to spin and therefore intake the block, the problem being that this would disrupt the other blocks in the quarry since it intaked the block from its short side.

    2) Wheel Gripper

    This design was to use wheels as grip since they have good friction, one set of wheels is stationary and the other set can open and close via a servo. Not compact, but required only one servo and had great grip on the stone. This was ultimately the design we ended up using in our final Robot in 2 Days bot, Frankendroid,since it was efficient in maneuvering and controlling stones and served as a good design for a quick, 2 days old robot.

    3) Aaron's Super Cool Gripper That Works 100% of The Time

    This design used 3-D printed wheels made of ninja flex that spun to intake the block, like the wheel gripper just not in a set position and it grabbed stones from above. This design was huge and required two servos as well as not having much grip.

    4) Rack and Pinion Gripper

    This design involved a rack and pinion closing some polycarbonate sheets to grip the stone. The polycarb sheets had foam for grip, but this was still not enough to even lift the stone, so an actual motor would be required.

    5) Parallel Gripper

    This design was to use a parallel grabber with some material for grip as an alternative to the rack and pinion design. Unfortunately, the parallel grabber wasn’t built correctly thus not parallel.

    Next Steps

    With all of our gripper designs from the Robot in 2 Days Challenge documented, we can now analyze how best we can improve these designs for future gripper iterations, as well as the potential of these designs to be combined to create an entirely new design. Currently, we are leaning towards using the gripper with Ninjaflex gears, which is the 3rd design in this article, once we've fine-tuned Frankendroid's design. We think a rolling intake will work well on our robot so this design is consistent with our idea to use the wheel gripper at present.

    Field Set-Up

    13 Sep 2019

    Field Set-Up By Trey, Bhanaviya, Ben, Jose, and Cooper

    Task: Clean our work space and set up the field

    Today we started preparing for the first meeting with the new recruits. Some of the things we set out to do were cleaning the robot room and assembling the new field for this year's challenge. All of the things we wanted to do had the common goal of making a safe and educational environment for the new recruits.

    Before we started cleaning the robot room was a total mess and the main room was no better. Because the robot room is where the rookie teams work, we set out to clean that first. We tried to put away everything that could pose even the smallest danger like loose parts and tools. Even though we didn't make too much of an effort to organize because we knew it wouldn't have lasted long, we still made the room 100% safer. We also did the same for the main room. Finally, we also filmed the reveal video for the robot in 24 hours; however, that footage is still not edited.

    Next Steps

    We need to ensure that we are prepared to open our meeting to an influx of new recruits tomorrow. Now that the field has been set-up and our robot room has been organized, it will be a lot easier for all new recruits and our 2 teams to work in a shared space.

    Test Driving New Robot

    14 Sep 2019

    Test Driving New Robot By Ben, Jose, and Trey

    Task: Test the "Robot in 2 Days" robot

    Today we were able to drive test our "robot in 2 days" robot. We used our robot from the previous season, Icarus, as our alliance partner. Jose and Trey drove several matches. They were able to score around 40 points consistently. This was a relatively high number considering Icarus was only used as a push bot (it hasn't been adapted to this season's challenge). Jose was able to stack the Stones with precision and accuracy. Because of this, he was also able to do it efficiently. We determined the height of the arm was perfect for the robot, but it could use some finer tuning and adjustments. The hook, which was used to move the foundation, worked well too. One issue we encountered was the loosening of a chain on the front right wheel. Even though it was a simple fix, it did cost several points, as the robot was more challenging to control.

    We were also able to test our robot with our sister team's (Iron Core) robot. Their robot was essentially a push bot too, but provided different challenges for our driver. The core bot was smaller, yet harder to maneuver, especially for newer drivers. This resulted in a loss of points and difficulty operating smoothly. Eventually, both drivers figured it out and were able to score 25-30 points consistently.

    Iron Reign's robot stacks a Skystone while Iron Core's robot pushes a Stone.

    Next Steps

    We will continue to test our robot and fine-tune the arm, chassis, and intake design based on performance. We will also monitor the wheels to ensure they remain adequately attached, to avoid them loosening again.

    New Recruits for the 2019-2020 Season

    14 Sep 2019

    New Recruits for the 2019-2020 Season By Bhanaviya, Karina, Aaron, Jose, Ben, Trey, Cooper, Paul, and Justin

    Task: Train the influx of new recruits

    The recruits learn how to code

    During a robotics interest meeting at our school 2 weeks ago, Iron Reign saw a crowd of around 20 hopeful recruits. Today was our first meeting to introduce the new recruits to our program - during which we encountered 4 returning members to our sister team, and 23 potential new members. Needless to say, practice this week was a little more chaotic than usual but we managed to not only train the recruits, but also take care of some driver practice and journal backlog.

    Of the 23 recruits, 4 had robotics experience and 2 had 3D-modelling experience. Regardless of their previous robotics experiences, however, all recruits made significant progress as they experimented with the new REV kits. Most of our team is compromised of under-classmen, and after a year of watching our older (and significantly taller!) seniors induct us into robotics, it was a new experience to be teaching new recruits of our own this year. We divided the new members into two team of 10 respectively, and the remaining 3 observed and learned on how to use PTC Creo from our lead modeler, Justin. The first team was assisted and taught by several returning members from our sister team Imperial Robotics. They worked on building a differential chassis with the Imperial members. The second team was compromised of entirely new recruits and they worked on building a pushbot using the new REV kits, an initiation ritual that we ourselves had to encounter our freshman year. The first team finished the chassis but is yet to implement any additional subsystems onto it, something they will work on during the next meet.

    The second rookie team finished building a push-bot during their first meet! Of course, they encountered some difficulties in the beginning as there were 10 individuals working with one REV kit. Some challenges they had to encounter included figuring out how to position the extrusion bars, and where to place the push-bot wheels. Several Iron Reign members floated in and out of their work area to provide assistance when needed, and as well as to teach them how to safely operate power-tools. Once they finished building their push-bot, Jose helped them program the robot with sample push-bot code and taught them how to operate the phones and expansion hubs. Although Iron Reign is the only team in our program as of current to be using a control hub, this may change in the future if members on our sister teams are confident enough of their robots to experiment with a control hub.

    By the time the rookie team had a coded, operational push-bot, we accomplished several hours worth of driver practice, which allowed us to play our very first round of the Skystone Season with our new sister team. This also served as a good opportunity for some of the new recruits to learn how to drive and control a robot, a skill that will come in handy as their first qualifier approaches.

    Finally, Iron Reign was able to clear some journal back-log. Our team has been occasionally guilty of abandoning journal articles until the last minute, so we used today's practice as an opportunity to knock out any posts we've held off on. As of now, we are 100% up to date with our blog, and we hope to be more consistent as our practices continue.

    Next Steps

    Although turnout was much higher than we initially anticipated, this practice was a good opportunity to meet the future members of our program. All rookies were advised to come to our Saturday practices regularly so that they could eventually be placed into teams. As this was the first practice of the year for many, we haven't yet identified how many teams we will be hosting but we hope to do so over the next remaining practices.

    P.A.U.L

    21 Sep 2019

    P.A.U.L By Aaron

    Task: Design a new intake system

    The Pivoting Accelerated User-friendly Locker

    After the end of the two day robot build, we had come up with two main gripper designs. One was consistent, however heavy and large, (Wheel Gripper) and one was lighter but wasn’t quite as versatile or controllable (Aaron's Super Cool gripper That Worked 100% of the Time). P.A.U.L (Pivoting Accelerated User-friendly Locker) is the best of both worlds. It’s made out of polycarb so it’s light and somewhat flexible, and its easily controlled by a servo.

    P.A.U.L was originally designed with a hole in the top where a servo could push a small polycarb rod straight down, pushing the stone out of the grasp of P.A.U.L. This might have worked, however we decided that it would most likely be more efficient and easily controllable if we switched to some sort of pivoting mechanism where one side of Paul could be controlled by a servo. The way that works is by fixing one side to an axle that is attached to a gear. That gear is then controlled by the servo on top of P.A.U.L.

    Next steps:

    In the future we plan to test different gear ratios, that way we could figure out the perfect ratio of torque to speed. We want a good amount of torque that way we can grip the stones tightly and securely so they don’t fall out while being jostled around on the field, however in this years challenge speed is going to be very important.

    Skystone Gripper Version 2

    24 Sep 2019

    Skystone Gripper Version 2 By Justin

    Task: Design an Intake Wheel

    The older iteration of the gripper wheel

    Last season, we designed a ninjaflex gripper for Icarus, our World championship robot. This season, we are experimenting with different intake designs. One of our intake designs is Aaron's Super Cool Gripper, which uses the ninjaflex gripper wheels we designed. The problem with this system is that the wheels are very large, and increase the total size of the intake system. In order to shrink the size of the intake, we need to design smaller wheels that will still be able to grip to the side of the stones. We also combined the design of this gripper with the Pivoting Accelerated User-Friendly Locker (P.A.U.L) so the new intake design uses the new gears on the combination of the existing gripper designs.

    Our design consists of a central hub with 8 short flaps attached around it. The design uses similar flaps to last season's design, but there is no ring to support them and the length is much shorter. The width was 2mm, with the circles at the end being 4mm in diameter. When we printed this design the flaps were not stiff enough to maintain grip on the stones. In our second iteration of the gripper wheel we increased the width of the flaps to 3mm, keeping the circle diameters 4mm. We did this to create stronger flaps that would provide more force against the sides of the stones. In addition to this, we also added curves on the edge between the flaps and the central hub to provide more support to the flaps. These two changes made the flaps much stiffer, so now there is much less force required to maintain grip on the stones.

    The newer version of the gripper wheel

    Next steps:

    We need to test this design on an actual intake system. We have a design that currently has last seasons gripper wheels on it. We need to swap the old grippers with our new design, and adjust the size of the gripper to accommodate the smaller wheels.

    TomBot CAD

    28 Sep 2019

    TomBot CAD By Ben

    Task: Design a concept for a circular chassis

    Concept of circular chassis

    A challenge we face this year is running into other robots. Last year, it was possible to easily get around other robots; however, this year it will be difficult to get around other robots, as there will be a lot more cross traffic in the building zone.

    Our solution to this is designing a circular chassis. This will allow us to brush other robots without getting caught. With this, we would be able to move quicker and accurately. We will construct a 17.5in circular chassis. It will be driven by 2 8-in wheels (ironton 8in. Solid Rubber Spoked Poly Wheel) with 2 sets of 4-60mm omni-directional wheels on the front and back of the robot for stabilization.

    Next Steps

    Our next steps are to begin construction of the circular chassis, which has now been named TomBot, after our coach's cat - Tom the Cat. We will begin construction of TomBot by creating a circular template, which will be 17.5in in diameter. We will then trace that shape onto a polycarbonate sheet and cut it out.

    Recruitment Update

    28 Sep 2019

    Recruitment Update By Bhanaviya

    Task: Plan for 30+ influx of team members

    Just like last year, this year has been pretty successful recruitment-wise. We have had 24 total signups, up from -5 last year. In addition to our returning members to our sister team, Imperial Robotics, and the existing members on Iron Reign, this wave of new recruits means that the Iron Reign family must continue growing. So, just as we have done last year, we introducing TWO new teams to North Texas, making us one of the only school-operated NTX teams supporting a total of 4 teams.

    Structure-wise, Iron Reign will remain the varsity team, and as such, will be responsible for tutoring and assisting the other teams, as well as other organizational decisions. Then, Imperial will now be the JV team, and be the intermediate training ground. You can see their efforts over at https://imperialrobotics.github.io/. Then, Iron Core Robotics and Iron Golem Robotics will be freshmen teams and will serve as a good platform for the new members on the SEM Robotics program to understand what it means to be on a first-time FTC team. While we are pretty early on in the season to make decisions on how many members each of the freshmen teams will have, we estimate that they will both have around 7-8 members each. So far, all of our recruits are motivated and show great potential for the future of our robotics program.

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

    Next Steps

    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. Our goal has been to ensure that the Iron Reign Robotics program is sustainable for years to come and with our 4 teams, we are confident that we will be able to achieve this.

    Fixing the Mechanum Chassis

    05 Oct 2019

    Fixing the Mechanum Chassis By Cooper

    Task: Fix the old mecanum chassis from last year

    Tonight, I worked on fixing the Iron Star robot from last year, since its a viable option for replacement of a chassis if there was ever a problem with ours at a competition. First we needed to strip it down to its bare form and take off the mecanum wheels. After that we took off the Tetrix axle holding blocks, as they were to thick and tall, and we printed out the holders from the minimech robot. We had to cut new axles since the ones that were used were very scarred. from there, the motors were removed and replaced with 20:1 planetary-geared REV motors. Then I attached the mecanum wheels back on.

    Next Steps

    In the future we need to attach the other set of mecanum wheels and add chains to the motors and the wheels. After that, we need to add on the general purpose mounting bracket that we are talking about making so that we can hot swap the subsystems on the fly.

    Preparing for the Meeting with Representative Colin Allred's Office

    05 Oct 2019

    Preparing for the Meeting with Representative Colin Allred's Office By Bhanaviya

    Task: Reach out to congressional representatives in our area to improve the implementation of STEM-based legislation

    This summer, our team reached out to three congressional representatives in our district - Colin Allred, Eddie Bernice Johnson and Kenny Marchant. We emailed to them letters detailing our Mobile Tech Experience Program (MXP), our accomplishments over the Rover Ruckus season, and how our team has dedicated itself towards promoting STEM education in underserved areas of Dallas.

    This week we received an email back from Representative Allred's office and they agreed to our request for a meeting with a member of their staff. The meeting will occur next week, during which we will discuss a bill pertaining to STEM education - more specifically, the H.R. Building Blocks of STEM A Act. This bill was passed this summer, after our correspondence to Allred. The H.R. Building Blocks of STEM is about improving female participation in STEM and in improving STEM education for younger children. As such, our meeting will focus more on discussing how best to implement the contents of the bill and how we can improve the MXP program to collaborate with Allred's office.

    Next Steps

    We are incredibly thankful to Representative Allred's office for giving us the opportunity to discuss STEM education with them. We look forward to the meeting next week.

    Presenting to Representative Colin Allred's Office

    10 Oct 2019

    Presenting to Representative Colin Allred's Office By Bhanaviya, Karina, Jose, Aaron, Cooper, Trey, Ben, Paul, and Justin

    Task: Meet with Representative Colin Allred's office to discuss FIRST robotics and STEM-based legislation

    Today, we presented to Mr Andrew Krause of the 32nd District Representative Colin Allred's office to increase awareness of FIRST and the STEM Outreach that Iron Reign has done in the community. Last year at World Championship in FIRST, the founder of FIRST Dean Kamen emphasized the importance about reaching out to our local representatives to spread the word of FIRST. So, our team reached out to Representative Allred's office, and they agreed to our request for a meeting!

    The legislative bill we wrote about in the email to their office was the H.R. Building Blocks of STEM Act. This bill focused on improving teacher training for STEM educators, increasing funding for STEM-based extracurriculars, and in reforming STEM based education to draw more girls to STEM. As a robotics team coming from a STEM-based school, all of these are issues that we care deeply about, and are issues that we have the privilege to address. During the meeting with Mr Krause, we brought up the National Science Teaching Association (NSTA) Convention that Iron Reign presented at 3 years ago to highlight the importance of STEM teacher training. We also discussed STEM Spark since it was an all-girls event wherein Iron Reign taught middle-school girls how to code and 3D-model.

    We were also able to bring our mobile learning lab, the Mobile Tech Xperience (or MXP, for short) to the meeting. The representatives we met with enjoyed boarding the vehicle to get a first-hand look at the activities we teach during our outreach events. We talked them through the actual process of how the MXP itself was built as well as the plans for its future expansion.

    Next Steps

    Although the Building Blocks of STEM Act was the bill we had reached out to the office about, our main goal for the meeting was to find ways to collaborate with Representative Allred's office to better spread STEM in our community. As students from a STEM-based school, we know that we are privileged in terms of opportunity, and through our existing outreach programs, we hoped to better spread that opportunity to other students in the Dallas community. At the end of today's meeting, we discussed the possibility of members from the Representative office being present at our school-hosted qualifier and our future outreach events. We are thankful for the opportunity to have gotten to present to Mr Krause and we hope to further collaborate with Representative Allred's office in planning our outreach events.

    Gripper Testing

    10 Oct 2019

    Gripper Testing By Paul and Justin

    Task: Test block gripper

    Here is us testing the gripper we designed to pick up the blocks in this years SkyStone challenge. This gripper combines the Pivoting Accelerated User-Friendly Locker, P.A.U.L, one of our earlier gripper designs, and Aaron's Super Cool Gripper, a design from our Robot in 2 Days Challenge. It has a backplate similar to that of P.A.U.L's but instead of polycarb flaps, it utilizes the smaller Ninjaflex gears (a smaller version of the gears on Aaron's Super Cool Gripper) that Justin modeled so it is essentially a combination of our best design ideas so far. It doesn't have a name yet so it will be called P.A.U.L Version 2. It was mostly effective in picking up the blocks, however we need more structural rigidity to ensure that the blocks don't rotate while being picked up.

    Next Steps

    Next steps include reinforcing the gripper frame, and mounting it to our prototyping robot. We also need to cut off the excess rev rail, to reduce weight and make it a little less bulky.

    Autonomous and TomBot Robot

    11 Oct 2019

    Autonomous and TomBot Robot By Karina, Jose, and Bhanaviya

    Task: Autonomous coding and TomBot progress

    DISD students have been blessed with a long weekend, which we plan to take full advantage of as our first scrimmage is closing in. Just as we started to test drive Frankendroid, we began to notice some faults with the robot. Lots of these were common errors, which can likely be attributed to the fact that we sped through the building of Frankendroid very quickly. For one, we left off a lot of pulleys on our belt and pulley system, which left the entire thing very loose and in need of tensioning. We also had an issue of bearings slipping out of their sockets for the gripper's elbow attachment. We promptly made sure that the axle and belt systems were set up properly.

    So far, much of the team's focus has been on building a robot, and we're just now getting around to coding. So besides tuning up Frankendroid, we took a look at our autonomous program. To start, we drew an auto path (version 1). Then, considering Iron Reign already has a large code base from all its years doing FTC, we copied the pre-existing minimech code to start the code for Frankendroid. In terms of the drive train, Frankendroid is pretty standard with four mecanums in a rectangular shape, and so the hardware map was the same. We had some null pointer exceptions due to calls to nonexistent motors, sensors, etc. Additionally, the motor behaviors were not working such that doing the controls to move forward and backwards actually made the robot strafe, and strafing commands made the robot rotate. All of this was fixed in code. Afterwards, we calibrated

    Lastly, we did build work on our work-in-progress TomBot. From wheel to wheel, the span was too great to fit within the polycarb frame we had previously cut. Everything (wheels, motors, extrusions) had to moved closer together on the main axle, and then centered. The two center extrusions intended to be a point of attachment to the polycarb frame extended past the perimeter of the frame, and so these had to shortened with a hacksaw.

    Next steps:

    Our code team is now gearing up for an intensive two weeks of writing and fine tuning code for the robot. Drivers will take this opportunity to practice driving and become familiar with controlling Frankendroid.

    FrankenDroid - TPM Calibration

    11 Oct 2019

    FrankenDroid - TPM Calibration By Jose, Cooper, and Bhanaviya

    Task: Calibrate FrankenDriod's Ticks Per Meter in preparation of programming autonomous

    Today we worked on the calibration of FrankenDriod's TPM. This is used to accurately and precisely move during autonomous by having a conversion factor between a given distance and the unit ticks, which is used in the code. This was done by commanding FrankenDroid to move forward 2000 ticks. Of course this wasn't a meter, but the distance it did travel(in centimeters) was divided by 100 and multiplied by 2000(estimate used above) to get the approximate TPM. After a few times of getting the number of ticks perfect, we got it exact to the centimeter. This was also done for strafing and with that we now have an exact TPM that can be used when programming autonomous.

    Next Steps

    Now for the fun part, actually programming auto paths. These will be planned out and coded at a later date.

    Beginning Auto Stone

    12 Oct 2019

    Beginning Auto Stone By Cooper and Karina

    Task: Design an intake for the stones based on wheels

    Initial Design: Rolling Intake

    We've been trying to get our start on autonomous today. We are still using FrankenDroid (our R12D mecanum drive test bot) because our competition bot is taking longer than we wanted. We just started coding, so we are just trying to learn how to use the statemachine class that Arjun wrote last year. We wanted to make a skeleton of a navigation routine that would pick up and deposit two skystones, although we ran into 3 different notable issues.

    Problem #1 - tuning Crane presets

    We needed to create some presets for repeatable positions for our crane subystem. Since we output all of that to telemetry constantly, it was easy to position the crane manually and see what the encoder positions were. We were mostly focusing on the elbow joints position, since the extension won't come into play until we are stacking taller towers. The positions we need for auto are:

    • BridgeTransit - the angle the arm needs to be to fit under the low skybridge
    • StoneClear - the angle that positions the gripper to safely just pass over an upright stone
    • StoneGrab - the angle that places the intake roller on the skystone to begin the grab

    Problem #2 - learning the statemachine builder

    I've never used lambda expressions before, so that was a bit of a learning curve. But once I got the syntax down, it was pretty easy to get the series of needed moves into the statemachine builder. The sequence comes from our auto planning post. The code has embedded comments to explain what we are trying to do:


    Problem #3 - REV IMU flipped?

    This was the hard one. We lost the last 1.5 hours of practice trying to figure this out, so we didn't get around to actually picking up any stones. We figured that our framework code couldn't have this wrong because it's based on last year's code and the team has been using imu-based navigation since before Karina started. So we thought it must be right and we just didn't know how to use it.

    The problem started with our turn navigation. We have a method called rotateIMU for in-place turns which just takes a target angle and a time limit. But the robot was turning the wrong way. We'd put in a 90 degree target value expecting it to rotate clockwise looking down at it, but it would turn counter clockwise and then it would oscillate wildly. Which at least looked like it found a target value. It just looked like very badly tuned PID overshoot and since we hadn't done PID tuning for this robot yet, we decided to start with that. That was a mistake. We ended up damping the P constant down so much until it had the tiniest effect and the oscillation never went away.

    We have another method built into our demo code called maintainHeading. Just what it sounds like, this lets us put the robot on a rotating lazy susan and it will use the imu to maintain it's current heading by rotating counter to the turntable. When we played with this it became clear the robot was anti-correcting. So we looked more closely at our imu outputs and yes, they were "backwards." Turning to the left increased the imu yaw when we expected turning to the right would do that.

    We have offset routines that help us with relative turns so we suspected the problem was in there. however, we traced it all the way back to the raw outputs from the imuAngles and found nothing. The REV Control Hub is acting like the imu module is installed upside down. We also have an Expansion Hub on the robot and that behaves the same way. This actually triggered a big debate about navigation standards between our mentors and they might write about that separately. So in the end, we went with the interpretation that the imu is flipped. Therefore, the correction was clear-- either to change our bias for clockwise therefore increasing in our relative turns, or to flip the imu output. We decided to flip the imu output and the fix was as simple as inserting the "360-" to this line of code:

    poseHeading = wrapAngle(360-imuAngles.firstAngle, offsetHeading);

    So the oscillation turned out to be at 180 degrees to the target angle. That's because the robot was anti-correcting but still able to know it wasn't near the target angle. At 180 it flips which direction it thinks it should turn for the shortest path to zero error, but the error was at its maximum, so the oscillation was violent. Once we got the heading flipped correctly, everything started working and the PID control is much better with the original constants. Now we could start making progress again.

    Though, the irony here is that we might end up mounting one of our REV hubs upside down on our competition robot. In which case we'll have to flip that imu back.

    Next Steps

    1)Articulating the Crane- We want to turn our Crane presets into proper articulations. Last year we built a complicated articulation engine that controlled that robot's many degrees of freedom. We have much simpler designs this year and don't really need a complicated articulation engine. But it has some nice benefits like set and forget target positions so the robot can be doing multiple things simultaneously from inside a step-by-step state machine. Plus since it is so much simpler this year and we have examples, the engine should be easier to code.

    2)Optimization- Our first pass at auto takes 28 seconds and that's with only 1.5 skystone runs and not even picking the first skystone up or placing it. And no foundation move or end run to the bridge. And no vision. We have a long way to go. But we are also doing this serially right now and we can recover some time when we get our crane operating in parallel with navigation. We're also running a .8 speed so can gain a bit there.

    3)Vision- We've played with both the tensor flow and vuforia samples and they work fairly well. Since we get great positioning feedback from vuforia we'll probably start with that for auto skystone retrieval.

    4)Behaviors- we want to make picking up stones an automatic low level behavior that works in auto and teleop. The robot should be able to automatically detect when it is over a stone and try to pick it up. We may want more than just vision to help with this. Possibly distance sensors as well.

    5)Wall detection- It probably makes sense to use distance sensors to detect distance to the wall and to stones. Our dead reckoning will need to be corrected as we get it up to maximum speed.

    Discuss the Impact of Our Robot in 2 Days Reveal Video

    12 Oct 2019

    Discuss the Impact of Our Robot in 2 Days Reveal Video By Bhanaviya

    Task: Analyze the viewer statistics of our Robot in 2 Days Reveal Video

    2 hours after the challenge reveal for Skystone, Iron Reign kicked off the new season with a new robot - FrankenDroid. It's been one month since then and FrankenDroid has undergone several significant build and code changes (to be revealed in our next few blog posts!), and the video we posted on our youtube channel, Iron Reign, has reached over 2K views. The whole purpose of the video was to inspire teams who were having trouble coming up with build designs for their robots. As a team who's had its fair share of build challenges, we know how Robot in 2 Days videos can be pretty helpful to look at when starting off the new build season.

    As shown above, the release of our video led to our channel receiving over 3,300 views and has a watch time of 7,033 minutes. This is an instance of online outreach and is the primary reason why all our journal articles and videos are public. The NTX region itself is pretty large compared to many other regions competing in FIRST, which makes for teams with active build seasons. Posting videos of this sort allows our team to share our build progress to the rest of the FIRST communities world-wide who may not be as expansive as the North Texas region is.

    Next Steps

    We hope our video was helpful for any teams starting off the new build season. We look forward to posting another reveal video once our robot for competition is ready.

    Auto Path 1

    12 Oct 2019

    Auto Path 1 By Karina and Jose

    Task: Lay out our robot's path for autonomous

    To kick off our autonomous programming, Iron Reign created our first version autonomous path plan. We begin, like all robots, in the the loading stone, its back to the field wall and with our intake arm upwards. We approach the line-up of stones and deploy the arm to its intake state over the last stone. At the same time, we have the wheels of the gripper rotating for a few seconds. The, we back up directly. Using IMU, our robot rotates 90 degrees, and then crosses underneath the skybridge to the building zone. About 1 foot past the end of the foundation closest to the bridges, we rotate again to the right and then deposit our stone. Afterwards, we retract the intake arm, back up, and then park underneath the skybridge.

    Next steps: Improving autonomous by testing

    The autonomous we have now is very simple, but this is only our first version. There are multiple steps that can be taken to increase the amount of points we score during autonomous.

    In testing, I've noticed that (depending on how successfully we initialize our robot) the stone we pick up during autonomous sometimes drags on the ground. This creates a resistive force that is not healthy of our intake arm, which is mounted on the robot by a singular axle. To fix this, we can add code to slightly raise the arm before we began moving.

    Eventually, when multiple teams on an alliance have an autonomous program, our own path will need to account for possible collisions. It will be strategic to have multiple autonomous paths, where one retrieves stones and places them on the foundation, while the other robot positions itself to push/drag the foundation to the depot.

    Also, our autonomous path is geared toward being precise, but going forward into the season, we will need to intake and place more stones if we want to be competitive. As well, we will need to use robot vision to identify the skystone, and transport that stone to the foundation, since this earns more points.

    TomBot Progress

    12 Oct 2019

    TomBot Progress By Karina, Justin, and Trey

    Task: Start assembling the TomBot chassis

    Today we made some progress on our round robot. We moved the rev rails and big wheels on the Bigwheel chassis to be able to fit inside the polycarb circle that we previously made. These movements gave us a good idea of where to position the rev rails, but the wheels were too close to the edge of the circle, to the point where cutting rectangular slots for the wheels would extend the slots outside of the edge of the circle. To correct this, we decided to first cut the slots, then adjust the wheel distance on the old chassis to fit the cuts.

    To cut the slots we first needed to make a template to map out where to cut. We did this on a circular piece of cardboard the same size as the polycarb. After two attempts at aligning the rectangles, we transferred the template onto the polycarb and cut them out with a jigsaw. We planned to round the edges of the rectangular slots to match the shape of the wheels, but an error during the cutting process caused only the outside edges of the rectangles to be rounded.

    Next we needed to mount the rev rail chassis to the polycarb circle and adjust the wheels to fit the new slots. One problem with the chassis is that the rev rails were positioned so that the wheels would sit towards the rear of the robot. After repositioning the rev rails, we marked and drilled holes, then mounted the chassis to the polycarb. TomBot now has the 2 big wheels

    Next steps:

    We need to add the 2 sets of omni wheels to the front and back of the robot to keep the base flat. We should build a basic wheel mount and design a 3d printed mount. The printed mount would be able to flex to soften to force of the robot on the chassis. The motors also need to be chained to the wheels.

    Dr. Woodie Flowers, in Memoriam

    12 Oct 2019

    Dr. Woodie Flowers, in Memoriam By Jose, Bhanaviya, Justin, Paul, Trey, Cooper, Ben, Aaron, and Karina

    Task:

    As most people in the FIRST community know by now, Dr. Woodie Flowers passed away on October 11th. As a team who has met Dr. Flowers twice at the FIRST Championship, this saddened us greatly. Dr. Woodie Flowers was an MIT and Louisiana Tech Alumni, college professor, husband and co-founder of FIRST robotics. Launched in 1989, FIRST was created to inspire kids of all ages to find STEM as a fun, engaging and learnable concept. Ever since its founding, Dr. Flowers was an actively-involved member of the organization. He introduced innovative ways to encourage non-STEM motivated kids to the program, and introduced core values to make FIRST an all-inclusive, one-of-a-kind environment. He coined the term "Gracious Professionalism" as a way to persuade everyone to be competitive while also being respectful to themselves and their opponents. Today, FIRST has become a community - one where students of all ages, nationalities, and skill-sets have learned to make robotics and STEM a crucial part of their lives. From creating one of the most popular robotics classes in MIT, to co-founding one of the longest-lasting robotics programs in the world, Dr Woodie Flowers was a man who had dedicated almost his whole life to inspiring the new generation of inventors. His contribution to FIRST is what inspired many teams, including ours, to spend the better part of our schooling towards learning and spreading the influence of robotics to our communities. Rest in peace Dr. Flowers, you will be missed by us all.

    Coding 10/19/19 (Putting meat on the skeleton)

    19 Oct 2019

    Coding 10/19/19 (Putting meat on the skeleton) By Cooper

    Task: work on actually filling out the auto

    As seen in the last post, the skeleton of the auto was done. Tonight My goal was to fill it out-- make it do the things it needs to at the points based on the skeleton. This Would have been a bit more automated had we put a distance sensor on the robot, as I could just tell it to do certain actions based on how far it was from something. Without that, all I could do was hard code the distances. This took most of the time, but was efficient since I did it in stages.

    Stage 1 - The blocks

    My first task was to pick up the first block in the quarry line. I started by going forward and estimating the amount I needed to go, then went into the arm. I needed to make sure that when I went forward, I would go over the block just enough that I didn't move in when moving, but low enough to be able to be picked up with relative ease. So I ran a teleop version of this and got the value for the arm above the block, grabbing the block and just low enough to clear the bridge, a value I'd need later. Then I did trial and error on guessing the distance to the block until the grabber was in position just over the block. Then I ran into a little issue. I wanted to run the intake servos while I put the arm down, but in the StateMachine class, we can only have one action happening at a time per StateMachine object. Therefore, I just set it to run the servos after the arm was put down.

    However there was a separate issue concerning that as well. In the intake method, we assign a value to our servo PIVs to control the speed at which they run. This is how you are supposed to do that, the only problem is that that by itself is not compatible with our StateMachine. As we use Lambda functions, the code runs through the lines of .addState() repeatedly until the method call in the method call in that .addState() call returns true. For starters, we had to change the output method to return a boolean value. But isn't it, as if it was left as that, the lambda funtion would always get back a false from that .addState(), and be stuck like that until we stop it. So, I looked back on the old code from last year, and with the help of Mr.V, we found a .addTimedState() method. This takes in a method like a normal .addState() method, but a time to complete can be assigned. With the intake method always returning false, it means that the servos would run until the end of the time set and then it would end that action and move on to the next.

    Stage 2 - The deposit

    So, after the bock was picked up, the robot was told to turn to the other end of the field, where another set of estimations were used to move forward. This is where the value of just clearing the bridge came to play. To get under the bridge, we have to hold the block and arm in a certain position. After the bridge is cleared, the arm is set to move back up so when we turn to face the build plate, we could deposit. Now this was interesting. As hard as I tried I could not get the deposit to work reliably, but some of the accidental effects gave me ideas for how to get the most efficient way of placing the block. On one of the runs, the block was set down and it didn't quite sit where it needed to, as to say it was tilted back away from the robot. This led to the arm knocking it back into the correct place. I think this is a great way to have a more catch-all way make sure that the first block is correctly placed. I would have expanded on the idea, but I had to leave soon after.

    Next Steps

    I need to test more efficient paths for this auto, but other than that, I just need to finish this version of the auto for the scrimmage.

    Investing in a CNC Router

    20 Oct 2019

    Investing in a CNC Router By Bhanaviya

    Task: Invest in a CNC router using our grants from the previous season.

    Last year was a very successful season for Iron Reign, financially speaking. We earned around $11,000 in grants and funding from FIRST in Texas, Texas Workforce Commission and Mark Cuban, to name a few sponsors. In addition, this year we received a $200 Gobilda product grant. Most of this money was invested in last season's expenses. But as we found out over the course of our build season, our team incorporates a wide number of 3D-printed parts into our robot, and especially since we were recognized for our design process at the Houston World Championship through Innovate Award Finalist, our design process was one that we could further improve now that we've seen the level of competition at Worlds. Part of this includes using a variety of materials, as illustrated in previous seasons where we've used ice-cube trays and turkey-coolers into our robot's subsystems. So, what better way to improve our design process and spend our grant money than in investing in a CNC router?

    The router itself cost around $3000, and while this isn't cheap, it's a good investment since it now allows to cut our parts out of durable, inexpensive materials like aluminum and wood. So far, we have plans to use the router on the mounting under the turn-table of our robot and a logarithmic spiral that is being modeled to reduce the torque on our linear slide system. There's no end to how much this router can influence our overall design process. Our team is used to using Ninjaflex-printed parts but with the router, we can be more creative with the use of 3D-modeled parts on our robot.

    Next Steps

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

    Control Mapping

    25 Oct 2019

    Control Mapping By Bhanaviya and Cooper

    Task: Map and test controls

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

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

    Next Steps

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

    Driving at the Hedrick Scrimmage

    26 Oct 2019

    Driving at the Hedrick Scrimmage By Karina and Jose

    Task: Figure out what went wrong at the scrimmage

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

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

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

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

    Next steps:

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

    First Season Scrimmage at Hedrick MS

    26 Oct 2019

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

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

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

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

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

    Next Steps

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

    Coding Before Scrimmage

    26 Oct 2019

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

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

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

    Problem #1 - dragging the base

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

    Problem #2 - problem with hook

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

    Problem #3 - PID Tuning?

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

    Problem #4 - putting the block on the build platform

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

    Next Steps

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

    TomBot Suspension

    26 Oct 2019

    TomBot Suspension By Ben

    Task: Design a suspension for TomBot

    3 Different iterations of the passive suspension.

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

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

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

    Wheel mount with example suspension

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

    Next Steps

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

    Hedrick Scrimmage - Code

    26 Oct 2019

    Hedrick Scrimmage - Code By Jose and Cooper

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

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

    Next Steps

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

    Ordering a Slip Ring

    26 Oct 2019

    Ordering a Slip Ring By Jose

    Task: Order a slip ring for the turn table

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

    Next Steps

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

    Updating TomBot's model

    27 Oct 2019

    Updating TomBot's model By Bhanaviya and Ben

    Task: Update the model to plan TomBot's build

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

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

    Next Steps

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

    Round Chassis Assembly

    02 Nov 2019

    Round Chassis Assembly By Justin, Trey, and Jose

    Task: Attatch Omni wheels to Round Chassis

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

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

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

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

    Next Steps:

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

    Transition from Expansion Hub to Control Hub

    02 Nov 2019

    Transition from Expansion Hub to Control Hub By Jose and Cooper

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

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

    Next Steps

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

    Stub Gripper

    02 Nov 2019

    Stub Gripper By Jose

    Task: Building gripper iteration #7

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

    Next Steps:

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

    Turn-table Assembly

    02 Nov 2019

    Turn-table Assembly By Aaron and Trey

    Task: Finish assembling the turn-table

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

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

    Next Steps:

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

    3-Fingered Gripper

    09 Nov 2019

    3-Fingered Gripper By Jose and Aaron

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

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

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

    Next Steps

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

    CNC Turntable Mounts

    10 Nov 2019

    CNC Turntable Mounts By Justin

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

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

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

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

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

    Next Steps:

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

    Mounting the Slip Ring

    10 Nov 2019

    Mounting the Slip Ring By Aaron

    Task: Mount a slip ring onto TomBot's chassis

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

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

    Next Steps

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

    Responding to Girl Scouts of Desert Southwest

    13 Nov 2019

    Responding to Girl Scouts of Desert Southwest By Bhanaviya

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

    The Mobile Tech xPerience

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

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

    The floorplan for a second vehicle

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

    Next Steps

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

    Logarithmic Spiral Design

    15 Nov 2019

    Logarithmic Spiral Design By Ben

    Task: Design a system that could linearly reduce torque.

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

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

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

    Final design over original spiral

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

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

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

    Next Steps

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

    (Detected as missing, recovered, and Restored on 11/19/2022)

    Presenting Our Engineering Notebook

    16 Nov 2019

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

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

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

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

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

    Woodrow Scrimmage

    16 Nov 2019

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

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

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

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

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

    Next Steps

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

    Linear Slides on TomBot

    19 Nov 2019

    Linear Slides on TomBot By Justin

    Task: Mount linear slides to the robot.

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

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

    Next steps

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

    Coding TomBot

    20 Nov 2019

    Coding TomBot By Cooper and Jose

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

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

    Change #1 - Mecanum Drive to Differential

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

    Change #2 - Rolling Gripper to 3-finger gripper

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

    Change #3 - Turret

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

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

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

    Change #4 - XML file

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

    Next Steps

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

    Morph Chart

    20 Nov 2019

    Morph Chart By Bhanaviya

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

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

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

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

    Next Steps

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

    Last Minute Code Changes

    22 Nov 2019

    Last Minute Code Changes By Cooper

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

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

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

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

    Next steps

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

    Night Before Competition Build

    22 Nov 2019

    Night Before Competition Build By Aaron, Cooper, and Trey

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

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

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

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

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

    Next Steps

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

    Match Play at Allen Qualifier

    23 Nov 2019

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

    Task: Compete in Qualification Matches and maybe some Playoffs

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

    Match 1(Quals 6)

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

    Match 2(Quals 11)

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

    Match 3(Quals 18)

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

    Match 4(Quals 28)

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

    Match 5(Quals 31)

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

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

    Semis 2-2

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

    Finals 2

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

    Finals 3

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

    Next Steps

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

    Allen Qualifier

    23 Nov 2019

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

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

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

    Inspection

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

    Presentation

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

    Robot Game

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

    Match 6

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

    Match 11

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

    Match 18

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

    Match 28

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

    Match 31

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

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

    Semifinals Match 2-2

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

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

    Finals Match 2

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

    Finals Match 3

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

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

    After-Judging and Awards Ceremony

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

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

    Next Steps

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

    Inspire at Allen

    24 Nov 2019

    Inspire at Allen By Bhanaviya

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

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

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

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

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

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

    Build Post-Mortem

    24 Nov 2019

    Build Post-Mortem By Bhanaviya and Aaron

    Task: Begin analyzing long-term build improvements

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

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

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

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

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

    Next Steps:

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

    Drive Issues at Allen Qualifier

    25 Nov 2019

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

    Task: Identify points of improvement after driving at Allen

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

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

    Next Steps:

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

    Post-Qualifier Code Debugging

    25 Nov 2019

    Post-Qualifier Code Debugging By Cooper

    Task: Debug code after the Allen Qualifier

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

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

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

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

    Next Steps

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

    Mentoring FTC Team 6964 Igutech

    26 Nov 2019

    Mentoring FTC Team 6964 Igutech By Bhanaviya

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

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

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

    Next Steps

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

    Swivel Mount

    26 Nov 2019

    Swivel Mount By Aaron

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

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

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

    Next Steps

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

    Finger Gripper Version 2

    26 Nov 2019

    Finger Gripper Version 2 By Jose

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

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

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

    Next Steps

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

    Adding to TomBot model

    27 Nov 2019

    Adding to TomBot model By Ben

    Task: Update the current robot model

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

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

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

    Next Steps

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

    Allen Qualifier Post Mortem - Code

    27 Nov 2019

    Allen Qualifier Post Mortem - Code By Jose and Cooper

    Task: Analyze our strengths, weaknesses, opportunities, and threats for our code at the Allen Qualifier

    Fresh off our first qualifier at the Allen STEAM Center, we decided to begin a SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis for code. While we will have other posts specifying what issues we needed to debug after the qualifier, and what articulations we need to implement within our code, this article mainly focuses on our code progress at the qualifier, and what can be improved in time for the next qualifier.

    Strengths

    • We have completely overhauled our codebase to be completely compatible with TomBot
    • We know how to use state machines to code autonomous much easier

    Weaknesses

    • Our autonomous only scores 5 points
    • We had few driver enhancements so many manual overrides were used

    Opportunities

    • We can have a tower height variable that makes the arm go to a certain height when stacking
    • We have plenty more things to do during autonomous and can make use of the turntable to make it faster
    • We can use a color sensor directly on the stone gripper to detect skystones during autonomous

    Threats

    • Any team with a 5+ point autonomous
    • 7172, they have many of our ideas for code improvements already implemented

    Next Steps

    Focus on building upon our opportunities, and begin creating plans for future articulations (which will be detailed in a later post).

    SEM Robotics Tournament

    27 Nov 2019

    SEM Robotics Tournament By Coach and Bhanaviya

    Qualifying Tournament needs Volunteers!

    Iron Reign (team 6832), The School of Science and Engineering and the Dallas ISD STEM Department are happy to announce that we are hosting our third annual FIRST Tech Challenge qualifying tournament at our Townview campus on December 14th. Thirty Two North Texas robotics teams will compete for awards plus approximately 4 or 5 advancements to the Regional Championship to be held in February, and 4 advancements to the Wildcard Qualifer for another chance.

    This is the third time our school has hosted an official qualifying tournament and we will need your help to make it a first-rate experience. This is a full day event on Saturday, December 14. There are also options to help with setup Friday afternoon December 13. Please feel free to circulate this message to everyone in the SEM community who can contribute their time and expertise. And if you can suggest a business that might want to sponsor the event, we'll be happy to talk with them.

    Volunteer Roles

    One group of volunteers that support the running of robot matches include referees, score keepers, inspectors, field managers. Some of these roles require training and certification and we will generally draw from mentors already involved in FTC. Other roles supporting match play do not require training and include field management, pit management and queue management.

    Another group of volunteers will support judging of teams for awards. Judges can be drawn from industry or academia and can have an engineering background or a general business backround in a technology industry. Judges assess the merits of teams' robots, their engineering process and journal, their strategic decisions, team dynamics and outreach. Judges will be led by a Judge Advisor, but will need to understand the awards criteria ahead of time.

    Another group of volunteers will support the event overall. This includes team registration, crowd control, DJ, photography, A/V support, floaters, runners, concessions, load-in/load-out crew, etc.

    This is just a summary of the most common roles, but there are many specialty roles. Full volunteer info can be found here.

    For some roles it helps to understand the run-of-show for the day.

    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.

    Please sign up for as many roles as you feel comfortable fulfilling. We may need to be flexible with assignments depending on who is available and which roles can be fulfilled by our regional managing partner. Students may volunteer for certain roles and as event hosts, Iron Reign team members will be supporting the event throughout the day.

    To begin, go to the volunteer signup page for our event: https://my.firstinspires.org/Volunteers/Wizard/Search/2?EventId=47076

    If you have not previously registered with FIRST, you'll need to sign up / register and activate your account first. Then you can go back to the link above and indicate your preferences. We truly need your help and look forward to working with you to create a great tournament for our students. We hope this event will showcase SEM as the premiere home for future scientists and engineers.

    All our Thanks,

    Karim Virani and Cathy Lux

    Location

    Tournament day is very involved for the teams and volunteers. Here is a typical schedule of the day:

    • 7:00 Doors open for volunteers
    • 7:30-8:30 Teams arrive, register and load their robots and gear into the pit areas
    • 9:00 - 10:30 Teams present their robots to Judges for the awards competition. They also get their robots inspected and approved for the robot game
    • 10:30 Opening ceremonies and then qualifying matches of the robot game begin. Judges are observing teams in their pits and on the competition field
    • Noon - Lunch will be provided for the teams and volunteers. Judges share information with each other about the teams they interviewed.
    • Afternoon - qualifying matches continue until each team has competed 5 times. There are 4 robots per match and we'll have two alternating competition fields to speed things up.
    • Mid-to-late afternoon is Alliance Selection, top teams from qualifying rounds will build alliances to compete in the elimination / playoff rounds. Judges continue deliberating.
    • Playoff rounds usually take a bit over an hour
    • Closing Ceremonies and Awards
    • Pack up fields and equipment

    We plan to end the tournament by 5:30pm, but events often run long. All volunteers are encouraged to stay until the end of the tournament - it's at the awards ceremony where it becomes clear how much your service matters. But it's not required if your role is completed earlier in the day.

    Finger Gripper Version 3 CAD

    28 Nov 2019

    Finger Gripper Version 3 CAD By Jose

    Task: Design a more comapct and efficient gripper design

    This version of the finger gripper is going to be mostly custom made to make it as simple and as compact as possible. This is just the CAD model of the actual design and we plan to update a little more before we can actually make the physical change on the actual gripper. The design remains the same but the gripper now has a new addition, a capstone deployer. The idea is to have the capstone preloaded on the gripper and have a mini servo drop it on the last stone we are placing. The design of this capstone is in another blog post, but the idea is to make it as small as possible to not make the gripper much larger.

    Next Steps

    We need to make this design perfect before printing, once that is done we can do so and begin its implementation on the robot.

    Creating a Robot Handle

    29 Nov 2019

    Creating a Robot Handle By Paul

    Task: Create a handle for the robot to make it more inspection-worthy

    The robot handle is a revolutionary piece of precision engineering, designed to allow the robot to lifted by a carbon-based linear motor, known as a human arm. The handle is made of a composite material, consisting of a matrix of polyurethane fibers surrounded by a carbon-based synthetic thermoplastic polymer sheath. This cording material shall henceforth be known as “Bungee cording”. This “Bungee cord” is wrapped around two aluminium support struts to ensure structural stability and ensure that the forces induced by the carbon-based organic linear motor don’t exceed the ultimate structural limits of the attachment points, which would result in the uncontrolled acceleration and subsequent sudden deceleration when the robot impacts the surface below. This would be bad because the robot is expensive and the ground is usually hard.

    This bungee cording helps protect the puny little meat sticks we call fingers, because for some reason that getting your fingers sliced open by the robot is bad or something. The meatbags that our team consists of need to be protected as per FTC regulations.

    Next steps:

    Enhance the carbon-based organic linear motors so our engineers can lift the robot without looking weak. Also maybe a little more padding to help protect people’s fingies.

    Bill of Materials

    30 Nov 2019

    Bill of Materials By Bhanaviya, Trey, and Jose

    Task: Create a list of parts needed for the new robot

    To determine all the materials we need for the new robot, we started a Bill of Materials. To do this, we first analyzed TomBot sub-system by sub-system. We determined the parts used for each sub-system and placed it into a spreadsheet. Upon doing this, we needed to get each part's exact measurements so that we could save time when trying to cut the new parts. Additionally, we needed the quantity of each part as well as which manufacturer it was from. Something new about the new robot is that we hope to have a completely CNC-ed bot with as many custom parts as we can incorporate. Using a good number of custom parts will allow us to be more creative with the robot design itself since everything we add to it will be custom-printed. This will also allow us to improve our engineering process as we iterate through multiple different versions of a part. This was critical because at the end of the day, the task was to build a better version of TomBot but using, more or less, the same parts.

    Next Steps

    We will update the bill as we iterate through more parts. As of now, TomBot has several build issues that will be discussed in our post-mortem posts. Part of rectifying these issues includes ordering/printing more parts and editing the bill accordingly.

    Capstone Version 3

    30 Nov 2019

    Capstone Version 3 By Jose

    Task: Design a minimalistic capstone that can be deployed by the stone gripper

    This version of our capstone is to be 3D modeled and printed as well as be as compact as possible to be deployed by the gripper. The basic idea is that the capstone is flat while meeting the minimum size for length and width. The capstone will be an 'I' shape to fit around the nubs of a stone. From here a small beam will be attached on the hole which is extended out of the 'I' as shown above. This will be 3 inches long, making this capstone technically legal. This capstone is small enough to allow another capstone to be placed on top if needed.

    Next Steps

    We need to fully 3D model this capstone and change the bottom of the gripper so it can be deployed easily.

    Short-term Post-Mortem Talks

    30 Nov 2019

    Short-term Post-Mortem Talks By Bhanaviya, Cooper, Paul, Aaron, Ben, Jose, and Trey

    Task: Begin analyzing our performance at the Allen qualifier

    It’s officially been a week since our first qualifier at Allen. Although we succeeded in qualifying there’s still a lot of work to be done before it we’re ready for the regional championship. Before we could begin any preparation for regionals, we needed to start off by analyzing our performance at Allen. To do this we created a SWOT (strengths, weakness, opportunities, threats) analysis.Today was simply a short-term version of this analysis and there will be a separate post detailing our comprehensive post-mortem analysis as well as other post-mortem posts for our build and code subdivisions.

    We started off by analyzing our performance at judging. In the past, timing is an issue we’ve struggled to nail down during judged presentations. As such, this year we worked to make our presentation as concise but thorough as possible. During the actual presentation, while we hit the 5 minute mark there were other areas in which we could have been improved - particularly, our robot demonstration and our ability to explain our build decisions with calculations. To solve this, we plan to design a research poster for regionals which explains our mathematical reasoning for every aspect of the robot. The poster will allow us to allude to our calculations during both presentations and pit visits. As for robot demo, it is more a matter of being prepared with working controls which is an issue we will cover in our long-term post-mortem.

    On the short-term, we also plan to better organize our bill of materials which will streamline our process of building our new robot. For reference, TomBot is our current robot. Before regionals, we plan to build a similar circular-chassis based robot but with more custom built parts which we plan to design using our new CNC mill.

    On the issue of drive practice our solution is simple, effective and fully on-track with the Iron Reign way: double it and try not to break the robot. In all seriousness, the only way to resolve lack of drive practice is doing more of it. Part of this includes documenting our driver practices with statistics for us to better analyse our progress (or lack of thereof).

    The final issue we discussed during today’s post-mortem talks was how we plan to organize our schools qualifier on December 14 . Although this isn’t related to our performance at the Allen Qualifier, our experience at the tournament allowed us to better understand what needs to be done to get all 4 of our teams ready to host a 31-team qualifier. Part of this includes all members registering for roles as well as ensuring that we have monitors, playing fields, and enough adult volunteers to pull off the whole event.

    Next Steps:

    Over the course of next week’s meeting, we will finish our post-mortem talks and will continue our preparations to host the Townview Qualifier. In addition, we will also detail our SWOT analysis on this blog when our post-mortem talks are finished.

    Allen Qualifier Post Mortem

    07 Dec 2019

    Allen Qualifier Post Mortem By Karina, Bhanaviya, Jose, Ben, and Paul

    Task: Plan for upcoming tournaments

    So our Allen qualifier was a success! Iron Reign won the Inspire Award, which we are so honored to have been given. We did a detailed SWOT analysis to identify our strengths, weaknesses, opportunities, and threats.

    Strengths

    • Preparation
      • Earlier preparation of the engineering journal
      • Productivity greatly increased under pressure
      • Everything was up on blog
      • Content was organized well
      • Functional robot
      • Judging box was prepared and had everything we needed
    • Judging
      • We were effectively able to communicate the reason behind our robot's unique shape
      • Good transitions between ideas
      • We were able to talk fluidly about our robot despite not having speeches prepared
      • Able to redirect judges to specific highlights
      • Storytelling abilities kept judges engaged
    • Robot Performance
      • We passed inspection the first time around
      • Physical build was solid
      • Focused on building/improving even throughout the competition
      • Great teamwork - everyone was coordinated and on task
      • Batteries were charged
    • Scouting and Pit Engagement
      • Good at queueing one another during pit visits
      • Demo worked better than at presentation
      • Scouters got to all the teams

    Weaknesses

    • Preparation
      • Workspace is realy disorganized which made it hard to find tools and equipment that we needed
      • No drive practice until the morning of the tournament since gripper was only mounted then
      • Not enough people for load out
      • Control Award submission
      • Missed items on the checklist for materials
      • Lack of rest
    • Judging
      • Redirected to topics that don't have a lot of substance
      • Not enough calculation based posts to talk about
      • Lack of driver statistics documentation
      • Hand off between different speakers could be smoother
      • Did not clearly discuss our focus on sustainability of the MXP
      • Robot demo did not work since chains fell off
    • Robot Performance
      • All drivers need to learn game strategy
      • Poor wire management
      • Compact design was also the reason behind the turn table knocking chains off of wheels' sprockets
      • Set screws came loose often
      • We had no autonomous at the beginning of the day
    • Scouting and Pit Engagement
      • Need to be more systematic about checking team's claims
      • Did not get video of all of our matches personally
      • Not enough people at the pits to represent the team
      • Unable to seed questions
      • Lacking in enthusiasm
      • Pits were a mess with backpacks thrown all over

    Opportunities

    • Preparation
      • Taking up more afterschool and Sunday practices
      • Allocating more time to preparation in the weeks before competition instead of days
      • Preparing a pit design to optimize organization and places to put up banners
      • Create business cards for handouts
      • Post-event follow through: plugging in phones, charging batteries, etc.
    • Judging
      • Be more aware of what a judge is looking for/what award they are judging
      • Make our binder stand out - aesthetically and by creating helpful guides such as a robot manual
    • Robot Performance
      • Allowing time for driver practice
      • Making sure that everyone gets enough sleep the night before competition
      • Test grippers
      • Better collaboration with alliance partners
      • Control swivel mount on gripper
      • Fully automatic gripper with distance sensors
      • Turn-table needs to stay in position while robot turns
      • Completely CNCed robot (base - polycarb with aluminum sides)
      • Dampen swing on gripper
      • Make model for gripper before build
      • Articulations - more accurate presets specifically for elbow
      • Create a bill of materials with links
    • Scouting and Pit Engagement
      • Design pit layout ahead of time
      • Dress up our pit with tent and banners
      • Have a laptop ready with important info
      • Detailed accounts for each match we do/play by play
      • Have someone assigned to watch matches so that we can personally gauge other team's strength, weaknesses, opportunities for collaboration, etc.
      • Take the chance to talk to other teams
      • Make use of a scouting app

    Threats

    • Preparation
      • Not getting focused until it is too late
      • Busy schedules
      • Not being able to prioritize
    • Judging
      • Rushing through important ideas because of the time limit
      • Judging panel is always an uncertain variable
    • Robot Performance
      • High performing teams
      • Time management
      • Acquisition of all parts
      • Enough time for modeling all the robot parts
    • Scouting and Pit Engagement
      • Sitting around looking at phones looks like disengagement even if we are researching stuff
      • Lack of robot data and statistics to present potential allies with might drive them away

    Next Steps

    We're at the point now where we are prepping for our regionals tournament. Thankfully we will have another opportunity to test out TomBot at the ____ qualifier. Between the work we do now and up until the regionals tournament, we hope to achieve a full autonomous with greater stacking capabilities.

    Capstone Iterations

    07 Dec 2019

    Capstone Iterations By Bhanaviya

    Task: Go over all 3 of our capstone iterations

    So far, we have experimented with 3 capstone models. While we do not intend to use all 3 of these models, they allowed us to effectively implement the engineering process on our robot. Although the capstone isn't physically a part of a robot, its various iterations influence the model of the gripper being used since the ideal gripper must be able to pick up both the skystones and the capstones over the duration of a match. As such, this article analyzes these designs to help us determine which gripper is best for use at our next qualifier on January 11.

    1) Aaron's Super Cool Capstone That Works 100% Of The Time

    The capstone that we made and used at the competition wasn’t the prettiest thing, but it had heart, and was destined for greatness. It was constructed from prototyping wire and duct tape. The basic design was a ring with a spherical top over it in order to not fall off when dropped onto the tower. It also had four large screws on each side in order to weigh down the capstone so as to not slip or slide off the tower when dropped. While this capstone was firm in structure, it requires a lot of precision to be placed on top of the stone itself. Since this year's game is very speed-based, a precision-based capstone is not the most effective.

    2) Jose's Super Cool Capstone That Works 100% Of The Time

    The next capstone was custom-designed and printed at our very own Robo Dojo. Simply put, it is a much flatter, rather 2D version of a skystone. It had two large rectangles in the center to drop onto both the stubs of a stone on a tower. It also has a small rectangular tab at its edge which will allow the gripper to pick it up. But given its shape, an issue would be the ability of our gripper to pick it up and drop it onto the tower without tipping over the entire stack. Once again, while it was destined for greatness, it was not built for the unrelenting force that is time and it would take too much control and seconds to be capped onto a tower.

    3) The I-shaped Capstone That Works 100% Of The Time

    Our latest capstone design is also custom-designed and 3D-printed out of nylon. Structure-wise, it is a flat 'I'. But in terms of capacity, it is the easiest of our capstone models to be picked by the gripper and drop onto the skystone. This capstone aims not to be dropped on the stubs of the stone but rather in in the middle of the capstone where it requires less precision to be dropped and is less likely to fall. It comes with a small tab similar to the one on our second capstone which allows the gripper to pick it up with ease.

    Next Steps

    Now that we have analyzed all of our capstone designs so far, it will be easier for us to streamline which design will be the best to implement on the robot. Right now, we are leaning towards the I-shaped capstone since it's less precision-based, smaller, and easier to be picked up by our current finger-gripper.

    Future TomBot Articulations

    07 Dec 2019

    Future TomBot Articulations By Cooper

    Task: Plan out potential robot articulations to improve game strategy

    Getting back from the tournament, we were able to immediately start to think about what was the big problems and possible improvements to the articulations of the robot. Overall, we ended up coming up with several ideas, both for fixing things and for efficiency.

    1- Turntable Articulations

    In the competition, we realized the extreme convenience that having some articulations for the turret. Not to say that we hadn't tried to make them before the competition, we were having some issues writing them. plus, even if we didn't have those convene, it would have been improbable that we would have gotten them tuned for the competition. Anyways, even though we agreed on needing to have these presets, we could not agree on what they should be. One argument was that we should have them field-centric, meaning that it would stay in one position from the POV of the audience. This was cited to have a good number of use cases, such as repetitive positions, like the left/right and forward of the field. However, another idea arose to have them be robot-centric. This would allow for faster relative turns.

    So, what we've decided to do is write the code for both. The field-centric will be turns and subsequent static positions will implement the IMU on the control hub mounted to the turret. The robot-centric version will be based on the tick values of the encoders on the turret's motor. Then, we will have the drivers choose which one they prefer. This we believe is effective, as it will allow for a more consistent use of the turntable for the driver.

    2- Move to Tower Height Articulations

    this is one of the more useful Ideas, which would be to extend the arm to the current height of the tower. How would we do it? Well, we have come up with a 2 step plan to do this, in different levels of difficulty. The first one is based on trig. We used the second controller to increment and decrement the level of the current tower. That value is then used in the extendToTowerHeight() method, which was written as the following:

    public void extendToTowerHeight(){ hypotenuse = (int)(Math.sqrt(.25 * Math.pow((currentTowerHeight* blockHeightMeter),2)));//in meters setElbowTargetPos((int)(ticksPerDegree*Math.acos(.5/ hypotenuse)),1); setExtendABobTargetPos((int)(hypotenuse *(107.0/2960.0))); }

    As you can see, we used the current tower height times the height of a block to get the opposite side of the triangle relative to our theta, in this case the arm angle. The .25 is an understood floor distance between the robot and the tower. This means that the arm will always extend to the same floor distance every time. We think this to be the most effective, as it means not only that the driver will have a constant to base the timing of the extension, but we minimize the amount we have to extend our arm. If we assumed the length of the hypotenuse, there would be overextension for lower levels, which would have to be accounted for.

    The next phase of the design will use a camera to continue to extend the arm until it doesn't see any blocks. not only will this allow for a faster ascension and more general use cases, It will eliminate the need for a second controller (or at least for this part.

    3-Auto-grab Articulation

    Finally, the last one that we came up with is the idea to auto-grab blocks. To do this we would use vison to detect the angle and distance that block is away from the robots back arm and extend to it. Then rotate the gripper, snatch it and reel it back.

    Next Steps

    Use a culmination of drive testing and experimentation to refine the robots movements and ultimately automate the robot’s actions.

    Townview Qualifier 2019 - Set Up

    13 Dec 2019

    Townview Qualifier 2019 - Set Up By Ben, Jose, Karina, Justin, Bhanaviya, Cooper, Paul, and Trey

    Task: Prepare Townview for the upcoming qualifier

    Tomorrow, December 14th, Iron Reign will be hosting the 2019 Townview Qualifier. 31 teams will be competing and we expect several hundred people to attend the event. We have recruited volunteers from Imperial, Iron Core, and Iron Golem, along with PTSA volunteers from our home schools, SEM and TAG. For our competition, we required over 31 individual tables for each team, 4 queuing tables, and about 6 other tables for snacks, equipment, and inspection. Three fields were also set up, two were brought in as competition fields, set up in the main cafeteria, while the third was provided by Iron Reign as a practice field in the far corner of the cafeteria. Two large monitors were provided by the schools to display match information during matches, along with live results, while the other was used to display inspection status and ranking. The competition fields were setup to the east of the cafeteria with several rows of chairs for spectators. Behind the fields were 4 queuing tables, two per field. We initially placed 4 chairs at every team table, however, more were available along the walls for teams to use. On every team table, we placed 2 signs with the team numbers of the team assigned to that table. Teams were organized by team number to make queuing easier.

    A tournament also required judging rooms. Because the tournament was on the first floor of the building, we transformed 5 classrooms into judging rooms. This usually meant moving many of the tables and chairs off to the side to allow teams and judges to move easily about the room. We posted maps around the building and marked every judging room with the judging room number.

    Next Steps

    Although we finished most of the preparation, there are still a few things left to do. We will need to construct a map of the pits, transport volunteer supplies (like snacks and water), and provide training for volunteers.

    Townview Qualifier 2019 - The Day Of

    14 Dec 2019

    Townview Qualifier 2019 - The Day Of By Bhanaviya, Jose, Paul, Aaron, Justin, Trey, Ben, Karina, Cooper, Jayesh, Tycho, and Max

    Task: Run the Townview Tournament

    On Saturday, December 15, Iron Reign hosted 31 teams and 300 students at the Townview Magnet Center, our home school's campus. With 31 teams, this was one of the biggest qualifiers in the North Texas region. A video play-by-play of the matches can be found in a separate entry here. This entry serves more as a description as to how we got to the point of hosting the qualifier and what to consider when hosting one.

    To start off, a full-fledged qualifier requires a large number of volunteers - both student and adult. While there are certain roles that are limited to adults only, many roles need a good number of younger volunteers - especially queuing and judging assistance. If the host team is not participating in the qualifier, then a good way to meet this cap is to recruit from a school's robotics program. In our case, student members from the Iron Reign Robotics program filled in positions such as game announcer, emcee, disc jockey, concessions, and around 10 queuers and runners. Prior to the start of match-play all our members helped with judging assistance. This includes ensuring that all teams are queued up on time outside their judging panels and ensuring that all teams have gone through field and robot inspection. This helps ensure that all teams are on schedule for the start of match-play. Below, you can see what specific roles which Iron Reign members helped fill during the tournament:

    Townview Qualifier Member Work Log

    Team MembersTaskStart TimeDuration
    KarinaReferee7:0012 hrs
    JustinQueuer and Runner7:0012 hrs
    BhanaviyaEmcee and Queuer7:0012 hrs
    BenQueuer and Queuer7:0012 hrs
    JoseGame Announcer7:0012 hrs
    CooperQueuer and Judge Advisor Assistant7:0012 hrs
    AaronQueuer and Runner7:0012 hrs
    PaulDisc Jockey7:0012 hrs
    TreyQueuer and Runner7:0012 hrs

    A good qualifier also needs adult volunteers. We had 2 judges in 4 judging rooms and one room with 3 judges. In addition, we also had 6 referees and one scorer. All of these are adult roles which meant we had to seek volunteers from a variety of sources including prior FTC Tournaments, alumni from our team, and even our own families. All adult volunteers must go through background checks as well as complete other training certifications on the FIRST website so this proccess must start at least 3 weeks in advance to recruit enough volunteers. To do this, we posted a request for volunteers on this blog for any visitors to our website to sign up.

    Fresh off of the Allen Qualifier, we knew the pressure that teams felt at a qualifier - whether its caused by a lack of driver practice, tools or just undulated anxiety, we wanted to alleviate this stress. So, we ensured that a practice field set up away from the pit area for teams to practice right before their matches. We also kept a spreadsheet with inspection results on 2 monitors in the pits so that teams could be updated, and made pit maps so teams could find one another. These maps are also helpful to runners who need to find teams to queue them for their matches or for their judging panels. With so many members of our team floating around the pits, we were also able to provide any build or code assistance to teams who might need it. Finally, one trait all FTC team members share on the day of qualifier is the perpetual need for sustenance so we collaborated with one of our school's, TAG, PTSA to set up a concessions stand while the DISD STEM Department ensured that all volunteers received lunch.

    Next Steps

    By the end of the qualifier, we were able to advance 4 teams to the North Texas Regional Championship, and another 4 to the Wildcard Qualifier on February 1st. The qualifier could not have gone as smoothly as it did without the help of all our volunteers for committing so much of their times on a weekend to promote FIRST and STEM. We'd also like the DISD STEM Department for proving all our volunteers with breakfast and lunch, to The School of Business and Management and our sponsor, Mr John Gray, for supporting the event. Finally, we'd like to thank our coach Mr Virani for managing all of the logistics for the event, including its set up and the qualifier itself.

    Third Annual Townview Tournament a Success!

    15 Dec 2019

    Third Annual Townview Tournament a Success! By Coach and Bhanaviya

    Thank you to all our volunteers!

    Thank you to all the volunteers that gave up their Saturday to contribute to the FTC community in North Texas. Because of you this tournament was a rousing success. We served 31 area teams and 300 students. We advanced four teams directly to the Regional Championship in February and gave another four a second shot at the Wild Card tournament. More importantly, all teams received a fair chance at competing with excellent Judging and Refereeing - and we are certain that all of them learned how to improve. We really could not have done this without our volunteers carrying the load.

    We extend our deepest appreciation to all volunteers, to the business school and our sponsor for supporting the event, to the TAG PTSA for providing concessions, to the leadership of SEM for hosting and to the STEM Department for feeding our volunteers and Dallas ISD students.

    -Karim Virani, Dr. Catherine Lux, and the students of Iron Reign, Imperial Robotics, Iron Core and Iron Golem

    For those interested, the full standings are up on The Orange Alliance and awards should follow soon.

    We also were doing a test of streaming for future tournaments in our region. Because we had little time to set it up, there were issues with quality on one camera and a complete lack of audio for about half of the tournament. But most of the matches are visible (with the exception of the final match) and most of the awards ceremony was audible. We know what to improve and can hope for a better stream at some following tournaments. Here is what we got:

    Turret IMU Code

    22 Dec 2019

    Turret IMU Code By Jose and Abhi

    Task: Code some driver enhancements for the turret

    With the return of the king(Abhi - an alumni of our team) we were able to make some code changes, mainly dealing with the turret and its IMU since that is our current weak point. At first we experimented with field-centric controls but then realized that for ease of driving the robot, turret-centric control are necessary. After a few lines of code using the turret's IMU, we were able to make the turret maintain its heading, as the chassis turn, so does the turret to maintain its position. This is useful because it will allow the driver to turn the chassis without having to turn the turret as well.

    Next Steps

    We must continue tuning the PID of the turret to allow for more stable and accurate articulations.

    Finger Gripper Version 4 CAD

    25 Dec 2019

    Finger Gripper Version 4 CAD By Jose

    Task: CAD a slightly different capstone version to improve upon v3's issues

    On this minor update to our flat gripper design a dropper for the latest capstone was added. Our capstone design (which can be seen here: E-65 ) is minimalistic to allow it to be placed on the gripper and only deployed until the last stone in the match is placed to cap it. The basic idea for this capstone dropper is to have a bar which has the number 6832 on it to match the 6832 indent on the capstone. This dropper will keep the capstone in place until the gripper is opened to beyond 45 degrees. To allow the gripper to actually close, a triangle was cut off the dropper as seen in the image above. Here is the final design:

    Next Steps

    Once the design is finalized(there may be a 5th version if a change is needed) this will be 3D printed and will replace the current gripper on the robot.

    Materials Test Planning

    26 Dec 2019

    Materials Test Planning By Bhanaviya

    Task: Create a system to test our materials to better understand their grip potential

    Here at Iron Reign, we're used to using off-the-shelf materials for our robot. For this season, these include silicon oven-mitts and ice-cube trays, since we find these grip skystones pretty well. However, we need to do a thorough investigation of these materials before we can determine their efficacy on the robot.

    Specifically, we plan to implement these parts on the underside of our gripper, to improve its friction when in contact with a stone. Our current gripper uses parts of ninjaflex gears but these aren't the most effective in picking up stones quickly. This is a bit of a concern since this year's game is so speed-based. As such, the time has come for us to replace the material on our gripper. However, before we can decide which material would have the best grip, we need to test them to determine their on-robot properties. To do this, we will implement a slip test as shown below.

    The main thing that we want to test is the amount of energy they have while rotating and then the amount of energy they lose upon collision. We plan to test this through the coefficient of friction of the mitts. Simply put, we will place the skystone on top of the of the silicon oven-mitts/ice-cube trays and will tape down the material being tested on a flat surface. Then, we will lift the surface and using simple inverse trigonometric properties, we will calculate theta, the angle at which the stone begins to slip from the material. The bigger the angle, the higher the friction coefficient of the material, which equates to it having better grip.

    Next Steps

    With our testing planned out, we will next begin documenting the angle at which the skystone slips from each type of material. The calculations from the actual testing, including the equation we used, will be inputted into a separate post.

    Code Developments 12/28

    28 Dec 2019

    Code Developments 12/28 By Cooper

    Task: Gripper swivel, extendToTowerHeight, and retractFromTowerHeight. Oh My!

    Today was a long day, clocking in 10 hrs continuously. In those ten hours, I was able to make tremendous progress. Overall, we have 4 main areas of work done.

    The first one gets it’s own blog post, which is the extendToTowerHeight, which encompasses fixing the 2nd controller, calculating the TPM of the arm, and calculating the TPD for the elbow.

    The second focus of the day was mounting and programming the swivel of the gripper. Aaron designed a swivel mount for the gripper the night after the qualifier, which was mounted on the robot. It was taken off by Aaron to finish the design and then today I put it back on, and then wired it. Once we tested to make sure the servo actually worked, we added a method in the Crane class that swivels the gripper continuously. But, since the servo is still a static one, I was also able to implement a toggle that toggles between 90, 0, and -90. With a couple of tests we were able to determine the correct speed at which to rotate and the code ended up looking like this:

    public void swivelGripper(boolean right){ if(right == true) gripperSwivel.setPosition(gripperSwivel.getPosition()-.02); else gripperSwivel.setPosition(gripperSwivel.getPosition()+.02); }

    The third development was the retractFromTowerHeight() method that was written. This is complementary to extendToTowerHeight, but is significantly less complex. The goal of this method was to make retracting from the tower easier, by automatically raising and retracting the arm, such that we don’t hit the tower going down. This was made by using a previously coded articulation, retract, with a call to setElbowTargetPos before it, such that it raises the arm just enough for the gripper to miss the tower. After a couple of test runs, we got it to work perfectly. The final order of business was the jump from ticks being used on the turntable to IMU mode. It was really out of my grasp, so I asked for help from Mr.V. After a couple of hours trying to get the IMU setup for the turret, we finally got it to work, giving us our first step to the conversion. The second came with the changing of the way the turntable moves, as we made a new low level setTurntableTargetPos() method, which is what everything else will call. Finally, we converted all of the old setTurnTablePos() methods to use degrees.

    Next Steps

    As of now both extendToTowerHeight() and the gripper swivel are good. On the retractFromTowerHeight(), it may be important to think of the edge cases of when we are really up high. Also, the turntable is unusable until we tune PID, so that will be our first priority.

    Extend to Tower Height and Retract from Tower

    28 Dec 2019

    Extend to Tower Height and Retract from Tower By Cooper

    Task: Develop the controller so that it can extend to tower height

    Since we have decided to move onto using 2 controllers, we can have more room for optimizations and shortcuts/ articulations. One such articulation is the extendToTowerHeight articulation . It takes a value for the current tower height and when a button is pushed, it extends to just over that height, so a block can be placed. This happened in 2 different segments of development.

    The first leg of development was the controller portion. Since this was the first time we had used a 2nd controller, we ran into an unexpected issue. We use a method called toggleAllowed() that Tycho wrote many years ago for our non-continuous inputs. It worked just fine until we passed it the second controllers inputs, as then it would not register any input. The problem was in the method, as it worked on an array of the buttons on the controller to save states, and there was conflict with the first controller. So, we created a new array of indexes for the second controller, and made it so in the method call you pass it the gpID (gamepad ID), which tells it which of those index arrays to use. Once that was solved, we were able to successfully put incrementTowerHeight() on the y button and decrementTowerHeight() on the x button. The current tower height is then spit out in telemetry for the second driver to see.

    Then came the hard part of using that information. After a long discussion, we decided to with a extendToTowerHeight() that has a constant distance, as having a sensor for distance to the build platform would have too many variables in what direction i t should be in, and having it be constant means the math works out nicely. So this is how it would look:

    Now, we can go over how we would find all of these values. To start, we can look at the constant distance measure, and to be perfectly honest it is a completely arbitrary value. We just placed the robot a distance that looked correct away from the center of the field. This isn’t that bad, as A) we can change it, and B) it doesn’t need to be calculated. The driver just needs to practice with this value and that makes it correct. In the end we decided to go with ~.77 meters.

    Then before we moved on we decided to calculate the TPM (Ticks Per Meter) of the extension of the arm, and the TPD (Ticks Per Degree) of the elbow, as it is necessary for the next calculations. For the TPM, we busted out a ruler and measure the extension of different positions in both inches (which were converted into Meters) and the tick value, then added them all up respectively and made a tick per meter ratio. In the end, we ended up with a TPM of 806/.2921. We did similar with the TPD, just with a level, and got 19.4705882353. With a quick setExtendABobLengthMeters() and a setElbowTargetAngle() method, it was time to set up the math. As can be seen in the diagram, we can think of the entire system as a right triangle. We know the opposite side (to theta) length, as we can multiply the tower height by the height, and we know the adjacent side’s length, as it is constant. Therefore, we can use the Pythagorean theorem to calculate the distance, in meters, of the hypotenuse.

    hypotenuse = Math.sqrt(.76790169 + Math.pow(((currentTowerHeight+1)* blockHeightMeter),2));//in meters

    From that, we can calculate the theta using a arccosine function of the adjacent / hypotenuse. In code, it ended up looking like this: .setElbowTargetAngle(Math.toDegrees(Math.acos(0.8763/ hypotenuse)));

    Then we set the extension to be the hypotenuse:

    setExtendABobLengthMeters(hypotenuse-.3683);

    While it has yet to be seen its effectiveness, it should at the very least function well, as shown in our tests. This will help the drivers get into the general area of the tower, so they can worry more about the fine adjustments. For a more visual representation, here is the position in CAD:

    Next Steps:

    We need to work on 2 main things. Tuning is one, as while it is close, it’s not perfect. The second thing to work on is using a custom vision program to automatically detect the height of the tower. This would take all the stress off the drivers.

    Testing Friction Coefficient

    28 Dec 2019

    Testing Friction Coefficient By Bhanaviya

    Task: Measure the coefficient of friction of our potential gripper materials

    We want to measure various constants of materials on our robot. These materials serve to improve the grip on our gripper. But before we can decide which material will be most effective on our gripper, we need to find the friction coefficient of these materials through a slip test. The slip test is detailed in a separate post in E-67. This article serves mainly to show the specific friction coefficient produced by each material in the slip test.

    To measure the coefficient of friction, we first had to simplify an equation to determine what values to measure.

    Based on these calculations, we realized that the best way to calculate friction coefficient would be by deriving the angle of incline at which the skystone begins to slip from the material, which is placed on a flat wooden board. If we take the length of the side of the board being lifted to be the hypotenuse, and the height at which the board is being lifted to be height, then theta, the angle of incline, is arcsin. As the board is lifted, the stone begins to experience slippage and the angle at which it slides off the material being tested will be marked as its friction coefficient. The higher this value, the more grip the material has.

    The materials we will be testing are a green silicon oven-mitt with hexagonal ridges, a red silicon oven mitt with small rectangular ridges, and an ice-cube tray with cubical ridges. The wooden board on which this the materials and skystone are being placed on has a length and width of 23.5 inches. This will be the hypotenuse for the purposes of this test.

    Green Silicon Oven-Mitt

    When the wooden board was lifted with this material on top of it, it took a height of 10.3 inches before the stone began to slip. Using arcsin, the angle of incline for this material was 26 degrees. By using the equation above, we can find that the coefficient of friction is tan(26) which 0.48.

    Red Silicon Oven-Mitt

    When this material was tested, the board had to be lifted 13.7 inches before the stone began to slip. The angle of incline for this material was 35 degrees so the coefficient of friction is tan(35) which is 0.7. Since this value is higher than the green oven-mitt, the red oven-mitt has the better grip.

    Ice-Cube Tray

    The board reached a height of 12.2 inches when the stone began to slip from the ice-cube tray. The friction coefficient for this material was 32 degrees, and its coefficient of friction was hence 0.66, putting it above the green oven-mitt, and slightly below the red oven-mitt in grip.

    Next Steps

    The material with the largest friction coefficient will be attached to the gripper on the robot. Since the red silicon oven-mitt had the largest angle of incline, this will be the material we will use in the next iteration of our gripper.

    Sliding Foundation Grabber

    28 Dec 2019

    Sliding Foundation Grabber By Trey, Jose, and Aaron

    Task: Design and create a more efficient and compact foundation grabber

    Moving the foundation throughout a match is an important part of the overall gameplay of a team. The builders on Iron Reign went through many different designs before reaching the one we have now. Early in the season, we simply settled for a simple hook attached to a servo on the front of the robot; however, this proved to be quite unstable. The foundation wobbled back and forth when the robot was in control of it and with this in mind, we went back to the drawing board. The second design we had in mind was a lot like the first but with two large, unwieldy, polycarbonate hooks that spanned at least four inches. These were often great at keeping a stable grasp on the foundation but they were made out of polycarbonate and flexed quite a bit and also were just too big in general.

    The design we have now consists of a sliding metal door that is controlled by a servo with a spool of string on it. The metal door models something of a guillotine that lifts to let the edge of the foundation in and then drops to secure it. This door, with its wide bottom, provides a great amount of stability and the base that its mounted to makes it so that the force inflicted by the foundation is passed into the base and then into the drivetrain. The fact that the grabber is not only attached to the servo but also fixed to the robot makes it so that the moving parts are less likely to snap or slip. And all of the components fit into a small space that should not be too much of an obstruction to the arm. Overall, this foundation grabber checks the boxes that the previous ones did not, It's compact, controls the foundation well, and definitely won't bend or snap.

    Next Steps

    No design for any part on any robot is perfect and this grabber is no different. The spool and string that is used to control the door is most likely temporary because there is probably a better way to open and close the door of the grabber. However, one thing that can and will be improved upon with the spool and string is that if provided with an upward force, the door of the grabber will open. This can be fixed by making the string on the spool continuous which will prevent this from happening by providing an opposite force, holding the door in place.

    Finger Gripper Version 2.1

    29 Dec 2019

    Finger Gripper Version 2.1 By Bhanaviya and Aaron

    Task: Replace the ninjalfex gears on the finger-gripper with a material with more grip.

    The finger gripper is the pinnacle of technological evolution, with class, durability and most importantly, metal. But it does lack one defining feature - grip. Currently, the underside of the metal plate on the gripper has parts from our ninjaflex gears used in Relic Recovery, and while it has all the refinement of an almost 3-year old part, it could be improved. Introducing the Finger Gripper 2.1, brought to you by Iron Reign. (although this change is being made after version 3 and 4 of our gripper, it is listed as 2.1 since 3 and 4 have only been designed in CAD and we are yet to translate this into a physical change.)

    On the matter of choosing which material to replace the ninjaflex gears with, we had 3 options to chose from. The first was a red silicon oven-mitt with rectangular ridges, a green silicon oven-mitt with hexagonal ridges, and an ice-cube tray with cubical ridges. To determine which material would work best, we put them a slip test, which can be found in E-69 . Of the 3 materials we tested, the red silicon oven-mitt had the largest friction coefficient. This makes sense, considering it had the sharpest ridges of the three, hence allowing it to grip the stone better. Hence, we replaced the material under our current finger gripper with a small piece from the red silicon oven-mitt. Although changing the material underneath the gripper seems like a minor design change, the improved grip will allow us to rely less on precision and more on speed during the actual game.

    Next Steps

    Next we will test the actual gripper to see if the material lives up to its results from the slip test. Once version 3 and version 4 of the finger gripper have been fully modeled we will print these designs and modify the gripper accordingly.

    Last Coding Session of the Decade

    30 Dec 2019

    Last Coding Session of the Decade By Cooper

    Task: Gripper swivel, extendToTowerHeight, and retractFromTowerHeight. Oh My!

    Today is the second to last day of 2019, and therefore the same of the decade. Thus, I want to spend it at robotics. Today I worked solely on vision testing and attempt of implementation. However they ended up being fruitless, but let me not get ahead of myself. To start the day, I tried looking at the example vuforia code that was provided. After which I hooked up a camera to the control hub to try any see it in action. We learned that in the telemetry, there are 2 lines of values spit out, which are the local position in mm and the XYZ values of the block. For the first bit of the day when we were testing, we thought to use the XYZ values, but they seemed to be unreliable, so we switched over to the local position. Once we had gotten that down and gotten a map of values of where the skystone would be, I tried to tailor the concept class to be directly used in our pipeline from last year, and then refactor all of it. But this didn’t work, as it would always throw an error and for the life of me I could not get it to work.

    Today wasn’t a complete waste, however, as I have learned a valuable lesson -- don’t be lazy. I was lazy when I just tried to use the example code provided, and it’s what ultimately led to the failure.

    Next Steps

    Take another stab at this, but actually learn the associated methods in the example code, and make my own class, so it will actually function.

    Assembling the Turntable Bevel Gears for a REV Motor

    31 Dec 2019

    Assembling the Turntable Bevel Gears for a REV Motor By Trey and Justin

    Task: Assemble the bevel gears to the turntable to fit a rev motor

    Today we assembled a second version of our bevel gear assembly for the turntable. Our previous design used an Andymark motor, which was very fast but couldn't provide enough torque for precise movement. The custom geared REV motors allow us to power the turntable with our desired torque. This is further explained in our Calculating Torque at the Turntable post dated 2020-01-01 . The Gobilda motor mount was designed to fit motors wit 6 evenly spaced mounting holes, while the new REV motors have 8. We decided that the most efficient solution was to mount a rev rail motor mount to the Gobilda channel. First we had to make sure the holes lined up and the motor shaft was centered in the channel; the holes lined up perfectly and centered the shaft in the channel. The sides of the motor mount were too wide and had to be cut to allow the mount to slide in the channel enough to line up the mounting holes. Due to the apparent standardization of mounting holes, we could easily mount our new motor to the gears. The rest of the assembly was just following the Gobilda instructions for assembling the bevel gears and bearings. We were ready mount the new motor assembly to the turntable.

    Next Steps

    Next we will remove the old motor assembly and replace it with the new one. We also need to test the strength of the mounting plate under the load of the turntable. We should also use the time with the turntable off to inspect the nylon gears for any wear.

    FIRST in Texas Grants

    31 Dec 2019

    FIRST in Texas Grants By Bhanaviya

    Task: Detail the FIRST in Texas Grants and understand how it will improve our business plan

    It's the last day of the decade! With a new decade, comes new money, and similar to last year, Iron Reign is supporting 3 sister teams, Imperial Robotics, Iron Core and Iron Golem, the latter two being veteran teams with rookie members. This programmatic growth also comes with a financial curve to overcome. As such, we've applied to the FIRST in Texas grants to find funding for all 4 of our teams. This allocates a total of $2000 for the Iron Reign program, but if Iron Core and Iron Golem are considered rookies due to their new members, then our program can receive around $4000.

    This, alongside the $3200 from University of Texas at Dallas for hosting the Townview Qualifier, the $200 GoBilda Product Grant and the the $4000 from DISD STEM Department, which covers our season registration fees, 4 REV FTC kits, and a full practice-field. This brings our total funding up to $11,400 for the Skystone Season . There is no end to how this funding can help with finding new parts, and investing in any machinery like our new CNC Mill. Additionally, since Big Thought our programmatic partner who owns the MXP vehicle, has agreed to invest in building a second, bigger vehicle for the program, this funding can also help us in improving our outreach efforts.

    Next Steps

    We have also reached out to other companies in our area for increased funding and we hope to expand on our business plan as the new year progresses. In the meanwhile, we here at Iron Reign wish everyone in the FIRST community a happy almost new year!

    Control Mapping v2

    01 Jan 2020

    Control Mapping v2 By Jose

    Task: Map out the new control scheme

    As we progressively make our robot more autonomous when it comes to repeated tasks, it's time to map these driver enhancements. Since we have so many degrees of freedom with TomBot we will experiment with using two controllers, where one is the main controller for operating the robots and the second handles simpler tasks such as setting the tower height and toggling the foundation hook.

    Next Steps

    We need to experiment with the two-driver system as well as implement a manual override mode and a precision mode where all the controls are slowed down.

    Calculating Torque at the Elbow

    01 Jan 2020

    Calculating Torque at the Elbow By Bhanaviya

    Task: Design an equation to model the torque at the elbow linearly

    In order to maximize our robot performance, we need to be able to use motors and gears with the most ideal gear ratios. This means having the right amount of torque to produce the most efficient performance out of our robot arm. As the arm extends, there is quite a bit of torque on the elbow. We want to model this torque as a function which will allow us to better analyze how much rotational force is being exerted on the elbow and whether the gear ratio of the gears at the elbow could be improved by using a different gear set.

    The torque at the elbow is a dynamic variable that changes as the arm is extended further and further. As such, we decided to model this equation as a function. Torque is generally T = Frsin(theta). F is force which can be derived by multiplying the mass of the arm (m) with g, the acceleration due to gravity. g can be otherwise defined as g = G, the universal gravitational constant, * (m/r * r). r is the distance from the center of mass of the arm when fully retracted to the axis of rotation, which is, in this case, the elbow. This value can be defined by 170.4 meters. However, since the center of mass changes as the arm extends, r is not a constant and as such can be modeled as C + x, where C is the constant for the center of mass when the arm is fully retracted increasing by x, wherein x is the value in meters by which the arm extends. C can be defined by 2358.68 grams. As the arm is extended, the axis of rotation is in motion so theta, the angle in degrees between the vertical and the position of the arm changes linearly and as such, cannot be represented as a constant. However, since this angle is more difficult to derive, and since the angle between the position of the arm and the horizontal is already shown in the code for the controls operating the elbow, theta can simply be stated as 90 - theta_0, wherein theta_0 is the angle between the horizontal and the position of the arm. The torque due to gravity at the elbow can be represented as the function T = 2358.68 grams g(170.4 meters + x)sin(90 - theta_0) wherein theta_0 and x are parameters which can be taken from the articluation positions.

    Next Steps

    Being able to model torque as a function will allow us to understand how much torque is needed for the robot to stack a certain number of stones. By identifying the non-constant values of the torque function, we will be able to analyze what specific values produce the best robot performance, as well as whether that performance can be improved by lightening the load on the arm.

    Logarithmic Spiral Update

    02 Jan 2020

    Logarithmic Spiral Update By Ben

    Task: Update the Logarithmic Spiral

    As the design and build of the robot progresses, many components must be updated to be compatible with the current design. The logarithmic spiral, which was used to linearly decrease the load on the elbow with a bungee cord, is one of these. The article for the original design is numbered as the 45th post in the engineering section and is dated 15-11-2019. Prior to updating the design, the part would interfere with the drive shaft for the elbow. This typically wouldn't have been a concern, as it provided a safe way to limit the movement of the arm, yet we have determined that we need a greater range of motion. To do this, we simply cut a small half-circle out of the spiral. This was a relatively simple fix which would allow us to stack the blocks higher, scoring even more points.

    The next fix was the mechanism for attaching the bungee to the spiral. We plan to attach a bungee from both the front and back of the spiral to generate a greater rotational force. A design issue we encountered was running a bungee to the back of the spiral. There was no simple method for attaching and containing the bungee. To overcome this, we decided we would attach the bungee to a string from the back of the spiral. The final spiral design required two individual machined parts. Each part would have a chamfered edge, forming a channel when the two were put together, allowing the string to run within that channel. The two parts would be connected using three new holes to prevent the string from wedging itself between the two.

    The image below highlights the changes made to the original part. The chamfers along the edge were added along with three holes to connect two of the parts. The half-circle is also highlighted. These changes should enable us to assist the elbow in lifting the arm with greater efficiency than with the previous version of the spiral.

    Next Steps

    Our next steps are to machine the two parts and determine how much tension we need on the bungees to generate enough torque to assist the elbow.

    Calculating Torque at the Drive-Train

    02 Jan 2020

    Calculating Torque at the Drive-Train By Bhanaviya

    Task: Calculate torque at the drive-train and analyze our choice of motors

    During drive-testing, one issue we noticed was that our robot was not as fast as could be, and in a speed-based game, this is not ideal. So, we decided to calculate torque at the drive-train, which currently runs on two Neverest Classic 40 motors. Currently, we are looking to replace these motors with REV HD Hex Motors with a 3-part cartridge. As such, we will find the torque acting on the drive train with both these motors to identify whether replacing the motors is the best choice, and if so, what combinations of a cartridge we ought to use on the new motors.

    Currently, we have 4 gear sprockets for the two 8-inch wheels on the chassis. However, since these are all of the same gear ratio, they do not need to be included in the calculations to find torque. The Classic 40 Neverest motors have a ratio of 40:1 and a stall torque of 2.47 Nm, both of which are values which can be found in the individual part specifications. Using this information, we can find that the torque acting on the drive train to be 2.47Nm * 40 which is a total rotational force of 98.8Nm.

    The Neverest motors give a significantly high amount of torque so looking to reduce it would help us increase the drive-train's speed which is our intended goal. A good replacement would be the REV Hex motors with the planetary cartridge but choosing the type of cartridge is the challenge. Ideally, three 3:1 cartridges would give the least torque but this combination would lack too much control. Especially since our supply of these catridges is limited, we want to choose a combination which gives a "good" amount of torque but also produces a decent speed. Currently, the Neverest motors are not slow and we only want a little more speed on the drive-train. Taking this into account, we want to choose a combination which is closest to the 40:1 ration but still falls under it. So, a combination of 3:1, 4:1, and 5:1 cartridges would be the best choice since it provides a compounded gear ratio of 36:1. Considering the stall torque of the Hex motors to be 2.1 Nm, we can calculate the torque to be 2.1Nm * 36 75.6 Nm.

    Next Steps

    The hex motors with a 36:1 compounded gear ratio are not only the closest in ratio to the Neverest motors, but also have a significantly lower torque with enough to maintain good control. As such, we are going to replace the our current motors on the drive train with this specific cartridge. If we find that the drive-train's performance could be improved, we will find more cartridge combinations or go altogether with a different motor to improve control.

    Calculating Torque at the Turn-table

    02 Jan 2020

    Calculating Torque at the Turn-table By Bhanaviya

    Task: Analyze torque at the turn-table and how it affects our choice of motor sets

    We want to know if we are using the best possible motor set on our turntable. Since our turn-table is programmed to rotate at the fastest possible speed, we are not too concerned with a motor that turns faster but rather one that has a higher level of control and produces a higher output torque. A faster turret gives us less control when we are turning on the field and we want to reduce the time we spend trying to get the turntable in the right orientation. So, it's time to replace its motors. Currently we are using a Neverest orbital motor on the bevel gear on the turret which has a stall torque of 0.23Nm. With a torque this low, we are not utilizing the turret to its maximum capability. We want to replace this with a REV HD Hex Motor with a double planetary cartridge. REV offers a manual which allows the user to see the exact gear ratios and output torque produced by each combination of cartridges. Based on the cartridges we have right now, two 4.1 cartridges have the highest output torque as per the manual. But we don't want to replace our current motor just yet, until we calculate the exact amount of torque and analyze whether this is a good amount.

    The gears operating the turntable are an 8:1 pinion gear and a 2:1 bevel gear. Thus, their compounded gear ratio is 16:1. Using this, we can find the output torque produced by our current motor which can be found by finding the value of 16 * 0.23Nm * 3.7 which gives us an output torque of 33.6. Now, this value can be higher so if we switch out with the double staged 4.1 HD Hex Motor, we get a compounded gear ratio of around 13.1, according to the REV manual. The stall torque for these motors are 2.1Nm which is significantly higher than the amount produced by the orbital motor. Plugging both these values and the 16:1 gear ratio of the turntable gears, we can find that the output torque produced by the turntable REV planetary motors can be found using the equation 16 * 2.1Nm * 13.1, which equates to 440.16 Nm.

    Based on these calculations, we can find that the planetary motors produce a significantly higher amount of torque and will give our turntable much more control and precision when operated. This amount of torque may cause some concern on how much the slower the turntable will be; as such, we also calculated the linear speed of the turret. To do this, we have to find the rotations per minute (RPM) of each motor. The no load RPM for the 3.7 motor is 1780 RPM. By dividing this by its gear ratio, we can find the RPM which is 1780 RPM/3.7Nm which is equal to 481.08m/s. As for the REV motor with more torque, its no-load RPM is 6000 RPM and when divided by its gear ratio of 13.1, we get a linear speed of 458.02m/s.Although this is a lower linear speed, the difference is very little, showing that the new 13.1 motors will not reduce our speed by much but will have a much larger effect on the output torque of the turret, thus maximizing the turntable's efficiency.

    Next Steps

    Since we determined that our current turntable motor needed to be replaced, our next step was to make the physical switch on our bevel gear system on the turret. However, we are yet to test how much of an improvement the replacement will be so that will be our next goal. If we find that the motor set can be further replaced then we will use calculations similar to the ones in the article depending on whether we want to reduce or increase torque. Our next qualifier is this upcoming Saturday, so the new motors should improve our turntable control for the match-play portion.

    STEM Expo Preparation

    03 Jan 2020

    STEM Expo Preparation By Bhanaviya

    Task: Plan for the DISD STEM Expo

    An FLL Team Gathered Around Iron Reign's Robot at the 2019 STEM Expo

    Next week, a week after our second qualifier, Iron Reign along with members from our 3 sister teams, is participating in the DISD STEM Expo for our fourth year. As we have done for the past 3 years, we are bringing the Mobile Learning Experience Lab to the event area in Kay Bailey Hutchinson Center. The purpose of this event is to connect with children in the DISD Area by helping them a foster an appreciation for engineering and the sciences. With the support of the Dallas City of Learning, a non-profit organization operated by Big Thought which helps schedule The Mobile Tech Xperience (MXP), Iron Reign will have a featured exhibit within the MXP. To maximize event productivity, we will be working alongside volunteers from Microsoft and Best Buy who will help us ensure that the exhibit runs smoothly.

    Iron Reign on the Student Passport at the 20202 DISD STEM Expo

    For reference, every year that we have held this event, Microsoft, Best Buy and Big Thought provide volunteers to help teach kids on 3D-modelling and block-programming, the two key highlights of the MXP program. As the youth voice for this program, we teach these volunteers on how to teach the activity to younger students with little to no STEM experience. For the first time in our years organizing a booth, Iron Reign has been recognized as a vendor on the student passports which will be given to all participants!

    As part of the exhibit, we will have events similar to those hosted as part of our summer outreach events. This includes the LEGO Mindstorm Sumo Robots Event as well as our 3D Printing keychains activity. We will also be bringing our field sets, so both us and our sister teams can demonstrate our robots to participants.

    It is worth mentioning that this may be the last year we run this event with the current version of the MXP. Since Big Thought has approved plans for funding a new, larger vehicle, we hope that we will be able to present the new and improved MXP next season, in time for the STEM Expo.

    Next Steps

    At the end of the day, modeling and coding are two of the many aspects encompassed in STEM, and more importantly, FIRST. In introducing these activities, we hope to promote a student initiative in FIRST Robotics. And who knows - tomorrow, we might just meet the future members of Iron Reign.

    Testing Two Drivers

    04 Jan 2020

    Testing Two Drivers By Justin and Aaron

    Task: Practice driving with two drivers

    Today we started testing out our new two controller setup. The goal is to have one driver control just the base, and have the other driver control the arm and turret. With the early stage of the 2 driver code, we were able to practice maneuvering around the field and placing blocks. unfortunately the code wasn't completely sorted, so the turret controller lacked many features that were still on the drive controller.

    An issue we noticed at first was that the drive controls were backwards, which was quickly fixed in code. After the robot was driveable, we spent most of our time practicing picking up blocks and testing out new code presets. Throughout the day we transferred functions between controllers to divide the workload of the robot into the most efficient structure. We found that whoever controls the base should also be responsible for placing the arm in the general area of where it needs to be, then the turret driver can make fine adjustments to grab and place blocks. This setup worked well and allows us to quickly grab stones off the lineup shortly after auto.

    Next Steps

    Next we will practice becoming more fluid with our driving and look for more common driving sequences that can be simplified to a single button.

    Driver Optimization Developments 5/1

    05 Jan 2020

    Driver Optimization Developments 5/1 By Cooper

    Task: Improve driver optimizations

    Today we worked on driver optimizations, since Justin was here. We changed around the controls for the arm to be more like the drivetrain and the D-pad on controller 1, with the left stick by controlling the elbow, the x controlling the turret, and y on the right stick to control the extension of the arm. This was cited to be more natural to the drivers than the previous setup. Then we tuned the PID values for the turret, while also reducing the dampener coefficient of the controller for the turret. Though here we ran into some issues with the dead zone rendering the entire axis of the given controller stick useless, but we shortly fixed it. There was also a problem with our rotateCardinal() method for the turret that we fixed by redoing our direction picking algorithms. Finally, I worked on tuning auto just a tad, but then had to leave.

    Next Steps

    Analyze more driver practice to get more concise controls for the driver, and finish auto.

    Drive Practice 1/6

    06 Jan 2020

    Drive Practice 1/6 By Justin and Aaron

    Task: Practice driving with new code

    Today we worked on driving the robot with new presets. Over the weekend, our coders worked on new presets to speed up our cycling time. The first preset the drivers learned was the cardinal directions, which allows the base driver, but potentially both drivers to quickly rotate the turntable 90 degrees. This made switching from intakeing to stacking directions very fast. To further speed up our stacking time, our coders implemented a stack to tower height, which allows the driver to set a height and the gripper will raise to it. This took a lot of practice to correctly distance the robot from the foundation for the preset to reach the tower. To avoid knocking over our own tower, we decided that the arm driver should stop the 90 degree rotate before it fully turns, so when the arm is extended it goes to the side of the tower, so the driver can rotate the turntable and still place the stone.

    We also worked on dividing the control between the two drivers, which involved transferring functions between controllers. We debated who should have turntable control and decided the base should, but we would like to test giving the turret driver control. The extend to height controls were originally on the drive controller but were moved to the turret to allow for a quicker extension process. The gripper wobble greatly slows down our stacking, even after dampening it.

    Next Steps

    Our next steps are to practice driving for our next qualifier and modify our gripper joint. A lot of our robot issues can be solved with enough drive practice. We need to start exploring other gripper joint options to allow it maintain orientation but not sway.

    Dissecting the Turret

    09 Jan 2020

    Dissecting the Turret By Karina and Cooper

    Task: Figure out why the turntable isn't turning

    Just as Iron Reign was at the point of getting driver practice started and hunkering down to do autonomous, the turntable stopped working. The issue was that there was heavy skipping of teeth between the planetary gear and pinion gear which drove the turntable. Still, there was no obvious reason for why the gears had suddenly disengaged.

    To get to the root of this issue, we took to dissecting TomBot. We had to detach the metal frame which supported the turntable from the chassis just to get a better view of the problem area.

    Ultimately we chalked it up to the metal plates shifting on the polycarbonate circle of the turntable from all the movement. Our solution was to shift everything on the turntable over a small amount in the direction of the point along the planetary gear where the pinion gear engaged so that there would not longer be skipping. We got to work with but drivers and pliers to detach the turntable attachments from the turntable, and then the slip ring, and then the circular polycarbonate plate from the mass of motors, wiring, gears, linear slide, and the gripper that make up the arm. Once we had the circular polycarbonate plate isolated, we used a dremel with a drilling bit to widen the holes through which the bolts attached the entire arm system to the plate. We figured shifting out the turret may alleviate the issue.

    Next Steps

    We will have to find a more solid solution for this in the event that this becomes a recurring problem. I suspect that the underlying cause is that the materials that we used for either printed planetary gear or the polycarbonate plate upon which the whole arm rests could not handle the stress of the torque and speed of the turntable. Going forward we can conduct some material strength tests to determine if they can handle the stress, or if we should find a replacement. To be frank, even after dissecting Tombot, we were not certain about the cause behind the planetary gear disengagement.

    Finger Gripper Morph Chart

    10 Jan 2020

    Finger Gripper Morph Chart By Jose

    Task: Create a morph chart to analyze all our 3-finger gripper versions so far in this season.

    Just like with our gripper designs, we've also gone through a number of changes with our final gripper - the 3 Finger Gripper. This calls for one thing - a morph chart! A morph chart shows us the various subsystems of the 3-finger gripper as it went through its different stages of design. The left axis addresses each part of the gripper like its grip material, back fingers, front finger, and capstone deployer. The right axis shows the different versions of each component visually. Right now, we are at a whopping 4 versions of the same design with 3 grip materials, 3 back and front fingers, and 2 different capstone deployer designs. The latest version has REV Extrusions, a GoBilda plate for the fingers, a red silicon oven-mitts for the grip material (and for helping with the turkey, of course), and no capstone deployer just yet.

    Next Steps

    By putting all of our grippers in one chart, we can see how our gripper has evolved from its humble beginnings, and lets us see which ideas we could possibly recycle. To read about our comprehensive gripper morph chart, visit our article on Gripper Designs Morph Chart. As the finger-gripper undergoes more modifications, we will create another, more updated morph chart later on.

    Match Play at UME prep. Qualifier

    11 Jan 2020

    Match Play at UME prep. Qualifier By Trey, Ben, Aaron, Bhanaviya, Jose, Cooper, Justin, Karina, and Paul

    Task: Compete in Qualification and Finals matches

    Today Iron Reign competed at our second qualifier at UME Preparatory Academy with TomBot which could have been better in terms of autonomous, driver practice, and build. But regardless of this, we were still able to be in the winning alliance and the following are descriptions of the match play that made that happen. For reference, we have a separate post underlining the analysis of the qualifier that does not include match analysis. This post merely details how each one of our matches went, and we will have a future post discussing our drive issues at the competition.

    Match 1(Quals 3)

    Match one was a little bit of a disappointment even though we won 26-19 because we made almost no points from auto (which we didn’t have) or the tele-operated period. The 25 points we did make in the endgame were made because we moved the foundation out of the build zone with the foundation grabber, which didn’t line up very well.

    Match 2(Quals 10)

    With the driver practice from match one, we entered match two, stacked two blocks, and tried to move the foundation again but the grabber kept getting stuck. And it didn’t help that In this match our partnering team did not contribute very much which led to the overall score of 8 vs. the opposing alliance’s score of 55.

    Match 3(Quals 15)

    We won this match 52-15 because of 40 points form the opposing alliance’s penalties and only 12 from what we accomplished. Those 12 points mostly came from moving three stones under the bridge and placing two on the foundation. We didn’t get very many other points because we still can’t move fast enough and sometimes when we place a stone on the foundation we knock it off shortly after.

    Match 4(Quals 17)

    We lost this match by 77 points. This was mostly because we were against 7172 Technical Difficulties and because we still weren’t able to quickly or accurately move blocks onto the foundation, with only one block in the end. We also were still having difficulties with the gripper and the foundation grabber, which kept getting stuck.

    Match 5(Quals 26)

    Things actually started to come together in this match and we won 72-16 because the drivers had a better feel for the robot and we fixed the foundation grabber. In the end, we were able to get 3 stones on the foundation and stack two of them. The other points came from parking and our partnering team’s auto which scored 15 points.

    Semis 1-2

    Contingent on the fact that we would place a capstone on their tower, 7172 decided to make us their second choice alliance partners. Together in the match, we scored 92 points even though, our capstone got stuck in the gripper. This meant that we contributed almost no points to the final score which was sad.

    Finals 2

    In this match we had the same strategy as the last one, sit around with a capstone and place it at the end of the game. The only difference between the placement of this capstone and the other one was that this tower was 2 blocks higher. And even though the tower’s height caused us to mess up and knock the whole thing over, we still won 51-89.

    Next Steps

    Overall, the match play of this qualifier did not go plan. Between the awkward flexibility of the gripper’s attachment point, the jamming of the foundation grabber, the lack of driver practice, and the severe absence of a functional autonomous, we only made up to 20 points per match. And if we want to have any hopes in robot performance at regionals we need to do better in all of the aspects mentioned starting with driver practice and autonomous, the two factors that contributed the most to our overall performance.

    UME Qualifier

    11 Jan 2020

    UME Qualifier By Bhanaviya, Karina, Cooper, Jose, Trey, Aaron, Ben, Justin, and Paul

    Task: Compete at the UME Preparatory Academy Qualifier

    A solid month or so after our first qualifier, Iron Reign walked through the doors to our second qualifier at the UME Preparatory Academy with our three sister teams. Compared to last season, we had gotten significantly more driver and presentation practice, but we still weren't as organized as we could have been and in a robotics qualifier, this is a bit of concern. Nevertheless, we were optimistic (though wildly unprepared) for the day ahead.

    Inspection

    Just like at our first qualifier at Allen, we passed inspection the first time around! While this was a minor victory, it served us well later on in the day.

    Presentation

    Having practiced more the second time round, our presentation ran relatively smoothly. We did lack enthusiasm, however, and as one of the earlier teams to go through judging, this was not ideal. Unlike last time, though, our robot demo worked significantly better. Still, our questioning period could have worked off better and the transition from each question is something we will be focusing on improving before regionals.

    Robot Game

    First off, the turret on our robot had to be entirely dismantled the week of qualifier, and there had been a storm the previous night, and since robots and rain don't generally make a good combination, we didn't have too much driver practice. We had practiced in the couple weeks leading up to the qualifier though, so needless to say, we were in much better shape than previously. For reference, this post will not discuss our robot performance at UME and merely serves as a summary of our day in each sub-category. There will be another post detailing our match-play soon.

    Match-Play

    With a win-loss record of 3-2, our qualification rounds weren't the best. But somehow, we managed to scrape through to be ranked 8th! Our sister teams Iron Golem, Imperial Robotics and Iron Core had placed 6, 10 and 12 respectively, an impressive feat, especially considering that 2 of these 3 were rookies. Though our rank wasn't as stellar as it could have been, we were able to demonstrate TomBot's Tall-Mode and its capping abilities to the 1st seed team Hockabots and them and their alliance partner Technical Difficulties picked us during selections! Additionally, for the first time in the history of our robotics program, all 4 of our teams were selected during alliance selection for the semi-finals match.

    Semifinals & Finals Matches

    Ultimately, our alliance's performance in the semi-finals served us well into our advancement to the finals... until it didn't. Nearing the end of finals, our attempt to cap Technical Difficulties' tower ended up knocking over the stack. Fortunately, our alliance still ended up winning, but finding accuracy in our stacking, especially with regards to capping is something we plan to work on going into regionals. Currently, we have gone through 3 different capstones and capstone-droppers but those still require more testing in order to ensure our capping abilities improve by regionals.

    After-Judging and Awards Ceremony

    While we didn't have high expectations for our success, we did manage to garner several visits from judges to our pits. A good measure of judging success is if the judges come back to talk to you, and at UME, we had four separate groups of judges come up to us and ask us about each component of our team, from business, to outreach, to sustainability, to our robot design.

    In the ceremony, every single member of the SEM Robotics program waited. With all 4 of our teams having made it to semi-finals, this was by far our most successful qualifier match-play wise. Since Iron Reign had already advanced at the previous Allen Qualifier, we were ineligible for the Inspire Award but we were still relatively hopeful. At the end of the day, we were finalists for the Design, Innovate, and Connect awards, closing off our day with 1st Place for the Think Award!

    Next Steps

    Although only one team from our program has advanced to the regionals, this season was successful both on a program and individual-basis. All three of our sister teams performed impressively well at the qualifier, and although their match seasons might be over, their robots still have a while to go. Next week Iron Reign is helping organize and coordinate a booth at the DISD STEM Expo, where all three of our sister teams will be demo-ing their competition robots to students with little to no STEM experience. As the season progresses, Iron Reign is looking forward to recruiting new members from our sister teams, 2-3 at the least. While this may have been our last qualifier, we still have a lot of progress to make leading up to the North Texas Regional Championship. Our post-mortem analysis detailing our performance at UME and preparing for our next tournament will be on our blog soon.

    Growing Pains and Reigns

    16 Jan 2020

    Growing Pains and Reigns By Bhanaviya, Shawn, Mahesh, and Anisha

    Task: Expand the Iron Reign Robotics Team

    One of our biggest challenges this year was learning to adapt our robotics program to the large influx of new recruits. Last year, most of us current members on Iron Reign were the new recruits, so to see the sustainability progress from a whole other outlook this season was at first jarring. However, just like last year, we expanded our robotics program to support 3 teams - Imperial Robotics, Iron Core and Iron Golem, bringing up our program count to a total of 30 active participants.

    Each of these three teams have underwent their own successes and failures through the Skystone Season. However, moving on from our program's last qualifier of the season, it's time to take a look back at our highlights. From competing at a grand total of 2 scrimmages, 2 qualifiers, and hosting one tournament, our program as a whole has progressed to a different, higher level. Moving on from here, our next step is to discuss recruitment for Iron Reign specifically. For reference, our team serves as the varsity team in our robotics program and everything you've seen in this journal thus far is specific to our team. With our regional championship being 3 weeks away, recruitment for our current 9-member team is a question we have yet to answer. As of now, our team comprises of mostly underclassmen - 7 to be exact. Based on this count, and our sub-team specific needs, we have decided to recruit 3 new members from our sister teams as we go into the next level of competition - Shawn Halimman, Mahesh Natamai and Anisha Bhattaru.

    Next Steps

    While we don't have any immediate plans to increase our team count further, we're confident that our 3 newer members will make a strong addition to our program as the season flies. All of us on this team were recruited from one of Iron Reign's sister teams, and being able to expand our team alongside our program will help SEM Robotics remain sustainable for years, if not decades to come.

    DISD STEM Expo 2020

    18 Jan 2020

    DISD STEM Expo 2020 By Ben, Justin, Jose, Cooper, Paul, Trey, Mahesh, and Shawn

    Task: Operate an exhibit at the DISD STEM Expo

    DISD STEM Expo has been our busiest event this year. Many kids, ranging from elementary school to high school visit the expo to learn more about STEM and the great things it has to offer. This is our 4th year bringing the Mobile Tech Xpansion Program to this event, but this will be the last year we bring the MXP as it is. For reference, Big Thought received a grant of $150K last year to expand the program, and the MXP is almost at the end of its pilot stage. This is also the first year we have been named as our own exhibit at the STEM Expo! We accumulated well over 1000 students to our exhibits. Being able to interact with an audience of students this big, many of whom have little to no STEM experience, gave us a great opportunity to not only introduce them to robotics, but also to meet the next generation of engineers. The purpose of this event is to spread STEM programs to students in the Dallas area who otherwise would have no access.

    Although the season has ended for most of Iron Reign Robotics’ teams they were still invited to help us run the exhibit. This gave them the opportunity to get a head-start on their journals for next season by providing an amazing community outreach opportunity. For reference, although all 4 of the teams in our robotics program participate in events like the expo, Team 6832 takes the lead in the MXP events, as Big Thought's programmatic partner for the program, and as the varsity team.

    Preparing for the STEM Expo was a little tricky because the MXP had to be parked in the convention center on Friday night, meaning we had to get all the materials onboard on Thursday. This wasn’t too difficult because most of the learning materials stay on the vehicle. On Saturday morning, we had to setup the practice field, tables, prepare 20+ laptops, reconstruct several sumo-bots, and prepare 4 3D-Printers for the hectic day that was to come.

    The New MXP Floorplan

    Once preparations were complete, iron Reign had to educate the volunteers on how to run the Sumo-Robots session. The Sumo activity required many volunteers, many of which were from Dallas City of Learning or BigThought. We also set up a practice field for our sister teams to demonstrate their robots for our visitors. Inside the MXP, several Iron Reign members hosted a 3D-Printing activity that allowed kids of all ages to build a small keychain and print it on their own. Outside, the vehicle, the rest of us worked with Big Thought volunteers to teach students on how to code an EV3 robot, the kind used in FLL, so that students could experience their first foray into FIRST. Being able to work with Big Thought's volunteers in teaching these students is what sets the expo apart from our other outreach event - apart from the expo being our biggest event of the year, the opportunity to work with these volunteers also gives us a chance to help Big Thought operate the MXP, a role which we hope to continue next year. In addition, since Big Thought approved the purchase for the new, bigger MXP vehicle this year, our team will be helping design the actual vehicle this season as the student voice of this program, and working with Big Thought at events like the expo helps us further solidify that role.

    The great thing about the MXP program is that usually, the participants in these events like the STEM Expo have not had any experience with robotics, and they tend to perceive the concept as something that is beyond them. Being able to show kids that robotics is something that anyone, regardless of age, can understand and enjoy, helps lead them towards considering pursuing a career in STEM. As such, the Expo was a huge success because we were able to reach many students of all ages and technical experience. We met with many VEX IQ and FLL teams and gave them demonstrations of our robots to show them what FTC is about and excite them about their FIRST future.

    Next Steps

    This STEM Expo will be the last Expo with the MXP in its pilot stage. BigThought has officially agreed to purchase the next vehicle with $150K they received in the past year and and move the program out of the pilot stage. We are truly grateful for all of BigThought’s help in maintaining the MXP along with all the help we received today at the Expo! Next year we'll have a bigger and better vehicle which will allow us to reach even more STEM-minded students and show them what they can achieve through FIRST.

    Auto Developments at the STEM Expo

    18 Jan 2020

    Auto Developments at the STEM Expo By Cooper

    Task: Improve autonomous and tune IMU

    During the STEM Expo, while also helping volunteer, we worked on auto. There were a series of cascading events that were planned and completed. The first of which was to calculate the TPM of the base. There was, however, a problem before we did that. Our robot has a slight drift when trying to drive straight, which could be solved by driving based off of the IMU. However, we had discovered a couple of days ago that it doesn’t run. This made no sense, until a critical detail was uncovered -- it sets active to false. With this knowledge, Ahbi sluthed that the action was immediately being completed, since it was in an autonomous path. We then took a break from that and calculated the TPM a different, and far less complex way- we drove it a meter by hand and recorded the tick values. After we did that, we averaged them up, and got 1304, which in the end we decided to use, since just after that Ahbi figured out the problem with the driveIMU() method, and it went perfectly a meter. The issue was rooted in one wrong less-than sign, which was in the if statement to detect if we had gotten to our destination yet.

    Next Steps:

    This is the first time we've actually tuned auto since the UME Qualifier, but now that Mahesh is trying to implement Vision, we plan to improve the sensor capabilities of our robot as well.

    Code Changes At STEM Expo

    18 Jan 2020

    Code Changes At STEM Expo By Mahesh, Cooper, and Abhi

    Task: Use Vuforia To Detect Skystones And Tune Ticks Per Meter

    This Saturday, we had the privilege of being a vendor at the Annual DISD STEM Expo. While this event served as a good way for us to showcase TomBot at our booth, it also gave us the much-needed chance to experiment with vision. With this year's game rewarding 24 points for locating skystones and placing them onto the foundation, vision is an essential element to success. To detect skystones, we could have gone down three distinct paths: OpenCV, Vuforia, or Tensorflow.

    We chose to use Vuforia instead of Tensorflow or OpenCV to detect skystones since the software gave the rotation and translation of the skystones relative to the robot's position, which could then be used to determine the position of the skystone, either left, center, or right. Additionally, Vuforia has proven to work under different lighting conditions and environments in the past, whereas Open CV requires rigorous tuning in order to prove flexible for a variety of field settings.

    The second major task we worked on during the STEM Expo was calibrating ticks per meter. The issue we encountered when driving both wheels forward a set number of ticks was that the robot drifted slightly to the right, either meaning that the wheels are misaligned or that one wheel is larger than the other. To fix this issue, rather than tuning PID Coefficients, we figured out a separate ticks per meter measurement for both wheels, so that one wheel would move less than the other to account for the difference in wheel diameters. After experimenting with different values and tuning appropriately based on results, we arrived at a ticks per meter number for each wheel.

    We could have used a more mathematical approach for calculating ticks per meter, which would be equal to (ticksPerRevolution * driveGearReduction) / (wheelDiameter * PI), with "wheelDiameter" being measured in meters. However, this solution would require a very precise measurement of each wheel's diameter, which our caliper is not wide enough to measure. Additionally, this solution would not account for wheel slippage, and for these reasons, we chose the latter approach.

    Next Steps

    Unfortunately, the vuforia vision pipeline did not work at the STEM Expo, which may be a result of bad lighting or some other code error. Moreover, constants such as the camera's placement relative to the center of the robot have not been measured as of now, which is a task for the future. In order to make sure vuforia is working properly, we should send the camera's feed into FTC Dashboard in order to debug more effectively and pinpoint the issue at hand.

    For last year's game, three different vision pipelines were used, Tensorflow, Vuforia, and OpenCV, and all three were compared for their effectiveness for finding the positions of gold cube mineral. This strategy can be employed for this year as well, since building a robust OpenCV pipeline would be impressive for the control award, and comparing all three options would give us a better idea as to which one works most effectively for this year specifically.

    Snapdragon - The Beginning

    19 Jan 2020

    Snapdragon - The Beginning By Bhanaviya and Aaron

    Task: Begin our 10th gripper design

    As you could probably tell from our plethora of gripper articles, here at Iron Reign we have one too many grippers. And now its time for another one! We could do a whole post-mortem analysis on what went wrong about our build at our last qualifier, but for the most part, the design was consistent, with one underlying exception - our gripper. The finger gripper was a revolutionary piece of work, and has gone through a whopping 4 different iterations. But as all good things, its time must end. The issue was that the finger gripper lacked precision when it turned and was not quick enough in picking up blocks, requiring excessive control on the drivers' end to be able to focus on a stone and pick it up. In a speed-based challenge like this year's, this was not ideal, so it had to go.

    A slapband in action

    In it's place stands the Snapdragon, its quicker, more rugged replacement. The snapdragon functions as a passive gripper - at its core, it works as a slapband would. A slapband is, simply put, a wristband that wraps around one's wrist when slapped with enough force. Similarly, the snapdragon's closing action is an elastic-powered snapping action that is physically triggered when the gripper is lowered onto a stone. It's ability to grip is a direct result of the lower metal "flap" below the larger rectangular plate above. The effectiveness of this flap relies on the precise placement of rubber bands holding the flap to the plate above it. However this also means that the plates must be triggered in a very specific manner so that the gripper closes down at the right time.

    Next Steps

    The beauty of the snapdragon relies on its ability to be self-triggered. However, it would still need to be reset after "snapping". This would require use of a servo. The servo would need to be able to close down on the stone, but this also means that the movement of the gripper needs to be controlled such that it does not snap upon contact with any other surface. Trying to find a balance between this passive action and the servo's movement will be our primary task since the gripper isn't ready to be mounted yet.

    Engineering Notebook Binder CAD

    20 Jan 2020

    Engineering Notebook Binder CAD By Jose

    Task: CAD an engineering notebook binder that is to be custom made

    We want to utilize our new CNC as best as we possibly can. Since we plan to CNC the second version of our current robot TomBot for regionals, the only companion that could serve a CNC-ed robot is a CNC-ed engineering notebook! Plus an aluminum-plated journal would also help us emphasize the iron part of our name to the judges (hi there, if you're reading this!). The first step is to make a CAD file for this binder which is what we have shown above. The most custom part is the cover, it features our team logo, name, team number and even outline of our robot. As per GM1, we can have 2 engineering notebooks so we will make 2 custom notebooks, one that reads "Engineering Section" and another that reads "Team Section". We plan to use piano hinges to joint all the panels of the binder, use polycarbonate as pockets, and steal some binder rings from other binders to be used for these. The panels of the binder will be made of aluminum and the cover will be carved out using our CNC.

    Next Steps

    The outline of our robot, TomBot, may be changed in the future but other than that all we need is to CAM the binder CAD to be able to make it using our CNC. Once the journal is printed, all that's left to do is add the rings, panels, and pockets to the actual binder.

    Snapdragon - The Sequel

    24 Jan 2020

    Snapdragon - The Sequel By Bhanaviya and Aaron

    Task: Improve the precision of the Snapdragon.

    Last week, we prototyped a new gripper called the Snapdragon. Now it's time to give it more complexity. The Snapdragon is a passively-triggered gripper which closes down on a stone upon an impact-heavy contact with it. The main issue we're focused on solving is the impact which triggers the gripper - the gripper needs to be able to close only upon contact with the skystone and not with any other surface. To solve this problem, we added the servo horns, which make the snapdragon look like an actual dragon, for an increased comedic value. Before the servo horns, an abrupt stop by the metal plate of the gripper and the momentum of the "flap" below it were needed to grip a stone but this requires too precise placement of plates. With the addition of the servo horns, the servo horns physically trigger the drop so that the rubber bands holding the gripper in place can be tighter and have more grip.

    In addition to the servo horns, we will also be using a capstone dropper. The capstone dropper is mounted between the two servo horns, and has three small wired which will go through a hole at the base of the capstone. The dropper will be pre-loaded with the capstone and be released during the endgame. The capstone dropper has not yet been tested but we will get to that once we have controls to release the capstone.

    Next Steps

    We need to test the Snapdragon's new version extensively so that our drivers can get a feel for it. Next, since this is a passive gripper model, it would need more grip, so we also need to conduct materials testing on more materials to determine which material has the best grip and can be mounted on the gripper.

    Coding the Snapdragon Gripper

    25 Jan 2020

    Coding the Snapdragon Gripper By Cooper

    Task: Code the new Snapdragon gripper

    Last night we installed the new Snapdragon gripper, which means we needed to re-work the gripper code. We started out by getting the positions the servo would go to using a servo tester. Then we decided whether to make it an articulation, which originally we did. This articulation would set the servo to pull up the gripper front and then return to its relaxed position. After doing some testing, that method was not working.

    So, we moved on to reformatting the gripper update sequence we had for the last gripper. There we still saw no success after that. So, we decided to call it a night, as it was getting late. The next morning, with a clear mind, we realized that the wire connection was flipped on the perf board, wherein after flipping it it worked fine.

    Next Steps:

    We still need to test it with drivers, see if there are any quirks.

    UME Prep Qualifier Cumulative Post-Mortem

    25 Jan 2020

    UME Prep Qualifier Cumulative Post-Mortem By Jose, Bhanaviya, Anisha, Mahesh, Karina, Cooper, Justin, Paul, and Trey

    Task: Analyze what went wrong at the UME Prep Qualifier

    It has officially been one week since the UME Prep Qualifier and we are now 4 weeks away from the Regional Championship. This is not great but it does mean one thing - a post-mortem talk! A post-mortem talk allows us to analyze our performance in full detail and take a closer look at our strengths, weaknesses, potential opportunities and threats in a cumulative SWOT analysis. The analysis itself is detailed by each of our subteams and on our performance throughout the day, and in our preparation efforts. You can see the analysis down below:

    PREPARATION

    Strengths

    • Earlier preparation of the engineering journal
    • Turret needs a better history - in an earlier post?
    • Driver practice
    • Robot Demo
    • Content was organized well
    • Functional (semi) robot
    • Judging Box - more cohesive

    Weaknesses

    • Disaster zone that is a flurry of parts and tools who knows where
    • Pit needs to be better organized
    • N A T U R E
    • There weren't very many match videos that were taken
    • Packing List
    • Need a rack for bags
    • Resizing images
    • A lack of people staying late on Friday
    • Presentation
    • Last minute preparation the day of (logistics)
    • Lack of Autonomous
    • Gripper mounted too late
    • Not enough people for load out
    • Control Award
    • Karina and Ben did all the packing the day of

    Opportunities

    • Afterschool & Sunday Practices
    • Allocating more time to preparation in the weeks before competition instead of days
    • Tent, banners, business cards (for handouts)
    • Post-event follow through: plugging in phones, charging batteries, etc
    • Research posters
    • Control map needs more hype

    Threats

    • Laziness
    • Busy schedules/low priority

    JUDGING

    Strengths

    • We won Think 1st place!
    • Nominated for all awards except Motivate
    • Had a good explanation for robot shape (mentioned center of gravity, turn table)
    • Find a better way to show outreach separation
    • Transitions at slides
    • Very good at redirecting
    • Storytelling
    • Pit visits:
    • Good at getting queues from one another
    • demo worked better than at presentation

    Weaknesses

    • Choices for content that doesn’t link to awards
    • LACK ENERGY
    • Don’t redirect to topics that don’t have a lot of substance
    • Conclude better?
    • Didn’t redirect
    • More calculations based posts
    • Document specific driver calculations
    • Referring back to their questions
    • Clarity about past achievement: We present a lot of information about outreach and prior accomplishments in our presentation but because of the sheer amount of information that we share, judges get the idea that our current team isn’t completely responsible.
    • Hand off between presenters needs to be smoother
    • Having our broom H A T S
    • Having more people at the pits to rep team
    • Did not seed questions
    • Discussing our focus on sustainability effectively (MXP, etc)
    • Needed people placed at pits to talk to judges

    Opportunities

    • Be aware of what a judge is looking for
    • Emphasize that circle helps with strategy
    • Make our binder stand out - create robot manual
    • Create a table for our swivels - qualitative research with Nylon, Ninjaflex
    • Polycarb?, Aluminum swivel, CNC-ed robot

    Threats

    • Not being able to communicate to judges effectively

    ROBOT PERFORMANCE

    Strengths

    • Inspection passed the 1st time
    • Advertised well to 1st seed
    • Physical build was solid
    • Focused on building/improving throughout competition
    • Teamwork

    Weaknesses

    • Learn game strategy, learn to wave
    • Less gripper wobble - fix dropper, improve placement
    • Wire management
    • Set screws

    Opportunities

    • Driver practice - allocate time and practice match play
    • CNC Bot:
    • - Create a base plan + turntable
    • -Gripper less jank: the ninjaflex part could use nylon
    • - Jiggle test?
    • LEDS MAKE BOT LIT
    • Joystick compensates for distance - being able to change heights for extend to tower height
    • Gripper less jank - measure elasticity
    • Slow down arm movement - precision mode
    • Test grippers
    • Collaborating with alliance
    • Fully automatic gripper with distance sensors
    • Completely CNCed robot (base - polycarb with aluminum sides)
    • Articulations - More accurate presets specifically for elbow
    • Dampen swing on gripper
    • BoM with links

    Threats

    • High performing teams(I would have never known!)
    • Time Management(ok…)
    • Acquisition of all parts
    • Enough time for modeling all the robot parts

    SCOUTING & PIT ENGAGEMENT

    Strengths

    • Hand off between presenters needs to be smoother
    • Having more people at the pits to rep team
    • Did not seed questions
    • Discussing our focus on sustainability effectively (MXP, etc)
    • Enthusiasm
    • Organizing pits (backpacks at pits - keep them in car)

    Weaknesses

    • Follow through on checking other teams claims is anecdotal, not systematic
    • Did we get video of all of our matches?
    • Having more people at the pits to rep team
    • Did not seed questions
    • Discussing our focus on sustainability effectively (MXP, etc)
    • Organizing pits (backpacks at pits - keep them in car)

    Opportunities

    • Be aware of what a judge is looking for
    • Make our binder stand out - create robot manual
    • Design pit layout ahead of time (Ben and Paul responsible for this)
    • Dress up our pit with tent and banners
    • HAVE LAPTOP READY WITH IMPORTANT STUFF
    • Center of Gravity for our hats
    • Business cards - have robot
    • 3D printed tiny robots?
    • Detailed accounts for each match we do/play by play
    • Watching other teams’ matches to see how good they are
    • Take the chance to talk to other teams
    • Scouting App

    Threats

    • Sitting around looking at phones looks like disengagement even if we are researching stuff
    • Having one person REIGN during pit visits
    • Lack of data - stats
    • Dominant autonomous teams

    Next Steps:

    We will work to implement the opportunities mentioned as well as rectifying all of the aforementioned errors before regionals. As we get closer to regionals, we will have to update this list, but as of now, it serves as a to-do list for the next following weeks.

    TomBot Calibration Sequence

    31 Jan 2020

    TomBot Calibration Sequence By Cooper

    Task: Create a calibration sequence to find a starting position for autonomous

    Today we worked on the calibration sequence. This has been a problem for awhile now, as the robot has so many degrees of freedom, and not a single flat edge to square off of (other than the guillotine, but that isn’t necessarily orthogonal to anything), it is rather difficult to come up with some way to ensure precision on startup, and this year its integral to the auton.

    To start, the arm is in need of a good way to calibrate. In theory, we have a couple of constants. We have a hard stop to the elbow, thoughtfully provided by the logarithmic spiral. We also can get the ticks from that position to a point that we define as zero. In terms of extension, we have a hard stop on the full retract, which is really all that is needed. So, we start by retracting the arm and increasing the angle of the elbow until it stalls, and we set that as the 0 for the extension. Then, we go down -elbowMax while extending the arm, such that it doesn’t hit the robot, and quickly set that elbow position as the 0 for the robot.

    Previous to this revision, we had different juxtapositions of the robot in terms of the arm and the base, because we couldn’t figure out what was the best compromise of precision and ease. This time around, we decided to have the robot and the arm face the north wall. In this way, the north is common between both alliances and sides, and we can just tell it with a button push which alliance it’s on. So, with that in mind, the next steps of the calibration are to raise up the arm and turn to be orthographically square with the wall. Then, it uses a driveIMUDistance to go back and tap the wall. This is how this sequence will probably stay relatively similar throughout the rest of the time with this robot, as this seems to be what we’ve been trying to achieve for awhile now. There, however, are still things that could be added.

    Next Steps

    In the future, we could add a magnetic limit switch between the turret and the base, so we can automate turning the turntable to the correct position. Also, we could add distance sensors to the (relative) back, left and right, as to ensure that were in the correct position based on the distance to the wall.

    Preparing for the Meeting with Deloitte

    31 Jan 2020

    Preparing for the Meeting with Deloitte By Bhanaviya

    Task: Reach out to companies and their branches in the local Dallas area

    Previously this season, Iron Reign has reached out and presented to various companies and individuals in the Dallas area. So far, we have been able to communicate and present our team to the political, non-profit and engineering sectors, including Representative Colin Allred, Big Thought, Best Buy and the Dallas Personal Robotics Group respectively. The one facet with whom we have not yet gotten in touch with , however, is a multinational corporation. As such, this year, we emailed a representative from Deloitte Touche Tohmatsu Limited, one of the world-wide "Big Four" accounting services, with a request for sponsorship and a meeting.

    This week, we received an email back from Deloitte's Dallas Branch and they've agreed to meet with us! While Deloitte isn't an engineering company, we are specifically meeting with their Bot-Development team and members of the Dallas Branch with an interest and appreciation for robotics. During the meeting, we plan to deliver our usual judging presentation, alongside an introduction to FIRST Tech Challenge and Iron Reign. We also plan to bring TomBot and demonstrate its capabilities. As such, this meeting will focus more on the technical aspects of our team, but we will dedicate a portion to discussing our business plan, specifically the MXP and its expansion, as well as our plans for the rest of the season, moving into, and hopefully beyond regionals.

    Next Steps

    We are incredibly thankful to Deloitte's office for giving us the opportunity to discuss FIRST and our robot with them. As one of the biggest multinational corporations in the Dallas region, we believe this meeting can help us further expand our robotics program nation-wide and further, as we plan to do with the MXP as it moves out of its pilot stage. We look forward to meeting with them this upcoming week.

    Updated Bill of Materials

    01 Feb 2020

    Updated Bill of Materials By Bhanaviya and Paul

    Task: Update the list of parts for TomBot for regionals

    Being around 2 weeks away from the North Texas Regional Championship, Iron Reign has made significant new changes to its Bill of Materials. s of now, TomBot has several build issues that will be discussed in our post-mortem posts. Part of rectifying these issues includes ordering/printing more parts and editing the bill accordingly. But the beauty of the bill of materials relies on the fact that we will be building our second, improved version of TomBot soon - a little after regionals - and having a corresponding bill will streamline this process. We would like to iterate that regardless of whether we qualify at the Regional Championship, Iron Reign's build season will not end with the competition, We plan on furthering ourselves in our build season by creating a more custom version of TomBot, one which incorporates as many custom-cut parts from our CNC mill as possible, and documenting all of our existing parts allows us to better analyze which parts we can possibly custom-cut.

    Next Steps

    We will update the bill after regionals, once we've finalized which parts we can custom-cut and which subsystems need a complete change. As of now, since we've shifted over to a new gripper, this was a big change we had to highlight in the bill and we will continue to do these with our other updated subsystems.

    Preparation for the Dallas Personal Robotics Group Meeting

    01 Feb 2020

    Preparation for the Dallas Personal Robotics Group Meeting By Shawn

    Task: Create a presentation for the Dallas Personal Robotics Group Meeeting Next Week

    In a week, we will be giving a presentation to the Dallas Personal Group, or DPRG. The DPRG is an engineering-based organization in the Dallas area that has monthly meetings to discuss robotics. DPRG has been involved with Iron Reign for years now, and they have volunteered at our annual Townview Qualifier as well as hosted an exhibit with us at Moonday at the Frontiers of Flight Museum this season. They are one of the biggest engineering groups we have connected with this season. In addition, we have been giving them an annual presentation about our build season for the past 4 years, this year being our fifth time. Through our presentation, we hope to gain engineering-based feedback on our robot but also with regards to our overall presentation. Below, you can see DPRG’s preview of our presentation at their monthly meeting.

    Part of the preparation for this presentation includes drive-testing TomBot and getting it ready for demoing. Last year, when we presented our season to them, they provided us feedback with our robot and our vision capabilities, which was pivotal to our accomplishments through the season. As such, alongside the demo, we will also be bringing our judging box, engineering journal and create a separate deck of slides for our code and vision progress this season.

    Next Steps

    The visit to DPRG will be a good opportunity to practice our presentation in front of an actual audience and ask for feedback on our robot and journal. We have been considering a custom binder cover for our journal made out of engraved aluminum, and we also hope to receive feedback on whether we should proceed with this new design or keep our existing binder for regionals. The article about how the presentation went will be detailed in a later post.

    Friction Coefficient and Energy

    02 Feb 2020

    Friction Coefficient and Energy By Trey

    Task: Calculate the friction coefficient of various off-the-shelf materials

    Before our last qualifier, we ran a couple material tests to find the friction coefficient of different materials. Now, since we've upgraded to a new gripper - the Snapdragon - a passive-intake gripper - we will need a newer material with much better grip than the ridged silicone oven-mitt we used for our previous 3-finger gripper. Since our new gripper works by slapping onto a block and clasping it, a better grip material will allow the skystones to latch more easily. As such, we ran a new series of materials tests to find a better material.

    The materials we are testing are a blue ice cube tray, a green oven mitt, a red oven mitt, a black shelving liner, a rubber cement pad, and a plate dipped in Plastidip. Three of these materials we have already tested before, which you can read about in Post 69 of our Engineering Section, but we will still conduct another test on them to keep our values in the new test consistent. The surface we are using is a 24in*24in wooden board. To conduct the tests we put a block on the selected material at the top of the board on its side and its bottom. Then we lifted the board while the block was placed in both positions and measured the height of the top of the board from the ground. We used the average of the heights in both positions to calculate the angle that the board was at using some simple trigonometry seen below. Then we used the friction coefficient equation which you can learn more about here in post 66 of our Engineering Section.

    Blue Silicone Ice Cube Tray

    When the wooden board was lifted, with this material keeping the block on it took 11.5 in until the block started to slide off. Using the equation: sin(θ)=O/H to calculate the angle at which the board was tilted which was 28.63°. Then, using the equation tan(θ)=friction coefficient, we found that the friction coefficient of the blue ice cube tray was 0.55.

    Green Silicone Oven Mitt

    We did the same thing that we did for the blue ice cube tray as we did for the green oven mitt. We lifted the board 12.75 in before the block slipped, which translates to a 32.09° angle, and a friction coefficient of 0.63. This is slightly better than the Blue ice cube tray but not the best by far.

    Red Silicone Oven Mitt

    We ran the same tests on the red oven mitt, the material we have on our robot now, and it was raised 12.5 in before the block started to slip which means that the angle was 31.39° and the friction coefficient was 0.61. This makes it an ok material just like the ice cube tray and the other oven mitt. If we were to use these materials, the grip of the robot would be fine; however, the testing of the materials is not about finding an acceptable material, it is about finding the best material.

    Black shelving liner

    This material was one of the best by far, with a height of 16.5in. The height translated into an angle of 46.43° and a friction coefficient of 0.96 which is a very high friction coefficient. This explains why this material is used on many robots like ours that want to effectively grab blocks. Another interesting note of this material was that unlike, every other material when this material surpassed its limit it didn’t slowly slide down, but it just fell all the way down the board all at once.

    Rubber cement pad

    The rubber cement pad was the most interesting and most effective material. It was made by freeze-drying some rubber cement in a mold. When it was dry it has the friction of a sticky hand. We lifted the board 18 in before the block slipped. That means that we had to lif the board at an angle of 48.59° which means that the friction coefficient was 1.13. The only downside to this material is that it has to be cleaned before match to get the best results out of it. Plastidip. This material was not very good. For one, It does not look very clean because of how clumpy it is. It also only had a height 12 in when the block started to slip, which means that the angle was 30° and the friction coefficient was 0.58.

    Next Steps:

    With these numbers in mind we are now able to decide which material we are going to use on the gripper which is going to be the rubber cement. We also know that for future seasons we can use both the shelf liner and the rubber cement to grab game elements. We are also going to continue to calculate the friction coefficient of different materials so that we can make sure that the Snapdragon gripper is the best it can be. This includes Geko Tape which we might use in the future.

    Post UME Drive Changes

    02 Feb 2020

    Post UME Drive Changes By Justin, Aaron, Trey, and ben

    Task: Improve Robot Driving

    Since the qualifier at UME, we have been focusing on tuning controls to make driving smoother. Our first set of improvements was changed turret controls. The turret driver now could turn slowly with the joystick and quickly with the triggers. This allows the turret driver to quickly move the arm when the base is driving and still be able to stack precisely. Next we noticed that manually moving the arm from a tower to a safe position was faster than our preset recall. We sped up this process to speed up our transport time. Drive practice has increased our capabilities with the robot a lot, and we hope it can make us competition ready.

    The biggest improvement to driving was the addition of the Snapdragon gripper. The gripper allows us to align over a block and slap down to grab. This reduces the precision necessary to grab a stone, and reduces the time it takes to close the gripper. This gripper makes a lot of noise so as soon as the base driver hears the snap he or she should start heading towards the foundation. The increased speed of the turret allows the turret driver to move the arm out of the way while the base moves to the foundation. The use of progressive joystick movement makes precise placement of the base and arm much easier and gives our robot a smoother look in matches.

    We have also made some adjustments to the extend presets for intaking stones. We have added a medium and long distance extension to allow the arm driver to quickly approach the stones, and quickly reach the safe zone from a distance during endgame. Practice with the arm has greatly sped up our cycle time and stacking ability.

    Next Steps

    We plan to continue training our primary drivers as well as secondary drive teams. We plan on playing practicing matches using the other teams' robots to practice moving around a busy field. We also need to make stacking at higher heights easier for the driver.

    Cumulative Drive Test Log 2/3 - 2/6

    06 Feb 2020

    Cumulative Drive Test Log 2/3 - 2/6 By Jose, Justin, and Aaron

    Task: Summarize the driver practice done throughout the week

    Over the course of the following week we have done much driver practice so we can improve our skills as drivers and also make some driver enhancements. On Monday we reached an average of 3.7 stones per match - this includes the endgame procedures but not the stones delivered during the autonomous period. We had a rhythm of driver 1 controlling the drive to have the wheels parallel the driver station wall while grabbing a stone and perpendicular when stacking. Both these alignments help driver 2(who controls the arm) stack much easier.

    On Wednesday we increased our average stones per match to 4.5, with more fine tuning on the movement between the zones and increased coordination we can keep decreasing cycle times. Finally, today we achieves a 5.4 average stones per match, although not very competitive, we are playing with no autonomous or alliance partner. We also got the idea of having a button to automatically raise the arm up and slam down to grab a stone. Since the gripper works similar to a mouse trap, all we need is force to close it and the process of getting this force can be sped up dramatically.

    Next Steps

    To continue to decrease our cycle times we can keep adding driver enhancements as well as learning to coordinate between the two drivers. These improvements will show up in a later post when implemented.

    OpenCV Grip Pipeline

    06 Feb 2020

    OpenCV Grip Pipeline By Mahesh

    Task: Develop An OpenCV GRIP Pipeline To Detect Skystones

    With this year's game awarding 20 points to teams than can successfully locate Skystones during autonomous, a fast and reliable OpenCV Pipeline is necessary to succeed in robot game. Our other two choices, using Vuforia and Tensorflow, were ruled out due to high lighting requirements and slow performance, respectively.

    With many different morphological operations existing in OpenCV and no clear way to visualize them using a control hub and driver station, we used FTC Dashboard to view camera output and change variables realtime. This allowed us to more rapidly debug issues and see operations on an image, like in a driver controller and expansion hub setup.

    To rapidly develop different pipelines, we used GRIP, a program designed specifically for OpenCV testing. After experimenting with different threshold values and operations, we found that a 4 step pipeline like the following would work best.

    The first step is a gaussian blur, used to remove any noise from the raw camera output and smoothen the darkness of the black skystone. Next, a mask is applied to essentially crop the blurred image, allowing the pipeline to focus on only the three stones. An HSV threshold is then applied to retain colors which have low values; essentially black. Afterwards, a blob of white pixels appears near the black skystone, who's center can be determined by using a blob detector, or even by finding contours, filtering them appropriately, and placing a bounding rectangle around them, then taking the center of that rectangle to be close to the centroid of the black skystone blob. Here is a visual representation of each stage of the OpenCV pipeline:

    Next Steps

    The next and only step is to integrate the GRIP pipeline with our existing FTC Webcam capture system, which uses Vuforia to take frames, and decide which x-coordinates of the skystone coorespond to which positions of the skystone. Specifically, we have to take the width of the final images and divide it into three equal sections, then take the boundaries of those three sections to decide the location of each skystone.

    Presenting to Deloitte

    07 Feb 2020

    Presenting to Deloitte By Bhanaviya, Karina, Jose, Aaron, Cooper, Trey, Ben, Paul, Justin, Mahesh, Shawn, and Anisha

    Task: Meet with Deloitte's Bot-Development Team to discuss

    Today, we presented to Deloitte LLC's Bot Development Team in their Dallas branch office to introduce them to our team, our robot, and FIRST. Deloitte is a multinational consulting company and we had reached out to them around 3 weeks ago, with a request for a meeting with their Bot Development Team and they agreed to meet with us last week!

    We gave them our judging presentation but a more extended version of it. Since we were presenting to professionals in bot development with an interest in engineering and robotics, we also spent a significant portion of our presentation demoing our robot for them and answering their questions about this year's challenge, and how our robot's design stood out in solving this challenge. Before we begun our presentation, we also showed them this year's reveal video, giving them more context into our robot capabilities and needs.

    We were also able to discuss the possibility of corporate funding from their office to our team. Especially since this year, we want to construct a new version of TomBot, corporate funding could bring our scope for innovation to whole new level. Once our presentation ended, we had a short Q & A session with the participants, all of whom were very interested in hearing about TomBot's potential and about how we had conceived the idea for its construction and capabilities. ONe feedback we received was that our focus on TomBot's turntable reflected our innovation with regards to our build season strongly. As such, this will be one point which we will be sure to hammer during the actual presentation.

    We even met one professional who had connections to a gecko tape research program at a bio-mimicry lab in Villanova University, and who mentioned she would be able to reach out to the lab to answer any of our questions about potential gripper materials. Since, we are currently looking into implementing gecko tape for our gripper, this was great to hear. Then, we were taken on a tour of their branch, where we were able to see the large variety of tech and virtual media they had implemented across their offices.

    Next Steps

    We would like to thank Deloitte for giving us the amazing opportunity to present at their Dallas branch. We really enjoyed being able to bring FIRST and our robot to their office, and we are incredibly grateful for their interest in our robotics team (and their generosity in providing us with cookies at the end of our visit!). We plan to reach out to them after Regionals, regardless of our qualification status, to find out about the possibility of partnering with them.

    Control And Vision DPRG Presentation

    08 Feb 2020

    Control And Vision DPRG Presentation By Mahesh and Cooper

    Task: Present Control And Vision To DPRG And Gather Feedback

    This saturday, we had the privilege to present our team's Control and Vision algorithms this year to the Dallas Personal Robotics Group. During this event, we described the layout of our robot's control scheme, as well as our OpenCV vision pipeline, in order to gather suggestions for improvement. This opportunity allowed us to improve our pipeline based on the feedback from more than a dozen individuals experienced in the designing, building, and programming of robots. We were able to demo our robot on a playing field, showcasing the mechanics of its design as well as semi-autonomous articulations to help improve driver performance.

    Here are is the slideshow we presented to DPRG:

    For this year's game, we chose a four step vision pipeline to detect skystones, which comprised of a blur, followed by a mask, then an HSV threshold, and finally a blob detector to locate the centroid of the black skystone. Although this pipeline worked fairly well for us, differences in lighting and the environment we are competing in may result in varying degrees of inaccuracy. To combat this, the DPRG suggested we used some kind of flash or LED in order to keep lighting of the stones consistent throughout different settings. However, this may result in specular reflections showing up on the black skystone, which will interfere with our vision pipeline. Another suggestion thrown was to detect the yellow contours in the image, and crop according to the minimum and maximum x and y values of the contour, allowing us to focus on only the three stones on the field and discard colors in the background. This suggestion is particularly useful, since any tilt of the webcam, slight deviation in the calibration sequence, or skystones lying outside the boundaries of the mask will not affect the detection of skystones.

    Next Steps

    The most significant input that DPRG gave us during the presentation was the cropping of skystones based on the size of the yellow contour present in the input image, allowing us to detect the black skystone even if it lies outside the mask. To implement this, we would have to test an HSV threshold to detect yellow contours in the image using GRIP, filtering those yellow contours appropriately, and cropping the input image based on the coordinates of a bounding box placed around the contour. Although this addition is not absolutely necessary it is still a useful add on to our pipeline, and will make performance more reliable.

    Presenting to the DPRG

    08 Feb 2020

    Presenting to the DPRG By Bhanaviya, Cooper, Jose, Justin, Karina, Ben, Mahesh, Paul, Anisha, Shawn, and Trey

    Task: Present to the Dallas Personal Robotics Group about robot vision and Iron Reign

    We reached out to the Dallas Personal Robotics Group to present. The DPRG are an organization in Dallas who have monthly meetings for robotics projects In past seasons, we've given them presentations about our seasonal progress in build and code. This year, we wanted to present again on computer vision, as this is something that they were very interested in, but we also wanted to give our actual presentation as practice for Regionals. Our presentation was advertised here.

    We presented to an audience of around 15. The initial agenda is hosted on our website, but briefly put, we started off by showing them this year's reveal video, gave our judging presentation, demonstrated our robot, and gave them a presentation on our codebase, particularly vision and our usage of the control hub. You can read about the vision presentation in the Post 94 of our Engineering Section. We recieved and answered questions about everything spanning our design, our approach to this year's game challenge, and on our code decisions. The entire presentation went a little over 2 hours. You can find the link to a video of our presentation here. We're going to upload the video here soon. We also asked for feedback from the listeners, especially with respect to our codebase, and our journal organization

    The main feedback we received for the journal was to keep our introduction at the very beginning of the engineering section shorter and more summarizing of the current robot design. We also recieved feedback with regards to over decision to CNC a journal cover - especially to use either a plywood, acryllic or something more metallic for an edgy feel. In terms of vision, we recieved feedback as to crop our skystones based on the contour of the image. A more detailed summary of how our vision presentation went can be found in post 94 of the engineering section.

    Next Steps

    We are incredibly grateful to DPRG for giving us the opportunity to present and showcase our robot at their monthly meeting, and for giving us substantial feedback about our robot and engineering journal. Overall, our presentation to DPRG was a great experience for us to gain insight from a group of engineers on how to improve our robot performance and other factors of our overall standing at NTX Regionals. Regardless of how regionals goes for us, qualification-wise, we plan to reach out to DPRG later on as we move into the next stage of TomBot's build, which is creating a second, CNC-cut version of all of its subsystems.

    Final Weekend Before Regionals - Meeting Log

    08 Feb 2020

    Final Weekend Before Regionals - Meeting Log By Anisha, Cooper, Trey, Paul, Aaron, Bhanaviya, Karina, Justin, Shawn, Mahesh, Jose, and Ben

    Task: Use feedback from our presentation at DPRG and get ready for regionals

    A couple hours ago, we presented our robot at the Dallas Personal Robotics Group (DPRG), and we received insight on not only our robot, but also on our presentation, codebase, and our engineering journals. With this feedback in mind, and considering that we have a week before regionals, Iron Reign returned to the RoboDojo to do what we do best - panic, cram at the last minute, and repeat. (For reference, all our subteams will go into detail about their version of the scramble before regionals in separate posts. This is just a broader summary of our meeting).

    Today, the Code team mainly worked on improving driver controls, improving the implementation of a GRIP pipeline, and finalizing our autonomous path before regionals. Having just returned from presenting the works of our code-base at the DPRG presentation, the code team gained more insight on improving TomBot’s autonomous which will be their focus leading up to regionals.

    The Build team worked on Plasti Dipping the bottom of the foundation grabber for better grip when dragging the foundation. Plasti dip forms a layer of rubber on top of whatever’s being dipped in it and makes it stickier. Unfortunately later on, problems were discovered with the turntable. There had previously been cracks in the turntable from previous driving incidents but now they had gotten worse and were interfering with TomBot’s wheels. Because of a part of the turntable hanging off, the chain was being interfered with and stopping the robot. This was one of the most important tasks to do because obviously, without a functioning robot, there ain’t gonna be dubs at the competition.

    Before the problems with the turntable revealed themselves, our drivers got a decent amount of driver practice. They mainly focused on stacking as fast/efficient as possible. Towards the end of practice, they were also able to train new members of the team on driving. During practice, they also collaborated with the coders on improving the controls.

    The editorial team mainly focused on adding some finishing touches to the judging presentation after getting some great feedback from the Deloitte, and DPRG presentations (both of which have separate entries in our team section). They also worked on creating a research poster and a timeline of our notable events this past season to display at our pit during regionals.

    The design team mainly worked on improving the polycarb base of TomBot’s drive-train to CNC after regionals. To claify, our team is planning on creating a fully CNC-ed version of TomBot after regionals, regardless of whether we qualify to the next level of competition. As such, finalizing the CAD designs of each robot system will better prepare us to CAM these parts to create the next version of our robot. However, we currently plan to still replace the current polycarb base with the custom one since as mentioned earlier, our current base is not in the best shape. The design team also worked on creating a model of our pit design for regionals, which you can see down below. Having a well-organized pit benefits both us and any pit visitors, and regionals was no exception. Finally, they also worked on the CAM of the binder for both our Team and Engineering Sections, which will be custom-cut in aluminium using our CNC mill. For more information on the to-be CNC-ed binder, you can take a look at the “Engineering Notebook Binder CAD” post.

    Next Steps

    Although we had a significant amount of progress today, there's still plenty to do. Over the next weelk, our main goals will be finalizing our autonomous, getting our binder and new polycarb base manufactured, and ensuring that our journals and posters are ready to print for regionals.

    Designing a New Build Plate

    09 Feb 2020

    Designing a New Build Plate By Ben

    Task: Model and CNC a new build plate for TomBot

    The renowned architect Frank Lloyd Wright once said, “The longer I live, the more beautiful life becomes.” This, however, is not the case for our build plate. Throughout the course of the season the plate has seen extensive use and has endured much abuse, which can be seen in the large cracks forming on the plate. Although there are many temporary remedies, such as attaching plates to hold it together. These are not permanent solutions and not only appear bad, but can only temporarily reduce the problem, as more cracks will inevitably form.

    The first build plate was cut from Polycarb on a bandsaw from a pattern. This process resulted in many imperfections and uneven cutting, subtracting from the sleek circular design. This second time around we’re going to completely CNC the whole plate, including the wholes for bolts and wires. Using a CNC ensures a greater precision and guarantees a higher quality build plate.

    Cracks weren’t the only problems facing the first build plate. Drive testing revealed a major flaw with the design, the flaps that folded down from the plate were too short, causing the foundation to get stuck under the robot during matches. This is obviously undesirable as no one likes a robot who drags a giant plastic plate around the whole match. To fix this we just slightly extended those flaps on the model to extend past the height of the foundation. There was also another issue, the bolts that secured the omni-wheels to the build plate were difficult to access because they were to close to one of the Rev rails. To fix this we just slightly increased that distance but also had to ensure that there was enough length on the ends of the axle to comfortably secure the wheel mounts. Other, smaller, issues such as wiring holes were also solved by providing adequate space for wiring next to the expansion hub mount.

    Above you can see an image of the completed build plate. To ensure accuracy one side was developed them mirrored. This removes any variability within the model and creates a symmetric object. The screw holes were created by imposing the turret mounts and rev rails from the previous robot model onto the current one, providing an accurate placement for each hole.

    Next Steps:

    After completing the model, we will print the pattern on a large sheet of paper and verify the placement of all the components that are to be attached. If there are any inaccuracies they will be fixed. We then have to develop a CAM path for the CNC machine. Construction of the second robot will begin once the second plate is completed.

    Big Thoughts for xPansion

    09 Feb 2020

    Big Thoughts for xPansion By Bhanaviya

    Task: Put the budgetary and technical plans for the second MXP in motion

    A long, long time ago, - well, 4 years ago really - alumni members of Iron Reign converted an old 90’s RV into a fully equipped Mobile Learning Lab with 3D-printers and FLL robots. Today, this vehicle is operated by Big Thought, funded by Best Buy and other donors, and taken to outreach events, by our team, Team 6832, where we introduce children with little to no STEM experience to robotics, and FIRST. We call this program the Mobile Tech xPerience and it’s been in service for around 4 years now! For reference, in the outreach events we take the MXP to, both our team and our sister teams participate, however, Iron Reign 6832 takes the lead in these events , from the set-up, to interacting with younger participants, and training Big Thought’s volunteers, to whom we show how we teach younger students block programming and 3D-modelling.

    Our team specifically and Big Thought, a Dallas-based company, are programmatic partners of the MXP program. Through the success of this program, Team 6832 has proven that the concept of a STEM classroom works, and this has inspired other organizations, like the Girl Scouts of Desert Southwest, who have reached out to us about creating their own version of the MXP.

    With the influence the MXP has had on students in underserved areas of the Dallas community, Big Thought was motivated to make the decision in 2019 to upgrade to a second, bigger version of the vehicle, and as their programmatic partner, our team has been heavily involved in the process, from creating the floorplan to actively seeking out sponsors like congressional representatives and multinational companies like Deloitte. However, this week, we are pleased to announce that Big Thought has voted to begin the budgetary and physical planning of the second vehicle and Iron Reign - 6832 has been provided a budget of $400,000 to map out the utilities and technology of the second vehicle. Additionally, we have been tasked with the responsibility of creating a virtual blueprint and model for the second vehicle in CAD, which Big Thought’s professional engineers and architects will use to complete the physical construction of the vehicle. The new vehicle is expected to have a digital media aspect, with a green screen wall and voiceover booth, and the floorplan will include a wheelchair access lift and 2 slide outs.

    The senior director for the Dallas City of Learning - a Big Thought program which encompasses the MXP program - has created an official title for 6832’s members as the Mobile STEM Ambassadors for the second vehicle. The first MXP was just a concept - a pilot program. The second however will be bringing this concept to reality and it is expected to be unveiled in the summer of 2020. Unlike the first, the newer one will be staffed year-round, meaning that while our team members are off doing non-robotics based activities, like school, Big Thought’s team for the MXP will be filling our roles, keeping the vehicle as sustainable as it can be in one season. The idea is still the same - bringing STEM and FIRST robotics to students who haven’t yet seen its potential - but the quality of execution will improve significantly, with our team, Team 6832 Iron Reign, still taking the lead on the MXP program during its larger outreach events.

    Next Steps:

    Once the new vehicle is unveiled, we expect to go on more deployments as opposed to our normal count in the summer. In the meanwhile, we look forward to planning out the virtual model of the second MXP and discussing how best to use the $400,000 budget big thought has authorized for the planning, going into and after regionals.

    Research Poster

    09 Feb 2020

    Task: Create a poster encompassing all of our calculations from this season

    From analyzing the friction coefficient of a variety of different materials, to calculating torque for our various robot sub-assemblies, and creating an equation for our tower-stacking abilities in our autonomous, Iron Reign has seen several different series' of calculations this season. Since these calculations are spread throughout our journal, we have compiled all of them in a single poster for us, and visitors to our pit to refer to at the NTX Regional Championship. Below, you can see how the chart is organized:

    Torque and Gear Ratios

    The first column covers the torque and gear ratios of TomBot's elbow and drive-train. You can read about these calculations in Calculating Torque at the Elbow and Calculating Torque at the Drive-Train which are posts 75 and 78 of the Engineering Section respectively.

    The second column also covers torque and gear ratios but this one focuses more on the torque of the turntable and on the logarithmic spiral, a custom-made part by our team to linearly reduce the torque on the elbow. You can read about these calculations in post 79 for the turntable, and 45 as well as 76 for the logarithmic spiral.

    Materials Testing

    The third column focuses on calculating the friction coefficient of various materials like silicone oven-mitts and rubber cement, which we used for our gripper materials. You can find the math behind the decision to use these materials in post 66, 69 and 91 of the Engineering Section.

    Extend to Tower Height

    The final column focuses on a method we implemented in our drive-controls which uses trigonometry to automatically calculate the height needed for the arm to extend to place a stone at a specific tower height. You can read about this method in post 68 of the Engineering Section.

    To take a closer look at these calculations compiled together, you can take a look at the chart in the very front pocket, or come visit us in our pits to see a much larger version of this math!

    Spicy Side Shields

    10 Feb 2020

    Spicy Side Shields By Jose

    Task: Design and CAD/CAM some spicy side shields

    In order to increase the spice factor for TomBot, we need to custom machine our own side plates out of aluminum using our CNC. The design is pretty simple, just a plate with our team number, but there are some other features such as the curved top. This keeps the side plates from being sharp and add some aesthetic to the design. Also, since the team number is to be put out of the aluminum, the circles inside the '8' need some strokes to keep them in place. To follow the font used these were at a set angle and thickness as seen above. The stroke for the '6' was also thickened to add some support as previous years' side shields have proven this stroke to be weak. Finally, there are holes on the top corners for the alliance markers. The idea for these is that a rectangle with both a blue circle and a red square is screwed to the top and is spun to show the color corresponding to the alliance we are in while the other color is hidden behind the side shield(of the spicy variety).

    Next Steps:

    With a CAM file of these (if not already obvious)spicy side shields already made we can immediately machine these on our CNC during our next meet as well as screw them onto TomBot. Since we have a circular chassis we will have to bend the aluminum, which shouldn't be too hard.

    Milling The Side Shields

    14 Feb 2020

    Milling The Side Shields By Jose, Justin, Trey, Paul, and Shawn

    Task: Mill the spicy side shields for the competition tomorrow

    In typical Iron Reign fashion we are making our side shields the night before regionals, as with many other things. The paper side plates look too jank on our robot that we are trying to make look professional, so we are going to use aluminum instead (a post covering the CAD and CAM of these can be found in a previous post). Since we are still fairly new to using our CNC it took us a while to get started, we broke 8 3mm mills before any major portion of the first side plate was done. After a few hours we were able to complete the milling of the numbers which we can use to label things like CartBot. To finish quickly as we were getting impatient, we used a 6mm flat mill to do the outside contour, some loose placement of the aluminum led to it drifting as this final stage occurred, but overall it finished quite well! After all these hours of suffering we still had to mill a second one this took a while, but not as long since we were used to the procedure.

    Next Steps:

    All that's left is to show off these aluminum side plates tomorrow at regionals!

    The Night Before Regionals - Code

    14 Feb 2020

    The Night Before Regionals - Code By Cooper and Trey

    Task: Fix our autonomous path the night before regionals.

    Twas the night before regionals, and all through the house, every creature was stirring, especially the raccoons, and boy are they loud.

    Anyways, it’s just me and Trey pulling an all nighter tonight, such that he can work on build and I can work on auto. Right now the auto is in a pretty decent shape, as we have the grabbing of one stone and then the pulling of the foundation, but we need to marry the two. So our plan is to use The distance sensors on the front and sides of the robot to position ourselves for the pull.

    Another thing we are working on is a problem with our bot that is compounded with a problem with our field. Our robot has a wheel that is just slightly bigger than the other. This leads to drift, if the imu was not used. But since our field has a slope to it, it drifts horizontally, which is not fixable with just the imu. So we plan to use a correction method, where the distance from where we want to go and the distance to the block to create a triangle from which we should be able to get the angle at which we need to go and how far we should go to end up perfectly spaced from the side of the build platform.

    Our final task tonight is to simply speed up the auto. Right now we have points at which the robot has to stop so that we don’t overshoot things, but that is fixable without stopping the robot.

    Next Steps

    Mirror the auto onto blue side and practice going from auto to teleop

    Wylie Regionals 2020

    15 Feb 2020

    Wylie Regionals 2020 By Bhanaviya, Cooper, Trey, Justin, Karina, Aaron, Paul, Ben, Shawn, Jose, Mahesh, and Anisha

    Task: Compete at the North Texas Regional Tournament

    Preparation

    Breaking our packing-the-night-before streak, we managed to start the night before. It helped that we had the day before the big day off, and had a decent sized packing list. Over the course of our preparation, we had our side-shields machined, presentation practiced, journals prepared, and autonomous in feverish motion. More detail on our last-minute robotics onslaughts will be detailed in a separate post, but to summarize, we were (mostly!) ready to go.

    Inspection

    We passed! This is one streak we haven't yet broken which is bit of a relief.

    Pit Decorum

    Unlike last season, our pit was much better organized and planned this year, decked with Roman Galea, 4 posters, and of course, Ducky. The clean outlook of our pit drew several visitors, including teams who wanted to get a chance at trying on our helmets.

    Judging

    Compared out last two qualifiers, we had much more practice at our presentation this time around, and we tried to maintain a decent amount of energy during the real deal. Unfortunately, after being accustomed to longer presentations from our visits to DPRG and Deloitte (which you can read about in earlier posts!), we were cut short. However, we were able to address most of the things we couldn't cover in our first 5 minutes during the questioning period, and the dmeoing of our turret on TomBot - our most unique subassembly. The overall outlook we presented, however, could have been more charismatic, which was our main concern after the session.

    Pit Visits

    However, we were able to bring back more energy during our pit visits. We recieved three panels of judges for what we guess were Connect, Motivate and Innovate panels. We were able to direct our visits to the posters in our pits, and something we recieved a lot of attention for was our financial and technical plans for the second MXP, which you can read about in T-50.

    Iron Reign: Bringing back Imperial Roman Energy since 2010

    Robot Game

    We will have a separate post detailing our match play-by-play and the technical and human errors in each one. Overall however, our match performance could have been better. During our first 4 rounds we experienced losses, finally scraping through and pulling a victory during our final two. However, from both an awards and rank perspective losing a match is never great since part of the picture is the consistent functionality of at least one sub-assembly. We did not employ the functionality as well as it could have been, with regards to our autonomous, tele-op and endgame and this is something we will be focusing on extensively going into the build of our second robot.

    Awards Ceremony

    By the time the ceremony started, our energy levels were not stellar, especially considering a lack of sleep from the previous night. However, our energy quickly skyrocketed when we first received a finalist for the Control award! Following this, we also recieved the Connect Award, which was exciting especially considering that our plans for the MXP and its expansion were put into drive this season. Then, we were nominated as a finalist for the Think award! And finally, as Inspire nominations were beginning to come up, we heard the announcement, "Inspire 3rd place goes to Team 6832 Iron Reign!" It was safe to say at that point, that Houston, we did indeed have a problem.

    Next Steps

    This season being our 3rd moving into the World Championship, we couldn't have done it without our partners and sponsors, the DISD STEM Department, Mr Andrew Palacios, our principal, our sponsor Mr John Gray ,and the VIrani-Lux family! It's worth mentioning that this is the first time where 3 DISD teams, in addition to our own, are moving onto Worlds! Our main goals moving into Worlds will be preparing for our next competition, the UIL Competition for Texas, and in solidfying the creation of the second version of our robot. We will be detailing our post-mortems and these preparations in the upcoming few posts. Until then, see y'all in Houston!

    Driving at Regionals

    15 Feb 2020

    Driving at Regionals By Justin, Aaron, and Jose

    Task: Drive at Regionals

    Driving at regionals was unfortunately a learning opportunity for our drivers. In our first few matches, for some reason we couldn't get our robot moving; we faced code crashes, cables being pulled, and incorrect calibration during the transition from autonomous to tele-op. These issues combined with our weak autonomous (sorry coders), led to a very unimpressive robot performance for our first few matches.

    When we finally got our robot working, our lack of practice and coordination really showed. The lack of coordination between these drivers and coders resulted in drivers relying on manual controls, rather than preset articulations. Our articulations were also very harsh and untested, some resulting in constant gear grinding, which pushed the drivers to use manual controls. This slowed down our robot and made us very inneficient at cycling. The presets that gave us the most issues were transitioning from stacking or intaking to moving. The intake to north preset, which pointed the arm north after picking up a block, practically tossed the stones we picked up out of our gripper. The stacking to intake preset, which raised the arm off of a tower and pointed it south, would keep raisign the arm up, stripping the gears. This made us rely on our very slow manual arm and turntable controls. A failure in the capstone mechanism caused the capstone to fall off the robot during matches. With all of these issues, we stacked at most three stones during a match; not nearly enough to make us a considerable team for alliance selection.

    Next Steps

    We need to get consistent driver practice while coordinating with coders about the effectiveness of their presets. Many of our failures at regionals could be solved by driver practice. Our drivers being comfortable with the robot, both manually and with presets, would allow us to stack much faster and speed up the robot's in code to make our robot as efficient as possible.

    Match Play at North Texas Regional Championship

    15 Feb 2020

    Match Play at North Texas Regional Championship By Trey, Ben, Aaron, Bhanaviya, Jose, Cooper, Justin, Karina, Paul, Shwan, Mahesh, and Anisha

    Task: Compete in Qualification and Finals matches

    Today Iron Reign competed at the North Texas Regional Championship with TomBot which was a mess, to say the least. But regardless of this, we were still able to win a few matches and qualify for worlds, which we should be able to do much better in. But regardless of this, we were still able to be in the winning alliance and the following are descriptions of the match play that made that happen. For reference, we have a separate post underlining the analysis of the qualifier that does not include match analysis. This post merely details how each one of our matches went, and we will have a future post discussing our drive issues at the competition.

    Match 1(Quals 2)

    We lost this match 51-148 because our robot contributed almost nothing to the alliance’s total score. What we did contribute consisted of two stacked blocks and parking. The other points in the match came from the other robot which stacked 4 blocks into a tower that later fell. However, their auto did the most for the outcome, racking up a total of 12 points. Overall, it was a pretty disappointing match that set the tone for the rest of the day.

    Match 2(Quals 7)

    At this point, most of us were thinking “this couldn’t get worse, could it?”. But we were very wrong. The reason why we lost this match 20-64 was that we were prevented from running the calibration sequence before the match. This plus a Vufora fail at the start of the match made our arm stuck at a 45-degree angle for the whole match. And on top of that, the other robot in our alliance disconnected. The only points we made were from moving the foundation out of the building zone and parking in the end game.

    Match 3(Quals 13)

    Continuing on the downward slope, somehow we managed to do worse with a functional arm. Losing this match 14-67, this may have been the lowest point of the day. Some of the faults with our robot in the match were being the only team without an auto, taking more than 10 seconds to pick up a block, repeatedly dropping blocks, and not parking in time.

    Match 4(Quals 20)

    After seeing us stoop as low as we did last match, the head judge, Freid, decided that he needed to talk to us and try to get us to do better. He gave us an inspirational speech about how we are going to have to live with the results of the competition for the rest of our lives and when we look back we would regret it if we didn’t give it our all. This helped us pick up our act and things started to get better. However, our robot disconnected mid-match and we lost 15-77.

    Match 5(Quals 29)

    Somehow the combination of 8 matches worth of time to prepare for the next match and Freid’s talk picked us up enough to win this match. With a lead of 9 points, we won our first match of the day 65-56. However, as seen by the low margin, this doesn’t mean our robot is never going to lose another match again. There were still many problems like how our auto still didn’t function and how the gripper still took to long to pick up blocks.

    Match 6(Quals 33)

    This was our last and most successful match of the day. We won 75-64, however, once again it should not go without mention that our alliance partners scored most of these points and stacked over half of the 6 stone tall tower. But it is also important to mention that our robot, and more importantly our drivers, preformed way better in this match than any of the other matches so we were clearly making progress.

    Next Steps

    After reading a short summary of the disappointing match play we had at regionals, it would be easy for one to point their finger at a particular team involved in the physical build and design of the robot. However, these results are a result of a failure to collaborate between teams and preform within teams. For example, it was common to see builders and coders need the robot at the same time. The solution to this problem was building a second version of the robot so that coders have their own robot and builders have their own robot. This will reduce friction between the two teams and overall, increase the efficiency of the overall team which will put us in a better spot for worlds, where we will hopefully not lose 4 matches.

    Wylie East Regional Qualifier Code Post-Mortem

    15 Feb 2020

    Wylie East Regional Qualifier Code Post-Mortem By Mahesh and Cooper

    Task: Reflect On Code Changes And Choices Made During The Wylie East Regional Qualifier

    Despite putting in lots of effort in order to pull off a working autonomous before regionals, small and subtle issues that surfaced only during testing at the competition as well as various other small bugs with our autonomous routine prevented us from performing well on the field. Trying to write a full autonomous in the last week before competition was a huge mistake, and if more time was dedicated to testing, tuning, and debugging small issues with our code base, we could have accentuated the theoretical aspect of our code with actual gameplay on the field. The issues experienced during the Wylie East Qualifier can be boiled down to the following:

    Improper Shutdown / Initialization of the Webcam and Vuforia

    We frequently encountered vuforia instantiation exceptions after attempting to initialize the camera after an abrupt stop. We suspect this issue to have originated from the improper shutdown of the Webcam, which would likely result from an abrupt stop / abort. During later runs of our autonomous and teleop with multiple, more complex vision pipelines, we saw that attempting to reinstantiate Vuforia after it has already been instantiated resulted in an exception being thrown. This issue caused us to not play in certain matches, since our program was either stalled or its execution was delayed from restarting the robot.

    Disconnection Of The Webcam (Inability To Access Camera From Rev Hub)

    Ocassionally when attempting to initialize our robot, we saw a warning pop up on the driver station which read "Unable to recognize webcam with serial ID ..." indicating that either the webcam had been disconnected or was for some other reason not recognized by the rev hub. On physical inspection of the robot, the webcam appeared to be connected to the robot via USB. The solution we came up with was to quickly disconnect and reconnect the webcam, after which the warning disappeared.

    This issue prevailed in other forms on the competition field, however. Sometimes, during gameplay, when the webcam was accessed, the blue lights on the rim of our webcam would not light up (meaning that the webcam was not active), and our program would stall on skystone detection. This happened despite getting rid of the driver station, warning, and is most likely another result of improper initialization / shutdown of vuforia after an abrupt stop or abort.

    State Machine Issues

    At the end of our autonomous, if the statemachine had completed, our robot would proceed to spin slowly in a circle indefinately. This unexpected behaviour was stopped using a stopAll() function which set all motor power values to zero, effectively preventing any functions which messed with the robot's movement to be ignored at the end of our statemachine's execution.

    Lack of Testing / Tuning

    By far the biggest reason why we did not perform as predicted at the qualifier was because of the lack of testing and tuning of autonomous routines. This would include running our statemachines multiple times to fine tune values to minimize error, and debug any arising issues like those that we experience during the competition. A lack of tuning made the time spent on our skystone detection pipeline completely useless as our crane did not extend to the right length in order to pick up the skystone, a direct result of inadequate testing. All of the above issues could have been prevented if they had surfaced during extensive testing, which we did not do, and will make sure we follow in the future.

    Next Steps:

    In the future, we ultimately plan to put a freeze on our codebase at least 1 week before competition, so that the remaining time can be spend for building, driver practice, etc. Additionally, we have agreed to extensively test any new additions to our codebase, and assess their effect on other subsystems before deploying them onto our robot.

    The Revenge of TomBot

    16 Feb 2020

    The Revenge of TomBot By Bhanaviya

    Introducing...The Revenge of TomBot!

    A long time ago in a galaxy far, far away there was a robot named TomBot. TomBot was a circle, a spinning circle with a turret and an arm that could extend to glory. Sadly, his reign was not destined for longevity - his cruel creators cut it short before he could enrich the FIRST world with his greatness. But TomBot remained scheming for many, many days, and in his wake followed... The Revenge of TomBot.

    That's right, we're building another robot! Even before our disasterous robot performance at the North Texas Regional Championship, we realized that our current robot, TomBot, lacked one defining one feature - class. Of course, only way to give a robot class is to bring a CNC Mill into the picture. The essential design of the robot will remain the same, but all parts, from the polycarb base to the the turntable mounts will be custom-cut and designed. Being able to custom mill our parts for every subsystem of the robot will also give us better control over the functionality of TomBot's design.

    Next Steps

    We will still be using TomBot in its original version for testing our code and drive practice and their corresponding blog posts. However, from this point onwards, every build post in our engineering section will refer specifically to our new robot - The Revenge of TomBot, coming to theatres near you.

    Meeting Log Post Regionals

    22 Feb 2020

    Meeting Log Post Regionals By Anisha

    Task: Get back to work after Regionals

    Alright kids, back to the usual grind now. As Iron Reign came back from regionals taking a lot away from it, we immediately got back to work because we still had a lot to do before being ready for UIL or Worlds.

    Because one of our main weaknesses at regionals was autonomous, our coders came back even more ready than ever to start working again. They worked collaboratively to continue calibrating the code for the most efficient and consistent function of the autonomous and also continued their work in Vuforia so it could systematically detect Skystones. They will continue to code autonomous and calibrate each and every part of it for consistent function in the next couple of weeks and hopefully by UIL we’ll have a really fresh auton.

    Since Tombot hung out with the coders majority of the time for auton testing, the builders mostly had a chill day, brainstorming new ideas on how some parts of the robot could be improved, so that when they build the new robot, it can be really clean. Some people even helped out by trying to organize different parts that were found all over the Iron Reign Headquarters so that in the future when building picks up again, people wouldn’t have to flip the premises upside down just to find a single part. Doing this also helped free up some space inside the house and it was here where we realized how much room it actually had.

    The modelling team worked on the finishing touches of the build plate for the new robot so that it can be CNC'd ASAP. They also worked on modelling the other parts of the robot, making frequent visits to where Tombot resided for accurate measurements of the parts.

    The editorial team worked on really reflecting on how our presentations went at regionals to analyze what the team can improve on. They also worked on figuring out what really worked for the award blurbs in the journal and what weren’t too clear because after all, the judges shouldn’t feel overwhelmed by the thick journals.

    Next Steps

    Overall it was a pretty productive meeting considering that it was the first after regionals and we look forward to making rapid progress in the next couple of weeks. Although Houston feel like a long time away, we know they’ll arrive quicker than anticipated.

    Wylie East Regionals Post Mortem

    22 Feb 2020

    Wylie East Regionals Post Mortem By Karina, Bhanaviya, Jose, Justin, Ben, Cooper, Mahesh, Shawn, and Trey

    Task: Reflect on what went right and wrong at the regionals tournament

    Iron Reign is so excited to be advancing to the World Championship. But there's no denying that across the board, we did not perform as well as we were expecting. Following the long day, first we feasted as per tradition. But then at a later time, we all sat down to discuss where things could have gone wrong, and found that in the weeks leading up to the regionals tournament, our team was already showing signs of underperformance. This is more of a long term issue that needs to be adressed, starting with in depth retrospection and a frank conversation among ourselves.

    Preparation

    Strengths
    • We had more than two people packing
    • Journal was printed and tabbed and color-coded and everything the night before
    • We kind of had a packing list going
    • The gamer station we made proved to be worthwhile
    Weaknesses
    • We did not check off of a packing list as we loaded the vehicles (we could have missed something)
    • Very little dedicated drive practice and so coordination between the two drivers was lacking
    • We goofed on printing the timeline that shows events we have gone to, professionals we have met with, progression of the robot, etc.
    Opportunities
    • log drive practice hours and scores
    • Aim to have a code freeze so driver don't have to deal with unexpected changes
    • Split the robot manual into two different documents: one that shows and summarizes each subsystem and one that lists step by step how to build TomBot
    • Fix the loose broom heads on the hats (but this is definitely not a priority)
    Threats
    • Not having everything with us due to travel restricted packing

    Judging

    Strengths
    • We got 3rd place Inspire, 3rd place Think, and 1st place Connect which we can probably say was due to the engineering journal and our presenting skills since our robot performance was not stellar
    • At this point we've had a lot of practice
    • Handing judges materials from our presentation box at the right times
    • Manual demo of the robot was successful
    • We got across all of our more important presentation material before the 5 minutes were up
    • Anything that we didn't get to during the five minutes we were able to cover in questioning
    Weaknesses
    • Since we were tired, we sounded kind of low energy and unenthusiastic
    • At the same time, we were talking super fast trying to get through all of our content
    • There was not much interest in our robot demo
    Opportunities
    • Rework our presentation to focus on the most important information (at this point we have realized we will not have enough time to talk about everything we have done this season)
    • Make good use of the questioning time - invite the judges during the initial 5 minutes to ask questions about our team's highlights after the 5 minutes are up
    Threats
    • The 5 minute time restriction
    • Lack of sleep bringing down our energy levels

    Pits Presentation and Conduct

    Strengths
    • Our pit setup was super clean with everything hidden away under table covers, and our posters and aquila
    • We had people stationed at the pits at all times to receive any judges who had questions
    • Some people were drawn to our pits because of our hats!
    • People also came to our pits when we displayed match results on our monitor
    Weaknesses
    • We didn't have a good scouting strategy and the scouting team was also lacking sleep
    • Not everyone got an opportunity to speak during pit interviews
    • As far as we understand, we did not get any pit interviews from design focused judges (we need to sell this more during judging)
    • Though displaying match results attracted people, it also created traffic in our pit area
    Opportunities
    • Have a working rotation of people at the pits, scouters, people watching matches, etc.
    • Have a more active scouting team
    • Redesign some of the older cross banners
    • Still display match results but find a way to minimize the mess created by this
    Threats
    • Not having scouting
    • Not making conversation with other teams/forming connections
    • Poor pit organization
    • Team members being off task in the pits

    Robot Performance

    Strengths
    • Physically, the robot worked alright
    • The foundation grabber worked
    • Parking also worked
    Weaknesses
    • We did not do a good job demonstrating the components that did work
    • We had to slap Snapdragon down multiple times on a stone before it would snap closed over the stone
    • The polycarb base plate is heavily cracked and needs replacement
    • While a lot of our autonmous functions worked in theory, they were untested, and so naturally they did not work
    • In one of our matches we lost functionality of the arm because a wire came loose
    • Capstone was never deployed
    • The mounts for distance sensor was bent
    • Drivers were unfamiliar with autonomous set-up
    Opportunities
    • Design a new 3D printed part for the gripper that triggers the snapping motion more effectively than the bent metal strip we have now
    • Cut and bend a new polycarb base plate
    • Better wire management
    • Adding LEDs - make TomBot look more snazzy
    • Add more sensor-assisted capabilities, such as stone retrieval
    Threats
    • Having to overcome the bad impression we gave at Regionals for the World Championship
    • All the teams who have a super fast wheel intake

    While there is a fair amount of time before the World Championship in Houston, we don't want to get too comfortable. We will be using the list above as a broad guide as to we should accomplish for the championship. We will be increasing the amount of afterschool meetings we have to develop autonomous and practice driving TomBot. The UIL tournament will serve as a good place to practice in a very realistic setting. Additionally, we are excited to be creating TomBot V2 for the World Championship, and seeing if we can create as iconic a reveal video as the previous year's.

    CNC a New Polycarb Robot Base

    24 Feb 2020

    CNC a New Polycarb Robot Base By Justin

    Task: CNC a new robot base

    We finished manufacturing our new base today, with very little difficulty, but a few flaws. The CAM was already designed so all we had to do was run the operations on the CNC. We drilled out the various sized holes, cut out the inner wheel slots and cable holes. Next was the groove along the edge to fold the side flaps along, which was a leap of faith because the orientation and position of polycarb on the CNC had shifted, which meant we didn't know exactly where we had it originally. We got it as close as we could remember and then ran the funky groove operation, which turned out to have pretty close to perfect alignment. Finally, we cut out the outline of the base, with flaps to fold down to increase the strength of the polycarb and to reduce flex. After looking at our finished project we noticed that the center slip ring hole was not cut. The hole is for general cable management and for the slip ring wires to reach the REV hub under the robot. We checked the CAM and found that it had been left out of the inner contours, so we made an operation for it, and cut it out separately. The build plate was finished on the CNC side of its production.

    Next we used attempted a new way to fold down the side flaps to make the structural ring of the base: some tasty oven baked aluminum. The plan was to heat the aluminum above the working temperature of polycarb, then place the edge of the hot aluminum in the groove and use the edge to make a straight 90 degree bend. We found that aluminum and polycarb just don't transfer heat very well, and ended up with a hot piece of aluminum and cold polycarb. Our less preferred alternative solution was the classic torch bend, which was prone to bubbling if rushed. We took our time and were very careful about how much heat we applied, so we only ended up with a few bubbles. Regardless, this was a major improvement over our previous build plate.

    Next Steps

    We are now ready to start mounting our subsystems onto the new base. We should first start with the drivetrain and the turntable. We also should document any errors we encounter with the new build plate, so we can fix them in CAM and make another more polished attempt. Our next CNC parts include boring out gears to fit on our big wheels, and cutting out more banana shaped mounts for the turntable.

    TomBot v2- Gripper Triggers

    25 Feb 2020

    TomBot v2- Gripper Triggers By Jose

    Task: CAD, 3D print and test new, better, and more aesthetically pleasing gripper triggers

    Since our gripper follows a design similar to a slap-band it needs a trigger to close it, for too long we have used a bent REV beam with screws on the end to hit the nubs of a stone. This proved to be very inconsistent as proven by driver practice before and at regionals since the screws were too small of a plane to hit the stone, forcing the driver to be precise to hit close the gripper. To help with this some better triggers were CADed by using the CAD of a stone as reference. since there is a servo on the top of the gripper the triggers have to work around that so a loft was made between the bottom circles and the attachment point on the gripper. Some filets were used to clean up some edges and this was sent to the 3D printer. At first the triggers were too short so they were extended by 2cm later on.

    Next Steps:

    With the print done we can test these triggers on the actual robots to test its viability on TomBot v2.

    Code Changes The Week Before Regionals

    28 Feb 2020

    Code Changes The Week Before Regionals By Mahesh and Cooper

    Task: Assess Code Changes During The Week Before Regionals

    Numerous code changes were made during the week before regionals, the most signicant of which were attempted two days before regionals, a costly mistake during competition. Firstly, three different paths were layed out for respective position of the skystone (South, middle, and North), which involved rotating to face the block, driving to the block, extending enough distance to capture the block, and driving towards the foundation afterwards.

    Next, we proceeded to add small features to our codebase, the first of which was integral windup prevention. We saw that when tuning gains for our turret PID, we experienced a build up of steady state error which was counteracted by increasing our integral gain, but resulted in adverse side effects. We used the following code to declare a range which we refer to as the integralCutIn range, and when the error of the system drops below that threshold, the integral term kicks in.

    This code was put in to account for a phenomenon known as integral wind up; when the theoretical correction given by the system surpasses the maximum correction that the system can deliver. An accumulation of error results in more correction that can possibly be given in the real model, so to prevent this, the integral term is active only within a small range of error, so that the robot can deliver a reasonable amount of correction and avoid overshoot.

    We continued to tune and tweak our autonomous routine Tuesday, making minor changes and deleting unecessary code. We also encountered errors with the turret which were fixed Wednesday, although the biggest changes to our algorithms occured in our skystone detection vision pipeline on Thursday.

    On Thursday, code was added in order to select the largest area contour detected by our vision pipeline, and avoid percieving any disturbances or noise in the image as a potential skystone. We achieved this by first iterating through the found contours, calculating area using Imgproc.contourArea(MatOfPoint contour), keeping track of the maximum area contour, and using moments to calculate the x and y coordinates of the blob detected. The screen was then divided into three areas, each of which corresponding to the three skystone positions, and the final position of the skystone was determined using the x coordinate of the blob. A snippet of the code can be seen here:

    On the final stretch, we added localization using Acme Robotic's roadrunner motion profiling library, which will be expanded on in the future. We also tuned and tweaked PID gains and ticks per meter. Finally, we added code to read distance sensors, which will be used in the future to detect distance to the foundation and follow walls. In addition we integrated the vision pipeline with the existing addMineralState(MineralState mineralState) method to be used during the start of autonomous.

    Next Steps:

    In the future, we plan to use the features we added during this weekend to expand on our robot's autonomous routine and semi-autonomous articulations. These include incorporating odometry and localization to reduce the error experienced during autonomous, and even drive to specific points on the field during teleop to improve cycle times. In addition we can now use distance sensors to follow walls, further improving our accuracy, as well as determine the distance to the foundation, allowing for autonomic placement of skystones using the extendToTowerHeight articulation.

    Narrowing Down the Configuration of the New Vehicle

    11 Apr 2020

    Narrowing Down the Configuration of the New Vehicle By Bhanaviya

    Introducing MXP 2: Electric Boogaloo

    As we have explained in earlier posts, Iron Reign is currently involved in the process of creating a new version of the Mobile Tech xPerience vehicle, a mobile STEM classroom which we, along with our programmatic sponsor Big Thought, take to various outreach events around the greater Dallas area. Given the success of the MXP through its lifespan, we are currently moving into the stage of creating a new vehicle, for which our team will be creating a virtual design plan as well as a financial plan.

    We'd like to make it clear that this 2020-2021 season, our team is not claiming any credit for the construction or events associated with the original vehicle but instead for the creation of the blueprint of the second vehicle. Now that schools all over the country are restricted to virtual learning, the best way our team can bring STEM to students across our community who lack the access to it is to move ahead with the virtual design for the new vehicle in hopes of bringing STEM in mobile fashion to them when the current COVID-19 pandemic has cleared. As such, we created a virtual model as created above of te exterior of the new vehicle. Using this student-designed plan for the new MXP, the board of directors in Big Thought were able to get a sense of our ideas for the new vehicle. Using this design, Big Thought has moved into the next stage of design, which is allowing their graphic design team to use our 3D-modelled version of the MXP to create a sketch for the design on the exterior of the vehicle . For a better sense of what this design can look like, you can refer to the image below of the design scheme for the pilot stage of the MXP.

    Next Steps

    Although our scope of action is limited under quarantine, access to STEM education and the technology associated with it has allowed us to move forward in designing the MXP. As such, our main focus will be narrowing down the quality of our current virtual design, and possibly move into designing the virtual floorplan. Similar to how many teams in the FIRST community have taken action to bring their knowledge of STEM to improve the quality of life in their community, our collaboration with companies like Big Thought to find a way to bring STEM to more students is our response against the current pandemic, and we hope to re-double these efforts over these next few weeks. From us here at Iron Reign Virtual HQ, we hope that everyone in the FIRST community stays safe!

    Summer Summary

    11 Jul 2020

    Summer Summary July 11, 2020 By Bhanaviya, Jose, Anisha, Paul, Shawn, Trey, Justin, Aaron, Ben, Mahesh, and Cooper

    Talking Heads: Summary July 11, 2020

    Task: Prepare for the 2020-2021 Game Reveal season

    Today kicked off our first meeting for the new Ultimate Goal season. Since the actual challenge for this year hasn't been released, the most we can do is to speculate what the new challenge might pose, and what we can do to prepare for it.

    Recruitment

    As most of our members have moved on to our Junior year, our team is now primarily upperclassmen-led. This means that within 2 years, we will need to recruit enough members to keep the team sustainable after our graduation. Unfortunately, due to the current pandemic, we will need to ensure that the Iron Reign program has the funding needed to maintain 3 teams in addition to ours. At the moment, our focus has been on keeping our own team viable over the virtual season, and this may mean that we will have to cut back on our recruitment and pick it back up closer to our senior year on the team.

    Outreach

    In an earlier post, we went over the plans for a new mobile learning lab. To clarify, the Mobile Tech xPansion program is owned by Big Thought, a non profit organization dedicated to education, but its outreach events are executed by Team 6832 Iron Reign. During these events, our team travels to low-income areas around the Dallas community with little access to STEM education, and teaches younger students about robotics and CAD to improve their interests in STEM which can sometimes be hard to discover without the access to a strong STEM-based education. Recently, Big Thought approved the plans for funding and expanding this program and our coach was able to purchase a new vehicle for the second, improved version of this Mobile Learning Lab. However, due to the ongoing pandemic, the plans for this vehicle have been put on temporary hold since most of our outreach events happen over the summer. As the count for COVID-19 cases in Dallas has been relatively high, there is no safe way for our team to interact with younger students and teach them hands-on robotics. As such, we will be placing our MXP outreach program on hold until the pandemic has improved (which will be, hopefully, soon).

    3D-Modelling and CAD Design

    Jose has been working on modelling various robot designs in anticipation of the upcoming season. The first is a kiwi drive, with a triangular chassis with 4 omni-directional wheels on each side of the chassis which enables movement in any direction using only three motors. The render of the robot itself is built using custom and goBilda motors. Another design was for an Inspirenc CAD Challenge, which resembled our Superman design from two seasons ago, but with a more rectangular chassis. All of these designs created over the summer will be within their own separate entry - this is merely a summary of our summer progress. Since we don't yet know what the challenge this year will look like, nor how much we would be able to meet in-person in light of COVID19, we plan on starting our build efforts with CAD designs to streamline the engineering process with an online reference in hand.

    Next Steps

    One of the hardest things about this year's season will be trying to cover all our usual grounds virtually since the number of team members who can show up to in-person practices has been severly limited. In the meanwhile, we plan on using our Discord group to map out the skeleton of our new season - journal and CAD will, for the most part, progress business as usual but we'll need to rely on CAD and our planning calls much more heavily to go through with build, code, and outreach. We plan to keep up our pace as a World-class team as best as we can over quarantine, as uncertain as our plans for this season may seem.

    Co-Hosting the Caravan CAD Challenge

    08 Sep 2020

    Co-Hosting the Caravan CAD Challenge By Jose

    Task: Help design a CAD Challenge game, make a reveal video for the game, judge submissions, and give feedback

    Over the summer, we collaborated with FTC teams 3658 and 6964 to host the first annual Caravan CAD Challenge. The idea of a CAD Challenge is to come up with a game to release to everyone participating. From there the participants will CAD a robot, just like they would for an actual FTC robot, and submit a brief summary of how the robot should work, if it were to be physically built. The game we came up with was Rafter Rave, which involved shooting pucks and climbing a rafter. We had a total of 29 teams sign up and 14 submissions. Following the deadline for submission, we judged each robot, ranked them based on several categories, and gave out awards. This was all revealed in a premiered judging video.

    One of the challenges of this past season was that we didn't get an opportunity to close it off properly owing to the pandemic. Hosting a CAD challenge in coalition with other FTC teams allowed us to not only connect with other teams who may have experienced the same abrupt ending, but also allowed us to provide an opportunity to all participating teams to acclimate to the likely virtual season by modelling a robot. If the season does end up being virtual, this is something a good number of teams would need to have under their belt if they were unable to meet in-person just as our team could not. A CAD Challenge not only speaks to the design elements of an FTC season, but also the necessity to plan ahead and be flexible with a virtual environment as well as the need to connect with other teams in the FIRST Community.

    Next Steps

    We hope that this CAD Challenge allowed all teams to better envision and address their engineering plans in this upcoming season as well as gave all teams an opportunity to form new connections with other teams around them. We wish all teams best of luck for the new season ahead!

    Connecting with Motus Labs

    08 Sep 2020

    Connecting with Motus Labs September 08, 2020 By Bhanaviya

    Reaching out to Motus Labs September 08, 2020

    Task: Reach out to potential sponsors in light of the 2020-2021 season

    Earlier in the summer, we learnt of an engineering group whose focus lies in innovative robotic gear drive designing and manufacturing. Prior to the start of this year's game season, we had sent Motus Labs an email in an effort to present our robotics program, team and robot to them and better understand how a professional robotics company operates (especially during the current pandemic). This week, we recieved a response back!

    In the email response, a representative from Motus Labs conveyed their interest to meet with us and discuss opportunities for sponsorship and to try out their new gear like the M-drives. As the younger generation for robotics, we are interested to meet with professionals in the field - particularly since they are a Dallas-based group like our team is. We have currently planned to schedule a time with them in January of 2021 to discuss any potential opportunities for mentoring.

    Next Steps

    We are incredibly thankful to Motus Labs for giving us the opportunity to discuss FIRST and our robotics team with them. As an up and upcoming robotics company in the Dallas region, we believe this meeting can help us further expand our robotics program from robotics groups to corporations as well. We look forward to meeting with them in these upcoming months, whether that may be virtually or in-person.

    FTC 2020-2021 Game Reveal

    12 Sep 2020

    FTC 2020-2021 Game Reveal By Ben B, Jose, Anisha, Shawn, Bhanaviya, Justin, Mahesh, and Trey

    Task: Watch the FTC Challenge Reveal event live

    Game Reveal:

    Today was a significant day; the FTC 2020-2021 challenge was unveiled. However, this year was very different from previous years, where we would attend a local kickoff event. Due to global circumstances, only a couple of members met in person while the rest of the team had to meet online. We joined a video call and watched the live event as a group.

    One of the major issues we foresee is ensuring accuracy in the launching mechanism. The clearance for the highest goal is significantly smaller than that of the lower 2 goals. We will prioritize launching the rings into the highest goal since it awards 2 more points than the lower goal. Because of the small clearance, if the driver or robot made an error and the ring fell into the goal below it, the other team will be rewarded those 4 points. Accuracy will also be necessary for knocking down the power-shot targets during the endgame since each target will award 15 points. Missing one of these targets would be a waste of precious time during the game's final moments.

    We also discussed how we would aim the launcher. One method would rely on a targeting system that would automatically horizontally and vertically align the angle of the launcher based on the robot's position relative to the goal. This would be done through code and would be controlled through a preset. A second method would be based around the GPS location of the robot. When a button is pressed, the robot would go to the shooting line directly across from the goal. By doing this, the launcher's angle could be predefined and the only action that would have to be done is launching the rings. The GPS position where the robot would have to travel would be calculated at the start of the game based upon the robot's starting location. The driver would have to go the approximate position and a preset would take care of the rest. The launcher could either be attached to an arm to angle the robot, or we could utilize our “superman wheel” which has been developing over the past 2 seasons.

    This season also comes with some unique challenges, one of which is the playing field's size. With our current setup, we can only fit the field and cannot accommodate the goal and human players. Luckily for us, remote events will only take place using half a field.

    Next Steps:

    Our next steps will be to conduct experiments with the rings to determine how we could construct a launcher. While we don’t currently have the foam rings, we can 3D print a prototype. We will also have further to discuss strategy and model different types of launchers.

    Printing Rings

    14 Sep 2020

    Printing Rings By Trey

    Task: Print some game elements to get a kick start on the season

    Recently, this year’s competition details were released, and while we couldn’t quite get started on a robot immediately like we did last year we were able to do some prototyping for ring launchers. The thing that we made which enabled us to do this was a rendering of the game element for the year. This was done by taking the model released on AndyMark’s website and 3D printing it. With this, we were able to start thinking about the size and proportion of our future launcher as well as its construction. The ring was printed in PLA at its exact size to best accomplish this.

    The biggest problem with this method of construction is that the ring does not have the characteristic foam squishiness so we also made another ring out of foam tape to get a better idea of how the official game element might fly and how we can get it to fly. We were able to throw the two rings around and notice that there is a very noticeable spin that can be achieved and will likely be desirable in the future for maximum stability in the air. The realistic shape of the ring was helpful when we were trying to figure out how the ring would fly since different ring shapes would obviously fly differently so having a replica was nice.

    Next Steps:

    We are going to kick off our development of a robot soon and with the rings we made we should be able to develop better early on than if we were empty-handed. This development is of course being curbed by the pandemic since at the moment only a few builders can come in to build at a time. Being one of these builders, I think the goal for the first launcher prototype is to see how easy it is to get a ring to fly and what variables will be important in the future for trajectory and speed rather than actual functionality. We are excited to have a whole season of development ahead of us.

    Robot in 2 Days - But in CAD

    14 Sep 2020

    Robot in 2 Days - But in CAD By Jose

    Task: CAD a robot for the Ultimate Goal Challenge quickly in order to get ideas for a final robot design and prototypes

    A new season, a new design challenge, and more opportunities to compete. Last season we participated in the Robot in 3 Days Challenge where teams race to build a robot for the new season as quickly as possible in order to accelerate the brainstorming and prototyping phase of the season. Due to certain circumstances this couldn't happen this season but overcoming the situation the idea of transferring the challenge to CAD arose.

    Day 1

    The first step of course is to come up with a design for this robot. Many ideas came and went, many ideas were inspired by previous seasons' robots, but ultimately the main design was decided over a few hours and a basic CAD model was made. A time lapse of this can be seen here:

    Since I was really lazy today, I mean since coming up with the design of the robot took a while and I was very busy today not much could be done in the first day. I began working on the claw to grab the wobble goal and taking inspiration from the one used in the xRC Sim version of the game(the sim can be found here: https://xrcsimulator.org/downloads/) I decided on a simple arm mechanism with a hook. The hook is designed to be passive, it's wide enough to go around the pvc pipe of the wobble goal, but small enough such that the top of the wobble goal can't escape as easily. Since the wobble goal isn't as heavy the arm doesn't need such a high gear ratio, so I went for a 30:1 final gear ratio.

    Day 2

    Day 2! Time to do everything I was too lazy to do yesterday, I mean too busy to finish. The first step today was to check how much length I had left over for the ring intake, this turned out to be a little over an inch, not much, but enough. Since I am going for a conveyor design for this robot a base is needed below it to not only support the conveyor, but to also make sure the rings don't fall since they will be travelling below the conveyor in order to feed into the shooter. Some supports were added with REV extrusions, which made things start to come together.

    Up next was to actually have a way to power the wobble goal grabber. However, this was really simple as I just needed to add an ultraplanetary motor and a belt.

    Next on the list for today was to actually make the conveyor belt, this will have "spikes" in order to grab the rings. The conveyor is about 6 inches long to allow for some extra room when intaking. Spikes are in pairs and spaced about 3 inches apart. This was a simple assembly and I was able to move on to adding the pulleys and bearing shortly after. As far as a gear ratio goes, a direct drive 19.2:1 should do.

    It's the final countdown..[plays the final countdown music], time for the final sub-assembly, the shooter. This was very simple to make. Holes in the polycarbonate base were made to allow for the shooter wheels(I used the new goBilda Gecko Wheel) and these were also direct driven with a 5.2:1 goBilda motor. This may be too slow but since this is CAD, it isn't very easy to test this. The process of getting renders of this robot proved to be resource demanding but it got done and here is the final product:

    Simple Roller Intake

    26 Sep 2020

    Simple Roller Intake By Jose

    Task: CAD a simple roller intake design

    This intake design is the most plain of them all, just compliant wheels on a shaft. The idea with this is to have it low to the ground, and drive up to the rings. This design has been tried and tested on many robots by many teams, but it will not work on ROBOT as there is no realistic way to transport rings so low to the ground up to the turret, especially not with the entry angle of the rings.

    Next Steps:

    Continue prototying more intake designs.

    Archimedes Screw Intake

    28 Sep 2020

    Archimedes Screw Intake By Bhanaviya, Jose, and Shawn

    Task: Begin creating intake systems on CAD to test their potential

    The Archimedes Screw Intake, as the name goes, was based on an Archimedes screw. A screw shaped surface would draw the rings from the fields and transfer it directly to the launcher as the screw rotates. Similar to the Archimedes screw water pump, it makes use of positive displacement and would rely entirely on the screw's movement for the rings to travel upward towards the launcher.

    While this is an intruiging system, our biggest concerns with it are size and timing. This system would take up most of the volume of the robot. Also, since the screw would have to rotate entirely for one ring to be taken upwards, this is likely not the most efficient system and even the mere drawing of the rings into the system is likely to be more time-consuming. It would also be very difficult to make. So, this intake ends here in the concept stage.

    Next Steps

    Our next steps are to begin brainstorming ideas for other, more efficient intake systems. We may still come back to the Archimedes system but as of now, it is of lower priority. Rest in Peace Archimedes.

    The First Launcher

    10 Oct 2020

    The First Launcher By Trey and Paul

    Task: Create and Test a Arm Disk Launcher

    One of the centerpieces of any robot this year is going to be the disk launcher. It’s likely that most robots in the competition are going to be built around their launchers, so one could logically conclude that that’s a good place to start when building a robot. This is no different for us; however, we didn’t just want to build a flywheel like most other people. Instead, we started to look into other designs. One of the designs that came into mind first was some sort of arm that is powered by an elastic or bungee cord that throws disks sort of like a clay pigeon thrower.

    But why did we start with an arm design? Wouldn’t a flywheel be easier? We started with an arm because we thought it was interesting and customizable. Yes, a flywheel would be easier but that would be at the cost of customizability. With a flywheel, there is only so much to change. You can change pretty much only the motor, the wheel, or the speed of the motor. This is good for a team that just needs a launcher that works but we want to be able to make a customizable launcher that we can tailor to our needs easily. There is a lot of open space and customizability with an arm launcher. For example, we can change the arm material, length of the arm, strength of the bungee, the time the disk is in contact with the arm, and much more.

    So that’s what we built and it works to a degree. Yes, it does launch a ring, in fact, it can launch a ring across the field to a height of 55 inches at an angle of 44 degrees with an easily retractable arm; however, in its current state it breaks easily, isn’t consistent, and is quite big. The first two are fairly easily fixable because they are mostly because the base of the launcher is made out of particle board which falls apart easily but the last one isn’t quite as easy to fix. Cramming this design into a smaller space could provide a difficult challenge. The function of the design is to accelerate a ring over a distance with an arm which can be difficult in a small area because with a smaller arm you have to use a stronger bungee to achieve the same results.

    Next Steps:

    I have only touched on a few major things to be improved. There are quite a few; however, the results that we observed from this design definitely warrant a second version, and there will be one. At the very least, I am thinking of new designs and improvements for this system. There are also many other things we can try and I know that regardless of what I have said about a flywheel launcher so far, it would have its advantages, mainly compactness, so I know we will definitely build one of those as well. There is still much more to be made and built for this robot.

    Code Planning For The New Season

    17 Oct 2020

    Code Planning For The New Season By Mahesh

    Task: Plan changes to our codebase for the new season.

    This year's game saw a significant boost to the importance of the control award, now being put above even the motivate and design awards in order of advancement. Therefore, it is crucial to analyze what changes we plan on bringing to our codebase and new technologies we plan on using in hopes of benefitting from the award's higher importance this year.

    Firstly, the very beginning of the autonomous period requires the robot to navigate to one of three target zones, specified by the quantity of rings placed, being either 0, 1, or 4. Since the drivers will not be able to choose an opmode corresponding to each path, we will have to implement a vision pipeline to determine which of the three configurations the field is in. This can be done with OpenCV, using an adaptive threshold and blob detection to differentiate 1 ring from 4 rings through the height of the detected color blob.

    Secondly, ultimate goal's disk throwing aspect opens up the opportunity for automatic shooting and aligning mechanisms and the software to go along with them. If a robot can use the vision target placed above the upper tower goal or otherwise localize itself, projectile motion models can be used to analyze the disk's trajectory and calculate the necessary angle and velocity of launch to score into the goal given a distance from it on the field. Such automation would save drivers the hassle of aligning and aiming for the baskets, allowing them to focus on more complex strategy and improve cycle time. Vuforia and OpenCV pipelines can be used to figure out the robot's location on the field, given the vision target's orientation and size in its field of view. If OpenCV is also used to allow for automatic intake of disks on the ground, then most gameplay could be automated, although this isn't as simple a task it may seem.

    Asides from using the webcam, another localization technique we dabbled with this summer was using GPS. We were able to get +- 4 cm accuracy when using a specific type of GPS, allowing our test robot to trace out different paths of waypoints, including our team number, the DPRG logo, etc. If this level of accuracy proves to be viable in game, GPS could be considered an option for localization as opposed to the odometry sensors many teams employ currently. Another sensor worth noting is the PMW3901 Optical Flow Sensor, which acts similar to a computer mouse, in that its movement can be translated into a horizontal and vertical velocity, giving us more insight into the position of our robot. Regardless of how many different gadgets and sensors we may use, an important part of the code for this year's game will be automatic scoring, no matter how we choose to implement it.

    As always, we hope to have this year's codebase more organized than the last, and efforts have been taken to refactor parts of our codebase to be more readable and easily workable. Additionally, although it is not necessary, we could use multithreading to separate, for example, hardware reads, OpenCV pipelines, etc. into their own separate threads, although our current state machine gives us an asynchronous structure which emulates multithreading fairly well, and implementing this would give us only a slight performance boost, particularly when running OpenCV pipelines.

    Next Steps:

    The most immediate changes to our codebase should be both working on refactoring as well as implementing bare bones for our teleop and autonomous routines. Next, we should work on a vision pipeline to classify the field's configuration at the start of the game, enabling the robot to navigate the wobble goal into the A, B, and C drop zones. Afterwards, the physics calculations and vision pipelines necessary to auto-shoot into the baskets can be made, starting with a mathematical model of the projectile.

    Custom Flywheel CAD

    24 Oct 2020

    Custom Flywheel CAD By Jose

    Task: CAD a custom flywheel

    Instead of using a grip wheel to launch rings we went with the approach to make a custom flywheel. The key concept of a flywheel is to maximize rotational inertia. This is done by putting as much mass towards the edge of the wheel as possible. To do this, a ring of ninjaflex was designed, from there, 5mm flaps were added as an experiment to see if it would give the wheel more points of contact to the ring. However, the wheel needs a center to be able to spin, so aluminum plates were added to sandwich the ninjaflex ring. To decrease the amount of mass not on the edges of the wheel, these aluminum plates were pocketed, leaving aesthetically pleasing curved spokes on the plates.

    Next Steps:

    The ninjaflex is to be 3-D printed and the aluminum plates will be milled on our CNC machine. Once that is done it will all be put together using M3 hardware.

    Dealey Presentation Preparation

    28 Oct 2020

    Dealey Presentation Preparation By Ben, Mahesh, Jose, Anisha, Shawn, Bhanaviya, Paul, Cooper, and Trey

    Task: Prepare for our presentation to Dealey International School

    On Saturday October 10 we received an email from the robotics coach at Dealey International School. Dealey is a public school in North Texas that is a primary feeder into our high school, making this an important long-term recruitment opportunity. This year they have started 2 FTC teams for the 7th and 8th graders and would like our team to join a Zoom meeting and discuss what our team does, explain the FIRST philosophy of Gracious Professionalism, and answer any of their questions.

    We decided it would be best to give a presentation about our team and FIRST then answer questions. Over the course of the week we have been discussing what we specifically wanted to present and put together a PowerPoint covering those topics. The presentation will cover how the Gracious Professionalism FIRST Tech Challenge operates robot competition, engineering journal, and both community and professional outreach. We will talk about the various award categories and what they mean, how to write an engineering notebook and what the team/engineering sections need to contain. We will then present an overview of the previous season’s outreach to Deloitte, Colin Allred, and DPRG. Then, we will discuss Iron Reign’s prototyping process and how we go from ideas to creating a CAD model to manufacturing with 3D print and CNC. We will then transition to the programming pipeline. The programming team will explain how all the components are connected, how they are coded, and how we use vision. The presentation will be concluded with a statement about the 10-year history of the team and how we hope they will be joining our program in the future.

    Today we joined a zoom call after school to distribute slides, practice presenting a few times, and troubleshoot and camera and microphone issues. Each subteam will present their respective specialties and each person will present around 2-3 slides. We aimed to keep the presentation under 25 minutes to allow enough time for questions. After practicing the presentation a few times and rearranging the order to be more consistent, we felt we were prepared to present to Dealey tomorrow.

    Next Steps:

    Each person will review their slides again tonight and before we present to ensure they are prepared. They will also make sure their cameras and microphones are still functional and ensure they have an appropriate background. We will also have to keep an eye out for the meeting instructions tomorrow.

    Dealey Presentation

    29 Oct 2020

    Dealey Presentation By Ben, Mahesh, Jose, Anisha, Shawn, Bhanaviya, Paul, Cooper, and Trey

    Task: Give a presentation to rookie teams at Dealey International School

    Today we gave a presentation to rookie FTC teams about FIRST and our team over Zoom. We began by introducing ourselves individually by saying our name, subteam, and Townview school and then jumped into the presentation. The presentation took about 30 minutes and went well overall with some minor rambling. Afterward we split our team into breakout rooms with 1 programmer, 1 modeler, and 1 builder and evenly distributed the rookie team into those breakout rooms to ask questions. This was done to give each team member more time with each rookie member and allow them to ask more questions. After 20 minutes we ended the breakout rooms and answered any more general questions.

    We also wanted to discuss followup opportunities to help the team in the future. We talked about a possible mentorship relationship where some Iron Reign members would go to the Dealey lab and help educate the team on different things like 3D modeling and printing or programming. This would be especially helpful to them because they recently got new 3D printing technology. We also discussed ways to do virtual mentorship through Zoom, which would also include educating them on different aspects of the engineering process. We agreed to let them discuss it as a team and let us know what would be best for them.

    We felt that the meeting was very successful because the presentation was great and they had lots of questions and showed a lot of interest. We also spent some time getting to know them. In the end, we were able to reach about 20 of their members and had a few follow-up emails from the members.

    Next Steps:

    We would like to eventually have some follow-up meetings with the team and discuss their progress and hold some programming, modelling, and journal classes.

    Recruitment Update

    31 Oct 2020

    Recruitment Update By Bhanaviya

    Task: Plan for sustainability goals

    Owing to the ongoing pandemic, our recruitment goals are not similar to that of previous seasons. One of our bigger concerns is that it will be harder to teach rookie members about our program and FTC in a virtual setting - especially if we support 3 teams like last season. So, in order to ensure that our program remains sustainable, we opted for a new recruitment strategy where we consolidate our 2 rookie and 1 JV team into a single Junior Varsity team.

    Structure-wise, Iron Reign will remain the varsity team, and as such, will be responsible for tutoring and assisting the other teams, as well as other organizational decisions. Then, Imperial Robotics, Iron Core and Iron Golem will now be consolidated into one JV team, and be the intermediate training ground. We believe that this team will serve as a good platform for the younger members on the SEM Robotics program to understand what it means to be on a FTC team. As of now, we anticipate that there will be 12 members in this team. So far, all of our recruits are motivated and show great potential for the future of our robotics program.

    We will deliver tutoring updates and joint outreach events on this blog, as well as our usual content. Everything claimed in this engineering notebook will be Iron Reign (6832) only, and we will hold the same standard of separation to the other teams.

    Next Steps

    For ongoing tournaments and eliminations, we will recompose new teams of the most promising members. Our goal has been to ensure that the Iron Reign Robotics program is sustainable for years to come and with our 2 teams, we are confident that we will be able to achieve this. By next season, we hope to either be out of the pandemic or have adopted a good ryhthm for working virtually and hope to expand our recruitment design.

    Ladder Intake CAD

    21 Nov 2020

    Ladder Intake CAD By Jose

    Task: Design a mechanism to trasfer rings from the ground to a future ring launcher

    The initial vision for this intake design was inspired by FRC team 1983’s Ultimate Ascent robot. The “ladder” pivots from the back of the robot to rotate out. The wheels in the front are very similar to the simple roller design, except here they extend out of the robot. The intial CAD was a very simplified model in order to get the idea across. After some discussion, it was decided that the design would be shrunk down as it was unnecessarily large.

    After that, a more realistic CAD model was made, using aluminum side supports and REV extrusions. This was then taken to the chassis CAD model to check for mountabilty. There seems to be a spot on the front of the chassis that allows the intake to work as intended, however more testing is necessary.

    Next Steps:

    Physically build this intake in order to more acurately test for functionality.

    Auto Path Plan

    24 Nov 2020

    Auto Path Plan By Cooper

    Task: Layout a plan for auto paths this season

    To begin, as you can see up above (a diagram that was generated on https://ftcchad.com/ ) our first auto path takes very little movement, and no turns whatsoever. This path assumes that on the robot we have some way to grab the wobble goal at the start of the match and can release it in a controlled manner during autonomous. In such, with the robot facing with the "front" of the turret and chassis facing away from the back wall, and the robot in the center of the outermost tape, the robot would use vision to figure out which of the 3 stacks of rings are present. After which, the robot will drive forward and park next to the correct spot, and turn the turret to release the wobble goal on the correct target location. To finish, all it has to do is drive backwards and end up on the shooting line.

    After that is coded, we'll add in features gradually. First, we would look at going back and getting the second wobble goal first using odometry, then vision. Next, and by the time all everything already said has been coded, we should have our first launcher and intake done, making it evident that we should shoot them into the high goal from where we sit on the back wall, and then intake and fire the ring stack before moving on to moving the wobble goals. The final revision would to be to use vision to find and then subsequently pick up rings the human player puts in the field after the wobble goal segment.

    Next Steps:

    Get to coding!

    Modelling an Equation for Forward Speeds of a Ring

    01 Dec 2020

    Modelling an Equation for Forward Speeds of a Ring By Bhanaviya and Ben

    Task: Model a projectile motion equation to approximate forward speeds of rings launched from a ring launcher

    A key challenge in this year's game is finding the best possible position to launch rings to ensure optimal performance of the ring launchers. Part of this challenge includes approximating a potential forward speed for each ring as it is launched from the launcher itself. There was also height and distance constraints that needed to be taken into account before we could find these forward speeds. Modelling an equation to identify this forward speed would allow us to directly plug in this equation into the robot's code so it can automatically adjust itself to aim rings from an optimal angle and position.

    In order to find the most optimal position and angle to launch the rings, we needed to first consider the angle of the launcher to be a variable to determine all possible forward speeds horizontally and vertically. We needed to look at the forward speeds both vertically and horizontally in order to attain the maximum distance (which would be tangential to the horizontal and vertical distance if we were to look at it like a right triangle). FTC constraints dictate that the maximum height a ring can be launched was 16ft we translated to 4.85 meters. While this was not a contant we inputted into our formulas, it was something for us to consider when we began. We knew that the height of our robot with the shooter mounted was roughly 0.41m and aiming to get the ring into the third level of the goals, we knew that the height the ring needed to reach was 0.88m. Subtracting the desired height from the initial height, we got 0.47m, and by placing that on one side of our projectile equation, we used simple algebra to find out that to isolate v0, 1/2(-a)t^2 needed to be subtracted from 0.47m for the vertical velocity. Since the final horizontal distance varies from launch to launch, we left it as xF (final horizontal distance) - 0 (inital horizontal distance) to reflect our steps for the vertical equation.

    When we began planning our equation, there were 3 things we anticipated we needed to know. 1) Angle of launch - this was what we were intending to find but we wanted a formula so we wouldn't have to manually measure theta each time. 2) Initial vertical speed - this was another unknown which affected the distance our rings could travel, which, consequently, relied on the measure of the angles. Finally 3) time - there are two things we need to know about time. First, how long the ring stays in the air, and second how long it takes for the ring to reach zero vertical velocity (in other words, when does it reach its maximum height?) Another issue we needed to account for was how the end of our equation would be represented. Did we want the height of the third level goal to be the summit of the ring's arc or did we want it to be its final point? Since we knew that the ring were not being launched 0 meters away from the ground but rather 0.41 meters away, aiming for the goal to be the end of its arc past its apex would cause too much error in our model if we were to graph the ring's arc as a parabola. So, we settled for making the summit of our parabola be the third level of the goal. So, time in our equation was represented as t/2 since in a standard parametric equation, t for time represents the complete arc while t/2 cuts the arc off at the apex. With all this taken into account, we were able to model two different equations - one for the horizontal velocity of the ring and second for the vertical velocity of the ring.

    Our equations were: Vertical: v0 = (0.47 - 0.5(-a)(t^2))/sinθ(t/2)) and Horizontal: v0 = (xF - 0.5(-a)(t^2))/cosθ (t/2)) t stands for time in seconds, a for acceleration due to gravity - 9.8 m/s^2 and xF for the final horizontal distance of the robot which will be calculated by the robot itself.

    While having two unknowns in our equation in a concern, we plan to find the velocity of one, plug it into the equation for the other side and retrieve theta from there. We want theta to be the same for both the horizontal and vertical equation assuming that the distance they travel is the same.

    Next Steps

    The next step would be for us to plug in constants into our equations and check to see if the velocity and theta seem to be reasonable. We anticipate that these equations will undergo several changes as we continue to build the ring launcher. Even once the equation is finalized, we will need to figure out how to translate it into code and whether or not we can find values such as RPM and muzzle velocity in order to control our motor to provide us our desired launch.

    FTC Legal Belt Sander

    12 Dec 2020

    FTC Legal Belt Sander By Paul

    Task: Create a prototype for a belt sander intake system

    The so-called “FTC Legal” belt sander was an early iteration of the intake mechanism for this year's robot. It was composed of a belt, from a Ryobi belt sander, rev wheels wrapped in tape, to help center the belt, and a tensioning mechanism. The belt would provide friction, moving the disk game elements upwards towards the launcher mechanism. However, an issue we ran into was the distance between the bottom of the belt and the floor was hard to regulate, resulting in disks either not having enough space to be sucked up, or havag too much space and not enough friction to be dragged up. This was partially solved by replacing the belt sander belt with a Ninjaflex belt with flaps, which is the current iteration of the robots intake system, using many of the same parts and designs as the original “FTC Legal” belt sander.

    Future plans include designing and constructing some form of leveling system, and a higher belt speed to more quickly collect disks. We are also considering using this sander design as an inspiration for a dual-tracked belt drive intake system and an elevator-like intake system with ninjaflex substituting for a traditional belt drive system.

    Caterpillar Track Intake

    31 Dec 2020

    Caterpillar Track Intake By Ben, Bhanaviya, Trey, and Jose

    Task: Build and prototype an intake system

    One of the first intake systems we made was the Caterpillar intake assembly (Tetrix tread intake). The inspiration for this design came from an earlier bekt drive comprising of a sander (which you can read about in our earlier post). This was originally built off a c-channel extrusion with a motor attached to sprockets that drive treads. The purpose of this subsystem is to transport the rings from the field into the launcher loading area.

    We first tested the assembly without the rubber bands and quickly realized that the treads couldn’t create enough friction to grip the ring and move it vertically. Our solution was to attach rubber bands within each tred piece. There were 2 reasons for this, the first being that rubber in general has high friction and good grip. The second reason is that the flinging rubber bands will conform to the shape of the ring at high speeds and drag the rings up the intake.

    We did experience a few problems with the construction of the assembly. We found that the rubber bands would often get caught on the edges of the c-channel and either fly off at a high velocity, snap, or tangle and prevent the assembly from moving. Because of the way the band fits into a tread, there wasn’t a way to permanently attach the rubber band without damaging the thread, meaning we would have to scrap the idea or find a work-around. We eventually decided to rebuild the intake with REV extrusions because it would be more compatible with our robot and we could replace the large c-channel with the smaller REV extrusions.

    Next Steps:

    Although this prototype holds promise, we will continue to experiment with it and alternatives to find an alternative that doesn’t run the risk of tangling and disrupting the system.

    NinjaFlex Belt intake system

    02 Jan 2021

    NinjaFlex Belt intake system By Trey

    Task: Design an intake with the NinjaFlex belt

    So far we have made a few Intake assemblies including the belt intake and the Tetrix tread intake. However, as is Iron Reign tradition, we like to make systems that utilize custom parts to both help our robot’s aesthetic and functionality. To do this, we took aspects from the other two intakes to better design and make the one that is discussed in this post. To recap, the belt intake was a sanding belt on to barrels that spun at high speeds to pull in rings and the tread intake was made with Tertis tank treads with rubber bands and spun, in the same way, to grip and pull in rings.

    The NinjaFlex belt intake takes the benefits of both systems without generating their issues. The NinjaFlex intake has the narrowness and form factor of the belt intake without the issues of the belt derailing which is caused by uneven pressure on the belt. Instead, the NinjaFlex belt intake is sprocket-driven with a custom belt to ensure that the belt stays on the rollers at all times as long as the two ends are aligned properly. Derailing was a big issue with the belt intake. Personally, I remember spending at least a few hours in total trying to get the belt to not fall off, with little success. That system would have needed much more work and improvement before we would have seen any results.

    The NinjaFlex belt intake system also yields the benefits of the tread system in that the 3D printed belt provides sufficient grip on the rings in order to pull them onto the robot. Additionally, the NinjaFlex belt system also doesn’t use rubber bands as gripers that can tangle with nearby screws or protrusions, possibly causing the system to break. Instead, the belt has flaps which can also be changed or molded into different lengths or shapes. This brings up one of the biggest benefits, customizability. When we use 3D printed or CNC parts we enter this space of customizability which is always a good aspect because if a change needs to be made to a part, we can usually make a new custom part in a matter of days if not hours with our machinery which gives us a lot of flexibility in how we can build our robot.

    Assembly-wise the intake is also super simple right now. It consists of 6 sprockets, 3 on each side that drive a belt with the sprocket spacing sits on to pulls in rings. The dimensions and specifics of how the belt was designed and made are in the post “NinjaFlex intake belt” but basically it’s just a belt with holes in it with the specific spacing of the REV sprockets. The motor right now has just been placed on one of the shafts but will be secured in a better location in the future, either parallel to the guide rails or perpendicular depending on how much space we have. If the motor is mounted parallel to the guide rails, then it will drive the belt with beveled gears, otherwise, it will be directly fitted onto the shaft.

    Next Steps:

    As mentioned previously, the motor has yet to be permanently mounted so that would be the next clear step and after that, there will likely be more testing and comparing of different intake systems. Then, we will interface the new intake with a ramp to see how we can assemble the two together to finish our intake system and start planning to put it on the robot. For now, though, we have made good progress.

    Proteus' model

    03 Jan 2021

    Proteus' model By Bhanaviya and Jose

    Task: Update the model to plan Proteus' build

    With our first qualifier being less than 2 months away, Iron Reign embarked on an ambitious project to create a robot with a circular chassis, an elevator-like intake system, and a fully automated launcher. While this robot is still in construction, we do have a name for it - Proteus. Named after the early-prophetic sea god who was also known for his versatility, this was the most fitting name for our robot given how flexible we needed to be this season and with only a few weeks left to construct a robot. In an earlier post, we detailed our decision to reuse our circular chassis in order to improve our robot's maneuvering abilities and get around other robot to avoid the traffic towards the goal posts. However, we are yet to decide which of our three intake systems to use as well as how the progression of our launcher might change considering that it is still in its CAD stage. To see how each of these intake systems look on the robot, we modelled the chassis design from the beginning stages and created multiple models to represent each launcher mounted on the robot.

    Earlier in the season, we created a model of just the chassis itself to account for the fact that we are only reusing the chassis design from last year and nothing above it. The updated model still has the same base chassis design from the earlier model, but it now has three different iterations - one with the ladder intake, one with the caterpillar intake, and one with the elevator intake system (yet to be named). Since the elevator intake does not yet have a full-fledged design, we are holding off on a full robot model with it until we figure out how to make it compatible for a final design.

    Next Steps

    With our robot model in progress, we can now plan out all our steps ahead of time in CAD so that we will make less mistakes on the physical build. We will be updating the model as the season progresses.

    Ladder Intake Build

    08 Jan 2021

    Ladder Intake Build By Jose and Bhanaviya

    Task: Physically build the ladder intake, based on the design in CAD

    For the intake system of this year's challenge we first brainstormed several ways which a ring could be collected and transferred to the launching system. Through that and experimenting with CAD, the ladder intake system was developed. Essentially it functions by using the series of Omni wheels on its edge to collect the ring, and then pivot back up to the robot. As pictured below, the ladder intake will be mounted onto the back of the robot and pivot as needed to collect the rings.

    Construction

    The ladder intake was constructed using 8 REV extrusion bars connected by 6 plastic brackets, 2 servos, 7 Omni wheels, a shaft and its respective parts for the wheels to rotate on, a sheet of polycarb below the Omni wheels and shaft to support the rings, and 2 more brackets for the servos to be mounted onto. As shown in the picture below, the idea is for the rings to be reeled in by the Omni wheels and be held using the support of the sheet of polycarb below the shaft, and then be transported to their designated locations in the launching system by the intake pivoting back.

    Testing

    Although the system seemed promising on paper, it unfortunately did not work out as intended. When tested with some first draft versions of code, we found out that the system was unable to actually take in the rings, and instead could only hold them. There wasn't enough traction on the rings for them to be reeled into the system in the first place, which was an issue. We will use this experience to construct an intake that overcomes these issues moving forward.

    Next Steps:

    Start brainstorming a new intake mechanism possibly using some of the components of the current intake that can overcome the issues that hindered the ladder intake from functioning optimally.

    Ring Launcher CAD Meets 1+2

    11 Jan 2021

    Ring Launcher CAD Meets 1+2 By Jose

    Task: Begin designing a ring launcher

    The initial vision for the ring laucher was to be a semi-circle in order to give the ring as much acceleration as possible. In this meeting, it was decided that instead it would be a quarter-circle for the following reasons: to save on space, since there will eventually also be an intake on the robot and a quarter-circle has been proven to give the ring enough acceleration, even if a faster motor is necessary.

    With that decision made, the flywheel was placed in the CAD and the quarter-circle was brought into existance. There is a circular shaft in the center that will hold everything together, but the plate that the ring will rest on cannot be jointed to this shaft. This is because it has to clear the flywheel, so instead another aluminum plate will be placed below it to act as support. From there, walls were added to keep the ring within contact of the flywheel. These walls where also extended a bit beyond the quarter-circle, this is to prevent any variabilty in the lauching of the ring. Finally, a motor mount was extended out of the center aluminum plate to drive the flywheel with the use of a pulley and belt.

    In the second meeting, some final design additions where made, namely screw holes were added(or removed, technically) from the plates and walls in preparation for 3-D prining and CNC milling. Additionally, any walls that were in the way of the belt driving the flywheel were split to make way for it.

    Next Steps:

    There are still many features to be added, such as a way to transfer rings from an intake to the launcher.

    Flywheel Assembly

    12 Jan 2021

    Flywheel Assembly By Jose

    Task: Assemble the flywheel with the readily manufacured parts

    Following the milling of the aluminum plates and the 3-D printing of the core of the flywheel, it is time to put it all together. The first step was to sandwich the ninjaflex core with the aluminum plates, and secure them together with long m3 screws. The plates have a spot for bearings, and those allowed for the addition of a 8mm circlular shaft. From there, the cut-out pulley was directly attached to the flywheel using more m3 screws. This pulley is how the flywheel will be driven, and it has a cutout to be able to fit bearing inside of itself.

    Following the assembly was testing, initial spinning by hand revealed some shakiness in the flywheel. This is likely due to variability in any of the parts, as well as the bearings.

    Next Steps:

    Further investigate the reason for the shakiness of the flywheel when spinning, and modify the weight distubution as needed to correct any variability.

    Presentation Prep-Run

    12 Jan 2021

    Presentation Prep-Run By Anisha and Bhanaviya

    Task: Practice the presentation prior to the PvC Scrimmage on Saturday

    Iron Reign will be participating in our first competitive event of the year at the PvC scrimmage. One of the submissions we needed for this scrimmage was a recorded version of our judged presentation. A stark contrast to previous seasons, the virtual nature of this year required us to be less extemperaneous at least when it came to presentations like this. We started out by building the actual presentation for this year and then assigning slides. Another difference was that our robot wasn't actually complete - since we were more used to building presentations for qualifiers, we usually do not anticipate the need to create a presentation with an unfinished robot (but there's a first time for everything!). As such, we needed to focus our presentation on the iterative nature of our design and on our future plans as the season progresses.

    Next, we needed to gather the whole team to run the presentation. Another significant difference was how we actually ran the presentation. In past years, we would meet in-person to practice the presentation but this year, all we needed was to find a time to meet virtually to make it happen. One downside to this is that usually, we provide our judges prototypes of our earlier designs and unorthodox materials considered for the final design (oven mitts, ice-sube trays, etc.) but with the virtual format, this is no longer a possibility. On the other hand, this means that our live robot demonstration is no longer limited to the constraints of a judging room. Since we have access to our field while we present, we can show our audience our robot in action by making full use of the game elements such as the goal posts.

    Next Steps

    Overall, we were able to successfully record our presentation. While timing is something we need to be mindful of, we expect to fine-tune this as the season progresses along with our actual presentation itself.

    1/16 Build Progress - The first rings fly

    16 Jan 2021

    1/16 Build Progress - The first rings fly By Trey, Cooper, Aaron, Paul, Bhanaviya, and Jose

    Task: Continue developing the ring launcher and do preliminary testing

    Today we continued to further our progression on our ring launcher, finally getting to do some preliminary testing to see what the design might do. For starters, we started to get some of the walls off of the 3d printer which was the first piece of our flywheel launcher barrel design that started to come into real life. We also modified the pulley for the flywheel with the CNC that would eventually be used in the final construction. We had to do this because we want to be able to use our REV motors and driving belts to move the non-REV wheel. In order to make sure that we could do this we set up a machining path that would remove an inner circle of material from a standard pulley so that we can put bearings through it.

    The machining of the pulley is actually fairly simple. All we did was set up a path that would mill a cylinder out of the pulley. What was more complicated was what we had to do before that since you can’t mount the pulley on the CNC since it doesn’t lie flat. Instead, we modeled and CNCed a divot for the pulley to fit into along with some holes for screwing the pully to the CNC. You can see both the divot and the final product above. This operation isn’t that difficult on the machine since it’s just plastic and wood but this is the first time that we have had to mill a divot to machine a part which is what makes it notable.

    Then we put what we had together for the first time on a sheet of particleboard and spun up the wheel to see if we could even get a ring moving. We did get some success and the rings did launch several feet but we did have a few problems. Mainly that the walls were being held in place by people so they were moving and we couldn’t get enough grip on the rings. However, actually assembling the flywheel in housing will solve this problem. Honestly, we weren’t looking for problems in the first place though. This event would fall more under team bonding because we really just wanted to see a ring fly. We put in a lot of work and it was quite inspiring to see the ring actually move.

    Next Steps

    We still have a lot more manufacturing ahead of us. We still need to finalize the model and the CAM of all 3 of the plates in the barrel and 3d print more parts. We also still need to assemble and think about how we are going to get the rings into the launcher which will come and bite us in the butt at some point. For now, it was nice to see some progress as well as the first rings fly.

    Updating Proteus' model

    16 Jan 2021

    Updating Proteus' model By Bhanaviya and Jose

    Task: Update the model to plan TomBot's build

    With our first qualifier being around a month away, Iron Reign is currently in the midst of trying to put together a functional (or semi-functional) robot. In a previous post, we detailed the earlier stages of our CAD design. As of now, Iron Reign is still testing our intake systems but before we finalize the system we want to implement, we plan to construct a robot with just our launcher system mounted. The reason for this is that we have more or less finalized the CAD design for our launcher (which you can read about in one of our earlier posts) and before we can begin the actual assembly and mounting, we need to have it represented in our robot model.

    So, we created a render with just the launcher itself mounted onto our robot Proteus. We anticipate that although the model will change substantially once an intake system has been mounted, the position of the launcher will be consistent and having this modelled allows us to plan out our articulations and strategy for scoring rings into the goalposts.

    Next Steps

    Once we have finalized which intake system we plan to use, the model will be altered accordingly to reflect these changes. As of now, this model will allow us to visualize and implement the addition of our launcher system which will streamline our ability to plan out how we want mount an intake in the future.

    Code Changes Leading up to the PvC Scrimmage

    18 Jan 2021

    Code Changes Leading up to the PvC Scrimmage By Cooper

    Task: Finalize code changes prior to the PvC scrimmage

    Leading up to the scrimmage, many code changes happened, mostly in the area of auton. To start, I tried to run 10 runs of every auton path, to check reliability. Time and time again though, the robot would go off towards joneses, crash into the far wall, or knock over the wobble goal when placing it.

    To address the robots tendency to not want to go straight forward, we wanted to start to use VUforia and the vision targets to help us know our relative angle. However, we had problems with VUforia, as it wouldn’t detect much past what was immediately in front of it. The problem probably has something to do with our abysmal lighting conditions on our field, and while there are solutions, we didn’t have time. So, we went analog and used a distance sensor on the front right of our robot, facing right. This was to basically just do wall following, with one ace up our sleeve. We decided to modify our existing movePID that uses the IMU, to make a moveGenericPID, where it could be used for more generic purposes, like this one. We pass the method our target distance, our current distance, plus all the other generic move variables, and with a bit of fiddling with input multipliers, it worked.

    The next issue caught me off guard, and put me into a state of confusion. Or I guess rather. In all seriousness, all I needed to do was decrease the distance it went for the far. To go into a little more detail on the final issue, it was caused by multiple things at the same thing. Firstly, the arm that holds the wobble goal is shorter than the robot; its end is inside the circumference of the robot when the base and turntable are lined up. That lined up position is how we start, so it had been where the arm just turns to one side to drop it off. Even swung out, the wobble goal is still 40% over the robot, as to where the robot lets go of it and it topples over. We decided to fix it by turning the robot in the opposite direction the arm is turning, at the same time. Then we aren’t losing time to it, and it's a clean drop.

    Next Steps

    Given that we have attended to all outstanding issues prior to the scrimmage, the next steps mainly include testing the robot out during practice runs and being prepared to drive it through the week for all matches.

    Ring Launcher CAD Meet 3

    22 Jan 2021

    Ring Launcher CAD Meet 3 By Jose

    Task: Expand the ring launcher to begin accomadating for a controlled system of firing the rings

    The first step in accomplishing this task is to expand the center aluminum plate to almost a complete semi-circle. From there the back of it was expanded to allow for a place for the rings to sit. Offsets were added to accomadate for any new walls that will be added. Finally, at the back is a place for a servo to be mounted, this servo will eventually be used to rotate rings into the flywheel.

    In terms of the center shaft assembly, the goBilda hyperhubs were removed as there were unnecessary, however the holes made for them were kept, in case they are ever needed again. Spacers and bearing were added to allow for clearance and minimal friction.

    Next Steps:

    Finalize, the left side of the ring launcher, walls need to be added to prevent rings from falling off and a trigger needs to be attached to the servo to rotate rings into the flywheel.

    Ring Launcher CAD Meet 4

    23 Jan 2021

    Ring Launcher CAD Meet 4 By Jose

    Task: Finalize the ring launcher design

    The main thing here is a huge wall on the left to guide rings to their resting position at the back of the ring launcher. But before that, the ring trigger needs to be made first, as it needs to be worked around. The trigger contours the ring perfectly by design, and only needs to rotate about 40 degrees to put a ring within contact of the flywheel. With that done, the guide wall was designed around it, encompassing the enitre left side and connecting to the back center.

    The final step here is to create a better motor mount. This will be a seperate part that will then be attached where the original motor mount was. This is being done to more easily allow for the mount to be slotted: doing so lets the motor's position be shifted to keep the belt it drives as tight as possible.

    Next Steps:

    With the first iteration of the ring launcher design completed, it is ready to be manufacuted.

    Iterate Trajectory Calculations in Preparation for DPRG Meet

    24 Jan 2021

    Iterate Trajectory Calculations in Preparation for DPRG Meet By Bhanaviya, Mahesh, and Ben

    Task: Improve the Trajectory Calculations

    As mentioned in our earlier posts, one of the biggest control challenges we face in this year's season is identifying a equation to model how the path of a ring launched from our launcher is affected by its angle of launch. 2 weeks ago, we were able to create a starter equation to model this trajectory. However, this time, we want to be able to identify time as not a variable but as a fixed constant and values for RPM, muzzle velocity and rotations per second of a motor. We want to be able to list these values in anticipation of our virtual meeting with the Dallas Personal Robotics this coming week where we will present both our Flywheel Launcher and the calculations we have derived so far. We anticipate that these calculations will be subject to change and our error as we go about the process of identifying how best to put our equations into code and as such, the values in this post are not final in any way.

    Our main purpose for modelling this equation is to correct the efficacy of our launcher - primarily what motor it uses and how the motor's PID values need to be fine tuned in order to provide us an ideal launch. In our previous post, we stated that the variables and constants we needed to derive the equations were:

    \(\theta\) - angle of launch

    \(hv_0\) - initial horizontal velocity of launch

    \(hv_0\) - initial horizontal velocity of launch

    \(h\))- height of goal at the third level which we know to be 0.88m

    \(d\)) - the horizontal distance between the goal and the robot

    \(g\) (approximately \(9.8 \frac{m}{s^2}\)) - acceleration due to gravity

    We initially created two equations - to represent the initial velocity of the robot horizontally and vertically. However, one key component which we originally considered to be manually calculated was time. In order to isolate time as a fixed variable, we needed to find the amount of time in seconds it would take a ring launched from the robot to reach 0 vertical velocity. We knew that for any shot that crosses through the goal with zero vertical speed, the ring needed to have an initial upward velocity such that the acceleration due to gravity brings it to zero vertical velocity at the point it reaches our target height. Regardless of what the horizontal component is, target time in this situation is governed by solely by gravity and vertical distance. Although we had initially modelled our equations to reach the summit in order to make the actual angle of launch more solvable since that would mean that we didn't have to consider "balancing" the initial height of the robot to derive the value of \(\theta\). However, seeing as the summit is the center of the portion of the trajectory with the least vertical travel for a given span of time or distance, we would not only be able to isolate time but also find \(\theta\) with the least vertical error. As such, we modelled an equation for time which can be found as shown below.

    \[\displaylines{t = \sqrt{v_0/(0.5* \(g\))}}\]

    In addition to time, we also needed to find the RPM of the motor of the launcher, for which we needed to find the circumference of the launcher, which was 0.48066m. From here, we found the radius to be approximately 0.076m, which we could use for our RPM equation which was RPM = v = \omega r, with r representing 0.076m. To find muzzle velocity, we plan on using our velocity formula as of now but this is likely to change as we continue to inspect our equation. Here are the overall equations we have developed so far now that we know how to look for time at the apex. \[\displaylines{d/cos(\theta)(t/2) = hv_0 \\ ((0.88 - 0.41) - 0.5(a)t^2)/sin(t/2)= vv_0, t = \sqrt{v_0/(0.5* \(g\))}}\]

    Next Steps:

    Using these equations, we plan to be able to identify angle of launch, RPM and muzzle velocity for a range of distances away from the goal. Mainly, we plan to derive values for a very specific range (likely 2 to 2.5m) to present our calculations as well as our equations to Dallas Personal Robotics Group in the upcoming meeting on Tuesday.

    DPRG Virtual Meeting

    26 Jan 2021

    DPRG Virtual Meeting By Bhanaviya, Jose, Trey, Paul, and Cooper

    Task: Present our flywheel launcher to the Dallas Personal Robotics Group

    Every year, Iron Reign presents our robot or standout subsystems to the Dallas Personal Robotics Group (or DPRG) - a group of professional robotics enthusiasts based here in Dallas. The DPRG are an organization in Dallas who have monthly meetings for robotics projects In past seasons, we've given them presentations about our seasonal progress in build and code. In an earlier post, we detailed the introduction of our ring launcher - the Flywheel Launcher. Initially, we had only gotten past the CAD design for the launcher, as well machining the plates and 3D-printing its nylon (which we needed to improve the 'gription' of the launcher. But today, we were able to begin the actual assembly and testing of launcher - and we were able to do all of it live on a virtual meeting with DPRG! A link to this presentation is here.

    We presented to an audience of around 18. We started off by giving them an introduction into this year's FIRST Tech Challenge game, as well as what goal specifically we were intending to attain with the flywheel launcher. For reference, the flywheel launcher consists of a spinning wheel sandwhiched between two custom-machined plates and as it the robot intakes rings, the spin of the wheels ejects rings with enough force to get it into the goal post. We started off by explaining how the CAD of the design progressed. Considering the multi-staged nature of this subsystem, it required 3 CAD sessions total and we were able to show DPRG each of these stages as well as how we went about the custom-machining of the parts.

    Next, we were able to discuss the ballistics calculations that this design inspired. In our previous two posts, we discussed the iteration of an equation we developed to model the inital velocity, muzzle velocity, RPM, and rotations/seconds of a ring launched from this flywheel, taking into account its circumference in order to determine the ideal angle of launch as well as how the PID values of the HD HEX motor on the flywheel needed to be tuned. Below is the slide from our presentation containing these values. Our ideal range for the horizontal distance of the robot is between 2-2.5m; this being said, we calculated all our values based on this range. Our equations were: Vertical: v0 = (0.47 - 0.5(-a)(t^2))/sinθ(t/2)) and Horizontal: v0 = (xF - 0.5(-a)(t^2))/cosθ (t/2)) While we couldn't perform a sanity check of these calculations at the time of their presentation, we found values from the average velocity of a frisbee to test the accuracy of our values.

    Finally, as this was ongoing, Paul and Cooper were able to assemble and perform the first-ever launch of our flywheel launcher! Since this subsystem had already been pre-modelled with all the necessary plates pre-machined, they were able to complete its assembly and test within the 40 minutes of our presentation. While the actual video of the first launch can be found on DPRG's video of the presentation, a video of a launch recorded soon after our meeting can be found here:

    At the end of this presentation, we were able to get tons of valuable feedback from DPRG - particularly about how to improve our testing process of the flywheel launcher. We anticipate that the equation we modelled earlier and those values are subject to change as our robot design becomes more sohpisticated and as we add more sources of error to the machine itself - in order to eliminate these confounding variables contributing to the launch and isolate the one that has the most effect (which we predict is the angle of launch itself), DPRG suggested that we use a Design of Experiments chart. A Design of Experiments chart is a system of organization that can be applied to virtually any machine to reflect the different variables that might affect its efficacy. More specifically, it identifies which variable had the greatest impact on a function and rank the variables in order of their influence. Applying a DOE to our flywheel launcher calculations would streamline our ability to identify which variable could have the greatest impact on our launch as we vary it by distance of launch, angle of launch, type of motor used, etc.

    Next Steps

    We are incredibly grateful to DPRG for giving us the opportunity to present our team and flywheel launcher to them for feedback. Our immediate next steps include continuing the testing of our flywheel launcher to see just how much we can improve driver control. Part of this includes fine-tuning our calculations and as we get deeper into the testing phase, we can check whether these equations work as well as they do in theory by using the DOE to identify any confounding variables. We plan on sending DPRG an updated version of our equation and calculations as we continue to periodically test and fine-tune our launcher.

    RingSlinger 9000 Build Progress

    27 Jan 2021

    RingSlinger 9000 Build Progress By Paul and Cooper

    Task: Build and prototype the Flywheel Launcher

    For this years new season we used an innovative flywheel-based launcher to score the disks into the goal. After 3 weeks of work, we also managed to come up with a name for it - The RingSlinger 9000. Any posts referring to our flywheel launcher refer directly to the Ringslinger itself. This launcher uses the properties of rotational inertia to propel the game pieces along a carefully calculated, fixed trajectory to ensure that the disks have the same launch trajectory every time, allowing both automation and driver control to more simple. The assembly is physically constructed from several sheets of aluminum and one sheet of polycarbonate, modeled by Jose and cut on our CNC mill. The spacers between the sheets are made of nylon due to its high strength and low friction, and we chose to use a custom ninjaflex ring around the CNC milled flywheel to ensure that the wheel could transfer the maximum amount of kinetic force to the disks. The launcher is designed in such a way as to impart rotational energy on the disks, spinning them. This helps maintain a constant trajectory, similar to how an NFL Quarterback spins the football when scoring a touchdown pass, or how the grooving on a rifle spins a bullet, ensuring in-flight stability. In tests, our design proved to be mostly effective, launching disks along a consistent trajectory. Our first firing test was during our video meet with the DPRG, and with a few tweaks, it was performing up to standards. However, there were some issues that needed to be addressed - mainly, we need to complete further testing to see if any of the rings experience damage as a result of our launch, where the general area the rings tend to cluster at, and fine-tuning an equation to model the launch. Correcting these issues will make the accuracy of the RingSlinger that much more accurate.

    Next Steps:

    Future plans to expand upon this design include integrating a voltage regulation module, to ensure that the disks are always spun at a constant velocity. In tests, we noticed that as time in a round passed, the drop in main battery voltage caused the disks to be launched at a slightly slower velocity, not enough to phase a human driver, but enough to render automated shooting protocols inaccurate. To remedy this, we will find out the lowest point the battery will reach during the course of a match, and regulate the voltage being fed into the flywheel motor to not surpass the aforementioned "low" voltage during the match.

    New Addtions to the Elbow

    28 Jan 2021

    New Addtions to the Elbow By Jose

    Task: Design new parts to better mount the ring launcher and encoder

    First thing to do in this CAD session is to design a secondary mounting point for the ring launcher. To do this, the existing mount was projected and any unecessary parts were removed. Only the holes for adding the REV extrusion as well as the holes for encoder pivot were left.

    The next thing to design was a mount for the encoder, as it needs to be prevented from rotating with the shaft. The closest stationary location was the REV extrusion on top of the GoBilda U-channel. This part has three holes at the bottom to be mounted on the REV extrusion, as well as a hole at the top to reach the encoder.

    Next Steps:

    As for manufacturing, we need to mill out the ring launcher mount and 3-D print the encoder pivot and holder. As for programming, the new encoder should help with aligning the ring launcher.

    Correcting the Trajectory Calculations Equations

    28 Jan 2021

    Correcting the Trajectory Calculations Equations By Bhanaviya, Ben, and Mahesh

    Task: Correct the trajectory calculations after the DPRG meeting

    In the past week, we've been experimenting with a series of equations to derive the angle of launch of our flywheel launcher when we need it to travel a certain distance. 2 days ago, we were able to present the calculations we'd derived so far to Dallas Personal Robotics Group. After feedback from DPRG and a little more testing ourselves, we've discovered the following corrections we need to make to our equation. For reference, this is a correctional post regarding our earlier calculations - you can find versions of our earlier equations and calculations in our previous posts.

    Time

    One of the biggest fixes we needed to make to our equation was identifying how to derive time as a fixed variable. We wanted to be able to find the exact time in seconds it would take for our launcher to launch a ring at 0 vertical velocity. We needed this because we knew that for any shot that crosses through the goal with zero vertical speed, the ring needed to have an initial upward velocity such that the acceleration due to gravity brings it to zero vertical velocity at the point it reaches our target height. Regardless of what the horizontal component is, target time in this situation is governed by solely by gravity and vertical distance. As such, finding time at 0 vertical velocity would allow us to model an equation for the summit of the ring's trajectory, which is where we expect the goal post to be in order to reduce variability and error in our calculations. This understanding allowed us to create the following equation for time with h representing the height of vertical travel:

    \[\displaylines{t = \sqrt{h/(0.5* g)}}\]

    Initial Velocity

    Initially, we had planned on solving for the initial vertical velocity of the ring then plugging into the equation for horizontal vvelocity, work backwards and find angle of launch. However, in order to have the most accurate trajectory possible, we expect the horizontal and vertical velocity to be varying, especially since the vertical velocity is affected by gravity and the horizontal isn't. Thus, we expect the vertical and horizontal initial velocity to look like the following, wherein t is time, initial vertical velocity is v_0 and initial horizontal velocity is h_v0:

    \[\displaylines{v_0 = g*t \\ h_v0 = d/t}\]

    Muzzle Velocity

    Initially, we had planned on using velocity on its own for muzzle velocity. However, now that we have two initial velocities, our equation for muzzle velocity changed to look sort of like the Pythogorean Theorem with us solving for c, since the muzzle velocity represents the "hypotenuse" or trajectory in this case, mV representing muzzle velocity.

    \[\displaylines{mV = \sqrt{v_0^2 + h_v0^2}}\]

    Initial Height of Launch

    Previously, we measured the height of the robot - 0.41m - to be our initial height of launch. However, one issue with the vertical travel is that if we take 0.41 to be a variable which is affected by \(theta\) then we need to figure out how much that change is for the vertical travel distance - an error bar or the design of experiments chart might work well for this so we can make sure angle of launch doesn't confound our initial measures for time and muzzle velocity since both of which rely on 0.47m (the height of travel taken by subtracting the height of the robot from the height of the goal) being constant which in turn relies on 0.41m.

    Fixed Values

    Since we know the height of travel to be 0.47m and \(g\) to be 9.8 m/s^2, using our time equation, we found time to be 0.31s. Using time, we could then find the initial vertical velocity to be 3.055m/s and horizontal velocity dependent on the distance of the robot away from the robot, which we take to be our explanatory variable.

    Our equation ultimately stays the same but the methods we used to calculate time and initial velocities have now changed, which should change our final values substantially. In our latest post, we had a set of very different values in our meeting with DPRG. However, with these edits, we now have the following calculations (which we simplified by plugging into a spreadsheet to get automated values.

    In order to sanity-check our calculations, we also derived the following parabola to represent the arc of the trajectory:

    Next Steps:

    Our immediate next steps are to model initial height as a function of \(theta\). Since we know that initial height is susceptible to change as the elbow of the robot drops and raises in accordance with angle of launch, being able to model initial height as a function will allow us to reduce all possible sources of error and find an accurate measurement of trajectory calculations. This will likely require another process like the one we did here as we attempt to model initial height as a function. W'd like to thank DPRG for all their feedback and for their help in allowing us to fine-tune these calculations!

    Derive And Translate Trajectory Calculations Into Code

    29 Jan 2021

    Derive And Translate Trajectory Calculations Into Code By Mahesh, Cooper, Shawn, Ben, Bhanaviya, and Jose

    Task: Derive And Translate Trajectory Calculations Into Code

    To ease the work put on the drivers, we wanted to have the robot automatically shoot into the goal. This would improve cycle times by allowing the drivers, theoretically, to shoot from any location on the field, and avoids the need for the robot to be in a specific location each time it shoots, eliminating the time needed to drive and align to a location after intaking disks.

    To be able to have the robot automatically shoot, we needed to derive the equations necessary to get the desired \(\theta\) (angle of launch) and \(v_0\) (initial velocity) values. This would be done given a few constants, the height of travel (the height of the goal - the height of the robot, which we will call \(h\)), the distance between the robot and the goal (which we will call \(d\)), and of course acceleration due to gravity, \(g\) (approximately \(9.8 \frac{m}{s^2}\)). \(d\) would be given through either a distance sensor, or using vuforia. Either way, we can assume this value is constant for a specific trajectory. Given these values, we can calculate \(\theta\) and \(v_0 \).

    However, without any constraints multiple solutions exist, which is why we created a constraint to both limit the number of solutions and reduce the margin of error of the disk's trajectory near the goal. We added the constraint the disk should reach the summit (or apex) of its trajectory at the point at which it enters the goal, or that it's vertical velocity component is \(0\) when it enters the goal. This way there exists only one \(\theta\) and \(v_0\) that can launch the disk into the goal.

    We start by outlining the basic kinematic equations which model any object's trajectory under constant acceleration: \[\displaylines{v = v_0 + at \\ v^2 = v_0^2 + 2a\Delta x \\ \Delta x = x_0 + v_0t + \frac{1}{2}at^2}\]

    When plugging in the constants, considering the constraints mentioned before into these equations, accounting for both the horizontal and vertical components of motion, we get the following equations: \[\displaylines{0 = v_0sin(\theta) - gt \\ 0^2 = (v_0sin(\theta))^2 - 2gh \\ d = v_0cos(\theta)t}\] The first equation comes from using the first kinematic equation in the vertical component of motion, as the final velocity of the disk should be \(0\) according to the constraints, \(-g\) acts as the acceleration, and \(v_0sin(\theta)\) represents the vertical component of the launch velocity. The second equation comes from using the second kinematics equation again in the vertical component of motion, and again according to the constraints, \(-g\) acts as the acceleration, \(h\) represents the distance travelled vertically by the disk, and \(v_0sin(\theta)\) represents the vertical component of the launch velocity. The last equation comes from applying the third kinematics equation in the horizontal component of motion, with \(d\) being the distance travelled by the disk horizontally, \(v_0cos(\theta)\) representing the horizontal component of the launch velocity, and \(t\) representing the flight time of the disk.

    Solving for \(v_0sin(\theta)\) in the first equation and substituting this for \(v_0sin(\theta)\) in the second equation gives: \[\displaylines{v_0sin(\theta) = gt \\ 0^2 = (gt)^2 - 2gh, t = \sqrt{\frac{2h}{g}}}\] Now that an equation is derived for \(t\) in terms of known values, we can treat t as a constant/known value and continue.

    Using pythagorean theorem, we can find the initial velocity of launch \(v_0\). \(v_0cos(\theta)\) and \(v_0sin(\theta)\) can be treated as two legs of a right triangle, with \(v_0\) being the hypotenuse. Therefore \(v_0 = \sqrt{(v_0cos(\theta))^2 + (v_0sin(\theta))^2}\), so: \[\displaylines{v_0sin(\theta) = gt \\ v_0cos(\theta) = \frac{d}{t} \\ v_0 = \sqrt{(gt)^2 + {\left( \frac{d}{t}\right) ^2}}}\]

    Now that \(v_0\) has been solved for, \(\theta\) can be solved for using \(sin^{-1}\) like so: \[\displaylines{\theta = sin^{-1}\left( \frac{v_0sin(\theta)}{v_0} \right) = sin^{-1}\left( \frac{gt}{v}\right) }\]

    In order to be practically useful, the \(v_0\) previously found must be converted into a ticks per second value for the flywheel motor to maintain in order to have a tangential velocity equal to \(v_0\). In other words, a linear velocity must be converted into an angular velocity. This can be done using the following equation, where \(v\) = tangential velocity, \(\omega\) = angular velocity, and \(r\) = radius. \[\displaylines{v = \omega r, \omega = \frac{v}{r} \\ }\] The radius of the flywheel \(r\) can be considered a constant, and \(v\) is substituted for the \(v_0\) solved for previously.

    However, this value for \(\omega\) is in \(\frac{radians}{second}\), but has to be converted to \(\frac{encoder \space ticks}{second}\) to be usable. This can be done easily with the following expression: \[\displaylines{\frac{\omega \space radians}{1 \space second} \cdot \frac{1 \space revolution}{2\pi \space radians} \cdot \frac{20 \space encoder \space ticks \space per \space revolution}{1 \space revolution} \cdot \frac{3 \space encoder \space ticks}{1 \space encoder \space tick}}\] The last \(\frac{3 \space encoder \space ticks}{1 \space encoder \space tick}\) comes from a \(3:1\) gearbox placed on top of the flywheel motor.

    To sanity check these calculations and confirm that they would indeed work, we used a desmos graph, originally created by Jose and later modified with the updated calculations, to take in the constants used previously and graph out the parabola of a disk's trajectory. The link to the desmos is https://www.desmos.com/calculator/zuoa50ilmz, and the image below shows an example of a disk's trajectory.

    To translate these calculations into code, we created a class named TrajectoryCalculator, originally created by Shawn and later refactored to include the updated calculations. To hold both an angle and velocity solution, we created a simple class, or struct, named TrajectorySolution. Both classes are shown below.

    public class TrajectoryCalculator {
            private double distance;
    
            public TrajectoryCalculator(double distance) {
                this.distance = distance;
            }
        
            public TrajectorySolution getTrajectorySolution() {
                // vertical distance in meters the disk has to travel
                double travelHeight = Constants.GOAL_HEIGHT - Constants.LAUNCH_HEIGHT;
                // time the disk is in air in seconds
                double flightTime = Math.sqrt((2 * travelHeight) / Constants.GRAVITY);
        
                // using pythagorean theorem to find magnitude of muzzle velocity (in m/s)
                double horizontalVelocity = distance / flightTime;
                double verticalVelocity = Constants.GRAVITY * flightTime;
                double velocity = Math.sqrt(Math.pow(horizontalVelocity, 2) + Math.pow(verticalVelocity, 2));
        
                // converting tangential velocity in m/s into angular velocity in ticks/s
                double angularVelocity = velocity / Constants.FLYWHEEL_RADIUS; // angular velocity in radians/s
                angularVelocity *= (Constants.ENCODER_TICKS_PER_REVOLUTION * Constants.TURRET_GEAR_RATIO) / (2 * Math.PI); // angular velocity in ticks/s
        
                double theta = Math.asin((Constants.GRAVITY * flightTime) / velocity);
                return new TrajectorySolution(angularVelocity, theta);
            }
        }
        
    public class TrajectorySolution {
        private double angularVelocity;
        private double theta;
    
        public TrajectorySolution(double angularVelocity, double theta) {
            this.angularVelocity = angularVelocity;
            this.theta = theta;
        }
    
        public double getAngularVelocity() {
            return angularVelocity;
        }
    
        public double getTheta() {
            return theta;
        }
    }
    

    Next Steps:

    The next step is to use PID control to maintain target velocities and angles. The calculated angular velocity \(\omega\) can be set as the target value of a PID controller in order to accurately have the flywheel motor hold the required \(\omega\). The target angle of launch above the horizontal \(\theta\) can easily be converted into encoder ticks, which can be used again in conjunction with a PID controller to have the elbow motor maintain a position.

    Another important step is to of course figure out how \(d\) would be measured. Experimentation with vuforia and/or distance sensors is necessary to have a required input to the trajectory calculations. From there, it's a matter of fine tuning values and correcting any errors in the system.

    Build Progress 1/30

    30 Jan 2021

    Build Progress 1/30 By Trey, Justin, and Jose

    Task: assemble different intake prototypes

    Today we worked on different intake systems to place the rings in the launcher. We finished our first prototype for a belt type intake and lift. The 3d printed belt was able to slide rings along a vertical piece of polycarb to place rings into the launcher. The speed of the motor and belt makes this one of our quickest intake and delivery prototypes. Our other prototype was a spatula shaped "intake" that would scoop up disks, and flip them upwards into a basket on top of the launcher. We used aluminum CNC'd into a curved spatula that would perfectly fit around the disks to ensure an accurate launch. Rubber bands pull the spatula upward, where it hits stoppers and launches the rings upwards. This prototype created semi consistent flips, but it was hard to gauge how far down to pull the spatula to give a desired launch height. A problem with this method is the many different factors that can be changed to give an optimal launch. Different launch angles, distances from the launcher, rubber band tensions and lengths. This flipper would involve a lot of experimentation that would result in mostly failures. This method also requires a lot more driver skill to scoop up the relatively small disks.

    We also tested our fully assembled launcher - the Ringslinger 9000 - with working code. We wanted to measure how consistent our launches were by shooting multiple rings at a target and measuring the furthest distance between impact points. We used flour on a flat surface to show where the rings were hitting, then circled the clusters for our trials to get an approximate radius of error. We found that our launches were mostly consistent within a small radius, but had outliers that were hitting the exact same outer lying spot. This indicates a consistent flaw with our launcher and requires a closer look at how it moves and launches the rings. We also repeated this test by identifying where the rings tended to cluster when they had been launched beyond the length of the goal-post - even though the Ringslinger 9000 was not supposed to launch rings at such a height, identifying where it tended to cluster after landing also allowed us to evaluate its general launch patterns and accuracy.

    Next Steps:

    The belt system can easily grab disks and brings them to the other end of the ramp very quickly. While it works well when we test it with our hands, we need to create a rigid structure to connect the belt and ramp, which will be mounted on the chassis. This will allow us to see how the belt will need to pivot to grab rings, and if our current belt still maintains grip without human assistance. We will also take a closer look at our launcher to see what's different about our outlier launches.

    Programming Session 1/31

    31 Jan 2021

    Programming Session 1/31 By Mahesh and Cooper

    Task: Set up FTC Dashboard

    We wanted to setup FTC Dashboard for graphing, configuration, vision, and later on, odometry. FTC Dashboard enables graphing of numeric variables, which can simplify PID tuning enormously through plotting the current position/velocity and the target. Additionally FTC Dashboard enables real-time editing of configuration variables, and in the context of PID tuning, this enables PID constants to be edited on the fly. With the later goal of implementing odometry for localization, FTC dashboard can be used to draw the robot's pose (position and heading) on a canvas, to easily confirm the accuracy of our odometry calculations. Dashboard also allows for images to be sent, allowing us to also debug our OpenCV vision pipeline.

    We used FTC Dashboard during this coding session to tune the coefficients of our newly created flywheel velocity PID loop. This would ensure that our flywheel would be able to maintain the desired angular velocity we want it to, in order to consistently shoot the disk into the goal using our trajectory calculator.

    Next Steps:

    The next step is to harness the power of FTC Dashboard to verify our odometry calculations by drawing the robot's pose information onto the canvas, using vectors/arrows to signify the base's heading, the turret's heading, and the bearing from the robot to the goal. This would point out any glaring errors in our odometry calculations, and would serve to visually represent the degree of error our calculations would naturally experience as a result of slippage and other factors.

    Pink v. Cyan Remote Scrimmage Post Mortem

    31 Jan 2021

    Pink v. Cyan Remote Scrimmage Post Mortem By Cooper and Jose

    Task: review the progression of matches in our latest scrimmage

    We participated in the “Pink v. Cyan Remote Scrimmage” over the week, wherein we submitted our matches at an appropriate amount of time before the cutoff time. Doing this scrimmage has given us good insight into how to tune the performance of what is on the robot already, and what needs to be added. We submitted the standard 6 matches, and I want to go in depth for each.

    Before I delve into the weeds, I would like to explain our hypothetical perfect run for these matches. In auton, since we aren’t using vision quite yet, we had the robot always assume a 4 stack. The robot should put the wobble goal we are holding in the start ibn the appropriate corner tile, then backup to park on the line. In teleop we should retrieve the second wobble goal and put it across the line. With this all such that we can, in the endgame, put both of the wobble goals over the back wall. So therefore, in a perfect run, we could have 60 points max. An example can be seen in the video above.

    Match 1: Starting off on the wrong foot, when we started auton things looked fine. However, our pink decorations on the front of the robot got caught in the front caster wheel, making us veer off and hit the wall. We were able to re-orient the robot since the next few steps of the auton were based on the imu. However we didn’t park due to being off of the expected final position of the first movement. During teleop we successfully moved both of the wobble goals over to the other side of the shooting line, and then in teleop we just barely ran out of time putting down the second wobble goal over the back wall.

    Match 2: We got lucky in the second round and got the preferred 4 ring stack. However, we couldn’t make use of that luck due to a driver error when selecting the auton-- auton did not execute. So in teleop, we moved both wobble goals over to the correct side of the shooting line. Then, in the endgame, we successfully moved one wobble goal over the wall. The second we ran out of time trying to grab.

    Match 3: This time around, we had the opposite happen from the last round in auton. The rings randomized to be a 1 stack, but auton performed perfectly. Teleop was nominal, but endgame posed a new problem. When trying to put the wobble goal over the wall, it got stuck on the turret, seen in the video below at 2:44. This costed us enough time to have us not score any of the wobble goals

    Match 4: this is the video at the top of the post, because it was a perfect match.

    Match 5: Like match 3, we were randomized 1 ring, and auton performed perfectly. Unlike match 3, teleop and endgame were normal, with us scoring 1 wobble goal.

    Match 6: Final match, auton almost worked. The wall-following messed up at the very end of the first run, making us drop the wobble goal just out of the box, and miss parking. In teleop/endgame, we almost had a repeat of match 3, but we were able to shake off the wobble goal and score one.

    To start on the subject of lessons learned, It is obvious we should practice more. Driver practice has always been a weak area for us.(Having said that, for the amount practiced the driver did excellent). One thing the driver should not have had to account for is that possibility to lodge the wobble goal on the robot. This is subject to change anyways, as when the launcher is mounted on the robot, the wobble gripper is going to have to move. Not only move, but change; the current gripper has too tight a tolerance to be used effectively. It isn’t possible to have it stay the way it is when drivers will also be tasked with picking up rings. Finally, we learned that we need to work out the kinks in the wall following what happens at the beginning of auton. We only really did this, because we are still working on a better way to square the IMU to the field, and the human error was too great and cumulative on that far run to have it work reliably.

    Next Steps

    Execute the solutions to the problems found.

    DPRG Virtual Meeting 2/9

    02 Feb 2021

    DPRG Virtual Meeting 2/9 By Bhanaviya and Mahesh

    Task: Present our flywheel launcher to the Dallas Personal Robotics Group

    2 weeks ago, Iron Reign presented our Ringslinger 9000 - our launcher, for brevity - to the Dallas Personal Robotics Group. For reference, Dallas Personal Robotics Group, or DPRG, are a group of robot enthusiasts and engineers who host weekly meetings to discuss personal projects in robotics. This meeting, Iron Reign had the opportunity to present our progress in build, code and documentation to DPRG based on the feedback we receieved from them from 2 weeks ago. You can find a link to our post detailing our first presentation with them this season here.

    We presented to an audience of around 20. We started off by giving them an update of our trajectory calculations. The last time we presented, we showed DPRG the initial version of our calculations which were meant to depict the trajectory of a ring launched from the Ringslinger 9000 when it was a certain distance away from the goal posts. Both the changes to our initial calculations as well as our takeaways from the first DPRG meet are in an earlier post in the Engineering Section of our journal. Using feedback from DPRG on our initial equation as well as what we could do to make it more accurate, we were able to generate a new set of calculations and equation, both of which we could show to DPRG. We also provided them with links to the corresponding blog posts which you can find here.

    Next, we focused on showing them the code and build changes that occurred over the week. Since the last time we presented, we could show DPRG the assembly of our launcher as well as its very first launch, this time, we could show them multiple test shots of the launcher we had recorded over the week in slow motion. You can see one of the videos we showed to DPRG below. DPRG members provided us with suggestions to improve the trajectory of our launcher including checking for ring damage and showing our equation and calculations to an expert in the field for review. One of the more fun takeaways of this meeting was that we were also able to put our various ideas for a launcher name up for vote and we settled on the Ringslinger 9000 thanks to input from DPRG. All references to our launcher will, from this point onwards, be referred to as the Ringslinger 9000.

    Next Steps

    We are incredibly grateful to DPRG for giving us the opportunity to present our team for feedback. Our immediate next steps include continuing the testing of our flywheel launcher to see just how much we can improve driver control. Part of this includes ramping up our testing progression as we get closer to the qualifier. We plan to meet with DPRG after our first qualifier to present our progress and performance as we seek to improve our robot and launcher capabilities.

    Intake Iterations Summary

    03 Feb 2021

    Intake Iterations Summary By Bhanaviya and Ben

    Task: Go over our 5 intake iterations

    This season, we experimented with 5 gripper models - both for our robot in three days project and for our competition bot. While we do not plan on using all 5 of these models, they allowed us to effectively implement the engineering process within our build season. Experimenting with each intake helped us to identify the potential of each design as well as how two individual designs could be combined to create a more efficient one. Each of these designs has its own article but this is just a summary of all of our intake designs so far.

    1)Archimedes Intake

    This was one of our first designs and it was based on an Archimedes screw. A screw shaped surface would draw the rings from the fields and directly to the launcher. While this would have been a great feeder, our primary issue was that would essentially be a slower system which could likely only draw in ring at a time so it never progressed past its CAD stage.

    2) Ladder Intake

    This gripper functions with a series of omniwheels mounted in between two rev extrusion bars, which in turn are connected to a ladder-like assembly with a control hub mounted on the first rung of the ladder and to the wheels. As the wheels rolled, they would slide on top of the rings and roll them into the system. The issue with this system was that it had significant delay in "rolling" the rings in since if the omni wheels spun too fast, they would lack the tracton to "grip" onto the wheel.

    3) Belt Sander Drive

    This system was far more simplistic than our earlier ones and had a faster intake speed during testing too. The actual drive would be mounted onto the robot with the "back" of the system sliding over the rings and carrying them across the conveyor belt to the top of the robot. Despite its efficacy, it had one main issue - it didn't have the gription needed to ensure the rings slid across the belt.

    4) Caterpillar Intake

    Luckily, the gription issue could be resolved pretty easily with the caterpillar intake. This system was dual tracked unlike the first one, and had rubber bands threaded through the tetrix tracks to improve gription with double the power. Ultimately, this was a pretty successful issue but it did not have as much speed as it could have and lacked the signature Iron Reign charm.

    5) Ringevator Ultra Flex Unlimited Intake

    This gripper, the Ringevator, for short was a combination of our two previous best systems - the belt sander drive and the caterpillar. It possessed the mono-drive from the belt sander and similarly drew in rings from its back and carried them across a conveyor belt to the top of the robot and like the caterpillar, had a means for increasing friction with the surface of the rings. While the caterpillar intake did this with rubber bands, the Ringevator accomplished it with ninjaflex "fins" layering the "belt" to sweep in the rings. Both sides of the intake are covered with polycarb to encase the conveyor built internally and to ensure the rings don't fall off when picked.

    Next Steps

    Now that we have analyzed all of our intake designs so far, it will be easier for us to streamline the best design to mount on the robot. While the ringevator seems to be our best choice, we still need to conduct further testing to see which one is the most efficient.

    Materials Test Planning

    04 Feb 2021

    Materials Test Planning By Bhanaviya

    Task: Create a system to test our materials to better understand their grip potential

    Here at Iron Reign, we're used to using off-the-shelf materials for our robot. For this season, these include pillowcases (front and back) and an Einstein wig, since we are looking for materials with lesser grip. However, we need to do a thorough investigation of these materials before we can determine their efficacy on the robot.

    Specifically, we plan to implement these parts on a ramp connecting the intake and our launcher. Although we have not yet mounted our intake onto the robot, we expect to have a launch leading down from the intake to the launcher to enable to ring to slide down and then be launched. This requires a material with very less grip and a lot more slip. However, before we can decide which material would have the best grip, we need to test them to determine their on-robot properties. To do this, we will implement a slip test as shown below.

    The main thing that we want to test is the amount of energy they have while sliding and then the amount of energy they lose upon collision. We plan to test this through the coefficient of friction of the mitts. Simply put, we will place the ring on top of the of the pillowcases/wig and will tape down the material being tested on a flat surface. Then, we will lift the surface and using simple inverse trigonometric properties, we will calculate theta, the angle at which the stone begins to slip from the material. The bigger the angle, the higher the friction coefficient of the material, which equates to it having better grip. Since we are looking for a material with the least grip possible, we will be looking for the material with enables the ring to slide down at the smallest angle.

    Next Steps

    With our testing planned out, we will next begin documenting the angle at which the ring slips from each type of material. The calculations from the actual testing, including the equation we used, will be inputted into a separate post.

    RingSlinger 9000 Summary

    05 Feb 2021

    RingSlinger 9000 Summary By Jose

    Task: Summarize the key components of Ring Launcher 9000

    A ring launcher is more than just a flywheel; it needs a barrel to give the ring a path to move through. A 90 degree barrel is the best fit for ROBOT as the intake will take up the other half of the robot. The plan is to later on add an indexer to transport rings from the intake to the barrel in a way that can be controlled, that is, allowing the driver to manually choose when to let rings into the barrel.

    The barrel design looks simple, but there are lots of hidden things making it work as intended. For one, the motor driving the flywheel is attached via a slotted motor mount. The mount is then placed directly on the center plate through an extension to the center plate. Additionally, there is a plate below the one that the ring travels on top of. This plate is used to keep the shaft in place, it follows a similar shape to the others to preserve strength, as it is half of what keeps the flywheel in place. The bottom plate also supplies support to the center plate, this is due to the fact that the center place is not attached to the flywheel, instead it has 3mm of clearance in case of any vibration the flywheel may have. Finally, at the exiting end of the barrel, the side wall extends linearly to ensure the ring doesn’t spin off its intended path.

    Over to the other side of the barrel is the ring feeder. A huge nylon wall guides the rings into the ring flipper. The ring flipper is composed of a a servo with a custom made flipper to push rings into the flywheel.

    Next Steps:

    With everything milled out and 3-D printed, the next step is to take this to programing as the idea is to have the ring laucher be almost completely automated.

    Ring Launcher 9000 On-Bot Testing

    05 Feb 2021

    Ring Launcher 9000 On-Bot Testing By Cooper and Jose

    Task: Test the intake now that it is on the robot

    Today we performed proper field testing of the Launcher subsystem. While we have done many tests in the past with it, this was the first time we ran arrays of consecutive shooting with the launcher on the robot. Doing this meant some small modifications that led to an evolution of the “trigger” of the subsystem. Performing the tests was one of my friends, who we let drive the robot to gauge interest in being in the robotics program, and his ability driving.

    First, lets cover the trigger evolution, which is what lets us more smoothly conduct the tests. As it stood, and as pictured above, the trigger was a single spike-like piece of 3-d printed nylon attached to a servo. Wherein it pushes rings into the flywheel to shoot them. It’s main body follows the contour of the shooter’s body that is directly above and below it, as to conserve space. We initially thought that this would be feasible to keep so small, however, we noticed in previous testing that the rings did not chamber correctly when fed by the in-built gravity-fed magazine. The ring would fall onto the trigger, and tilt backwards, leading to the ring getting jammed behind the trigger when it tried to return to its original position. That effectively meant that we could only shoot one ring before we would have to physically reload. To combat this, it was devised that a small plate would have to be added to the top of the trigger, protruding at the back top of the trigger. Since it was just me and the driver there that day, I fashioned a mock-up out of cardboard and painters tape, as seen in the video below. You might also notice a cardboard piece in front of the rings in the magazine, and this was another impromp-to thing, which addressed the unforeseen movement of the rings in the magazine during on-bot use. This ended up, later that night, for the resident CAD/CAM expert, Jose, to make adjustments to the model. The following day, a version of the trigger was printed that had the plate, and was tested/proofed to see that it worked as expected.

    Moving on, let's talk performance. The shooter, after replacing the motor gears and removing an elastic band from the arm, did wonderfully. When firing consecutively in the same position, the effective spread of the shots was tight enough to actually hit whichever goal was being aimed for. The driver also came up with a test, where he would shoot a goal, move, and then return to the same position, to see if the turret auto-turn was fine enough. Turns out, having a different subsystem with different weight distributions means that the PID coefficients aren’t properly tuned. Of course this was to be expected, but it wasn’t too off, suggesting that all that needs to be done is to adjust ki and kd.

    Next Steps:

    Tune said coefficients, make a final version of the magazine retainer, and further test the driver.

    Accounting For Initial Height

    06 Feb 2021

    Accounting For Initial Height By Mahesh

    Task: Account For Initial Height

    In the previous trajectory calculations post, "Derive And Translate Trajectory Calculations Into Code", we did not take into account how the length of the launcher would effect our calculations. In reality, the height the disk would have to travel would be shortened by the launcher, since when titled at an angle the vertical distance would be shortened by \(lsin(\theta)\), where \(l\) represents the length of the launcher. This is because our launcher is mounted on a hinge, and therefore the rotation of the launcher affects the position where the disk leaves the launcher.

    To take this into account, we would have to add \(lsin(\theta)\) to the vertical distance the disk has to travel, however, \(\theta\) depends on this distance as well. To solve this problem of circular dependency we can use an iterative method. This is because when \(\theta\) is calculated for a given trajectory, the initial height of the disk will be raised by \(lsin(\theta)\). This means the disk has to travel less distance vertically, meaning that \(\theta\) will be smaller with the new launch height. But, when \(\theta\) is decreased, so will the launch height, will in turn will raise theta, and so on. This process is convergent, meaning that iterating the process described above will eventually yield a \(\theta\) whose change in the launch height is reflective of the launch height's change in theta. The following process can be used to find the convergent \(\theta\):

    1. Calculate \(v_0\) and \(\theta\) from the current launch height
    2. Find the new launch height given the previously calculated \(\theta\)
    3. Repeat steps 1-2

    We graphed out the convergence of \(\theta\) to confirm that these calculations would work correctly. Below is an image of the convergence of \(\theta\) given a distance of 4 meters and a launcher length of 0.3 meters:

    To exaggerate the effect here is another image with a launcher length of 1.8 meters:

    Next Steps:

    The next step is to implement this in code to account for the height of the launcher, a fairly simple task. Tuning the iterations for performance vs accuracy won't really be necessary since \(\theta\) seems to converge exponentially and iterations happen very quick on modern hardware anyway.

    One concern still exists which is that the horizontal distance the disk has to travel is also effected by the launch angle \(\theta\). However, this would only effect the distance by a matter of fractions of a centimeter, so it is likely not a big problem. If significant errors are encountered which cannot be traced down to other hardware or software defects/bugs then we can consider taking into account the effect that \(\theta\) has on distance, and vice versa.

    Meeting Log

    06 Feb 2021

    Meeting Log By Ben, Bhanaviya, Cooper, Jose, and Trey

    Task: Prepare the portfolio and intake before the qualifier

    The three of us worked on the engineering portfolio, discussing what we needed to get done in these 3 weeks between now and the qualifier. It was agreed that Ben, Bhanaviya, and Jose would be largely responsible for the portfolio and having other team members add information when necessary. We also began drafting an email to a physics professor who may help us with our physics calculations.

    Trey and Justin mostly worked on rebuilding the ring intake to make it easier to mount onto the robot. They also rebuilt parts of it to make it easier to service in the future. There were little issues with this, although access to the robot was limited at times during code testing. Time constraints also played a role in the progress that was made.

    Cooper had planned on calibrating the ticks/degree on the arm, implementing the trajectory calculator, fixing the LED on the robot, and making progress on Vuforia. By the end of the work period, he had successfully calibrated the ticks per degree on the robot arm and implemented the trajectory calculator. He decided to fix the LED later because of its low priority and time constraints restricted progress on Vuforia.

    Next Steps

    The next steps for the portfolio are to begin formatting and gathering information for all the subsystems and from team members. Once we have all the information, we will have to condense it into an easily-digestible 15 pages. We will also have to fix the LED lighting solution on the front of the robot, along with troubleshooting Vuforia.

    Adding Margins Of Error To Desmos

    13 Feb 2021

    Adding Margins Of Error To Desmos By Mahesh

    Task: Add Margins Of Error To The Desmos Calculator

    In order to visually represent the significance of placing the constraints we did, we modified our desmos trajectory calculator to include a margin of error box. This box would help to highlight the importance of keeping the summit of our trajectory aligned with the goal, and how deviations from the summit would result in drastically increasing margins of vertical error for the same horizontal error.

    As seen above, even with the same theoretical horizontal margin of error, having the goal (which can be thought of as the center of the error rectangle) placed further from the summit of the trajectory results in a larger vertical error. This helps to visually justify why we chose to have the summit of the disk's trajectory at the height of the goal, because the disk's vertical margin of error is minimized with that constraint.

    Additionally, we are able to minimize the energy required to launch the disk. This is because, by the law of conservation of energy, the energy at any point in the disk's launch must be equal to the energy at any other point. We can consider the point where the disk is about to be launched from the launcher and the point where the disk is at it's maximum height. The total mechanical energy (kinetic energy + gravitational potential energy) of the disk in these two points must be equal.

    Kinetic energy is represented by \[\displaylines{K = \frac{1}{2}mv^2}\]

    and gravitational potential energy is represented by \[\displaylines{U_g = mgh}\]

    The higher the disk goes, the larger the total mechanical energy of the disk at the highest point in it's trajectory, since \(U_g\) is proportional to \(h\). And by the laws of conservation of energy, the energy at the start of the launch would have to equal this larger mechanical energy for the disk to reach a higher altitude. By having the disk only go as high as it needs to in order to reach the goal, we minimize the total energy we need to put into the disk and the initial velocity of the disk at launch (since \(K\) is proportional to \(v^2\)). This is ideal for our flywheel as the likelihood of it being not fast enough is minimized.

    The link to the edited desmos calculator can be found at https://www.desmos.com/calculator/csxhdfadtm, with \(E_c\) being the variable to control the center of the error rectangle and \(E\) being the variable to control the margin of horizontal error.

    Ringslinger 9000 Step-by-Step Guide

    13 Feb 2021

    Ringslinger 9000 Step-by-Step Guide By Anisha, Paul, Trey, and Cooper

    Task: assemble different intake prototypes

    The Ringslinger 9000 is a crucial part of the robot and requires careful planning to build. Although we have a relatively simple intake and launching mechanism, their components are a bit more complicated. After getting the individual pieces of our launcher system ready, we were able to start putting them together to form the system. This post will serve as a step-by-step guide on how the entire launching system was assembled.

    The process starts with the launcher baseplate which was constructed using aluminum and was cut on the CNC mill. As shown in the picture above, several holes were strategically placed in various areas on the periphery of the plate for screws to go to hold the other elements such as the Ultraplanetary REV motor that powers the flywheel and the nylon guide wall which guides the rings as they move through the system. The plate itself is mounted onto 2 REV extrusion bars using several metal brackets as shown below.

    The bars are mounted onto a hinge which carries the entire system and rotates as needed during the game.

    Launcher Guidewall/extension

    The custom-printed guidewalls are attached to the plates using retaining screws, and function to guide the rings to the flipper to be prepared for launching.

    Motor Mechanism

    The REV 3:1 Ultraplanetery motor which drives the flywheel is attached via a slotted motor mount as shown below. It is then placed on an extension of the launcher baseplate using 6 screws. The motor can spin its sprocket at 1,727 RPM and drives the wheel by a belt between the two sprockets.

    As mentioned in the Ring Launcher Summary, our launching system essentially is made out of 3 levels: the mounting, driving, and ring levels. The pictures below show the driving level's center plate with 3D printed nylon spacers mounted to separate it from the ring level. The spacers closest to where the flywheel will be attached each contain 2 holes and are attached by screws. The larger spacers also contain 2 holes where screws are attached to mount the driving and ring levels together. After getting the two individual levels ready, they are put together using screws, as shown below.

    Shown below is the custom-made servo spacer. The servo is mounted next to the opening that is next to where the motor is mounted. It is fixed into place using screws.

    Pictured below is a bird's eye view of the center plate. The servo located on the back of the ring slinger essentially spins the ring flipper to exert motion onto the rings to prepare them for launching by pushing them into contact with the flywheel. The REV Ultraplanetery motor is mounted onto the platform using 4 screws and nuts and the servo is mounted also using 4.

    The flywheel is composed of a NinjaFlex center wheel which is sandwiched between 2 custom aluminum plates.

    The flywheel's upper aluminum plate works to keep the wheel from flying upward. A polycarbonate sheet works with its lower aluminum plate to fix the axle in place. The polycarbonate sheet is shown below. It also plays a role in keeping parts in place.

    The Flywheel is attached to a pulley which drives it using the belt that runs from the wheel pulley to the REV motor. As seen in the CAD model above and the picture below, the wheel was assembled by connecting the 2 aluminum plates to the NinjaFlex wheel in the center using screws. The flywheel spins on the shaft that is locked into place with the shaft collar on each end.

    As shown above, the whole launching system to the arm that sits on a pivot in the back of the robot which adjusts itself by rotating to the angle that is ideal for where a ring needs to be launched to.

    Finally, a look at the robot after all the individual parts were assembled is pictured below.

    Next Steps:

    One of the highlights of this system is that it is completely custom-designed and built . All our parts were either 3D-printed or custom-machined on our CNC. Documenting its assembly allows us to keep track of all of the parts involved in its print. Being able to showcase the build stages of the Ringslinger 9000 is also incredibly useful for two more reasons. First, if we ever intend to build a second one, we have the progress of the first one fully documented for inspiration and/or to isolate potential causes of structural error. Second, if any teams who follow our blog want to create a similar model, they have ours for a source to help. As the launcher continues to undergo changes, it is likely we will create another such assembly post - likely after our first qualifier in 3 weeks.

    Achieving Continuous Targeting and Launching

    17 Feb 2021

    Achieving Continuous Targeting and Launching By Mahesh and Cooper

    Task: Achieve Continuous Targeting and Automatic Launching

    With the goal of having the turret continuously aim towards the goal, the elbow tilt to the correct angle at will and the flywheel to ramp to the correct velocity at will, we began by verifying our odometry calculations using FTC dashboard. Our odometry calculations would be the cornerstone of our entire automatic launching system, since the distance between the robot and the goal as well as the bearing to the goal from the robot would both be determined using the robot's x and y position as given through odometry. Using FTC dashboard's field overlay, we were able to draw our robot as a circle onto the given canvas like so:

    In the above image, the bottom circle represents the robot, with the top circle representing the goal. The longest black vector represents the heading of the drivetrain or base of the robot. The second to longest red vector represents the heading of the turret of the robot. The shortest blue vector, which is the same size as the circle robot itself, represents the bearing from the robot to the goal.

    The blue and red vectors (bearing to goal and heading of turret) are equal in direction because of the PID loop running to continuously target the goal. We are able to accomplish this by setting the target heading of our turret PID controller to the bearing between the robot and the goal, which can be calculated with: \[\theta = tan^{-1}\left(\frac{y_{goal} - y_{robot}}{x_{goal} - x_{robot}}\right)\] The PID controller compares this target angle with the IMU angle of the turret and corrects for them to be equal.

    As for the other part, automatic launching, we were able to achieve this using our previously made trajectory calculator. The input to our trajectory calculator, the distance between the robot and the goal, was calculated using: \[distance = \sqrt{(y_{robot} - y_{goal})^2 + (x_{robot} - x_{goal})^2}\] The outputs of the trajectory calculator, the angle of elevation of the elbow and angular velocity of the flywheel, were then set to the targets of the elbow PID and flywheel PID controllers, in order to consistently hold the desired articulation. When the flywheel ramped up to a velocity in a 5% error threshold of the target velocity, we toggled the trigger servo and launched the disk, with the ramping of the flywheel seen below through FTC dashboard:

    Next Steps:

    By testing our continuous target and automatic shooting system, we quickly realized our calculations were slightly off. The next obvious step is to diagnose any sources of error in our calculations and account for them appropriately. The main one being how the angle of the launcher affects the vertical distance travelled by the disk (initial height of launch), and vice versa. This can be done using the convergent, iterative process described in a previous post. Other sources of error could include the turret being offset to the right of the center of the robot, and a later discovered glitchy flywheel power cable. We can now advance from simply implementing our theoretical calculations to diagnosing issues with them and addressing errors in our robot.

    Control Mapping

    20 Feb 2021

    Control Mapping By Bhanaviya, Mahesh, and Cooper

    Task: Map and test controls

    With our first qualifier being a week away, Proteus (our robot) needs to be in drive testing phase. So, we started out by mapping out controls as depicted above.

    One stark difference between this control map from previous years is that there a lot more controls than previously since one of our team goal's this season was to reduce human error as much as possible when it pertained to driving and having more expansive controls was reflective of this goal. For instance, last year, when our turret was still in use as in this year, we had two controls for rotating the turret. However, this season, since turret rotation allows us to maximize our capabilities when it comes to continuous targetting, we've set aside 4 controls for turret rotation alone since being able to vary its speed manually is something we've had difficulty with earlier in the season.

    Next Steps

    As the season changes, we expect our controls to change as well and we will document these changes accordingly as time progresses.

    A Lot to Intake

    20 Feb 2021

    A Lot to Intake By Paul

    Task: Prepare the intake before the qualifier

    Today’s meet consisted of Cooper working on code, Paul burning polycarb, and Trey working on the intake with Paul. We were able to get the ringevator-esque intake working with some level of reliability, at least off the robot. The design is quite ingenious, using the friction of the rings against the floor and a polycarbonate scoop-type thing to integrate the flipping of the rings and the lifting of the rings into one cohesive unit, that saves space, motors, and weight. Paul was in charge of heat-bending the polycarbonate plate, but Paul overheated it and ended up warping the plate. However, this proved to be quite useful, as the warp helped to hold the rings against the ninjaflex elevator belt. Sometimes, rarely, screw-ups are a good thing.

    Meanwhile in the robot garage dungeon, Cooper was working on optimization of the code and helped to optimize the odometry, calibrating the robot's autonomous mode to be more accurate based on its surroundings, using both the IMU and potentially an intel RealSense camera in the future. In addition, Cooper worked to enhance the robot’s position holding and automatic targeting systems, helping to ensure that the ring lands in the goal, every time, automatically. Pretty neat stuff.

    In the more whimsical department, the robots 12-round chefs-hat extendo-mag turns the robot from an FTC legal precision machine to a motorized fear-inducing machine. This extended mag was used for demonstration, target testing and shooting rings at unsuspecting team members only, as FTC regulations only allow the robots to be in control of 3 rings at a time, not 12 (though that would be kinda cool).

    Next Steps

    With the ringevator mounted, we plan to get the mag removed by the next meet to create more precision with our launcher system.

    Accounting For Offsets And Launching In Motion

    21 Feb 2021

    Accounting For Offsets And Launching In Motion By Mahesh

    Task: Build A Forward Kinematic Model Of The Robot To Account For Turret And Muzzle Offsets, And Counter-Lead The Target To Allow For Launching In Motion

    After building the base of a trajectory calculator to allow for continuous targeting and launching, the next step was to address the discrepancies between our robot in code and the real robot, a major one being the offset between the muzzle compared to the center of the robot. Thus far, we had been treating the muzzle exit point as the center of the robot, which in reality isn't the case. The center of the turret is positioned behind the center of the robot to be flush with the back edge, and muzzle is positioned in front of and to the right of the center of the turret. In order to account for these offsets in code, we would have to build, in technical terms, a forward kinematic model of the robot to figure out the final (x, y) position of the muzzle, or the point at which the disk leaves the robot.

    To account for the turret's offset we calculated the center of the turret to have the coordinates: \[\displaylines{x_t = x_r - dcos(\theta_r) \\ y_t = y_r - dsin(\theta_r)}\] where \(x_t\) and \(y_t\) represent the x and y coordinates of the turret respectively, \(x_r\) and \(y_r\) represent the x and y coordinates of the robot respectively, \(d\) represents the distance between the center of the robot and the center of the turret, and \(\theta_r\) represents the heading of the robot's base.

    We then took \(x_t\) and \(y_t\) and used them to calculate the muzzle exit point using a polar approach: \[\displaylines{x_m = x_t + rcos(\theta_t + \theta_m) \\ y_m = y_t + rsin(\theta_t + \theta_m)}\] where \(x_m\) and \(y_m\) represent the x and y coordinates of the muzzle respectively, \(\theta_t\) represents the heading of the turret, and \(r\) represents the "radius" of the muzzle, and \(\theta_m\) represents the "angle" of the muzzle. In reality, the terms "radius" and "angle" of the muzzle don't make sense since the muzzle is positioned in front of and to the right of the turret, and using a cartesion approach we would have to make two separate adjustments for the x and y for the vertical and horizontal offsets, however converting these offsets into a polar form can help to simplify the process, and is where a "radius" and "angle" are derived from. If the horizontal distance between the muzzle and the turret center is \(o_x\) and the vertical distance between the muzzle and the turret center is \(o_y\) (when the robot is viewed from the top-down), then \(r\) and \(\theta_m\) can be derived like so: \[\displaylines{r = \sqrt{o_x^2 + o_y^2} \\ \theta_m=tan^{-1}\left(\frac{o_y}{o_x}\right)}\] \(r\) and \(\theta_m\) are used in the previous equations for \(y_m\) and \(x_m\) to derive the final position of the muzzle exit point, and completes the "forward kinematic model" of our robot for trajectory calculation purposes. \(x_m\) and \(y_m\) are then substituted for \(x_r\) and \(y_r\) in all trajectory calculations to account for all offsets from the center of the robot. In the first image on this post, the turret can be seen repositioned from the center of the robot with a heading labeled with a red vector, and the muzzle can be seen with a smaller circle containing a neon-green line to the currently selected target.

    Our second task was to allow the robot to launch at its target while in motion. The first step of achieving this would be to address how the robot's velocity in the x direction would affect the trajectory of the disk. We would have to counter-lead the target in the x direction to account for side-to-side motion of the robot while launching. This is because when the robot is moving with a velocity \(v_x\) in the x direction while launching, the target will be offset by a factor of \(v_x \cdot t\), where \(t\) represents the time the disk spends in the air. To account for this we can simply subtract \(v_x \cdot t\) from the target's x position in order to counter-lead it.

    To account for the robot's velocity in the y direction (\(v_y\)) we can subtract \(v_y\) from the disk's horizontal velocity calculation, which then becomes \(\frac{d}{t} - v_y\). This effectively adds the robot's y velocity onto the y velocity on the disk, which reduces the needed horizontal velocity of the disk, hence why \(v_y\) is subtracted.

    With these two additions, we can now, at least theoretically, launch in motion. In practice, we saw that our underdamped PID controller could not keep up with the bearing to the counter-led target. In a perfect world, the turret's heading would equal the bearing the offset target, although due to poorly tuned PID coefficients, this was not the case. With some tuning we hope to correct this and get the turret to somewhat lock on to the offset target while the base is in motion.

    Next Steps:

    Our next steps would be to continue addressing small errors in between our robot in code and our robot in the real world, perfecting our trajectory calculator to maximize accuracy and precision. From a few tests we determined our successful shooting rate was around 75% from a fixed location, which can be used to conclude that there are mechanical faults at play as well, which could be a non-stationary elbow or unbalanced flywheel. These are all investigations to delve into later in order to perfect our automatic launching.

    A Lot to Intake

    22 Feb 2021

    A Lot to Intake By Paul

    Task: Prepare the intake before the qualifier

    At today's meeting, Paul worked on the ringevator, with the guidance from Mr. V. The intake mechanism required a motor to be installed, which at first glance seems like light work. However, the intake is composed of two separate parts that move independently, connected by a hinge. The motor had to be attached to the static, robot part, however, the power had to be transferred to the belt, which just so happened to be on the dynamic part that swings around like a screen door in a hurricane, so mounting the motor on the swingy bit was out of the question. Paul took a page out of last years book, drawing inspiration from the elbow mechanism of Icarus and with some help from Mr. V, designed a mechanism that allowed the belt and hinge to rotate on the same axis, ensuring constant distance between the motor axis and the axis of rotation for the belt pulley. This allowed the motor to be mounted in a safe spot on the robot, away from the dangers of an FTC field, while simultaneously being able to drive the belt mechanism on the moving part of the robot. Future plans call for replacing the pulley drive bushings with custom fabricated ball bearings, and moving the motor further down the robot to lower the center of gravity.

    Next Steps

    The ringevator still needs to be mounted on the robot but this was enough progress to hopefully get us to a working intake before the qualifier.

    Morph Chart

    24 Feb 2021

    Morph Chart By Bhanaviya and Ben

    Task: Create a flow chart to analyze all our intake designs so far in this season.

    Iron Reign has seen several iterations of our intake over this past build season. With our first qualifier being 2 days away, its finally time to come full circle and identify the different iterations of our intakes coming together. To do this, our team used a flow chart. A morph chart shows the various subsystems of our 2 robots in this system - our robot in 2 days bot Frankendroid and our competition bot TomBot.

    Each intake's progression is represented vertically, shwoing stages from the sketch, to the CAD to the final product. For the Ringevator intake design in particular was inspired by a combination of two other intaek designs - the belt drive and caterpillar. The combination of these two designs, as well as a description of each design is also represented on this chart.

    Next Steps

    Placing all of our designs in one chart like this allows us to see how iterative our design process has been, and how much of an influence each design has had on another. With all of our designs so far placed in the flow chart, our next step is to continue to update the chart after our first qualifier so that we can have a pictorial summary of our entire build season for reference.

    Ringevator Overview

    25 Feb 2021

    Ringevator Overview By Trey

    Task: Describe the construction and development of the Ringevator intake

    This year we have done a lot of work on intakes and launchers. The purpose of this post is to go over the function and overall design and build of the Ringevator intake. It doesn’t go too far in-depth so if you are looking for something more specific I would recommend that you look at specific posts discussing different parts of our design but if not you are in the right place.

    Build Breakdown:

    The construction of the Ringevator is moderately complex. It consists of a custom belt, two axels, a motor, a pivot, a base, and some elastics. The belt is custom modeled and printed in NinjaFlex. The design is based on the belt seen in one of our previous robots, Kraken, which competed in 2018. It has flaps that do the work of pulling in the rings and holes that are used by sprockets to drive the belt. The holes are the exact size and space apart to be fitted onto the sprockets on the drive axels which are attached to the base. The base is a simple H design that used to be in between the sprockets but now sits so that the sprockets are inside to make mounting easy. The axels are driven by one motor attached by a belt on the base of the robot.

    As you can see in the photo above, the belt assembly base and the robot base have a pivot between them. The purpose of this pivot is to make picking the rings much easier. Normally you would have to pick a ring up horizontally and then turn it to a vertical orientation which is what we need but instead, the pivot allows for the belt assembly to walk over rings. This means that when the intake reaches a ring, the movement of the belt causes the mechanism to open and consume the whole ring. Since only one side of the ring is being pulled up by the belt, it is flipped vertically and travels up the rest of the mechanism and out the top. The elastics make sure that the belt keeps in contact with the ring at all times. The only other thing that is apart of the design is a guide ramp on the inside made of heat-bended polycarbonate. You can see a photo of this ramp below along with the intake before it was attached to the robot on a pivot.

    Testing:

    We tested the Ringevator multiple times throughout its life to make sure that it will work. It gets a good grip on the rings and is able to pull them up most of the time. We still need to iron out a few tensioning issues with the elastics to make it more consistent but other than that it works well based on our tests so far which are few and far between. More testing will come.

    Improvements:

    The design didn’t start out this well though, we made several improvements since the start. For starters, the whole pivot idea was a mistake, to begin with; however, we discovered while doing preliminary tests that the belt walking over rings was a feature, not a defect. We realized that picking up rings without the pivot would be far more difficult and that was the spark for the design we have now. We also suffered some grip issues with the polycarbonate ramp which wanted to grip the rings too much and hindered the ability of the intake. We fixed this with some friction-reduced tape and now it works well. The design is still in its baby stages so we haven’t found a lot of problems but we will eventually and we are excited to address them.

    Next Steps:

    We are working right now on dialing in the shooter to make it more consistent and also testing a 1:1 motor to see how it compares to the 1:3 motor in terms of accuracy. We are also being posed with a challenge unlike any other challenge we have faced this season which is taking what we made when we were developing intakes and making a system that can feed into the shooter. This is going to prove a challenge because of the size of the shooter and the fact that it can be rotated or tilted to any angle. The challenge may be large but we are a worthy opponent.

    Making the Ringevator Legal

    05 Mar 2021

    Making the Ringevator Legal By Trey and Paul

    Task: Make the Ringevator legal so we can use it in competition

    We’re at the point now where we have a lot of our systems ready to be put on the robot, but we have to face another big challenge, which is making everything legal. Since the robot is a circle, we don’t exactly have any space to put an intake in the sizing cube. We can take advantage of the hypotenuse of the box by putting our equipment in the corners but then we raise the problem of height. This is because the Ringevator was never actually built to be permanently attached to the robot.

    We built the Ringevator as a prototype that harnessed the abilities of all of our previous models without their problems. However, with time closing in, it became apparent that the ringevator would have to be on the robot regardless of what we think. In order to do this, we had to shorten the assembly by about 2.5 inches and somehow pull the assembly inside more. With only a few builders being able to join us at any particular time, this proved to be a challenge.

    Two things needed to happen to make the robot even close to legal. The first was that the front would have to be chopped off, spitting the front Omni wheel assembly in two. And the second was actually shortening the ringevator which meant shortening the belt. The first part was easily accomplished by modeling two new Omni wheel bases for the front and surgically removing the front of the robot with a hacksaw. This was accomplished in the span of two days. After this was done, Paul also chopped the top of the ringevator off. The last piece was the belt.

    The problem with the belt was that I was the only one who knew how to shorten it and I was stuck at home for the next few days. So after Paul was done with the robot surgery, he swung by my house at 3 AM and dropped the belt off in my mailbox. The next morning, I marked off about 5 inches or 5 flaps of the intake, printed a new rig for the welding, cut, and welded the belt into a shorter configuration with my own tools. Then to get the belt back to the robot, we thought about getting a courier to deliver it but instead, I showed up the next day with the new belt and it was assembled onto the robot. After all of that, the robot was still not legal. The reason why it wasn’t legal is because we used bulky REV extrusions as sides since they are easy for prototyping. Since those rails are thick it just barely falls out of the sizing cube. So we had to detach the whole assembly for our next competition.

    Next Steps

    We would have liked to cut the assembly down more at this point but we couldn’t because we had already pushed the limits of its size. Our next step is to completely redesign the whole intake system. We knew this was going to have to happen at some point but we didn’t think it was going to be this soon. In order to make the intake legal, we have to CNC all of the parts. And I think that’s the kind of challenge Iron Reign is built for.

    UTD Qualifier Build Post Mortem

    06 Mar 2021

    UTD Qualifier Build Post Mortem By Trey

    Task: Review our failure of rushed build leading up to the UTD qualifier

    As discussed in the post "Making the Ringevator Legal" there was a lot of rushed build leading up to this qualifier. As a recap of that post, the Ringevator was too wide and too tall to be legal, so we had to cut off the front of the robot, split the omni wheels, shorten the assembly, and shorten the belt. For more information, read that post. So with all of this change leading up to the competition, one would expect that it all worked out.

    Alas, it did not. By the end of the raised build, the robot was still not legal by any means. In fact, the ringevator had to be removed so that we could actually run matches with a legal robot. This, however, is not the end. Even though the robot may not be legal, the judges still respected the development we displayed in our journal and portfolio. We demonstrated real development in innovative systems that I suppose resonated with the judges because we were awarded the Inspire award. Ordinarily, any team would see this as a big accomplishment but the builders at IronReign were restless. We failed our goals. The end objective with building a good robot is to score high amounts of points and that’s the one thing we didn’t do.

    At the very least we did learn quite a bit from the situation. Firstly, the troubles we had with the ring transfer from intake to outtake demonstrated that the pancake flipper was not a good idea. Such a path for ring transfer would be cool but a challenge too large for the coders. Besides, we already have put so much into the ringevator. Abandoning it now would be reckless. We also discovered that another pivot point at the bottom would be vital to the ring transfer. At the moment this is just a REV core hex motor but something more advanced would be helpful. There is also the added possibility of adding a slide to the bottom of the intake which paired with the current pivots, would make the intake far more versatile and clear of the spin of the turntable, which gets caught. There is still much thinking to be done in this department. Finally, the last thing we learned is that the ringevator would need to be remade in a fully custom, aluminum version to make it fit in the sizing cube. This will be a large feat but if we can do it, we will have points when our next qualifier rolls around.

    Next Steps

    We’re going to need to do a lot more before our robot scores real points. I admire our progress but we still have a long way to go. We need to step up on driver practice, reevaluate the ringevator, and start thinking about a final version of the robot. What comes immediately next is modeling and redesigning the ringevator to lose any bulk in the system so it can fit on the robot. I hope that those new developments will allow us to run matches next competition.

    Recruitment in Senior Season 2021

    06 Jul 2021

    Recruitment in Senior Season 2021 By Bhanaviya

    Task: Decide plans for expansion and recruitment strategies

    For the first time in 11 years, Iron Reign had a no-recruitment year, owing to the pandemic, and the difficulty of introducing new recruits to an event which is not usually remote. However, now that all of our members are upperclassmen and since this upcoming season - Freight Frenzy - will be the final one for most of our team members, we have to ramp it up (puntentional). So, this summer, we have been discussing new methods to increase recrtuitment and the following participation as our school year transitions from remote to in-person.

    For all of its lifetime, Iron Reign has been a school-sponsored program. This is a tradition we intend to keep and we've specifically been looking at recrtuitment efforts in our home school - School of Science and Engineering - as well as our sister school - School for the Talented & Gifted. Over the summer, TAG is having a club fair which we currently have plans to participate in. Following this, we plan to go the traditional recruitment route with posters galore. Mainly, we want to ensure that before our graduation, we are able to set up a proper feeder system to keep our program running past our (high school) life-time.

    One major difference is that this year, we plan to go with only one feeder team - FTC 3734 - rather than 3 feeders, which has been our practice in yearss where we are pressed for recruitment. This mostly has to do with how sustainable we can keep our group - fewer teams means we are less concerned about resources and instead can work to individually improve our two teams and expend energy on smaller elements of each time. This does mean, however, that we will be taking on fewer personnel and therefore, our "tryouts" process could be more competitive based on how much interest we've garnered. This process generally consists of putting new recruits into a smaller "group" (not necessarily a team) and looking at their ability to work one another and/or their willingness to learn new skills.

    Next Steps

    With school starting in a week, our primary goal is to get the robot in working condition for robot demo for the TAG club fair this week, and then build up an interest form that we will put on our website and display to school-based websites the underclassmen use. Based on how the form fares, we will make a more concrete decision on how many members we want to take and what kind of sub-skills we need for both the growth of this season and the next one. Our ultimate goal (puntentional part two) is to ensure that our team can be sustainable past our generation. As our time on the team and program ends, we want to ensure that we are adequately set-up to welcome and help acclimatize new members so FIRST Tech Challenge and our program is as fulfilling for them as it was for us.

    Wattever Meeting

    31 Jul 2021

    Wattever Meeting By Trey, Anisha, Bhanaviya, Shawn, Ben, Mahesh, and Cooper

    Task: Meet with the team Wattever and give insight

    This Saturday, all of Iron Reign met with team 16296, Wattever, to discuss how the Iron Reign robotics program works and give them a detailed insight into how they can improve their own operations. The members of Iron Reign gave them a quick tour of our space from the first floor to the second and then had a long conversation on the base floor shortly after. We answered questions and offered insight into how we operate. Our main advice consisted of making sure that every team member gets a chance to have a voice in the journal, to prioritize custom parts, improve operations in CAD, etc. We tried to help them in ways that might not have been available for an online meet, seizing the opportunity of meeting in person. We gave them insight into how our program works. That meant that they got to see what works and what doesn’t which gave us an opportunity to show good examples of Iron Reign’s ability to innovate and quickly prototype but also show them how we are a bad example of organization and time management. With this, they could imagine what the “perfect” FTC team looks like and better make decisions to become ever closer to it.

    Of course, any in-person meeting is a fantastic opportunity to bond and share common interests and this inevitably happened. The conversation in the main room of the workshop was as engaging as it was insightful. The teams talked together for what seemed like minutes but was in fact, several hours. From this meeting, Iron Reign certainly strengthened its relations with Wattever and had some fun, improving team morale and helping a relationship that contributes to team sustainability.

    Next Steps:

    With this being a pre-season event, there isn’t a straightforward next step. We would like to have another meeting with Wattever at some point and continue to grow our relationship with them. In addition, our summer projects need to continue so that we can be better prepared for the new season when it starts. Other than that, the watters ahead look clear!

    Club Fair 2021-2022

    05 Sep 2021

    Club Fair 2021-2022 By Bhanaviya

    Task: Welcome New Recruits!

    Thank you for your interest in Iron Reign robotics! Please fill out the following interest form. Check out the rest of this article for more on our robot!

    Future Plans For Programming

    11 Sep 2021

    Future Plans For Programming By Mahesh

    Task: Plan Out Changes To Codebase and Use New Libraries/Hardware

    This season, we plan to utilize the PAA5100JE Near Optical Flow Sensor (left image) and Realsense D435 Depth Camera (right image) to improve our robot's autonomous accuracy and reliability when running alongside other robots.

    The optical flow sensor's potentially higher accuracy over traditional odometry deadwheels and immunity to slippage can make autonomous routines more reproducible. However, it is not a device that comes with out of the box FTC support, so a custom java driver will need to be translated from the existing python driver to have it correctly interface with the i2c ports on the REV Control Hub. Additionally, the device uses the SPI protocol for communication, so code will need to be written to convert the SPI calls to i2c, which can then be converted back to SPI via a i2c to SPI bridge chip.

    As for the Depth Camera, a pipeline can be created to take its output, detect robots or other objects that the robot may collide with, and preemtively come to a stop during autonomous and possibly tele-op to avoid those collisions. This would save time spent communicating with an alliance partner prior to a match to determine where to place delays in an autonomous program to prevent collisions, since those delays would be performed automatically.

    Furthermore, the optical flow sensor outputs movement in both the x and y directions, so only one is required to get xy localization on a holonomic drive. If we wish to also use the sensors for heading information instead of/alongside the IMU, two can be mounted on opposite corners of the robot. But what good is localization for autonomous if not to be used with path following?

    We plan to experiment with the roadrunner motion profiling library for FTC robots, using as input the Pose provided by the optical flow sensors. It simplifies many of the common needs for path following, like providing OpModes for odometry tuning, path following for linear and even spline trajectories, as well as asynchronous methods which can easily integrate into our current asynchronous codebase. Since we are dipping our toes back into a mecanum chassis for robot in two days, roadrunner will be ideal to harness the full potential of a holonomic drive.

    Next Steps:

    The most important first step is to get the optical flow sensor working with the Control Hub, so that we can have an accurate localization system as the backbone for future path following during autonomous. In a separate track, different pipelines can be experimented with to get obstacle detection working using the realsense depth camera.

    A Prerequisite Chassis to Robot In 3 Days

    12 Sep 2021

    A Prerequisite Chassis to Robot In 3 Days By Trey, Cooper, and Aaron

    Task: Build a robot that can be adapted to any challenge

    The challenge reveal is going to be quite soon. In the weeks leading up to the challenge reveal we began to wonder if there was anything we could do that would make our transition from preseason to prototyping any better. And obviously, there are many things we could do that would make our work easier when the time comes to see the new challenge. Mainly, we were thinking that since we do a robot in three days when the challenge gets revealed, it would be beneficial to have a robot chassis that could be used in most challenges and be adapted to the specifics of this year’s challenge. A robot like this should be easily maneuverable and have an arm or subsystem capable of interacting with ordinary objects. That’s where the idea for this robot came from.

    N-bot is the solution to this problem. The idea for N-bot was that we should have a chassis that can drive over elements and manipulate them within the walls of the robot. In order to do this, we created a robot in the shape of a lower case n that can drive over objects. Ideally, the next step would be to give it an arm that can manipulate anything it can drive over; however, we did not have time to complete this. Instead, what we ended up with was a chassis in the shape of a lowercase n.

    For wheels on this robot, we decided that mecanum wheels would be the best choice since we would be able to move in all directions on the field with them and position ourselves accurately over objects. Those four wheels are chained to motors and paired together in wall-shaped blocks that are linked together on top by 4 structural extrusions. The overall shape of the robot appears to be sturdy; however, it is actually quite flimsy. Linking two halves of a robot with only 4 beams on top is not a great idea if you’re looking for a rock-solid design. Instead, our robot tends to flex and shake but that’s ok because those issues are manageable. We sacrificed the structural integrity of our robot for ease of adaptation to challenge specific tasks.

    Next Steps:

    The next steps for this project are clear: we wait for the challenge to be revealed and then we adapt N-bot to that challenge with any number of additional subsystems. We are planning on only using this robot for our robot in 3 days challenge and nothing else so none of the subsystems we produce will be used at any other point in the year.

    Code Cleanup

    12 Sep 2021

    Code Cleanup By Cooper and Mahesh

    Task: prepare code-wise for robot in three days

    To better prepare for “robot in three days” (ri3d for short), we decided to get ahead a bit and resuscitate the code base. After making sure everything was up to date, we set off on cleaning it up. Going through it, we simplified the movement pipeline, got rid of unused variables, and generally worked on formatting. After which came the big part of the day; getting rid of Ultimate Goal-specific code.

    This was tough for one main reason. The aforementioned movement pipeline is the same lower-level pipeline we’d been using for years, with some new code on top of it to act as a higher-level interface for movement. The purpose of which was a rather basic field-relative movement method. However even basic, it was extremely useful last year in Auto, and would make sense to keep. All well and good, but since the entire method was built on the old pipeline, it was designed for 2 wheel differential steer robots. Go all the way back to rover ruckus, and you can see even back then we were using 2 big wheels instead of mechanums.

    Therein lies the problem. The ri3d chassis that we had pre-built uses mechanums, and the 5-year-old mechanum code that was left in the codebase was certainly off. So, we decided to try and fix said code to see if the pipeline would be compatible. Surprisingly, after about an hour of head-scratching, not only were we able to get it to move in tele-op, but auton as well. This boils down to the fact that in essence, we’re still using the mechanums like normal wheels. But for ri3d, it was good enough.

    Next Steps:

    Integrate strafing into the pipeline such that the higher level move code can use it intelligently.

    Chassis Brainstorming

    02 Oct 2021

    Chassis Brainstorming By Trey, Cooper, and Shawn

    Task: Build a robot that can be adapted to any challenge

    The new challenge is upon us and with a new challenge comes new robot designs. This year we have found that we are going to need to focus on the chassis of our robot more than ever. This is because the barrier to the warehouse is an important obstacle that we want to be able to climb or get around in order to score. The drawings and notes depicted below are the unfiltered notes that I took shortly after the discussions we had about chassis designs.

    Next Steps:

    The next steps here are to pick one or two of these designs and run with them. We need to build some prototypes of these fast before the first scrimmage or competition. I think the ones we are most likely to prototype in the coming weeks are the Flipin' tank, the tricycle, and the Flippin' bot. We're excited to see where these designs take us.

    Flyset Workshop Vision Presentation

    02 Oct 2021

    Flyset Workshop Vision Presentation By Mahesh

    Task: Deliver a Presentation Over Developing Vision Pipelines At The Flyset Workshop

    This Saturday, we had the oppurtunity to present at the Flyset workshop, an event in which multiple teams could present a topic of their choosing, such as (but not limited to) build, design, and programming. For one of our two presentations, we decided to share our process for rapidly prototyping and testing OpenCV vision pipelines, taking a drag-and-drop visual pipeline in GRIP to a fully-fledged working android project that can be deployed to a control/expansion hub.

    To begin the presentation, we introduced the programs and dependencies we use for developing vision pipelines. These include GRIP (a graphical tool to easily visualize and test out different computer vision pipelines), FTC Dashboard (a project dependency that allows for remote debugging with image previews, on-the-fly variable editing, live telemetry, graphing, and a field overlay), and EasyOpenCV (a project dependency that simplifies using OpenCV for FTC and runs vision pipelines in a separate thread for maximum efficiency).

    Next, we laid the foundation for the HSV threshold step to come by introducing the audience to the HSV color space and its advantages that make it easier to tune for the purposes of sampling an orange cone or colored team marker. We then transitioned (not shown in slides) to the concept of an HSV threshold, which takes an rgb image and uses hue, saturation, and value ranges to let only certain pixels through the threshold, ultimately producing a binary image.

    The final requirement for understanding our color-based detection approach is that of contours in the context of computer vision. We explained the definition of contours (boundaries that enclosed shapes or forms in an image), and how they can be detected from thresholded images.

    The final constructed GRIP pipeline is shown above. It follows the steps:

    1. gaussian/box blur
    2. HSV threshold
    3. contour detection

    However, multiple contours/color blobs may be detected in the last step shown in the GRIP pipeline, so the largest contour must be selected by area. From this largest contour, moments can be used to find the (x, y) coordinate of the contour's centroid. Moments are defined as the weighted sums of pixel intensities (pixel values when converted to grayscale), weighted by their x and y positions to produce m_1_0 and m_0_1 respectively. These moments can then be divided by m_0_0 to produce the x,y coordinate of the centroid of the largest detected contour, the final desired result.

    Finally, the completed vision pipeline was exported to java and modified to be compatible with EasyOpenCV, as well as select the largest contour by area and compute its centroid.

    Next Steps:

    Possible next steps for other approaches of detecting FFUTSE cones include the shape-based approach and machine learning with tensorflow. The shape-based approach would use an adaptive threshold and contour detection to detect multiple contour, and can rely on the shape of the contour (tapered towards the top like a cone) to detect the location of the FFUTSE cone placed in the image.

    In order to construct a tensorflow model to detect FFUTSE cones, training data (images of FFUTSE cones placed in various different orientations, lightings, and backgrounds) will need to be collected and labelled with the (x, y) coordinate of the FFUTSE cone in each image. Then, a CNN (Convolutional Neural Network) can be constructed, trained, and exported as a .tflite file to be used in the FTC ecosystem.

    Deriving Inverse Kinematics For The Drivetrain

    08 Dec 2021

    Deriving Inverse Kinematics For The Drivetrain By Mahesh, Cooper, and Ben

    Task: Derive Inverse Kinematics For The Drivetrain

    Due to having an unconventential drivetrain consisting of two differental wheels and a third swerve wheel, it is crucial that we derive the inverse wheel kinematics early on. These inverse kinematics would convert a desired linear and angular velocity of the robot to individual wheel velocities and an angle for the back swerve wheel. Not only would these inverse kinematics be used during Tele-Op to control the robot through joystick movements, but it will be useful for getting the robot to travel at a desired forward velocity and turning rate for autonomous path following. Either way, deriving basic inverse kinematics for the drivetrain is a necessity prerequisite for most future programming endeavors.

    More concretely, the problem consists of the following:
    Given a desired linear velocity \(v\) and turning rate/angular velocity \(\omega\), compute the required wheel velocities \(v_l\), \(v_r\), and \(v_s\), as well as the required swerve wheel angle \(\theta\) to produce the given inputs. We will define \(v_l\) as the velocity of the left wheel, \(v_r\) as the velocity of the right wheel, and \(v_s\) as the velocity of the swerve wheel.

    To begin, we can consider the problem from the perspective of the robot turning with a given turning radius \(r\) with tangent velocity \(v\). From the equation \(v = \omega r\), we can conclude that \(r = \frac{v}{\omega}\). Notice that this means when \(\omega = 0\), the radius blows up to infinity. Intuitively, this makes sense, as traveling in a straight line (\(\omega = 0\)) is equivalent to turning with an infinite radius.

    The main equation used for inverse wheel kinematics is:

    \[\displaylines{\vec{v_b} = \vec{v_a} + \vec{\omega_a} \times \vec{r}}\]

    Where \(\vec{v_b}\) is the velocity at a point B, \(\vec{v_a}\) is the velocity vector at a point A, \(\vec{\omega_a}\) is the angular velocity vector at A, and \(\vec{r}\) is the distance vector pointing from A to B. The angular velocity vector will point out from the 2-D plane of the robot in the third, \(\hat{k}\), axis (provable using the right-hand rule).

    But why exactly does this equation work? What connection does the cross product have with deriving inverse kinematics? In the following section, the above equation will be proven. See section 1.1 to skip past the proof.

    To understand the equation, we start by considering a point A rotating around aother point B with turn radius vector \(\hat{r}\) and tangent velocity \(\vec{v}\).

    For an angle \(\theta\) around the x-axis, the position vector \(\vec{s}\) can be defined as the following:

    \[\displaylines{\vec{s} = r(\hat{i}\cos\theta + \hat{j}\sin\theta) }\]

    by splitting the radius vector into its components and recombining them.

    To arrive at a desired equation for \(\vec{v}\), we will have to differentiate \(\vec{r}\) with respect to time. By the chain rule:

    \[\displaylines{\vec{v} = \frac{d\vec{s}}{dt} = \frac{d\vec{s}}{d\theta} \cdot \frac{d\theta}{dt}}\]

    The appropriate equations for \(\frac{d\vec{s}}{d\theta}\) and \(\frac{d\theta}{dt}\) can then be multiplied to produce the desired \(\vec{v}\):

    \[\displaylines{\frac{d\vec{s}}{d\theta} = \frac{d}{d\theta} \vec{s} = \frac{d}{d\theta} r(\hat{i}\cos\theta + \hat{j}\sin\theta) = r(-\hat{i}sin\theta + \hat{j}cos\theta) \\ \frac{d\theta}{dt} = \omega \\ \vec{v} = \frac{d\vec{s}}{dt} = \frac{d\vec{s}}{d\theta} \cdot \frac{d\theta}{dt} = r(-\hat{i}sin\theta + \hat{j}cos\theta) \cdot \omega \mathbf{= \omega r(-\hat{i}sin\theta + \hat{j}cos\theta)} }\]

    Now that we have an equation for \(\vec{v}\) defined in terms of \(\omega\), \(r\), and \(\theta\), if we can derive the same formula using \(\vec{\omega} \times \vec{r}\), we will have proved that \(\vec{v} = \frac{d\vec{s}}{dt} = \vec{\omega} \times \vec{r}\)

    To begin, we will define the following \(\vec{\omega}\) and \(\vec{r}\):

    \[\displaylines{ \vec{\omega} = \omega \hat{k} = \begin{bmatrix}0 & 0 & \omega\end{bmatrix} \\ \vec{r} = r(\hat{i}cos\theta + \hat{j}sin\theta) = \hat{i}rcos\theta + \hat{j}rsin\theta = \begin{bmatrix}rcos\theta & rsin\theta & 0\end{bmatrix} }\]

    Then, by the definition of a cross product:

    \[\displaylines{ \vec{\omega} \times \vec{r} = \begin{vmatrix} \hat{i} & \hat{j} & \hat{k} \\ 0 & 0 & \omega \\ rcos\theta & rsin\theta & 0 \end{vmatrix} \\ = \hat{i}\begin{vmatrix} 0 & \omega \\ rsin\theta & 0\end{vmatrix} - \hat{j}\begin{vmatrix} 0 & \omega \\ rcos\theta & 0\end{vmatrix} + \hat{k}\begin{vmatrix} 0 & 0 \\ rcos\theta & rsin\theta\end{vmatrix} \\ = \hat{i}(-\omega rsin\theta) - \hat{j}(-\omega rcos\theta) + \hat{k}(0) \\ \mathbf{= \omega r(-\hat{i}sin\theta + \hat{j}cos\theta)}}\]

    Since the same resulting equation, \(\omega r(-\hat{i}sin\theta + \hat{j}cos\theta)\), is produced from evaluating the cross product of \(\vec{\omega}\) and \(\vec{r}\) and by evaluating \(\frac{d\vec{s}}{dt}\), we can conclude that \(\vec{v} = \vec{\omega} \times \vec{r}\)

    1.1

    Based on the constants defined and geometry defined in the image below:

    The equation can be applied to the left wheel to derive its inverse kinematics:

    \[\displaylines{\vec{v_l} = \vec{v} + \vec{\omega} \times \vec{r_l} \\ = \mathbf{v + \omega (r - \frac{l}{2})}}\]

    where \(r\) is the turn radius and \(l\) is the width of the robot's front axle. Applied to the right wheel, the equation yields:

    \[\displaylines{\vec{v_r} = \vec{v} + \vec{\omega} \times \vec{r_r} \\ = \mathbf{v + \omega (r + \frac{l}{2})}}\]

    Applied to the swerve wheel, the equation yields:

    \[\displaylines{\vec{v_s} = \vec{v} + \vec{\omega} \times \vec{r_s} \\ = \mathbf{v + \omega \sqrt{r^2 + s^2}}}\]

    where \(s\) is the length of the chassis (the distance between the front axle and swerve wheel).

    The angle of the swerve wheel can then be calculated like so using the geometry of the robot:

    \[\displaylines{\theta = \frac{\pi}{2} - tan^{-1}\left( \frac{s}{r} \right)}\]

    Mathematically/intuitively, the equations check out as well. When only rotating (\(v = 0\)), \(r = \frac{v}{\omega} = \frac{0}{\omega} = 0\), so:

    \[\displaylines{ v_l = v + \omega(r - \frac{l}{2}) = \omega \cdot -\frac{l}{2} \\ v_r = v + \omega(r + \frac{l}{2}) = \omega \cdot \frac{l}{2} \\ v_s = v + \omega\sqrt{r^2 + s^2} = \omega \cdot \sqrt{ s^2} = \omega \cdot s}\]

    In all three cases, \(v = \omega \cdot r\), where \(r\) is the distance from each wheel to the "center of the robot", defined as the midpoint of the front axle. Since rotating without translating will be around a center of rotation equal to the center of the robot, the previous definition for \(r\) can be used.

    As for the equation for \(\theta\), the angle of the swerve wheel, it checks out intuitively as well. When only translating (driving straight: \(\omega = 0\)), \(r = \frac{v}{\omega} = \frac{v}{0} = \infty\), so:

    \[\displaylines{ \theta = \frac{\pi}{2} - tan^{-1} \left( \frac{s}{r} \right) \\ = \frac{\pi}{2} - tan^{-1} \left( \frac{s}{\infty} \right) \\ = \frac{\pi}{2} - tan^{-1}(0) \\ = \frac{\pi}{2} - 0 \\ = \frac{\pi}{2} }\]

    As expected, when translating, \(\theta = 0\), as the swerve wheel must point straight for the robot to drive straight. When only rotating (\(v = 0\)), \(r = \frac{v}{\omega} = \frac{0}{\omega} = 0\), so:

    \[\displaylines{ \theta = \frac{\pi}{2} - tan^{-1} \left( \frac{s}{r} \right) \\ = \frac{\pi}{2} - tan^{-1} \left( \frac{s}{0} \right) \\ = \frac{\pi}{2} - tan^{-1}(\infty) \\ = \frac{\pi}{2} - \lim_{x \to +\infty} tan^{-1}(x) \\ = \frac{\pi}{2} - \frac{\pi}{2} \\ = 0}\]

    As expected, when only translating (driving straight), \(\theta = \frac{\pi}{2}\), or in other words, the swerve wheel is pointed directly forwards to drive the robot directly forwards. When only rotating, \(\theta = 0\), or in other words, the swerve wheel is pointed directly to the right to allow the robot to rotate counterclockwise.

    Next Steps:

    The next step is to use PID control to maintain target velocities and angles calculated using the derived inverse kinematic equations. Then, these equations can be used in future motion planning/path planning attempts to get the robot to follow a particular desired \(v\) and \( \omega\).

    A distance sensor will also need to be used to calculate \(s\), the distance between the front axle and swerve wheel of the robot.

    Deriving Maximum Chassis Length On Turns

    08 Dec 2021

    Deriving Maximum Chassis Length On Turns By Mahesh and Cooper

    Task: Derive The Maximum Chassis Length On Turns

    Having a chassis able to elongate and contract during play poses its advantages and drawbacks. If properly used, the chassis can serve to strategically defend portions of the field. However, if not shortened during turns, the extended length of the robot can lead the swerve wheel to lose traction and start skidding on fast turns. Therefore, it is crucial to derive a model for the maximum chassis length achievable on a turn of angular velocity \(\omega\) before skidding starts to occur.

    More concretely, the problem is the following: given an angular velocity \(\omega\) and other physical constants, what is the maximum distance \(s\) achievable between the front axle and swerve wheel before the centripetal force required to keep the robot in circular motion \(F_c\) exceeds the force of friction \(F_f\) between the wheels and the ground?

    To start, we can define the force of friction \(F_f\):

    \[\displaylines{F_f = \mu N = \mu mg}\]

    where \(\mu\) is the coefficient of friction betewen the wheels and the ground, \(m\) is the mass of the robot, and \(g\) is the acceleration due to gravity.

    Then, we can define the centripetal force required \(F_c\):

    \[\displaylines{F_c = ma_c = m\omega^2r_s}\]

    where \(a_c\) is the required centripetal acceleration, \(\omega\) is the angular velocity of the robot, and \(r_s\) is the distance from the swerve wheel to the center of rotation.

    Setting these two equations equal to eachother and solving for \(r\) will yield the final equation:

    \[\displaylines{F_f = F_c \\ \mu mg = m\omega^2r_s \\ \mu g = \omega^2r_s \\ r_s = \frac{\mu g}{\omega^2}}\]

    However, the \(s\) must be related to \(r_s\) to be used in the above equation. This can be done by substituting the expression \(\sqrt{r^2 + s^2}\) for \(r_s\), where \(r\) is the true turn radius, which will compute the distance from the swerve wheel to the instantaneous center of rotation. So,

    \[\displaylines{r_s = \frac{\mu g}{\omega^2} \\ \sqrt{r^2 + s^2} = \frac{\mu g}{\omega^2} \\ r^2 + s^2 = \left(\frac{\mu g}{\omega^2}\right)^2 \\ s^2 = \left(\frac{\mu g}{\omega^2}\right)^2 - r^2 \\ s = \sqrt{\left(\frac{\mu g}{\omega^2}\right)^2 - r^2}}\]

    As seen in the above screenshot of the following desmos calculator, the slower the robot rotates, and the closer \(w\), or in this case \(x\), is to 0, the higher the maximum chassis length \(s\), or in this case \(y\), is. Intuitively, this checks out, since when at a standstill, the robot can be as long as possible with no side effects. When rotating slowly, the robot needs to be slightly shorter to maintain traction, and when rotating fast, the robot needs to be very short to maintain traction, as reflected in the downward slope of the graph.

    Next Steps:

    The next step is to use PID control with input as the measured chassis length as given by the distance sensor and target being the output of the derived equation for \(s\) to maintain the robot's length to keep traction. Additionally, the coefficient of friction \(\mu\) between the wheels and ground will need to be tuned to the drivers' liking.

    Meeting Log 3/12

    12 Mar 2022

    Meeting Log 3/12 By Trey and Leo

    Task: Decreasing the Movement of Linear Slides During Expansions

    The continuous expansion and contraction of the robot placed a lot of stress on the mounting gear attaching the slides directly to the chassis. With each expansion the slides stretch out, and under their own weight, they would flex downwards. During regionals, the slides were subjected to these forces all day, and by the end our sliding components, “carriages”, were pretty damaged. The internals were unevenly worn and the ball bearings just fell out on the field; If left unattended, the carriages would eventually detach from the slides and the robot would literally break in two.

    To fix this, Trey came up with a double-carriage approach, aimed at reinforcing the mounts attached directly to the front of the robot. He machined an aluminum plate on the CNC, and then combined two different carriages to create a single sliding component. This effectively doubled the “strength” of the mounts by shifting the pivot point of the slides further in, and adding more resistance to the gravitational torque acting on the bar. Overall, the slides weren’t as steep and so carriages were much smoother during extensions.

    Next Steps

    We noticed that the slides did sag a little, however we need some compliance to allow for twisting caused by sharp crane movements and turns.We also noticed that the slide attached to the swerve module did flex so we might need to address that. Testing was limited however so we’d like to get some driver practice in and see how well the upgrades perform on the field.

    Iron Reign and the Three Magnets

    14 Mar 2022

    Iron Reign and the Three Magnets By Bhanaviya and Georgia

    Task: Evaluating what magnet type works best with the FFUTSE and bucket attraction

    FFUTSES with magnets mounted

    Iron Reign has its final event of the season, the UIL championship, in just one month! One driver task we've been needing to complete has been picking up and depositing a Freight Frenzy Universal Team Shipping Element (FFUTSE). To read about the FFUTSE and Iron Reign's open-source design, please refer to our FFUTSE repository. To overcome this part of the game challenge, we have decided to attach magnets on the underside of our bucket-intake and to the top of our cone-shaped FFUTSEs. The idea is that when the bucket roves over a FFUTSE, its magnet will be strong enough to attract the one atop the shipping element. However, the magnetic attraction must not be too strong, otherwise the bucket will not be able to drop off the FFUTSE on the shared shipping hub if the magnet is still affixed to the robot.

    In order to determine which kind of magnet could best meet these two criterion, we experimented with niodimium and ceramic magnets. Of the niodium magnets, there are 3 differently-sized ones - a large, medium, and small, with their sizes corresponding to the degree of magnetic attraction from greatest to least respectively.

    To reinforce the shipping element's attraction to the bucket, we have also created an array of corresponding magnets inside the bucket rather than simply affixing one magnet, since that way, the vertical thrust of the crane when is lifted upwards will not disrupt the attraction of the FFUTSE to the intake.

    It was clear that the ceramic and smallest niodimium magnets were too weak - even with an array of magnets in the bucket, they required too much precision on the driver's part in order to swiftly attract a FFUTSE and part of our idea is to minimize the driver effort and error that can come into play with this FFUTSE pickup process. Between the large and medium-sized niodimium magnets, though the large could attract a magnet faster, it did its job too well since dropping off the FFUTSE was not a task it could accomplish since the attraction of the magnets was too strong

    Next Steps

    In the end, our decision was influenced by Goldilockian principles - not too large, not too small but just right. The bucket does a reliable job of picking up and transfering FFUTSEs but as of now, this component has not yet been programmed. Once programmed, there is a chance we may have to either use a stronger magnet or find amiddle ground between the largest magnet and medium-sized one in order to minimize driver accuracy while maximizing efficiency.

    Hybrid Swerve Drive Progression

    19 Mar 2022

    Hybrid Swerve Drive Progression By Georgia, Shawn, Trey, and Bhanaviya

    Task: Fix issues found by Drive Practice in the robot

    Iron Reign has seen several dIfferent iterations of our swerve module this past season. In this post we’ve identified the different versions of our modules so we can isolate the failures and successes of each modification from sketch, to a CAD model to the constructed, manufactured iteration.

    To accommodate for our expanding chassis design this year, we’ve had to create a hybrid-differential swerve drive which means the combination of two differential wheels and swerve wheels and how they work together to achieve 2 degrees of freedom.

    Our first version of the swerve drive had a thrust bearing the same size as the ring gear. Unfortunately, this iteration was too small to cross over the barrier.

    The second iteration had a larger compliant wheel to cross over the barrier. Alas, the swerve drive created a high center of gravity for the robot, causing the robot to tip over.

    The third version had custom-machined aluminum plates for further weight reduction.The Hex Motor was moved inside and above the wheel hub to reduce the center of gravity. Sadly, the wheel was not malleable enough to pass over the barrier without dropping the freight.

    The fourth iteration is a rover-inspired swerve module made of six custom CNC carbon-fiber plates and ten custom 3D printed components. The wheel is made of NinjaFlex and has gothic arch-style to support a large vertical force. The wheel hub is made of nylon and has been holed to reduce weight. The walls of the holes have added infill to increase the strength of the wheel. This version has a lower center of gravity and a lighter wheel module.

    Next Steps

    We will contact the original designers of the rover-inspired swerve module, an Australian college rover team.

    Meeting Log 3/19

    19 Mar 2022

    Meeting Log 3/19 By Anuhya, Georgia, Aarav, Bhanaviya, Mahesh, Trey, and Gabriel

    Task: Get more drive practice before the UIL Championship

    This weekend, we focused on on-boarding new recruits as well as getting more drive practice to get us ready for the UIL competition next month.

    New Recruits Learnt to Create Blog Posts

    Bhanaviya taught us how to make blog posts on different topics, and also showed us the most efficient ways to bug the experienced members to get the information we needed.

    Drive Practice (we really need it)

    Gabriel got in practice going straight and using the extension function to minimize the amount of turning. Different angles of blocks were tested to see how the gripper would pick them up. An average of 3 pieces of freight per round was achieved.

    Build Improvements

    To help prevent the turret from drifting, we were looking at two options: implementing a tensioner to one of the belts to prevent skipping or adding an IMU to help the turret know where it is. We also added a potentiometer to be able to reliably be able to tell the shoulder position. There was a lot of shaft left, so Trey used a dremel to cut down the shaft so he could add the potentiometer.

    Code Changes

    There was an issue with an intake. The intake was running at a very high speed so it would spit the freight back out, for lack of a better phrase. A distance sensor was added to slow down the gripper when a shipping element is located nearby. Finally, he worked on fine tuning the crane so the transfer is seamless, and he is currently working on balancing the crane so it doesn’t bump into the shipping hub.

    Next Steps

    We have to test our robot without outriggers to see if the robot starts to tip over. (NB - We tested it out, it didn’t work. Let’s see what happens at the next meeting.) We also have to fine tune autonomous, so we can have a reliable auton which regularly works. We also have to work on driver optimization using present positions, so it’s easier on our drivers to control. Automating the intake cycle is also on our todo list.

    Repairing ‘Reach’

    19 Mar 2022

    Repairing ‘Reach’ By Gabriel

    Task: Fix issues found by Drive Practice in the robot

    To better prepare for UIL, we have started using Driver Practice to find issues that would’ve impacted the robot performance at the competition. Within the first 15 minutes of driving the robot, the servo that sustains the crane experienced thermal overload and could no longer hold up the axel by which the crane was able to move vertically.

    This required the deconstruction of the component to be able to access and replace the Steel Servo that had issue with the weight of the crane. This led to further experimentation with different aspects of the crane, such as the servo horn to test whether the axel would fully insert into the horn and reworking the distance sensor on the bucket so that it would function properly and automatically drop any held element onto the top of the shipping hub, though dropping elements into the shared shipping hub still needs some improvement. Unfortunately, even after changing out the Servo, the weight of the crane would still cause thermal overload, leading us to determine that it was unable to be fully fixed without reworking the crane in its entirety.

    Next Steps

    Continue with Drive Practice and rigorous testing of the robot attachments to see what needs improvement or complete reworking before UIL

    Solving Tipping Issues in The Reach

    19 Mar 2022

    Solving Tipping Issues in The Reach By Aarav, Shawn, Mahesh, and Bhanaviya

    Task-Identify and solve the problems that led to The Reach tipping over mid-match.

    Our robot, The Reach, utilizes a hybrid-differential swerve drive along with an extending design in order to effectively cross the barriers and score freight. Although this design is unique and avoids the congested areas of the playing field, it comes with trade-offs and flaws.

    At our first qualifier, we noticed one major flaw in the design of The Reach. The robot would often tip over during game play, rendering it unable to move and score points. Observing our matches and looking over our design, we attributed this problem to a couple of key components of our design.

    First off, due to limitations on the dimensions of the robot at the beginning of matches, the robot had quite a narrow base for its extended length of around 5 feet. This led to the robot being susceptible to tipping when in motion when combined with a variable center of mass.

    Furthermore, the jerky and sudden acceleration of the robot when traversing the playing field and extending caused the robot to fall over due to the sudden movement.

    Finally, our robot has an unusually high center of mass due to the design of its drive train and wheel modules. The motors that powered the wheels were housed above the actual wheel in the module, which led to a high center of mass. This issue was exacerbated by the extending crane arm we used for scoring freight, which led to a variable center of mass.

    Overall, we mainly attributed this failure to our robot's high and variable center of mass, which changed rapidly due to the robot's expansion and contraction. These factors combined with the narrow base were the key factors leading to the robot tipping.

    Looking at these diagrams of the robot and its center of mass, we can see how as the crane extends past the base of the robot, the center of mass moves towards the base. Eventually, the center of mass reaches a position outside of the base and the robot falls over. To solve this problem, we would have to either lower the center of mass or limit its fluctuation during movement.

    You can see from these free-body diagrams that as we lower the vertical component of the normal force, the overall rotational torque exerted by the swerve module is decreased, which inspired our decisions to lower the center of mass.

    We did this by redesigning our wheel modules and moving the motor further down. Our redesigned wheel modules utilize custom printed "barrier beaters" instead of the rock climbers we used before. These wheels were printed out of ninja flex and nylon and utilized a Gothic Arch design inspired by Monash University's rover wheels. The custom wheel modules used custom carbon-fiber plates and holes in the nylon hub to help reduce weight. Overall, these wheels were excellent at traversing the barriers, weighed less, and the wheel module allowed the motor to drop 5 inches in height. This led to a lower center of mass for the robot.

    However, in the situation that the crane and robot extension did lead to the center of mass nearing the base, we installed an outrigger system as a preventative measure. An outrigger is essentially a beam that extends from a robot that is used to improve stability. Our outriggers used omni wheels and functioned similarly to training wheels, preventing the robot from tipping over when the crane moves out and extends.

    Finally, we implemented some code changes to help deal with this problem, building anti-tipping limiters which allowed for gradual acceleration. This prevented the sudden acceleration mentioned earlier which was a cause of our tipping issue. We also programmed in pre-set arm locations to help keep the center of mass near the wheelbase, making sure that the center of mass never passes the base of the actual robot.

    Next Steps

    Building a unique and innovative robot like The Reach comes with a unique set of challenges and obstacles, and we will keep iterating our swerve module by experimenting with different wheel designs and weight-reduction patterns to reduce odds of tipping.

    Meeting Log 3/26

    26 Mar 2022

    Meeting Log 3/26 By Anuhya, Georgia, Bhanaviya, Leo, Gabriel, Aarav, Ben, Shawn, and Mahesh

    Task: Work on teamwork with drive practice for the UIL Championship

    This weekend, we worked on giving the new recruits a basic understanding of HTML so they could operate the blog when we were no longer here to help them. We also worked on communication in drive practice, because we have two drivers and two controllers.

    Gabriel and Georgia got in some drive practice

    They got in more practice working together driving, and figuring out how they wanted to split up the responsibilities. We have a robot which works better with two drivers controlling two separate controllers, but this means we have to spend extra time planning out our strategies and deciding how the controls will work for each individual driver.

    The new recruits are learning how to use HTML

    Bhanaviya and Shawn taught us how to use HTML to upload blog posts to the blog. We wrote our first blog posts a couple weeks ago, and today we learned how to upload them to the blog and possibly run damage control if we accidentally break something in the blog.

    Code Changes

    Mahesh worked on updating the code for picking up blocks. Now, whenever the robot is trying to pick up a block and drops it midway, instead of going through the whole motion of putting it in the bucket, it goes back down. This will help our robot become more efficient, as it will have more time to pick up blocks when it’s not wasting time.

    Making an Innovate Poster

    Bhanaviya and Shawn worked on making an Innovate poster which detailed our game strategy and the build for our robot. This is the main award for the UIL Championship.

    Next Steps

    First things first, we need to fine-tune the autonomous for our robot. We are planning to get more drive practice with an autonomous system so we’ll know how to time things properly. We also want to get in more drive practice in general, so we'll have better control over our robot overall and will be able to control the arm better.

    Meeting Log 3/29

    29 Mar 2022

    Meeting Log 3/29 By Anuhya, Georgia, Trey, Gabriel, Ben, Cooper, and Paul

    Task: Getting in some serious drive practice at Woodrow

    We took some time out of our week to get in some drive practice at Woodrow so we would be able to practice working together with another team and collaborating with a make-shift alliance.

    Drive Practice at Woodrow

    Practice matches run: 16 The main purpose of our drive practice at Woodrow was getting drive practice with another team, the Mechanicats. This would be one of our only opportunities before UIL to practice with another team and play in a full practice field with another team working as an alliance. One of the challenges we faced today was with our drivers learning how to work together. There were many kinks with having two people drive, including having two separate controllers with their own unique functionalities. One controller deals with the intake inside the warehouse while the other deals directly with the alliance shipping hub and the arm. Learning how to collaborate while using both was a difficult obstacle to overcome, especially because we didn’t have as much drive practice overall as we would have liked. Another major challenge we faced was getting the team shipping hub to not tip over. Our arm would extend too low and it would tip over the team shipping hub if we weren’t careful. Right now, we are working on maneuvering so it doesn’t tip it over, or only slightly nudges it. We also started working on our duck game, because we realized we didn’t have our duck spinner as efficient as we would have liked. The band which held the duck spinner back from deploying early snapped when we were setting it up, so we had to make do while practicing.

    Next Steps

    We are planning on getting even more drive practice as the days progress and we’re getting closer to UIL. We also need to work on not tipping over the alliance shipping hub, because that is a major penalty and it also makes it nearly impossible to get any points afterwards. We also need to figure out how to “double duck” with our current duck spinner, meaning we have to spin the duck off the duck spinner and then deposit them in the alliance shipping hub. Trey is currently working on redesigning the duck spinner so it has a wider range of compliance. This is so we can maintain our goal of “double duck”, which needs a larger range of motion and a robot which can reach further. We also need to keep working on strategy, so we can finalize what we’re running with at UIL and have time to practice it.

    Meeting Log 4/01

    01 Apr 2022

    Meeting Log 4/01 By Vance, Georgia, Trey, Gabriel, Bhanaviya, Leo, and Mahesh

    Task: Replace Crane Servo with a Motor

    After six broken servos amounting to around 240 dollars worth of funding, it became apparent that the current model of servo we were using wasn't up to the task that it needed to fulfill.

    First came the issue of figuring out how to mount the motor. An HdHex Motor was decided upon as it was able to support additions to increase the gear ratio, while a CoreHex motor had around the same power as the servos previously used. We were able to use a 90 degree mount in order to attach the motor as to not allow it to jut out of the robot, which would break the proper sizing restrictions. After assembly, it was found to solve most issues found with the servos, though did introduce the issue of leaning due to the unequal weight distribution. So far, it has had a better performance than the servos did

    Next Steps

    Figuring out how to mount on a counterweight to offset the weight of the motor so both the crane and the robot no longer lean off to one side

    Think Gripper Progression

    01 Apr 2022

    Think Gripper Progression By Vance

    Gripper Progression

    V1

    Our first gripper design was for robot in 2 days and with the time crunch came some downsides: little power and poor reach. Our second design intended to fix these downsides.

    V2

    Our second gripper design was made just before a scrimmage. While it fixed all V1's downsides it was bulky and heavy.

    V3

    Our third gripper design was used during our first qualifier. While it was significantly lighter than V2 and had much more reach, its gripper power was still too low.

    V4

    Our fourth gripper design was used for regional and it used a new beater bar on a continuous servo to pull blocks into the intake. The beater bar/spinner was controled by a distance sensor which could detech if a block was in the intake. It was held together using a carbon fiber-nylon sandwich (with aluminum shavings) system. It had 6 CNC carbon fiber plate and had 9 Nylon 3D printed parts.

    CONNECTions through the season

    02 Apr 2022

    CONNECTions through the season By Anuhya, Bhanaviya, Shawn, and Ben

    Task: Getting in some serious drive practice at Woodrow

    This past year, we connected with a lot of professional engineers that helped us optimize our robot performance and capabilities. We got a lot of helpful advice from professionals in our field as well as opportunities to learn more about the field itself. This way we have some insight as to what we will be able to do in the future, when we’re no longer in FTC.

    Dallas Personal Robotics Groups

    21 adult mentors, 4 hours total
    In the first zoom session, on December 6, 2021, we identified the gap in time between when the swerve wheel changes direction and spins. This was also the first live demonstration of the robot as well as the expanding mode, or the “reach”. In the second zoom season on February 8, 2022, we discussed solving the tipping over problem through the usage of counter-balances, training wheels and limiting wheel acceleration.

    Texas Instruments

    1 test engineer mentor, 1 hour total
    On November 24, 2021, we showed the first drive of our hybrid differential-swerve robot and we discussed tensile tests to improve our robot’s durability.

    NVIDIA

    1 adult mentor, 1 hour total
    NVIDIA is a computer systems design services company. On January 17, 2022, we discussed image processing, radar and object detention to improve the distance sensor feature on our gripper with them. The distance sensor feature auto-dumps the bucket.

    Monash Nova Rover

    2 adult mentors, 1.5 hours total
    Monash Nova Rover is a college robotics program based in Monash University, Australia. On January 31, 2022, we discussed unpressurised wheel/tire designs. Their wheel design inspired our current gothic interleaved arch design which is made entirely out of custom 3D-printed parts.

    US Congressional Representative

    32nd District TX Rep. Colin Allred
    On January 27, 2022, we discussed FTC and Iron Reign’s work in STEP education and we urged for the passage of a bill which improves access to STEM programs in rural education districts. This bill was passed this year and Iron Reign was attributed as one of the reasons Representative Allred voted to pass.

    Bell Helicopter, Lockheed Martin, Design Connect Create

    4 adult mentors, 3 hours total
    On July 31, 2022, we worked with engineers from these companies and delivered a joint presentation about avenues to STEM careers through school to 40 high school girls.

    Deloitte

    2 adult mentors, 0.5 hours total
    On February 23, 2022, we discussed our game strategy and sustainability plan for the current season. This was also the first time our rookie members communicated directly with engineers through our program.

    Meeting Log 4/2

    02 Apr 2022

    Meeting Log 4/2 By Anuhya, Georgia, Aarav, Bhanaviya, Mahesh, Trey, Gabriel, Ben, Anisha, Vance, and Shawn

    Task: Solve minor issues with the robot’s design and code. More drive practice in preparation for the UIL Championship next week.

    With only one week left until the UIL FTC State Championship in Houston, we doubled down on our efforts to fix a few small problems that remained in The Reach, as well as prepare for the State Tournament. Specifically, we had to finish constructing a new duck spinner that could extend farther out, and fix minor difficulties in the code of the robot that was messing up the positions of the crane during gameplay.

    Designing and Constructing a New Duck Spinner

    There were a couple of key issues with the old duck spinner that led to the development of an improved version, which Trey designed and constructed. The old duck spinner was too short to reach the duck carousel when the gripper was lowered and in an intake position and the drivetrain for the duck spinner motor was not very good. Trey designed and 3-D printed a new motor mount that allowed the spinner to be directly driven by the motor. To address the length issue, the entire mount was attached to a carbon fiber rod. This new system allows the hot swappable duck spinner to extend further out and work in tandem with the beater. We managed to mount the duck spinner by the end of our meeting.

    Remember to use safety glasses kids!

    Fixing Minor Build Issues

    There were a couple of structural and wiring issues with our robot that needed to be sorted out in order for the robot to function properly. On the bucket, the distance sensor that allowed an automated transfer system and automated drop off was re-wired to ensure that it didn’t unplug during the robot’s motion. This allowed for the proper transfer of freight from the beater to the bucket. Then, the servo for the second gripper beater was properly wired to make sure that the gripper could intake freight into the gripper properly. Finally, the magnets used to score our team shipping element were reattached so that we could lift FFUTSE’s and placed them on the alliance shipping hub.

    Code Modifications

    We recently added a new shoulder servo for the crane, and we worked today to help integrate it into the code and fine-tune it. We also dealt with an issue with the code that caused the crane to turn only to the right during freight drop-off.

    UIL Posters and Documentation

    Bhanaviya, Anisha, and Shawn worked on documentation posters for the UIL State Championship to submit for the awards at State. Bhanaviya worked on the engineering and design posters that highlighted how we developed and designed our robot. Shawn completed the innovate poster, which showed how we thought outside the box and created an innovative design. Anisha worked on the connect and motivate posters which displayed how we connected with industry professionals to improve our robot and how we spread robotics and opportunity to our community. Shawn also worked on designing our pit layout for UIL.

    Next Steps

    More drive practice. Don’t destroy the robot in the one week before State. Try and not have to pull an all-nighter the night before competition. Continual maintenance and upkeep of the robot would be useful to make sure the robot still works in a week. Documentation will also have to be finished and finalized in the coming week in preparation for UIL.

    Last Practice Before UIL!

    07 Apr 2022

    Last Practice Before UIL! By Anuhya, Georgia, Bhanaviya, Ben, Mahesh, Gabriel, Aarav, Trey, Shawn, and Leo

    Our Last Meeting Before UIL!

    This marks our final competition of the Freight Frenzy season.

    Getting in our final drive practice

    Trey, Georgia, Ben and Gabriel got in their last couple hours of drive practice at the RoboDojo. Knowing this was our last time we would be able to practice in our home field, we made sure that we knew exactly what we would be doing at UIL. Mahesh was cleaning up the code, tuning up the arm and getting it so that when you press dump, it goes up and then goes down so it doesn’t run into the shipping hub.

    Yesterday's meeting

    Yesterday, Trey and Georgia got a lot of drive practice. They tested the robot with the sizing cube to make sure that it fits within the regulations. Trey also installed a grasp rivet on the bucket which allows the distance sensor wire to go through the pivot point so it doesn’t tangle and so the bucket’s auto dump works. The bucket’s auto dump wasn’t working because the distance sensor’s wire couldn’t be plugged in without getting tangled. The grasp rivet helped the wire go through the pivot point without it breaking, so we could use the distance sensor seamlessly.

    Packing for UIL

    We had to pack up all the necessities for the UIL trip. We worked on ensuring that we were fully prepared for success at the UIL competition and we tried to foresee any unexpected circumstances and prepare for them. We were fully ready to stock up the bus tomorrow morning before heading for Houston.

    Iron Reign’s Mechavator - Safety Features and Protocols

    09 Jul 2022

    Iron Reign’s Mechavator - Safety Features and Protocols By Gabriel and Trey

    Let's not do this!

    Intrinsic Hazards and Safeties
    Primary Safety
    Backup Safety
    Site Safety
    Operational Safety

    Intrinsic Hazards and Safeties

    Intrinsic Hazards

    It’s important to keep in mind that with a 3 to 4 ton class mini excavator we are dealing with forces that can crush and pull down trees, destroy structures and potentially end lives. There is no place for any lack of vigilance and caution for safely operating this machine.

    Intrinsic Safety

    The machine has two emergency stop controls and we employ them redundantly in fail-safe modes. The only intrinsic safety lies in the reliable slow motion of the machine. The engine will only be run at idle speed. Its normal ground travel speed is equivalent to a slow walk and it cannot move faster than an able bodied person can run. There are still cautions around this. Swinging the arm when extended can cover a lot of ground quickly. People need to maintain safe distances. Therefore, we have established Operational Safety and Site Safety protocols.

    Primary Safety

    The Primary Safety functions as a lock-out of the hydraulic pump. When the safety is engaged, no part of the excavator will move with the possible exception of a very slow sag of heavy components to the ground. For example, the bucket and arm may sag by a few millimeters per second if they were left off the ground.

    The Primary Safety is constantly engaged by a rugged bungie. To disengage the safety (UnSafed – therefore hydraulics activated) a servo can actively hold the safety lever down.

    Fail Safes

    • The servo is configured as a deadman switch – the operator needs to continuously hold down a button on the primary remote control for the servo to remain in the Safety-Disengaged position.
    • If the servo or control system loses power or browns out, the bungie will pull the safety back into the engaged position.
    • If the control system stops receiving active disengage commands from the remote, the safety will re-engage. This covers out-of-range conditions.
    • We specifically chose a digital servo that does NOT have a memory of the last good position signal. Some digital servos will continue to hold the last good position they received if they continue to receive power. The servo we chose does not have this feature, so if the PWM position signal fails for any reason, but power remains on, the servo will fail to hold position and the safety will re-engage.
    • If the control system app crashes, the safety re-engages
    • All of the above have been tested
    • We can’t say it’s impossible for the control software stack to crash in a state where it continues to send a safety-disengage PWM position signal. We’ve never seen it happen and we believe it’s prevented by the interaction of the firmware and the app – but we can’t say it’s impossible. It’s also possible to imagine a freak condition where the servo gearbox breaks and locks up in the safety-disengaged position. So we decided to create a redundant backup safety.

      Backup Safety

      The Backup Safety uses similar fail-safe design principles as the Primary, but it is completely independent of the normal control system.

        The Backup Safety is operated through an independent standard RC (digital radio control) transmitter and receiver.
      • The Backup Safety kills the engine when it is Safety-Engaged.
      • The Backup Safety is also normally pulled into its Safety-Engaged position by a tensioning system.
      • To suppress/disengage the Backup Safety, a servo can hold the kill switch in the down position.
      • The servo is configured as a deadman switch – the operator (a different operator than the Primary Safety operator) needs to continuously squeeze the throttle on the RC transmitter for the servo to remain in the Safety-Disengaged position. The throttle is spring loaded to return to Safety-Engaged.
      • If the servo or loses power or browns out, the bungie will pull the safety back into the engaged position.
      • If the RC receiver stops receiving active disengage commands from the transmitter, the safety will re-engage. This covers out-of-range conditions. It also applies when the transmitter is turned off.
      • We specifically chose a digital servo that does NOT have a memory of the last good position signal. Some digital servos will continue to hold the last position they received if they continue to receive power. The servo we chose does not have this feature, so if the PWM position signal fails for any reason, but power remains on, the servo will fail to hold position and the safety will re-engage.
      • All of the above have been tested

      Site Safety

      Site safety speaks to conditions of the site and surrounding properties that informs the risk to people and property.

      The site is the backyard 3 acres of our coach’s residence and the primary structure on the site is the home itself (blue oval, below). The site slopes downhill fairly steeply from the back of the house to the creek that cuts all the way across the property at the bottom (right side in the image). The site is heavily forested with the exception of an open glade, a clearing for a future workshop, and a gravel driveway connecting them uphill to the main driveway for the residence.

      With the exception of the driveway, the open areas are surrounded by impassable forest (yellow line in the overhead shot below). By impassible we mean that the excavator would stall on trees and undergrowth within 10 feet if it tried to push through the surrounding brush without skillfully employing the arm and bucket to uproot the vegetation. In addition to the forest/undergrowth, all of the neighbor’s properties are further isolated by being either significantly upslope or on the other side of the creek. The creek has cut an impassable 20 foot sudden drop across the property’s southern border, effectively creating a moat that would protect the only neighbor property that is downslope. Right now there is no path to the creek that the Mechavator could take.

      The future workshop site (white oval) is the only area that the Mechavator will be allowed to operate in. The ground there is mostly loose soil but does have rocks, mounds and branches that should be treated as trip hazards. Team members need to be aware of the terrain at all times. We will refer to this area as the arena.

      Operational Safety

      Operational Safety consists of the training and protocols that will be followed to assure minimal risk to the participants.

      • Mechavator will only be operated in the arena.
      • Our coach will always be present and supervising operations. The machine may not be started without an OK by coach.
      • There will be a minimum of two operators, a driver and a safety operator. The primary driver will operate either the arm or the chassis as well as the primary safety. The safety operator will operate the backup safety and is primarily responsible for nothing but safe operations of the vehicle.
      • A secondary driver is required if the plan calls for operating the chassis and the arm at the same time.
      • Every session will begin with a meeting to discuss all planned movements to be sure that everyone in the area knows what to expect as well as what could go wrong and to address specific safety concerns.

      Designing the New Workshop

      30 Jul 2022

      Designing the New Workshop By Aarav and Anuhya

      Task: Design a floorplan and model for the new workshop

      With the limits of our current workspace reached and the need to expand with more recruits and machinery; Iron Reign set off on a new summer project. The objective: design a new workspace for Iron Reign to be constructed further into the property. This new workshop would help Iron Reign improve our fabrication and machining capabilities and expand our program. It also served as a productive way to spend our summer and improve our CAD skills.

      A few major constraints and requirements had to be fulfilled by the new workshop, mainly increased capacity for teams and equipment. 2 full-size playing fields were needed to accommodate both Iron Reign and its growing sister teams, and more space for machines, tools, and storage to help delay the workshop's inevitable descent into chaos would be ideal. Finally, we also decided to include brainstorming areas, basic amenities, and a garage for vehicles.

      With our concepts and ideas somewhat straightened out, we began developing a floor plan that fits in the cleared-out patch of land on the property. After a few days of work and revision, we had a basic floorplan complected with dimensions. Below is our preliminary floorplan, which included all of the requisite areas.

      After that, we decided to take the design to the next level by turning our 2D design into a 3D model, using Fusion 360. Here we had to add components like doors, windows, hallways, walls, and roofs to our design. This helped better prepare it for construction and allowed us a chance to include model furniture to help verify our dimensions and make sure we have enough space. After a couple of weeks, we had a preliminary 3-D model. It is still not finished, and we are continuing to iron out any issues and add more components.

      Next Steps

      After finishing the 3-D model, the next step would be to think about construction and start contacting contractors to help sort out any potential issues, along with potentially finding ways to fund this project.

      Dallas City of Learning at Frontiers of Flight

      06 Aug 2022

      Dallas City of Learning at Frontiers of Flight By Aarav, Anuhya, Gabriel, Trey, Vance, Leo, and Georgia

      Task: Connecting with the communoity through the Frontiers of Flight

      This morning, Iron Reign demoed at the Dallas City Learning event at the Frontiers of Flight Museum, which had over 550 attendees. This fair featured STEAM activities from local organizations and the museum, along with local industry professionals.

      At this event, we demonstrated our previous year’s robot, The Reach, and its capabilities on the field to the public and industry professionals from Waymo. Waymo is a subsidiary of Google that focuses on autonomous driving in order to transform lives in a safe and effective manner. We were able to talk to them about our robot and get small bits of feedback on its design and code. Here, we are both able to motivate the community while also connecting with industry professionals.

      Additionally, we also engaged in a LEGO Mindstorms robotics activity with young children where they were able to build and code LEGO robots and then battle each other’s robots. This should help spark interest in children about the world of STEM and possibly motivate them to consider it in the future.

      Recruiting at Flight School

      10 Aug 2022

      Recruiting at Flight School By Aarav, Anuhya, Gabriel, Leo, and Georgia

      Task: Recruit new members at the TAG Flight School

      Earlier this afternoon, at TAG's flight school event for new freshmen, Iron Reign had a club booth for all the new freshmen to check out. There was a quick recruitment presentation for all the people who showed interest. Potential members also received information about the first meeting at our offsite location. Recruitment efforts like these are important to fill up our sister teams Iron Core and Pandemonium and help ensure the sustainability and longevity of the Iron Reign program. With a decent amount of the current iron Reign team being incoming seniors, it is important to keep recruiting potential members who can move up the ranks and eventually replace those who graduate.

      Next Steps

      The next steps would be to have all the new members attend the informational meeting offsite and be divided among our sister teams if they do commit to the program. Further recruitment efforts at SEM would also be welcome.

      FLYSET Workshop

      20 Aug 2022

      FLYSET Workshop By Anuhya, Gabriel, Trey, Vance, Leo, and Aarav

      Task: Give a presentation at the FLYSET Workshop

      At the FLYSET Workshop, hosted by team 8565, Technicbots, and team 20313, Mustang Robotics, we were tasked with introducing our remote controlled excavator, Mechavator, to the advance track attendees.

      Gabriel was tasked with making the presentation and script for the workshop, in which we would also include teasers about our video, Duck Hunt. Each of us were given certain slides to memorize and learn everything about, so we would all have enough experience to answer any and all questions about the Mechavator. The Mechavator was our project over the summer, and we were very excited to introduce it to the FTC community.

      Reflections

      As we reflect back on our presentation earlier, we have come to the consensus that the delivery was alright. However, we recognized that we didn't make our presentation for the audience. Since we were presenting for the advanced track, we should have gone more in depth with more technical aspects of creating the Mechavator, such as coding the Mechavator and the GPS RTK system. We only had 15 minutes for a presentation about a concept that hasn't been tried within FTC before, so we had to condense our content and this was the best outcome we could have hoped for. Nevertheless, most people enjoyed the presentation, because it was introducing a fresh idea of how robotics could be implemented. The presentation overall went well, and we connected the content from slide to slide seamlessly.

      Next Steps

      Our next steps are to post the videos where we showcase our Mechavator, as well as a parody of the FTC reveal videos. Unfortunately, we no longer have the Mechavator, but it's legacy will forever be a part of Iron Reign Robotics.

      Interest Meeting

      07 Sep 2022

      Interest Meeting By Anuhya, Aarav, Georgia, Gabriel, Vance, Leo, and Trey

      Our Interest Meeting at TMC

      To gain more members for our sister teams, Team 15373, Iron Core, and Team 3734, Pandemonium, we held an interest meeting at Townview Magnet Center earlier today. It was crucial to get more members so we could continue the Iron Reign legacy for the future years, as our members are all from our sister teams.

      Our new sponsor, Mr.Florczak, kindly let us use one of his rooms to host our interest meeting. We had an incredible turnout from all the grades, and we're all looking forward to forming new relationships with the new members of our team. We gave a presentation on what FTC is about and what an incredible opportunity joining this robotics team will be. We explained how our team works and showed them our accomplishments, including the Mechavator. The new recruits were very curious about Iron Reign Robotics, so we happily answered all their questions. We also presented our robot from the most recent season, The Reach, and demonstrated the innovative design. After we had finished everything scripted, we all split off to get to know all our new teammates.

      Next Steps

      The official kick off for the new game, Power Play, is happening this coming Saturday. The first thing we have to do is organizing the RoboDojo so it's robot-ready, and making sure the team, including the new members, are prepared for the new season.

      Season Reveal

      10 Sep 2022

      Season Reveal By Anuhya, Aarav, Georgia, Gabriel, Vance, and Trey

      The Season Reveal of 2022-2023's Game: Power Play!

      Today was the season's official kick off the 2022-2023 game, Power Play! However, Gabriel, one of our members, gave a wonderful keynote speech, taking inspiration from Steve Jobs, for the reveal of our Mechavator.

      Initial Thoughts

      Our first thoughts when we saw the new game, which is about capping yellow poles mounted on springs throughout the game field, was that we would have fewer options when it came to innovative designs. We also knew we would need to read the game manuals very thoroughly, memorizing small details so we knew exactly what the rules were and so we wouldn't have any issues with inspection in competitions. One of the main challenges would be getting a mechanism which would be able to grab the game pieces and place them onto the tallest poles, which are 30 inches in height. This is 12 inches more than the tallest height our robot is permitted to be at the starting position, meaning we would have to make a collapsible mechanism, such as a linear slide. We also need a method of picking up the game pieces which doesn't require too much precision so our drivers have more freedom. We are experimenting with beaters as well as different shapes of claws so we have a variety of options.

      Next Steps

      We will begin working on making a robot for Robot in 2 Days, which will be a base robot we will build on and adapt so it will be usable throughout the season. This is a way for us to brainstorm our ideas into a functional robot and see it in action.

      Robot in 2 Days

      11 Sep 2022

      Robot in 2 Days By Anuhya, Aarav, Georgia, Gabriel, Vance, Trey, and Leo

      Our First Ideas: Robot in 2 Days!

      Our Ideas with Build

      As a base robot, we started with an 18 inch cubic frame. This was the frame we'd most easily be able to modify and build upon as we progressed further into the year. For an initial brainstorming session, our Robot in Two Days would let us get some ideas into place which we could then bring up to our standard and innovate on.

      First, we noticed that our motor placement would make it harder to retrieve any of the cones. We knew we would need a mechanism to bring the cones up at varying heights to deposit on top of the poles, so we decided on using a gripper and linear slides. We moved all the motors back to create space in the front for our linear slide and gripper. We also had to clear up any obstructions, such as beams, control hubs, our expansion hub and battery to make some more space. We attached the control hub, expansion hub, and battery to the back of the robot. We fixed inconsistencies in the frame, such as misalignment in beams, to improve the stability and quality of construction. Working on wire management was cumbersome, but necessary, so our robot would be able to get as many points as possible without getting tangled up in wires.

      System for Intake

      Because the highest beams are 30 inches, we designed a linear slide which can reach a maximum height of 30 inches. This means it will be able to score on all the poles: low, medium, or high. The linear slide was attached to the middle of the robot, in the space which was just cleared out. We also made a pair of tweezers which would help grab game elements from the top and latch on inside the game elements. These were then attached to an angle control servo, which would make it easier to grab the cones and also increase the reach height slightly.

      Because we needed more accuracy, we used a flexible material to make a funnel to better intake our game elements. We had to fix and align the funnel a few times for greater efficiency. Next, we got to wiring up the motor for the actual lift. We realized that the linear slides stick out of the sizing cube by a 1/2 inch, but we purposefully ignored the problem because we'll have more time to get the technicalities correct by our first league meet.

      Finally, we covered all the sharp corners of our robot with gaff tape and added the LED panels we're using for team markers.

      First Implementation of Code

      Our team has a lot of new coders this year, so we spent most of this time getting used to the interface and re-examining and interpreting code from past years which we could then use as a template. However, we got all the motors and servos to work, as well as coding the Mecanums to navigate the game field.

      Meeting Log 9/24

      24 Sep 2022

      Meeting Log 9/24 By Aarav, Anuhya, Georgia, Gabriel, Trey, and Leo

      1. Game strategy 2. Tombot as sparring partner. 3. Gripper Designs. 4. New recruit build teams.

      Game Strategy

      Iron Reign engaged in an exercise to better understand the game and create an optimal strategy when multiple robots are on the playing field. Two team members were blindfolded and acted as “robots,” while two others were the “driver” and voiced instructions. The blindfolded members followed their instructions and effectively played the game. This helped us better understand how the game evolved and the best ways to score points efficiently.

      With the season coming up quickly and the first league meets scheduled for about a month away, we needed to prepare robots for competition and help the recruits begin.

      Fixing up Tombot

      One of the critical action points was fixing up Tombot, one of our older competition robots that utilized a linear-slide crane to score pieces at high altitudes. Tombot could potentially be used as a competition partner to simulate gameplay better and improve drive practice. However, TomBot had a couple of issues that needed to be resolved. Specifically, the Omni wheels at the ends of the chassis were getting caught in the junctions, so we raised them to allow for cleaner movement. We also fixed a loose chain that kept coming off and practiced driving around the poles and over the junctions.

      New Recruits Progress

      Next, the new recruits started working the chassis for their root, using a mecanum-based drivetrain and vs-shaped chassis. They also split into two teams and started building prototypes of their cone gripper. The first prototype(shown below) uses a conventional gripper that wraps around the cone from both sides and picks it up. Driven by a single servo, it uses two gears to move the two gripper parts.

      The second prototype currently only has the two sides of the gripper, which use metal pieces and rubber bands to wrap around the cone. The new recruits also started working on the chassis for their robot, which uses the metal REV rails and a mecanum drivetrain. They were able to conceptualize it and started cutting the REV rails to the correct lengths for assembly.

      Iron Reign Gripper

      Iron Reign began modeling potential grippers for testing, including designs that packed up the cones from the top song with a few to grab the cones from the side. A greater variety of options will be helpful when creating the robot. In addition, work began on a cone-adjusting mechanism to right fallen cones and adjust the position of picked-up ones to score them properly.

      Code Development

      A few recruits interested in coding were taught the basics of programming the robots with Java, and our senior coders created basic mecanum and tank drive code for the teams to use. This should help us get a head start on coding and better help the rookie teams later in the season.

      Next Steps

      The next steps for the rookie teams would be to start building the chassis, attaching additional components, and continuing to develop their grippers. For Iron Reign, our next steps are continuing to design and prototype the gripper iterations and optimizing TomBot.

      Think Robot Ideation - TallBot

      02 Oct 2022

      Think Robot Ideation - TallBot By Aarav, Gabriel, Trey, Vance, and Leo

      Task: Design and Think about possible robot ideas after Ri2D

      After Robot in 2 Days, we decided to brainstorm and create more robots to test out ideas. One of those preliminary robot ideas was TallBot. This design involved using linear slides to increase the robot's height in order to allow it to drive over the poles. However, as you can see in the video below, it was not structurally stable and often collapsed on itself. It's wires also easily unplugged, which is not ideal for competition scenarios. Embedded above is a video showing our initial testing of a prototype TallBot, and you will see exactly why we chose to scrap it. However, it did represent our effort to stretch outside the box, literally.

      Overall Progress From the Past Two Weeks

      16 Oct 2022

      Overall Progress From the Past Two Weeks By Anuhya, Georgia, Gabriel, Vance, and David

      Tasks:
      1. Working on path following with Code
      2. Creating prototypes to optimize the Build design
      3. Gaining experience with 3D Modeling using Fusion 360

      Code

      Our main coders, Vance and David, have continued working on reqriting the code base to make it easier to understand. We have many new recruits on our sister teams who are interested in learning how to code, so a lot of time has been spent on making the code base more user-friendly.

      One major issue we were having is that there was a lag between operating the robot and the robot function. While scouring the code to find and address the problem, we noticed that there was a 1 second loop time. By eliminating this loop time, which may have initially been added to add a buffer period, our robot began to work much faster and was far easier for our drivers to operate. We also added custom PIDs for the turret and crane, giving us smoother movement with controlled speeds.

      The coders are also working on using different methods of path folowing, such as straight orthogonal line following versus Pure Pursuit, to determine which would be the optimal method. Straight orthogonal line following would be far simpler to use and code and is already well aligned with the field set up and game design for Power Play, while Pure Pursuit is more often used in collegiate-level robotics and is a common path following algorithm. Once you get it right, it is very reliable and can be manipulated well.

      We hope to get the path following and code base overall testable as soon as possible so we can work through specific motions and rotations as well as making it easier for our drivers to get in more practice before the first league meet.

      Build

      One of the major components of our robot is the extension of the arm, which enables us to reach even the tallest of poles with no difficulty. However, the set screws on the pulley system, which control the arm extension, were very loose, caused the axle to come off and render the whole arm useless. The first thing we did was tighten the set screws and work on many of the other regular repairs which were needed to keep the robot in optimal working condition.

      Our robot uses a coiled extendable wire to operate the servo which controls our gripper system. However, due to the length of the wire, it got in the way of a lot of robot function and was just inconvenient overall to work around. We created a simple cardboard prototype to set our extendable wire so it wouldn't inhibit the rest of the robot and would allow all functions to occur freely.

      So we would be able to automate the process of depositing cones, we installed a webcame which allows us to see how far the arm is extended.

      Our gripper system needed a way to conveniently attach to the arm, so we had to create a component which would attach and align the gripper system properly. The gripper system has 4 main parts: a distance sensor, a servo, an expandable bulb and a cone guide. The component, appropriately named the Servo Clamp, was designed to be able to attach the bulb, servo, cone guide, and distance sensor separately while also aligning them so the robot would be able to use the sensor to detect the cone and pick it up using the bulb and cone guide.

      Next Steps

      There are always more improvements and more progress we can make in code, and we also need to make a separate intake system for the cones because it's more efficient and would allow us to score more points quickly. We also want to rebuild the robot piece by piece to make it more resilient and fix each individual aspect.

      Meeting Log 10/22

      22 Oct 2022

      Meeting Log 10/22 By Georgia, Aarav, Gabriel, Leo, Trey, Anuhya, Aarav, and David

      Task: Drive Practice and Getting Code to Work

      Today was mainly focused on getting proper drive practice and getting the path following for the April Tags to go to the correct locations. As such, in between commits, our drivers Leo and Georgia were able to get some familiarity with the controls, while our coders Vance and David worked on PID tuning and autonomous corrections.

      We ran a few practice matches of just teleop to measure and improve the skills of our drivers. This consisted of 2 practice matches each for both Leo and Georgia under the 2 minute timer. Leo scored 2 cones the first match and 3 cones the 2nd match, while Georgia scored 2 cones for both matches. This highlighted how little we had actually practiced driving the robot, but also sparked an idea in Vance and David.

      Upon witnessing how slow going manually picking up a cone and scoring it on the tallest pylon was, the coders begun work on making preset values for picking up a cone and scoring it, implementing a memory element so that the robot would record where it picked up and scored a cone, and specifically return to those locations. In addition to working on the April Tag location to recognition, they also achieved being able to cut our scoring time basically in half, giving us more opportunities to score cones.

      Next Steps

      Creating a prototype LED battery holder for our panels and getting the April tag locations to work for both Autonomous points, as well as Tiebreaker points for the future.

      October 29th Screamage Overview

      29 Oct 2022

      October 29th Screamage Overview By Georgia, Aarav, Anuhya, Trey, Gabriel, and Leo

      Screamage at Marcus High School Overview

      Today, Iron Reign attended the Screamage at Marcus High School to play a couple of practice matches. This event allowed us the opportunity to better understand the game flow and further develop a strategy, finally get some drive practice, and point out any flaws in the robot and its design to help improve the next iteration of TauBot.

      Initially, we were faced with a lot of structural issues regarding the build of the robot. The wire connection on the arm had to be properly secured to ensure that cables did not get tangled or caught whenever the crane extended, and minor modifications to the chassis were required to properly secure the LED Panels to the robot.

      Then came the software troubleshooting. The robot struggled to properly drive without drifting and our drivers needed minor modifications to the mapping of the buttons to streamline gameplay. However, we were able to get tons of solid drive practice at the practice field and were able to consistently score multiple cones on all 3 levels of the poles by the end of the scrimmage. We also utilized our memory functions to help automate the pickup and drop-off process and taught our drivers how to best use those capabilities.

      Then came the actual practice matches, and let's just say, they did not proceed as smoothly as expected. Our lack of drive practice was evident, as we often dropped cones short of the poles and were barely able to score successfully. At one point, we managed to pick up around 6-7 cones, but only succeeded in scoring 1-2 cones onto the actual pole. Evidently, this is something that will need to be addressed before the first league meet.

      Robot reliability also proved to be a major concern and created a lot of issues during gameplay as our robot would often break down during the game, rendering it useless and incapable of doing anything. After ramming our robot into a junction during gameplay, part of the polycarb chassis cracked where the screws were attached to the Rev Rails, which also locked up our front set of Omni wheels that we used for stability. We managed to restore the robot to a usable state, but the cracked polycarbonate will remain until we build the new robot. These issues continued to plague our robot, and during a match, the axle holding up the crane dislodged from the motor mount, which caused the entire crane to shut down mid-match, and led to us replacing the axle and the screws used to secure it.

      Next Steps

      The first thing we need to do is shave off part of the arm so our robot will fit within the sizing cube. Secondly, we need to redesign the configuration of the LED panel and battery mount, bottom battery wire, and the arm wire holder, so the wires do not hinder the robot's movement and ability to perform. Thirdly, we must find a way to keep the left motor from slipping out of its mount. We also need to adjust the height of the front Omni wheels, using spacers to allow for more movement and prevent them from locking up. Finally, we need to add polycarb plates to the chassis to prevent furthur damage.

      Meeting Log 11/4

      04 Nov 2022

      Meeting Log 11/4 By Gabriel, Trey, and David

      Task: Fixing Issues from the Screamage

      After the Screamage, many different problems became apparent, including the fact that the robot just barely fit sizing requirements. In order to combat this, we decided to cut off .75 inches off the arm extension from the carbon fiber rod and added a new hole for the mount for the gripper system, which didn’t have an effect on the code or presets. Trey also continued to work on 3D modeling for the new robot.

      David then proceeded to work on fine tuning for the presets for picking up and scoring a cone, as the movements were a bit aggressive to say the least, and by the end of the day, while slower, had become much more manageable as testing would prove to us. He also continued to work on the April Tag recognition for autonomous.

      Next Steps

      Make use of polycarb to create a new LED battery holder than can be mounted directly to the robot and fix the pulley system to keep it from falling off the axel and rendering our robot useless.

      Meeting Log 11/5

      05 Nov 2022

      Meeting Log 11/5 By Gabriel, Trey, Vance, Leo, and Georgia

      Task: Fixing Issues from the Screamage Pt.2

      In tandem with yesterday, the main goal of this meeting was to improve upon the robot after the Screamage. This consisted of two main aspects, being a new way to mount the pulley because of the set screw of the motor that kept untightening from the axel and falling off at the most inopportune times, and a new battery holder for the LED panels with better mounting, as it was just wedged into the robot at the Screamage

      Fixing the Pulley System

      After many failures of the pulley system and antics with threadlocker and set screws, enough was enough. We decided that using the CNC to directly drill into the pulley to attach that directly to the motor was a better idea, and after a careful process, the pulley was directly mounted to the motor and thus far has experienced no further issues.

      Making a New LED Battery Holder

      The cardboard battery holder was an okay temporary solution, but in no way was meant to be a permanent addition to the robot. Instead, we opted to make a new one out of polycarb and create a place for the wire to filter through, which required measuring the battery and bending a piece of appropriately sized polycarb. It worked well, and looked semi decent but may be replaced in the future

      Meeting Log 11/8

      08 Nov 2022

      Meeting Log 11/8 By Gabriel and Leo

      Task: Preparing the Robot for the Upcoming League Meet

      General Fixes:

      The LED battery holder from the previous meeting snapped, requiring us to rebend and make a new gate for the LED Battery holder from scratch, which took a bit of time. In addition to this, all the set screws on the robot for the shaft collars and the pulley systems, as well as using threadlocker on the right motor mount in order to keep the right motor from shifting out of place and causing the chain to fall off the gear. This also solved the problem of the chain not fully aligning with the gear, causing a gradual stray of the straight pathing.

      3D Modeling a New Wire Holder:

      As discussed previously, the current iteration of the wire holder for the arm extension made of cardboard isn’t practical, and so Leo worked on a 3D model for the new version of the wire holder. This version addresses the wire getting caught upon on the corners of the holder as well as a more durable design as cardboard is not good at keeping it’s shape, and will more easily fit over the 2 motors.

      Meeting Log 11/10

      10 Nov 2022

      Meeting Log 11/10 By Georgia, Gabriel, Leo, Vance, Trey, and David

      Task: Finishing Code for Upcoming Meet and Drive Practice

      We fixed the turret heading PID so that it does not spin uncontrollably when the angle changes from 359 to 0, and adjusted and tuned ticks per inch. We integrated memory of drop off and pickup positions with the crane so our drives don't have to spend a lot of time precisely aligning the arm with the cones and poles, enabling us to quickly score more cones per match. In addition, we created a basic auton program that reads the AprilTag on our custom team sleeve, then parks in the correct location accordingly.

      The drivers practiced pick up and drop off using the new presets, then ran timed matches to see how many cones they could score, averaging 3-4 cones per match. We also practiced positioning and setting up the robot before beginning auton.

      Next Steps

      Due to oscillation of the arm after calibration, the camera occasionally cannot read the April Tag, so we need to fix this before the meet. Additionally, we need to do more drive practice before the meet this Saturday, inorder to improve the number of cones we score each match.

      Meeting Log 11/11

      11 Nov 2022

      Meeting Log 11/11 By Gabriel, Vance, Aarav, David, and Georgia

      Task: Finalizing the Robot the Day Before Competition

      The day before a competition always sees arguably the most productivity from all the teams in a rush to finish up what they hope to accomplish the next day. For Reign, this was getting autonomous working, final drive practice for Georgia, and the printing of the team beacons.

      Finishing Auton:

      The first few hours were filled with commits from both David and Vance in an attempt to get the April Tags basically perfect. The camera was able to read the tags only some of the time due to the oscillation of the arm after calibration, which would be frequent at low voltage levels. Fortunately, this was solved and the rest of the night was spent on simplifying the calibration sequence and PID tuning for the arm.

      Drive Practice:

      A few practice matches were run which included both autonomous and TeleOp with a timer to see our limits. The average performance saw autonomous working and around 3-4 cones scored, but some outliers saw no autonomous points and no cones scored, which was certainly worrying. In the end, further drive practice was sacrificed in order to get the autonomous code working.

      Making and Dying the Beacons:

      The final thing we finished that night was the beacons for additional scoring. This was modeled as a loose sleeve that fit around the cone initially, but then we cut around it and made just a tab protruding from the base in order to meet sizing requirements, as well as dying them red and blue respectively and writing the team number on them.

      1st League Meet - Post Mortem

      12 Nov 2022

      1st League Meet - Post Mortem By Georgia, Aarav, Gabriel, Leo, Trey, Vance, and David

      Tasks:
      1. Review 1st League Meet
      2. Analyze 1st League Meet Performance
      3. Discuss Possible Fixes + Next Steps

      Play By Play

      1st Match - The first round went horribly wrong, as Gabriel touched the phone after randomization, netting a minor penalty. While autonomous did read the April Tags, the arm was outside the tile, so regardless we didn’t score the 20 points for autonomous. In an attempt to get the robot started and not have to do calibration, the sequence was skipped which caused the turntable and arm extension to fail completely. Our score was 2 points scored by our alliance partner, and was a loss.

      2nd Match - The 2nd this time, the autonomous program worked, but yet again the arm was outside the confines of the tile, meaning no autonomous points. The new calibration sequence, which required a button press, was not completed, and so yet again, failure in the arm and turntable, and an additional crash of the robot. The score was 37 points scored by our alliance partner and a loss.

      3rd Match - The 3rd match autonomous finally worked, netting us 20 points. The presets for cones, however, was not working and so had to be done manually. The score at the end was 38 points and resulted in a win.

      4th Match - The 4th match autonomous succeeded yet again, gaining 20 points. Unfortunately, the calibration sequence again wasn’t completed, meaning we couldn’t score any elements. The match resulted in a 34 point win, a win that was barely gained, as we scored 1 more point than the opposing alliance.

      5th Match - The 5th match was by far our best performance. The April Tag recognition worked again, netting us 20 points. The presets for cone scoring finally worked, and with it, our driver Leo was able to score 9 cones, one of which had a beacon on it, getting our alliance 93 points, the record for that meet, of which we scored 74 points.

      What Went Wrong + How To Fix It

      This past Saturday marked the first League Tournament for the University League and our first competition. Unfortunately for us, it did not go as we had hoped, but was instead more grounded in reality. There were a lot of problems that only reared their heads during the competition.

      The beginning of the competition was the most problem intensive, with everything from the calibration sequence infinitely rotating the turntable, the belt slipping off the arm extension, and the presets for cone scoring going awry. Luckily for us, the end of the competition resulted in a fix to some of these issues which lead to us placing in 4th ranking wise, and getting the high score for point total in conjunction with our alliance partner. However, this does not mean that there were no persisting problems after the fact.

      Starting off with build issues, our mount for the current iteration of our bulb gripper was able to shift slightly to both the left and right with enough force applied. The constant smacking down of the gripper onto cones was a likely culprit in the shift meaning its an issue that has to be further addressed by tightening the carbon fiber bar more. The belt for the arm also managed to slip off at one point, but luckily it was in between matches. It serves as a good reminder to replace old rubber bands, which do not age well at all. The robot was also getting caught on the pylons, even when they didn’t have cones on them, meaning that its a combination of the chassis being a bit too big even though it fits standard sizing and more drive practice needed. Also, while it didn’t present too big of an issue at the competition, our current wire holder for the arm extension is just impractical and arguably cardboard should never appear on a robot at a competition.

      Moving onto code issues, the start of the competition began with a big scare. During the calibration sequence, the turntable would rotate uncontrollably and would persist through infinite rotations. Fortunately, Vance and David were able to address this before any of the matches actually started. The issue of presets also became apparent because of calibration. Once autonomous finished, the Teleop program had to be initialized and recalibrate itself, which for one reason or another, completely messed up the presets, which are designed to remember the locations that it picked up a cone, and where it dropped off a cone.

      Next Steps

      Our robot needs to be thinner in order to navigate this year’s field more effectively, which is currently being addressed with the modeling and future construction of basically a version 2 of our current robot. The cardboard wire holder is going to be replaced with a 3D modeled version, which hopefully will look sleeker and serve its function better than the current iteration. There is also the idea of custom wheels as last year set a standard that we should keep alive.

      Meeting Log 11/18

      18 Nov 2022

      Meeting Log 11/18 By Gabriel, Trey, and Vance

      Tasks:
      1. Fix Issues from the Last Meet
      2. Build Upon our Current Strategy
      2. Continue to Develop TauBot 2.0

      The League Meet was a rude awakening for all the things we needed to improve upon and start. This includes a better autonomous, as other leagues are already having regular 30-40 point autonomous programs, documentation as even though League Meets don’t require them, the Tournament is slowly encroaching on us, and it needs to be solid by then and the modeling of a version 2.0 for the current robot to further improve cone scoring.

      Building Upon our Current Strategy

      In order to be a competitive team, we need a stronger autonomous. The current strategy for this is just the April Tags, which nets us 20 points. However, since April Tags still leaves around 14 seconds of autonomous to be filled, Vance has been working on a pre-load cycle, which would read the April Tag with the preload, drive to the destination, score the preload on the tallest pylon, and then continue to take from the cone stack and continue to score, which could easily elevate us to a 30-40 point autonomous run. We also need to start thinking about capturing more pylons, as this early in the season it’s been noted that each team generally stays to their quarter of the field. In order to capitalize on this, we plan to change our strategy to capture all the pylons within our quarter of the field, as each junction/pylon captured is an additional 3 points, which would then be followed by scoring on the tallest pylon.

      Version 2.0 of TauBot

      Currently, there is a second version of Taubot being 3D modeled in order to accommodate a smaller sizing as well as a separate intake system. More details about this will be discussed in a future blog post.

      Next Steps

      Continue to build upon the autonomous program and learn a new drive strategy for the League Meet on December 3rd.

      Meeting Log 11/19

      19 Nov 2022

      Meeting Log 11/19 By Georgia, Aarav, Gabriel, Trey, Leo, and Vance

      Task: Drive Practice and Improving Code

      Today, we spent time improving upon the code by fixing the odometry and fine tuning it, along with doing some much needed drive practice.

      We fine tuned the PID and speed, as well as the pickup and drop speed and staging. We also fixed the odometry, which calculates the position of the robot based on how many times the wheels have turned. We changed the staging of the crane memory system to be more accurate and fix the angle of the shoulder before it extends, so it won't hit the poles or cone stacks when changing position.

      Our drive team ran practice matches to improve precision and accuracy while also scoring as many cones as possible. We focused on picking up cones from a long distance, utilizing our crane's reach and scoring from afar. The arm tended to overshoot when fully extended, making it more difficult to score, so our drivers had to practice taking this into account when aligning the crane and turret with the cone and poles for pickup and scoring.

      Next Steps

      We need to finish our auton code so the robot will pickup and score cones from the cone stacks and drop them onto poles during the auton period. We also want to finish and tune code for grid drive. And, of course, more drive practice!

      Code Progess for November

      21 Nov 2022

      Code Progess for November By Vance and David

      April Tags

      This year, using FTC 6547's tutorial on april tags, we developed a system to detect which parking location we should park in. The april tag system allows the onboard camera to detect the sleeve at a distance without it being directly in front of the camera unlike other systems. It also requires much less processing than QR codes which allow it to detect the sleeve faster and with greater accuracy.

      Crane Memory System

      One unique feature of this robot is the crane's memory system. The crane remembers its position where it picks up a cone and where it drops the cone. This memory allows the crane to take over positioning the gripper for picking up a cone and dropping it off. The driver now only has to finetune the pickup and drop position and initiate the pickup and drop sequence.

      Grid Drive

      One helpful feature that would make the robot more reliable is grid drive. Since the field this year has all the objects placed in a grid, the robot can navigate between the pylons relatively easily however we found that drivers could not be as precise driving than the robot’s odometry and as such we developed a system where the driver tells the robot where they want the robot to go and the robot creates and follows a path to get to its target location. This system decreases transit time significantly and makes driving more precise. This system can also be used with the crane to pick up cones from a specific location and drop them at a certain pylon of the driver's choosing.

      Field Class

      We've also developed a special class to keep track of the current state of the field. The Field class keeps track of all objects on the field and their location, height, and name by creating a separate fieldObject object for each. These objects are then stored in a list and that list can be sorted through to find for example the closest object to the robot of a specific height. The robot using grid drive can then drive to a location where it can then score on that object.

      Meeting Log 11/26

      26 Nov 2022

      Meeting Log 11/26 By Georgia, Gabriel, and Leo

      Task: Build, Modeling, and Drive Practice for Upcoming League Meet

      We spent today's meeting fixing minor build problems, then ran timed practice matches. Additionally, we started modeling the prototype for the nudge stick.

      We began designing a prototype for a nudge stick, which will help speed up cone drop off. The stick will touch the pole at one point of contact and will be able to move to either side, depending on which direction we are scoring from.

      The arm and mount, specifically the set screws and shaft collars, will often become loose, so we used threadlocker to secure these and reduce its chances of becoming too loose during a match. We redid the connection for the LEDs because a wire had snapped out, then rewelded the mount for the LED panels, as it was beginning to split down the center and was revealing the inside of the panel.

      We did lots of drive practice, running many timed practice matches. We managed to score the auton preload, along with about 3-6 additional cones and beacon. Unfortunately, auton was somewhat unreliable, as Taubot did not always score the preload cone on the pole and fully park in the correct space.

      Next Steps

      Our next step is to fix our auton code so Taubot consistently manages to score the auton preload cone and fully park in the correct spot. We also need to finish the nudge stick prototype so we can begin testing and finetuneing it.

      Meeting Log 11/29

      29 Nov 2022

      Meeting Log 11/29 By Georgia, Anuhya, Gabriel, and Vance

      Task: Code and Build Before League Meet

      We partially remade the joint that connects the extension part of the crane to the turret, as we found that under high stress the gears were prone to slipping. We also changed the gear ratios on the shoulder to increase the torque produced at the cost of the speed of the crane. We did this because under most situations we were hitting the torque limit of the motor but we almost never hit the speed limit of the motor. This will make the crane much more controllable, especially when the crane is at maximum extension. Additionally, we began building the nudge stick for the crane.

      As for code, we created two new methods. The first method takes in the robot's current position on the field and, using an IMU that is attached to the turret, calculates the position of the center of the turret. This is method is needed for inverse kinematics to work because the center of the robot is not aligned with the center of the turret. The second method takes in the desired X, Y, and Z coordinates that the turret should target. It first takes the turrets's position then uses that position to calculate the heading that the base needs to target inorder to align itself with the proper X and Y coordinates. It then calculates the horizontal distance needed to get to the target position. That distance, along with the Z target height, is then used to calculate the angle and amount of crane crane extension required to achieve the target position.

      We began working on a model for the differential distance sensor mount, with the distance sensors mounted on the side pieces so we can adjust their angle inorder to pinpoint where the cone is located. We added a space in the middle for a laser, which we will use for testing the range of the distance sensor.

      Next Steps

      We need to finish building and coding the nudge stick so we can test it and practive scoring with it. As for the differential distance sensor mount, we need to finish modeling it and then build and test it.

      Meeting Log 12/02

      02 Dec 2022

      Meeting Log 12/02 By Georgia, Anuhya, Gabriel, Leo, and Vance

      Task: Prepare for Our Second League Meet

      Today we worked on finishing the nudge stick and auton code, along with doing driver practice and other preparations for the upcoming meet.

      We finished working on code for the nudge stick so it will rotate to the left or right of the pole in order to help the driver align the cone with the pole more easily and quickly. The stick is mounted to a servo which allows it to move to either side of the arm. Next we worked on code for auton and tuned it to be more reliable.

      Our drivers spent lots of time practicing seting up the robot and diving it. We scored about 4 or 5 cones per match plus auton and a beacon.

      League Meet #2 Post Mortem

      03 Dec 2022

      League Meet #2 Post Mortem By Anuhya, Georgia, Gabriel, Trey, Vance, Leo, and Aarav

      Task: review the progression of matches in our latest League Meet

      Team 6832, Iron Reign, and our sister teams, Iron Core and Iron Giant had our second league meet earlier today. Overall, it was a very good learning experience and we got to see the functional robots of many of the teams in our league in action. After observing many unique robots, we learned a lot about the differences in strategies between us and other teams and how we could use our differing strategies to work together in a cohesive alliance.

      Play by Play

      Match 1: Win

      We got a total of 45 points, but we got a 20 point penalty for our human player placing a cone in the substation at the same time the robots were in the substation. In the autonomous section, Taubot's arm wrapped around the pole, which got stuck in the wires. We were unable to get a cone or parking. During driver control, we got 3 cones, and we got 1 cone with the beacon during the end game. Our robot scored 28 points by itself.

      Analysis: During autonomous, our robot was overshooting while trying to place the cone, so it would get stuck around the pole.

      Match 2: Win

      We got a total of 88 points, but we got a 10 point penalty for our human player, once again. In the autonomous section, we were unable to get the cone, but the overshooting issue was resolved and we got the points for parking. During driver control, we got 4 cones, and we got 1 cone with the beacon during the end game. Our robot scored 53 points by itself.

      Analysis: Our autonomous section needed to be tuned, and our drivers need more drive practice so the arm can be more reliable.

      Match 3: Win

      We got a total of 68 points, with no penalties. Our human player was incredible at telling the other team to not put their robot in the substation as she was placing cones. In the autonomous section, we scored a cone and got parking. This was the most we were capable of in autonomous. In driver control, we got 3 cones and we got another cone with the beacon in the end game. Our robot scored 53 points.

      Analysis: We could have gotten more points during driver control if our gripper mount wasn't so loose and didn't need to be constantly tightened, and we needed more drive practice for more precision/reliability.

      Match 4: Win

      We got a total of 78 points, with no penalties. In the autonomous section, we scored a cone and got parking, once again. In driver control, we got 5 cones, and we got another cone with the beacon in the end game. We scored 63 points with our robot, which is the highest score we got individually the whole tournament.

      Analysis: This match was the limit of both our autonomous and driver control, which means we need to push the limits and make the robot more efficient so more points are possible.

      Match 5: Loss

      We got a total score of 67 points, with no penalties. In the autonomous section, our robot couldn't score the cone, but we got parking. In driver control, we got 3 cones, but we didn't manage to get a cone with the beacon during the end game. We got a total score of 35 points with our robot.

      Analysis: We need more driver practice and precision, because adjusting the arm slightly when it's fully extended is incredibly inaccurate as it has very high momentum. We also need to practice different strategies, specifically defense, and not get distracted from our strategy by the strategy of the opposing team. Our autonomous section also needed to be more reliable.

      Post Mortem

      Strengths:

      • Not having to move the placement of the robot to score
      • Flexibility - we can score across the field and change where we pick up our elements without interfering with our alliance's strategy or robot
      • Human player - very good at telling teams not to move into box when she's placing things
      • Communicating with alliance partners

      Weaknesses:

      • Robot is bad at making circuits due to design of the robot
      • The big arm is too shaky to score quickly because of the weight
      • Cycle time is too long

      Opportunities:

      • Doing some defensive play
      • Scoring on multiple poles
      • Adding a fourth extension stage by decreasing the weight of the already present rods
      • Increasing the motor count to 5 on top of the turntable to support shoulder joint with more torque for the 4th stage of the arm

      Threats:

      • Letting the strategy of our alliance team interfere with our strategy
      • Getting distracted by the opponent's strategy, limiting how well we can perform
      • The cables of the robot getting tangled around itself or poles

      Meeting Log 12/06

      06 Dec 2022

      Meeting Log 12/06 By Georgia, Anuhya, Leo, Vance, and Gabriel

      Task: Improving code

      Today we tuned auton, implemented inverse kinematics, and made driver controls more user friendly.

      We implemented inverse kinematics with driver controls, auton, and the memory system. ​​We changed the driver controls to use height and distance rather than angle and shoulder. This makes it faster and much easier for the drivers to fine tune adjustments when dropping and picking up the cones. We also implemented this system in auton to make it easier to specify a target that the robot should aim for during auton.

      Next Steps

      Now that we have inverse kinematics working we can begin a scoring pattern code, which will allow the robot to memorize the field and move to score without driver input. This will make scoring quicker and easier for the drivers.

      Townview Tournament

      10 Dec 2022

      Townview Tournament By Gabriel, Georgia, Anuhya, Trey, and Leo

      Hosting the Townview Tournament

      This Saturday marked the First Tournament of the season, and with it came the opportunity for us to host the event at our homeschool, Townview. Twenty seven teams showed up for the tournament, all displaying great levels of gracious professionalism and a wonderful sense of sportsmanship for the whole tournament.

      What we learned

      This was a great opportunity for us to learn how judging would work this year and truly see how a tournament would function ahead of time. It also gave us a chance to see some of the more than impressive robots and their unique designs and innovations, as well as some potential new strategies to test out for ourselves.

      Overall, we had a great time hosting this event in collaboration with a lot of First representatives and alumni and we're very thankful to all the teams, volunteers, and judges that showed up and for having a great competition. We wish the teams good luck for the rest of the season!

      Virtual DPRG Meeting 12/17

      17 Dec 2022

      Virtual DPRG Meeting 12/17 By Aarav, Anuhya, Georgia, Gabriel, Trey, Vance, and Leo

      Task: Present TauBot to the Dallas Personal Robotics Group

      Today, we virtually presented our robot to the Dallas Personal Robotics Group(DPRG) to showcase our progress for this season and hopefully get advice on our robot's design, code, and presentation. DPRG is a group of engineers and robot enthusiasts who meet multiple times a month to discuss robotics and share their personal projects in the field of robotics. These meetings allowed us to practice our presentation skills and receive valuable advice from mentors and professionals.

      The meeting started with us briefly explaining Power Play to the members who tuned in and then transitioned into our initial Ri2D efforts and how that influenced our current design. We shared our initial idea of creating a "tall bot" that could drive over the poles and how that quickly shifted into the current robot focused on minimizing movement across the field.

      We went over the critical subsystems of our robot, which included the bulb gripper, arm, turret, and chassis, and explained how all of these worked together to accomplish our game strategy. Then we transitioned into the code aspects of things and shared how we managed to automate much of the gameplay with our memory functions, inverse kinematics, and anti-tipping code while also stating how we planned to integrate OpenCV and grid drive in the future.

      After that, we discussed our plans for the future iteration of TauBot and some of the significant changes we planned to make to the chassis to improve its efficiency and ability to score points. Finally, we presented a show demonstration of the robot driving around, scoring cones, and running the auton code. A lengthy question and answer session ensued, and we got lots of valuable feedback from the DPRG members that we will use to improve both TauBot 2.0 and our presentation.

      Regarding the feedback we received on the robot, DPRG suggested that we consider the distribution of mass and a potential counterweight to prevent tipping(which happened a decent amount during the demo), as well as possible code changes to help better control the autonomous path of the arm during movements. They also pointed out the oscillation of our gripper and suggested we add a degree of freedom to prevent that. Finally, one of the biggest pieces of advice they gave was to consider utilizing a movement system that allowed us to “fly the gripper.”

      On the presentation side of things, the main advice given was to consolidate our information, focus on the most impressive parts of our robot, talk slower, and create a correlation between our strategy and the implementation of our robot.

      Next Steps

      We are incredibly grateful to DPRG for letting us present and connect with professionals to improve our robot. We hope to meet with them in the future, possibly in January, as we develop our robot. Our next steps are considering their advice when designing and assembling TauBot 2.0, further automating our robot, and preparing our presentation and portfolio for the tournament in January.

      Meeting Log 12/30

      30 Dec 2022

      Meeting Log 12/30 By Georgia, Leo, and Gabriel

      Task: Driver Practice!

      Recently, Vance implemented a new control scheme : scoring patterns. This required some changes to the way the cone is “transported” throughout the field when the driver operated, and we found it was best to “fly the gripper” by controlling the 3 dimensional position of the cone on a cartesian space superimposed on the field. Basically, we control the x,y,z, which is a big change compared to the old controls, which controlled extension, turret angle and shoulder angle independently of each other. We're down to 3 weeks from our next meet and the goal is to get affluent with these new controls, which will (hopefully) help us score more cones.

      Next Steps

      There's still some fine tuning to be done with the controls, especially at long distances. The robot is still prone to tipping and crashing, but as a proof of concept, scoring patterns are looking promising. There was also some progress done on the CAD for the new robot (epic reveal coming soon), and we're looking to start manufacturing some of our designs on the CNC in the coming week, stay tuned.

      Meeting Log 01/04

      04 Jan 2023

      Meeting Log 01/04 By Georgia, Anuhya, and Leo

      Task: Build and CAD

      Today we focused on building and modeling our second iteration of Toubot. After designing and cutting out the parts for the underarm on the CNC we began assembly.

      As for modeling, we worked on the shoulder drive for Toubot2. We are redesigning our motor mounts because we need the extension on the arm to be stronger. We are changing the design for the shoulder drive by using 8 mm axles and using four 30 tooth gears instead of the single 30 tooth gear currently being used. We are also using “bridges” to mount our motors, because they are stronger than the standard REV rails.

      Next Steps

      Our next steps are to print the motor mounts and continue build. And more drive practice!

      Meeting Log 1/6

      06 Jan 2023

      Meeting Log 1/6 By Aarav, Anuhya, and Georgia

      Task: Documentation and CAD

      Today,we focused mainly on documentation and the continued CAD for the next iteration of TauBot. We worked on the outreach and Motivate sections of the Engineering Portfolio along with a few of the preliminary slides. Furthermore, we also made sure that the blog was all up to date.

      On the CAD side of things, we finished the shoulder drive on the CAD model and began 3-D printing a few motor mounts for the next iteration of TauBot.

      Next Steps

      Our next steps are to continue finishing the CAD model of TauBot2, continuing to assemble the parts we have completed, and to continue working on the Engineering Portfolio in preparation for the Tournament on January 28th.

      Presenting to DPRG

      14 Jan 2023

      Presenting to DPRG By Anuhya, Trey, Leo, Gabriel, and Vance

      Task: Present a status update to Dallas Personal Robotics Group

      You can watch our full presentation here. Today was our second meeting with Dallas Personal Robotics Group , or DPRG, this season. We updated the engineers at DPRG with our build and code progress. First, we ran through our newly assembled parts and subsystems. Then we showed our work in progress CAD in Autodesk Fusion 360 directly, and our main coder ran through our code. Finally, we had time for a small Q&A session with the engineers, where they asked us questions about our robot design and how it would achieve the goal put forth by the playing field.

      Build

      Newly Assembled Parts and Subsystems

      We had 3 main things to discuss when it came to newly assembled parts and subsystems: the new wheels and the underarm/chariot, which included the lasso gripper. Gabriel introduced the new wheels, which are made out of carbon fiber, nylon and ninjaflex. We also demoed the new wheels, which had just been attached to an axle. Because the bearings weren't aligned properly, the wheel was slightly wobbly. However, it was a good demonstration of how the wheel would work when it would be attached to the second iteration of our robot, Taubot. We changed to a custom wheel because it would give us more control and would also be slightly smaller than the old wheels, allowing us to optimize the design.

      Leo, who was the main designer behind all aspects of the underarm/chariot, was responsible for introducing it to the judges. Our underarm is designed to slot into the front of the robot, replacing the omni wheels with driven omnis which drive out the chariot. Our underarm is entirely made out of custom carbon fiber parts, and will be the intake system for Taubot: 2nd iteration. The chariot drives out, using the driven omnis, to the cone stacks and the substation. The underarm uses the lasso gripper to grip around a cone and passes through itself to hand the cone off to the main arm.

      New CAD For Future Assembly

      After displaying the custom parts of the robot which we had already assembled, we showed the parts of the modeling which were still in progress. I started by introducing the shoulder and turret assembly, which was still very much not completed. I talked about motor placement and gear alignment, and why we changed the design of the shoulder and turret. We wanted to stop using the standard REV rails and replace them with aluminum plates, which would be stronger and designed specifically for our purposes.

      Trey showed the changes we would be implementing with the arm. We changed the linear slides to a lighter model so it would be possible for us to add a 4th stage. This would make it possible for the robot to move minimally and still reach the entire span of the field. We are using a belt system and a motor at the base of the arm to extend the arm. Trey then showed the base and the chassis of the robot. He talked about how we changed the design, and how we would be using carbon fiber for the base as opposed to polycarbonate, because of how much stronger carbon fiber is and because of the issues we were having due to the polycarbonate cracking when it hit the walls of the playing field.

      Leo showed the model of the underarm and the chariot so the engineers could get a better understanding of how it would extend and operate. He also talked about how the battery would be in the moving section so we could counteract the tipping problem due to the weight of the arm.

      We also touched on our manufacturing process, and how we turned modeled parts into physical parts which would be used on our robot.

      Code

      Vance took the lead on showing what he'd been working on with code. The auton wasn't fully tuned up so everything was slightly off. In an ideal autonomous game, we would have gotten around 3 cones. Currently, reliability is a bit of an issue because of cone placement, because cones are very close to the wall. This makes the margin of error we have very little. The robot tipped over while we were trying to demonstrate autonomous, but it was an easy fix, along with a reset.

      Scoring Patterns

      The first thing Vance demonstrated was the scoring patterns. They were a very new addition, and they were good for drivers because it meant the drivers would only have to make a few micro adjustments to the arm placement instead of moving the arm the whole way around the game field.

      What is a scoring pattern?
      A scoring pattern is an array of field positions that the arm targets.

      1. The arm goes to a substation.
      2. The arm automatically goes to a different pole every time a new cone is picked up.

      The arm gets pretty close, but the driver has to line it up perfectly manually themselves. The reason we go to a different pole every time a new cone is picked up is because that gets us a lot of poles, which results in possible points for controlling poles. Each cone which is controlled is 3 extra points. This is very helpful strategically. There are 8 scoring patterns, because there are 2 cone sources. The driver can swap between any of the scoring patterns mid-match.

      While we were demonstrating scoring patterns, a pulley on the robot fell off. This took a while to fix, but the show must go on!

      Feedforward for PID

      The PID brings the shoulder to the correct angle at the correct speed and time. Our robot now uses feed forward, which calculates how much torque is on the arm and how much torque is needed for the motor to hold position or counteract the torque of the arm/gravity. This is entirely based on the current angle and position. If we fully extend the arm using PID but not feed forward, the arm would always slip down slightly. However, now the arm holds position, even when it's fully extended.

      Q&A

      The last portion of our meeting with DPRG was the Question and Answer session. The engineers asked us questions about our design and the game itself.

      Q. Why do you score during autonomous?
      A. We get double the points for every cone we score in autonomous, because it counts during both autonomous as well as driver control. We also get 20 additional points for parking the robot, which is quite reliable.

      Q. How many of you design the robot?
      A. There are 7 total people on the team. 3 of us model, and we mainly communicate through Discord and TickTick to divide the work. We also have design meetings to find mistakes in our models and discuss what needs to be fixed. Subsystems and different assemblies are organized into folders, and we each take responsibility for one main part. To sum it up, it's organized chaos.

      Q. What is the scoring estimate/target with the new pattern?
      A. We don't have one with the current pattern, because we don't have any testing. We got 8 - 9 cones with the old pattern.

      League Meet #3 Review

      21 Jan 2023

      League Meet #3 Review By Aarav, Anuhya, Gabriel, Leo, Vance, Trey, and Georgia

      Task: Review our performance at the 3rd League Meet and discuss possible next steps

      Today, Iron Reign and our two sister teams participated in the 3rd League Meet for the U League at UME Preparatory for qualification going into the Tournament next week. Overall, we did solid, going 4-2 at the meet; however, we lost significant tiebreaker points in autonomous points due to overall unreliability. At the end of the day, we didn’t do as great as we would have liked, but we did end the meet ranked #2 in the U League in #5 between both the D and U Leagues, and got some valuable driver practice and code development along the way.

      We entered the meet with brand new autonomous code that allowed us to ideally score three cones in autonomous and park, equating to about 35 points.

      Another main issue that plagued us was tipping, as our robot tipped over in practice and in an actual match due to the extension of the arm and constant erratic movement, which we will elaborate on in the play-by-play section.

      We also want to preface that much of our code and drive teams were running on meager amounts of sleep due to late nights working on TauBot2, so a lot of the autonomous code and river error can be attributed to fatigue caused by sleep deprivation. Part of our takeaways from this meet is to avoid late nights as much as possible, stick to a timeline, and get the work done beforehand.

      Play by Play

      Match 1: 46 to 9 Win

      In the autonomous section, our robot missed the initial preload cone and fell short of grabbing cones from the cone stack because there was an extra cone. Finally, our robot overshot the zone and got no parking points. Overall, we scored 0 points. In the tele-op and endgame sections, because of a poor quality battery that was overcharged at around 13.9 volts, our entire shoulder and arm stopped functioning and just stood stationary for the whole period. In the end, we only scored 2 points by parking in the corner. However, due to the extra cone on the cone stack at the beginning of autonomous, we were granted a rematch. In the autonomous of the rematch, our preload cone dropped to the side of the tall pole, but we could grab and score one cone on the tall pole, missing the second one. However, it did not fully move into Zone 3, meaning we didn’t get any parking points. Overall, 5 points in auton. In the tele-op and endgame, we scored two cones on the tall poles and one on a medium pole, which equates to 20 points in that section, including six ownership points. Total Points: 29

      Analysis: We need to ensure that our battery does not have too high of a voltage because that causes severe performance impacts. More autonomous tuning is also required to score both cones and properly park. Our light battery also died in the middle of the second match due to low charge, which will need to be taken care of in the future since that can lead to major penalties.

      Match 2: 68 to 63 Loss

      In the autonomous section, our robot performed great and went according to plan, scoring the preload cone and 2 more on the tallest cone and parking, equating to 35 points. However, in the tele-op and endgame, the robot’s issues reared their ugly heads. We did score one cone on a tall cone and one on a medium cone. However, after our opponent took ownership of one of our tall poles, we went for another pole instead of taking it back, and that led to us tipping over as the arm extended, which ended the game for us. We did not incur any penalties but had we scored that cone and taken back our pole, we would have won and gotten to add a perfect autonomous to our tiebreaker points. We ended up scoring 9 points in this section. Total Points: 44

      Analysis: Excellent autonomous performance marred by a tipping issue and sub-par driver performance. The anti-tipping code did not work as intended, and that issue will need to be fixed to allow TauBot to score at its entire range.

      Match 3: 78 to 31 Win

      In the autonomous section, we missed the preload cone and couldn’t grab both the cones on the stack, and we also did not park as our arm and shoulder crossed the border. As a result, we scored 0 points total in this section. In the tele-op and endgame section, we scored a lot better, scoring two cones on the tall poles, one on the medium poles, and two on the short ones. This, including our 15 ownership points, equates to a total of 35 points. Total Points: 35

      Analysis: The autonomous does need tuning to at least park because of the value of autonomous points. Our lack of driver practice is also slightly evident in the time it takes to pick up new cones, but that can be solved through increased gameplay.

      Match 4: 40 to 32 Win

      In the autonomous section, we scored our preload cone on a tall pole, but intense arm oscillation meant we missed the first cone from the stack on drop-off and the second cone from the stack on pickup. We also overshot parking again, bringing our total in this period to 5 points. In the tele-op and endgame section, we scored two cones on the tall poles. So with ownership points, our total in this section was 16 points. We did miss one cone drop-off, though, and our pickups in the substation could have been better as we tipped over a couple of cones during pickup. Total Points: 21

      Analysis: Parking still needed to be tuned, but the cone scoring was a lot more consistent, but still requires a bit more work to achieve consistency. Other than that, improved driver practice will help cycle times and scoring.

      Match 5: 51 to 24 Win

      In the autonomous section, our arm never engaged to go and score our preload, and the robot did park, meaning we scored 20 points in this section. In the tele-op and endgame section, we scored two cones on the tall poles, one cone on the medium poles, and missed three on drop-off. We also scored our beacon, bringing our total point count in this game portion to 30 points. Total Points: 50

      Analysis: Pretty solid match, but the autonomous still needs tuning, and driver practice on cone drop-offs could be better.

      Match 6: 74 to 50 Loss

      In the autonomous section, our robot missed the drop off of 2 cones but parked, bringing the total to 20 points for autonomous. In the tele-op and endgame section, miscommunication with our alliance partner led to them knocking our cones out of the substation and blocking our intake path multiple times. We scored three cones on the tall poles and missed two on drop-off. In the end, we scored the beacon, scoring 30 points in this section. Total Points: 50(we carried)

      Analysis: Communication with our alliance partner was a significant issue in this match. Our alliance partner crossed onto our side and occupied the substation for a while, blocking our human player from placing down cones and blocking our intake path. This led to valuable seconds being wasted.

      Overall, our main issues revolved around autonomous code tuning; although our autonomous performance did improve, poor driver practice we chalk up to fatigue, along with minor tipping and communication issues. However, we plan to understand what happened and solve our problems before the next week’s Tournament.

      Then, for a quick update on TauBot2, parts of the manufacturing and build have begun, and we hope to incorporate at least part of the new design into the robot we bring to the Tournament on the 28th. Currently, parts of the Chassis and UnderArm have been CNC’ed or 3D printed, and assembly has begun.

      Next Steps

      Finish up the design of Tau2 and start manufacturing and assembling it, tuning our autonomous and anti-tipping code, and attempting to get more driver practice in preparation for next week’s Tournament.

      Overview of the past 3 weeks

      27 Jan 2023

      Overview of the past 3 weeks By Anuhya, Aarav, Leo, Vance, Trey, Gabriel, and Georgia

      Task: Recount the developments made to the robot in the past 3 weeks

      The past three weeks have been incredibly eventful, as we try to beat the clock and finish TaBbot: V2. We had a lot of work to do in build and code, since we were putting together an entirely new robot, coding it, and getting it competition-ready for the D&U league tournament on 01/28/2023.

      Build:

      We were making many changes to the design of our robot between TauBot: V1 and TauBot: V2. We had a lot of build and assembly to do, including putting the rest of the UnderArm together, adding it to the robot, CNCing many of the carbon fiber and aluminum components and assembling the new tires. Our 3D printer and CNC were running constantly over the span of the past 3 weeks. We also had to make sure the current iteration of the robot was working properly, so we could perform well at our final league meet and cement our league ranking going into the tournament.

      Leo focused on assembling the UnderArm and attaching it to the robot. The UnderArm was fully designed, CAMed and milled prior to the tournament, but we didn’t get the chance to add it to the robot or test the code. We were still having a problem with the robot tipping over when the Crane was fully extended, so we decided to attach the omni wheels and “chariot” for the UnderArm to the robot, to counterbalance the Crane when it was fully extended. We experimented with it, and this almost completely eradicated our tipping problem. However, while testing it separately from the robot, we got an idea for how the UnderArm would work with the Crane, and how we should begin synchronizing it.

      Because the majority of the new iteration of Taubot is entirely custom parts, designing the robot was all we had the chance to do prior to the tournament. However, we managed to get the basic chassis milled with carbon fiber and a sheet of very thin polycarbonate. We also began assembling parts of the new Shoulder and Turret assembly, but decided to not rush it and use the old assembly with the new chassis of Taubot: V2.

      Before the tournament though, we incorporated the new UnderArm assembly, carbon fiber chassis, and newly-printed TPU wheels with the Shoulder, Turret, and Crane from TauBot in preparation for the upcoming tournament.

      Code:

      On the code side of things, we mainly worked on fine tuning the code for the scoring patterns and feedforward PID. Most new things which we will be adding to our code will be done after we have completely attached the UnderArm to the main body of Taubot: V2, because that is when synchronization will occur.

      Vance updated auton so it would calculate how many points were feasible and go for the highest scoring option after 25 seconds. He also sped up auton, so it wouldn’t take as long to get a cone and score it. The preloaded cone was scored consistently, but grabbing new cones from the conestacks and scoring them was still unreliable.

      When he wasn’t making auton more stable and reliable and working through the scoring patterns, Vance was working on coding the parts of UnderArm which would be independent of the rest of the robot. He added a simulation so it would be possible to test UnderArm off the robot, and changed UnderArm servo calibration. Limits were also added to UnderArm so it wouldn’t continuously loop through itself.

      Next Steps:

      We need to perform well at the Tournament to ensure our advancement. If all goes well there, the next steps would be a Post-Mortem and the continued development of TauBot2 and the portfolio in preparation for either a Semi-Regional or Regionals.

      D&U Tournament Play by Play

      28 Jan 2023

      D&U Tournament Play by Play By Aarav, Anuhya, Gabriel, Leo, Vance, and Trey

      Task: Narrate the events of the D&U Tournament

      Today, Iron Reign and our two sister teams competed in the D&U League Tournament at Woodrow Wilson High School, the culmination of the previous three qualifiers. Overall, we did pretty well, winning both Inspire 1 and Think 2, which means we will be directly advancing to the Regional competition in about a month. There will be a separate blog post about the tournament Post-Mortem, and this post will cover the play-by-play of the matches.

      The robot we brought to the tournament was a mix between TauBot V1 and V2, with the V2’s Chassis and UnderArm and the V1’s Turret, Shoulder, and Crane. Unfortunately, there were some robot performance drop-offs, as we slipped from 5th to 9th in the qualification standings, going 2-4 overall at the tournament.

      Play by Play

      Match 1: 84 to 17 Win

      In autonomous, due to arm wobble, we missed both the preload cone on drop-off and the cone on the stack during pickup. However, the robot was still about to get parking. Then in the tele-op and endgame, our robot scored three cones on the tall pole and one cone on the medium cone. However, rushing during cone drop-offs led to us missing a couple, and a decent amount of time was wasted during intake and arm movements. Finally, we also scored a beacon. Overall, this was a solid match, but there could be improvements. One important thing to note was that the UnderArm almost went into the substation while the human player was inside due to an issue with the distance sensor that regulated chassis length. This is something that we will have to diagnose and fix quickly.

      Match 2: 86 to 48 Loss

      In the autonomous section, our robot almost collided with an opposing robot when attempting to score the preload cone. In the end, we did not score any cones and lost parking when the UnderArm did not fully retract and traveled past the edge of the area. In the tele-op and endgame, our robot scored two cones on the tall poles and one on a medium cone. However, poor gripper positioning on intake led to time-wasting as cones kept getting tipped over, and we missed a low cone on drop-off due to rushing. In addition, the LED battery went out during the match, which could have caused a penalty and is starting to become a recurring issue. Finally, we lost due to the 40 penalty points that we conceded by pointing at the field during gameplay four times, which was a major mistake and should serve as a valuable lesson for the drive team. Overall, this match was messy and a poor showing from both our drive team and robot.

      Match 3: 74 to 33 Loss

      This match did not count toward our ranking since we were filling in. Regardless, we didn’t view this as a throwaway game. In autonomous, the robot got off track when driving toward the tall pole to drop off the preload, meaning the entire autonomous section got thrown off. We didn’t score any points or park at all. Then, in the tele-op and endgame section, a major code malfunction threw off the arm for a while. We missed multiple cone intakes by overshooting the distance, and the arm was frequently caught on the poles. Our human play was also quite sloppy and there were a few times we got close to being called for a penalty for the human player being in the substation at the same time as the robot. In the end, we only scored 1 cone on a tall pole in this section, and luckily this game did not count towards qualification rankings, but it did reveal a code issue that we quickly corrected.

      Match 4: 97 to 18 Loss

      In autonomous, our robot got bumped, missed both cones, and did not park because the arm and shoulder ended up outside the zone. Then, in the tele-op period, quickly into the start of the driver-controlled proportion, the servo wire on our bulb gripper got caught on our alliance partner’s robot. This caused the plate on which the arm was mounted to bend severely and left us out of operation for the rest of the match. Immediately after, we had to switch to the arm and gripper for TauBot2 that we had assembled but not yet attached, and this required slight modifications to the shoulder to allow all the screw holes to align. Thankfully we were able to get it working, but we faced issues later on with the movement of the new gripper limiting our cone intake.

      Match 5: 144 to 74 Loss

      In autonomous, the arm wobble caused our preload to drop short, but we parked. We also accidentally “stabbed” our opponent’s preload cone out of their gripper when they were about to score it. Since this was in autonomous, we were not penalized, but it was quite funny. However, in tele-op and endgame, we missed multiple cone pickups and drop-offs and went for the cone stack instead for intaking at the substation, which was a major tactical blunder and increased our cycle times. We did score two cones on the tall poles and one cone on a small pole that allowed us to break our opponent’s circuit at the very end, but we still lost. Overall not a bad game, but we had a questionable strategy, and the pains of a newly assembled robot did show.

      Match 6: 74 to 66 Win

      This match was a great way to end the qualification matches, as we escaped with a narrow and intense win. Because our left-side start code was broken and our alliance partner heavily preferred standing on the right side, we started our robot on the right and stood on the left, which was quite a novel strategy. It did come with drawbacks, as during the start of tele-op, we wasted valuable seconds crossing the field with our robot. Anyways, in autonomous, major arm wobble led to us missing the preload by a mile, the stack intake code was off, and we did not park. Tele-op and endgame were quite an intense competition, and we scored three cones on the tall poles, including a clutch beacon cone in the last 10 seconds of endgame to win the game. Overall this was a great game, although we still had autonomous issues, and it was a good ending to an overall poor run in qualifications.

      We ended the qualification portion with an overall standing of 9 and a record of 12-3. Thanks to good connections with our fellow teams, we were picked by the 3rd-ranked alliance as their 3rd pick. Therefore, we did not play the 1st match of the semifinal, which we lost, but we did play the 2nd match.

      Semifinal 2 Match 2: 131 to 38 Loss

      In autonomous, the arm wobble led to us missing the preload and the cones from the stack, and we did not park either. Then, during tele-op and endgame, we scored one cone on a tall pole. Unfortunately, though, our alliance partner’s robot tipped over during intake, which led to ou5t gripper getting stuck to their wheel and causing yet another entanglement. This led to the shoulder axle loosening, and the entire subsystem became unusable after the match. This isn’t that bad since we plan to replace that with the new, redesigned Turret, Shoulder, and Arm, but it wasn’t the best way to go out.

      Overall, though, we did okay, considering we were running a new robot with a partially untested subsystem in the UnderArm and still won a few matches and made the semifinals. In the end, though, our portfolio and documentation pulled through as we won Inspire. However, this tournament exposed many flaws and issues in our robot, which will be discussed in the Post-Mortem Blog post, and we will need to fix these issues before Regionals next month.

      D&U League Tournament Post Mortem

      29 Jan 2023

      D&U League Tournament Post Mortem By Anuhya, Georgia, Gabriel, Trey, Vance, Leo, and Aarav

      Task: Discuss the events of our first tournament of the season

      Team 6832, Iron Reign, and our sister teams, Iron Core and Iron Giant had our first tournament to qualify for Regionals or Semi Regionals. Overall, it was an incredible learning experience for our newer members. This was our first opportunity this year to talk to judges and leave a lasting impression with our presentation skills and our robot.

      Strengths:

      • The speed and success with which we replaced the gripper
      • We won Inspire and 2nd place Think so our portfolio was definitely well constructed
      • We did a good job of selling the team's story, its role in the larger ftc community, and how tau is the pinnacle of that story

      Weaknesses:

      • Less emphasis on outreach
      • Distance sensor detected wire, messed with underarm
      • Need new place to mount power switch to make room for underarm
      • Coordinating with alliance partners
        • Collisions were avoidable, high scores more achievable
        • Have to get better at concisely explaining strategy, maybe with a short video
      • Drive Practice: Not enough, excusable since it was a new robot, but not going forward
        • Time to train with multiple drivers for scoring patterns

      Opportunities:

      • UnderArm
      • New Crane which can extend farther
      • A more versatile gripper: Flipper Gripper
      • Prioritize presentation for proper emphasis
      • Mechavator reveal video
      • Taubot Reveal Video
      • Subsystems video
        • Linear slide video
      • STEM Expo
      • Better cable management
      • Reliable UnderArm distance measurement - need ideas
        • Odometry wheels on linear slides
        • Encoder on a spring-powered retractable string (like the ones you would use for an id badge)
        • Tape measure with sensor to read numbers
      • Using sensors for autonomous period and tele-op

      Threats:

      • Robot capability
        • Release the Flipper Gripper - we need to see the dynamics in action, it might not be viable
        • Flipper gripper damping - we need to try different friction materials
        • Bulb gripper wrist - we may need to do active wrist control, which needs to be figured out asap
        • Flipper Gripper elbow - we may need to do active elbow control, which needs to be figured out asap
        • New Crane/Shoulder/Turret - need to avvelerate the build
        • Crane bouncing needs to be fixed on the new system
        • New Crane wiring harness with distance sensor and 3 servos - can't wait for full custom board manufacturing - need prototype
        • New IMU for new Crane (ordered)
        • Nudge stick distance sensor - will it work over the ultra long cable?
        • UnderArm
          • Mount onto robot and get unfold and articulations right
          • Anti-collision code with Crane
          • Better distance sensing and control for chariot extension
          • May need wrist control for conestacks
        • Lasso gripper needs to be tested, might not be viable
          • Make an alternate gripper design for UnderArm, as a fail-over option
        • Sensors
          • Cone and Cone Stack detector
          • Junction pole detector
          • Differential Distance Sensor as alternative to vision
          • Team number labels if LED Panels get rejected
          • Huge amount of drive practice needed
      • Team Composition - will onboarding new members at this time cause confusion and harm productivity?
      • Teams
        • Technic Bots
        • Mark X
        • Technical Difficulties
      • New sponsors and connect opportunities
      • Prep
        • Poor battery planning
          • Missing a multimeter
          • LED panel batteries not charged
          • Batteries not properly labeled
          • LED Switch and battery not properly secure
          • Batteries need to be tested for internal resistance
        • Rank what would be best to talk about, so talk about what benefits our stationary robot
      • Judging
        • Didn't have powerpoint up for initial judge motivate
        • More practice/preparation beforehand
        • Lack of presentation practice and timing(couldn't finish connect and motivate)
        • Don't oversaturate with information/gloss over other parts
        • Lack of people ready for judging panels
        • Lack of enthusiasm
        • Need Cart with display ready to go
        • Practice entering the room with the robot running
        • Practice in-judging Demo
        • Whenever we mention a specific part of subsystem, let judges interact with it
      • Inspection
        • Capstones were too close to being out of sizing - reprint
        • Robot close to out of sizing (Inspector was young, careless, and did not thoroughly check sizing)
        • Missing power switch label and full initialization label (they let us replace it, it was fine)

      Meeting Log 2/3

      03 Feb 2023

      Meeting Log 2/3 By Jai, Aarav, Anuhya, Leo, Trey, Georgia, Vance, Gabriel, Alex, Sol, Tanvi, and David D

      Task: Onboarding New Recruits, Organization, CAM, and Connect

      Today we onboarded most of the new recruits and continued to work on fixing our broken shoulder from the last tournament. We also organized a lot of the RoboDojo and brainstormed more ideas for how we can reach out to professionals to better prepare for the upcoming Regionals competition.

      We welcomed a couple of new recruits from some of our JV sister teams, Iron Giant and Iron Core. Today's new recruits were Alex, David, Jai, Sol, and Tanvi. We helped them get acclimated to the Iron Reign environment and taught them things like how to write blog posts, our organization system, and everything else they need to know to be a contributing member. This came with its own set of changes to the website to include them. Their performance over the few weeks leading up to Regionals will decide future team composition as we prepare to deal with our current seniors graduating.

      As far as TauBot2 build progress, we began CAM (Computer Aided Manufacturing)on the shoulder, which controls the arm and its extension. CAM allows us to create custom pieces to fit our use case effectively. We also made progress on the secondary turret on the UnderArm, which should help increase our intake speed and score more points through a "handshake" between the grippers, although it still remains a daunting task.

      We also organized much of the RoboDojo prepping for Regionals and any future competitions, specifically most of the screws and building materials. This should make building and robot maintenance much easier in the future as TauBot2 is built and developed.

      Finally, we drafted a couple of emails that enabled us to set up calls with professionals. We hope to get some responses so that we can get some expert guidance on how we can improve our robot's code and design, as well as improve our connections with professionals for our portfolio.

      Next Steps

      Our next steps are to continue to teach the new members what they need to do and to continue the assembly of TauBot2 in preparation for Regionals. Additionally, we would like to expand our outreach to both our community and corporations.

      CONNECTing with Professionals at the DISD Stem Expo

      04 Feb 2023

      CONNECTing with Professionals at the DISD Stem Expo By Aarav, Anuhya, Jai, and Georgia

      Task: Explore Possible Connection Opportunities at the DISD STEM Expo

      Today, Iron Reign presented at the DISD Stem Expo in the Kay Bailey Hutchison Convention Center. Here, we both demoed TauBot and hosted a STEM activity for young children which involved building LEGO Mindstorms EV3 robots and then battling them SUMO style in a battle hexagon.

      While this event was a great opportunity to motivate and interact with the community as a form of outreach, with the 100+ STEM exhibits and multitude of universities and corporations, it was an amazing opportunity to connect with professionals in order to receive valuable feedback on our robot.

      Although with the hustle and bustle of the actual EXPO, not much assistance could be received as we also had a booth to manage, but we viewed this as a great time to go around, meet some professionals, build connections, and hopefully schedule future sessions where we could properly present and explain the robot.

      First off, we were able to talk to some students from both the Texas A&M Engineering Program and SMU’s Lyle College of Engineering. Both programs seem quite interested in our robot, we are hoping to be able to get a meeting with a professor and some graduate students in order to present our robot to them, but those are still in the works.

      In terms of corporations, we met a local startup called Strawbees, which focuses on developing STEM Building kits for children. They told us that they could potentially get us in touch with their lead “inventor”, who designed most of the product line. Since these projects incorporate both mechanical, electrical and software components, this could be a great opportunity for us.

      We also were able to talk to representatives from Jacobs, Lenovo and NASA. Jacobs is a local engineering and architecture firm that is headquartered in Dallas, while Lenovo and NASA are both well-known organizations that could provide relevant hardware and software advice.

      Next Steps

      Our next steps will be following up with the people we talked to at the Expo in order to possibly schedule a session where we can interact with professionals, present our robot and receive feedback.

      Dallas ISD Stem Expo

      04 Feb 2023

      Dallas ISD Stem Expo By Sol, Georgia, Tanvi, Jai, David D, Arun, Anuhya, Vance, Trey, Gabriel, Alex, Aarav, Leo, and Krish

      Task: Motivate the community at the DISD Stem Expo

      Today we hosted a booth at the Dallas ISD STEM Expo at the Kay Bailey Hutchinson Convention Center. There, we taught kids coding, introduced them to robotics and the FIRST community, and demonstrated TauBot to the public. Not to mention, we also got some decent driver practice in, which is always a plu. For the coding section, we used LEGO Mindstrosm EV3 Sumo robots to teach kids about block coding and spark interest in robotics and STEM in general. Overall it was a hit and a lot of kids enjoyed the activity.

      At the Sumo Bot portion of our booth, we set a up table with laptops, Sumo EV3 robots, and two sumo rings. We taught kids basic block coding and allowed them to expirement with their code and see how the robots execute their code. They then got to use the robots in Sumo showdowns against each other.

      Alongside our Sumo Robotics station we had an FTC competition field set up, in which we gave kids a demonstration of the Iron Reign, Iron Giant, and Iron Core robots. We allowed the kids to drive them and get firsthand experience with a robot, which they really enjoyed. We also answered a lot of questions about our robot, betterng both our understanding of the robot itself and our presentation skills, which will come in hand at Regionals.

      Our team talked to both parents and children about how to get involved in the FIRST program, explaining how it works and the opportunities it creates, and why we love participating in the FIRST program. We talked about our experiences in robotics, joining the Iron Reign program, and shared personal stories about how we got into robotics. Not only did we share information about our own program, but also how to get into FLL, FTC, FRC, and other robotics programs based on their age and interests.

      Overall, it was quite a rewarding experience and we got to interact with a lot of people of a lot of different ages. We also were able to connect with some professionals in a somewhat limited manner, but there will be a seperate blog post about that coming soon.

      Sudie Academy FLL Team Mentorship

      07 Feb 2023

      Sudie Academy FLL Team Mentorship By Aarav, Georgia, Jai, Arun, Gabriel, and Sol

      Task: Help the Sudie Academy FLL teams prep for Regionals

      Today, Iron Reign attended a meeting with multiple local FLL teams from Sudie L Williams TAG Academy to help them practice their presentation for upcoming Regionals competition.

      The three teams, 43326 The Tin Men, 46425 Electric Spuds, and 51997 Lithium Ions all advanced to the FLL Regional Competition that will be taking place this Saturday, 2/11. To help them prepare for this competition, we hosted a virtual session where they could practice their presentation and a few of our members could listen in and offer feedback.

      Overall, the kids did a really good job, showing us not only their innovate project but effectively describing their robot and hitting all their talking points in regards to iteration and design. They also talked about their core values and how they managed to work efficiently as a team to complete all their objectives. Finally, they managed to do all this while also tying it back to the overall FLL theme of renewable energy.

      However, their presentation still had some things they could iron out and improve on, and our members made sure to constructively point these out. The kids could definitely do a better job of spreading the speaking around, as we felt that occasionally one person would come to dominate the entire thing while the others just stood around silent. They also could prepare more for the core values questions that we asked that sometimes led to an awkward silence. Finally, with all the great technical knowledge the teams had about their robot and their project, we felt that they could do a better job integrating that with the purpose and impact that their project had.

      Overall though, it was great helping out these FLL teams, and there are a lot of good things that they did that could serve as a takeaway for some of the new recruits that joined in our preparation for Regionals.

      Meeting Log 2/10

      10 Feb 2023

      Meeting Log 2/10 By Tanvi, Sol, Gabriel, Trey, and Alex

      Task: Attend to TauBot2 and transfer knowledge to the new recruits

      Today was another day of onboarding recruits. For the next few weeks, along with regional preparation, we will be focused on the transfer of knowledge from seniors to recruits. Today the recruits shadowed the senior Iron Reign members, Trey and Gabriel.

      Gabriel was working on TauBot 2. Trey was working on soldering a new cable harness for the arm. Tanvi shadowed Trey and practiced soldering; Sol shadowed Gabriel and learned the mechanics of previous Reign robots and TauBot while also helping Gabriel work on the UnderArm. 2.

      While learning to solder, Tanvi learned the specific applications of this tool and the different materials used, as well as safety precautions. She practiced soldering with a spare plate and insulated wire. With further practice, she hopes to solidify her skills with this tool. Sol and Gabriel fixed the double motor tester today, and Gabriel reconfigured the Tau 2 UnderArm. Another recruit, Alex, studied the Iron Reign code base to become familiar with it. He hopes to further his coding knowledge by working with Vance.

      Overall we helped the recruits learn skills needed to be efficient on the Iron Reign team, and continud the build of TauBot2 in preperation for Regionals, which is in 2 weeks.

      Next Steps

      We are working to further our recruit's knowledge and to further our progress on TauBot2. Throughout the next few weeks, our recruits will become acclimated to the Reign environment, and this will be crucial for us in order to complete the variety of tasks required to optimally prepare for Regionals. Specifically, we need to begin the code of the UnderArm and observe how the two subsystems interact to ensure that we have adequate control of the robot when it comes time to drive it. We also have to assemble the new Turrent and Shoulder and attach those to the new Chasiss. Finally, Motivate and Connect could always be improved to refine our award-winning ability.

      Meeting Log 2/11

      11 Feb 2023

      Meeting Log 2/11 By Jai, Anuhya, Arun, Sol, David D, Georgia, Vance, Gabriel, Aarav, Alex, Tanvi, Leo, and Krish

      Task: Continue to assemble TauBot2, work on portfolio, and prepare for Regionals

      First off, we began assembling and wiring the UnderArm system. In the process of putting the UnderArm together, we ran into a couple of hurdles. The alignment on our parts was incredibly difficult to get right, and in the process of aligning them, we discovered that one of our servos was stripped. After tons of trial and error, we wired the servos that control the joints of the underarm. This was incredibly exciting because this was the first bit of functional mobility that our UnderArm system would be capable of. We strung the wires for connecting the servos, the new power switch, and the camera wire in a wire sleeve. We color-coded a lot of our wire management so that it's much easier to organize and understand for further replacement and continual maintenence.

      Then, a seperate team worked on assembling the newly designed Shoulder and Turret. Our new Shoulder and Turret are custom-made and improve our robot in many ways. They make our robot lighter through the use of carbon fiber over aluminum. However, this mechanism is very similar to the initial iteration of TauBot. We switched to using an 8mm axle on the shoulder drive because our original shaft was too fragile and would bend under the pressure of the arm. We also worked on sourcing the right-sized bearings for our shoulder. During this meeting, we managed the slip ring wires and attached the slip ring to the carbon fiber base of the turret.

      We also attached the nylon 3D-printed motor mounts for the motors that drive both the angle of the shoulder and the extension of the crane and began assembling the new motors with their required gear ratios. Preliminary work on the linear slide system also began as we 3D-printed the requisite spacers and cut the slides down to their proper length. We hope to have both these redesigned subsystems on TauBot2 as quickly as possible.

      We continued to cut custom carbon fiber parts using our CNC machine, such as our belt tensioner and one of the motor mounts. In the process, we talked a lot of our new recruits through the CNC process and trained them to be proficient in using the CNC. This will help make our work with custom parts much quicker, as more people are capable of doing it. In doing this, we practiced a lot of problem-solving as we learned the hurdles that came with using a CNC machine. One such problem stemmed from the fact that step motors can't retain their positions. This led to the machine constantly losing where it was and slipping, which called for lots and lots of head-scratching and problem-solving.

      Next Steps

      Our next steps are to continue to train our new recruits to help make them more valuable assets to the team. With their help, we want to fully assemble and code the UnderArm system, the new Shoulder and Turret system and the new Crane. Once that's done we'd like to test the code and optimize it with the drive team so that we're ready to go for Regionals.

      A Deep Dive into the Shoulder and UnderArm

      16 Feb 2023

      A Deep Dive into the Shoulder and UnderArm By Aarav, Anuhya, and Krish

      Describe our Implementation of the Shoulder and Turret Subsystems

      With our primary game strategy for this season being to limit our movement around the playing field, the ability to quickly and easily rotate our intake and deposit systems is vital. Additionally, the ability to reach a variety of poles and scoring options is also crucial if we are to remain stationary. This is why we implemented a Turret and Shoulder on both versions of TauBot. This post will be a deep dive into the mechanics of both these subsystems on TauBot2.

      First, let's talk about our Turret, which allows the Crane to move a full 360 degrees independently of the actual differential drivetrain. First off, we have the Slip Ring, a crucial part of the Turret since it allows the Turret to rotate continuously without interfering with the wire runs. Below is a simple breakdown of the new Turret assembly, which consists of turning curricular rings with ball bearings. Inside is a custom Nylon 3D-printed planetary ring used to drive the entire Turret and motorize it.

      Finally, on top is a carbon fiber base plate upon which the entire Shoulder assembly rests. The Turret uses two main motors that synchronously drive its turning motion. The addition of another driving motor is what separates TauBot2 from the one lonely motor driving the TauBot Turret.

      As seen in the image above, near the front, the two TauBot2 turret motors lay horizontally on the carbon fiber cover under the REV channels. These motors use bevel gears to direct power downward towards the turntable and the planetary gear, allowing it to turn twice as fast as its previous iteration.

      On top of the REV channels, we have the entire Shoulder assembly, which is the basis for the Crane and allows our robot to score on various poles of all sizes from one stationary spot on the field. The two main functions of the Shoulder are to rotate the entire Crane up and down, and to power the extension of the linear slide.

      As you can see, the slide extension is controlled by the front motor and a belt drive. A gear ratio and second motor control the rotation. The gear ratio allows one motor to drive the entire elevation process and ensures easier positioning.

      The axle housing the largest gear is also a co-axial joint, allowing it to drive the extension and rotation through two separate systems. The Shoulder uses the shaft as an axle, but the main arm rotation gear pivots freely due to two attached ball bearings. Overall, this allows us to combine multiple responsibilities into one design and save space.

      The motor used for rotation and elevation is assisted by two springs and a custom-designed logarithmic spiral to provide a consistent upward force to counter the force of gravity on the extended Crane, helping to reduce torque.

      And that's a brief overview of the entire Shoulder and Turret system. This is also where our main Control Hub and our webcam are housed on the original version of TauBot. All in all, these two subsystems are crucial to the functionality of our robot and are the results of loads of careful and meticulous design by our team.

      UnderArm Inverse Kinematics

      17 Feb 2023

      UnderArm Inverse Kinematics By Jai, Vance, Alex, Aarav, and Krish

      Task: Implement Inverse Kinematics on the UnderArm

      Inverse kinematics is the process of finding the joint variables needed for a kinematic chain to reach a specified endpoint. In the context of TauBot2, inverse kinematics, or IK is used in the crane and the UnderArm. In this blog post, we'll be focused on the implementation of IK in the UnderArm.

      The goal of this problem was to solve for the angles of the shoulder and the elbow that would get us to a specific field coordinate. Our constants were the end coordinates, the lengths of both segments of our UnderArm, and the starting position of the UnderArm. We already had the turret angle after a simple bearing calculation based on the coordinates of the field target and the UnderArm.

      First, we set up the problem with the appropriate triangles and variables. Initially, we tried to solve the problem with solely right angle trigonometry. After spending a couple hours scratching our heads, we determined that the problem wasn't possible with solely right angle trig. Here's what our initial setup looked like.

      In this image, the target field coordinate is labeled (x, z) and the upper and lower arm lengths are labeled S and L. n is the height of the right triangle formed by the upper arm, a segment of x, and the height of the target. m is the perpendicular line that extends from the target and intersects with n. We solved this problem for θ and θ2, but we solved for them in terms of n and m, which were unsolvable.

      After going back to the drawing board, we attempted another set of equations with the law of sines. More frustration ensued, and we ran into another unsolveable problem.

      Our Current Solution

      Finally, we attempted the equations one more time, this time implementing the law of cosines. The law of cosines allows us to solve for the side lengths of non-right triangles.





      Using this, we set up the triangles one more time.

      Our goals in this problem were to solve for q1 and for α.

      We quickly calculated a hypotenuse from the starting point to the target point with the Pythagorean Theorem. Using the radius and our arm length constants we determined cos(α). All we had to do from there was take the inverse cosine of that same equation, and we'd calculated α. To calculate q1, we had to find q2; and add it to the inverse tangent of our full right triangle's height and width. We calculated q2 using the equation at the very bottom of the image, and we had all of the variables that we needed.



      After we solved for both angles, we sanity checked our values with Desmos using rough estimates of the arm segment lengths. Here's what the implementation looks like in our robot's code.

      Meeting Log 2/17

      17 Feb 2023

      Meeting Log 2/17 By Aarav, Anuhya, Jai, Alex, Tanvi, Georgia, Gabriel, and Krish

      Work on build, code, and presentation in preparation for Regionals next week.

      With the Regional competition coming up quite soon, we needed to get to work finishing up the build for TauBotV2, optimizing the code with new inverse kinematics for the double-jointed UnderArm, finishing up some subsystem blog posts, and practicing and preparing our presentation.

      Presentation:

      With a heavily below-par performance than the Tournament presentation where we skipped the entire Connect and Motivate section, we needed to stress practicing the performance this go around. We condensed the information into quick lines for each slide, but also expanded the overall amount of content to allow us flexibility.

      After that, we got in valuable presentation practice to ensure that we don’t run over the 5-minute mark and miss out on sharing valuable information to the judges. At around a medium-ish pace, we finished the entire presentation in about 4:15. Pretty good, but that does mean that a few more slides of content could be added to maximize the time.

      Build:

      The new shoulder, turret, and linear slides need to be fully assembled and attached to TauBot2. We made the decision to move the entire shoulder assembly up a centimeter because of size restrictions and requirements, which meant we needed to reprint most of the motor mounts for the extension and rotation motors. We also finished assembling together all the linear slides and their carriages.

      Code:

      This is where most of the progress for today was made. Because of the double-jointed nature of the UnderArm crane, we needed new inverse kinematics equations in order to derive the proper angles for both sets of servos. From a given (x,y) point and the constants a1 and a2, which each refer to the length of each section of the crane respectively, we should be able to calculate the requisite servo angles. Through both right triangle trig and the law of cosines, we could find angle ɑ, the angle for the servos mounted by the turret, and angle β, the angle for the servos mounted between the two sections. This should allow us to move the crane to any position we desire simply with a set of coordinates.

      We plugged both equations into Desmos to find the acceptable movement distances for the entire crane and added these calculations to the codebase, although we were not able to test them tonight. This is sort of a brief overview, but there will be a more detailed blog post covering the inverse kinematics of the UnderArm soon.

      Next Steps:

      With Regionals next week, we need to finish the full build of TauBot2 and begin coding the UnderArm so our two “intakes” can work together effectively in union. The UnderArm is still heavily untested, and there is a chance it fails miserably, so we need to start working on ironing out its issues and getting the entire robot to a functional state where it can cycle and score a few cones as intended. Our portfolio still needs to be converted into landscape and additional content added to fill up the vast amounts of empty space that remain. We also need to start working on possibly designing a custom binder out of carbon fiber to house the entire portfolio. With only a week left, we need to start acting now in order to finish everything before Regionals. The presentation is also a little bit low on content and slides, especially for pit interviews and Q&A, so we will be transferring more of the portfolio content to the presentation. To be competitive at Regionals for an award and advancement, we will need to tier documentation, which means sorting out any potential issues and lots of effort and practice. Overall, we made lots of progress, but there is still a lot of work left to be done.

      Meeting Log 2/18

      18 Feb 2023

      Meeting Log 2/18 By Alex, Anuhya, Sol, Gabriel, Aarav, Jai, Leo, David D, Georgia, and Krish

      Task: Regional Prep, Portfolio Development, Underarm Wiring and new Shoulder and Turret Assembly

      To start we began to bring the wiring for the UnderArm through our wiring sleeve. The current UnderArm wiring situation was less than ideal and it needed to be reworked. About half of our UnderArm’s wires were in a wire sleeve and today we added the rest to it. We need a flexible wire sleeve that can collapse in and extend out so the underarm system can extend properly without being limited by the wires and prevent tanglement. This particular design of sleeve with interlocked fibers provides that functionality and with some extra attachment points that were added today it effectively holds the wires in place during UnderArm extension. However, there was a slight mishap with one of the servo wires coming loose from its plastic case, so we had to take a quick detour and fix that, but we were able to fully finish rewiring the UnderArm.

      Currently in terms of our portfolio we have been redesigning the layout to switch from a portrait to landscape orientation to hopefully better present out robot and create some buzz. In addition, we made some additions to the portfolio to increase its thoroughness, detail, and remove extranous blank space. We also made some changes and updates to the TauBot build guide to improve its quality and detail when it gets added to our Engineering Notebook for Regionals. Much of the new Shoulder and Turret assembly was not there, so we added the instructions along with a couple helpful pictures. Finally, we completed many more blog posts to catch the blog up to date in time for the Regional competition.

      In terms of build, we attached our new motor mounts that we printed overnight and are a lot closer to finally finishing the whole Shoulder and Turret assembly, although both axles still require significant work.

      Next Steps

      Our next steps are to continue to train our new recruits to help make them more valuable assets to the team. We also need to finish TauBot build as well as to finish code testing and preparing for Regionals in both presentation and portfolio, as well as start thinking about our Regional booth.

      Meeting Log 2/21

      21 Feb 2023

      Meeting Log 2/21 By Jai, Anuhya, Vance, Leo, Gabriel, and Georgia

      Regionals Prep: Work on Build, Code, and Presentation

      With regionals just 4 days away, we had a lot to work on for TauBot2. Today, we focused on implementing a new Joint class in all of our joints in the UnderArm, soldered wires for the new Shoulder and turret assembly, and continued to wire the robot.

      Code:

      One issue that we had run into before was that whenever our Servos were given angles or positions that they couldn't reach, they would run themselves as fast as they could, often into other parts of the robot, which caused a lot of damage and undid a lot of our progress. Our solution to this was to run the Servos through another Class layer that did all of the calculations for Servo position given a target angle in degrees. Most importantly, it gave us the ability to control the speed of each individual Servo, which would make testing a lot less risky.

      Build:

      We also soldered the wires onto the slip ring and used heat shrinks to hold the wires together. This made it so that the slip ring can rotate, thus giving our robot the ability to rotate. However, the wires were incredibly thin, which led to constant failure in the soldering of the slip rings. After many many tries, however, we were able to finally get the wires fully soldered onto the slip ring. We continued to wire the UnderArm, and used heat shrink to secure wires on the Shoulder and Turret assembly. These were both exciting developments in the build progress of the new Shoulder and Turret assembly of TauBot2.

      Next Steps:

      With Regionals coming up soon, we are making good progress, and we need to continue to build, code, and test the robot, as well as work on our presentation.

      NTX Regionals Play-by-Play

      25 Feb 2023

      NTX Regionals Play-by-Play By Aarav, Anuhya, Jai, Alex, Sol, Georgia, Gabriel, Trey, Vance, Leo, Arun, and Krish

      Review the events of the NTX Regional

      Today, Iron Reign participated at the NTX Regional Championship in Flower Mound. Even with major robot performance issues, we were still able to advance to both the UIL State Championship and the FTC State Championship by winning the Motivate award after a strong presentation and portfolio showing. We ended up with a record of 1-5, which ranked us 39th out of 40th. Obviously, given the late night and lack of planning and preparation, this was partially expected, but there needs to be significant progress made in order for us to remain competitive at State and have a chance to advance to Worlds.

      First, we will review the documentation events, specifically our presentation and our pit interviews. We had a new custom-designed portfolio using a ninja flex hinge, an aluminum body, and a carbon fiber cover, which was definitely unique. Our presentation was a lot smoother and more concise than the Tournament and we were able to impress the judges and involve the entire team. Our pit interviews also went decently well but could have been better, as we accidentally turned down an Innovate panel over time concerns, something that almost cost us an opportunity to meet with them. At the end of the day, our outreach and presentation ability was enough to win Motivate, allowing us to advance on from State.

      Now we will go over the play-by-play for all of our matches, which did not go very well in terms of a robot performance perspective.

      Match 8: 80 to 63 Loss

      In our first match, we did not score any points in autonomous, instead focusing on maneuvering our robot to a spot where it could score optimally and grab cones from the same position. We are able to score one cone on a high pole. Our alliance partner parked and cycled multiple cones, but they received two major penalties for handling multiple cones at once, which led to us losing the overall match. Our robot also did become dysfunctional in the endgame as part of the arm got caught on the nudge stick attachment, preventing us from moving our crane. After the match, we removed the nudge stick guide since we were not using the nudge stick at this competition.

      Match 20: 93 to 10 Loss

      In the next match, we were able to fix the nudge stick problem, but then a massive code issue during gameplay and a minor mechanical issue essentially shut down the robot for the entire game. Our alliance partner also did not show up at all because right before the match, their linear slide broke. This led to one of our worst performances, as we scored 0 points and got 10 from an opponent penalty. Our robot essentially stood there for the majority of the match, unable to move its crane. We later found out that there was a shaft collar issue, which we promptly fixed, but this was quite frustrating and disheartening.

      Match 30: 152 to 63 Loss

      The next match went slightly better, but we still ended up with a loss. Initially, we did not score any autonomous points, and it took a while for us to get into position, which shaved valuable seconds off. We missed 2 high cones for scoring, but our alliance partners were able to score on both the low and the medium poles. We ended up not scoring at all, but this was not due to code or build, we just needed more driver practice. Our opponents were scoring very fast, and our alliance partners’ circuit attempt was not enough to subdue them. They almost even tipped trying to circuit. The loss wasn’t very bad numerically, but it stung that we couldn’t score anything.

      Match 38: 152 to 63 Win

      In the next match, we just parked for autonomous. Our alliance scored two high cones and parked as well. During the driver-controlled section, we had a problem with the robot and had to reinitialize the robot, while our partners cycled. While our partners fought for possessions, we managed to score 1 cone on the middle pole and got our element on a cone for the low pole. At the end of the day, we won the match comfortably, mainly due to the efforts of our partner alliance.

      Match 48: 171 to 138 loss

      In our 5th match, our autonomous ran, but we stumbled over a ground junction during parking, so we weren’t lined up. For TeleOp, we had to spend lots of time getting in position, but we scored on a middle and tall pole. For one cone, we tried to score while the opponent was already trying to score on it, resulting in a penalty. We got another penalty because our gripper flipped and wrapped on a pole, which was deemed a major penalty. There was, though, a penalty on the other team for moving the cone stack during their intake. After all the penalties were determined, we lost the match, which was unlucky, but the gripper issue will be something we look into.

      Match 55: 112 to 68 loss

      For our last match of the day, we managed to get positioned for scoring during autonomous, but missed by a hair, then parked along with our partners. Our opponents scored up to three high cones and double parked. During TeleOp, we once again spent considerable time positioning ourselves. While our partner struggled to score, we scored one cone on the nearest high pole and scored on a different high pole for spread possession. We missed a 3rd high cone but scored a cap on an opponent-possesed pole during the endgame. We even had penalty points from an opposition penalty.

      Our poor time management was seen in our lackluster robot performance, but our portfolio and outreach was enough to advance us to State. We hope to use the 4 weeks we have gained to finish our robot design and code, while also expanding our connections with professionals and outreach in general.

      NTX Regionals Post-Mortem

      27 Feb 2023

      NTX Regionals Post-Mortem By Aarav, Anuhya, Georgia, Gabriel, Trey, Vance, Alex, Krish, and Jai

      Discuss the events of Regionals, analyze our performance, and prepare future plans

      This past Saturday, team 6832 Iron Reign participated in the NTX Regionals Championship at Marcus High School. Overall, despite some robot performance issues, we won the Motivate award, meaning we advanced to both the UIL State Championship and FTC State Championship. Today, 2 days after the competition, we had our Regionals Post-Mortem, and below are our main strengths, weaknesses, potential opportunities, and threats.

      Strengths:

      • Motivate game was quite strong -> Figure of 1500 kids at two outreach events was quite impactful
      • Presentation
        • Should work on arrangement of members, some were off to the side and couldn’t do their slides -> Potentially utilize CartBot and a monitor
      • Meeting with judges went generally pretty well
      • Portfolio is quite well constructed and unique
        • Well-practiced portfolio/presentation team(lots of improvement from last time)
      • Shoulder of the robot was strong
        • Rails were bending; tension too tight.
      • Switching to carbon fiber resulted in a far stronger robot that did not crack
      • Turret was much more capable of moving the extended crane
        • Even worked well in fast mode -> probably could increase the speed of our articulations

      Weaknesses:

      • The need to sleep
      • Team burnout
      • Significant under planning
      • Entanglement of springy cable on junctions during auton
        • Arm does wide arcs sometimes, articulations not working half the time
      • Lack of driving practice
      • Cone placement accuracy
      • Navigation to final position speed
      • Connect game compared to other top teams
      • Turning down an Innovate panel
      • Robot Demo in judging
      • No reliable auton
        • If auton goes bad, effects extend into tele-op. The dependence is nice when auton is working but a hindrance when it needs to work.
      • No reliable wheels that rotate straight which messes up auton
        • Underarm wheels not working well and the cable management is still out of wack
      • Placement of certain components on the robot
      • Should have made it more clear to new recruits that this was crunch time and expectations for attendance are way up
      • Coordination in pre competition prep
      • Our funding situation is really bad. We are way over extended on deficit and Mr. V is not putting more money in

      Opportunities:

      • Booth at the pits with detailed banners
      • Good robot == good judging
        • Completing the robot puts us in the running for more technical awards
      • Build Freeze
      • A fully functioning robot with the transfer that can win matches would put us in Inspire contention somewhat
        • Synchronization with transfer would be impressive in a control sense as well
      • Strengthening our motivate outreach
      • Spring Break
      • A larger team to better spread the workload leading up to State
      • Curved Nudge hook
      • Drive practice
        • Need more on the left side. We are becoming a liability for our partners to side limitations in terms of driver practice.
      • Code Testing
      • Maintenance for parts that were previously underdone/not to our standards
      • Live robot demo
      • Time to improve our connect game
      • Judges for control award wanted to see more sensors
        • Nudgestick + cone gripper
      • Mechavator Reveal
      • Cart Bot
      • Matching shirts and hats

      Threats:

      • Our Connect game is significantly weaker than the competition
      • Technic Bots won Inspire twice
        • They had good outreach as well
        • They also have an underarm & it is very much working well
      • We have 3 weeks to code an entire robot
      • 9 advance from state to worlds so we cannot rely on Motivate again, we need a stronger award, also most likely cannot just place 2nd for any award so Think Winner should be our absolute minimum goal or Inspire 3r
      • Mr. V unavailable for a number of days leading up to State

      Meeting with the Head of the Dallas College STEM Institute

      28 Feb 2023

      Meeting with the Head of the Dallas College STEM Institute By Aarav, Anuhya, Georgia, Arun, Jai, Krish, Trey, Vance, Leo, and Gabriel

      Task: Meet with the Dallas College STEM Institute

      Today, team 6832 met with Jason Treadway, Head of the Dallas College STEM Institute and a former structural engineer. We virtually presented our robot and outreach efforts and were able to both intrigue him and received important input from him.

      Overall, Mr. Treadway was quite impressed with our presentation, robot, and efforts to not just “design for ourselves,” but also educate the community on robotics. He was a large fan of the recruitment pipeline we established with Dealey Robotics and our 2 JV teams.

      In terms of advice on the presentation, he suggested that we focus on adapting our images to help better highlight the differences between V1 and V2, possibly a side-by-side comparison that would appeal to visual learners and help them better see the evolution. He also found some of the diagrams of the drivetrain potentially confusing, and stated that adding dimensions and more detail would make them clearer and add a point of reference.

      Finally, we discussed our outreach and motivate efforts, and Mr. Treadway asked about how we found out about outreach opportunities. As a team, we definitely do a lot of networking and make an effort to talk to people and build strong relationships. We also have mentor connections, utilize cold emails, and personal connections that we do our best to take advantage of. We were also advised to follow up with our Waymo connection and possibly get a tour of their local Dallas location.

      Mr. Treadway also offered us a possible later connection opportunity, where we could come to the Dallas College Brookhaven campus to present our robot to college students in early April. Overall, it was a very informative session and we would like to thank Mr. Treadway for his time and advice, and we will definitely take it into account as we head to State.

      Meeting Log 3/3

      03 Mar 2023

      Meeting Log 3/3 By Jai, Anuhya, Aarav, Alex, Tanvi, Georgia, Gabriel, Sol, Trey, Krish, Arun, Vance, and Leo

      Task: Plan and strategize for the Road to State

      Finally back from a much-needed break after regionals, the team got back together for a more strategy-focused meeting, and we did some preliminary work on code, build, and portfolio.

      Planning:

      To help us use our time efficiently, we focused the first couple hours of the meeting on planning. We created a spreadsheet with tasks, task descriptions, and deadlines. Learning from our experience at regionals, we decided to have a build freeze two weeks from the state tournament to make sure that our coders have enough time to fully integrate our new subsystems. With Spring Break coming up, we created a Doodle to help us find the best times to meet.

      Code:

      The main code task for today was creating collision detection for the UnderArm and the main Crane. This would add another layer of safety to make sure that our robot doesn't hit itself while it's controlled by Inverse Kinematics. We initially started by creating a line of no pass halfway between the main chassis and the chariot. We then realized that we needed more maneuverability with the UnderArm, so we created a box of no pass instead. We did this by checking if the field coordinates at the end of the UnderArm were outside the coordinates of a virtual box that we drew around the UnderArm. We also planned for the rest of the code that needs to get done before state.

      Connect and Outreach:

      For Connect and Outreach, we started with drafting grant applications. We need more funding to keep building the robot and attending the tournaments, and this was our first step toward acquiring some. After this, we reached out to some companies that we had connections with as a team. We talked to some people that were close with our team members so that we could get to them before state. We also emailed and contacted some newer companies with a connection to STEM.

      Build:

      On the build side of things, we reattached the UnderArm. We also tested new gear ratio motor speeds to find the most efficient one for our robot. We made more progress on the wiring harness for the crane and we created a couple of new custom pieces to help implement it. We also came up with a possible new solution to stagger the movement of each stage of our slide to improve predictability.

      Next Steps:

      Now that we have a clear plan and we've gotten some good work done already, it's just a matter of executing and polishing on the road to state.

      UIL and State Play-by-Play

      26 Mar 2023

      UIL and State Play-by-Play By Aarav, Anuhya, Jai, Alex, Tanvi, Georgia, Gabriel, Trey, Vance, Leo, Arun, and Krish

      Review the events of the UIL and FTC State Championships

      This past week we participated in the FTC state championship and UIL state competition in Belton, Texas. Overall, we were successful, winning the Think Award at State and thus advancing to Worlds despite less-than-ideal robot performance. First, we will discuss judging and then transition into our game-by-game account. There will also be a post-mortem that will be uploaded later.

      Regarding judging, all of it was done the week before the competition remotely. This meant we had to ensure that we remained on schedule because robot demonstrations are essential to virtual judging. Unfortunately, we could not show a live transfer, but we did have embedded videos depicting our robot’s functionality. Our main presentation and callbacks went well despite a few mishaps, especially regarding the key points we wanted to hit. Overall though, we were able to show our innovation and iteration processes and how TauBot connected with our game strategy and our team’s story as a whole.

      As for gameplay at both events, it did not go as smoothly as we would have liked. We did face some trouble during sizing but managed to get the robot to fit. Here is a game-by-game account of each of our matches. Overall we went 1-11 and managed to transfer and score 3 times in total across both days. Some key notes to mention were that we did not have a working autonomous at all and thus did not run one in any of our matches.

      Texas UIL

      Match 4: 60 - 47 Loss

      In the autonomous period, our robot did not move at all. During the teleop period, our robot hit one cone out of the substation, scored one cone, knocked another cone down, and grabbed the cone in intake, but the transfer didn’t work, and during the endgame, we were not able to score our beacon.

      Match 7: 181 - 73 Loss

      During the autonomous period, our robot did not move at all. In the teleop period, we had issues controlling UnderArm and determined that our driver synchronization needed to be worked on. In addition, our Crane was acting glitchy, and our flipper gripper wasn’t working. In the endgame, our robot was completely stationary the whole time.

      Match 16: 251 - 75 Loss

      During the autonomous period, our robot did not move at all. In the teleop period, we picked up a cone, put it back down, picked up a cone, and dropped it. During the endgame, the transfer worked, and we scored a cone. Some additional notes we took include that while transfer worked, it was inconsistent and slow (15-20 seconds for transfer, not including scoring).

      Match 25: 144 - 20 Loss

      During the autonomous period, our robot did not move at all. During teleop, our Crane was glitching again, and our UnderArm picked up a cone, but the Crane dropped it while trying to deposit it. Our Crane kept glitching in the endgame, but UnderArm worked to some degree.

      Match 29: 171 - 83 Loss

      During the autonomous period, our robot did not move at all. During teleop, our UnderArm struggled to pick up cones more than usual, and the transfer messed up. During the endgame, the robot demonstrated the same behavior as in teleop.

      Match 34: 107 - 55 Loss

      During the autonomous period, our robot did not move at all. During teleop, something went wrong in the shoulder of the UnderArm, and the robot stopped operating. During the endgame, the robot was stuck and couldn’t move due to the prior issue.

      FTC State Championship

      Match 9: 226 - 97 Loss

      During the autonomous period, our robot did not move at all. During the teleop, we lost 20 points in penalties (our side). Our alliance partner wouldn’t let us go to the substation for cones, but we picked up a cone from the ground and scored. We picked a cone up from the substation, but the transfer didn’t work. During the endgame, we were not able to score our beacon..

      Match 18: 280 - 29 Loss

      During the autonomous period, our robot did not move at all. During teleop, the robot took long to recalibrate and transfer and couldn’t fully grab a cone. During the endgame, the turret started rotating. One thing to note was that referees said our sizing wasn’t proper (even though it was). We had to turn our robot 45 degrees, which contributed to the late start of recalibrating, which we later challenged but did not amount to anything.

      Match 26: 110 - 97 Loss

      During the autonomous period, our robot did not move at all. During teleop, we picked up a cone, the transfer worked, and a cone was scored; a cone got stuck but was transferred after a cancellation, and we scored a cone. During the endgame, the Crane got stuck on a pole.

      Match 32: 111 - 79 Loss

      During the autonomous period, our robot did not move at all. During teleop, we picked up a cone, but the transfer didn’t work, and this happened multiple times. We pulled from the cone stack during the endgame, but it didn’t land on the pole when we deposited them.

      Match 39: 242 - 165 Loss

      During the autonomous period, our robot did not move at all. During teleop, the robot wasn’t moving; it was completely stuck. However, during the endgame, the robot was still stuck in position. Some things to note are that we queued late and didn’t have time to run the full calibrate sequence and ended up stopping to stop the robot from breaking itself. We also started without calibration because we were told we would incur penalties. This is definitely something we can improve on.

      Match 48: 144 - 88 Win

      During the autonomous period, our robot did not move at all. During teleop, the robot got into position, grabbed a cone, and hyperextended the wrist, so we switched to using the Crane as both intake and depositing. Unfortunately, during the endgame, we couldn’t get the beacon. One thing to note is that the wrist went limp and couldn’t be corrected through manual control.

      Even though TauBot was not up to par, we hope to spend the next 4 weeks fine-tuning it and truly turning it into a Worlds-level robot. More information on our takeaways and future plans will be discussed in our post-mortem, but we made it to Worlds at the end of the day.

      Texas State and UIL Championship Post-Mortem

      28 Mar 2023

      Texas State and UIL Championship Post-Mortem By Aarav, Anuhya, Georgia, Gabriel, Trey, Leo, Vance, Alex, Krish, Jai, and Tanvi

      Discuss the events of Regionals, analyze our performance, and prepare future plans

      This weekend, Iron Reign participated in the FTC UIL Championship, which was mainly robot game, and the FTC Texas State tournament, where we advanced to FTC Worlds with the Think award, an award granted for the engineering portfolio and documentation. We learned a lot from our gameplay and communications with our alliance partners, and got the chance to see our robot in action properly for the first time. This is our analysis of our main strengths, weaknesses, and future opportunities and threats we will have to deal with before competing at Worlds.

      Strengths:

      • fast maintenance when things went wrong, both build and code related
      • sticking to our own strategy
      • being able to access all the junctions/ cover a lot of ground
      • communication with alliances
        • not being a hindrance to our alliance partners

      Weaknesses:

      • penalties for wrapping around poles and extending out of field
      • long time required to recalibrate if setting up goes wrong
      • no consistent gameplay
      • turret movement is very choppy
      • lack of time to modify UnderArm
      • less time for testing because of complicated design
      • cone gets dropped, especially during transfer

      Opportunities:

      • further optimizing transfer and transfer speed
      • working on auton parking and cone scoring with transfer
      • automating transfer
      • we will have time to further finetune the robot

      Threats:

      • Nudge Stick is still a hindrance to game play
      • lack of drive practice because design was prioritized
      • robot pushes itself past what is mechanically possible
      • robot relies on calibration, which isn't convenient

      Meeting Log 4/1

      01 Apr 2023

      Meeting Log 4/1 By Sol, Georgia, Trey, Anuhya, Gabriel, Leo, Krish, Tanvi, Jai, Vance, Alex, and Aarav

      Task: Gripper Redesign and Build Fixes

      Trey redesigned the gripper stopper on the underarm to limit the degrees of movement so that the underarm gripper will not get stuck. The original design of the gripper stopper did not fully stop the gripper because it did not limit the gripper's movement as much as we wanted it to.

      The tensioning belt on the shoulder attached to the crane became too lose, and started skipping at lot, so Krish and Georgia re-tensioned it again by moving the motor on the turntable farther away from the other.

      The omni wheels on the bottom of the underarm kept breaking, so we replaced them, and worked on ideas about how to stop breaking the wheels. We figured out what was happening was that there was so much pressure being put on the wheels that the spokes for the small wheels kept falling out of the seams. The problem with this was that the wheels would damage the field, and the underarm wouldn't smoothly move across the field. To solve this problem, we melted the plastic so that the seams were no longer open and the spokes wouldn't be able to fall out.

      Our code team continued to tune and debug autonomous, while our build team asynchronously worked on the robot. Later, Georgie and Tanvi worked on pit design for Worlds. They designed the pit and figured out how much it would cost. After deciding on what materials we would need, they reached out to companies to ask about sponsorships. In addition, we worked on updating our portfolio and designing banners for Worlds.

      Next Steps:

      Our next steps are to continue tuning code, more drive practice, and finish pit design.

      Meeting Log 4/9

      09 Apr 2023

      Meeting Log 4/9 By Georgia, Sol, Trey, and Leo

      Task: Prepare for Worlds through Build and Drive

      Today, we did drive practice, and worked out some of the smaller issues with transfer.

      While doing robot testing, the servo on the underarm shoulder joint broke. We took apart the joint in order to fix the servo, but the servo's gearbox was not accessible, rendering us unable to diagnose the problem, so we had to replace the old servo with a new one.

      Trey redesigned a new transfer plate bridge, then milled it on the CNC. While milling this piece, we pushed the CNC too much, causing a drill bit to break. After that, we cut the part again, but the cutouts got caught between the drillbit and the plate, causing the CNC to crash. Twice. Eventually, we fixed the issues, and successfully cut out the new transfer plate bridge.

      By the end of the meeting, we had successfully tested underarm.

      Next Steps:

      Our next steps are to finish making transfer work, remove the shoulder support spring, get more drive practice, and prepare for State and UIL.

      Consequences of Removing the Shoulder Support Spring

      11 Apr 2023

      Consequences of Removing the Shoulder Support Spring By Anuhya, Trey, Leo, Gabriel, and Vance

      We learned the consequences of making small changes to build without fully knowing the outcome

      A small change can make a huge difference: we have learned that we really should have put the shoulder spring back in place after we rebuilt Taubot. The Crane arm fails to maintain its shoulder angle, and this is an issue which has only started since we built Tau2. We're probably hitting the thermal cutoff for the motor port, which causes the control hub to stop sending power to the shoulder motor and the whole arm crashes to the ground.

      This also means that its stalling the motor and it pulls a huge amount of Amps. We also have horrendous battery management, which leads to short battery life and permanent battery damage. The Crane being held out fully extended further damages it.

      A lot of Tau2 is an inherited, yet modified, design. We aren't fully aware of the considerations that caused a spring to be in Tombot, the original robot we based part of our design on. We also changed the gear ratio of the shoulder motor so we could power through lifting the shoulder at extremes, and we're pulling many more electrons to compensate for something which was built-in initially.

      The original reason was a design goal - whenever you make an arm, you want as little motor force as possible dedicated to maintain the arm against gravity. The motor should just have been changing the position, not maintaining it. Real world cranes use counterweights or hydraulics to fix this problem, something which we don't conveniently have access to.

      The spring was meant to reduce the burden of maintaining the crane's weight against gravity. It wasn't perfect by a long shot, but it definitely did help. Our batteries would also last longer in matches and have a longer life.

      Thankfully, we still have access to the original CAM we used for the log spiral, and a spring could easily be reintroduced into our robot if we messed with some of the wires. It's a high priority and needs to be done as soon as possible.

      However, hardware changes like these are incredibly annoying for coders. We recently added a custom transfer plate too, and it was very helpful to increase transfer efficiency. It also changed the angle of the initial transfer plate to the flipper gripper, which added 3 hours of extra coding time to retune transfer and grasping the cones so it didn't get knocked off. It will be better once fully tuned, but it doesn't change the fact that small changes in physical build are incredibly annoying for the coding team. Adding the shoulder support spring will also have this kind of cost, but it's crucial for further success.

      Scrimmage Before Worlds

      15 Apr 2023

      Scrimmage Before Worlds By Anuhya, Jai, Alex, Trey, Gabriel, Vance, and Leo

      Attending a Final Scrimmage Before Worlds

      Today, we attended a scrimmage that team 8565, Technic Bots, graciously invited us to. The point of this scrimmage was to get some time seeing the changes which the other Worlds-advancing NTX teams had implemented, and to get some ideas of strategies and alliances. This was the first time we were able to get proper driver practice with the newly designed Transfer Plate and Nudge Stick.

      One of the main problems we experienced was our cable harnesses malfunctioning. The servos kept getting unplugged or the signals just weren't sending properly, which was a large issue. This meant that our Gripper Flipper assembly wouldn't flip into place, so the cones which the UnderArm was depositing onto the Transfer Plate would remain on the Transfer Plate and act as a hindrance. This also increased the chances of double cone handling, which is a major penalty. The Bulb Gripper was unable to get cones off the Transfer Plate because the servo which controlled the Gripper Flipper wasn't working. However, we learned that UnderArm to Transfer Plate mechanisms worked incredibly effectively and consistently.

      We also learned an important lesson about calibration; without realizing there would be consequences, we started calibration of our robot with the robot in the starting position, against the walls of the playing field. During calibration, the Turret does a full 360, during which the nudge stick kept hitting the walls of the playing field, causing one end to completely snap off at the joint which connected the REV channel to the nylon.

      The scrimmage also gave us a chance to work on auton. During our autonomous drive, we use a timer separate from the one on the driver station to make sure that we can complete or abort our auton safely before the driver station timer kills power to our robot. In our auton testing, we found that this time-management system was not properly iterating through the stages of our autonomous. To solve this, we reviewed and edited our code to work with our timer system and performed repeated trials of our autonomous system to ensure reliability. Once we fixed these bugs, we had the chance to begin working on improving the accuracy of our parking procedure. Our parking procedure hadn't been modified for our new cone-stack-dependent autonomous strategy, so we changed the code to account for it. We are now well on the way to a consistently performing autonomous mode.

      Next Steps:

      We will continue working on building and code, especially auton. We need to make sure that our Nudge Stick works in practice, and we need to make sure our drivers get time to get used to having a Nudge Stick to control. Overall, we need drive practice, and we need to make parking and getting cones from cone stack consistent in our autonomous period.

      FTC World Championship 2023

      25 Apr 2023

      FTC World Championship 2023 By Anuhya, Jai, Alex, Trey, Gabriel, Vance, Leo, Tanvi, Georgia, Krish, Arun, Aarav, and Sol

      Our Experience This Year at Worlds

      Over this past week, we had our final preparations for the FTC Worlds Championship in Houston, Texas, which was our final destination after everything we’d done this season. This Championship was an incredible opportunity for us to interact with teams from around the world, and establish relationships with teams we never would have been able to meet otherwise. It was an incredible outreach opportunity, where we talked to teams from Romania, India, Libya, and other countries with different approaches to how we did robotics. At the Regional Edison Awards, we won 2nd place Motivate!

      What was productive at worlds?

      The build of the robot was much closer to being done than it had been at previous tournaments. We were also relatively confident in the capabilities of our transfer system, especially with the implementation of the Transfer Plate. We were also prepared with replacement parts fully made and manufactured, so we knew we would be able to replace the UnderArm if something went wrong with one of the arms.

      What was beneficial to our team?

      The time and effort we put into our portfolio as a team was definitely one of our strongest points. We were prepared for how to interact with judges, and we had also practiced our answers to some possible questions we could get. By showing the judges how our team was set up and the true nature of our compatibility and cooperation, we were able to leave a lasting impression.

      We also had a pit design which was made to help our productivity, with shelving to organize our tools and supplies, tables set aside for different purposes and stools to maximize space within the tent. It also helped us convey a good team image to the other teams who were present at Worlds, and gave us a place to talk about our robot design and game strategy. The posters which were put up in our pit were also very effective, because they were great conversation starters. Teams were very interested in seeing our robot design and getting an explanation for some of our decisions when they saw the engineering banners which were put up at eye level.

      How do we want to improve?

      One large issue that we had throughout the entire season was our robot was never fully prepared when it was time for the tournament. We didn’t have the opportunity to have driver practice throughout the season, especially with the new robot and the new design, so we found a lot of issues at the actual Worlds Championship that we should have found and fixed way earlier. We also burnt out many of our axon servos at the tournament, and scrambling to find more because they were the basis of our UnderArm was not a good look for the team. One of our primary goals for next year will definitely be finishing the robot on time, so our drivers have a good opportunity to get drive practice. At the Championship, we also barely passed inspection. Because we didn’t have enough time to ensure that our robot fit under sizing when it was initialized, we had to get inspected a second time. Overall, we want to make sure that we are fully prepared for all tournament procedures in the upcoming season, so we don’t have as much of an issue during the actual tournament.

      Our packing and organization also left something to be desired, because we didn’t start packing until 1 or 2 days before the tournament. While our pit design was effective, we didn’t have a chance to practice it beforehand, and we could have made some design changes and improvements if we had practiced it prior to the tournament. Even though we had shelves, it took us 20 to 30 minutes to find tools and that was incredibly frustrating when we were in a time crunch.

      Something else we were lacking in was communication between different subteams. One of our largest problems was that the coders weren’t given enough time to work on the robot because the modelers and builders weren’t entirely sure about when prototypes would be available. We also sacrificed a lot of sleep because we weren’t ready to compete when tournaments came around, and it wasn’t sustainable throughout the year and led to a lot of burnout. Our morale was also low because of deadlines and not having a sustainable work ethic.

      Next Step:

      The next season started the day Power Play ended. Over the summer, we have plans to start recruitment and outreach early, and set up boot camps to get the new members of our team more specialized and ready for the next season. We also wanted to get the MXP up and running, so we would have more mobile opportunities to teach kids how to code and use 3D printers and just set up more outreach events. We’ve also started setting up organization softwares and setting up different team roles to maximize organization in the following seasons.

      How To Get Your Daughter (or Son) Started in Robotics

      21 Jul 2023

      How To Get Your Daughter (or Son) Started in Robotics By Anuhya

      FIRST Robotics is an incredible opportunity for kids of all ages to get involved in STEM! It starts with FIRST Lego League (FLL), which uses LEGO robots to teach kids the basics of robotics and STEM-based activities. FLL has 3 levels for different age ranges.

      FIRST Lego League Discover: Grades PreK - 1: This is the introductory level of FLL, which introduces kids to robotics using LEGO® DUPLO® bricks.
      FIRST Lego League Explore: Grades 2 - 4: This is the second level of FLL, which introduces kids to solving real-world problems using engineering and logical thinking skills.
      FIRST Lego League Challenge: Grades 4 - 8: The third level of FLL is competitive, and teams of kids learn how to program and design a LEGO robot to navigate a robot game and engage with other teams.

      For older kids, such as middle and high school students, they can participate in the FIRST Tech Challenge, or FTC, and FIRST Robotics Challenge, or FRC.

      FIRST Tech Challenge: Grades 7 - 12: Students design, build, program and drive robots to navigate a robot game and beat their opponents. They learn important time management, problem solving and teamwork skills while participating in friendly competition. In FTC, they also uphold FIRST's core value, Gracious Professionalism, where kids learn how to compete but maintain good relationships with their opponents.

      FIRST Robotics Challenge: Grades 9 - 12: Students work alongside engineering mentors to create robots under strict guidelines. FRC is meant to be similar to the real-world engineering environment, where students must find funding, resources and ideas by themselves, and create a robot which can compete in a difficult robot game against opponents.

      What Steps Should I Take?

      • Talk to your principal and PTA to see if your school has pre-existing robotics opportunities. If not, you can start a team yourself! You can create robotics opportunities within your school or community through FIRST! Click the following links to find out how to start an FLL team, FTC team or FRC team.
      • Sign up to talk with coaches and other parents through the North Texas FLL google group
      • For middle and high school students, sign up with the North Texas FTC google group

      Frontiers of Flight Moon Day Outreach

      22 Jul 2023

      Frontiers of Flight Moon Day Outreach By Aarav, Anuhya, Georgia, Jai, Tanvi, Leo, Arun, Sol, Alex, Paul, Ben B, and Bhanaviya

      Today, Iron Reign presented at the 15th annual Frontiers of Flight Museum “Moon Day” celebration, meant to honor the anniversary of the first moon landing in 1969. There were around 1,150 attendees, many of whom were kids. There, we hosted demos of both TauBot and our sister team, Iron Giant’s competition robot, and engaged with child attendees in LEGO Mindstorms programming activities in order to promote STEM and FIRST.

      We taught kids the basics of block programming as they coded the basic Mindstorms robot to fight in the round “Sumo” circle. They used a color sensor to detect the black tape and stay within the circle as they battled each other’s robots. Afterward, they could experiment with the software and use their creativity to code whatever functions they wanted. We also introduced FIRST to them and their parents, how they can get involved in organizations such as FLL, and information about Iron Reign. We assembled a guide on getting your child into FIRST and posted it to this blog, which we shared at the event.

      Additionally, we set up an entire game field to demo our robots and allow attendees to drive around Iron Giant’s robot. Many kids enjoyed driving around, scoring cones, and watching TauBot’s transfer. Along the way, we answered questions about our robot design and implementation and were able to talk to many adults in related fields about our work.

      Finally, we had CartBot and the air cannons, which drove around the Museum, bringing joy to guests’ faces. Participants could “feed” the canon and watch as a Coca-Cola can be launched. Everyone had lots of fun catching the cans and even driving CartBot themselves.

      Overall, presenting the museum for Moon Day was a major success and extremely fulfilling. For all the Iron Reign members, giving back to the community and sharing our love for robotics is a significant part of why we do FTC, and we are grateful for the ability to do so on a yearly basis.

      Recruiting at Flight School

      08 Aug 2023

      Recruiting at Flight School By Aarav, Anuhya, Tanvi, Jai, and Georgia

      Task: Recruit new members at the TAG Flight School

      Today, Iron Reign presented at TAG’s Flight School in order to recruit new members in preparation for the upcoming season to fill out our sister teams, Iron Core and Iron Giant. There was a quick recruitment presentation and a demonstration of basic REV components for interested freshmen. The idea was to generate hype and interest in order to ensure attendance at a more in-depth meeting later during the school year with more logistical information and a live demo of TauBot. Efforts like this are important to ensure the sustainability of the Iron Reign program to help replace our members who graduate with ones who already have FTC experience through our sister teams.

      Next Steps

      Host a more in-depth informational meeting with a live demo of TauBot and a meeting at our workspace. Additionally, recruitment efforts aimed at SEM students are also a significant priority.

      Iron Reign’s R2V2 - Safety Features and Protocols

      11 Aug 2023

      Iron Reign’s R2V2 - Safety Features and Protocols By Coach

      Let's robotify this!

      What if you took an RV, converted it into a mobile learning lab, and then turned that into a droid? What would you call it? We call it R2V2

      Intrinsic Hazards and Safeties
      Primary Safety
      Backup Safety
      Site Safety
      Operational Safety

      Intrinsic Hazards and Safeties

      Intrinsic Hazards

      It’s important to keep in mind that our mobile learning lab is based on a Class A motorhome chassis. As such it weighs on the order of 16 tons and represents a real danger with any kind of untrained operation. There is no place for any lack of vigilance and caution for safely operating this vehicle.

      Intrinsic Safety

      R2V2 has multiple emergency stop overrides and we employ them redundantly in fail-safe modes. The only intrinsic safety lies in the reliable slow motion of the vehicle with max speed under normal human control. The engine will only be run at idle speed and the PSO will only apply acceleration if needed to get the vehicle moving at a walking pace ground travel speed. The acceleration pedal is not automated. People in the test zone will still need to maintain safe distances. Therefore, we have established Operational Safety and Site Safety protocols.

      Primary Safety Operator

      The Primary Safety Operator (PSO) is our coach, who is the owner and operator of the vehicle and who will always be behind the wheel while the vehicle's engine is on. Only he has the authority to start the engine and operate the gear shifter. He also has the ability to physically override the primary brake and independently operate the parking brake. He is the only one able to apply any force to the accelerator via normal foot control. He is also able to kill power to the whole control system, thereby engaging passive braking and locking the steering.

      Remote Safety Operator

      The remote safety operator will be a student trained and solely assigned the task of the ensuring safe operations from the outside. Their mandate is to stop the vehicle if they see anything wrong. Their interface is a normal gamepad where they have only two controls, either of which will stop the vehicle. The left trigger is configured as a deadman switch and has to be held in order for unbraking (and therefore motion) to happen. They can also press the red button on the gamepad to stop the opmode, thus idling the unbrake.

      Remote Driver

      The remote driver also has access to a kill button on their gamepad. They are responsible for starting and stopping automation by controlling the opmode. They can engage in remote steering or enabling automated steering, and can unbrake the vehicle, thereby allowing overrideable movement.

      Fail Safes

      • The brake and steering are the only two systems under automation.
      • The brake is the real safety system and is designed to fail into braking mode. The brake pedal is continually pushed toward stopping the vehicle by rugged bungees.
      • Unbraking or counter-braking requires a motor to counteract the passive bungee tension and allow the brake pedal to release.
      • If power fails to the counter braking motor, the tension in the bungees is enough to back-drive the motor and apply pressure to the vehicle's brake pedal.
      • If the control system locks up with counterbraking applied and doesn't respond to any of the kill commands, the Primary Safety Operator still has the ability to overpower the counterbrake motor. The motor simply doesn't have the torque needed to compete with a human leg. As stated elsewhere, 3 people have access to multiple means of shutting down the control system and we find this extremely unlikely, but are keeping this potential failure mode in mind.
      • The steering motor simply locks up in any kind of failure mode. The gear ratio is approximately 200:1 and the gentle natural tendency of the steering column to center when no input is applied is insufficient to back-drive the steering input. There are too many factors to decide how steering should be applied in an emergency situation. So we decided to take steering out of the equation and simply rely on stopping the vehicle while locking the steering motor. Removing power, killing the opmode and not receiving continuous unbraking commands all result in engaging braking and locking steering to the current angle.
      • All of the above are testable both off the vehicle and while installed.
      • We can’t say it’s impossible for the control software stack to crash in a state where it continues to send a safety-disengage PWM position signal. We’ve never seen it happen and we believe it’s prevented by the interaction of the firmware and the app – but we can’t say it’s impossible. It’s also possible to imagine a freak condition where the servo gearbox breaks and locks up in the safety-disengaged position. So we decided to create a redundant backup safety.

        Site Safety

        Site safety speaks to conditions of the site and surrounding properties that informs the risk to people and property.

        The site is the backyard 3 acres of our coach’s residence and the primary structure on the site is the home itself (blue oval, below). The site slopes downhill fairly steeply from the back of the house to the creek that cuts all the way across the property at the bottom (right side in the image). The site is heavily forested with the exception of an open glade, a clearing for a future workshop, and a gravel driveway connecting them uphill to the main driveway for the residence.

        With the exception of the driveway, the open areas are surrounded by impassable forest (yellow line in the overhead shot below). By impassible we mean that the R2V2 would stall on trees and undergrowth within 10 feet if it tried to push through the surrounding brush. In addition to the forest/undergrowth, all of the neighbor’s properties are further isolated by being either significantly upslope or on the other side of the creek. The creek has cut an impassable 20 foot sudden drop across the property’s southern border, effectively creating a moat that would protect the only neighbor property that is downslope. Right now there is no path to the creek that R2V2 could take.

        The future workshop site (white oval) is the only area that the R2V2 will be allowed to operate in. The ground there is mostly level and compacted. Still, team members need to keep this area clear of possible stumbling hazards. We will refer to this area as the arena.

        Operational Safety

        Operational Safety consists of the training and protocols that will be followed to assure minimal risk to the participants.

        • R2V2 will only be operated on a closed course like the arena. Closed means that we have good control and awareness of all souls on a private course and no other vehicles are moving.
        • Our coach will always be present and supervising operations. The vehicle will only be started by coach.
        • There will be a minimum of three operators, the Primary Safety Operator, a Remote Safety Operator and a Remote Driver. These roles were defined above.
        • Additional spotters will be able to call out safety concerns by issuing a Halt call and hand signal.
        • Every session will begin with a meeting to discuss all planned movements to be sure that everyone in the area knows what to expect as well as what could go wrong and to address specific safety concerns.
        • While we may use "movie magic" to make it appear otherwise, no participant will be allowed to approach closer than 25ft to the path of the (slowly) moving vehicle
        • The vehicle will be kept to a maximum speed of about 5mph (jogging speed) when under automation

        Flyset - R2V2 and Dashboard

        19 Aug 2023

        Flyset - R2V2 and Dashboard By Anuhya, Jai, Krish, Alex, and Sol

        Task: Give presentations at Flyset about progress made this summer

        This weekend, we participated in the FlySet workshop, graciously hosted by team 8565, TechnicBots. We gave two presentations: one on our summer project, R2V2, and one on changes we made to FTC Dashboard.

        R2V2 - A Center-Stage Drive

        Aarav and Anuhya were tasked with creating the presentation, with Anuhya focusing on the steering wheel while Aarav focused on the braking mechanism. During our presentation, Jai and Alex split all the code slides, as they were the ones who worked on steering wheel and braking mechanism coding, calibration and testing. Anuhya, Krish and Sol focused on build and assembly based slides, because the build team designed and built the steering wheel and braking mechanism.

        Overall, the presentation went well! However, because of a lack of practice in the presentation, there were hiccups with passing the microphone from person to person and lines were not entirely memorized. The team didn't seem as put-together as we could have and we want to ensure that we get more practice before our next presentation.

        FTC Dashboard

        Alexander and Jai created and presented a presentation detailing the changes Iron Reign made to FTC Dashboard with the assistance of Mr Brott. Some of the changes included translation and rotation of the origin in FTC Dashboard as well as the addition of image and text support for the graph and field in the Dashboard. These changes were made to enhance the useability of Dashboard for teams and to enable more flexibility in Dashboard's display. There is a more detailed description of these changes in the blog post(hyperlink this) dedicated to this topic.

        Alexander and Jai created and presented a presentation detailing the changes Iron Reign made to FTC Dashboard with the assistance of Mr Brott. Some of the changes included translation and rotation of the origin in FTC Dashboard as well as the addition of image and text support for the graph and field in the Dashboard. These changes were made to enhance the useability of Dashboard for teams and to enable more flexibility in Dashboard's display. There is a more detailed description of these changes in the blog post dedicated to this topic.

        An Overview of the R2V2 Braking System

        26 Aug 2023

        An Overview of the R2V2 Braking System By Aarav, Tanvi, Krish, Sol, and Gabriel

        Task: Design a subsystem to control the braking of R2V2

        An essential part of effectively remote controlling R2V2 is the developing a method for controlling the brake autonomously. We decided, for safety reasons, to not involve the accelerator at all, so the movement of RV2V would be reliant on the application of pressure on the brake.

        Our main requirement with the system's integration with R2V2 was a quick installation process and no permanent changes, meaning that the entire assembly would have to be removable but also rigidly installed for reliability. Additionally, for safety purposes, the resting state of the mechanism would need to be with the brake pushed down, and with power, the brake would be released and the vehicle would move forward. For more information about the safety protocols implemented to protect us, check out this blog post.

        Here is an image of the brake pedal(the larger one) and the area immediately around it. There were size restrictions due to a large center console on the right and the driver’s seat assembly.

        Our initial idea was to use a series of pulleys and bungees to manipulate the brake pedal; however, this applications would require the use of the driver’s seat itself, making us unable to have a driver physically present in the case of emergency. For safety reasons, we pivoted and decided to attempt to emulate the natural movement of a foot and ankle that a human uses to driver.

        Engineering

        The braking subsystem consist of an approximately 2.5 foot by 7 inch REV rail frame that slides in under the driver’s console and lines up with the brake pedal. It attaches to points drilled into the flooring of the RV, and can be quickly installed. This allied for no significant permanent alterations that could interrupt our ability to drive the RV “normally.”

        On the frame, there is a “foot” mechanism mean to simulate the movement of a foot that presses the brake by rotating on an axle attached to the frame. This “foot” is what we manipulate in order to press and release the brake.

        In order to set the default position of the foot mechanism to down, a system of bungees and pulleys are used to create tension and pull the brake down. This way, if the system ever loses power or fails, the foot will revert to pressing the brake and stopping the vehicle. The bungees are tied to the front of the foot and pass through a set of pulleys that send them to the back of the frame, where they are securely tied down. These bungees create a significant amount of tension in order to ensure the foot presses the brake far enough to stop the vehicle.

        To lift the foot, we used heavy-duty twine that could withstand the forces put upon it. The twine was tied to the back of the foot and passed through an elevated pulley(allowing us to more effectively lift the foot through mechanical advantage) to a spool. We used a REV ultraplantery motor connect to a gear train to rotate the spool and lift the foot. Our usage of gears and an elevated pulley system allowed to to counteract the tension of the bungees and release the brake.

        The diagram below highlights the major components of the system as described above.

        Coding

        The code for the “unbreaking” mechanism consists of two parts: calibration and running. Additionally for the code of the robot we refer to the braking system as the unbreak as it only runs when we want to stop breaking.

        First we perform the calibration where we run the motor until we have tightened the string pulling the unbreak up and we set this encoder position to 0 and are not able to go lower then this. Then we run the break until a human sees that the break has stopped being depressed; this is the maximum for the unbreak, and we cannot go higher than that. That finishes the calibration sequence now we can run the unbreak.

        The way that the unbreak runs is a two-fold controller system. One person must depress the deadman switch or the unbreak will automatically run to its lowest position. Once the deadman switch is depressed then the unbreak can be lifted. When the trigger to unbreak is pressed when the deadman switch is active then the unbreak will raise until it reaches its max or until the trigger is released. When the trigger is released the unbreak runs back down to ensure that we are always breaking when not actively unbreaking.

        A majority of the system is comprised of REV parts, illustraring how we can use the parts on our FTC robots for larger and more complex applications. The system itself, after lots of code tuning, worked pretty reliability throughout our testing.

        Next Steps

        We are hoping to further test R2V2 and extend upon its capabilities and further share our progress through our blog, socials, and Youtube.

        An Overview of the R2V2 Steering Wheel

        26 Aug 2023

        An Overview of the R2V2 Steering Wheel By Anuhya, Vance, Trey, Leo, Alex, and Jai

        Task: Design a subsystem to control the steering wheel of R2V2

        One of the main components of our mission to make a remote-controlled RV was figuring out how to automate our steering wheel.

        Step 1: Designing the plywood base for the steering wheel

        Our first plan was to attach a sprocket and chain to the plywood base for the steering wheel. We knew we needed a plywood base because it would be both lightweight enough to easily be removable and attachable onto the steering wheel, and sturdy enough to handle a motor with high torque without splitting. While trying to screw in the sprocket to the base, we realized we didn’t have a convenient way to attach the motor assembly and the chain would most likely “lock up” if we tried to constantly move it forward and backwards.

        We settled on a design using a worm gearbox and the REV ultra planetary motors. We used a paddle to keep the worm gearbox and motor stationary so the steering wheel could move. The paddle was latched onto the window using REV bars and attached to a carbon fiber plate, which was then secured onto the worm gearbox. We used a second carbon fiber plate to attach the shaft collars on the axle of the worm gearbox to the plywood base, and made sure the shaft collars were tight enough to not spin on the axle when high amounts of torque were applied with the worm gearbox.

        Step 2: Attaching the plywood base for the steering wheel

        We didn’t want to make any permanent changes to the RV, so we devised a system to attach the plywood base to the steering wheel using straps and buckles. We attached the buckles to 2 sides on the top of the plywood, and attached one end of the straps onto the back of the plywood. To attach it, the straps go under the steering wheel and latch onto the buckles on the top of the steering wheel, securing the plywood to the steering wheel.

        Step 3: Coding and calibration!

        After we finished the design portion of the steering wheel we had to get it to actually move. We needed to not only map the left and right motion of the steering wheel to buttons on the logitech controller we are using for the R2V2 but also to know where the wheel is in relation to its maximum rotation to either side at all times.

        In order to find the maximum rotation of the wheel we had to spin it all the way to one side. We need to find a way to know in the code that we reached the end of how far we could turn. For this we decided to test to see if the motors stalled because when the motor cannot move the wheel anymore in a direction its amperage spikes. This makes up our calibration mechanism. We spin the wheel all the way to the left and when it stalls we record the encoder position as the max left we can go. Then we spin the wheel all the way to the right and do the same thing but with the max right. We then find the distance between the max left and right and assume the middle of those numbers is center. To finish the calibration we run the wheel to center and then set that encoder position to 0 for easy readability for the driver. Left is negative and right is positive. Finally as a sanity check we make sure the encoders were recording values and if they were not we stop the robot as a safety precaution.

        This procedure gets us the precise location of the wheel relative to where it is, and we can safely run the robot using the controller.

        Next Steps

        We are hoping to further test R2V2 and extend upon its capabilities and further share our progress through our blog, socials, and Youtube.

        FTC Dashboard Field Versatility Update

        07 Sep 2023

        FTC Dashboard Field Versatility Update By Jai and Alex

        Task: Update FTC Dashboard to better suit our needs

        During our PowerPlay season, we used FTC Dashboard extensively. However, because of some suboptimal code and some limitations of the platform, we were unable to use it to its full potential, especially in regard to the Field View component. We contributed to the repository with some quality-of-life changes that impact the hundreds of FTC teams that use Dashboard.

        What is Dashboard?

        FTC Dashboard is an open-source repository at https://github.com/acmerobotics/ftc-dashboard. It’s a tool that creates a webserver on your Control Hub and opens up a port that any web browser can connect to. Once it’s up and running, you can use it to visualize telemetry with plots and graphs, edit configuration variables, view feed from the camera, run op modes, and visualize your robot in the context of the field, all live.

        Why’d we change it?

        During our PowerPlay season, we had conflicting origins used by FTC Dashboard’s field visualization, RoadRunner, and our native pathing solution, which led to headaches and near-impossible navigation debugging. This season, we’ve committed fully to RoadRunner’s navigation system, but the lack of flexible origin and origin heading in the field visualization component was a hurdle for our development.

        Because of this, we set out to implement a setTranslation() function to make development with dashboard much more flexible. It was a bit more ambitious than we’d initially thought, though, and we needed to speak to the original author, Ryan Brott, to truly understand the inner workings of dashboard.

        Once we got setOrigin() working, however, we understood the true potential of this field visualization tool. We implemented support for image drawing, text drawing, scaling, transparency changes, editing the grid lines, and more.

        Next Steps

        Ultimately, we’ve succeeded in making an incredibly useful tool even more useful, and many of these changes are incredibly convenient for tons of our fellow FTC teams. We also always love the opportunity to give back to the community and contribute to the libraries that are lifesavers for teams like us. We’re looking forward to making more open-source contributions to make FTC more accessible for everyone.

        Center Stage Game Reveal and Ri2D Day 1

        09 Sep 2023

        Center Stage Game Reveal and Ri2D Day 1 By Aarav, Anuhya, Georgia, Sol, Tanvi, and Alex

        Task: Assess the Center Stage Game and begin Ri2D

        Today, Iron Reign attended the season reveal for the new FTC season and began working on this year’s Robot in 2 Days, a tradition where we prototype a preliminary robot the weekend after the reveal to experiment with ideas and concepts. Unfortunately, because of the complexity of this year’s field, most of today was spent attending the reveal, tidying up the workshop, and assembling the Center Stage field. This post will be a distillation of our thoughts about the game, strategy interpretation, and commentary about the field setup and assembly.

        This year’s game is quite a bit more complicated and convoluted than those of previous years. There are multiple scoring methods and multiple objectives during the game, and the field layout itself will test the communication of alliances and the referees. Here’s a list of some key things we noted during the reveal:

        • At first glance, a small, light, and fast robot seems to be the most effective tactic. There is very little strength required due to the hanging aspect and lightweight pixels.
        • Lightweight pixels mean the intake system/gripper can be quite weak.
        • The right of way on the stage door also limits the value of defensive play.
        • Short robots will probably be what is utilized by most teams this year to avoid using the stage door and robot traffic
        • It is 11” between the bottom of the closed stage door and the ground, so this effectively cuts maximum height by a third. The 14” truss will also be used in this same manner.
        • There will be a heavy emphasis on video pipelines and object recognition for the autonomous portions.
        • We also cannot use April Tags for recognition like we did last year; we will need to differentiate on other aspects.
        • Grippers need to be able to pick up 1-2 pixels at a time, potentially adding to an already captured pixel, and drop them off one at a time.
        • Turns and rotations can be reduced by building two separate subsystems of intake and deposit to reduce cycle time.
        • The less-than-ideal placement of the wing will lead to intense competition for the white pixel stacks.
        • The drone aspect leaves a lot of gray areas in the rules and what qualifies as a legal “drone.” There will need to be experimentation to determine the ideal shape.
        • It can be tough to score pixels in the background. They have a tendency to bounce off if placed with too much power or placed too high up.

        After the reveal, we headed back to the dojo, tidied up, and began the grueling task of assembling the game field, which took multiple hours(around 5) to build. Certain aspects of the game, such as the assembly for the C channels and A-frames on the rigging posed significant challenges. Additionally, one of the rigging tubes had stoppers stuck in both ends, proving it difficult to be further used in the construction of the field. As a result, Sol had to cut down one of the tubes from last year’s field components as a substitute. Because of these issues, we were unable to start on Ri2D today, but we did have a fully assembled Center Stage field. A second blog post detailing our Ri2D efforts will be posted tomorrow, along with an overview of Ri2D.

        For now, here are a couple of key questions we had about the game that could potentially influence design decisions:

        • What is the highest point where a pixel will need to be placed?
        • Can the drone be more like a dart?
        • Is a simple arm-based drone launcher enough?
        • Could we just pop the pixel up using a “spatula” like motion/object?
        • What is the smallest paper airplane that can be made with a single sheet of 20 lb paper?
        • Could you make a drone follow a U-shaped path?
        • What would be an effective team prop that could be easily identified?

        Next Steps

        Use the newly assembled field and our fresh ideas to create a preliminary Robot in 2 Days that can score points and complete a couple of basic tasks. Experiment with methods for hanging and drone design as well. Finally, we would like to capture footage and produce a video in order to share our work and findings with the FTC community.

        Center Stage Robot in 2 Days(Ri2D) Overview

        10 Sep 2023

        Center Stage Robot in 2 Days(Ri2D) Overview By Aarav, Anuhya, Krish, Sol, Tanvi, and Alex

        Task: Build, Code, Test, and Film our Center Stage Ri2D

        This blog post will serve as a more in-depth analysis of Ri2D, including dives into specific subsystems and rationale.

        The Chassis

        In order to save time, we repurposed a basic mecanum and REV rail chassis from our sister team, Iron Giant. It is a basic REV rail frame with mecanums driven by motors and chains, along with all the requisite electronics. We built all of our additions on top of this base; however, we did spend a sizable amount of time fixing the chains on the chassis. Mecanums were the clear-cut choice because of their simplicity to use, the lack of on-field barriers that could interfere with them, and their strafing capabilities(which we unfortunately did not get working due to balance issues). One of the critical issues with this chassis was its lack of weight balance. The Control/Expansion Hub and Battery were located on the front side, preventing our Ri2D from strafing and causing the opposite side to pop up when driving.

        The Gripper

        We found that a prototype of our old UnderArm gripper from TauBot(last year’s robot) fit the pixels relatively well, which allowed us to adapt it to this competition. It features a pincer grip articulated by a single servo between 2 carbon fiber plates. There are also custom Ninjaflex squinches on the pincers to allow for better gripping. Since we wanted to implement a transfer strategy, we gave the gripper limited mobility, allowing it to only pick up 1-2 pixels from the ground and then lift them for transfer.

        The Scoopagon/Transfer System

        In order to limit the need for our robot to turn in order to pick up pixels and deposit them on the backdrop, we implemented a basic transfer system into our Ri2D. The primary mechanism that deposits the pixel is an arm with a pixel holder built out of tape and polycarbonate, which we call the “Scoopagon”(it scoops the pixel up and is shaped like a hexagon). The gripper flips up and drops the 1-2 pixels into the Scoopagon during the transfer. This allows us to reduce cycle time by reducing the amount of driving we have to complete; however, sometimes pixels can get stuck on the edges of the Scoopagan or get tangled with other parts of the robot.

        Scoring System

        In order to score the pixels, our Ri2D uses the Scoopagon in combination with a rotatable arm and extendable linear slide. The Scoopagon is mounted on an arm that can be rotated by a servo, creating a “catapult-like” motion. The entire servo and arm assembly is then placed on a linear slide that can extend out to allow us to place pixels higher on the backdrop and from farther away. One potential issue with our implementation is that the arm may accidentally propel pixels, which is not allowed by the rules, so the arm must be close enough to ensure the pixels are placed onto the backboard.

        Expansion Ideas and Limitations

        Because of time constraints and the extended field assembly time, we could not attempt the drone and hanging aspects of the game. However, we found a hanging mechanism used by previous year’s robots(pictured below) that relies on tape measures. Due to the massive amount of weight imbalance, we were unable to attach it to our robot, but we hope to be able to test it out on future robots. As for limitations, the robot itself was very tough to drive due to the weight imbalance and general lack of driver practice, and the linear slide was poorly built and ended up being quite unreliable.

        Overall, though, Ri2D served as a valuable learning opportunity for us, and we will be using everything we have learned over the past 2 days as we move forward into the season.

        DPRG Meeting Presentations

        12 Sep 2023

        DPRG Meeting Presentations By Aarav and Anuhya

        Task: Share R2V2 and Ri2D with mentors at DPRG

        Throughout this month, Iron Reign has been presenting its recent work at DPRG(Dallas Personal Robotics Group) meetings on Tuesday evenings. On August 22nd, Iron Reign presented our summer project, R2V2, to DPRG. We received lots of great feedback about improving and expanding our project, including vision-based object tracking to allow the RV to follow specific objects. You can watch a recording of that linked below:

        Then, today, we presented our Robot in 2 Days and the Ri2D video we produced at the DPRG meeting. We discussed our design process, prototype, and general strategy for the match. We discussed the importance of communication on the playing field, possible origami techniques to incorporate into our drone, and deposit systems on the backdrop. Here is a recording of the presentation:

        Thanks to DPRG for allowing us to present. Overall, meetings with DPRG are great opportunities to get feedback on our work, brainstorm new ideas, and practice presentation skills. We plan to meet with DPRG further into the season once we progress more on our competition Robot.

        CenterStage Introductory Meeting & 9/16 Meeting Log

        16 Sep 2023

        CenterStage Introductory Meeting & 9/16 Meeting Log By Aarav, Anuhya, Krish, Tanvi, Sol, Alex, Vance, and Georgia

        Task: Welcome Recruits to the Workshop and begin Robot Ideation

        Today, Iron Reign hosted our introductory meeting for all new recruits at our workshop. We also began planning and brainstorming for our competition robot and potential subsystem ideas.

        We had approximately 20 recruits in attendance, and we initially showed them the Center Stage reveal video and discussed potentially confusing aspects of this year’s game. We then talked about potential strategy while also sharing our Ri2D video. We tried to highlight the importance of building small and fast and decreasing cycle times and communication over more complicated designs. Lastly, we reviewed the main robotics subteams: build, cad/design, code, and the editorial team, along with logistical information about tournaments and the awards categories.

        After, we split up the recruits into code and build teams and introduced them to the software/hardware used in FTC. Those interested in code were exposed to our repository structure, FTC Java syntax, and methods, and we were able to walk them through a basic program that makes a motor run. The build and design recruits started by learning about essential components such as motors, servos, control hubs, and REV rails, and we talked to them about basic building structure(how to connect nuts/bolts to rails), chain-breaking, control hub wiring, and the critical differences between motors and servos. Next week, we hope to be able to split them up based on previous experience into 2 teams and have them begin brainstorming, discussing strategy, and starting on assembling their robot chassis.

        As for Iron Reign, we began with an ideation session with a whiteboard where we thought about chassis and gripper ideas. At this moment, we are leaning towards a mecanum-based chassis to allow for strafing, but we came up with various potential gripper ideas, from a beater bar to a box-shaped design. Finally, we came up with some ideas to allow our robot to suspend from the rigging, and we started working on CAD prototypes.

        Next Steps:

        The rookie teams will soon begin to split up into teams and start working on their robots. For Iron Reign, our next steps are to begin CADing a preliminary version of our robot and the requisite subsystems while also considering other ideas.

        9/23/23 Meeting Log

        23 Sep 2023

        9/23/23 Meeting Log By Aarav, Anuhya, Jai, Krish, Tanvi, Vance, and Alex

        Task: Prepare R2V2 for Filming and begin Designing Subsystems

        Today, Iron Reign had an extended meeting to focus on preparing R2V2 for video production and to start designing and testing robot ideas. We plan to produce a complete walkthrough of R2V2, with footage of the individual subsystems and the entire RV driving around autonomously. We were hoping to begin filming today, but we needed to repair both the Steering and Braking subsystems, which took some time.

        We tightened the bungees on the Braking and increased the gear ratio of the motors from 15:1 to 120:1 to deal with the increased tension on the “foot” mechanism. We decreased the gear ratio on the Steering system to accommodate the increased ratio in Braking. Unfortunately, once all the planning for the shoot and subsystem adjustments were complete, we did not have enough time to film before the meeting “officially” started for all the recruits.

        The recruits split into teams and started working on chassis for their robots, creating REV rail frames, and Iron Reign had multiple design meetings to create a clear plan for our competition robot.

        We decided that for the first iteration of our robot, we would focus on a mecanum chassis to allow for a quick build and strafing capabilities. Anuhya began designing an assembly with a wheel and an integrated motor(sketch shown above). For the drone launching mechanism, Tanvi began creating and experimenting with a catapult-type system and designs for the drone itself(sketch shown below). Vance started to work on an intake system modeled after the Ringevator(our ring intake system from Ultimate Goal), and Krish began to manufacture a prototype for our hanging system.

        Code-wise, Alex and Jai refactored the codebase and began working on integrating Roadrunner with our drivetrain and teaching the new coders some basics.

        Next Steps:

        We aim to have a functioning robot quite soon in preparation for the first qualifier so that we can begin coding. To do so, we will need to keep working on the various subsystems and starting to manufacture and iterate them. We will ramp up our connect and motivate efforts as the season progresses.

        9/30/23 Meeting Log

        30 Sep 2023

        9/30/23 Meeting Log By Aarav, Anuhya, Tanvi, Georgia, Vance, Krish, Jai, and Alex

        Task: Start prototyping our robot

        Today, Iron Reign continued working on designing and prototyping our robot in preparation for scrimmages and our initial meets. We began working on an intake system for the pixel stack, based on Ringevator, our 2019 intake system. It involves custom ninja-flex belts that grab the pixels and propel them to a collection point for further manipulation. We finished designing it in CAD and began 3D printing the belts and assembling the motor and belt subsystems needed to move the belt. The chassis and drone launcher are also still being designed.

        On the code side, we continued working on coding the classes for our 2023 and dividing it into subsystems and classes to streamline it for us in the future once our robot has been designed.

        Finally, we finished up preparation for shooting the R2V2 walkthrough and videos, which we plan to do tomorrow.

        Solar Prep for Girls Recruitment

        03 Oct 2023

        Solar Prep for Girls Recruitment By Sol and Vance

        Task: Recruit Future Members at Solar Preparatory for Girls

        Today, Iron Reign members Sol and Vance represented Iron Reign at a recruiting event at Solar Prep for Girls in Dallas. This was an event to recruit new members for the program from middle school and recruit students to attend Townview next year. We had a booth set up with TauBot, our Power Play robot, which we showed off to the students. Overall, events like these are a great way to foster early interest in robotics and specifically FIRST/FTC, and ensure that we have a stream of new recruits coming in for when we graduate.

        10/7/23 Meeting Log

        07 Oct 2023

        10/7/23 Meeting Log By Aarav, Anuhya, Tanvi, Sol, Vance, and Jai

        Assemble and Test our Pixel Intake System

        Today, Iron Reign focused on turning our ideas and designs on CAD into real-life prototypes in preparation for our first scrimmage on October 28th. We began assembling our beater-bar intake system that relies on a custom ninja-flex belt with protrusions that bring in pixels from the ground and from the stack. The ninjaflex belts on the prototype are controlled by a motor and chain system, but when further refined, we intend to replace them with belts.

        The subsystem is shaped like a triangle, with one large ninjaflex belt in the center and two secondary belts that feed into the main belt. The triangle shape allows for a wider range of intake locations for the pixel and more flexibility for our game strategy when intaking.

        The entire beater system is intended to be placed on an intake tray to hold the pixels as they slide in. Our current prototype has a cardboard version, but we intend to manufacture a carbon fiber version for further iterations. Our goal is to use this new intake system with a redesigned version of the Scoopagon with a transfer system.

        Next, we continued prototyping and designing multiple drone launching mechanisms, including a trebuchet-like mechanism and a slingshot release by a servo. We plan to test both these ideas and continue to design and test throughout the season to develop the mechanism that is the most accurate and consistent.

        Next Steps:

        We will finish assembling and testing the subsystem for the beater-bar intake system, then begin redesigning the Scoopagon to hold 2 pixels and attaching the intake to our prototype Robot in 2 Days chassis. Additionally, continuing to design the chassis and drone mechanism is required to be able to field a complete robot by the scrimmage. On the code side, we need to start working on creating pathways and sensing for auton and integrating the new subsystems into the Robot in 2 Days code. A completed prototype of the robot also allows us to engage with local mentors in the coming months to get feedback on our design.

        Scrimmage Review

        28 Oct 2023

        Scrimmage Review By Anuhya, Vance, Alex, Sol, Georgia, Krish, Tanvi, Jai, and Aarav

        Task: Review our performance at the first scrimmage of the season

        Earlier today, we had our first scrimmage at Woodrow Wilson! This was our first proper opportunity to interact with other teams and their robots this season and we got a chance to troubleshoot any design issues with our robot. We entered this scrimmage with our beater bar system in the vague shape of a triangle and a linear slide with a “scoopagon” as our outtake. Overall, because of a lack of driver practice, we experienced quite a few issues without our linear slide and beater bar system, but it was an incredible learning opportunity!

        Play by Play

        Match 1: 9 to 0 Win

        Our auton wasn't enabled. We also had a bad servo configuration on our beater bar so we were essentially a “push bot” for this first match. After the autonomous period, when our drivers went to pick up their controllers, they noticed a driver station issue, rendering our robot useless for this match. We scored 0 points and our alliance partners scored the other 9 points.

        Match 2: 13 to 16 Loss

        Our auton wasn't enabled again because we thought it would cause our robot to crash. Our outtake wasn't working so we ended up using our beater bar to score. We managed to score two pixels but, because of a lack of driver practice and an unconventional and unplanned method of scoring, we knocked them off the backdrop into backstage. Instead of our initial plan of getting pixels from the pixel stacks, we took pixels from the wing. We wanted to take pixels from the pixel stacks because we wouldn't have to go diagonally through the opposing team's area but it wasn't possible because of the level of precision needed to score from the pixel stacks using a beater bar.

        Match 3: 18 to 46 Loss

        Once again, our auton wasn't enabled. We continued using our beater bar to score. We were able to score 2 pixels on the backdrop this time and we took pixels from the stacks like we had initially planned instead of from the wings. We got a lot more pixels but in the process of transferring them through our beater system, we ended up loosing quite a few of them. Our opponent got 30 points in the way of penalties, so they won. We haven't found the right balance in speeds for our beater bar's rotations, nor do we know how stiff the tabs should be. We need to do a lot more experimentation so the beater bar can be used properly to both retain pixels, take pixels from both the wings and pixel stacks and possibly score pixels on the randomization lines and the backdrop.

        Match 4: 37 to 17 Win

        Our auton still wasn't enabled but we had hopes we could get it to work before the next match. We continued using our beater bar to score, and we got 3 pixels on the backdrop and one backstage. By picking up pixels from the wings, we also got some level of precision with our beater bar and human player because we managed to successfully create a mosaic on the backdrop! This was our first mosaic of the season!

        Match 5: 19 to 15 Loss

        The highlight of the scrimmage was definitely the last match. Our auton was enabled but didn't end up working as we intended and we scored one pixel on the backdrop but we managed to drop it by hitting the backdrop with too hard a force.

        Next Steps

        One of the biggest issues we had throughout this meet was with our beater bar system. The “tray” we were using to keep the pixels moving through the beater bar is made out of MDF with a chiseled tip so it can lay flat against the mats. However, because of friction with the mats, it kept fraying, meaning it acted as a slight barrier for the pixels entering the beater bar. As soon as possible, we need to replace the MDF with both a thinner, more sturdy and frictionless material. Our outtake is also notoriously unreliable, especially because of how bad our servo configuration and wire management is. Our motor placement for extending the linear slide could also be improved. Overall, we want to work on improving this current iteration of our robot for now instead of completely changing our build.

        Woodrow Scrimmage Presentations

        28 Oct 2023

        Woodrow Scrimmage Presentations By Aarav, Jai, Vance, Krish, Sol, Alex, Tanvi, Anuhya, and Georgia

        Task: Share our Portfolio Advice and Summer Adventures with other Teams

        Today, at the Woodrow Scrimmage, in addition to participating in mock inspections and matches, Iron Reign hosted two workshops for Scrimmage participants, one on constructing effective portfolios and another detailing our summer activities. These workshops were significant successes, with 25+ attendees in two sessions, each lasting 30-50 minutes.

        The portfolio “how-to” guide involved us walking through our portfolio from last year, explaining major design/content decisions, and sharing a couple of tips and tricks along the way. Some key points we stressed were taking pictures, sorting portfolio sections by the 7 award categories, clearly showcasing the engineering-design process, and adding (at minimum) rudimentary drawings to enhance understanding. Because most of our attendees were from rookie teams, we also discussed the types of content that would work well in a rookie portfolio, such as talking about starting logistics, failed ideas, and experiences as a new team to FTC.

        In the summer activities workshop, we talked about our summer project, R2V2, and the details behind its planning, creation, iteration, and eventual testing. We also noted the specific operational safety protocols we used, which can be found in an earlier blog post.

        We want to thank the organizers of the Woodrow Scrimmage for allowing us to present. We love sharing our enthusiasm for robotics with other teams and inspiring them in the process. There will be a separate blog post detailing our performance at the Woodrow Scrimmage and our major takeaways.

        AWS Solutions Architect Connect Meeting

        06 Nov 2023

        AWS Solutions Architect Connect Meeting By Aarav, Krish, Anuhya, Jai, Alex, and Georgia

        Task: Get Advice from a AWS Solutions Architect

        Today, 6 members of Iron Reign virtually connected with Bilal, an Amazon Web Services (AWS) Solutions Architect, in order to present our team and gain some valuable advice. As a Solution Architect, Bilial focuses on designing, setting up, and troubleshooting client-server solutions through the AWS infrastructure, which involves technical skills, teamwork, and a lot of problem-solving.

        In our meeting with Bilal, we first talked about our team and the robots we build. We touched on team structure, our core team principles, and some of our recent successes. However, with Bilal’s knowledge of robotics, the Internet of Things(IoT), and work experience, we quickly moved on to discuss our recent projects and team struggles.

        One central point of emphasis was our summer projects from the past 2 years: Mechavator and R2V2, which we spent a hefty amount of time discussing. These projects, in which we used REV hardware and FTC software to automate 2 modern vehicles, are heavily related to modern IoT practices in companies like AWS.

        Additionally, we focused on our core team’s recent open-source work, where they contributed to the FTC Dashboard repository, adding features such as field transformations, expanded image and text handling, and a variable origin.

        Finally, as a team, we brought up many of our shortcomings and points of improvement in hopes of gaining some advice. We identified a few key issues: a lack of cohesion between the build/design and code subteams (we often have serious time crunches around competition), poor time management, an absence of proper planning, and the need to transfer knowledge between seasons.

        On these topics, Bilal gave some great advice. Regarding knowledge transfer, Bilial noted that this was also a significant issue at AWS since the technical landscape is constantly changing and information grows outdated quickly. He says even AWS internal documentation and blog posts can often be inundated. For us, he suggested we expand existing documentation and knowledge base, such as adding more blog posts, creating CAD walkthroughs/tutorials (AWS does a lot of digital panels and videos), and further engaging our vast alum network.

        Moreover, on time management, Bilal mentioned the Kanban method and the tool Asana as pathways we could test. Finally, he suggested that to allow for greater coordination between build and code; we look at simulation services such as AWS Robomaker, which would allow code to get started earlier and could serve as a valuable addition to our documentation efforts.

        Overall, though, thanks to Bilal for taking the time to meet with us. We had a great conversation and took away a lot of great feedback. We hope to meet with Bilal in the future and show him our CenterStage Robot!

        League Meet 1 Review

        18 Nov 2023

        League Meet 1 Review By Anuhya, Vance, Sol, Georgia, Krish, Tanvi, Jai, and Aarav

        Task: Review our performance at our first league meet!

        Today was our first league meet, which means all our wins, losses, overall points and points gained in autonomous would count towards league tournament rankings. This was a good opportunity to see how we'd hold up against other robotics teams who all had the same amount of time to prepare for this season's game. Overall, it was a good experience and we were pleasantly surprised by our robot's capabilities as well as our luck!

        Play by Play

        Match 1: 26 to 10 Win

        Our auton actually worked! Our robot's auton is designed to move the robot back slightly and deposit a pixel onto the middle randomization line. We scored 20 points for auton! The beater bar was slow to start, so we were at a bit of a disadvantage of our own creation, and the linear slide servo wire came out, meaning we had to rely on the beater bar for depositing our pixels. We ended up with one pixel backstage, and we parked during the end game but we were almost outside the field.

        Match 2: 20 to 26 Loss

        Our robot moved in auton but the beater bar didn't release the pixel. This was similar to an issue we were having at the scrimmage, where the beater bar wasn't able to get a good hold on the pixels. We scored one pixel using the beater bar but one issue we noticed was that the beater bar was getting stuck on the tape which demarcates the wings. This can be both problematic for our game because it can give the opposite team penalties and it also takes away from our ability to get pixels from the wings. We parked in end game. Some possible solutions we may look at to help with the tape issue is curving the edge of the tray of the beater bar or adding some frictionless tape so it doesn't catch as much.

        Match 3: 15 to 39 Loss

        Our robot, once again, moved in auton but didn't release the pixel. Immediately after auton, our robot's battery died so we couldn't move it at all. It was also a hindrance to our alliance team because it died right in front of the backdrop. We got some points from a penalty, but it was still a resounding loss. In many of our previous robotics' seasons, our robots' dying has been a major issue. As a team, we need to do a better job of ensuring that we have charged batteries available and the voltages are at the optimal amount for a fully functional robot.

        Match 4: 14 to 28 Win

        Our auton deployed properly but luck was not on our side; the pixel placement didn't match randomization. We scored 4 pixels on the backdrop, picking up the pixels from the wings and using our linear slide and scoopagon to score on the backdrop, but they didn't form a mosaic. In end game, both of the robots on our alliance parked!

        Match 5: 54 to 60 Win

        Our auton deployed properly and the pixel fell on the randomization line! Our alliance partners parked during the autonomous period as well. We scored five pixels on the backdrop but two of them got knocked off. During end game, both our alliance teams got parking! Pixels getting knocked off the backdrop are a recurring issue throughout our matches this season. We need more driver practice to make sure the scoopagon hits the backdrop with the correct amount of force to deploy the pixels but also doesn't knock off any pixels already on the backdrop. We also need a strategy to make mosaics instead of placing random pixels on the backdrop because mosaics get far more points.

        Next Steps

        Our outtake is still not as reliable as it could have been, especially because of the wire management and how wobbly our linear slide is overall. We have made clear progress from our scrimmage, where the outtake didn't work at all, to now, where the outtake works but isn't reliable, but there is still a lot more work to do. We've seen that our “scoopagon” is quite reliable and don't have any plans to change it at this moment, other than to secure our counterweight in a better way. We also know that using the vision pipeline is very possible for our autonomous and we want to implement that by the next league meet. We are also going to experiment with different materials for the tray of the beater bar, with it currently being a very thin sheet of aluminum.

        League Meet 1 Post-Mortem

        21 Nov 2023

        League Meet 1 Post-Mortem By Aarav, Krish, Jai, Sol, Tanvi, Alex, Vance, Georgia, and Anuhya

        Task: Analyze our performance at our 1st League Meet

        After Meet 1, Iron Reign met to discuss their performance as a team and make plans for the next month in preparation for Meet 2. Here are our takeaways and analysis, divided into strengths, weaknesses, threats, and opportunities.

        Strengths:

        • Our drive team communicated quite well, and we could score pixels very well and turn those points into match wins.
        • A better auton performance than we expected. We only coded it for the middle region, but it consistently scored that. However, we were lucky with the region selection during this meet. Adding code for the two side zones is near the top of our to-do list right now.
        • No hang-ups on the stage door while crossing the playing field. Our strategy this year involves building a robot shorter than the stage door so that we can freely transit across the center rigging, and during this meet, our robot was quite successful at that task.

        Weaknesses:

        • A mediocre gameplay robot that does not stand out innovation-wise. Generally speaking, this year's robot will not be super innovative compared to the previous year's robot. This means that we need to put effort into improving the gameplay capabilities of the robot to stand out.
        • The outtake got stuck and missed the pickup location. Because of the tight spacing near the transfer point, our outtake would get stuck on wires and bungees around there and not reach all the way down, leading to failed transfers.
        • Wire management limited our usage of the outtake. Often, when we extended the outtake, the wire connecting the servo at the end would get caught on the chassis and unplug, rendering us unable to score. We need to cable manage the entire robot and test to ensure nothing gets caught when the robot moves.
        • Intake catching on tape/tiles. When we were picking up the robot on the wings, the front edge of the beater bar would get caught in the tape and not pick up the pixels. That is something we will have to experiment with and fix.
        • Erratic movement and a lack of control sometimes led to us hitting the backdrop and descoring pixels. A better understanding of our scoring positions and outtake positions should help us avoid this.

        Threats:

        • Lack of organization. So far during the season, we have not communicated well between subteams and as a team in general. We must ensure everyone is on the same page and up-to-date on what is happening, especially across subteams.
        • Careless placement of expensive parts. We often misplace motors and servos, and these costs increase over time. This ties into being more organized, both in our workspace and as a team.
        • Only working on the robot at the Robodojo(not emphasizing design and portfolio). Editorial work, CAD, and code(to an extent) can be done off-site, and our ability to stay on schedule relies on us putting time outside our formal meetings.
        • We have not thought about what we want our portfolio to look like or put much effort into our documentation efforts.
        • We simply have not put much effort into finding and getting donations/sponsorships. We must focus on that to continue the program's sustainability and fund the parts we need for the new robot.

        Opportunities and Next Steps:

        • Seeking out mentorship and connect opportunities. Building relationships for the long-term. For example, we could have more meetings with DPRG.
        • A new chassis for the next robot version with a potential 3-wheel drive.
        • We have yet to tackle the lift or drone aspect. Getting designs underway for those and testing them on the robot to increase our point-scoring capability.
        • We could experiment with a shortened linear slide and Scoopagon to solve some of our problems with a reliable transfer system. Also, adding a way for the robot to detect the backdrop for depositing pixels should allow us to automate the process and reduce our chance of descoring pixels.
        • Expanding auton to all 3 regions and adding the yellow pixel
        • Blending innovation and gameplay strength for future competitions
        • More driver practice, which is something we have neglected in past seasons.

        Explaining Drone Launcher V1

        23 Nov 2023

        Explaining Drone Launcher V1 By Tanvi and Aarav

        Task: Explain how we arrived at our current drone launcher design

        The first iteration of the drone launcher is a simple servo-powered elastic launcher that is controlled like a switch. A linear slide has a servo mounted to the back end and a V-shaped nylon airplane holder is attached to surgical tubing which is attached to a zip tie held by the servo. The system is set on a linear slide, resulting in easy change of the amount of power being transferred to the plane. We opted for a compact drone design so it can easily be held by our airplane holder, which allows for a more consistent launch by reducing impact of draft. Hopefully, our final plane design will have very few open folds, resulting in minimal aerodynamic drag.

        The Design Process

        Our first step for creating the plane design was to look at multiple videos on YouTube explaining paper airplane design, in the hopes of getting some inspiration. Our initial thoughts for the trajectory of the airplane was that we wanted it to shoot out to the side, and basically make a U-turn so that it lands parallel to the lines of the landing zones. This way we would lower the chance of the plane flying past the scoring zones. However, as we looked more and more into the physics behind how airplanes work, we realized it wasn’t feasible. Our current plane design was achieved mostly through trial, error and research about lift, drag and thrust.

        First, we figured we wanted our launcher to be spring-controlled. Our initial thoughts for the design were to use a holder and a spring that would be stretched and released to launch the plane, but springs are better at launching objects over a short distance and we wanted the plane to be pushed down a longer runway to reduce errors during launching. Next, we turned our attention to rubber bands as a launching medium. This would eventually lead to us using surgical tubing as our mode of tensioning.

        Another initial design was a trebuchet-esque design, pictured below. This consisted of a base plate with a beam on a pivot. The beam would be controlled by servo and tension would be applied through surgical tubing. There would be adjustable axles at the stopping points. Additionally a “sling” would have to be constructed to cradle the airplane. Challenges with this design regarding how to keep the plane in an aerodynamic position and mounting.

        Strategy

        Our goal for the launcher was to be as straightforward as possible. During the endgame, the drone has to be launched from behind the truss to one of the three distinct launch areas. The launch area closest to the field is the area with the most points allotted. Due to this complication, the drone cannot be launched as far as possible. It must stay within a set distance. As a result of the adaptable design, the mechanism can be coded with a simple on-off type code and can be adjusted mechanically by hand (in tiny adjustments).

        Next Steps

        Over the course of the season, we expect to keep experimenting with models and shifting them to find the best one for us. Eventually, we hope to have a fully 3D-printed design. As our robot goes through iterations, so will the launcher!

        League Meet 2 Play-By-Play

        09 Dec 2023

        League Meet 2 Play-By-Play By Aarav, Krish, Jai, Sol, Tanvi, Alex, Vance, and Georgia

        Task: Review our performance at our 2nd League Meet

        Today, Iron Reign has its second league meet. It was, in general, a helpful experience and a great chance to compete with local teams. Overall, we went 3-3 and ended up ranked 9th due to our high tie-breaker points. Even though our record was slightly worse compared to the first meet, our robot performance was significantly worse, and multiple helpful alliances gave us our wins. Code bugs and poor packaging made the meet a significant struggle for us, leaving us with a lot of ground to make up during winter break. However, before we look at some of our takeaways, here’s a brief play-by-play of our matches.

        Match 1: 118 to 15 Win

        We ended up not running an auton due to reliability issues. Our alliance partner scored 30 in auton through a combination of placing the purple pixel in the randomized location, a pixel on the backdrop, and navigating backstage. During tele-op, we started slowly due to a long initialization cycle. Unfortunately, the axes on the field-oriented drive made the robot almost undrivable, and it took a good 45 seconds to cross the stage door. This was a recently added feature that had not been fully tested before the competition. When we reached backstage, the preloaded yellow pixel fell out of the Scoopagon, meaning we had to go all the way back to our wing to pick up a new set of pixels - costing us time. On the way across the stage door, we got caught on our alliance partner and yanked off their drone from their launcher. Despite this, our alliance partner performed well, cycling 2 pixels onto the backdrop and hanging from the rigging.

        Match 2: 40 to 31 Loss

        Auton successfully placed the purple pixel on the right tape based on our team element, albeit because of a somewhat favorable noise, but we took those. After the buzzer rang, we promptly switched modes, quickly crossed underneath the stage door, and cycled two pixels on the backdrop. However, our driver Krish had trouble maneuvering back through the rigging posts, an issue that could be fixed through driver automation in tele-op. We hurried back for parking in the endgame, but our opponent managed to hang from the rigging, which gave them the win.

        Match 3: 38 to 48 Loss

        During this match, our robot successfully scored the purple pixel in auton, and our partner parked backstage. We cycled 1 pixel onto the backdrop, but the messed up driving system, combined with a lack of communication during pixel intake, meant that’s all we were able to score. During the meet, we tried to solve the communication issue by creating a simple hand gesture system. Unfortunately, we ended up losing because of a penalty our alliance member incurred for interfering with the pixel stacks.

        Match 4: 71 to 51 Loss

        Before this match even started, we had struggles with initializing the robot and setting it up for match play. Because our outtake slide was not fully retracted, we also had issues complying with the sizing requirements, which took a bit of time to sort out. A comprehensive “pre-match checklist” that we adhere to could help fix this. In auton, we deposited the purple pixel properly; from there, things worsened. Because of a code bug in the transition between op-modes, we remained stationless for the final 2 minutes. We could not solve the code error during the meet, so this issue continued to hurt us. One potential reason for this was how many code changes we were making at meet, often at the very last minute, which left us unable to fully take the time to test out the changes.

        Match 5: 30 to 34 Win

        Here, we missed the auton pixel and fell victim to the same code bug that happened before, which left us static for all of teleop. We got very lucky as our alliance partner scored their drone and a couple of pixels, carrying us to victory(we scored no points in this match). We thought we had fixed the code bug during testing on the practice field, but we simply didn’t have enough time to verify that.

        Match 6: 37 to 26 Win

        In our final match, our auton remained consistent, but yet again, the code issue reared its ugly head. This meet was very much the tale of two halves. A sort of successful first 3 matches led to us pushing new code and build changes to get features such as the lift working, which eventually

        We'll be posting another post with our post-mortem thoughts, takeaways, deeper analysis, and some plans for the future.

        League Meet 2 Post-Mortem

        11 Dec 2023

        League Meet 2 Post-Mortem By Aarav, Krish, Jai, Sol, Tanvi, Alex, Vance, Georgia, and Anuhya

        Task: Analyze our performance at our 2nd League Meet

        After our performance at Meet 2, Iron Reign sat down as a team and discussed what happened. Here’s an overview of our takeaways and next steps as a team, divided into our strengths, weaknesses, potential threats, and opportunities/next steps.

        Strengths:

        • Our autonomous scored the purple pixel consistently when set up correctly. This significantly helped us with the tiebreaker and is a significant reason for our high ranking.
        • When it worked, the field-oriented drive was quite helpful and simplified things for the drivers.
        • When the robot functioned in tele-op, we could consistently and accurately cycle pixels to the backdrop.

        Weaknesses:

        • The transition to Teleop was unreliable because of a code bug we could not fix during the meet. Late code changes near our queue-up period meant we could not properly test them, and because of this, we sat still in Teleop for the last 3 matches.
        • Over the week of the meet, we burned through about 3-4 servos for the intake lift. We kept shattering their gearboxes through hazardous driving and not correctly setting up the robot. This isn’t sustainable, and we currently don’t have the budget to replace servos as they get destroyed.
        • Our init cycle at the beginning was too long and held up a couple of our matches, and we needed to remain aware and properly reset our robot each time.
        • Sizing remains a problem, mainly because we have little room for error. Even when our lift was slightly out, we failed to size and held up a match because of it. We need to focus more on sizing in the next iteration of the robot instead of being an afterthought until the night before a meet.
        • When we traveled under the door, the Scoopagon ran the risk of getting caught under the door if it was not entirely down. A way to combat this would be to create a travel position for the Scoopagon that can be toggled when moving under the stage door.
        • Wire management and the packaging of the robot are also issues with the current robot. The Scoopagon will often get stuck on the surgical tubing holding up the intake, the lift will de-spool, or wires will get caught on the chassis and unplug our servos. Issues like these end our matches, but we can fix this with a robot that is designed and visualized first.
        • Finally, in general, we have been behind as a team, especially on CAD for the next version of the robot, and that means more people getting involved to support our design efforts so that we can have the next version of the robot by Meet 3.

        Threats:

        • Our slow progress on V2 of the robot due to a lack of design participation.
        • There are fewer connection opportunities than in years before at this time.
        • A lack of funding, especially with the need to build an entirely new robot and deal with broken servos.
        • Becoming complacent with documentation and completing the portfolio at the very last minute.
        • Not expanding our industry connections and using them to get advice on our robot design.

        Opportunities and Next Steps:

        • We were able to get the hanging mechanism functioning the week before the meet, but we could not get it working at the meet. Specifically, it needs more angled support bars, and the motor placement needs to be redone, as they keep messing up pixel transfer. However, it did serve as a proof-of-concept, and we can adapt the same concept to the lift for the next version of our robot.
        • We could also experiment with a kinetic lift that uses the momentum of the robot instead of motors.
        • Similarly, we had a drone launcher that could score points the week of the meet, but when we attached it to the lift mechanism, it conflicted with the outtake and was too heavy. However, the concept is a strong starting point for incorporating a drone launcher into the next version of the robot.
        • The Scoopagon hinge currently wiggles and is not stable, so we need to replace it with a stronger material, such as carbon fiber.
        • A second hinge to allow the outtake to tuck away in a position that doesn’t interfere with as many components.
        • A new custom-designed chassis that is not built on rev rails and is lighter/faster will decrease our cycle times. It will also be designed with the complete robot in mind, helping deal with some of the packaging issues we have been facing.
        • A swerve drive is an idea that we could implement later in the season for maneuverability.
        • Adding the yellow pixel drop-off to our current autonomous routine
        • Automating driver paths and the intake/outtake articulations to reduce errors caused by the driver
        • Earlier and more consistent driver practice. This is important with a more straightforward game that requires robot performance.

        UPDATE: We did find out what the code bug was that messed up a couple of our matches. It was an error in the transition between the autonomous state and the tele-op state.

        Portfolio Workshop with 9161 from Aledo, TX

        06 Jan 2024

        Portfolio Workshop with 9161 from Aledo, TX By Tanvi, Aarav, and Anuhya

        Task: Give portfolio tips to 9161 Overload

        Today, Iron Reign held a portfolio workshop for team 9161 Overload from Aledo, TX. During this meeting, we presented our old Power Play portfolio page-by-page and relayed advice we have from our past experiences and meetings with professionals. We emphasized the importance of the balance between readability and detail along with formatting. We have learned that word usage and the layout of pages can impact how the content is relayed to the reader so we made sure to discuss with the team. Lastly, we participated in a Q&A session to answer all the questions the team had.Thanks to 9161 for letting us work with them!

        Mentoring FLL Teams

        10 Jan 2024

        Mentoring FLL Teams By Georgia, Sol, and Alex

        Task: Help the Sudie L. Williams Academy FLL teams

        Today we met with four FLL teams at Sudie L. Williams TAG Academy: the Code-iators (11978), Mechanical Mammoths (43326), Robotic Robloxians (51977), and the Artsy Armadillos (46872).

        We split up and had each team give a mock portfolio presentation to us as if we were judges. This not only let us help these FLL teams work on and improve their presentation skills, and give them feedback to further improve their presentation content, but also let us observe presentations to see how we could improve upon our own.

        We gave feedback on four categories: Research, Robot Game, Robot Design, and Core Values. After each section presentation, we would ask questions pertaining to the section. For example, for robot design, we might ask “Explain the most Innovative part of your robot and code” if they haven't already answered it. We took notes on how well they answered the question, and anything interesting in their answer.

        After we had asked our questions and finished judging, we went to give individual feedback to each of the teams we met with. The first part of this process was asking the teams what they wanted feedback on. Surprisingly enough, the teams had a good understanding of what they needed help with and asked some pretty insightful questions. Luckily, a lot of FLL portfolio knowledge applies to FTC, and we were able to answer their questions thoroughly.

        Next, we worked through a judging rubric with the teams, giving them scores, explaining why they earned that score, and explaining what they might be able to work on to raise each score.

        Additionally, we talked with the teams about FTC and Iron Reign, and answered their questions and any questions coaches/parents had.

        Overall, we had a great time helping these four teams, and we can't wait to meet with them again!

        Positioning Algorithms

        15 Jan 2024

        Positioning Algorithms By Jai and Alex

        Task: Determine the robot’s position on the field with little to no error

        With the rigging and the backdrops being introduced as huge obstacles to pathing this year, it’s absolutely crucial that the robot knows exactly where it is on the field. Because we have a Mecanum drivetrain, the included motor encoders slip too much for the fine-tuned pathing that we’d like to do. This year, we use as many sensors (sources of truth) as possible to localize and relocalize the robot.

        Odometry Pods (Deadwheels)

        There are three non-driven (“dead”) omni wheels on the bottom of our robot that serve as our first source of truth for position.

        The parallel wheels serve as our sensors for front-back motion, and their difference in motion is used to calculate our heading. The perpendicular wheel at the center of our robot tells us how far/in what direction we’ve strafed. Because these act just like DC Motor encoders, they’re updated with the bulk updates roughly every loop, making them a good option for quick readings.

        IMU

        The IMU on the Control Hub isn’t subject to field conditions, wheel alignment or minor elevation changes, so we use it to update our heading every two seconds. This helps avoid any serious error buildup in our heading if the dead wheels aren’t positioned properly. The downside to the IMU is that it’s an I2C sensor, and polling I2C sensors adds a full 7ms to every loop, so periodic updates help us balance the value of the heading data coming in and the loop time to keep our robot running smoothly.

        AprilTags

        AprilTags are a new addition to the field this year, but we’ve been using them for years and have built up our own in-house detection and position estimation algorithms. AprilTags are unique in that they convey a coordinate grid in three-dimensional space that the camera can use to calculate its position relative to the tag.

        Distance Sensors

        We also use two REV distance sensors mounted to the back of our chassis. They provide us with a distance to the backdrop, and by using the difference in their values, we can get a pretty good sense of our heading. The challenge with these, however, is that, like the IMU, they’re super taxing on the Control Hub and hurt our loop times significantly, so we’ve had to dynamically enable them only when we’re close enough to the backdrop to get a good reading.

        Meet Our Field Class

        18 Jan 2024

        Meet Our Field Class By Jai and Alex

        Task: Explain how we map the field and use it in our code

        A huge focus this season has been navigation; each scoring sequence spans the whole field: from the wing or stacks to the backdrop, and it’s crucial to make this happen as fast as possible to ensure high-scoring games. To do this, the robot needs deep knowledge of all of the components that make up the field.

        Enter: The Field

        Our field class is a 2D coordinate grid that lines up with our RoadRunner navigation coordinates. It’s made up of two types of components: locations & routes. Locations include our Zones, Subzones, and POIs.

        The field's red, blue, and green colors demarcate our overarching Zones. Zones are the highest level of abstraction in our Field class and serve as higher-level flags for changes in robot behavior. Which zone the robot is in determines everything from what each button on the robot does to whether or not it’ll try to switch into autonomous driving during Tele-Op.

        The crosshatched sections are our Subzones. Subzones serve as more concrete triggers for robot behaviors. For example, during autonomous navigation, our intake system automatically activates in the Wing Subzone and our drivetrain’s turning is severely dampened in the backdrop Subzone.

        The circles in the diagram are our POIs. POIs are single points on the field that serve mainly as navigation targets; our robot is told to go to these locations, and the navigation method “succeeds” when it’s within a radius of one of those POIs. A good example of this occurs in our autonomous endgame: the circle in front of the rigging serves as the first navigation target for hang and the robot suspends itself on the rigging at the lower circle.

        A combination of Zones, Subzones, and POIs play into our automation of every game, and our field class is crucial to our goal of automating the whole game.

        League Meet 3 Play-By-Play

        20 Jan 2024

        League Meet 3 Play-By-Play By Anuhya, Krish, Jai, Sol, Tanvi, Alex, Vance, and Georgia

        Task: Review our performance at our 3rd League Meet

        Today, Iron Reign had its third league meet. It was more successful than our last league meet, with more success with both the drone launcher and our autonomous code. Overall, we went 5-1 and ended up ranked 3rd due to our relatively high tie-breaker points. We ended up perfectly tying with the 2nd place team when it came to autonomous points, and we had a lower score than them for end-game. We saw huge improvements in driving from our previous league meets to this league meet, and learned many valuable lessons about being prepared for matches. However, before we look at some of our takeaways, here’s a brief play-by-play of our matches.

        Match 1: 77 - 23 Win

        We scored a 45 point auton this round, which is the highest we can score alone. We placed a purple pixel where it was supposed to go, but a bug that started happening with our auton so it could detect placement is that it starts spinning. This can lead to an issue because of how short the autonomous period is, but it wasn’t an issue here. We placed the yellow pixel on its appropriate location on the backdrop and then parked. Driving during the Tele-Op portion started out rocky and we hit the rigging a few times. We were also having issues working together with our alliance partner, as they ended up in front of the backdrop many times as we tried to score and they would be in the wings at the position we needed to be in. One of our wheels was also stuck in a pixel for the majority of the match, which is a problem that could easily have been avoided if we had side shields on the robot. Our alliance team got hung, resulting in our win.

        Match 2: 88 - 102 Loss

        We got a 28 point auton, where we placed the purple pixel correctly but the yellow pixel was on the wrong section of the backdrop. We also got parking. Our partner was a push bot but they could get the drone as well. We ended up getting a total of 6 pixels on the backdrop by the end of Tele-Op, and we got hang but couldn’t get the drone launched because the drone hit the rigging. Our opponent launched their drone, resulting in their win.

        Match 3: 106 - 31 Win

        Once again, we got a 28 point auton, where we placed the purple pixel correctly but the yellow pixel was on the wrong section of the backdrop. We also got parking. In this match, none of the other robots had an auton. During Tele-Op, we got a mosaic by placing an additional purple and green pixel. With the help of our alliance partner, Iron Core, we got 6 total pixels on the backdrop by the end of Tele-Op. By the end game, our drone had already fallen off, which was a great missed opportunity for points which remained throughout this entire league meet. The Skyhooks weren’t set up prior to the match, so they were already locked and we couldn’t hang. This showed us how much we need to have a pre-match checklist. We also got 30 points in penalties.

        Match 4: 67 - 17 Win

        We got a 6 point auton. The purple pixel missed the tape and the yellow pixel fell before it could reach the backdrop. We got parking, however. In Tele-Op, we knocked over the pixel stack so our alliance partner could pick up pixels from the ground. We scored a purple and green pixel in addition to a yellow pixel, resulting in a mosaic. The stage door broke as we went through the center because it was already bent and our robot hit the lowest part, resulting in it bending even further. While we were taking in new pixels, we dropped the drone. At the end of tTele-Op, we had a total of 4 pixels on the backdrop. In the end game, we hung but because our drone dislodged, we couldn’t score the drone. Our alliance partner got parking.

        Match 5: 112 - 29 Win

        We got a 26 point auton because we scored the purple pixel properly, but the robot dropped the yellow pixel because of the “spin sequence”, which ensures that we are pointing directly at the backdrop but takes too much time. We also got parking. In the Tele-Op portion, we hit the stage door but it didn’t mess us up too badly. Some traffic by the wings also slowed us down. We almost got a mosaic but there was a very small gap between two of the pixels, and all the pixels have to be perfectly touching to be a mosaic. We failed to try for a second mosaic even though there was time. We scored a total of 7 pixels on the backdrop, 1 on the backstage. In the end game, we scored the drone to get a full 30 points and we hung as well! This was our most successful drone launch of the league meet!

        Match 6: 85 - 34 Win

        We got a 25 point auton, with the purple pixel barely touching the tape. The robot did the “spin sequence” again, but timed out completely so the yellow pixel wasn’t dropped at all. We also got parking. In Tele-Op, we first scored the yellow pixel we couldn’t score because of the weird auton. One of our alliance partners also knocked one of our pixels off the backdrop. Placing one of the pixels resulted in a ricochet so we couldn’t score a mosaic. We had a total of 6 pixels on the backdrop by the end of teleop. In end game, we couldn't score a drone because the drone launcher wasn’t tensioned. This was the second match where we noticed this issue.

        We'll be posting another post with our post-mortem thoughts, takeaways, deeper analysis, and some plans for the future.

        League Meet 3 Post-Mortem

        22 Jan 2024

        League Meet 3 Post-Mortem By Aarav, Krish, Jai, Sol, Tanvi, Alex, Vance, Georgia, and Anuhya

        Task: Analyze our performance at our 3rd League Meet

        After our performance at Meet 3, Iron Reign sat down as a team and discussed what happened. Here’s an overview of our takeaways and next steps as a team, divided into our strengths, weaknesses, opportunities, and potential threats.

        Strengths:

        • Pretty consistent robot performance as we went 5-1 and were able to score points in all 3 games stages
        • Improved mosaic scoring
        • More accurate when scoring pixels on the backdrop and when dropping pixels off during auton
        • Good time management. Less last-minute code changes or queue delays

        Weaknesses:

        • Goofy, careless mistakes
          • Not loading drone for launch
          • Not setting up skyhooks
          • Not having a writtenm checklist to go over before match starts
          • Robot spinning around in auton
        • Occassional mishap when placing pixels on the Backdrop
        • Unreliable drone launcher. Only cleared the game walls once

        Threats:

        • Not having PPE V3 built or coded in time
        • Less innovative design compared to older iron Reign robots
        • Giving up on R2V2 and Mechavator videos
        • Slacking and not getting portfolio done on time/rushing it the week before Tournament

        Opportunities:

        • Cleaning up our minor mistakes(ex. Pre-Match Checklist)
        • Portfolio and Presentation
        • Connect Meetings for Feedback
        • Motivate Opporunities

        Meeting with the Director of R&D at Hoya

        26 Jan 2024

        Meeting with the Director of R&D at Hoya By Tanvi, Aarav, Anuhya, Jai, and Alex

        Task: Meet with the Director of R&D at HOYA

        Today, Iron Reign met with the Director of R&D at HOYA ITC, Abhi Patnaik. This meeting was focused on discussing the team’s portfolio and materials usage. We presented our work and participated in a Q&A style period to receive feedback, including on our own presentation styles.

        Takeaways

        Portfolio

        Overall, we lacked proper presentation practice and this was very evident during the meeting. We were advised to put more effort into practice beyond only our individual lines. When presenting we were often redundant in some of our vocabulary (ex. Carbon Fiber) which took away from the presentation by creating a monotonous tone. We were advised to make our wording more diverse. Similarly, we were advised to be less redundant in our content as we brought up events such as Ri2D too much. For more readability, we were encouraged to make our portfolio less “wordy” and include more labels on diagrams, because judges don’t have time to read paragraphs on each of the slides. Each of the presenting members received personal presenting advice such as avoiding the statement “if we had more time”, focusing on positives more than negatives during questions, being consistent in explanations, and more!

        Materials

        Throughout this season we have struggled with various material components of our robot, and implementing feedback we received was very helpful. We were advised to create a materials database for new members and consistently do stress analyses to reduce strain on our materials. Regarding our concern about string strength, we were encouraged to check string materials for reliability before using them, because we have such high quality materials everywhere else on our robot. We also discussed friction caused by carbon fiber and how to ensure our 3D printed parts also had less friction, possibly by changing the direction of the print on the topmost layer to align with the movement.

        Meeting with the Director of the Dallas College STEM Institute

        27 Jan 2024

        Meeting with the Director of the Dallas College STEM Institute By Georgia, Anuhya, Sol, Aarav, Krish, Alex, and Jai

        Task: Meet with the Dallas College STEM Institute

        Today, we met with Dr. Jason Treadway, Director of the Dallas College STEM Institute and a former structural engineer. We virtually presented our progress throughout the season, demoed our robot, and shared our work on Mechavator and R2V2. From him, we received valuable feedback about our robot design and game strategy.

        We started by detailing the CenterStage game and highlighted the point scoring opportunities that we focused on. Starting from our work at Robot in 2 Days, we talked about how we iterated our robot up to the current version, mentioning components like scoopagon, our intake pixinerator, and the skyhooks.

        Dr. Treadway is a structuralist engineer, so much of the Q&A was about our engineering and material choice. We discussed the amount of stress placed on the robot(especially when he hung on the rigging), and he gave us advice on how to lessen this issue, such as reducing the weight of the robot. We showed him our design for a future iteration of our robot, which will be made of carbon fiber in order to reduce the size (and weight) of the robot, as well as adding stability. This feedback will be especially valuable for hanging, which puts a lot of weight on our robot.

        Additionally, we talked about our outreach and motivate efforts with Dr. Treadaway and showed him our summer project, R2V2, and our efforts to automate it and revitalize it. We shared the railers we made and specifically focused on our efforts to incorporate object-tracking.

        Overall, it was a very informative session and we thank Dr. Treadway for his time and advice.

        U^2 Tournament Play-By-Play

        04 Feb 2024

        U^2 Tournament Play-By-Play By Aarav, Anuhya, Krish, Jai, Sol, Tanvi, Alex, Vance, and Georgia

        Task: Review our performance at the U^2 Tournament

        Today, Iron Reign competed in our U^2 League Tournament. We won Think 1 and Inspire 2, advancing us directly to the North Texas Regionals competition on February 24th. Although we could not get V3 of Purple Pixel Eater(our robot) built in time for this competition, we performed well on the field and in judging. But, there will be a post-mortem that goes into more detail about our analysis and identifies areas of improvement. For now, this post will focus on a summary of our judging efforts and matches.

        Judging:

        Unfortunately, we did not practice our presentation as much as we should have the week before the competition, but a late judging slot gave us time to practice beforehand. Overall, our judging session was pretty strong, but we struggled with rambling too much and talking too quickly. This led to our judges not understanding everything we said and not being able to ask all the questions they wanted. We still got a solid number of judging panels in the pit though.

        Matches:

        Match 1: 88 to 40 win

        We scored a 45-point auton, placing both the purple and yellow pixels and parking in the backstage area. Then, at the start of teleop, we initially waited for our opposing alliance to move before scooping up the purple pixel placed in auton and scoring it next to the yellow pixel. Then, we cycled multiple yellow pixels but regularly conflicted with our alliance partner. However, while crossing the stage door, we dropped our drone, which would continue throughout the day. Overall, we scored 7 pixels and 1 mosaic in teleop. In endgame, we did not hang because one of the skyhooks twisted up too early because of incorrect tensioning, and we lost our drone, so we could not score that either. It was a comfortable win, and we also decided that if we were ever allied with a push bot again, they could knock pixel stacks down and bring us pixels to score.

        Match 2: 66 to 17 win

        In this match, auton ran properly, but we got caught on the team element, leading to us losing our position and not scoring anything. Our team element was too stiff and did not slide properly, which we must fix. On a positive note, our alliance partner did manage to park. Then, we lost significant time at the start of teleop initializing our robot before the outtake stopped working, most likely because of something with the servo or lift. We lost the drone again, and in endgame, we hung. Overall, it was a solid win, but our performance left a lot to be desired.

        Match 3: 68 to 64 win

        We correctly placed the purple pixel in auton but missed the yellow one. Throughout the match, we struggled with poor coordination and rushed driving. We constantly rammed into the walls and collided with the rigging, leading us to lose our drone again. During intake, poor pixel placement and rushed attempts ended with us not entirely securing pixels. Our alliance team also descored a couple of pixels, which was unfortunate. In endgame, we hung. Our drive team struggled in this match and was under constant pressure from our alliance team. We need more support and direction from our coach to help our driver Krish focus and not have to strategize himself. Luckily, we squeaked out a narrow win.

        Match 4: 64 to 63 loss

        In a poor display of game awareness, we forgot to load our drone before the match. This could easily be rectified with a pre-match checklist. In auton, we scored purple but missed the yellow pixel. We struggled with driving and coordinating with our alliance partner in this match. Throughout the match, opposing robots constantly blocked our wing, limiting us to scoring only 4 pixels in teleop. In endgame, we missed hang and could not launch the drone because we forgot to load it before the match. After the match, we went to contest the match and advocated for the referees to penalize our opposing team for blocking our access to the intake. After much discussion, our opponent was penalized 20 points(two minor penalties), which was not enough for us to win the match, as we lost 1 point. Throughout this match, we observed that our outtake was moving too fast(leading to missed pixels). We also saw how our lack of flexibility with intake positions(we could not pick up from pixel stacks) hurt us in a match scenario since the wing was blocked off.

        Match 5: 94 to 94 tie

        In auton, we scored both the purple and yellow pixels. However, in teleop, we got our intake stuck on the wing tape, which made it difficult to intake pixels. Despite this, we scored 1 green, 1 purple, and 2 white pixels(just shy of a mosaic). In endgame, because of time-wasting and our driver pressing the wrong button, we missed hang. This was a major mistake since the match ended in a tie, and hanging would have gotten us the win. Issues like this indicated the strategy oversights we consistently made during this tournament. By the end of the qualifying matches, we were ranked 4th, going 13-1-1.

        Match 6: 73 to 66 win

        We were selected by the 2nd seed(22008 RoboBison Knowledge) to join their alliance for the elimination matches. In the first semifinal match, our auton was delayed, and we scored nothing. In teleop, yet again, our drone was dislodged while we traveled through the stage door. We picked up a green pixel from the wing and went to score a mosaic with the pixels our alliance partner had placed. Even though one of the skyhooks was tensioned wrong in endgame, we still managed to hang. We won the match and went up 1-0 in the semifinals. However, our alliance partner broke a servo during this match, which meant they would be out for the next match.

        Match 7: 26 to 64 loss

        In the 2nd semifinal match, our auton did not sense the team prop and thus scored the pixel in the wrong position. At the beginning of teleop, our drive team accidentally started our auton, which led to us wasting time and banging into the rigging. During the match, our struggle continued as we kept missing pixels when intaking from the wing. Even in endgame, hang did not work, and we lost the drone again. Overall, this sloppy match allowed the opposing alliance to even things at 1-1.

        Match 8: 123 to 114 win

        In the final match of the semifinals, we were partnered with RoboBision Knowledge. We missed both pixels in auton and accidentally ran into our alliance partner. However, in teleop, we scored multiple pixels(even though we missed a mosaic) along with our partner. In endgame, we hung and managed to launch the drone but it did not clear the field wall. We won due to a clutch set bonus we gained during teleop, sending us to the finals.

        Match 9: 255 to 100 loss

        This match turned out to be a tough loss. Our auton did not detect the team prop again, and we could not keep up with our opponents' cycle times. We started 35 seconds late in teleop and got penalties for going into our opponent's backstage and knocking over a pixel stack. We didn't hang, and the drone fell off again. After this match, we were replaced by the 2nd pick in our alliance for the 2nd match, which we lost. Regardless, we were delighted with our robot performance, finishing as the 1st pick of the Finalist alliance, which advanced us to Semi-Regionals.

        Pit Interviews

        Throughout all the robot action, we received 4 pit interviews from the panels for Design, Innovate, Connect, and Motivate. We discussed our plans to rebuild our robot and why we were not at that stage yet. We also discussed our team's non-technical parts.

        All of this culminated in us winning Inspire 2 and Think 1 at the awards ceremony, which sent us straight to the North Texas Regionals. This gives us 4 weeks to build PPE V3 and get it working to advance to UIL and State. Stay tuned for our post-mortem post detailing our analysis of this event and highlighting a few key takeaways.

        U^2 Tournament Post-Mortem

        05 Feb 2024

        U^2 Tournament Post-Mortem By Aarav, Krish, Jai, Sol, Tanvi, Alex, Vance, Georgia, and Anuhya

        Task: Analyze our performance at the U^2 Tournament

        After we advanced to Regionals by winning Inspire 2, we sat down as a team and discussed our performance as a team. Although we advanced, we are not as far as we want, with PPE V3 not built. If we want to advance to State, we need to show up to Regionals with a fully-built V3 that hopefully works. With that being said, here’s an overview of our takeaways as a team, divided into our strengths, weaknesses, opportunities, and potential threats.

        Strengths:

        • Transfer between outtake and intake worked efficiently
        • Strong pit interviews. Were able to engage the judges and cover our main points. Can still be improved
        • Virtually no coding during the meet, which is a welcome change
        • Implemented a driver checklist by the end, which should help us in the future
        • Skyhooks displayed a surpising amount of reliability

        Weaknesses:

        • Dislodging of drone when we hit obstacles
        • Difference in skyhook tensions (ex. Types of rubber bands) (get blue rubber bands!)
        • Rushed portfolio(completed mainly during the week before)
        • Lack of communication in presentations and a lack of practice
        • Talking too fast in the presentation
        • New team props did not have prior testing with the robot
        • Subpar and inconsistent auton by our standards
        • Starting auton/teleop multiple times, messing up field position and driver controls

        Opportunities:

        • New redesigned robot(PPE V3)
        • More Fundraising/Connect/Outreach
        • New organizational system in Clickup
        • More driver practice
        • Banners/Posters/Booth
        • Less content in presentations so we can talk slower
        • Distributed speaking topics
        • More presentation prep(specifically for questions)

        Threats:

        • Falling behind on blog
        • Time management
        • Auton
        • Not finishing PPE V3 in time

        Next Steps

        Get to work cutting and assembling PPE V3 and working through any design flaws. Start working on aotnomous teleop navigation in code and adapting to the new chassis. Documentation wise, we need to update both the portfolio and presentation, and work on connecting with local engineering professionals.

        Mentoring FLL Teams at Sudie

        08 Feb 2024

        Mentoring FLL Teams at Sudie By Tanvi, Georgia, and Fernando

        Task: Help the Sudie L. Williams Academy FLL teams

        Today, 3 Iron Reign team members met with three Sudie L. Williams FLL teams to provide feedback on the presentation. Each member was assigned a team to guide throughout the meeting. The teams were Code-iators (11978), Robotic Robloxians (51977), and Mechanical Mammoths (43326).

        We focused our feedback on 4 major categories: research, robot game, robot design, and core values. Each team decided which presentation to show us and we acted as mock judges to create a realistic atmosphere. We were each given judging rubrics to note growth points, which we shared with the teams for their future use. This was great preparation for their upcoming meet. The teams did a wonderful job and their dedication to FLL was very clear! Their presentations/projects were very creative and on theme. We did notice a few things the teams could work on, such as making more eye contact and being more familiar with their scripts. To help out with this, we encouraged the kids to understand the gist of their lines more than the exact wording so that they can relay the content without getting caught up with the specifics of the script. After we provided feedback for their presentations, many members of the FLL teams asked us individual questions regarding future FIRST opportunities in FTC. We were able to share our experiences and encouraged them to join an FTC team in the future.

        Overall, major thanks to the Sudie Academy for allowing us to help out and we wish their FLL teams the best for their upcoming tournament. We had a fantastic time and look forward to meeting with them in the future!

        Meeting with the Stanford Salisburg Lab

        09 Feb 2024

        Meeting with the Stanford Salisburg Lab By Aarav and Nalin

        Task: Meet with the Salisbury Robotics Lab and discuss their work

        Today, Iron Reign met with four members of the Salisbury Robotics Lab at Stanford University. During this meeting, we discussed project ideation and making the design process more efficient. One piece of advice we received was to split the design process into three parts: synthesis, analysis, and judgment. The synthesis portion is creating the model/design after initial ideation. The analysis portion is theoretically testing the design’s ability. The judgment portion is deliberating what needs to be changed in the design. In addition, they answered design questions we had from this season. Lastly, the members of the lab discussed their work in bio-robotics and remote surgery! Many of our team members are interested in biomedical engineering as a future career path, so this was a great opportunity to learn about the work being done in that field. We thank these mentors for taking the time to work with us!

        Lessons We’ve Learned Switching from CAD to a Physical Model

        27 Feb 2024

        Lessons We’ve Learned Switching from CAD to a Physical Model By Anuhya, Sol, Krish, and Fernando

        Task: Overview the issues with PPE V3 and the changes that need to be made.

        This past weekend, we had our regional competition! We were incredibly fortunate to have gotten Inspire 3 and were the 5th advancements to the FTC Texas State Championship in a couple weeks! However, we went into Regionals with a robot we had barely finished building due to an incredibly long design season, and we had barely any robot game, except for our Skyhooks. There were also a lot of challenges that came up as we built our robot from machined parts. Here are some of the problems we noticed and steps we are going to take to fix them.

        Intake (Pixinerator):

        • The new robot is way too wide, the two main causes are 1. Intake width and 2. Electronic plate wiring(where the control & expansion hub are mounted)
        • Solutions:
          1. We can narrow the intake because the current size is completely random (<3 pixels, >4 pixels) and it probably won’t have the worst repercussions
          2. Drivers may decide that the width isn’t an issue because of the new corner deflectors and we can continue using this iteration of the chassis
        • Pixinerator is intaking unevenly (thinner carbon fiber plate isn’t as rigid as the 2 mm aluminum plate we were using initially, the side without servo power isn’t being pushed into the mat with enough force)
          • Routing cables also needs to be improved, not enough space for a second servo because of how things were routed
          • Solution: Use two intake servos as opposed to one so both sides of the Pixinerator will receive servo power

        Outtake (Ralph):

        • Ralph is getting caught on the surgical tubing used to assist Pixinerator
        • Solutions:
          1. Possibly move the surgical tubing to the inside of the nacelle (side wise) and attach to back plate
          2. Create new attachment point for longer bolts which attach further back on the Pixinerator side plates so it doesn’t interact with the inside of the nacelles
        • Many issues occurred with Crook moving while we were trying to outtake pixels(electrical problem, bad connection between the Crook servo) → we generally have wiring problems/power injection problems, need to be sorted out
        • Hinges and Clamps (Joints)
          • The carbon fiber tube clamps allow sideways movement → too much wiggle (cf tubes are not held square towards robot)
          • Pillow blocks and how they accepted bearings also had a lot of wiggle
          • Solutions:
            1. Switch over to using bearing blocks as opposed to bearings
            2. Possibly moving the REV bearings to the inside of the pillow blocks to lock them in place
          • Nothing is retaining the axle on far side of pillow blocks (axles twisted and slid)
            • Solution: Switch to using locking hubs

        Chassis:

        • Support for cable management/cable runs was not properly considered by design team because of a time crunch
          • Hand-held drilling may be our only option
        • LEDs
          • Back camera LEDs need a place to mount to as well as wiring and battery solutions
        • Battery Compartment
          • Current battery compartment “door” doesn’t open fully because the back plate doesn’t have enough clearance
          • The hinge for the battery compartment is incorporated within a structural element which results in a very weak design
          • Solution: Redesign battery compartment door so it can open fully and is stronger

        Dock:

        • Dock flaps were interacting with Pixinerator when it is completely vertical
        • The forward boundary for Ralph wasn’t effective in real life even though it looked like it was in CAD. It also doesn’ seem necessary because Ralph can bottom out by itself
          • Parallel alignment with Pixinerator can be done w just pins instead of forward wall
          • Either it retains pixels or the pixels will slide out of robot by way of dock so we won’t get penalized
        • Passive dock roof doesn’t seem feasible → just too many problems :(
          • Solution: Possibly attach dock roof to inward facing inner nacelle walls, operated by micro/mini servos
          • Test high speed intake to see what kind of hand-held roof placement prevents pixel ricochet
        • Bridge needs to be 8-10 mm lower because Scoopagon doesn’t get low enough to intake from pixel stacks
          • Solution: pacers can be printed which go between the L beams that connect the bridge and the inner nacelle walls
        • Camera was too high: it could not see when scoopagon was up and could not interact when scoopagon came down
          • Solution: We need to redesign a front camera mount and possibly illuminate it

        Drone Launch:

        • Drone clamp is too weak, doesn’t stop the drone from being knocked off the robot by rigging or interaction with anoth
        • Solution: Drone clamp should cover at least half of the drone, or double as a hangar for the drone - cover it completely
          • Physical prototype and test first

        Skyhooks:

        • Still having rubber band/tensioning issues but that’s more of a set-up thing, doesn’t necessarily need a design change
        • Had to abandon the concept of the limit switches to detect when they're fully up due to having to manually drill holes to increase clearance of Skyhooks with Pixinerator side plates
        • Mount the IMU

        DPRG Presentation Review Meeting

        27 Feb 2024

        DPRG Presentation Review Meeting By Aarav, Nalin, Anuhya, Elias, and Jai

        Task: Meet with the DPRG and review our judging presentation

        Today, Iron Reign mock-presented at the DPRG weekly meeting and received tons of valuable feedback. We went through our typical presentation for competition, albeit at a slightly slower pace (we took about 7 minutes as opposed to the traditional 5). After the presentation, we had a long review session where we went through the presentation again and all the DPRG members gave input on how the presentation could be improved.

        Some of the major issues include unclear labeling on CAD models, slides with too much information, and a lack of pictures on certain slides. Major thanks to DPRG for helping us out in improving our presentation before we head off to the States.

        2nd Meeting with the Director of R&D at HOYA

        29 Feb 2024

        2nd Meeting with the Director of R&D at HOYA By Aarav, Anuhya, Sol, Krish, Jai, Elias, and Fernando

        Today, we had our second meeting this season with the Director of R&D at Hoya, Abhi Patnaik. This past weekend, Mr. Patnaik was able to attend the North Texas Regional Championship, where he watched our robot and many others in action. Our meeting today mainly consisted of a Q&A session where Mr. Patnaik asked us questions about choices we made on our robot, why we made them and possible solutions to problems he saw at the tournament.

        The first question Mr. Patnaik asked us was about our intake. At the tournament, even when the Pixinerator tank tread was moving, it wouldn’t intake pixels or would only intake pixels from the left side. However, we had already solved this problem by using two intake servos as opposed to one intake servo, because our issue was due to the bottom intake plate not pushing into the playing field with enough force. He also recommended sanding the tip of our intake plate down like a knife so it sits completely flat to the playing field as opposed to at an angle.

        He then asked us questions about our outtake and how confident we were in its ability to score pixels. We told him that this iteration of outtake was an incredibly new addition to the robot, and we were confident in the previous iteration and Scoopagon, specifically, but the changes we made, such as adding a new passive hinge, the Twist, as well as two new actuated hinges, the Lift and Wrist, were so we would have increased reliability and be able to score from more angles. He told us to pay attention to be careful about the amount of jerk on Outtake, especially because there are a lot of vibrations when it takes in pixels and deposits them onto the backdrop.

        Finally, Mr. Patnaik commended us on our use of carbon fiber because it’s great at shock absorption and is very sturdy, which was a problem we had discussed in our previous meeting.

        Main Takeaways:

        The most important things he said to work on were to make sure our intake actually works, whether that means ensuring the 2 servos work or switching back to a 2mm aluminum bottom plate. Organizing cable management will also be very important, ensuring that we’re using the minimum viable wire length instead of having a lot of extra length on wires. We also need to account for inertia in our outtake.

        Meeting with a Program Management Director at Lockheed Martin

        08 Mar 2024

        Meeting with a Program Management Director at Lockheed Martin By Anuhya, Sol, Krish, Elias, Alex, Nalin, Fernando, and Aarav

        Task: Meet with the a professional from Lockheed Martin for advice

        On March 8th we had a meeting with Luis Sanoja, a Program Management Director of Precision Fires Development and Transformation at Lockheed Martin, with a mechanical focus. Our plan for this meeting was to introduce him to the CenterStage game and talk about particular strategies we have, as well as running through our engineering and code processes.

        When running through our presentation, he was proud of us for showing our preliminary ideas because they showed we had a plan before moving forward and designing our actual robot. We also talked through our thought process of our intake and outtake, including why we have so many degrees of freedom.

        We also talked through our code, including the number of sensors we have as well as how our navigation and pathing works. He was impressed about our robot performance when we don’t use too many sensors, especially because of our field-oriented drive.

        Next Steps

        Most of the notes we got were on our presentation. We were told to add labels on the ideation slide for more readability. On the diverter slide, we need to show diverter action, so we added a pixel. Similarly, to show twisting motion in the scoopagon, we added an indicator. We were told to update all the videos on intake to outtake so they no longer show v1 of the robot. We added the degrees of freedom to the “Ralph” slide and updated the desmos model in the slides. We were told to change the corner deflector to an overhead shot to make it more meaningful. We were advised to redo the transfer to show the path of the pixel, add pixel sensors, use the term relocalization more, indicate how many parts we make by making a slide which includes all our 3D printed and CNC’d parts, show mecanum location correction, and change the CAD of the drone launcher to a side view. Lastly, we were told to put a lot more work into the autonomous slide.

        Support for the FTC State Championship

        11 Mar 2024

        Support for the FTC State Championship By Aarav and Anuhya

        Iron Reign’s state bound! At NTX Regionals, we proudly got Inspire 3, and were the 5th advancement to FTC Texas UIL and the State Championship! With the State championship coming up in only a few weeks, we have a lot of work to do to get our robot up to par, including buying new parts and increasing our outreach efforts. New motors and servos are expensive, and we want to put more money into sustaining our program past just this season. However, we need your help and support to do so.

        While we welcome donations any time of the year, they are especially appreciated as we prepare for this upcoming challenge. Any and all support is deeply appreciated, including warm wishes and DMs on our Instagram account. If you have any questions, feel free to reach out via email at ironreignrobotics@gmail.com or through our instagram, @team6832.

        Thank you for all your support and we hope to see you cheering us on at FTC State and beyond!

        Applying Forward/Inverse Kinematics to Score with PPE

        12 Mar 2024

        Applying Forward/Inverse Kinematics to Score with PPE By Elias and Alex

        Task: Explain how we use kinematics to manipulate PixeLeviosa (our Outtake)

        This year’s challenge led Iron Reign down a complex process of developing an efficient means of scoring, which involved the interaction between the intake and outtake. Currently, we are in the process of implementing Forward and Inverse Kinematics to find and alter the orientation of our outtake, known as PixeLeviosa.

        Forward and Inverse kinematics both revolve around the part of a robot’s subsystem, known as the end-effector, which is essentially what the robot uses to score or achieve certain tasks (that being PPE’s scoopagon). The simple difference between forward and inverse kinematics is that forward is the method of find the end-effector’s position given the angles of each respective joint and using geometric principles to find its position from there, whereas inverse kinematics has you finding the angles of each joint given the position of the end-effector. Typically, one will use the methods and formulas derived from forward kinematics to then apply them for inverse kinematics.

        For PPE, we use inverse kinematics to set PixeLeviosa’s orientation given a point in relation to the backdrop such that the outtake maneuvers itself for effective scoring and reducing cycle times. We hope to have this fully fleshed out by State!

        Contact Us

        E-Mail: ironreignrobotics@gmail.com Website: In the address bar