Articles by tag: think

Articles by tag: think

    Finishing the Chassis

    Finishing the Chassis By Kenna and Janavi

    Task: Build a Chassis

    We have been working on this chassis, on and off, for over three months. Just about every part of it has been built, disassembled, and rebuilt more than twice. In out last post, we had thought the wheels were ready to go. However, various parts had been put on backwards or were unusable so we had to do everything over again. Once we had rebuilt, we realized that there were even more issues. So we fixed those and built them again. Both of us could probably assemble wheels, motors, and chains in our sleep.
    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. After a short search, we found it in a box of 3D-printed parts whose prime was long over. 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. Though it was a pain to build and rebuild every aspect of the chassis, we gained a lot of building experience out of one robot. We chose a relatively difficult design to built for the first time but, in the end, it was functional and that's all we can really ask for.

    Next Steps

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

    UIL 2018

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

    Task: Attend the 2018 UIL Robotics Competition

    Background

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

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

    The Night Before

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

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

    The Day Of

    We walked into the tournament, tired, but excited for the last tournament of the season, led by our two robots, Kraken and C.A.R.T. BOT. Kraken is our Relic Recovery robot; a tank on wheels with specially cut aluminium 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 suprising 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, its 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 standin.

    We started off the day amazingly, 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. Somehow, 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 "alliance unreliability," meaning that the gremlins inside of our robot started acting up

    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, and UIL realizes this, so all of the awards are "funny" awards.

    Next Steps

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

    Swerve Drive Experiment

    Swerve Drive Experiment By Abhi

    Task: Consider a Swerve Drive base

    During the entire season of Relic Recovery, we saw many robots both in and outside our region that had a swerve drive. As Iron Reign, we never considered a swerve drive in the past but seeing all the robots, I wanted to see if it was maybe possible. One motivation was that I didn't like how slow mechanums were. Swerves generally use traction wheels and create a faster speed than usually can be found with mechanum. Also, it seemed as if swerve could provide the mobility neccessary that a mechanum drive provided. This is why I wanted to consider the possibility of a swerve drive and why I did more investigation.

    I first came across the PRINT swerve for FTC by team 9773. They had a very detailed explanation of all the parts and assebly tools. After reading into it more, I decided that the system they created wasn't the best. 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 didn't work for some reason after playing with it over the summer or if the chassis didn't make sense to use in Rover Ruckus, we would have almost no money for an alternate drive train since we wanted to presearve Kraken. Also, they parts used by 9773 invovled X-rail rather than extrusion rail from REV. This would cause problems in the future as we wold need to redesign the REVolution system for X-rail. In the end, I decided this was not worth it to pursue.

    After further investigation, I found a chassis by team 9048. The swerve they developed looked like a more feasible option. By using REV rail and many of the parts we had, I thought this would be a possible prototype for Iron Reign. 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. But I am still motivated to find a way to make this happen.

    Next Steps

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

    Swerve Drive Prototype

    Swerve Drive Prototype By Abhi and Christian

    Task: Build a Swerve Drive base

    During the discussion about swerve drive, Imperial robotics, our sister team, was also interested in the designs. Since we needed to conserve resources and prototype, 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. This system would be mounted to a square base. We decided to go ahead and make the base.

    Immediatly 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 train 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.

    Next Steps

    Wait until Rover Ruckus starts so that we can think of a new chassis.

    Big Wheel Ideas

    Big Wheel Ideas By Janavi

    Task: Create a Unique Chassis

    This summer we are working on creating unique chassis that we havent gotten the opportunit to try before. Often we choose safe bases opting for ones that we have tried in the past and know work. But though taking the opporunity to explore unique bases we now hare able to see how less commonly uses bases fare on the field. One of our ideas is for a two wheel robot, to be clear there would be four wheels on the robot but two of the wheels would be significantly larger and the purpose of the two smaller wheels would be to stop the body from dragging on the floor. I think that this robot with two wheel would be a good possile chassis for the upcoming season beacuse while we dont know the upcoming challange we do know that our new robot has to be light. Therefore a robot with only two motored wheel would weigh much less than our current mechanum chassis of four motored wheels

    Next Steps

    To create this chassis we are planning on using two lightweight wheels along with a square body made out of polycarb. We plan to minimize metal in our design rather opting for materials that are just as functional but weight less.

    CNC Machine Rehab 1

    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.

    Position Tracking

    Position Tracking By Abhi

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

    Throughout the Relic Recovery season, we have had many issues with the autonomous being inaccurate simply because the scoring was dependent on perfectly aligning the robot on the balancing stone. This was prone to many issues as evidenced by numerous matches in which our autonomous failed. Thus far, we had relied on the encoders on the mecanum chassis to input distances and such. Though this worked to a significant degree, the bot was still prone to loss from drift and running into the glyph pit. We don't know if glyphs will be reused or not but we definitely needed a better tracking mechanism on the field to be more efficient.

    After some investigation online and discussing with other teams, I thought about a way to make a tracker. For the sake of testing, we built a small chassis with two perpendicular REV rails. Then, with the help of new trainees for Iron Reign, we attached two omni wheels on opposite sides of the chassis, as seen in the image above. To this, we added axle encoders to track the movement of the omni wheels.

    The reason the axles of these omnis was not dependent of any motors was because we wanted to avoid any error from the motors themselves. By making the omni wheels free spinning, no matter what the encoder reads on the robot, the omni wheels will always move whichever direction the robot is moving. Therefore, the omni wheels will generally give a more accurate reading of position.

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

    Next Steps

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

    Chassis Flyer

    Chassis Flyer By Ethan

    Kraken

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

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

    Iron Reign uses two design processes in conjunction with each other to create efficient and reliable parts. First, we use the Kaizen design process, also used in industrial corporations such as Toyota. The philosophy behind Kaizen is the idea of continual improvement, that there is always some modification to each system on our robot that will make it more efficient or more reliable. As well, design competitions are a focal point of Iron Reign’s design process. In these design competitions, team members choose their favored designs that all complete some field challenge, and build them individually. Upon completion of each mechanism, the designs are tested against each other, considering weight, maneuverability, reliability, and efficiency.

    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

    Technicbots Chassis Project - July Meeting

    Technicbots 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 Technicbots' 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.

    C.A.R.T. Bot Summer Project

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

    Task: Enhance our robot-building skills

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

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

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

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

    Next Steps

    Our cart box isn’t done yet, as we intend to make a mount for a solar panel, which we will be able to charge the cart during the downtime in competitions (only if there’s a good window we can park it next to). The cart wasn’t just about having a cool new and improved cart that we don’t have to push (which it is), it also was a test of our engineering skills, taking things that never should have been and putting them together to make something that we will utilize every competition. We learned so much during this experience, I for one learned how to wire something with two batteries as not to destroy the system, as for everyone else, I can’t speak for all but I think we learned a very important lesson on the dangers of electricity, mainly from the height of the sparks from an accidental short that happened along the way. Despite this, the cart came out great and moves smoother than I ever could have hoped. The thing is a real blast and has provided a lot of fun for the whole team, because yes, it is rideable. 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.

    Garchomp Part 2

    Garchomp Part 2 By Janavi and Kenna

    Task: Build the Chassis

    So, we thought we finished but we were wrong, oh so wrong. As you saw in our last post, we thought our chassis was functional. However, after leaving it alone for over a week, Garchomp decided that it didn't want to work any more and 3 out of 4 of the chains came off. First, Kenna and I sat and cried.

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

    We decided to replace the tetrix rails. First we loosened all of the screws on the current bar, carefully slid it out, and replaced it with new bars. This solved one of many problems that we had somehow missed when building our chassis. After fixing all of the chains and confirming that each of them were individually working, we re-attached all of the cables to the robot and ran the code. We discovered that not all of the wheels were running at the same speed because our robot kept on moving in circles. After checking that the motors were working, we discovered that it was our encoder cabels that were plugged in wrong. But finally... After fixing that, and after many, many hours of trying to fix the chassis, we finished! Now, I think, we can safely say our chassis is complete.

    Next Steps

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

    My Summer at MIT

    My Summer at MIT By Abhi

    Task: Spend a Summer at MIT

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

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

    The work I was doing was very intensive. I applied the algorithms we were being taught to a number of situations. One week, I was analyzing physiological signals to determine the state of sleep. The next week, I was training models to detect breast cancer from mamograms. 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.

    BigWheel CAD

    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.

    Bigwheel Presentation

    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 Teas 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 extarnal gear ratio, so we can get more speed out of it.

    Garchomp Presentation

    Garchomp Presentation By Janavi and Kenna

    Task:

    After months and months of Kenna and I working on our chassis, all of our work finally accumulated in our presentation. We participated in the Chassis Presentation workshop hosted by technicbots for teams all around the North Teas region to work on one or more chassis, perform various tests with them and then present their findings. We presented our Chassis Garchomp who is 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 alligned 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 wooded sides instead of the aluminium sides that Kraken used our wheels became misaligned to the who different types of wood used for the two sides.

    Our robot is not able to turn relatively fast but as can be seen on Kraken it is able to hold alot of load and move at a constant speed

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

    Post Kickoff Meeting

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

    Meeting Log September 08, 2018

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

    Today's Meet Objectives

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

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

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

    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 condsider 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. Yay! Clean practice field and more tools!

    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

    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 codebase that we don't really need to update it any further.

    Next Steps

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

    Testing Intakes

    Testing Intakes By Ethan, Evan, Aaron, and Freshmen as to be determined

    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 seperating the different kinds of game elements, and it may be too slow to feasibly use. But, its a first step and we'll see what happens.

    Rover Ruckus Strategy

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

    Task: Determine the best Rover Ruckus strategies

    Challenge Game Timing Points Level of Difficulty (1 - 3 [hard]) Priority Idea
    Landing Autonomous 30 2 Medium
    Claiming Autonomous 15 1 High
    Parking Autonomous 10 1 High
    Sampling Autonomous 25 2 Medium
    Latching End Game 50 3 High
    Robot in Crater End Game 15/25 1 High
    Mining [Depot] Tele-Op 2 per item 1 High
    Mining [Cargo] Tele-Op 5 per item 2 High

    Brainstorming Two - Enter the Void

    Brainstorming Two - Enter the Void By Evan, Abhi, and Janavi

    Task: Have a 2nd brainstorming session

    Last week, we had a lot of new recruits show up for the FTC kickoff. In fact, a bit too many. Luckily for us, we either scared them off or they realized that they'd like to move to FRC. So, today's session was a bit more managable, and we were able to break down into some new building tasks.

    Intake System 3 - TSA Bag Scanner

    If any of y'all have ever been on an airplane, you've gone through airport security. This part of our robot is inspired by the bag-scanning machine, more specifically the part at the end with the spinning tubes. The basic design would be like a section of that track that flips over the top of the robot into the crater to intake field elements.

    Intake System 4 - Big Clamp

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

    Lift 2 - Thruster

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

    Next Steps

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

    Meeting Log

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

    Meeting Log September 15, 2018

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

    Today's Meet Objectives

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

    Since the game has been released, some teams have already revealed robot reveals, like a 30 hr robot video that was recently posted. We watched and discussed this video. Though we will probably not use these designs, we have learned a lot from them about the game and what kind of competition we should expect.

    Since last meeting, we have begun prototyping the many ideas we have discussed, often with unconventional materials. 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, but. 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

    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.

    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. We began exploring in Open CV so that we can have a visual tool to find the gold minerals; the algorithms we are exploring can be used for both autonomous and tele-op. We also began mapping autonomous after our discussions last time and we began to make our marker.

    Open CV progress

    Today's 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

    Vision Discussion By Arjun and Abhi

    Task: Consider potential vision approaches for sampling

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

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

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

    Next Steps

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

    CNN Training

    CNN Training By Arjun and Abhi

    Task: Capture training data for a Convolutional Neural Network

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

    Next Steps

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

    Chassis Brainstorming

    Chassis Brainstorming By Ethan and Evan

    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. So, as the true hipsters of FIRST Tech Challenge, we want to move onto something new and fresh.

    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 seperator, which we will detail in a later post. Then, the robot will drive over to the lander and lift itself up. Since the main segment of the robot is based off of two wheels, we're attaching a telescoping slide that pushes off of the ground at the opposite end and pivots the front of the robot upwards. Then, the intake will launch upwards, depositing the elements in the launcher.

    Next Steps

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

    Meeting Log

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

    Meeting Log September 22, 2018

    Home Depot Trip!

    Today's Meet Objectives

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

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

    We have continued prototyping various grabbing mechanisms with sorting ability, one passive and one active sorter. The passive version we modelled in Creo and printed before practice, and the active was modelled using Legos! Our new rectuits have been helping us prototype also, as we have been making a version 2 for the active model.

    Passive model
    Active model

    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 came back home to set up our new baby. Here it is in action:

    New chopsaw

    Our new recruits finished up the field today! We are glad we had this project for them to do, as they could become familiar with building on a team while doing meaningful work. They ran into some problems along the way, but we only gave them a gentle push and let them problem solve themselves; these problems include 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. Some of their difficulties stemmed from the field parts being machined inaccuately, so pieces didn't line up perfectly. They had use their own problem solving to get past these diffculties and the field looks great!

    Our freshman recruits! Look how cute they are :)

    Evan and Janavi finished up the linear slides they were working on last week. In the previous meeting log, I described the difference between the two, but now that they are done we are going to test them both. 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.

    Battle of the Slides

    Karina narrowed down the ideas for a marker and she, with Kenna, has began building it. More details to come in later posts.

    For autonomous, we have been putting a strong priority in computer vision using Open CV. While we are waiting to begin code, we are testing many algorithm in Open CV, so we can accurately and consistenly detect field minerals. These algorithms consider shape and color to map points to predict the location of the minerals. Ideally, we will perfect our algorithms to find exactly where the gold block is among the three minerals during autonomous.

    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). Also, he tested the different chassis we build this summer on the field to see how they interact with the terrain (aka the crater). He 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 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

    Autonomous Path Planning By Abhi

    Task: Map Autonomous paths

    Ahhhhhhh! Rover Ruckus has been around for a while now and it's time to figure out our autonomous plans! This year's autonomous is a lot more hectic than last year's since there is the detaching from the lander component which can take an unknown amount of time right now. That cuts down the potential speed for the rest of the auto but only time will tell.

    Until then, I can only dream of the potential autonomous paths our robot can take. First, we need to know some basic facts. One, the field is the exact same for both red and blue aliance, meaning I 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 this 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 autnomous 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 multifunctionality. The time restriction makes this autonomous unlikely but it is stil nice to plan out a path for it.

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

    Next Steps

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

    Hanging Hook Prototype

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

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

    Today, we designed a basic prototype to hang the robot. We designed it, like all our parts, in PTC Creo, and printed it in nylon with ~80% infill. The hook was designed to minimize material used while also being strong enough not to stretch over time. First, we tested it by hanging ~20 lbs of material off of it for one minute. This worked, but a little too well. While the nylon piece remained undamaged, the metal bracket it was supported by bent at a ninety degree angle. So, we had to pursue further testing.

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

    Next Steps

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

    Meeting Log

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

    Meeting Log September 28, 2018

    Coding lessons with new recruits

    Today's Meet Objectives

    Since our overflow of new recruits, we have opened up two other teams 15373 and 15375, which Iron Reign will mentor and lead along with our mentorship of 3732 Imperial Robotics, who has also received new recruits. Today we plan to continue intergrating 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.

    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.

    In the build team, Janavi continued working with linear slides, Kenna built and installed a battery and REV hub holder for Garchomp, and Evan worked on an intake system. We installed Janavi's linear slides on a bare chassis and installed the hook Abhi designed and printed onto the slides. 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. Kenna used plywood to make the battery holder, which is helpful because we are going to use Garchomp for testing this year. Before we just secured the battery with Gaff tape. Evan worked on a secret project, details will be written about in future blog posts. 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. Justin 3D modelled and printed wheel mounts for churros and hex shafts.

    Ducky incarcerated :(
    Justin modelling

    In our code team, Arjun and Abhi updated to the new FTC app; a process we have to do every year before we start the code for that year. 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).

    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 Modelling2:004 hrs
    JanaviRobot build2:004 hrs

    BigWheel Chassis

    BigWheel Chassis By Evan

    Task: Work on a possible chassis

    We have our first qualifier coming up real soon, and to get ready we decided to get a robot into gameworthy shape. So far we have a few chassis from our work over the summer, so I decided to start on a neat little competition bot out of the one we called Bigwheel, named for its two big drive wheels in the back. 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

    So far, not much has gone into materializing the lever since this was made while the rest of the team was at an outreach event. Next week, the team will have to make some serious progress since there will be more hands to build. My hope is that the lever will come about soon, even if in its most infant stage, and that some semblance of a functioning robot can be game tested in the next few weeks, just in time for a scrimmage and potentially an early qualifier.

    CNN Training Program

    CNN Training Program By Arjun and Abhi

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

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

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

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

    Next Steps

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

    Intake Sorter

    Intake Sorter By Abhi

    Task: Design a sorter for the balls and blocks

    We've been brainstorming ways to sort the gold and silver pieces, and here's our first one. It's a little bulky, but it's a start.

    The way this works is that 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 modelled this design in PTC Creo, then printed it in ABS.

    Next Steps

    This is a little too bulky, so we're going to have to find a smaller and simpler way to sort game pieces, but it's a start. In the future, we're going to minimize this and probably move to a smaller sorting mechanism.

    Designing Wheel Mounts

    Designing Wheel Mounts By Justin

    Task: Create wheel mounts for our Mini-Mecanum chassis

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

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


    Next Steps

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

    Designing the Corn Cob Aligner

    Designing the Corn Cob Aligner By Ethan and Abhi

    Task: Design an aligner for the beater bar

    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.

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

    Next Steps

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

    Corn-Cob Intake

    Corn-Cob Intake By Ethan and Abhi

    Task: Design an intake system unique for balls

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

    First, we bought ice-cube trays. We wanted a compliant material that would grip the particles and be able to send them into a larger delivery mechanism. Last year, we looked at a silicone dish-drying tray as a compliant way to grip the blocks. This year, we're thinking about doing the same with the ice cube trays.

    First, 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.

    Next Steps

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

    Team Marker Fun

    Team Marker Fun By Karina

    Task: Create the Team Marker

    Last week, we decided to take up the task of creating the team marker, a simple project that would surely be overlooked, but can score a significant amount of points. We wanted the marker to be meaningful to the Iron Reign, but also follow the team marker rules. To start, we made a list of ideas, and considering how ridiculous we all are at Iron Reign, this is what we came up with:

    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 inbetween 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 peice for the duration of a match hopefully). It's survived many nights now in the our coach's house, which is no small feat, with all the children running about and constantly misplacing things. Once we have an intake system working for the minerals, we will need to test how compatible it is with Ducky in a Cage. Lastly, we need to decorate Ducky's cage, including our team's number (6832).

    Another Design Bites the Dust

    Another Design Bites the Dust By Ethan

    Task: Discuss a new rule change

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

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

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

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

    Next Steps

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

    Labelling Minerals - CNN

    Labelling Minerals - CNN By Arjun and Abhi

    Task: Label training images to train a Neural Network

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

    Next Steps

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

    Meeting Log

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

    Meeting Log October 06, 2018

    Code Testing with Arjun :)

    Today's Meet Objectives

    Since many of our members had other commitments today, we are expecting a quiet day. We set up some tables with FTC Starter Kits for our new rectuits so we can give them an introduction to building with REV parts. We want to continue research & design and building for Iron Reign. There is a scrimmage coming up in a few weeks, so we want to have a working chassis by then.

    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 or effective 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. Before worrying about this we want to get it working.

    Kenna with the chassis frame (pre-motored)
    Kenna and Janavi installing the motors

    We have been pretty behind in our blog posts, so Ethan has been catching us up with some prototyping posts. We also discussed what we want to improve in ou engineering notebook this year. In previous years, one of our greatest weaknesses has been the lack of mathematical analysis in our blog posts. A few members showed interest, so we are going to work hard to do more parts testing and incorporate statistics and physics from those tests into our blog posts. Also Ethan has been working on his own 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.

    Ethan working on the blog
    Ethan with the "corn on the cob"

    Today, I made some real progress on our team "Gantt" chart. I will write more about this in a separate blog post, but 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.

    Arjun has kept working on updating to the new app. Once updated, 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 neural network. He began compiling those images and will work on the neural network in the coming weeks.

    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

    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

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

    Next Steps

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

    Project Management

    Project Management By Charlotte

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

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

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

    Next Steps

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

    BigWheel+

    BigWheel+ By Evan

    Task: Continue work on BigWheel

    Since the last time we have discussed Bigwheel, the robot has gone through a few major changes. First and foremost, it now has a flipper arm. Since the robot itself is the lift mechanism, we had to put a lot of work into the design of the flipper. Right now it is a 10 inch REV rail attached to two of the largest REV gears you can buy, with a custom 3D printed mount housing an omni wheel pair. Right now it’s turned by two pairs of the smallest REV gears you can buy creating a 3:25 gear ratio. It’s a bit odd, but it increases torque which is what we’re going for, the philosophy being that it’s better to be smooth than to be quick, as a quick robot is weaker and less controllable. 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 previously the wires went every which way and created an infuriating mess that had the potential to get caught in the gears. Personally I’ve noticed that we’re a tad out of touch with gears right now, none of our other robots have sported them to much degree. We’ve been really in touch with sprockets though, since they’ve featured heavily in our designs the past two years. That’s just an observation, and since my first awareness of this, I’ve seen our gear savvy grow.

    Next Steps

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

    Developing a CNN

    Developing a CNN By Arjun and Abhi

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

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

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

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

    Next Steps

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

    Meeting Log

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

    Meeting Log October 13, 2018

    Sumo bots :)

    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.

    We brought some tools to the event so that Janavi could work on the chassis. Our chassis is a lot smaller than previous years, as we usually have a problem with size. We had been working on a different chassis beforehand, but we scrapped that design because of its lack of mounting points and due to the fact that it was poorly assembled. Because we completely started a new chassis with so few weekends before our first scrimmage, it is essential that we utilize the time that we have to get things done. Janavi started with just some extrusion rails and mounted some motors and wheels.

    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.

    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.

    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

    Mini Mechanum Chassis

    Mini Mechanum Chassis By Janavi and Justin

    Task:

    To everyone's suprise, Garchomp didn't pan out. But, practice makes perfect, and that’s what we are going to do: create new chassis until we find one that works!

    When looking for inspiration for a new chassis, we found the mini mechanum wheels that we had been fiddling with last season but eventually scrapped in favor of the larger wheels that can be seen on Kraken.

    In the past, Iron Reign has been infamous for creating robots that barely fit within the sizing cube by a fraction of an inch, so we decided to take a different approach this time. We built a low-laying 6" x 6" robot to counter our older approaches. However, this new design meant that many of the pieces we had created in previous competitions would be unusable due to the changes in size and structure. For example, the way we affixed the wheels to the frame didn't work, as the axles were too big and the wheels were too small to use with our former wheel mounts. As well, these new mini mechanum wheels came with almost frictionless bearings, but the axle that fit within these bearings was hexagonal, unlike the round ones we usually use.

    Justin first designed the axle plate below to solve this, but discovered that it raised the robot off the ground quite a bit, something we wanted to avoid, and it was very flimsy since it was so far away from the frame. We discussed these issues with our coach and brainstormed various methods we could use to attach the axle the frame in a more secure way; he suggested that we use a pillow block design that would have one side of the axel touching the frame. That way we 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're using motors with a gear ratio of 20 rather than 40s and 60s. This is another reason that we wanted to create such a minute robot. The gear ratio combined with the size will make this robot a speed demon on the field and allows us to dart between the minerals and the depositing location quickly.

    Next Steps

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

    Rewriting CNN

    Rewriting CNN By Arjun and Abhi

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

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

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

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

    Next Steps

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

    Intake Update

    Intake Update By Ethan, Abhi, Justin, and Kenna

    Task: Update the intake for the new robot size

    So, 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. Thus comes 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 the Iron Reign signature REVolution system. Then, we attached a REV Core Hex Motor to the design, then added a 2:1 gear ratio to increase the speed, as the motor wasn't exactly what we wanted.

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

    Next Steps

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

    Meeting Log

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

    Meeting Log October 20, 2018

    Juggling the minerals

    Today's Meet Objectives

    Our first scrimmage is next weekend! We have a lot of work to get done before then so today is going to be a busy day. We need to complete our chassis and some sort of intake system 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.

    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. Usually, we have a problem with sizing requirements, so we are going to try for a different approach.

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

    Arjun built a phone mount, a simple necessity for our robot. Besides building, 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
    GitHub Sesh!

    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.

    Intake mechanism with red silicon mats

    Kenna built a mount for all of electronics and attached to the chassis. We tried to use the mount that was built for Garchomp, but it wasn't ideal and would not have lasted due to size differences. We used plywood to create this mount so that we can make adjustments in the future. On the new board, Kenna attached REV hubs, so we finally are able to set up the electronics of the robot.

    Team MembersTaskStart TimeDuration
    CharlotteBlog and organization2:004 hrs
    EthanWorking on blog and build2:004 hrs
    KennaRobot build2:004 hrs
    JanaviRobot build2:004 hrs
    ArjunBuild and mentoring2:004 hrs
    KarinaRobot Build2:004 hrs
    AbhiRobot Build2:004 hrs

    Off-Schedule Meeting Log

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

    Meeting Log October 21 to October 23, 2018

    First, I will begin with an anecdote. Last year at Texas Regionals, another team's coach called us a Juggernaut, as we had started our season slow and unassuming, but we picked up pace rapidly with a strong performance at Texas Regionals, then Supers, then Worlds. We still find this an apt comparison.

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

    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. First, during our second test, we failed to notice that the string was entangled within the motor, and by the time we did, it created a tangled web not unlike the Gordian Knot. And like the Knot, we resolved to cut it out.
      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.
    • Reenforced lift
    • Nothing is perfect, and our robot is no exception. 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
    • We never actually restrung our lift after the Gordian debacle, so we decided it was high time to do so. 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 'Ol Faithful - 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

    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 gague 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 unoperable. 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.

    Strategy and Business Whitepaper

    Strategy and Business Whitepaper By Ethan

    Task: Write the Strategy+Business Whitepaper for the Journal

    For teams who don't know, this kind of paper is suggested for judging. Iron Reign usually completes one every year. You can download the pdf of this post here.

    Intro

    This year is Iron Reign’s eleventh season in FIRST, our ninth year overall. We’ve participated in five years of FLL and seven years of FTC:



    FLL

    • Body Forward
    • Food Factor
    • Senior Solution
    • Nature’s Fury
    • World Class



    FTC

    • Ring It Up!
    • Block Party
    • Cascade Effect
    • RES-Q
    • Velocity Vortex
    • Relic Recovery
    • Rover Ruckus

     

    While our team originated at WB Travis Vanguard and Academy, as our members became older (such is the passage of time), we moved to the School of Science and Engineering at Townview (SEM) in DISD. Despite our school being 66% economically disadvantaged and being Title 1, our school consistently ranks in the top 10 nationwide academically. Our school also has numerous other award-winning extracurricular clubs; including CX Debate, Math/Science UIL, and more. Our school employs a rigorous STEM-based curriculum, which provides our students access to specialized class schedules, such as Engineering, Computer Science, and Math, as well as paying for AP classes that our students would normally not be able to afford. The average SEM student takes at least 10 APs.

     

    A History of Iron Reign

     

    Iron Reign has been a team for nine years. We initially started as a First Lego League (FLL) team, plateauing in regionals every year we competed. This was usually not due to the actual “robot game” in FLL, but because of our presentations. Starting there, Iron Reign was defined as focusing on creative and innovative designs. We also did Google’s Lunar X Prize program every summer, achieving finalist status in 2011 and 2012. Upon moving to high school, we started doing FTC, as FRC was too cost-prohibitive to be parent-run.

    We have been an FTC team for 7 years, advancing further and further each year. In Velocity Vortex, we got to the South Super Regionals, qualifying by winning the North Texas Inspire Award, which means that we represent all parts of the competition, from teamwork, to the presentation, to creativity, and to the actual game. In Georgia, the same year, we were the first alternative for Worlds if another team dropped out.

     

    Then, last year, we finally got to Worlds. We got there in two ways: the 2nd place Innovate award at Supers, and also got the lottery, on the prior merits of being a FIRST team for so long. There, we got the recognition that we’d been seeking – we won the Worlds Motivate Award.

    In the same vein, we compete in the Texas UIL State Championships. For those unfamiliar with UIL, it is the main organizational committee for all public school academic and athletic events in the state of Texas. Through UIL, we helped compete in the first test program for the UIL Robotics program and since then have competed in every subsequent tournament. This year, it finally got out of the trial period, and became a full-fledged competition.

     

    Outreach

     

    Our outreach stands out from other teams through our mode of presentation. Last year, we renovated a 90’s Seaview Skyline RV, took out the “home” components, such as the bathroom and bedroom, and turned it into a mobile tech lab, so that we can bring STEM to underprivileged demographics within our community. Our RV currently holds 4 3D Printers, 30+ computers, 3 widescreen TVs, and 1 microwave. Our current curriculum consists of teaching kids 3D modelling in the back of the RV, using Google Sketchup, as it is free and available to any family with a computer. We usually help them design keychains, as they are memorable, but don’t take excessive time to print on our printers. In the front, we teach kids how to use EV3 robots and teach them how to use the EV3 programming language to compete in a sumo-bot competition. We also give advice to parents and educators on how to start FIRST teams.

     

    To make Iron Reign’s history entirely clear, we built the RV two years ago. We do not claim any credit for the actual construction of the RV in this journal; however, we do share the goals of this program: making the RV run as a standalone program, expanding the program to other communities, and serving more and more underprivileged communities in Dallas. To our own standards, we have achieved this.

     

    Our current funding services for the operation of the RV come from Best Buy, who purchased the thirty-plus laptops and four 3D printers. We receive grants from non-profits such as BigThought and Dallas City of Learning to fund events and provide staff (even though our team provides staffing).

     

    This year, we have obtained $150k in additional funds to expand our outreach program by building a second Mobile Learning Lab. This is an unprecedented level of funding - it can cover the majority of buying an RV, staffing it, and filling it to the brim with technology. So far, this is the highlight of the Iron Reign season.

     

    When not in outreach service, we can transform our RV into tournament mode. We have taken numerous long-distance road trips aboard our RV, with locations such as Austin, Arkansas, Oklahoma, and Florida. We substitute the laptops for a band saw and drill press, use the flat screens to program instead of teach, and bring our higher-quality personal 3D printer. At tournaments, we encourage other teams to board our RV, not only to encourage them to start their own similar programs, but also to help them with mechanical and building issues.

    Iron Reign spends a lot of time on outreach. So far, we’ve spent 84.5 man-hours and talked to just under 2000 people (1995) within our community. Our goal of this outreach is to reach disadvantaged children who would not normally have the opportunity to participate in STEM programs in order to spark their interest in STEM for future learning. Some of our major outreach events this year include Love Field Turn Up!, where we reached 1100 children from around the Metroplex. We’ve worked for our school district in various circumstances, including bringing children back-to-school STEM education and running orientations for our high school.

    We also represent FIRST in a variety of ways. At our Mobile Learning Lab events, we talk to parents and educators about starting their own FLL and FTC teams. We currently mentor our school’s FRC team Robobusters and are in the process of founding another. We are the mentors for our sister team, FTC 3734 We also provide help as-requested for FLL teams to go back to our roots. As well, we’ve historically hosted underfunded teams for late-night-before-tournament workshops.

     

    Date

    Event

    People

    Hours

    # People

    2018-04-26

    SEM Orientation

    Shaggy

    6

    200

    2018-06-23

    Turn Up! Dallas Love Field

    Justin, Ethan, Charlotte, Kenna, Abhi, Evan

    24

    1100

    2018-07-14

    Dallas Public Library

    Ethan, Kenna, Charlotte, Evan

    16

    190

    2018-07-21

    MoonDay

    Karina, Ethan, Janavi, Charlotte

    26

    200

    2018-07-22

    Summer Chassis

    Kenna, Ethan, Charlotte, Karina, Shaggy, Abhi

    24

    25

    2018-08-01

    SEM Summer Camp

    Arjun

    6

    175

    2018-08-18

    Back to School Fair

    Ethan, Kenna

    6.5

    130

    2018-10-13

    SEM STEM Spark

    Ethan, Charlotte, Janavi, Abhi, Karina, Justin

    80

    140

    2018-10-16

    Travis High School Night

    Ethan, Evan, Kenna, Charlotte, Karina

    12.5

    120

         

    201

    2280

    Business and Funding

     

    Iron Reign, for the past two years, has increasingly ramped up its funding. We aggressively seek out new sponsors so that we can continue to keep Iron Reign great. Currently, these include:

    • BigThought - RV materials, staffing, and upkeep
    • Dallas City of Learning (DCOL) – RV materials and upkeep
    • Best Buy – 4x3D Printers, Laptops for RV
    • DISD STEM – Practice field and tournament funding
    • RoboRealm - $1500 of machine vision software
    • Dallas Makerspace – Access to machining tools
    • DPRG – Robot assistance
    • Mark Cuban - $2500
    • DEKA - Rookie team funding for our two new teams
    • Texas Workforce Commission - $525 for our team, $2350 for new ones



    We are always seeking more funding. We apply for the FIRST and FIRST in Texas grants every year, and seek grants from STEM-curious companies and individuals in the Dallas area. We have applied for grants from Orix and Mark Cuban, receiving personal funding from the latter. We receive staffing and upkeep from a local Dallas non-profit, BigThought. Currently, we are seeking funding and assistance from Ernst and Young, an international company with a Dallas branch, that a team member works for.

     

    In previous years, we have lacked the ability to get significant transportation funding to get to tournaments. However, through our partnership with DISD, we have solved that problem, and when DISD is unable to provide transportation due to short notice, we can provide our own transportation due to our building of the RV.

     

    Reference Business Letter

     

    “To whomever it may concern,

              My name is Abhijit Bhattaru, and I am currently a member of Iron Reign Robotics at the School of Science and Engineering at Townview, a DISD magnet school whose population is 66% economically disadvantaged. We have been a FIRST team for about nine years, over half of some of our members’ lives. For the past six years, we have operated as FTC Team 6832, Iron Reign. We’ve achieved various forms of success in these years, culminating with our rise to the Houston World Championship this year, winning the Motivate Award, an award for outstanding outreach within our community.

     

              What makes our team stand out from other teams is our dedication to our community. Two years ago, we converted a Sea View RV into a Mobile Learning Lab equipped with 4 3D printers, 15 EV3 robots, and 30 laptops to teach children basic programming and 3D modelling. The purpose of all of this is to start a spark of STEM in underserved communities so that these children can later go into STEM. And, we have expanded this program nationwide, presenting at the National Science Teachers’ Association national conference in 2017. We have partnered with local nonprofits such as Big Thought to fund our outreach expenses, and to reach out to interested communities across Dallas, and the nation, to expand our program.

     

              So, why do we need your help? Our school is 66% economically disadvantaged, and adding to that, DISD is facing up to an $81 million budget gap. The district’s funding for robotics has been dropping to the point where only the basics are covered and even then come too late in the season due to red-tape. The one silver lining is that the DISD STEM Department is still able to handle most of our competition travel expenses. This offsets our largest expense category. But we still have to fund the development of our robot, and we aim high. Our robot earned an Innovation Award at the twelve-state South Super Regional Championship this year. We try to push the boundaries of design and execution and this requires a different level of funding for parts, materials and tools.

     

            To achieve this higher level of funding, Iron Reign is aiming to create a 501(c)(3) foundation to avoid the level of red tape and financial mismanagement from DISD that we have experienced for the past several years. This is where you come in, Mr. Cuban. We are asking for a seed donation for this non-profit, so that our team can become a free-standing team unhampered by DISD’s bureaucracy. Our mission would still be to serve our school and community, as it has been for the past eight years, but we would be able to avoid DISD’s mismanagement.

     

            If the money is not utilized for a seed donation, we would allocate it for new robot parts and equipment. A starter kit for FTC is at least $600 but this is nowhere close to cost of a World Championship robot. To become more successful in the robot game for the following seasons, we would need a higher investment into parts, considering many things can go wrong in an 8 month season. Your donation to the cause would allow us to become more successful.

     

            In return for your investment, Iron Reign will set out to accomplish what you desire from us. We can promote you and your companies on our website, presentations, etc. However, this is just one option. We are open to helping you in whatever way you  would like in return for your help to our team.

     

               Thank you for taking the time to consider our request, and if you happen to have additional time, we would like you to look over our previous Engineering Journals here to see our team’s engineering process and history. To see a video about our robot, please visit https://www.youtube.com/watch?v=TBlGXSf_-8A.

     

            Also, since you were not able to meet with us, we thought we would bring ourselves to you. Here is a video of our team and the FIRST Tech Challenge program.

    Thanks for your consideration,

    Iron Reign (6832)

    Looking Back, Moving Forward

     

    Recently, Iron Reign has put a large emphasis on recruitment. We have alternating years with high turnover due to graduation, so we hold recruitment meetings at our school every year for both Iron Reign and Imperial Robotics.

     

    We already have another team in our school, team 3734 Imperial Robotics. 3734 is an entirely different team, with different sponsors, members, robots, journal, outreach, and codebase. That being said, we recruit the more accomplished members of that team. The teams’ relationship is most similar to the difference between a Junior Varsity team and a Varsity team.

     

    We tend to recruit based on robotics experience, but having robotics experience alone is not a guarantee of joining our team. Iron Reign has a specific culture, and we tend to recruit people whose personalities fit our culture. We also do not accept people who only want to join robotics as a resume booster. While robotics is indeed a resume booster, and we allow every member to claim co-captain on their college applications, members of Iron Reign ought to join out of their genuine passion for robotics, not because of it getting them ahead in the rat race of college applications.

     

    This year has been an unprecedented year in recruitment for Iron Reign. We recruited approximately 30 new freshmen, expanding the Iron Reign program from two teams to four; from Iron Reign and Imperial Robotics, to adding Iron Star Robotics and Iron Core. And, our efforts have been recognized by our donors: we have been supplied four additional REV kits, and two fields so that we can support the larger program.

     

    Build

     

    Iron Reign utilizes a variety of parts and kits. At the moment, Iron Reign prefers the REV kit due to its simplicity - everything seems to just fit together, while still being minimalist. However, Iron Reign’s old standby is 3D printing. We’ve used 3D printing before it became widespread within FTC, and we’ve become sort of pros at specialized design. We even have our own 3D-print kits such as REVolution, a system to turn REV extrusions into axles.

     

    This year, we’re using a new base that’s more adapted to the challenge. Its working name is Minichassis. It is approximately 6”x6” for the base with an additional 4” extension for mounting. It uses four 4” AndyMark mecanum mounted low to the ground with NeverRest 20s with planetary gearboxes attached to each wheel. So, the robot is astoundingly small and fast.

     

    We have two main attachments to our robot, the lift and the intake. First, the intake is a small square with silicone oven mitts attached to it. It knocks the particles upward into racks spaced 68mm apart. This spacing allows the blocks to fall through while the balls move upwards into the lift. Then, the lift. The lift is a series of REV rails attached through a linear slide kit with a hook and particle holder on the end. This extends, allowing the robot to deposit particles in the lander while also being able to hook onto the lander.

     

    In addition to this design, we have also developed BigWheel, aptly named for its 6-inch wheels at the back with a front-facing omniwheel. At the front of the robot, we installed two “arms” which brace an intake system named “CornCob” for its lumpy, cylindrical appearance. This is mounted at a height just so it only contacts the silver particles, not the gold. But, what truly differentiates this robot is it’s lift mechanism. Unlike the majority of FTC robots we’ve encountered this year, BigWheel has no lift, extending-arm, or linear slide. Instead, we have a central lever mounted to two high-torque motors, with a ridiculous 3:1 gear ratio for a cumulative 19.4 N*m of torque. This serves to rotate the robot into a near-total-vertical position, allowing the arms of the robot to reach to the lip of the lander. We feel that this differentiates our team’s robot from the majority of other robots within the current FTC season.

     

    Code

     

    Iron Reign has a large pre-existing codebase. We’ve been improving off of our prior code for years. The particulars we want to focus on are thus:

    • Pose
      • This class uses the IMU to approximate the location of the robot on the field relative to the starting position. The math behind this is simple; we use trigonometry to calculate the short-line distance between the robot’s prior location and its current one.
    • OpenCV
      • We use OpenCV to recognize particles in autonomous. To do this, we trained the software to differentiate between gold and silver particles. To extend our knowledge of computer vision, we ran tests of OpenCV vs TensorFlow CNN in Python to see if there would be a meaningful runtime difference.
    • PID
      • At this point, PID is common among FTC teams. However, as we moved to a new driving base for the first time in three years, we had to retune it, so we rewrote our code to account for the changes in behavior.

     

    Design Process

     

    Iron Reign uses two design processes in conjunction with each other to create efficient and reliable parts. First, we use the Kaizen design process, also used in industrial corporations such as Toyota. The philosophy behind Kaizen is the idea of continual improvement, that there is always some modification to each system on our robot that will make it more efficient or more reliable. As well, design competitions are a focal point of Iron Reign’s design process. In these design competitions, team members choose their favored designs that all complete some field challenge, and build them individually. Upon completion of each mechanism, the designs are tested against each other, considering weight, maneuverability, reliability, and efficiency.

     

    This year, we have exemplified this process. Since kickoff, we’ve had two separate design paths, allowing us to explore the most efficient and workable design. Here, we will describe each segment in detail.

     

    First, we explored chassis designs. Over the summer, we created BigWheel, the aforementioned paragon of uniqueness - operating off of just two wheels. Then, we created the MiniChassis to compete against it, letting the best robot win. As of now, this is undecided, but we’re entering BigWheel to compete, as we feel that this is our more technically-impressive robot through its ability to rotate into a vertical position.

     

    Then, we compared intake mechanisms. First, we created the Corn-Cob intake - a silicone ice cube tray - and mounted it on a beater bar that would ensure sorting through the height difference between blocks and balls. We found that if we mounted it at about 6.5 cm above the ground, it would only consume the silver particles. After, we felt that this wasn’t our best work. So, we created a second intake. As described previously, we attached silicone oven mitts to a beater bar, and added lower fins as a ramp separated 68mm apart so that blocks would fly through, even as balls entered the intake system.

     

    The best thing about Kaizen is that we can mix-and-match these systems for the ultimate robot. At the moment, we’re considering removing the second intake from MiniChassis so that we can replace the Corn-Cob. The fact that we can even consider this system matching casually demonstrates the power of the Kaizen system.

     

    BigWheel Arm

    BigWheel Arm By Evan

    Task: Design an arm for BigWheel

    Bigwheel’s arm is going tied with the lifter arm as the most integral part of the robot. It wouldn’t work without it. Since our scrimmage, we have learned how to make this arm much more efficient, starting with some supports. The arm was made of two disconnected Tetrix rails scavenged from the bottom of our scrap bin, lending itself to weakness and instability, much like a country that recently won its independence. The worst part was how the two sides of the arm would be out of sync with one another, creating a twist in the arm that caused it to drive in an odd path. Since then it has been stabilized with cross beam REV rails that have significantly straightened out the robot. Why we hadn’t done it before is a mystery to me, and something we should have recognized as an issue sooner, but hindsight is 20/20 and since we can’t change the past we can only vow never to make the mistake again. Always support your attachments. The next upgrade on the arm is going to be the box to hold the minerals. Right now it’s made of cardboard off an amazon box, and it kind of sucks. I can say this because I cut it out and made it. The plan is to make it out of polycarb but we only came to this conclusion after a bit of debate. 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. Finally we came to the polycarb and decided upon that. So far it works as a nice way to hold the blocks as we transport them into the lander.

    Next Steps

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

    Full Circle

    Full Circle By Evan

    A reflection on my time at Iron Reign

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

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

    Meeting Log

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

    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.

    First and foremost, we have to work on our presentation. Iron Reign prides itself on its presentation - and we certainly don't want to disappoint this year - so we did an hour-long runthrough to get slide order and content memorized. I don't want to spoil it for y'all, but we've got something special this year.

    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 reenforcing 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 mergining 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. We're a little disappointed but also relieved.

    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.

    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

    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.

    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 neccesary help if you just look at our github!

    Torque

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

    RIP CNN

    RIP CNN By Abhi

    Task: Farewell Iron Reign's CNN

    So FTC released a new software update that added Tensorflow support. With it came a class that implemented Tensorflow to autonomously detect both minerals. This meant all our progress was undercut by a software 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. We're still gonna need an F in the chat tho.

    Next Steps

    We gotta figure out how to use the autonomous detection of the minerals to path plan.

    Lift

    Lift By Janavi

    Task: Design a lift for MiniChassis

    So we need to lift the robot. There are multiple ways to accomplish this including a linear slide or an arm; we decided to begin experimenting with the linear slide method. I created a linear slide using Tetrix bars and the standard linear slide kit. Instead of putting nuts with bolts on the end as stops I took an aluminum plate with holes on it and had Max, one of our mentors, assist me by cutting the plate into small squares to screw into the end of the bar. We planned to test out the tetrix bar at the scrimmage we attended, but two things went wrong. First, I forgot to make the linear slide stronger by attaching side plates, and we only brought 3 of the four needed REV hubs to be able to use both our MiniChassis and our big wheel chassis. Since BigWheel required more testing, we decided to give up one of our two REV hubs so that BigWheel would be able to get some much-needed testing. Since we were not running mini chassis I attempted to strengthen to linear slide by adding side plates but was unsucessful due to a lack of parts availiable. We relized that if we were to include a linear slide on our robot it would require too much maintaince and would soon become too finicky.

    Next Steps

    In the end we decided to scrap the standard linear slide in place of a geared linear slide with a different bar. By usingthe geared slide we would eliminate the need to deal with complicated string and would need to simply reverse the difrection of the motor to move it up and down. Working with the previous linear slide though showed us that it was not the best implementation to use with our robot design and allowed us to try better more efficient variations.

    BigWheel Upgrades

    BigWheel Upgrades By Evan

    Task: Get BigWheel ready for the tournament

    Sunday and Monday were good days to be an intake system for big wheel. Mounts were built to attach both types of intake to the rack and pinion tetrix slide and a new way of mounting the arm to the chassis. The original corn on the cob intake was sized down for the system, and stitched to a REV rail design as opposed to the tetrix and REV rail hybrid it was before. It has yet to be chained up but that should happen soon. 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. The only issue is that it that we have yet to find an ideal gear ratio for the arm, but we imagine that what we have now will suffice (a small 12 tooth gear to a large 86 tooth gear for that extra torque). We have to work on the actual mount that the arm will attach to, the only issue being space and that there may not be enough of it without either switching to bevel gears or chaining the motors to the small 12 tooth gears. We have yet to decide exactly what we’ll do, but since we may not have the bevel gears we want, it might end up being a chained mechanism. Another addition that is simple enough but quite necessary, 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 incase the polycarb is not enough to support the push of the robot. Part of this process will involve some code tuning so that the robot stops itself, but the tail is necessary as a preventative measure.

    Next Steps

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

    Conrad Qualifier

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

    Task: Compete at the N. TX Conrad Qualifier

    Hello, and welcome, to Iron Reign's first tournament of the season. Right off of a mortifying experience at the Hendricks MS Scrimmage, in which we got the worst score at thr 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 shard corners.

    Presentation

    So, before this tournament, we'd done two presentation runthroughs. Usually, we do at least five. In addition, we had two members missing for the presentation, and two more who arrived just as the doors open. In summary, we were anything but prepared.

    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 (confidence is equated with energy). 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 (where we usually shine).

    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 dissappointing 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 seperate groups of judges come up to us and ask us about *every* component of our team, from business, to volunteering, to code, to design. So, for the first time, our cold, cold hearts skipped a beat.

    In the ceremony, every single member of SEM Robotics waited with bated breath. 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. Even though we won Inspire, we have a long way to go. We are going to compete at at least one more tournament, and don't want to completely embarrass ourselves.

    Code Post-Mortem after Conrad Qualifier

    Code Post-Mortem after Conrad Qualifier By Arjun and Abhi

    Task: Analyze code failiure at Conrad Qualifier

    Iron Reign has been working hard on our robot, and we expected to do fairly well at our last competition. However, we couldn't be more wrong, since our robot came last place in the robot game. While we did win the Inspire award, we still would like to make some changes to ensure that this doesn't happen again.

    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. Unfortunately, we didn't begin writing the code for our autonomous until the Thursday before our competition.

    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 failiure 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. I plan to fix our autonomous sometime soon, well before our next competition, so that we do not have to come to our next competition without a working autonomous.

    Next Steps:

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

    Materials Testing Planning

    Materials Testing Planning By Ethan

    Task: Design a lab to test nylon properties

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

    Similarily, 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 videoanalysis. 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 recieve to commonly accepted constants to test our accuracy.

    Conrad Qualifier Post Mortem - Short Term

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

    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 so much that we could do better.

    Problems:

    The Robot

    So, to be frank, our robot was a hunk of junk. A breadless toaster attached to a REV hub would have performed the same as our robot, and saved us the embarassment in the meantime. So, we'll have to go a bit more in-depth than just saying that our robot was a hunk of junk.

    • The Intake
    • So, 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 that allows our intake to extend further (we had to saw through it). Now, we have latches that keep the intake from retracting without human assistance.

    • Superman Arm
    • So, 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 unaligned 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

    So, we didn't have much practice with our presentation. In addition to that, we were missing a member and had just added another member. So, we weren't really in tip-top shape. 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 majorly 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 "autonomous," and by that I mean we theoretically had code that could be construed as an autonomous if you squint hard enough.

    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.

    Chassis Mark Two Planning

    Chassis Mark Two Planning By Ethan

    Task: Plan a new BigWheel chassis

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

    Our original BigWheel base.

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

    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. This being Iron Reign, the logical solution to this is maximalism.

    The main way to prevent the wobbliness is by replacing the polycarb with something a bit 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 aluminium 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 seperate metal plates in combination with a filler metal that melts and joins the two plates together).

    Basic design for the newest version of BigWheel.

    Next Steps

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

    Conrad Qualifier Post Mortem - Long Term

    Conrad Qualifier Post Mortem - Long Term By Ethan

    What could have gone better?

    Our last postmortem discussed what went wrong with our performance, what our negatives were, discussing on each point whether we crashed and burned or if we merely dropped in altitude. This post isn't about that - it's about what we need to do to do better

    WWJD? - Prep

    We were not at our best in prep. But, this isn't about what we did wrong, it's about what we need to improve. The format of this will be in issue > solution format.

    • 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

    Build

    Other

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

    Next Steps

    Conrad Post-Mortem 3 - the Presentation

    Conrad Post-Mortem 3 - the Presentation By Ethan

    Task: Review our presenation and point out issues

    Issues

    0:05 [Evan & Everyone] – Absolutely no energy | Suggestion: Have Abhi start off with energy

    0:32 [Ethan] – Still no energy, sounds like a plain list of info, no excitement

    0:51 [Ethan -> Janavi] – Dropoff, pause between people | Suggestion: Practice

    1:02 [Janavi] – Again, no energy | Suggestion: Need emphasis on “that was two years ago”

    1:18 [Charlotte] – Pauses, lack of momentum in speaking | Suggestion: More practice

    1:34 [Janavi] – Lack of emphasis on team hour\connection #s | Good: No pauses\stuttering

    2:00 [Charlotte] – Dependence on presentation slides (what it sounds like, lots of pauses)

    2:15 [Janavi] – Almost too fast transition, sounds like you’re speaking over Charlotte | Suggestion: Try to draw out that “so!” to a “sooo!” to make a smooth transition

    2:22 [Bhanaviya] – Same thing, draw out that list, but good energy

    2:50 [Janavi] – Put emphasis on that 150k bc its really exciting, sound excited

    3:08 [Janavi -> Ethan] – Paused between slides

    3:16 [Ethan] – Pausing in the middle of speaking

    3:40 [Abhi] – Good energy

    3:43 [Abhi] – Paused

    4:27 [Abhi -> Justin] – Biiiiig pause

    4:32 [Justin] – Negative energy

    4:36 [Justin -> Ethan] – Long pause, rushed intro b/c of that

    4:58 [Ethan] – Pause in between topics

    5:40 [Janavi -> Evan] – Big pause

    5:55 [Evan] – Content comes across clearly, just need to be excited

    6:14 [Evan] – Pls don’t refer to presentation, is noticeable

    6:34 [Bhanaviya] – Same thing

    7:00 [Janavi] – Pauses in the middle of content

    7:10 [Karina] – Pls don’t refer to presentation

    7:21 [Abhi] – Good energy

    7:46 [???] – Didn’t have BigWheel ready

    7:53 [Evan] – Small but very noticeable pause

    8:00 [Evan -> Abhi -> Karina] – Very good transition

    8:16 [Robot] – O no

    8:45 [Karina] – Little pauses

    9:05 [Evan] – Mistake on what information to present (went for the one Karina did instead of corncob)

    9:26 [Evan -> Janavi -> Karina] – Lag time between segments

    9:35 [Karina] – Reliance on presentation slides

    9:59 [Justin] – Sound excited not sad

    10:01 [Justin -> Abhi] – Large pause between

    10:40 [Arjun] – Please gesticulate

    11:26 [Abhi] – Started to mumble

    11:33 [Ethan] – Stuttering

    11:37 [Ethan] – Again

    11:46 [Ethan] – And

    11:52 [Ethan] – Again

    12:13 [Ethan] – Lost confidence, got quieter

    Next Steps

    The main way to fix all of this is just practice, and a lot of it.

    C.A.R.T. Bot Side Shields

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

    Task: Design sideshields for the Townview Tournament

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

    Friction Coefficient and Energy

    Friction Coefficient and Energy By Ethan

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

    So, we wanted 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 coeffiencent of friction of the silicone mitts.

    To measure the coeffiencent 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 effiecent 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.

    Breaking the Big Wheel Arm

    Breaking the Big Wheel Arm By Ethan and Abhi

    Task: Evaluate damage to BigWheel's arm

    We broke the Superman arm. We were testing it right as practice ended when a horrible cracking noise echoed through the house as the gears on the arm were stripped.

    We found that the arm had overextended, breaking the zipties securing the motors and allowing the motors to press into the frame. Then, as they pushed into the frame, the frame pushed into the gears, stalling the motor and causing the clicking noise as the gears were stripped.

    Next Steps

    The solution to this is not mechanical, but through code. We need to create limits on the motor in the code so that the arm can't rotate past 160 degrees, keeping the gears from grinding.

    Nylon Strength Test

    Nylon Strength Test By Ethan

    Task: Determine what circumstances wear down nylon

    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 had a member (182 lbs) hang on 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.

    Programming breaks Build

    Programming breaks Build By Abhi

    Task: See how we broke the robot

    After a lot of use, it finally happened. The robot arm broke.

    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. When Evan took off the linear slides for maintenance we saw this happen. 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 hope to gang up the gears and make the mesh stronger to fix the build side of things. In the code, I already added the software limits to motion so we don't have those problems anymore.

    Arm repairs

    Arm repairs By Evan and Abhi

    Task: Fix elbow and Superman

    In a previous post I explain how our elbow and superman arms broke. 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.

    Nylon Materials Testing 2 - Wear and Tear

    Nylon Materials Testing 2 - Wear and Tear By Ethan

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

    So, here's the next article in the material testing series. After our last tournament, we noticed several 3D-printed sprockets that had worn down significantly. So, we wanted to meaure 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 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 expiriment.

    The Return of BatteryBox

    The Return of BatteryBox By Ethan

    Task: Create a charging station for our phones and batteries

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

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

    Next Steps

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

    BigWheel Arm Locks

    BigWheel Arm Locks By Evan

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

    So, as y'all know, 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 (18^3)" sizing cube. However, as it descends, the linear slides will glide upward, staying attached to the lander until the robot contacts the mat. And, as the slide finishes moving, it will move over a triangular piece of polycarb such that it is easy for the slide to move up, but near impossible to reverse its direction. This will ensure that the robot's arm stays extended.

    Next Steps

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

    Scoring Mechanism

    Scoring Mechanism By Janavi and Abhi

    Task: Create a way to hold minerals

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

    We want 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 including a literal box design. 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 part.

    Creating Side-Latches

    Creating Side-Latches By Evan

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

    My second favorite building material has to be polycarbonate. It can be both flexible and sturdy, malleable and stiff, and everything in between. Recently, it’s become the material of choice in the different aspects of out lift. The issue with the lift is that many of the pieces needed to be made required a bit of a specificity that’s hard to obtain using aluminum parts, so I turned to good old polycarb. Over the past four years, I’ve been developing my polycarb bending skills, that is, the perfect technique for quickly and precisely bending polycarb into the shape you need it, with as little air pockets as possible. The key is a small butane torch, similar to the kind you use to make crème brûlée, held at just the right distance, with a steady hand and a good pair of eyes. 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. I 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 I 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, and I couldn’t be more happy with it. The next stage or design for this will be to make these brackets out of steel, a job that will be made significantly easier once it warms up a little bit, stops raining, and we find the time to fire up the forge. I will forge a new, stronger version, which will hopefully eliminate a potential point of failure in our current robot. This is the plan. It will happen in due time.

    Refactoring Vision Code

    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

    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

    Teammember Statistics Update By Ethan

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

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

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

    As of today, our stats page displays this.

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

    And, the differences between each are below.

    Next Steps

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

    Off-Schedule Meeting Log, Winter Edition

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

    Meeting Log (Week of)January 03, 2019

    It's wintertime in Texas! The wind is gusting through the trees, the cool chill of the rain is permeating the air, and the fire of robotics keeps us toasty in our hearts, driving us to finish our robot as our tournament approaches.

    We have quite a few tasks this week, including but not necessarily excluding those not listed:

    • 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, much like a baby bird departing its nest for the last time.
    • Latch attachment

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

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

    • Fixing superman and wheels

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


      Karina putting weight on the robot

    • End\Beginning of year review

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

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

    Debug OpenCV Errors

    Debug OpenCV Errors By Arjun

    Task: Use black magic to fix errors in our code

    We recently implemented OpenCV support in our code, but we hadn’t tested it until now. Upon testing, we realized that while our code worked in theory, it misbehaved in practice. Thus, we began the time-tested ritual of debugging our code. From past experience we know that debugging is 90% luck and 10% hoping that you have pleased the gods of programming. We crossed our fingers and hoped that we were able to correctly diagnose the problem.

    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! This meant 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.

    Vision Summary

    Vision Summary By Arjun and Abhi

    Task: Reflect on our vision development

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

    Early on in the season, we began experimenting with using a Convolutional Neural Network to detect the location of the gold mineral. A Convolutional Neural Network, or CNN, is a machine learning algorithm that uses multiple layers which "vote" on what the output should be based on the output of previous layers. We developed a tool to label training images for use in training a CNN, publicly available at https://github.com/arjvik/MineralLabler. We then began training a CNN with the training data we labeled. However, our CNN was unable to reach a high accuracy level, despite us spending lots of time tuning it. A large part of this came to our lack 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 the lighting conditions to 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.

    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.

    Next Steps

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

    Designing Side Shields

    Designing Side Shields By Ethan

    Task: Create side shields for BigWheel

    Our tournament is on Saturday, and in traditional Iron Reign fashion, we're designing our side shields the Monday before. Iron Reign has access to an Epilog Mini laser-cutter through our school, so we had the genius idea to use it for the first time.

    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 fitted to the robot, issues became apparent. It was barely scraping the size limit, and while it fir 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.

    Next Steps

    We aim to cut these shields out of wood Wednesday morning after cutting the cardboard test print.