Articles by tag: mechanical

Articles by tag: mechanical

    REV Robot Reveal

    REV Robot Reveal By Tycho, Austin, Charlotte, Omar, Evan, and Janavi

    Argos V2 - a REV Robot Reveal

    This video was pulled from Argos visits to: The NSTA STEM Expo in Kissimmee FL, in the path of eclipse totality in Tennessee, and in North Texas at The Dallas Makerspace, The Southwest Center Mall, Southside on Lamar and the Frontiers of Flight Museum. We hope you find it interesting:

    Intake System Competition

    Intake System Competition By Evan and Austin

    Task: Compare build designs for the cryptobox intake system

    The block scoring system is going to be an integral part of the competition this year, and it will have to built sturdy. It’ll have to be reliable for us to have any shot of winning any matches. So we got to brainstorming. We spent a while at the whiteboard, drawing up various mechanisms and ways to pick up blocks. One idea was the idea of a block delivering system similar to those modern vending machines that have two degree of freedom movement. We began to design the contraption so that a conveyor belt could be placed on an up and down linear slide to position the blocks just right to make the different symbols. Another person came up with the idea to use our tank treads from Geb, our competition robot from two years ago, to push the blocks up a ramp and deposit them into the cryptoboxes. Neither of us could convince the other about what was to be done, so we both split off to work on our own models. Next week we will keep working on this build off of the century.

    Makeshift Glyphs

    Makeshift Glyphs By Janavi, Abhi, and Evan

    Task:

    After the game reveal video was released we had some ideas on how to have our robot grip onto the blocks, but we couldn't test it without a makeshift glyph to hold onto. So we decided to upcycle some old cat and weather damaged field tiles by cutting them up into 6 X 6 squares and placing them in a cube formation. Attached below is an image of our handiwork and a image of the glyphs used on FTC fields

    Our glyph real glyph

    Reflections

    This did not end up work very well and in hindsight we could have used other materiel like printing out a 6 X 6 X 6 frame on the 3-D printer or by making it out of foam board so it would be more similar to the real thing. But thanks to the generous donations of the DISD STEM department we were provided with a full field set so we don't have to worry about creating our own glyphs. However, we will remember this for the future.

    Further Design of the Intake

    Further Design of the Intake By Evan and Austin

    Task: Design the grabbing systems further

    The sun came out and it was back to the field. We got started right away, both of us building our designs. Since the cryptoboxes were wider than the 18 inch sizing cube, we started by designing a fold out for the conveyor belt. This was entirely proof of concept, purely to see if it was at all aplicable in the game this year. We spent an hour or two gathering parts and put together an extending conveyor belt. This device would swing down, like the arrow suggests, allowing for more space to move the blocks back in forth, giving us accuracy in rune completion. This will be later attached to linear slides, allowing for an up and down motion.

    Intake Systems

    Intake Systems By Austin

    Task: Work on designs for the intake system

    Over the past couple of days we’ve experimented with a horizontally mounted track system that we had hoped would serve to move blocks through the entire length of the robot and into the crypto box. Immediately we noticed a few issues, the primary one being that the tread was static in terms of mounting and therefore wasn’t accepting of blocks when feed at an odd angle. To correct our feeding issue, we widened the gap between the tracks and added rubber bands in hopes of maintaining traction and adding to on demand orientation ability.

    Initial tests of our second prototype went fairly well, however the design suffered from some severe drawbacks; the first was its weight and size which would limit robot mobility and take up much needed space for other components, the second issue was that keeping the treads tensioned perfectly for long periods of time was nearly impossible and they would often sag leading to loss of grip, and finally the system was still fairly unpredictable especially during intake (blocks were flung occasionally). These finding lead me to believe we may scrap the idea in consideration of time.

    Aside from our track intake we’ve also been working on a gripper and slide system that shows promise.

    Narrowing Down the Designs

    Narrowing Down the Designs By Evan and Austin

    Task: Redesign our grabber systems

    In an attempt to get a working lift system before the coaches meeting we will be presenting at, a linear slide has been attached to the robot, along with a pair of grabbing arms. They work surprisingly well and aren’t as complicated as my idea. Plus the importance of speed has really taken hold on me this year. We need to be as fast as possible but my contraption is slow compared to the grabber arm. I think we'll be scrapping the idea for this grabber arm bandwagon everyone seems to be hopping on. While the grabber arm allows for quick pick ups and easy placement, our idea was only bulky and unnecessary because of our use of mecanum wheels which eliminate any need for a system to go side to side. Since the grabber was rudimentary, we’ll be making improvements and new iterations. We toyed with some materials earlier on in the season, and we’ll probably be implementing that into it.

    Slide Designs

    Slide Designs By Austin

    Task: Figure out slide mechanism

    After determining that the treaded channel was much too buggy to perfect with the time we had, we shifted attention to other scoring systems like grabbers, however before finding the right grabber we decided we needed to get the track for it completed first. We’ve had experience in the past with all sorts of rails from Tetrix kits that convert their standard channels into lifts, to the newer REV sliding rail kits which we also toyed around with in initial prototyping shenanigans.

    One of our key concerns was also wear and tear, in that we have had systems slowly breakdown in the past, such as our mountain climber and catapult, since they had plastic components that broke over time, we knew that long periods of use over multiple competitions would deteriorate the plastic components of either rail sets, and other rails that used full metal parts would simply be bulky and rough to fit in snugly with our robot. After a bit more research we settled on standard steel drawer slides from home depot, mainly because they were streamline and all around sturdy. The slides also provided us with easy mounting points for our future claw and attachments.

    We understood that whatever option we picked for slides would have to be easily repairable or replaceable during competition, should something go wrong. Since the drawer slide were easy to come by and needed little modification we could easily make duplicates to act as stand by and demonstration parts during competition.

    These positives came to form more than enough of a reason to continue prototyping our grabber that would eventually be attached once completed to the lift, which was now mounted to the robot and used a system of spools and pullies to extended above the minimum height for scoring in the top row.

    Building Competition 2017

    Building Competition 2017 By Evan and Austin

    Task: Find the best robot design

    The games have begun and it’s time to build. So that’s what Austin and I did. A war had been declared. Legions of the indentured collided on the battlefield. Millions were slaughtered during this new age armageddon. Austin had his army. I had mine. Two different ideas to do the same task: lift glyphs into their correct positions. A simple job but one that caused a rift in Iron Reign, an incurable rift between the forces of light and darkness.

    But then I decided to stop because his design had more speed than mine and speed is more necessary this year. My idea had been a lift that could move the glyphs back and forth but I realized that it would be a little too slow for the competition. Or, another solution would have had a side to side conveyor belt that moved glyphs back and forth to arrange them in the correct order, and then push them into the slots. This movement would have been separate from the four mecanum wheels that we are using in the chasis. His idea was simpler than mine, a conveyor belt that ran through the middle of the robot to bring the glyphs to the keybox, where they could be slotted in with the side to side movement provided by the mecanum wheels. So, like an outnumbered Supreme Court judge, I decided to join the winner so I could have a say in the early design. Once he got a prototype ofhis contraption working, it was able to pick up blocks effectively but it still needs improvement. It has issues with blocks at an angle, and it has trouble slotting the blocks into the keybox, but it's a nice step toward a working block system. We are currently planning to use the mecanum wheel base we used last year but this could change anytime. We left practice with a direction and that's better than nothing.

    Designing the Grabber Further

    Designing the Grabber Further By Evan

    Task: Design the grabber design and make future plans

    The grabber has been evolving. A column made of a turkey baster and a wooden dowel attached to servo has come into fruition. The first drawings and designs are coming along, and some 3D printed parts have been thought up to allow the square dowel to become a hexagon. An adapter of sorts. The grabber and lift have been outfitted with a back board to stop blocks from getting caught underneath the backing bar. The back board is just some 1/16th inch wood cut to fit. The new turkey baster columns are in the first stages, so more info on them will come as more is discovered and progress has been made. The sketches will explain these designs better.

    Designing the Grabber

    Designing the Grabber By Austin

    Task: Work on the grabbers more

    With our single degree of freedom lift fastened to the robot we focused on the appendage that would grip to within an inch of its life any glyph we fed it. We initially toyed with simple tetrix channels to form a make shift rail that would hold axels for pivoting points, however we found tetrix to be a bit too cumbersome and decided to use rev rail instead. Using two tetrix U-brackets we built a makeshift grabber that used rubber bands and a servo to secure blocks without letting them slip through its grasp. To add extra grip to the long L-beams that formed the pincers of the claw, we added even more rubber bands, and moved on to testing.

    Initial tests were very positive, the high strength servo coupled with a few rubber bands maintained enough of a grip on one or two blocks with ease, and because the entire system was mounted to a rev rail we could easily slide and size the pincers to the right distance. Feeling confident in our work we attached the grabber to the lift and attempted drive practice, which ended relatively quickly due to a surprising number of jams between the lift and glyphs.

    The key issue we now faced was that as the lift returned to its home state blocks were getting stuck beneath the retracting claw causing jams. To fix this relatively simple problem we added a back plate to the claw that kept blocks from slipping to far into the robot, this was easily fashioned out of a bit of thin wood board we had lying around from the decks of other robots. The overall performance of our glyph wrangling device was astounding, so long as whoever was operating the robot was a well-trained driver.

    Oh No! Dying Glyphs

    Oh No! Dying Glyphs By Abhi

    Problem: Glyph Damge due to Robot Design

    We were tearing up our glyphs like this because our wheels had no guard for their screws:

    More specifically, we had multiple issues with damaging the glyphs. First, the exposed screws on the mechanum wheels (Fig 1) tended to cut into the glyphs as seen in the above picture. As well, you can see relatively sharp edges on the wheels where the block could also be cut, and that the blocks could be pinched by the wheels on the wheel. As well, the corners on the REV and TETRIX pieces cut into thr glyphs when they were rammed into the walls of the field (Fig 2).

    Fig 1

    Fig 2

    Chassis Upgrades

    Chassis Upgrades By Austin

    Task: Upgrade our chassis

    Because our robot at this point has merely become a collage of prototypes that we compete with, there are often subtle improvements that need to be made. Starting with the wheelbase, Abhi has written a blog about the shields we printed to protect the glyphs from the gnashing bolts of our mechanum wheels, and we also tensioned all our set screws and motor mounts to make sure that our base was preforming in terms of the speed and strength we needed. As we add components to the robot things often are shifted around as well, after tuning up the drive train we focused on realigning our REV expansion hubs and their wiring so that nothing would be in the way of critical lift or drivetrain components.

    Any jettisoning bolts that have been catching components while moving, and any sharp edges have all been ground down to ensure that any motion is smooth and that there are minimal catching hazards during operation. Because of the earlier mentioned prototype state our robot was in, many of the key components laid outside of the 18 inch cubic limits and so these components we brought in and neatly fastened to the internals of the robot bearing in mind ease of access for future updates to components. This entire push for cleanliness was the result of upcoming scrimmages and practice matches that we would be participating in.

    Stopping Glyph Damage

    Stopping Glyph Damage By Abhi

    Task: Stop Destroying Glyphs

    Since damaging field elements is a huge no-no, we needed to fix this, we decided to create a 3-D part to protect the glyphs from our wheels

    Model:

    During the first attempt, I had just self taught Creo hours prior to construction. As a result, I was not very precise nor efficient in my design. Nevertheless, we recognized that there were some basic shapes we could use for construction such as a semicircle for the bottom half and two rectangles on the top part. We decided to use measurements that were estimated from a singular mechanum wheel. This culminated in the design below.

    Result:

    The part itself is made out of nylon as usual. Our main issue was measuring the wheel accurately to create a functional part. The two parts hampering the design was that the U-shape must be off the ground slightly, and that the shape's semi-circle would not have the full radius of the wheel. So, we iterated through various designs of the U-shape, changing the height off the ground by ~1mm each time. We also varied the radius, until we realized that we could measure the width of where the semi-circle segued into the rectangle and get the estimated diameter of the semi-circle.

    Wheel Protector Correction

    Wheel Protector Correction By Abhi

    Problem: Wheel Guard Innacuracy

    Refering back to the design of the wheel guard, we decided it was time to actually mount it on the robot. At first, it seemed like the part was perfect for the robot since it fit just snug with the screws on the wheel. However, upon mounting, we discovered the following:

    Turns out that the part is acutely shorter than the real height of wheel relative to the horizontal axis superimposed upon the vertical plane. As a result, a second and better trial for modeling needed to be conducted. For this run, I chose to measure the dimensions directly from the robot rather than a spare wheel.

    Correction:

    As seen above, the corrected version of the part looks and works much better. Though there is a slight margin of error in the success of the part due to the dynamic nature of the density of the field tiles , the part should be reliable for the most part

    Designing the Jewel Thief

    Designing the Jewel Thief By Evan

    Task: Design a part to remove the jewel

    The jewel thief, the mechanism for knocking off one of the jewels, was going to be one of the tougher parts of our bot to integrate, based on the chassis we began with. But, with a little engineering and some long thought, we came up with a few ways to implement it. First, we began with a side mount, and it was alright for the angle, but we switched our autonomous plan to begin pointing forward, presenting me with a new problem. The part we had used before would simply not work. We tried a modified version of the pusher we'd made, but it didn't fully suffice. It was impractical and would require more than a little wire extention for the servo. We finally decided that a frontwards approach should be taken from the side. Instead of a single middle forward facing prong, a two bar prong sticking from either side, meeting in the middle, and providing a platform for a potential relic placer. While not completely finished, we intend to have it done by the first qualifier, fully functional. It should allow us to knock the jewel off during autonomous effectively and efficiently, although that’s all to be seen.

    Gripper Part 2

    Gripper Part 2 By Evan

    Update:

    The task today was simple. We replicated the prior work with the first gripper, as stated in the prior post, so we can begin connecting them. The biggest problem was finding all the parts to make it. We are hoping we can connect and mount them in the next couple days so it will be ready for the qualifier in Oklahoma. The improvement over last post was the addition of the rubber gripping material, as found in our "Material Test" post.

    Drive Practice

    Drive Practice By Karina, Charlotte, and Abhi

    Task: Become experts at driving the robot and scoring glyphs

    Iron Reign’s robot drivers Abhi, Charlotte, and I, have been working hard to decrease our team’s glyph-scoring time. The past few meets, we have spent many hours practicing maneuvering on the field and around blocks, something that is crucial if we want to go far this competition season. When we first started driving the robot, we took approximately 4 minutes to complete a single column of the cryptobox, but now we can fill one and a half columns in two minutes.

    When we first started practicing, we had trouble aligning with the glyphs to grab them. The fact that were using our prototype arms was partially at fault for our inability to move fast and efficiently. We also had some human error to blame. Personally, it was difficult for me to not confuse my orientation with the robot's orientation. In addition, our drive team had yet to establish a communication system between the driver and the coach, so the driver had no guidance as to which glyphs seemed like the easiest to go for or whether or not the robot was in position to grab a glyph. Below is a video that shows our shaky beginning:

    Our driving has improved significantly. We have done mock teleop runs, timed ourselves on how long we take to complete different tasks, and have repeatedly tried stacking blocks and parking on the balancing stone. When our robot doesn't break, we can fill up to two columns of the cryptobox!

    Reflections

    Overall, we feel that we can further improve our driving skills with more drive practice. Driving the robot really does require being familiar with your robot and its quirks, as well as the controls to move the robot. Abhi, Charlotte, and I know we are still far from being driving experts, but we are putting forth our time and effort so that we can give it our best at tournaments.

    How to Assemble parts in PTC Creo

    How to Assemble parts in PTC Creo By Abhi

    Task: Learn how to Assemble parts in Creo Parametric

    In addition to making parts to print in Creo, it is sometimes useful to combine multiple parts to make a model. For example, we can make a robot model by assembling parts in Creo. We have conducted a video on how to do so.

    For this tutorial, we first created two simple parts which fit snugly inside one another (done before the video). Then, we created a new assembly file and uploaded the bigger part first. We placed the smaller part and did the assembly by matching the sides of the cylinder. That is how we ended up with a cylinder with its hole plugged in the end.

    Reflections

    We hope to use Assemblies to make models for various structures in our robot in the near future. We hope this tutorial helps you with your endeavors!

    Intake Grippers Pt2

    Intake Grippers Pt2 By Evan

    Task: Attach the new intake grippers

    The basters are here and in full swing. We spent a late night putting together the two intake columns. They were attached to a backing by previously, allowing to finish it by attaching the final servo and tieing it to the two columns. Since the new intake needed new code, we whipped up some code to allow us to have control. Upon doing this he realized we needed two controllers, one for movement and controlling the lift, and a second purely to work the two columns as they spun. This allowed the operator to operate the whole robot just a little easier. The new columns are set on a majority REV base, allowing for more choices in design that normal tetrix doesn’t provide. The new grabber has already been placed on the robot and seems to be working smoothly, only time will tell if it is a long term solution.

    Grabber Arms v3

    Grabber Arms v3 By Abhi and Karina

    Task:Develop a More Efficient System

    At the Oklahoma qualifier, we saw numerous teams with similar systems to that of ours. However, since we had the mobilized gripper arms to stack with auto alignment, we were able to collect glyphs easier. In spite of that, after observing other teams in action, we realized our current gripper method had the issue of not being ready by the time we got back to the cryptobox. This is because we had to turn around everytime we needed to pick up glyphs and we also needed to pick up glyphs. This leads to longer time to fill the cryptobox, something that is not good if we plan on recovering the relic later in the season. As a result, we decided to upgrade our arms to a new level: a chain based intake system.

    The idea behind this system is that the grabber arms would be on a mobilized chain system, kind of like a conveyor belt. One of the reasons this is much faster than our old system is that we don't need to turn our robot around as we approach the cryptobox. We can drive forward, pick up glyphs, and as we drive backwards, we can use a toggled button on our gamepad to move the grabber arms to the back of the robot upright. As a result, by the time we get back to the cryptobox, we have the glyphs ready to place.

    Another benefit of this new system is that we don't need to stack glyphs. When we drive forward to pick up glyphs, we can tilt the grabber arms forward so that even if the pre stacked glyphs look far apart, they can still be in-took with the tilted system. Also, this system can be used for intaking the relic in the future. If the chain system is placed on an elevated level on our robot, the grabber arms will be taller than the field walls. Because of this, if we pick up the relic when it is on the ground, we can place it easily.

    This picture represents our current progress. We hope to complete this system soon so we can test it on the robot.

    Gripper v4, Octopuckers

    Gripper v4, Octopuckers By Tycho and Abhi

    Task: Design a new piece for intake

    Version 2 of our gripper arms worked much better than our original. Due to their silicone material and trianglular shape, we definitely had more control over the glyphs than our one degree of freedom grabber arms. However, we still had issues we needed to address. When glyphs were taken in, since the silicone surface did not have much mobility and compressibility, glyphs would often fall. Due to slight changes in glyph size, the bigger glyph would determine the space between the grabbers, meaning the other glyph would be mobile despite us wanting its control. This is when we develoepd the first version of our new rotators.

    The first edition of our rotatory mechanism allowed us to play with ninjaflex printing and flexibility. They were 15mm extrusions designed to stack on one another on a REV rail or similar rigid structure. Since Ninjaflex can bend, we got more grip on the glyphs. It was definetely a well designed model but had many issues. First, each fin of the fan was very thick. Though it was able to grip glyphs well alone, the system was not able to grip much better when stacked together. We decided we needed more surface area contact with glyphs during intake.

    This led us to create a new model with thinner fins and thin tabs at the end. The thin flaps allowed more grip area with the glyphs allowing us to work better. Though good in theory, when we went to print out the part, we discovered our 3-D printer didn't allow printing vertically of surfaces less than 1 mm. Since this idea didn't work, we started thinking of the idea of suction cups. This led us to our current design.

    The design worked very well. We decided to name them Octopuckers since they had suction cup shape and there were 8 fins to a pucker. The surfaces of the octopuckers which would contact the glyphs were large and had a large area. Since this was heavier than the bridge connecting them to the center, the branches bent easily allowing for a grippy surface which was also flexible. After testing it on a small scale, it seemed to work well so we will continue development and implement it on our next edition of the grabber arms.

    Jewel Thief

    Jewel Thief By Austin and Evan

    Task: Build a Functional Jewel Thief

    The jewel thief we built before *worked* but that was about it. More often than not, it failed or, even worse, knocking off the wrong jewel due to instability. And, in the Greenhill Qualifier, we lost several rounds because of a problem that could've been easily fixed. So, we had to redesign it.

    The jewel thief was initially intended to be simple. It was comprised of no more than a 180 degree rotation servo and an arm with a standard rev color sensor. The arm was foldable and collapsible so that it would fit inside our robot, and as the servo turned out to its extended position the arm would open up with the help of a single bungee cord.

    This plan had a few inital downfalls: first, the arms were rather large, clunky, and never really folded well into position, second the arms was heavy due to the use of tetrix bars meaning that the servo would strain, and finally the overal position of the arm was inconvenient for our autonomous programing, so we moved on completely. Rather than focusing on a single arm that could extend to reach the jewels, we decided to focus on something that would conform well to our current setup and then focus on making it long enough to reach. We realized that the outer edge of the robot was open enough to contain a V-shaped device that would rise 180 degrees over the head of our robot. The immediate perk to this was the fact that the system would be 18 inches in length. We felt no need to update which sensor we were using at the end of whatever mechanisim we finally attached, since the rev color sensor served it purpose correctly and effectively each time we had tested it in the past. Our final design was the V-shaped rim that laid flush with our robots exterior and was made from cut and bent L-bracket and was moved with two continuous rotation servos.

    Flipper Prototype

    Flipper Prototype By Evan

    Task: Build an alternate glyph-placing mechanism

    The world advances on innovation. We strive to make the most efficient devices and aparati to complete jobs for us. There’s a hundred different ways to work a task, but only one will be the best at functioning in the areas of efficiency and timeliness. Just as America runs on Dunkin, advancement runs on efficiency. That’s why the robot must be outfitted with a flipper system to intake and deposit blocks. It’s the only design that will make it to the world competition, and it’s the only way that we will make it out of local competitions. I personally have taken it upon myself to develop the prototype while the majority of the team is focussed on a new grabber arm.

    While our grabber arms were *good*, they weren't great. The arms currently attached to the robot, which use the turkey-pans, didn't grip as much as we hoped, and while we're designing a new version which has specialized 3-D printed arms, we can't put all our eggs in one basket. So, we decided to make the flipper system. The advantages of the flipper system as compared to the other systems is that the flipper system:

    • Does not depend on friction to hold blocks
    • We had previous issues with block slippage with the arms model, and this should fix our dependency on high-friction materials.
    • Faster
    • Our old arms depended on stacking to get more than one block, while this one wheels blocks in, reducing the time needed.
    • Less precision needed
    • Before, we had to align blocks directly with the arms to pick them up, but this can just use the wheels to intake blocks.

    So far I have built a flipper and an intake system, both that function well, but have yet to get the teams’ permission to attach it directly to the robot, as it would require a lot of dismantling. Since it won’t be able to be put on before the upcoming Wylie qualifier, it’s been put on a backburner as I also throw myself at the new grabber arm. The flipper is being held in a frame I built around it but as a system is comprised of a board attached to a servo attached to a drawer slide that works as a vertical lift. The intake system is composed of two intake wheels made of the same foam tiles that make up the field floor attached to two axles that are chained to two opposite rotating gears powered by one of the new REV motors. The intake works with the flipper well and only needs some side guards. I’m half of the way through designing. It should be on the robot before any regional qualifiers we go to.

    Fixing the Robot Chassis

    Fixing the Robot Chassis By Austin

    Task: Redesign the robot chassis, fix issues

    When we designed our new grabber with the octopuckers, one of the variables we neglected was the width of the new grabber once assembled and resting. After the grabber was completed it’s width was actually greater than that of the housing bay we had built into the current drive train, so to get the grabber to fit we actually had to widen the bay. We had know from past experience that the base was never truly square, so we took this necessary widing as a chance to resquare the base and drastically improve the efficiency of our mecanum drive. We added ¾ inch to the inside base and the resquared the frame before finally bolting everything down and attempting to mount the new grabber. Because the closed grabber barely fit within the new widened bay we had to cut away portions of the frame over the front wheels to allow the octopuckers room to actuate.

    The other key chassis modification needed to accommodate the new grabber system was a lift bolstering. We decided that to handle the newly doubled weight of the grabber we would share the load across two strings and convert to a double pulley system. The lift was also strengthened with newly squared and adjusted cross beams similar in length and angle to the other iteration. Because of the double pulley, we also centered the drive motor and utilized a second spool. The pulleys rest on either side of the lift system and are both being run by the same motor.

    The Grabber V. Kraken

    The Grabber V. Kraken By Austin and Evan

    Task: Build a new version of the grabber

    One of our issues with the previous iteration of the gripper was the fact that the material that coated the actual pincers weren't even and would often lead to blocks slipping from the bottom of the gripper and falling out. Our solution to this was to retest materials and in this process we decided to try our hand at 3D printing a circular and pliable material that could be part of our new rotating pincers. We designed the OCTOPUCKERS and built the rest of the grabber around that. Because the octopuckers were designed to slide onto typical rev-rail extrusions we also had to design a new system of bearings that could house the rails with skewered octopuckers.

    We developed a “revolutionary” new 3D printed rev-rail bearing system that was liked with a series of chains and pulleys that could be attached to our current lift system and not severely alter the base and drive train. Previously the grabber was actuated via a system of servos controlled by a rev hub back on the main drive train, however in this newer iteration of the grabber, we decided that all of the necessary wiring would be kept inside the grabber to eliminate tangling by mounting the rev hub on the back of the grabber. While this grabber was a major upgrade that drastically improved our glyph handling capabilities, it did in fact double the weight that our lift had to bear.

    Creo Parametric, a Learning Journey

    Creo Parametric, a Learning Journey By Abhi

    Task: Learn Creo Over Time

    Over the course of this past season, I have been learning how to use Creo Parametric to learn 3-D modeling. Since this is Tycho's last year on the team (so far he has been our main modeler), I decided to learn from him so the modeling legacy would continue.

    The first project I was tasked to design was the wheel guard on the robot. As a very early learner, I ran into many issues. For example, I used to eyeball all my dimensions. This clearly didn't work out as evidenced by my epic fail of the first form wheel guard. However, after experimenting with the constriants, I jumped all the early hurdles and learned the basics.

    My first assembly project was to CAD the conveyor belt we hope to eventually mount the grippers onto. As someone who had never dealt with assemblies before, I felt like someone going through a maze. Even assembling basic parts like an axle hub to the axle, it took me 10 minutes because I struggled changing dimensions and such. This project, though very basic, seemed impossible to me. However, after working through it, I was able to become more familiar with constraints to apply to the next biggest task, the robot model.

    So far this is what we have constructed of the robot chassis. After training on the conveyor system, I was able to complete the chassis easier. By doing this, I have dealt with more constraints and have been moving faster.

    Next Steps

    After learning a lot so far from Tycho, I hope to finish the model soon and continue growth on the model. The only thing remaining on the model is the vertical bars connecting the lift and the lift itself.

    Flipper+

    Flipper+ By Evan, Abhi, and Janavi

    Task: Build a new glyph scoring system

    As the season wears on, the robot game looms over Iron Reign since the bot we built scores only a fifth of the world record. To lessen the gap, we continue to invest in the flipper system I contrived earlier on in the season. As of late, we’ve furthered the project by building a chassis for it to rest in. It’s a slightly modified version of the one on the current robot because we want to still keep the lovely mecanum wheel drive for that extra mobility. We’ve had one major hiccup that has slowed progress which is that the spare set of mecanum wheels we have are all too thick. It turns out there’s about a centimeter of extra wheel depthwise, and this has made us have to try and refit the chassis to accommodate the discrepancy. We're going to rearrange the frame to fit the wheels.

    The first thing we did when trying to design the new chassis to go around the flipper system was to arrange the different components of the flipper onto the base where they would go in the future. We were able to secure the intake system I designed a while back to the part where it would suck up the blocks. Then we started to rearrange the supports that are used to keep the robot base square to different places around the robot where they wouldn’t interfere with the flipper and instead utilize the space that would be under the flipper board.

    To give the required room the flipper needs, we’ll have to rig the motors upward, so they won’t take up space in the center of the robot. Doing this will require gearing it in a one to one ratio, then allowing those to be connected to other gears what are then chained to the larger mecanum wheels. This is a necessary part of the design because there’s not many other places we can put the motors that won’t collide with another function of the robot. Since the last competition, I’ve been assisted by numerous members such as Ahbi and Janavi in the quest for a high performing robot, and it wouldn’t be as far as it is without them. The flipper has potential, and we're going to push it towards its full.

    Building a new chassis

    Building a new chassis By Karina and Janavi

    Task:

    Janavi and I have started to build a new chassis for Kraken 2.0., modelled after Kraken’s current chassis.

    First, we had to measure the chassis of Kraken, then cut REV rails to these measurements. Lastly, we assembled the pieces to look as it does above.

    With this being the first build project Janavi and I have taken the lead on, we had to have some help from the more experienced builders on our team: Evan and Austin. The most difficult task we came across was having to figure out at which angle to cut the REV rails to fit diagonally on the main frame of our new chassis. After we found this measurement, it was easy cutting the pieces using the miter saw and safety equipment and then we assemble all the REV rails with handy-dandy brackets.

    Our current plan is to use this chassis as a base for our fifth generation grabber system. Going forward, we have to figure out how we are going to mount our conveyor belt onto our chassis, and then how to mount grabber arms onto the conveyor belt. We also have a new set of mecanum wheels which we are going to attach to the chassis. However, it came to our attention that they are thicker, so we will have to adjust the rails that run parallel to one another so that the wheels can fit in between.

    Normally during the season the build team, the programming team and the drive team all need the robot and this can be difficult. Often times this can hinder our performance since the drive team doesn't get the practice it needs. Therefore the team decided to build a new chassis because having a second base will enable us to dedicate more time to drive practice with Kraken while simultaneously testing out new designs on what will be our second robot. Additionally, having two robots will allow to choose which robot we will take to competition based on performance.

    Conveyor Belt V2

    Conveyor Belt V2 By Abhi

    Task: Develop Conveyor System 2

    After analyzing the lack of speed from our last competition, we decided to continue the journey of attaching the gripper arms to a conveyor belt as previously designed. To do so, we realized that we needed to utilize the REVolution system to make the grippers work better. Also, we needed two points of attachment for our robot after seeing that one didn't work with the first version of the conveyor. To figure out how to do all this, we went to our best tool: Creo Parametric.

    The assembly began with an assembly of two REV rails through distance and coincident constraints. To this, we mounted two bearing holders with bearings inside on either side of the bars. Inside, the plugs holding the REV rails were attached with coincident constraints. This combined assembly was added to the final assembly and was set with a default constraint. To the inside of the plugs, REV rails were attached using coincident constraints. Next, a copy of the bearing assembly was added and attached to the REV rails attached to bearings.

    For the next part of the assembly, we had to make a couple of subassemblies. First, we attached a Sprocket hub that we custom designed for the REVolution system and attached it to a 35 Sprocket from Andymark. The other end was plugged into another hub. This sub-assembly was replicated 4 times so that it could fit on all of the conveyor belt pieces. Also, we had to make a similar subassembly for the 25 sprockets since those are what our motors were designed to do.

    Finally, we mounted two motors on the insides of the REV rails. The sprocket attached to this motor would connect to the REV rails so that the whole system could actuate. This was constrained using coincidence.

    Next steps...

    We really liked how this model turned out. By starting to build it based on the model, we realized how useful Creo is to our design process. We hope to use it again soon for determining how to mount the grabber arms to the belt system.

    Robot Drive Team

    Robot Drive Team By Charlotte, Tycho, Karina, and Evan

    Task: Build a solid drive team.

    One of the leading problems Iron Reign faces is our ability to allot time to effective driving practice. Driving practice is essential for our success in the robot game, but it is sometimes difficult to find time to practice due to other team members working on various robot improvements. We have created two different drive teams, a main team and a backup team, so that despite who is available at meeting we can always have some kind of drive practice going on. The bulk of the time spent in driving practice is spent practicing putting glyphs in the cryptobox, trying to better our previous time and complete as many columns as we can. We focus on performing and scoring timed runs, and sometimes when our sister team 3734 is available, we scrimmage our robots against each other. Another smaller, yet equally essential, part of drive practice is setting up the robot in the correct orientation for every situation and running our autonomous. It is important that we make all of our mistakes during practice, so that when it is time to compete we run autonomous perfectly every time. The main challenges we face in driving practice is consistency in filling the cryptobox, adjusting to significant robot design changes, and our time management (actually finding the time to get in good practice).

    In the future, the drive team is going to meet more often and hold more efficient practices. Our main goal is to significantly decrease the time that it takes to fill the cryptobox, and to accomplish this we will need to clock in many hours so that we are very comfortable in driving the robot. Ideally, any error that might occur during competition will be mechanical errors that are out of the drivers' control. We have improved a lot, but we still have a long way to go.

    Last Minute Robot Fixes

    Last Minute Robot Fixes By Ethan and Evan

    Task: Add last-minute design changes to the robot

    It was a temperate night. The waning moon shone overhead, a blazing reminder of the continuity of time, for as the moon dipped lower in the sky, our precious little time until the tournament dripped away. Under this oppressive, singular symbol, we labored, trying to outpace the continual march of time.

    Over the past week, we had worked tirelessly on the robot. In Wylie, we had used the Octopucker Gripper System, but it didn't perform to our expectations, as the internal lift didn't work. However, in this week, we fixed that issue, and designed the Gripper 4.5, which can be found here. Now, all that was left was to actually attach this new gripper.

    At 9PM, things were already going downhill. Apparently, "people have to sleep" or "the team should be well rested for the tournament", so we watched our members drip out the door, one by one, until only us two were left. The task still remained - attach the gripper to the robot. From the get-go, we experienced problems, most prominently that since we had extended the height of our grabber, our phone now stuck out of the 18x18x18 sizing box. Now, we as a team already have significant experience just *barely* passing the sizing cube requirements - before this, our robot was 17.5x17.96875x17, in width, length, and height respectively - so we had certain tricks to get our robot just under it. However, this time, our phone stuck a solid inch outside of the cube, so there was no reconfiguration with the parts attached to the grabber at the time that would allow us to fix this.

    So, with traditional Iron Reign ingenuity,we had to devise a solution to our problem. In the words of of the legendary Lil Darsh', "First you gotta analyze\see the problem\conceptualize so you can solve 'em". And, we must follow in the words of our elders, as all good robotics members do. So, we devised these ways to fix our phone problem:

    • Position the phone under the grabber system
    • No, vision was hampered too much in this position.
    • Position the phone on another side of the robot
    • No, this autonomous would be too slow, as the robot would have to turn to locate blocks
    • Attach the phone to a servo, which then moves off the grabber after autonomous
    • This may have been the dumbest and the most difficult solution, but it was the best for our robot
    So, we set out to create a moveable phone-mounting system. First, we designed the servo.

    The next issue was attaching it. We had to find a position that could view the blocks, pattern, and cryptobox from the same angle. We ended up positioning the phone right in the middle of the grabber, about here.

    Next Steps:

    In our postmortem, we will talk about the issues caused by these last-minute changes.

    Grabber V5. Diagrams and Pictures

    Grabber V5. Diagrams and Pictures By Austin

    Task: Implement the new grabber system and record how it works

    So, we've been talking about our new gripper system for a while - we've made prior 3D models and started it, hoping that we'd have it done by the Oklahoma Regional, since that was sort of a low stakes tournament for us. Unfortunately, we didn't get it just in time, so we had to go back to the basic Kraken model of our robot. We really don't want to repeat this mistake again, so we're doing a last-minute drive towards adding V5 to the robot.

    First we had to build a new base, in case we had to suddenly revert back to the old bot. We've detailed that in the Building a Chassis post. Next, we had to make the design. We wanted something with more versatility than the static up-down gripper system, and looked at the flipper that our sister team had designed for inspiration. However, we didn't want to give up the whole design process that we'd used for the gripper. We decided on a comprimise, a gripper-flipper system that would intake blocks on either side of the robot, but then had the capability to flip over the entire robot and deposit blocks.

    First, we made a model in Creo to see how we would get the gripper to be mobile over the entireity of the robot. This system continued to use the REVolution system that we'd previously designed. Described, the design was a gripepr system hooked to two chains which in turn moved the gripper system from one side to another. The default configuration is to let the gripper rest on top of the rotation system in order to relive stress on the chains.

    Next Steps:

    Next, we need to hook all of this up onto the robot and test them - we don't have much time, so we've got to act fast.

    Relic Arm Design

    Relic Arm Design By Ethan, Abhi, and Shaggy

    Task: Design and implement a new Relic Arm mechanism

    At the North Texas regionals, we realized that if we really want to go further in the robot game, we need to significantly improve. Part of this is designing the new grabber-flipper system detailed in a later post, but another good way to score points is to score the Relic. So, we designed v1 of the Relic Arms, as detailed in this post.

    However, designing a model and designing a real-life part are much different. First, we didn't have the Tetrix piece needed for a backing plate, and it is easier to say you can attach unrelated materials than actually doing it. As well, having a single 18-inch deploying arm would test the size limits more than we already do.

    In comes Relic Arm V.2. This version is twice as long as the previous version so that we can score in the third zone for 40 points. As well, we have an updated relic-grabber that uses the silicone sheet from our Grabber V.2, so we can grip the relic more securely. Finally, we have a new mounting point on the robot that allows us to extend even farther than before.

    Next Steps:

    We now need to build and attach this design before Supers, in less than a week.

    Kraken LED Installation

    Kraken LED Installation By Ethan, Austin, Evan, and Abhi

    Task: Install LEDs on our robot

    This has been a low-priority task for the robot throughout the season. We wanted to be able to a) look cool and b) signal team color and problems with the robot with LEDs. And, at Supers, we just happened to have access to a Fender switch, servo, and a roll of LEDs, so in our downtime we decided to take advantage of it. If we knew we weren't going to win, we could at least make our robot look cool.

    The installation was relatively simple. We attached a servo to a Fender switch so that we could automatically toggle between colors, and rewired our servos to accomidate that. We threaded the LEDs above the wheels so that we could have a nice backlit effect on our robot.

    Next Steps:

    Next, we need to code the appropriate signalling for the colors and the servo to move the switch.

    Engineering the Flag Holder

    Engineering the Flag Holder By Abhi

    Task: Find a place to put the flag

    When we went to Super Regionals, we forgot about where to put our flag with the new design. That led us to strapping a zip tie to a side shield, ruining the aluminum aesthetic. We decided we need a specially designed part to put our flag in since duct tape didn't look nice (we're classy like that). I embarked on a mission to create a 3-D printed part for it. That led to the part you see above, which has worked very well. It didn't always look that nice though. The part endured a very special process, one that Iron Reign has used for years and has carried us through the hard times. If you guessed the engineering process, you are correct.

    This was the first iteration of the flag holder. The reason it looks so circular was that it was originally going to stick into the Relic arm so that when it extended, the flag would go with it. I built it around those specifications. However, when I went to print it, I realized that there was no good way to print it without supports (nylon doesn't clean very easily for big supports). I also saw that the holder wasn't modular enough to encompass different flags and had to be mounted only one way. I threw this design in the trash and started over.

    Inspired by REV's pillow blocks, I decided to make something similar to that. I wanted the part to be able to mount in different ways in case if robot design modifications were required. That led me to the the design above. It worked much better than the previous design. However, the holes for the flag weren't big enough to fit even a pencil. This is a problem because we don't know how flags will be at worlds. I went back into Creo to make a new design.

    As many other people have said, third time is the charm. After enlarging the flag circles and making overall dimension modifications to fit this change, the holder ended up accomplishing both tasks I need it to do. It was big enough to fit a pin with some wiggle room and actually held the flag as seen the first picture. We will use this at worlds and possibly hand them out to teams like us at Supers who are using zip-tie holders.

    The Cost of Mistakes

    The Cost of Mistakes By Abhi

    Task: Analyze Failures

    Two words describe the picture above: "Oh dear". The wires shown above are connected to our jewel thief on the bottom of our robot. The reason the wires are so shredded and torn is because the chain on our grippers would rub against the wires when the lift was in the lower position. However, it was not always like this.

    This piece used to be on the robot prior to stripping. It's purpose was to protect the wires from damage of grippers. However, at SSR, I decided to take the piece off temporarily because it halted the gripper too short from the optimal intake position. Ignorance led to this piece becoming forgotten about and left in a random box. Since then, the robot had experienced many issues.

    The first and most evident effect was the wires being stripped. This created a safety hazard and made the robot dangerous to others on the field. In addition, this cutting led to the color sensor becoming unresponsive many times, taking away valuable time from autonomous testing. Another issue was that the wires shorted out our batteries, leading to destruction of valuable batteries. This is shown below.

    From this, we lost over 4 hours of driver practice since we would constantly be waiting for batteries to charge (unaware of the issue at this time). As a result of losing one piece of the robot, we lost many things in the process. To fix this, we had to: order new sensor cables, use a new color sensor, rewire the robot, use new batteries, and reassemble the jewel thief.

    It took me about 3 hours just to remove the jewel thief and reassemble it to get it ready for rewiring. After this, someone who was better at electrical had to rewire the robot. In the end, the fix took close to 7 hours.

    Aside from physical build, I also made a mistake on the software side. Being a novice at Github, I managed to create a collection of merge issues for our game repository. As a result, Tycho had to take about 2 hours to fix all merge conflicts and make the robot functional again. This again led to loss of driver practice-something we are very bad at.

    Though I have made many failures recently, this post is also about the team as a whole. As a team, we have not been the best at organization. For example, after returning from Georgia, we left the poles for our tent in the middle of the backyard. Though we were very tired, we should have put the poles in a safe location. Since we neglected them, we now have to wash them because of rain damage in the following days. Another issue we have is phone and battery management. It is always exciting to be on the practice field driving around but we seem to forget about the most important thing: charging. After some driver practice, we seem to just leave the phone and used batteries on the field and go home. Therefore, we lose valuable time to charging, time that could be used for driver practice or autonomous testing. Finally, we are terrible at putting things back where they belong. If you look at our practice space currently, you cannot see one clean spot as it is either occupied with another chassis, some rev rails, or nuts/bolts. Spreading all these items around leads to not only decreased efficiency as we spend infinite amount of time looking for parts, but also an unappealing place to live for our coach and his family.

    I have reflected on my failures and am working hard to make sure I don't make similar mistakes in the future. It is also time for the rest of the team to reflect on our negligence. After analyzing our weak points, we are slowly working towards fixing the mistakes. As an example, Kenna was able to clean up our table so we could finally see the wood underneath. Our team is now at the Championship level and we shouldn't make these mistakes simply due to laziness. As we continue on our journey it is important for us to grow from our failures and avoid them to reach maximum efficiency.

    Elastics Testing

    Elastics Testing By Ethan

    Task: Test wear and tear on our robot's bungees

    This is the fifth or so article in our series on robotics testing. Today's spotlight will be on the constants of our robot's bungees, and how they're affected by various wear and tear. So, we took three bungees from the same set as the ones on our robot, and placed them in various places: stretched outside, stretched inside, and a control sitting in the robot room. The purpose of this is to see whether or not our bungees merit periodic replacements.

    Procedure

    1. Cut three identical elastics
    2. Leaving one unstretched inside, place the other two stretched inside and outside
    3. Attach your chosen bungee to a 10 lb weight
    4. Positioning your hand 8 cm from the knot, pull upwards, recording this inital position as xi
    5. When the weight barely moves off of the ground, measure the knot-hand distance and record it as xf
    6. Using these values, calculate the elasticity constant for each bungee

    Data

    Run x-initial (m) x-final (m) Δx (m)
    Normal .08 m .151 m .071 m
    Inside .08 m .155 m .075 m
    Outside .08 m .162 m .082 m

    Calculations

    W = 10 lbs = 44.482 N
    x1 = .071 m, x2 = .075 m, x3 = .082 m
    ΣF = Fsp - W = 0
    Fsp = W
    kx = W
    k = W/x
    k = 44.482/x
    k1 = 626.51 N/m, k2 = 593.09 N/m, k3 = 542.46 N/m

    Calulated Data

    Run Elastic Constant (N/m)
    Normal 626.51 N/m
    Inside 593.09 N/m
    Outside 542.46 N/m

    Analysis

    Assuming a standard deviation of 5%, we can perform a one-sample t-test to see if our results are statistically significant. We will test the inside/outside values against the contol.
    Mean = 626.51 N/m
    SD = 31.32
    N = 3
    α = .05
    Ho: There is no significant difference between the unstretched band's elasticity and the stretched bands inside or outside Ha: There is a significant difference between either the band left unstretched and the bands left stretched inside or outside

    For the elastic left inside, we found a p=.2058. For those not accustomed to statistics, this means that there is a ~20% chance that our results come from chance. This is too high of a probability to say whether or not to say that staying inside affects the elasticity of a band.

    For the elastic left outside, we found a probability p=.0433. This means that there is a 4.33% probability that these results come from chance. For most journals, the minimum p-value, or α, is .05 = 5%. Thus, we can safely say that elastics left outside can be damaged and will not work on the same level as the untouched bands.

    Conclusion

    Given that we only found a statistically significant result for the band left outside, we cannot safely conclude much. That being said, these results suggest that we should replace bands before Worlds, as we leave our robot outside, but covered. As well, even with a 20% probability that there isn't a difference for the inside bands, it is still uncomfortable to say that there is absolutely no correlation. For these reasons, we suggest regular switching of the elastics on the robot.

    Build Kraken 2

    Build Kraken 2 By Janavi and Kenna

    Task: Build a Pushbot (Kraken 2)

    Building. It seems so simple but alas I was wrong, so wrong. During our post mortem, when we discussed our roles on the road to worlds, Kenna and I volunteered for building a pushbot. We both wanted to get more experience in building and thought this would be a perfect way to becoming well-versed in building. Our task was to create a drive base that, when placed on the field, would emulate a real robot on the field allowing our drivers to get more realistic practice. Our design for the pushbot imitates an earlier version of Kraken, just with side shields.

    1. To cut the pieces for the drivetrain, we needed to get trained for using the miter saw. Austin showed us and Abhi how to properly use one.
    2. After cutting the tetrix pieces, we followed an earlier design to create a square upon which we attached the wheels.
    3. We printed 3D custom motor mounts to mount the motor on. Often times the real motor mounts are very expensive, so we decided to used a CAD model. Now unbeknownst to both of us, we attached these lovely lads backwards. We did not realize our mistake until all motors and chains were already on the robot.
    4. The next step was to find the lazer cut side shields, which work as our wheel mounts. On our last robot we created custom 3D mounts for the mecanum wheels but these proved to be large, bulky, and limiting in terms of building space. So this year we designed side-shields that would hold the wheel in place while maximizing the 18 by 18 by 18 space we have. After searching for the shields for about 3 hours, we finally found them and placed them on the robot. Putting the wheels on after that was a breeze.
    5. Kenna and I set out the look for motors, sprockets, and motor collars. Sadly neither of us knew that both axle and motor collars existed and, after searching for so long, we had to go back and begin our search anew for motor collars. Finally, we were able to locate the required supplies and set to attaching the motors to the drive train.
    6. Finally, it was time to put on the chains connecting the wheels and motors. We learned how to find and remove the masterlink, as well as how to put the whole thing back together. For a short period of time, we flew into a panic because we couldn't find the masterlinks we had put aside, but soon we found them and put them onto the robot.

    New Skills Learned:
    • Miter Saw
    • Handheld Drills
    • Chain Assembly
    • Trial and error is key

    Next Steps: Finish and Code Chassis

    Once we put the finishing touches on the chassis physically, we can begin coding it. Expect a new post on how we code it soon! Both of us are relatively new to coding robots so this should be interesting.

    Upgrading Kraken

    Upgrading Kraken By Abhi

    Task: Update CAD model

    With FIRST Champs right around the corner, we needed to update our CAD model to match our current Kraken. After all, Kraken can't be lackin' any features. I decided to reopen Creo and make some modifications.

    One of the most important things I needed to put on was the Relic arm. After planning on it for the whole season, we finally finished it recently. I made a quick CAD model for it in a separate assembly. The servo horn with a custom made circular disk for holding spool was attached via co-incident constraints. The linear slide system was represented with coinciding a set of REV rails to do this job. The elbow joint with actual grabber was done previously in another assembly. Once I finished the Relic arm assembly, I constrained it to the Robot model using coincident and distance constrains. I also made a small modification to the existing Jewel arm to account for the alignment on our actual robot. I used angle offset for this.

    Next Steps:

    Present this model to anyone who is interested in the specifics of our robot!

    Relic Arm

    Relic Arm By Karina and Evan

    Task: To have a working relic arm in time for Worlds

    For weeks now, Team 6832 has been working hard to have a functional relic arm designed and mounted on the robot. We feel that it is absolutely necessary to be able to complete relic recovery at Worlds if we do not want to be crushed by the competition. Well, fear not, our relic arm is here!

    Now, as you probably already know if you have seen our robot, Kraken is big and heavy. There’s not much space left to fit much of anything before different parts of the robot start interfering with each other. There is very little clearance left vertically and from the front to the back of the robot before we exceeded the 18 by 18 inch size limit.

    Due to this, there was a bit of hesitance when it came to mounting the darn thing because it had seemed at first as if we would have to cut our beautiful side shields to be able to fit the relic arm onto the robot. However, we found a way around this.

    First, I will briefly explain the design. There are two major components to the relic arm: the linear slide system and then the final metal bar that the “hand” of the relic arm is mounted on. The linear slide of the relic arm provides most of the extension length to the robot, and is what gets the “hand” across the walls of the field. A servo on the end of the linear slide system extends the final length of the arm, the part which grasps the relic. We felt that having this part at the end of the arm would give us more control when grabbing the relic, and help make it easier to balance the relic in endgame.

    Anyway, because the final extension of the robot attached via a servo, this creates a distance between the two major components of the arm, which allowed us to fit the side shield in between the two. We still had to drill holes in the side shield, sadly, but this was much better than the alternative. We did not mount the arm directly by the slide system, of course. Instead, we attached another REV rail to the bottom of the slide system using double brackets, which created extra space for the side shield to fit in between the two components of the arm. Also, surprisingly enough, when we tested the grabber system, we found that despite the tight fit, the relic arm did not get in its way of the octopuckers when flipping upward or downward.

    Where will we go from here?

    Just because we finally have a relic arm does not mean we are done working on it. From now until Worlds, we will continue improving our relic recovery and tweaking the design of the arm along the way. We will have to fit time in for completing the challenge, but we have faith in our drive team!

    REVolution on Thingiverse

    REVolution on Thingiverse By Abhi

    Task: Publish REVolution Parts

    Tired of slipping set screws? Want a rigid drive shaft as long or tall as your robot? Have a bunch of REV Rail lying around? Have we got a solution for you...

    Turn your REV Rail into a beater-bar, a drive shaft or a heavy duty hinge with our Spintastic Axializer System … The REVolution System

    Iron reign has developed these parts over the course of this season and they have served as essential pieces of our robot. Now you don't have to worry about snapping axles and those darn set screws. Choose your attachment plate, your internal pieces, and assemble them together! With this system, you robot can be efficient and flashy.

    The parts are avaliable at

    https://www.thingiverse.com/thing:2859442

    If you need help with part assembly or printing, please contact us and we will be glad to help. Tutorial videos are in the process of being made. Details about the parts are listed below

    REV Rail Deformation and Faults of Design

    REV Rail Deformation and Faults of Design By Karina, Austin, and Abhi

    Task: Analyze Source of Gripper break

    As you can see from the video above, the REV rail twisted when the gripper rotated. Due to the high torque caused by intaking glyphs (4.02 Nm), the rails were required to turn very quickly. When we were designing the gripper, we didn't consider the friction among the nylon parts. Before we noticed the rails twisting, we heard squeaking noises (now we know its because of the high friction). The twisting led to the much slower grippers and a twisted frame.

    To fix the issue, we needed to create less friction in the REVolution parts. We don't have enough time to remove the grippers and switch out the parts so we just used Teflon powder to lube the REVolution parts. It wasn't necessary to switch out the REV rail because since the twisting occurred uniformly. After testing the grippers again, the grabber moved properly.

    Next Steps:

    In order to not replicate the same issue, we must switch out the REVolution parts frequently. Even after Championships, we have Texas UIL so we can fix the gripper by then. Next year, we hope to use REVolution for our drive train, so we must be extremely careful with the parts.