Articles by tag: innovate

Articles by tag: innovate

    Swerve Drive Experiment

    Swerve Drive Experiment By Abhi

    Task: Consider a Swerve Drive base

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

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

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

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

    Next Steps

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

    Swerve Drive Prototype

    Swerve Drive Prototype By Abhi and Christian

    Task: Build a Swerve Drive base

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

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

    Next Steps

    Consider and prototype other chassis designs until Rover Ruckus begins.

    Big Wheel Ideas

    Big Wheel Ideas By Janavi

    Task: Create a Unique Chassis

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

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

    Next Steps

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

    Position Tracking

    Position Tracking By Abhi

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

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

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

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

    Next Steps

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

    Rover Ruckus Brainstorming & Initial Thoughts

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

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

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

    Building

    • A One-way Intake System

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

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

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

    Journal

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

    Programming

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

    Next Steps

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

    Testing Intakes

    Testing Intakes By Ethan and Evan

    Task: Design a prototype intake system

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

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

    Next Steps

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

    Choosing Drive Train

    Choosing Drive Train By Janavi

    Task: Analyze the game

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

    Drivetrain Comparison

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

    What do we need to look at in a Drivetrain?

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

    Comparison

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

    Selecting Wheels

    Selecting Wheels By Janavi

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

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

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

    Brainstorming Two

    Brainstorming Two By Evan, Abhi, and Janavi

    Task: Have a 2nd brainstorming session

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

    Intake System 3 - TSA Bag Scanner

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

    Intake System 4 - Big Clamp

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

    Lift 2 - Thruster

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

    Next Steps

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

    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.

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

    Proposed Additions

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

    Next Steps

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

    BigWheel Chassis

    BigWheel Chassis By Evan

    Task: Work on a possible chassis

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

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

    Next Steps

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

    Intake Sorter

    Intake Sorter By Abhi

    Task: Design a sorter for the balls and blocks

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

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

    Next Steps

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

    BigWheel+

    BigWheel+ By Evan

    Task: Continue work on BigWheel

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

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

    Next Steps

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

    Mini Mecanum Chassis

    Mini Mecanum Chassis By Janavi and Justin

    Task:

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

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

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

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

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

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

    Next Steps

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

    Intake Update

    Intake Update By Ethan, Abhi, Justin, and Kenna

    Task: Update the intake for the new robot size

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

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

    Next Steps

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

    BigWheel Arm

    BigWheel Arm By Evan

    Task: Design an arm for BigWheel

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

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

    Next Steps

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

    Torque Calculations

    Torque Calculations By Karina

    Task: Calculate the torque needed to lift chassis

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

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

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

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

    Next Steps

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

    BigWheel Upgrades

    BigWheel Upgrades By Evan

    Task: Get BigWheel ready for the tournament

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

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

    Next Steps

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

    Chassis Mark Two Planning

    Chassis Mark Two Planning By Ethan

    Task: Plan a new BigWheel chassis

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

    Our original BigWheel base.

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

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

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

    Basic design for the newest version of BigWheel.

    Next Steps

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

    Selecting Lift System

    Selecting Lift System By Janavi

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

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

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

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

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

    Next Steps

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

    Code Issues Break the Superman Arm

    Code Issues Break the Superman Arm By Abhi

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

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

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

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

    Next Steps

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

    Arm Repairs

    Arm Repairs By Evan and Abhi

    Task: Fix elbow and Superman

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

    Selecting Intake System

    Selecting Intake System By Janavi

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

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

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

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

    Passive Deposit vs Passive Intake

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

    Intake Mechanism Material / Shape

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

    BigWheel Arm Locks

    BigWheel Arm Locks By Evan

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

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

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

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

    Next Steps

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

    Modeling Slide Barriers

    Modeling Slide Barriers By Kenna

    Task: Create barriers to prevent the linear slide from falling

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

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

    Next Steps

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

    Latch Model

    Latch Model By Abhi and Justin

    Task: Model and print the Latch

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

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

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

    Next Steps

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

    Belt Drive

    Belt Drive By Evan and Karina

    Task: Install a belt lift on our robot for depositing

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

    Next Steps

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

    Latch Updates

    Latch Updates By Justin, Abhi, and Ben

    Task: Update the latch

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

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

    Issues

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

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

    Gearkeepers

    Gearkeepers By Jose and Evan

    Task: Create and install gearkeepers to reduce slippage

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

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

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

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

    Next Steps

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

    Latch V.3.5 Assembly

    Latch V.3.5 Assembly By Ben

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

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

    Latch attached to polycarbonate brackets.

    Next Steps

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

    Fixing Mineral Dropper Components

    Fixing Mineral Dropper Components By Jose and Evan

    Task: Fix any issues with the mineral dropper

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

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

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

    Next Steps

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

    Latch 2.0 - Forged in Flame

    Latch 2.0 - Forged in Flame By Evan

    Task: Design a new latch for hanging

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

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

    Bigwheel Model

    Bigwheel Model By Justin

    Task: Design and update the Bigwheel Model

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

    Completed Changes

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

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

    Next Steps

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

    Elbow Rebuild

    Elbow Rebuild By Ethan, Jose, Karina, and Ben

    Task: Rebuild the elbow after total gear annihilation

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

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

    Next Steps

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

    Latch Designs - A Retrospective

    Latch Designs - A Retrospective By Ethan

    Task: Analyze past successes and failures in our latching system

    Version 1

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

    Version 2

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

    Version 3

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

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

    Version 4 - the Hook

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

    Big Wheel Articulations

    Big Wheel Articulations By Abhi

    Task: Summary of all Big Wheel movements

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

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

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

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

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

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

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

    Next Steps

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

    Up-to-Date Bigwheel Model

    Up-to-Date Bigwheel Model By Justin

    Task: Finish the Bigwheel model

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

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

    Next Steps

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

    Road to Worlds Document

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

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

    ROAD TO WORLDS - What we need to do

     

    OVERALL:

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

     

    ENGINEERING JOURNAL: - Charlotte, Ethan, & all freshmen

     

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

     

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

    Page numbers [Ethan][Done]

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



    ENGINEERING TEAM:

     

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

     

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



    CODE TEAM: -Abhi and Arjun

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



    DRIVE TEAM:

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

     

    COMPETITION PREP:

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

     

    VEX 393 Motor Testing

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

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

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

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

    Next Steps

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

    New Robot Base - Icarus

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

    Task: Build the base for the new robot

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

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

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

    Next Steps

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

    Finishing Icarus' Base

    Finishing Icarus' Base By Evan, Aaron, and Ethan

    Task: Perform the final steps to complete Icarus' base

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

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

    Next Steps

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

    New Elbow

    New Elbow By Justin

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

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

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

    Next Steps

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

    Constructing Icarus' Elbow

    Constructing Icarus' Elbow By Evan, Aaron, and Ethan

    Task: Build the elbow for intake

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

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

    Next Steps

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

    Icarus' Superman Arm

    Icarus' Superman Arm By Evan, Aaron, and Ethan

    Task: Design and install a lifting arm for Icarus

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

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

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

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

    Next Steps

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

    Reverse Articulations

    Reverse Articulations By Abhi

    Task: Summary of Icarus Movements

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

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

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

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

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

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

    Next Steps

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

    Icarus' Arms

    Icarus' Arms By Evan, Aaron, and Ethan

    Task: Install intake arms

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

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

    Next Steps

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

    Wiring Icarus

    Wiring Icarus By Jose, Abhi, Evan, and Aaron

    Task: Wire Icarus to be functional and move utilizing code

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

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

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

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

    Next Steps

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

    Intake Flappers

    Intake Flappers By Jose, Evan, and Abhi

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

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

    Next Steps

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

    New Superman Arm

    New Superman Arm By Ethan and Evan

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

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

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

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

    Next Steps

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

    Intake Update

    Intake Update By Ethan

    Task: Custom design an intake to improve intake times

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

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

    Next Steps

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

    Machining Gears for Superman

    Machining Gears for Superman By Ethan and Justin

    Task: Machine replacement gears for Superman

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

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

    Next Steps

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

    Ninja Flex Intake V2

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

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

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

    Next Steps

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

    Meeting Log

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

    Meeting Log June 08, 2019

    Task: Prepare for the 2019-2020 Skystone season

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

    Recruitment

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

    Prototyping leg-drive

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

    Experimenting with grippers

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

    3D-Modelling and CAD Design

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

    Next Steps

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

    Meeting Log

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

    Talking Heads: Summary June 08, 2019

    Task: Prepare for the 2020-2021 Game Reveal season

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

    Recruitment

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

    Outreach

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

    3D-Modelling and CAD Design

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

    Next Steps

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

    Leg Drive Prototype

    Leg Drive Prototype By Jose

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

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

    Next Steps

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

    SuperMan Wheel Fix

    SuperMan Wheel Fix By Jose

    Task: 3D model a fix for Superman using Fusion 360

    During the Discovery Faire Icarus' Superman wheel broke as the gears were skipping, rendering most robot articulations useless. For reference, Icarus was our robot for the 2019 World Championship and the Superman wheel is a mecanum wheel fixed to the base of the robot that, when extended, allows the robot to stand upright to a height of approximately 5 feet. The problem was the top gears were separating from each other and that caused them to also separate from the SuperMan gear. There is an easy fix for this, use a bar to join the motors together, effectively doing the same to the gears.

    This part was modeled by measuring the distance between the motors and the holes of the gearbox to hold the bar down. This ended in a bar 163.5mm long with holes spaced accordingly. This was simply extruded and the edges were made round. After the bar was printed it was proven to be tool long, the issue being the space between the motors is 62mm not 102.5mm.

    Next Steps

    We need to test the part on the Superman Wheel to see if its able to perform its articulations functionally.

    Fixing Mini-Mech

    Fixing Mini-Mech By Cooper

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

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

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

    Next Steps

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

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

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

    Task: Prototyping a rolling gripper

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

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

    Next Steps

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

    Wheel Gripper

    Wheel Gripper By Jose and Trey

    Task: Design an intake for the stones based on wheels

    Initial Design: Rolling Intake

    The first idea we came up with for gripper designs during our Robot in 2 Days (Ri2D) challenge was a rolling intake with the wheels coming from the top and spinning to intake the stone. Since the wheels needed to spin they were placed on shafts which required two extrusions since the pillow bracket for them needs to be threaded on the ends of them to make this design compact.This design was rejected since we want to use the minimal amount of servos as possible and we came up with a more compact design that requires only one servo instead of two(one for each wheel).

    Final Design: Gripper Wheels

    This design involves two wheels attached to extrusions, one is idle and can't pivot while the other can be rotated in place by a servo. Once its grip was tested we saw that the wheels spinning was a problem. To fix this, the wheels where attached directly onto the extrusions this time and to enhance their grip, a rubber band was added to default the wheels' position as closed. A servo was added to the end of the main extrusion with a servo horn and polycarb beam to rotate the non-idle wheel back to release the stone in its grip. Finally, since drivers aren't perfect, a stabilizer made out of polycarb was placed in the middle of the gripper so it will always move towards the middle of the stones, in between the stubs. At first this was off by 90 degrees, but this was fixed shortly after.

    Next Steps

    We will have to implement this onto the Ri2D bot and run tests to compare this gripper against our others.

    Robot in Two Days - Day One

    Robot in Two Days - Day One By Karina, Bhanaviya, Aaron, Jose, Ben, Trey, Cooper, Sam, Sterling, Beau, Mahesh, and Shawn

    Task: Build prototype subsystems that pick up the stone elements

    This season Iron Reign decided to take on the robot-in-two-days challenge. Given that our team had never done this before, and we are primarily a team of underclassmen, we knew we would have to be organized in our efforts and that we would probably reuse old chassis.

    First thing right after the kickoff, the team convened back at our meeting spot to brainstorm ideas for robot designs which you can see above. Among the ideas we discussed was a "cupbot" of sorts, a lot like the designs seen for last years' challenge, except it would be shaped after the tops of the stones. This idea didn't pan out, however, because it would only be able to pick up the stones in the upright orientation, which is not something we can count on. We also had a sub-team prototype a parallel gripper, but it was an unsuccessful build in that it could not actually pick up stones. We did proceed further into the building phase with two designs for a gripper system: a rack-and-pinion gripper and a rolling gripper. One sub-team started on the rack-and-pinion gripper project, while another sub-team started on the rolling gripper project, both of which have separate articles which you can read about in our blog.

    Besides the gripper systems, we also discussed what kind of drive train we wanted to use this year. When we were at the kickoff, we noticed that Icarus's chassis was ideal for moving underneath the skybridges, and so we considered using this chassis for our robot in two days challenge. We also had the MiniMech chassis available for reuse. In the end, we proceeded with the mini mech chassis, which a subteam tuned on day one of the two day build, since it would be easier to add a gripper to the next day, and this earlier in the season, we were prioritizing gripper speed, not traveling speed between the two areas of the field.

    All work and no play? Of course not! Here at Iron Reign we like to have safe and wholesome fun as we work, which we had the opportunity to do when we caught an ice-cream truck driving around the neighborhood. Look at us having such a chill time!

    Next Steps

    To finish the challenge tomorrow, we will complete our gripper builds, choose our best design, and then mount it onto the mini mecanum chassis.

    Rack and Pinion Gripper

    Rack and Pinion Gripper By Cooper and Aaron

    Task: Build a gripper system for the 2019-2020 Skystone Challenge

    The rack-and-pinion gripper system is one of the 4 gripper systems we built this weekend for our Robot in 2 Days project. Since we’ve never used a rack-and-pinion system before, we realized that it would be a creative idea to start off the new season. Going for simplicity, we made a box such that we could fit 2 racks going in opposite directions, having the pinion in the middle. We constructed the racks with standard rev rails attached to the box with a rev standard linear slide piece and attached tetrix rack gears on the opposite side with double sided tape. Then the pinon was a rev standard gear attached to a rail on the back. The plan was such that when the pinion was turned the two grippers will move outwards and inwards to grasp the stones.

    After that, the actual grippers went through 2 iterations. The first was a straight, flat bladed polycarb sheet attached to the rack. We tried this, but it turned out that did not provide enough friction. The second iteration was a slight variation, where we bent the arms and added rubber foam to the end. This saw some success.

    Next Steps

    Overall, the system was very solid and worked reliably, and could be used in conjunction with a gimbal to make a well performing arm, but that didn't save it. For our weekend build, the rack-and-pinion is too incompatible with our chassis to be implemented in time - but as FrankenDroid (our new robot!) is not the final iteration of our competition robot, the rack-and-pinion gripper system will act as a prototype for any changes we choose to make to our gripper system as the season progresses.

    Parallel Gripper

    Parallel Gripper By Ben

    Task: Prototype a parallel gripper

    While there are many different solutions and gripper designs, one of the most common is the parallel gripper. The purpose of a parallel gripper is to grip objects, in our case stones, parallel to the object instead of at an angle. Since this was a rational idea to start off with, this was one of the gripper designs we experimented with in the duration of our Robot in 2 Days challenge.

    A parallel gripper would allow us to grip the stones more effectively, as it would grip with more surface area. Theoretically, these grippers work by having 4 bars/connectors which are all the same length. When they close, they close parallel.

    After building the gripper, we tested it with the stones. While it did an okay job at gripping, due to the fact that we didn't use any gripping material, it slipped a few times. Another issue we encountered was that it would be difficult to flip a stone if needed, which is a task other designs could perform.

    Next Steps

    If we decide to pursue the parallel gripper system, we would have to figure out a way to flip a stone so we could stack it, along with improving the grip.

    Robot in 2 Days - Day Two

    Robot in 2 Days - Day Two By Bhanaviya, Aaron, Cooper, Jose, Ben, and Paul

    Task: Finish Robot in 2 Days

    Since the reveal was released yesterday, Iron Reign embarked on a project to build a skystone-specific robot in 2 days. Yesterday was a planning ground, during which we began prototyping 4 robot grippers, and 2 chassis designs. With less than 24 hours to complete our robot, we started today off by getting build-specific decisions out of the way, so that we could narrow in on one robot design to code and work on.

    Of course, we couldn't settle on a decision without first finishing all 4 of our gripper designs. At the end, we had one gripper system that incorporated nylon gears, one that used regular wheels, one that used a rack-and-pinion system, and one that was a parallel gripper system. We decided to settle on the one using standard wheels that pivot to grip onto a skystone. While we haven't yet decided if this will be the same design we will work with in time for our first qualifier, it is a stable system for a robot in two days.

    As far as the chassis was concerned, we stuck to using Mini-Mech, our summer chassis project from the previous year. Since we added a control hub to Mini-Mech earlier in the week, all that had to be done was incorporate the gripper system onto its chassis, and program it to at the very least move and grip onto skystones. This was a lot of work that needed to be accomplished in 4 hours, but as full-fledged members of the Building A Robot The Night Before A Competition Club, working on a small time frame was nothing new to us. In the span of one practice, we finished implementing a working gripper system to Mini-Mech and coded it to move, grab and stack a skystone on the foundation top. We christened our creation FrankenDroid as a testament to this year's Star Wars-based theme and the fact that the robot was made from harvesting parts from our last years' robots, Big Wheel and Icarus.

    Next Steps

    While FrankenDroid's movements are far from being smooth, it is a start. Robot in 2 Days started off as a fun challenge for us - we did not expect to accomplish as much progress as we did in such a short span of time. As of now, we don't plan on using FrankenDroid as our competition robot - but it will be useful for drive-testing, and will serve as a prototype for any future iterations.

    Robot in 2 Days Grippers Comparison

    Robot in 2 Days Grippers Comparison By Jose and Bhanaviya

    Task: Analyze all our grippers from the Robot in 2 Days challenge

    During the making of our Ri2D we prototyped and designed several gripper designs to collect stones. These designs varied in the method of manipulating the stone, how many servos they required and how compact they are. All of these gripper designs have their own post describing them in detail, but this article summarizes all of these grippers as a way to help us with future gripper designs.

    1) Wheel Intake

    This idea was though of but never built since the design was to have wheels at about ground level to spin and therefore intake the block, the problem being that this would disrupt the other blocks in the quarry since it intaked the block from its short side.

    2) Wheel Gripper

    This design was to use wheels as grip since they have good friction, one set of wheels is stationary and the other set can open and close via a servo. Not compact, but required only one servo and had great grip on the stone. This was ultimately the design we ended up using in our final Robot in 2 Days bot, Frankendroid,since it was efficient in maneuvering and controlling stones and served as a good design for a quick, 2 days old robot.

    3) Aaron's Super Cool Gripper That Works 100% of The Time

    This design used 3-D printed wheels made of ninja flex that spun to intake the block, like the wheel gripper just not in a set position and it grabbed stones from above. This design was huge and required two servos as well as not having much grip.

    4) Rack and Pinion Gripper

    This design involved a rack and pinion closing some polycarbonate sheets to grip the stone. The polycarb sheets had foam for grip, but this was still not enough to even lift the stone, so an actual motor would be required.

    5) Parallel Gripper

    This design was to use a parallel grabber with some material for grip as an alternative to the rack and pinion design. Unfortunately, the parallel grabber wasn’t built correctly thus not parallel.

    Next Steps

    With all of our gripper designs from the Robot in 2 Days Challenge documented, we can now analyze how best we can improve these designs for future gripper iterations, as well as the potential of these designs to be combined to create an entirely new design. Currently, we are leaning towards using the gripper with Ninjaflex gears, which is the 3rd design in this article, once we've fine-tuned Frankendroid's design. We think a rolling intake will work well on our robot so this design is consistent with our idea to use the wheel gripper at present.

    P.A.U.L

    P.A.U.L By Aaron

    Task: Design a new intake system

    The Pivoting Accelerated User-friendly Locker

    After the end of the two day robot build, we had come up with two main gripper designs. One was consistent, however heavy and large, (Wheel Gripper) and one was lighter but wasn’t quite as versatile or controllable (Aaron's Super Cool gripper That Worked 100% of the Time). P.A.U.L (Pivoting Accelerated User-friendly Locker) is the best of both worlds. It’s made out of polycarb so it’s light and somewhat flexible, and its easily controlled by a servo.

    P.A.U.L was originally designed with a hole in the top where a servo could push a small polycarb rod straight down, pushing the stone out of the grasp of P.A.U.L. This might have worked, however we decided that it would most likely be more efficient and easily controllable if we switched to some sort of pivoting mechanism where one side of Paul could be controlled by a servo. The way that works is by fixing one side to an axle that is attached to a gear. That gear is then controlled by the servo on top of P.A.U.L.

    Next steps:

    In the future we plan to test different gear ratios, that way we could figure out the perfect ratio of torque to speed. We want a good amount of torque that way we can grip the stones tightly and securely so they don’t fall out while being jostled around on the field, however in this years challenge speed is going to be very important.

    Fixing the Mechanum Chassis

    Fixing the Mechanum Chassis By Cooper

    Task: Fix the old mecanum chassis from last year

    Tonight, I worked on fixing the Iron Star robot from last year, since its a viable option for replacement of a chassis if there was ever a problem with ours at a competition. First we needed to strip it down to its bare form and take off the mecanum wheels. After that we took off the Tetrix axle holding blocks, as they were to thick and tall, and we printed out the holders from the minimech robot. We had to cut new axles since the ones that were used were very scarred. from there, the motors were removed and replaced with 20:1 planetary-geared REV motors. Then I attached the mecanum wheels back on.

    Next Steps

    In the future we need to attach the other set of mecanum wheels and add chains to the motors and the wheels. After that, we need to add on the general purpose mounting bracket that we are talking about making so that we can hot swap the subsystems on the fly.

    Gripper Testing

    Gripper Testing By Paul and Justin

    Task: Test block gripper

    Here is us testing the gripper we designed to pick up the blocks in this years SkyStone challenge. This gripper combines the Pivoting Accelerated User-Friendly Locker, P.A.U.L, one of our earlier gripper designs, and Aaron's Super Cool Gripper, a design from our Robot in 2 Days Challenge. It has a backplate similar to that of P.A.U.L's but instead of polycarb flaps, it utilizes the smaller Ninjaflex gears (a smaller version of the gears on Aaron's Super Cool Gripper) that Justin modeled so it is essentially a combination of our best design ideas so far. It doesn't have a name yet so it will be called P.A.U.L Version 2. It was mostly effective in picking up the blocks, however we need more structural rigidity to ensure that the blocks don't rotate while being picked up.

    Next Steps

    Next steps include reinforcing the gripper frame, and mounting it to our prototyping robot. We also need to cut off the excess rev rail, to reduce weight and make it a little less bulky.

    Autonomous and TomBot Robot

    Autonomous and TomBot Robot By Karina, Jose, and Bhanaviya

    Task: Autonomous coding and TomBot progress

    DISD students have been blessed with a long weekend, which we plan to take full advantage of as our first scrimmage is closing in. Just as we started to test drive Frankendroid, we began to notice some faults with the robot. Lots of these were common errors, which can likely be attributed to the fact that we sped through the building of Frankendroid very quickly. For one, we left off a lot of pulleys on our belt and pulley system, which left the entire thing very loose and in need of tensioning. We also had an issue of bearings slipping out of their sockets for the gripper's elbow attachment. We promptly made sure that the axle and belt systems were set up properly.

    So far, much of the team's focus has been on building a robot, and we're just now getting around to coding. So besides tuning up Frankendroid, we took a look at our autonomous program. To start, we drew an auto path (version 1). Then, considering Iron Reign already has a large code base from all its years doing FTC, we copied the pre-existing minimech code to start the code for Frankendroid. In terms of the drive train, Frankendroid is pretty standard with four mecanums in a rectangular shape, and so the hardware map was the same. We had some null pointer exceptions due to calls to nonexistent motors, sensors, etc. Additionally, the motor behaviors were not working such that doing the controls to move forward and backwards actually made the robot strafe, and strafing commands made the robot rotate. All of this was fixed in code. Afterwards, we calibrated

    Lastly, we did build work on our work-in-progress TomBot. From wheel to wheel, the span was too great to fit within the polycarb frame we had previously cut. Everything (wheels, motors, extrusions) had to moved closer together on the main axle, and then centered. The two center extrusions intended to be a point of attachment to the polycarb frame extended past the perimeter of the frame, and so these had to shortened with a hacksaw.

    Next steps:

    Our code team is now gearing up for an intensive two weeks of writing and fine tuning code for the robot. Drivers will take this opportunity to practice driving and become familiar with controlling Frankendroid.

    TomBot Suspension

    TomBot Suspension By Ben

    Task: Design a suspension for TomBot

    3 Different iterations of the passive suspension.

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

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

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

    Wheel mount with example suspension

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

    Next Steps

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

    Updating TomBot's model

    Updating TomBot's model By Bhanaviya and Ben

    Task: Update the model to plan TomBot's build

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

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

    Next Steps

    With our robot model in progress, we can now plan out all our steps ahead of time in CAD so that we will make less mistakes on the physical build. We will be updating the model as the season progresses.

    Round Chassis Assembly

    Round Chassis Assembly By Justin, Trey, and Jose

    Task: Attatch Omni wheels to Round Chassis

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

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

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

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

    Next Steps:

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

    Stub Gripper

    Stub Gripper By Jose

    Task: Building gripper iteration #7

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

    Next Steps:

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

    Turn-table Assembly

    Turn-table Assembly By Aaron and Trey

    Task: Finish assembling the turn-table

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

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

    Next Steps:

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

    3-Fingered Gripper

    3-Fingered Gripper By Jose and Aaron

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

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

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

    Next Steps

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

    Gripper Iterations Summary

    Gripper Iterations Summary By Bhanaviya

    Task: Go over our 9 gripper iterations

    This season, we experimented with 9 gripper models - both for our robot in three days project and for our competition bot. While we do not plan on using all 9 of these models, they allowed us to effectively implement the engineering process within our build season. Experimenting with each gripper helped us to identify the potential of each design as well as how two individual designs could be combined to create a more efficient one. Each of these designs has its own article but this is just a summary of all of our gripper designs so far.

    1)Wheel Gripper

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

    2) Parallel gripper

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

    3) Rack and Pinion Gripper

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

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

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

    5) Pivoting Accelerated User-Friendly Locker

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

    6) P.A.U.L Version 2

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

    7) 3-Finger Gripper

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

    8) Stub Gripper

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

    9) Cylindrical Gripper

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

    Next Steps

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

    CNC Turntable Mounts

    CNC Turntable Mounts By Justin

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

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

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

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

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

    Next Steps:

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

    Mounting the Slip Ring

    Mounting the Slip Ring By Aaron

    Task: Mount a slip ring onto TomBot's chassis

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

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

    Next Steps

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

    Woodrow Scrimmage

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

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

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

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

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

    Next Steps

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

    Linear Slides on TomBot

    Linear Slides on TomBot By Justin

    Task: Mount linear slides to the robot.

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

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

    Next steps

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

    Morph Chart

    Morph Chart By Bhanaviya

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

    Iron Reign has seen several iterations of several subsystems over this past build season. With our first qualifier being 2 days away, its finally time to come full circle and identify the different iterations of different subsystems coming together. To do this, our team used a morph chart. A morph chart shows the various subsystems of our 2 robots in this system - our robot in 2 days bot Frankendroid and our competition bot TomBot.

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

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

    Next Steps

    Placing all of our designs in one chart like this allows us to see how iterative our design process has been, and how much of an influence each design has had on another. With all of our designs so far placed in the morph chart, our next step is to continue to update the chart after our first qualifier so that we can have a pictorial summary of our entire build season for reference.

    Night Before Competition Build

    Night Before Competition Build By Aaron, Cooper, and Trey

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

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

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

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

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

    Next Steps

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

    Build Post-Mortem

    Build Post-Mortem By Bhanaviya and Aaron

    Task: Begin analyzing long-term build improvements

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

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

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

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

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

    Next Steps:

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

    Drive Issues at Allen Qualifier

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

    Task: Identify points of improvement after driving at Allen

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

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

    Next Steps:

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

    Swivel Mount

    Swivel Mount By Aaron

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

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

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

    Next Steps

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

    Finger Gripper Version 2

    Finger Gripper Version 2 By Jose

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

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

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

    Next Steps

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

    Adding to TomBot model

    Adding to TomBot model By Ben

    Task: Update the current robot model

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

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

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

    Next Steps

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

    Finger Gripper Version 3 CAD

    Finger Gripper Version 3 CAD By Jose

    Task: Design a more comapct and efficient gripper design

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

    Next Steps

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

    Creating a Robot Handle

    Creating a Robot Handle By Paul

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

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

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

    Next steps:

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

    Capstone Version 3

    Capstone Version 3 By Jose

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

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

    Next Steps

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

    Capstone Iterations

    Capstone Iterations By Bhanaviya

    Task: Go over all 3 of our capstone iterations

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

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

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

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

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

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

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

    Next Steps

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

    Finger Gripper Version 4 CAD

    Finger Gripper Version 4 CAD By Jose

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

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

    Next Steps

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

    Sliding Foundation Grabber

    Sliding Foundation Grabber By Trey, Jose, and Aaron

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

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

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

    Next Steps

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

    Finger Gripper Version 2.1

    Finger Gripper Version 2.1 By Bhanaviya and Aaron

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

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

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

    Next Steps

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

    Assembling the Turntable Bevel Gears for a REV Motor

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

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

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

    Next Steps

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

    Logarithmic Spiral Update

    Logarithmic Spiral Update By Ben

    Task: Update the Logarithmic Spiral

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

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

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

    Next Steps

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

    Modeling TomBot Articulations

    Modeling TomBot Articulations By Ben

    Task: Model TomBot's Articulations in Fusion360

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

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

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

    Next Steps

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

    Calculating Torque at the Drive-Train

    Calculating Torque at the Drive-Train By Bhanaviya

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

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

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

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

    Next Steps

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

    Dissecting the Turret

    Dissecting the Turret By Karina and Cooper

    Task: Figure out why the turntable isn't turning

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

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

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

    Next Steps

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

    Snapdragon - The Sequel

    Snapdragon - The Sequel By Bhanaviya and Aaron

    Task: Improve the precision of the Snapdragon.

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

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

    Next Steps

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

    Updated Bill of Materials

    Updated Bill of Materials By Bhanaviya and Paul

    Task: Update the list of parts for TomBot for regionals

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

    Next Steps

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

    Designing a New Build Plate

    Designing a New Build Plate By Ben

    Task: Model and CNC a new build plate for TomBot

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

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

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

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

    Next Steps:

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

    The Night Before Regionals - Code

    The Night Before Regionals - Code By Cooper and Trey

    Task: Fix our autonomous path the night before regionals.

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

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

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

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

    Next Steps

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

    The Revenge of TomBot

    The Revenge of TomBot By Bhanaviya

    Introducing...The Revenge of TomBot!

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

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

    Next Steps

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

    Meeting Log Post Regionals

    Meeting Log Post Regionals By Anisha

    Task: Get back to work after Regionals

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

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

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

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

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

    Next Steps

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

    CNC a New Polycarb Robot Base

    CNC a New Polycarb Robot Base By Justin

    Task: CNC a new robot base

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

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

    Next Steps

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

    TomBot v2- Gripper Triggers

    TomBot v2- Gripper Triggers By Jose

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

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

    Next Steps:

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

    Summer Summary

    Summer Summary July 11, 2020 By Bhanaviya, Jose, Anisha, Paul, Shawn, Trey, Justin, Aaron, Ben, Mahesh, and Cooper

    Talking Heads: Summary July 11, 2020

    Task: Prepare for the 2020-2021 Game Reveal season

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

    Recruitment

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

    Outreach

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

    3D-Modelling and CAD Design

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

    Next Steps

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

    Printing Rings

    Printing Rings By Trey

    Task: Print some game elements to get a kick start on the season

    Recently, this year’s competition details were released, and while we couldn’t quite get started on a robot immediately like we did last year we were able to do some prototyping for ring launchers. The thing that we made which enabled us to do this was a rendering of the game element for the year. This was done by taking the model released on AndyMark’s website and 3D printing it. With this, we were able to start thinking about the size and proportion of our future launcher as well as its construction. The ring was printed in PLA at its exact size to best accomplish this.

    The biggest problem with this method of construction is that the ring does not have the characteristic foam squishiness so we also made another ring out of foam tape to get a better idea of how the official game element might fly and how we can get it to fly. We were able to throw the two rings around and notice that there is a very noticeable spin that can be achieved and will likely be desirable in the future for maximum stability in the air. The realistic shape of the ring was helpful when we were trying to figure out how the ring would fly since different ring shapes would obviously fly differently so having a replica was nice.

    Next Steps:

    We are going to kick off our development of a robot soon and with the rings we made we should be able to develop better early on than if we were empty-handed. This development is of course being curbed by the pandemic since at the moment only a few builders can come in to build at a time. Being one of these builders, I think the goal for the first launcher prototype is to see how easy it is to get a ring to fly and what variables will be important in the future for trajectory and speed rather than actual functionality. We are excited to have a whole season of development ahead of us.

    Archimedes Screw Intake

    Archimedes Screw Intake By Bhanaviya, Jose, and Shawn

    Task: Begin creating intake systems on CAD to test their potential

    The Archimedes Screw Intake, as the name goes, was based on an Archimedes screw. A screw shaped surface would draw the rings from the fields and transfer it directly to the launcher as the screw rotates. Similar to the Archimedes screw water pump, it makes use of positive displacement and would rely entirely on the screw's movement for the rings to travel upward towards the launcher.

    While this is an intruiging system, our biggest concerns with it are size and timing. This system would take up most of the volume of the robot. Also, since the screw would have to rotate entirely for one ring to be taken upwards, this is likely not the most efficient system and even the mere drawing of the rings into the system is likely to be more time-consuming. It would also be very difficult to make. So, this intake ends here in the concept stage.

    Next Steps

    Our next steps are to begin brainstorming ideas for other, more efficient intake systems. We may still come back to the Archimedes system but as of now, it is of lower priority. Rest in Peace Archimedes.

    The First Launcher

    The First Launcher By Trey and Paul

    Task: Create and Test a Arm Disk Launcher

    One of the centerpieces of any robot this year is going to be the disk launcher. It’s likely that most robots in the competition are going to be built around their launchers, so one could logically conclude that that’s a good place to start when building a robot. This is no different for us; however, we didn’t just want to build a flywheel like most other people. Instead, we started to look into other designs. One of the designs that came into mind first was some sort of arm that is powered by an elastic or bungee cord that throws disks sort of like a clay pigeon thrower.

    But why did we start with an arm design? Wouldn’t a flywheel be easier? We started with an arm because we thought it was interesting and customizable. Yes, a flywheel would be easier but that would be at the cost of customizability. With a flywheel, there is only so much to change. You can change pretty much only the motor, the wheel, or the speed of the motor. This is good for a team that just needs a launcher that works but we want to be able to make a customizable launcher that we can tailor to our needs easily. There is a lot of open space and customizability with an arm launcher. For example, we can change the arm material, length of the arm, strength of the bungee, the time the disk is in contact with the arm, and much more.

    So that’s what we built and it works to a degree. Yes, it does launch a ring, in fact, it can launch a ring across the field to a height of 55 inches at an angle of 44 degrees with an easily retractable arm; however, in its current state it breaks easily, isn’t consistent, and is quite big. The first two are fairly easily fixable because they are mostly because the base of the launcher is made out of particle board which falls apart easily but the last one isn’t quite as easy to fix. Cramming this design into a smaller space could provide a difficult challenge. The function of the design is to accelerate a ring over a distance with an arm which can be difficult in a small area because with a smaller arm you have to use a stronger bungee to achieve the same results.

    Next Steps:

    I have only touched on a few major things to be improved. There are quite a few; however, the results that we observed from this design definitely warrant a second version, and there will be one. At the very least, I am thinking of new designs and improvements for this system. There are also many other things we can try and I know that regardless of what I have said about a flywheel launcher so far, it would have its advantages, mainly compactness, so I know we will definitely build one of those as well. There is still much more to be made and built for this robot.

    Custom Flywheel CAD

    Custom Flywheel CAD By Jose

    Task: CAD a custom flywheel

    Instead of using a grip wheel to launch rings we went with the approach to make a custom flywheel. The key concept of a flywheel is to maximize rotational inertia. This is done by putting as much mass towards the edge of the wheel as possible. To do this, a ring of ninjaflex was designed, from there, 5mm flaps were added as an experiment to see if it would give the wheel more points of contact to the ring. However, the wheel needs a center to be able to spin, so aluminum plates were added to sandwich the ninjaflex ring. To decrease the amount of mass not on the edges of the wheel, these aluminum plates were pocketed, leaving aesthetically pleasing curved spokes on the plates.

    Next Steps:

    The ninjaflex is to be 3-D printed and the aluminum plates will be milled on our CNC machine. Once that is done it will all be put together using M3 hardware.

    Deconstructing TomBot

    Deconstructing TomBot By Trey, Jose, and Cooper

    Task: Create and Test a Arm Disk Launcher

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

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

    Next Steps:

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

    FTC Legal Belt Sander

    FTC Legal Belt Sander By Paul

    Task: Create a prototype for a belt sander intake system

    The so-called “FTC Legal” belt sander was an early iteration of the intake mechanism for this year's robot. It was composed of a belt, from a Ryobi belt sander, rev wheels wrapped in tape, to help center the belt, and a tensioning mechanism. The belt would provide friction, moving the disk game elements upwards towards the launcher mechanism. However, an issue we ran into was the distance between the bottom of the belt and the floor was hard to regulate, resulting in disks either not having enough space to be sucked up, or havag too much space and not enough friction to be dragged up. This was partially solved by replacing the belt sander belt with a Ninjaflex belt with flaps, which is the current iteration of the robots intake system, using many of the same parts and designs as the original “FTC Legal” belt sander.

    Future plans include designing and constructing some form of leveling system, and a higher belt speed to more quickly collect disks. We are also considering using this sander design as an inspiration for a dual-tracked belt drive intake system and an elevator-like intake system with ninjaflex substituting for a traditional belt drive system.

    Caterpillar Track Intake

    Caterpillar Track Intake By Ben, Bhanaviya, Trey, and Jose

    Task: Build and prototype an intake system

    One of the first intake systems we made was the Caterpillar intake assembly (Tetrix tread intake). The inspiration for this design came from an earlier bekt drive comprising of a sander (which you can read about in our earlier post). This was originally built off a c-channel extrusion with a motor attached to sprockets that drive treads. The purpose of this subsystem is to transport the rings from the field into the launcher loading area.

    We first tested the assembly without the rubber bands and quickly realized that the treads couldn’t create enough friction to grip the ring and move it vertically. Our solution was to attach rubber bands within each tred piece. There were 2 reasons for this, the first being that rubber in general has high friction and good grip. The second reason is that the flinging rubber bands will conform to the shape of the ring at high speeds and drag the rings up the intake.

    We did experience a few problems with the construction of the assembly. We found that the rubber bands would often get caught on the edges of the c-channel and either fly off at a high velocity, snap, or tangle and prevent the assembly from moving. Because of the way the band fits into a tread, there wasn’t a way to permanently attach the rubber band without damaging the thread, meaning we would have to scrap the idea or find a work-around. We eventually decided to rebuild the intake with REV extrusions because it would be more compatible with our robot and we could replace the large c-channel with the smaller REV extrusions.

    Next Steps:

    Although this prototype holds promise, we will continue to experiment with it and alternatives to find an alternative that doesn’t run the risk of tangling and disrupting the system.

    NinjaFlex Belt intake system

    NinjaFlex Belt intake system By Trey

    Task: Design an intake with the NinjaFlex belt

    So far we have made a few Intake assemblies including the belt intake and the Tetrix tread intake. However, as is Iron Reign tradition, we like to make systems that utilize custom parts to both help our robot’s aesthetic and functionality. To do this, we took aspects from the other two intakes to better design and make the one that is discussed in this post. To recap, the belt intake was a sanding belt on to barrels that spun at high speeds to pull in rings and the tread intake was made with Tertis tank treads with rubber bands and spun, in the same way, to grip and pull in rings.

    The NinjaFlex belt intake takes the benefits of both systems without generating their issues. The NinjaFlex intake has the narrowness and form factor of the belt intake without the issues of the belt derailing which is caused by uneven pressure on the belt. Instead, the NinjaFlex belt intake is sprocket-driven with a custom belt to ensure that the belt stays on the rollers at all times as long as the two ends are aligned properly. Derailing was a big issue with the belt intake. Personally, I remember spending at least a few hours in total trying to get the belt to not fall off, with little success. That system would have needed much more work and improvement before we would have seen any results.

    The NinjaFlex belt intake system also yields the benefits of the tread system in that the 3D printed belt provides sufficient grip on the rings in order to pull them onto the robot. Additionally, the NinjaFlex belt system also doesn’t use rubber bands as gripers that can tangle with nearby screws or protrusions, possibly causing the system to break. Instead, the belt has flaps which can also be changed or molded into different lengths or shapes. This brings up one of the biggest benefits, customizability. When we use 3D printed or CNC parts we enter this space of customizability which is always a good aspect because if a change needs to be made to a part, we can usually make a new custom part in a matter of days if not hours with our machinery which gives us a lot of flexibility in how we can build our robot.

    Assembly-wise the intake is also super simple right now. It consists of 6 sprockets, 3 on each side that drive a belt with the sprocket spacing sits on to pulls in rings. The dimensions and specifics of how the belt was designed and made are in the post “NinjaFlex intake belt” but basically it’s just a belt with holes in it with the specific spacing of the REV sprockets. The motor right now has just been placed on one of the shafts but will be secured in a better location in the future, either parallel to the guide rails or perpendicular depending on how much space we have. If the motor is mounted parallel to the guide rails, then it will drive the belt with beveled gears, otherwise, it will be directly fitted onto the shaft.

    Next Steps:

    As mentioned previously, the motor has yet to be permanently mounted so that would be the next clear step and after that, there will likely be more testing and comparing of different intake systems. Then, we will interface the new intake with a ramp to see how we can assemble the two together to finish our intake system and start planning to put it on the robot. For now, though, we have made good progress.

    Proteus' model

    Proteus' model By Bhanaviya and Jose

    Task: Update the model to plan Proteus' build

    With our first qualifier being less than 2 months away, Iron Reign embarked on an ambitious project to create a robot with a circular chassis, an elevator-like intake system, and a fully automated launcher. While this robot is still in construction, we do have a name for it - Proteus. Named after the early-prophetic sea god who was also known for his versatility, this was the most fitting name for our robot given how flexible we needed to be this season and with only a few weeks left to construct a robot. In an earlier post, we detailed our decision to reuse our circular chassis in order to improve our robot's maneuvering abilities and get around other robot to avoid the traffic towards the goal posts. However, we are yet to decide which of our three intake systems to use as well as how the progression of our launcher might change considering that it is still in its CAD stage. To see how each of these intake systems look on the robot, we modelled the chassis design from the beginning stages and created multiple models to represent each launcher mounted on the robot.

    Earlier in the season, we created a model of just the chassis itself to account for the fact that we are only reusing the chassis design from last year and nothing above it. The updated model still has the same base chassis design from the earlier model, but it now has three different iterations - one with the ladder intake, one with the caterpillar intake, and one with the elevator intake system (yet to be named). Since the elevator intake does not yet have a full-fledged design, we are holding off on a full robot model with it until we figure out how to make it compatible for a final design.

    Next Steps

    With our robot model in progress, we can now plan out all our steps ahead of time in CAD so that we will make less mistakes on the physical build. We will be updating the model as the season progresses.

    Ladder Intake Build

    Ladder Intake Build By Jose and Bhanaviya

    Task: Physically build the ladder intake, based on the design in CAD

    For the intake system of this year's challenge we first brainstormed several ways which a ring could be collected and transferred to the launching system. Through that and experimenting with CAD, the ladder intake system was developed. Essentially it functions by using the series of Omni wheels on its edge to collect the ring, and then pivot back up to the robot. As pictured below, the ladder intake will be mounted onto the back of the robot and pivot as needed to collect the rings.

    Construction

    The ladder intake was constructed using 8 REV extrusion bars connected by 6 plastic brackets, 2 servos, 7 Omni wheels, a shaft and its respective parts for the wheels to rotate on, a sheet of polycarb below the Omni wheels and shaft to support the rings, and 2 more brackets for the servos to be mounted onto. As shown in the picture below, the idea is for the rings to be reeled in by the Omni wheels and be held using the support of the sheet of polycarb below the shaft, and then be transported to their designated locations in the launching system by the intake pivoting back.

    Testing

    Although the system seemed promising on paper, it unfortunately did not work out as intended. When tested with some first draft versions of code, we found out that the system was unable to actually take in the rings, and instead could only hold them. There wasn't enough traction on the rings for them to be reeled into the system in the first place, which was an issue. We will use this experience to construct an intake that overcomes these issues moving forward.

    Next Steps:

    Start brainstorming a new intake mechanism possibly using some of the components of the current intake that can overcome the issues that hindered the ladder intake from functioning optimally.

    Flywheel Assembly

    Flywheel Assembly By Jose

    Task: Assemble the flywheel with the readily manufacured parts

    Following the milling of the aluminum plates and the 3-D printing of the core of the flywheel, it is time to put it all together. The first step was to sandwich the ninjaflex core with the aluminum plates, and secure them together with long m3 screws. The plates have a spot for bearings, and those allowed for the addition of a 8mm circlular shaft. From there, the cut-out pulley was directly attached to the flywheel using more m3 screws. This pulley is how the flywheel will be driven, and it has a cutout to be able to fit bearing inside of itself.

    Following the assembly was testing, initial spinning by hand revealed some shakiness in the flywheel. This is likely due to variability in any of the parts, as well as the bearings.

    Next Steps:

    Further investigate the reason for the shakiness of the flywheel when spinning, and modify the weight distubution as needed to correct any variability.

    1/16 Build Progress - The first rings fly

    1/16 Build Progress - The first rings fly By Trey, Cooper, Aaron, Paul, Bhanaviya, and Jose

    Task: Continue developing the ring launcher and do preliminary testing

    Today we continued to further our progression on our ring launcher, finally getting to do some preliminary testing to see what the design might do. For starters, we started to get some of the walls off of the 3d printer which was the first piece of our flywheel launcher barrel design that started to come into real life. We also modified the pulley for the flywheel with the CNC that would eventually be used in the final construction. We had to do this because we want to be able to use our REV motors and driving belts to move the non-REV wheel. In order to make sure that we could do this we set up a machining path that would remove an inner circle of material from a standard pulley so that we can put bearings through it.

    The machining of the pulley is actually fairly simple. All we did was set up a path that would mill a cylinder out of the pulley. What was more complicated was what we had to do before that since you can’t mount the pulley on the CNC since it doesn’t lie flat. Instead, we modeled and CNCed a divot for the pulley to fit into along with some holes for screwing the pully to the CNC. You can see both the divot and the final product above. This operation isn’t that difficult on the machine since it’s just plastic and wood but this is the first time that we have had to mill a divot to machine a part which is what makes it notable.

    Then we put what we had together for the first time on a sheet of particleboard and spun up the wheel to see if we could even get a ring moving. We did get some success and the rings did launch several feet but we did have a few problems. Mainly that the walls were being held in place by people so they were moving and we couldn’t get enough grip on the rings. However, actually assembling the flywheel in housing will solve this problem. Honestly, we weren’t looking for problems in the first place though. This event would fall more under team bonding because we really just wanted to see a ring fly. We put in a lot of work and it was quite inspiring to see the ring actually move.

    Next Steps

    We still have a lot more manufacturing ahead of us. We still need to finalize the model and the CAM of all 3 of the plates in the barrel and 3d print more parts. We also still need to assemble and think about how we are going to get the rings into the launcher which will come and bite us in the butt at some point. For now, it was nice to see some progress as well as the first rings fly.

    Updating Proteus' model

    Updating Proteus' model By Bhanaviya and Jose

    Task: Update the model to plan TomBot's build

    With our first qualifier being around a month away, Iron Reign is currently in the midst of trying to put together a functional (or semi-functional) robot. In a previous post, we detailed the earlier stages of our CAD design. As of now, Iron Reign is still testing our intake systems but before we finalize the system we want to implement, we plan to construct a robot with just our launcher system mounted. The reason for this is that we have more or less finalized the CAD design for our launcher (which you can read about in one of our earlier posts) and before we can begin the actual assembly and mounting, we need to have it represented in our robot model.

    So, we created a render with just the launcher itself mounted onto our robot Proteus. We anticipate that although the model will change substantially once an intake system has been mounted, the position of the launcher will be consistent and having this modelled allows us to plan out our articulations and strategy for scoring rings into the goalposts.

    Next Steps

    Once we have finalized which intake system we plan to use, the model will be altered accordingly to reflect these changes. As of now, this model will allow us to visualize and implement the addition of our launcher system which will streamline our ability to plan out how we want mount an intake in the future.

    RingSlinger 9000 Build Progress

    RingSlinger 9000 Build Progress By Paul and Cooper

    Task: Build and prototype the Flywheel Launcher

    For this years new season we used an innovative flywheel-based launcher to score the disks into the goal. After 3 weeks of work, we also managed to come up with a name for it - The RingSlinger 9000. Any posts referring to our flywheel launcher refer directly to the Ringslinger itself. This launcher uses the properties of rotational inertia to propel the game pieces along a carefully calculated, fixed trajectory to ensure that the disks have the same launch trajectory every time, allowing both automation and driver control to more simple. The assembly is physically constructed from several sheets of aluminum and one sheet of polycarbonate, modeled by Jose and cut on our CNC mill. The spacers between the sheets are made of nylon due to its high strength and low friction, and we chose to use a custom ninjaflex ring around the CNC milled flywheel to ensure that the wheel could transfer the maximum amount of kinetic force to the disks. The launcher is designed in such a way as to impart rotational energy on the disks, spinning them. This helps maintain a constant trajectory, similar to how an NFL Quarterback spins the football when scoring a touchdown pass, or how the grooving on a rifle spins a bullet, ensuring in-flight stability. In tests, our design proved to be mostly effective, launching disks along a consistent trajectory. Our first firing test was during our video meet with the DPRG, and with a few tweaks, it was performing up to standards. However, there were some issues that needed to be addressed - mainly, we need to complete further testing to see if any of the rings experience damage as a result of our launch, where the general area the rings tend to cluster at, and fine-tuning an equation to model the launch. Correcting these issues will make the accuracy of the RingSlinger that much more accurate.

    Next Steps:

    Future plans to expand upon this design include integrating a voltage regulation module, to ensure that the disks are always spun at a constant velocity. In tests, we noticed that as time in a round passed, the drop in main battery voltage caused the disks to be launched at a slightly slower velocity, not enough to phase a human driver, but enough to render automated shooting protocols inaccurate. To remedy this, we will find out the lowest point the battery will reach during the course of a match, and regulate the voltage being fed into the flywheel motor to not surpass the aforementioned "low" voltage during the match.

    Build Progress 1/30

    Build Progress 1/30 By Trey, Justin, and Jose

    Task: assemble different intake prototypes

    Today we worked on different intake systems to place the rings in the launcher. We finished our first prototype for a belt type intake and lift. The 3d printed belt was able to slide rings along a vertical piece of polycarb to place rings into the launcher. The speed of the motor and belt makes this one of our quickest intake and delivery prototypes. Our other prototype was a spatula shaped "intake" that would scoop up disks, and flip them upwards into a basket on top of the launcher. We used aluminum CNC'd into a curved spatula that would perfectly fit around the disks to ensure an accurate launch. Rubber bands pull the spatula upward, where it hits stoppers and launches the rings upwards. This prototype created semi consistent flips, but it was hard to gauge how far down to pull the spatula to give a desired launch height. A problem with this method is the many different factors that can be changed to give an optimal launch. Different launch angles, distances from the launcher, rubber band tensions and lengths. This flipper would involve a lot of experimentation that would result in mostly failures. This method also requires a lot more driver skill to scoop up the relatively small disks.

    We also tested our fully assembled launcher - the Ringslinger 9000 - with working code. We wanted to measure how consistent our launches were by shooting multiple rings at a target and measuring the furthest distance between impact points. We used flour on a flat surface to show where the rings were hitting, then circled the clusters for our trials to get an approximate radius of error. We found that our launches were mostly consistent within a small radius, but had outliers that were hitting the exact same outer lying spot. This indicates a consistent flaw with our launcher and requires a closer look at how it moves and launches the rings. We also repeated this test by identifying where the rings tended to cluster when they had been launched beyond the length of the goal-post - even though the Ringslinger 9000 was not supposed to launch rings at such a height, identifying where it tended to cluster after landing also allowed us to evaluate its general launch patterns and accuracy.

    Next Steps:

    The belt system can easily grab disks and brings them to the other end of the ramp very quickly. While it works well when we test it with our hands, we need to create a rigid structure to connect the belt and ramp, which will be mounted on the chassis. This will allow us to see how the belt will need to pivot to grab rings, and if our current belt still maintains grip without human assistance. We will also take a closer look at our launcher to see what's different about our outlier launches.

    Flywheel CAM

    Flywheel CAM By Trey and Justin

    Task: CAM and cut our flywheel model

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

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

    Next Steps:

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

    Ringslinger 9000 Overview

    Ringslinger 9000 Overview By Trey

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

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

    Build Breakdown:

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

    Manufacturing:

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

    Testing and Calculations:

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

    Next Steps:

    We are working right now on dialing in the shooter to make it more consistent and also testing a 1:1 motor to see how it compares to the 1:3 motor in terms of accuracy. We are also being posed with a challenge unlike any other challenge we have faced this season which is taking what we made when we were developing intakes and making a system that can feed into the shooter. This is going to prove a challenge because of the size of the shooter and the fact that it can be rotated or tilted to any angle. The challenge may be large but we are a worthy opponent.

    Pink v. Cyan Remote Scrimmage Post Mortem

    Pink v. Cyan Remote Scrimmage Post Mortem By Cooper and Jose

    Task: review the progression of matches in our latest scrimmage

    We participated in the “Pink v. Cyan Remote Scrimmage” over the week, wherein we submitted our matches at an appropriate amount of time before the cutoff time. Doing this scrimmage has given us good insight into how to tune the performance of what is on the robot already, and what needs to be added. We submitted the standard 6 matches, and I want to go in depth for each.

    Before I delve into the weeds, I would like to explain our hypothetical perfect run for these matches. In auton, since we aren’t using vision quite yet, we had the robot always assume a 4 stack. The robot should put the wobble goal we are holding in the start ibn the appropriate corner tile, then backup to park on the line. In teleop we should retrieve the second wobble goal and put it across the line. With this all such that we can, in the endgame, put both of the wobble goals over the back wall. So therefore, in a perfect run, we could have 60 points max. An example can be seen in the video above.

    Match 1: Starting off on the wrong foot, when we started auton things looked fine. However, our pink decorations on the front of the robot got caught in the front caster wheel, making us veer off and hit the wall. We were able to re-orient the robot since the next few steps of the auton were based on the imu. However we didn’t park due to being off of the expected final position of the first movement. During teleop we successfully moved both of the wobble goals over to the other side of the shooting line, and then in teleop we just barely ran out of time putting down the second wobble goal over the back wall.

    Match 2: We got lucky in the second round and got the preferred 4 ring stack. However, we couldn’t make use of that luck due to a driver error when selecting the auton-- auton did not execute. So in teleop, we moved both wobble goals over to the correct side of the shooting line. Then, in the endgame, we successfully moved one wobble goal over the wall. The second we ran out of time trying to grab.

    Match 3: This time around, we had the opposite happen from the last round in auton. The rings randomized to be a 1 stack, but auton performed perfectly. Teleop was nominal, but endgame posed a new problem. When trying to put the wobble goal over the wall, it got stuck on the turret, seen in the video below at 2:44. This costed us enough time to have us not score any of the wobble goals

    Match 4: this is the video at the top of the post, because it was a perfect match.

    Match 5: Like match 3, we were randomized 1 ring, and auton performed perfectly. Unlike match 3, teleop and endgame were normal, with us scoring 1 wobble goal.

    Match 6: Final match, auton almost worked. The wall-following messed up at the very end of the first run, making us drop the wobble goal just out of the box, and miss parking. In teleop/endgame, we almost had a repeat of match 3, but we were able to shake off the wobble goal and score one.

    To start on the subject of lessons learned, It is obvious we should practice more. Driver practice has always been a weak area for us.(Having said that, for the amount practiced the driver did excellent). One thing the driver should not have had to account for is that possibility to lodge the wobble goal on the robot. This is subject to change anyways, as when the launcher is mounted on the robot, the wobble gripper is going to have to move. Not only move, but change; the current gripper has too tight a tolerance to be used effectively. It isn’t possible to have it stay the way it is when drivers will also be tasked with picking up rings. Finally, we learned that we need to work out the kinks in the wall following what happens at the beginning of auton. We only really did this, because we are still working on a better way to square the IMU to the field, and the human error was too great and cumulative on that far run to have it work reliably.

    Next Steps

    Execute the solutions to the problems found.

    Intake Iterations Summary

    Intake Iterations Summary By Bhanaviya and Ben

    Task: Go over our 5 intake iterations

    This season, we experimented with 5 gripper models - both for our robot in three days project and for our competition bot. While we do not plan on using all 5 of these models, they allowed us to effectively implement the engineering process within our build season. Experimenting with each intake helped us to identify the potential of each design as well as how two individual designs could be combined to create a more efficient one. Each of these designs has its own article but this is just a summary of all of our intake designs so far.

    1)Archimedes Intake

    This was one of our first designs and it was based on an Archimedes screw. A screw shaped surface would draw the rings from the fields and directly to the launcher. While this would have been a great feeder, our primary issue was that would essentially be a slower system which could likely only draw in ring at a time so it never progressed past its CAD stage.

    2) Ladder Intake

    This gripper functions with a series of omniwheels mounted in between two rev extrusion bars, which in turn are connected to a ladder-like assembly with a control hub mounted on the first rung of the ladder and to the wheels. As the wheels rolled, they would slide on top of the rings and roll them into the system. The issue with this system was that it had significant delay in "rolling" the rings in since if the omni wheels spun too fast, they would lack the tracton to "grip" onto the wheel.

    3) Belt Sander Drive

    This system was far more simplistic than our earlier ones and had a faster intake speed during testing too. The actual drive would be mounted onto the robot with the "back" of the system sliding over the rings and carrying them across the conveyor belt to the top of the robot. Despite its efficacy, it had one main issue - it didn't have the gription needed to ensure the rings slid across the belt.

    4) Caterpillar Intake

    Luckily, the gription issue could be resolved pretty easily with the caterpillar intake. This system was dual tracked unlike the first one, and had rubber bands threaded through the tetrix tracks to improve gription with double the power. Ultimately, this was a pretty successful issue but it did not have as much speed as it could have and lacked the signature Iron Reign charm.

    5) Ringevator Ultra Flex Unlimited Intake

    This gripper, the Ringevator, for short was a combination of our two previous best systems - the belt sander drive and the caterpillar. It possessed the mono-drive from the belt sander and similarly drew in rings from its back and carried them across a conveyor belt to the top of the robot and like the caterpillar, had a means for increasing friction with the surface of the rings. While the caterpillar intake did this with rubber bands, the Ringevator accomplished it with ninjaflex "fins" layering the "belt" to sweep in the rings. Both sides of the intake are covered with polycarb to encase the conveyor built internally and to ensure the rings don't fall off when picked.

    Next Steps

    Now that we have analyzed all of our intake designs so far, it will be easier for us to streamline the best design to mount on the robot. While the ringevator seems to be our best choice, we still need to conduct further testing to see which one is the most efficient.

    RingSlinger 9000 Summary

    RingSlinger 9000 Summary By Jose

    Task: Summarize the key components of Ring Launcher 9000

    A ring launcher is more than just a flywheel; it needs a barrel to give the ring a path to move through. A 90 degree barrel is the best fit for ROBOT as the intake will take up the other half of the robot. The plan is to later on add an indexer to transport rings from the intake to the barrel in a way that can be controlled, that is, allowing the driver to manually choose when to let rings into the barrel.

    The barrel design looks simple, but there are lots of hidden things making it work as intended. For one, the motor driving the flywheel is attached via a slotted motor mount. The mount is then placed directly on the center plate through an extension to the center plate. Additionally, there is a plate below the one that the ring travels on top of. This plate is used to keep the shaft in place, it follows a similar shape to the others to preserve strength, as it is half of what keeps the flywheel in place. The bottom plate also supplies support to the center plate, this is due to the fact that the center place is not attached to the flywheel, instead it has 3mm of clearance in case of any vibration the flywheel may have. Finally, at the exiting end of the barrel, the side wall extends linearly to ensure the ring doesn’t spin off its intended path.

    Over to the other side of the barrel is the ring feeder. A huge nylon wall guides the rings into the ring flipper. The ring flipper is composed of a a servo with a custom made flipper to push rings into the flywheel.

    Next Steps:

    With everything milled out and 3-D printed, the next step is to take this to programing as the idea is to have the ring laucher be almost completely automated.

    Meeting Log

    Meeting Log By Ben, Bhanaviya, Cooper, Jose, and Trey

    Task: Prepare the portfolio and intake before the qualifier

    The three of us worked on the engineering portfolio, discussing what we needed to get done in these 3 weeks between now and the qualifier. It was agreed that Ben, Bhanaviya, and Jose would be largely responsible for the portfolio and having other team members add information when necessary. We also began drafting an email to a physics professor who may help us with our physics calculations.

    Trey and Justin mostly worked on rebuilding the ring intake to make it easier to mount onto the robot. They also rebuilt parts of it to make it easier to service in the future. There were little issues with this, although access to the robot was limited at times during code testing. Time constraints also played a role in the progress that was made.

    Cooper had planned on calibrating the ticks/degree on the arm, implementing the trajectory calculator, fixing the LED on the robot, and making progress on Vuforia. By the end of the work period, he had successfully calibrated the ticks per degree on the robot arm and implemented the trajectory calculator. He decided to fix the LED later because of its low priority and time constraints restricted progress on Vuforia.

    Next Steps

    The next steps for the portfolio are to begin formatting and gathering information for all the subsystems and from team members. Once we have all the information, we will have to condense it into an easily-digestible 15 pages. We will also have to fix the LED lighting solution on the front of the robot, along with troubleshooting Vuforia.

    Ringslinger 9000 Step-by-Step Guide

    Ringslinger 9000 Step-by-Step Guide By Anisha, Paul, Trey, and Cooper

    Task: assemble different intake prototypes

    The Ringslinger 9000 is a crucial part of the robot and requires careful planning to build. Although we have a relatively simple intake and launching mechanism, their components are a bit more complicated. After getting the individual pieces of our launcher system ready, we were able to start putting them together to form the system. This post will serve as a step-by-step guide on how the entire launching system was assembled.

    The process starts with the launcher baseplate which was constructed using aluminum and was cut on the CNC mill. As shown in the picture above, several holes were strategically placed in various areas on the periphery of the plate for screws to go to hold the other elements such as the Ultraplanetary REV motor that powers the flywheel and the nylon guide wall which guides the rings as they move through the system. The plate itself is mounted onto 2 REV extrusion bars using several metal brackets as shown below.

    The bars are mounted onto a hinge which carries the entire system and rotates as needed during the game.

    Launcher Guidewall/extension

    The custom-printed guidewalls are attached to the plates using retaining screws, and function to guide the rings to the flipper to be prepared for launching.

    Motor Mechanism

    The REV 3:1 Ultraplanetery motor which drives the flywheel is attached via a slotted motor mount as shown below. It is then placed on an extension of the launcher baseplate using 6 screws. The motor can spin its sprocket at 1,727 RPM and drives the wheel by a belt between the two sprockets.

    As mentioned in the Ring Launcher Summary, our launching system essentially is made out of 3 levels: the mounting, driving, and ring levels. The pictures below show the driving level's center plate with 3D printed nylon spacers mounted to separate it from the ring level. The spacers closest to where the flywheel will be attached each contain 2 holes and are attached by screws. The larger spacers also contain 2 holes where screws are attached to mount the driving and ring levels together. After getting the two individual levels ready, they are put together using screws, as shown below.

    Shown below is the custom-made servo spacer. The servo is mounted next to the opening that is next to where the motor is mounted. It is fixed into place using screws.

    Pictured below is a bird's eye view of the center plate. The servo located on the back of the ring slinger essentially spins the ring flipper to exert motion onto the rings to prepare them for launching by pushing them into contact with the flywheel. The REV Ultraplanetery motor is mounted onto the platform using 4 screws and nuts and the servo is mounted also using 4.

    The flywheel is composed of a NinjaFlex center wheel which is sandwiched between 2 custom aluminum plates.

    The flywheel's upper aluminum plate works to keep the wheel from flying upward. A polycarbonate sheet works with its lower aluminum plate to fix the axle in place. The polycarbonate sheet is shown below. It also plays a role in keeping parts in place.

    The Flywheel is attached to a pulley which drives it using the belt that runs from the wheel pulley to the REV motor. As seen in the CAD model above and the picture below, the wheel was assembled by connecting the 2 aluminum plates to the NinjaFlex wheel in the center using screws. The flywheel spins on the shaft that is locked into place with the shaft collar on each end.

    As shown above, the whole launching system to the arm that sits on a pivot in the back of the robot which adjusts itself by rotating to the angle that is ideal for where a ring needs to be launched to.

    Finally, a look at the robot after all the individual parts were assembled is pictured below.

    Next Steps:

    One of the highlights of this system is that it is completely custom-designed and built . All our parts were either 3D-printed or custom-machined on our CNC. Documenting its assembly allows us to keep track of all of the parts involved in its print. Being able to showcase the build stages of the Ringslinger 9000 is also incredibly useful for two more reasons. First, if we ever intend to build a second one, we have the progress of the first one fully documented for inspiration and/or to isolate potential causes of structural error. Second, if any teams who follow our blog want to create a similar model, they have ours for a source to help. As the launcher continues to undergo changes, it is likely we will create another such assembly post - likely after our first qualifier in 3 weeks.

    A Lot to Intake

    A Lot to Intake By Paul

    Task: Prepare the intake before the qualifier

    Today’s meet consisted of Cooper working on code, Paul burning polycarb, and Trey working on the intake with Paul. We were able to get the ringevator-esque intake working with some level of reliability, at least off the robot. The design is quite ingenious, using the friction of the rings against the floor and a polycarbonate scoop-type thing to integrate the flipping of the rings and the lifting of the rings into one cohesive unit, that saves space, motors, and weight. Paul was in charge of heat-bending the polycarbonate plate, but Paul overheated it and ended up warping the plate. However, this proved to be quite useful, as the warp helped to hold the rings against the ninjaflex elevator belt. Sometimes, rarely, screw-ups are a good thing.

    Meanwhile in the robot garage dungeon, Cooper was working on optimization of the code and helped to optimize the odometry, calibrating the robot's autonomous mode to be more accurate based on its surroundings, using both the IMU and potentially an intel RealSense camera in the future. In addition, Cooper worked to enhance the robot’s position holding and automatic targeting systems, helping to ensure that the ring lands in the goal, every time, automatically. Pretty neat stuff.

    In the more whimsical department, the robots 12-round chefs-hat extendo-mag turns the robot from an FTC legal precision machine to a motorized fear-inducing machine. This extended mag was used for demonstration, target testing and shooting rings at unsuspecting team members only, as FTC regulations only allow the robots to be in control of 3 rings at a time, not 12 (though that would be kinda cool).

    Next Steps

    With the ringevator mounted, we plan to get the mag removed by the next meet to create more precision with our launcher system.

    A Lot to Intake

    A Lot to Intake By Paul

    Task: Prepare the intake before the qualifier

    At today's meeting, Paul worked on the ringevator, with the guidance from Mr. V. The intake mechanism required a motor to be installed, which at first glance seems like light work. However, the intake is composed of two separate parts that move independently, connected by a hinge. The motor had to be attached to the static, robot part, however, the power had to be transferred to the belt, which just so happened to be on the dynamic part that swings around like a screen door in a hurricane, so mounting the motor on the swingy bit was out of the question. Paul took a page out of last years book, drawing inspiration from the elbow mechanism of Icarus and with some help from Mr. V, designed a mechanism that allowed the belt and hinge to rotate on the same axis, ensuring constant distance between the motor axis and the axis of rotation for the belt pulley. This allowed the motor to be mounted in a safe spot on the robot, away from the dangers of an FTC field, while simultaneously being able to drive the belt mechanism on the moving part of the robot. Future plans call for replacing the pulley drive bushings with custom fabricated ball bearings, and moving the motor further down the robot to lower the center of gravity.

    Next Steps

    The ringevator still needs to be mounted on the robot but this was enough progress to hopefully get us to a working intake before the qualifier.

    Morph Chart

    Morph Chart By Bhanaviya and Ben

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

    Iron Reign has seen several iterations of our intake over this past build season. With our first qualifier being 2 days away, its finally time to come full circle and identify the different iterations of our intakes coming together. To do this, our team used a flow chart. A morph chart shows the various subsystems of our 2 robots in this system - our robot in 2 days bot Frankendroid and our competition bot TomBot.

    Each intake's progression is represented vertically, shwoing stages from the sketch, to the CAD to the final product. For the Ringevator intake design in particular was inspired by a combination of two other intaek designs - the belt drive and caterpillar. The combination of these two designs, as well as a description of each design is also represented on this chart.

    Next Steps

    Placing all of our designs in one chart like this allows us to see how iterative our design process has been, and how much of an influence each design has had on another. With all of our designs so far placed in the flow chart, our next step is to continue to update the chart after our first qualifier so that we can have a pictorial summary of our entire build season for reference.

    Ringevator Overview

    Ringevator Overview By Trey

    Task: Describe the construction and development of the Ringevator intake

    This year we have done a lot of work on intakes and launchers. The purpose of this post is to go over the function and overall design and build of the Ringevator intake. It doesn’t go too far in-depth so if you are looking for something more specific I would recommend that you look at specific posts discussing different parts of our design but if not you are in the right place.

    Build Breakdown:

    The construction of the Ringevator is moderately complex. It consists of a custom belt, two axels, a motor, a pivot, a base, and some elastics. The belt is custom modeled and printed in NinjaFlex. The design is based on the belt seen in one of our previous robots, Kraken, which competed in 2018. It has flaps that do the work of pulling in the rings and holes that are used by sprockets to drive the belt. The holes are the exact size and space apart to be fitted onto the sprockets on the drive axels which are attached to the base. The base is a simple H design that used to be in between the sprockets but now sits so that the sprockets are inside to make mounting easy. The axels are driven by one motor attached by a belt on the base of the robot.

    As you can see in the photo above, the belt assembly base and the robot base have a pivot between them. The purpose of this pivot is to make picking the rings much easier. Normally you would have to pick a ring up horizontally and then turn it to a vertical orientation which is what we need but instead, the pivot allows for the belt assembly to walk over rings. This means that when the intake reaches a ring, the movement of the belt causes the mechanism to open and consume the whole ring. Since only one side of the ring is being pulled up by the belt, it is flipped vertically and travels up the rest of the mechanism and out the top. The elastics make sure that the belt keeps in contact with the ring at all times. The only other thing that is apart of the design is a guide ramp on the inside made of heat-bended polycarbonate. You can see a photo of this ramp below along with the intake before it was attached to the robot on a pivot.

    Testing:

    We tested the Ringevator multiple times throughout its life to make sure that it will work. It gets a good grip on the rings and is able to pull them up most of the time. We still need to iron out a few tensioning issues with the elastics to make it more consistent but other than that it works well based on our tests so far which are few and far between. More testing will come.

    Improvements:

    The design didn’t start out this well though, we made several improvements since the start. For starters, the whole pivot idea was a mistake, to begin with; however, we discovered while doing preliminary tests that the belt walking over rings was a feature, not a defect. We realized that picking up rings without the pivot would be far more difficult and that was the spark for the design we have now. We also suffered some grip issues with the polycarbonate ramp which wanted to grip the rings too much and hindered the ability of the intake. We fixed this with some friction-reduced tape and now it works well. The design is still in its baby stages so we haven’t found a lot of problems but we will eventually and we are excited to address them.

    Next Steps:

    We are working right now on dialing in the shooter to make it more consistent and also testing a 1:1 motor to see how it compares to the 1:3 motor in terms of accuracy. We are also being posed with a challenge unlike any other challenge we have faced this season which is taking what we made when we were developing intakes and making a system that can feed into the shooter. This is going to prove a challenge because of the size of the shooter and the fact that it can be rotated or tilted to any angle. The challenge may be large but we are a worthy opponent.

    Making the Ringevator Legal

    Making the Ringevator Legal By Trey and Paul

    Task: Make the Ringevator legal so we can use it in competition

    We’re at the point now where we have a lot of our systems ready to be put on the robot, but we have to face another big challenge, which is making everything legal. Since the robot is a circle, we don’t exactly have any space to put an intake in the sizing cube. We can take advantage of the hypotenuse of the box by putting our equipment in the corners but then we raise the problem of height. This is because the Ringevator was never actually built to be permanently attached to the robot.

    We built the Ringevator as a prototype that harnessed the abilities of all of our previous models without their problems. However, with time closing in, it became apparent that the ringevator would have to be on the robot regardless of what we think. In order to do this, we had to shorten the assembly by about 2.5 inches and somehow pull the assembly inside more. With only a few builders being able to join us at any particular time, this proved to be a challenge.

    Two things needed to happen to make the robot even close to legal. The first was that the front would have to be chopped off, spitting the front Omni wheel assembly in two. And the second was actually shortening the ringevator which meant shortening the belt. The first part was easily accomplished by modeling two new Omni wheel bases for the front and surgically removing the front of the robot with a hacksaw. This was accomplished in the span of two days. After this was done, Paul also chopped the top of the ringevator off. The last piece was the belt.

    The problem with the belt was that I was the only one who knew how to shorten it and I was stuck at home for the next few days. So after Paul was done with the robot surgery, he swung by my house at 3 AM and dropped the belt off in my mailbox. The next morning, I marked off about 5 inches or 5 flaps of the intake, printed a new rig for the welding, cut, and welded the belt into a shorter configuration with my own tools. Then to get the belt back to the robot, we thought about getting a courier to deliver it but instead, I showed up the next day with the new belt and it was assembled onto the robot. After all of that, the robot was still not legal. The reason why it wasn’t legal is because we used bulky REV extrusions as sides since they are easy for prototyping. Since those rails are thick it just barely falls out of the sizing cube. So we had to detach the whole assembly for our next competition.

    Next Steps

    We would have liked to cut the assembly down more at this point but we couldn’t because we had already pushed the limits of its size. Our next step is to completely redesign the whole intake system. We knew this was going to have to happen at some point but we didn’t think it was going to be this soon. In order to make the intake legal, we have to CNC all of the parts. And I think that’s the kind of challenge Iron Reign is built for.