Articles by tag: innovate

Articles by tag: innovate

    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.

    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.

    Testing Materials

    Testing Materials By Austin, Evan, and and Tycho

    Task: Test Materials for V2 Gripper

    Though our current gripper is working sufficiently, there are some issues we would like to improve in our second version. The mounting system is unstable and easily comes out of alignment because the rev rail keeps bending. Another issue we've encountered is the cervo pulling the grippers so that they begin to cave inwards, releasing any blocks being held at the bottom. By far the biggest problem is our intake. Our drivers have to align the robot with the block so precisely to be able to stack it that it eats a majority of our game time. However, there are some advantages, such as light weight and adjustability, to this gripper that we would like to carry over into the second version.

      We tested out a few different materials:
    • Silicone Baking Mats - The mats were a very neutral option because they didn't have any huge advantages or disadvantages (other than not adhering well). These could have been used, however, there were other better options.
    • Shelf Liner - It was far too slippery. Also, when thinking about actually making the grippers, there was no good way to put it on the grippers. Using this materials would have been too much work with little gain.
    • Baking Pan Lining (picked) - It was made out of durable rubber but was still very malleable which is a big advantage. We need the grippers to compress and 'grip' the block without causing any damage.
    • Rubber Bands on Wheels - This material was closest to our original version and, unexpectedly, carried over one of the problems. It still requires very specific orientations to pick up blocks, which would defeat the purpose of this entire task.

    The purpose of this is as a part of our future grabber design, which will need to be relatively light, as our string is currently breaking under stress due to weight. The material must also have good direct shear and direct strength, as the grabber will have rotating arms that move in and out to grasp blocks. As well, we're replacing the tetrix parts with REV, as they're smaller and a little lighter, with the additional bonus of more mounting points.

    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.

    V2 Hexifier and Parts

    V2 Hexifier and Parts By Tycho and Abhi

    Task: Creating the Parts for V2

    Today we continued our work on the second grippers. We talked about this in another post, but the gist is that we iterated through various materials to find something that would securely grip the block, without damaging it. At the beginning, that got rid of most of our options, but we tested various sprays, materials, and pressures to find the right material. The baking pan liner was the best, as it had some give without damaging the block, but had enough friction that slippage was a minor issue. So, we needed the baking pan liner to adhere to the large square dowel we chose to be the base for our grippers. In order to do this, we had to design and print a hexifier, as seen below, which makes the dowel's square shape into a hexagon. We also designed and printed square pieces to go on the top and bottom of the gripper to keep it in place.

    Reflections

    The new grippers are probably going to be much heavier than our previous ones. Not only because of the difference in material, but in sheer size. We may not be able to retain the lightness in V2 that we had hoped to.
    We used PTC Creo for all of these parts. Abhi has some video tutorials on using Creo that can be found here and here. Soon we will start assembling our V2 grippers.

    Machine Vision Goals – Part 1

    Machine Vision Goals – Part 1 By Tycho

    We’ve been using machine vision for a couple of years now and have a plan to use it in Relic Rescue for a number of things. I mostly haven’t gotten to it because college application deadlines have a higher priority for me this year. But since we already have experience with color blob tracking in OpenCV and Vuforia tracking, I hope this won’t be too difficult. We have 5 different things we want to try:

    VuMark decode – this is obvious since it gives us a chance to regularly get the glyph crypto bonus. From looking at the code, it seems to be a single line different from the Vuforia tracking code we’ve already got. It’s probably a good idea to signal the completed decode by flashing our lights or something like that. That will make it more obvious to judges and competitors.

    Jewel Identification – most teams seem to be using the REV color sensor on the arm their jewel displacement arm. We’ll probably start out doing that too, but I’d also like to use machine vision to identify the correct jewel. Just because we can. Just looking at the arrangement, we should be able to get both the jewels and the Vuforia target in the same frame at the beginning of autonomous.

    Alignment – it is not legal to extend a part of the robot outside of the 18” dimensions during match setup. So we can’t put the jewel arm out to make sure it is between the jewels. But there is nothing preventing us from using the camera to assist with alignment. We can even draw on the screen where the jewels should appear, like inside the orange box below. This will also help with Jewel ID – we won’t have to hunt for the relevant pixels – we can just compare the average hue of the two regions around the wiffle balls.

    Autonomous Deposition – this is the most ambitious use for machine vision. The dividers on the crypto boxes should make pretty clear color blob regions. If we can find the center points between these regions, we should be able to code and automatically centering glyph depositing behavior.

    Autonomous glyph collection – ok this is actually harder. Teams seem to spend most of their time retrieving glyphs. Most of that time seems to be spent getting the robot and the glyphs square with each other. Our drivers have a lot of trouble with this even though we have a very maneuverable mecanum drive. What if we could create a behavior that would automatically align the robot to a target glyph on approach? With our PID routines we should be able to do this pretty efficiently. The trouble is we need to figure out the glyph orientation by analyzing frames on approach. And it probably means shape analysis – something we’ve never done before. If we get to this, it won’t be until pretty late in the season. Maybe we’ll come up with a better mechanical approach to aligning glyphs with our bot and this won’t be needed.

    Tools for Experimenting

    Machine vision folks tend to think about image analysis as a pipeline that strings together different image processing algorithms in order to understand something about the source image or video feed. These algorithms are often things like convolution filters that isolate different parts of the image. You have to decide which stages to put into a pipeline depending on what that pipeline is meant to detect or decide. To make it easier to experiment, it’s good to use tools that let you create these pipelines and play around with them before you try to hard-code it into your robot.

    I've been using a tool called ImagePlay. http://imageplay.io/ It's open source and based on OpenCV. I used it to create a pipeline that has some potential to help navigation in this year's challenge. Since ImagePlay is open source, once you have a pipeline, you can figure out the calls to it makes to opencv to construct the stages. It's based on the C++ implementation of OpenCV so we’ll have to translate that to java for Android. It has a very nice pipeline editor that supports branching. The downside is that this tool is buggy and doesn't have anywhere near the number of filters and algorithms that RoboRealm supports.

    RoboRealm is what we wanted to use. We’ve been pretty closely connected with the Dallas Personal Robotics Group (DPRG) for years and Carl Ott is a member who has taught a couple of sessions on using RoboRealm to solve the club’s expert line following course. Based on his recommendation we contacted the RoboRealm folks and they gave use a 5 user commercial license. I think that’s valued at $2,500. They seemed happy to support FTC teams.

    RoboRealm is much easier to experiment with and they have great documentation so now have an improved pipeline. It's going to take more work to figure out how to implement that pipeline in OpenCV because it’s not always clear what a particular stage in RoboRealm does at a low level. But this improved pipeline isn’t all that different from the ImagePlay version.

    Candidate Pipeline

    So here is a picture of a red cryptobox sitting against a wall with a bunch of junk in the background. This image ended up upside down, but that doesn’t matter for just experimenting. I wanted a challenging image, because I want to know early if we need to have a clean background for the cryptoboxes. If so, we might need to ask the FTA if we can put an opaque background behind the cryptoboxes:

    Stage 1 – Color Filter – this selects only the reddest pixels

    Stage 2 – GreyScale – Don’t need the color information anymore, this reduces the data size

    Stage 3 – Flood Fill – This simplifies a region by flooding it with the average color of nearby pixels. This is the same thing when you use the posterize effect in photoshop. This also tends to remove some of the background noise.

    Stage 4 – Auto Threshold – Turns the image into a B/W image with no grey values based on a thresholding algorithm that only the RoboRealm folks know.

    Stage 5 – Blob Size – A blob is a set of connected pixels with a similar value. Here we are limiting the output to the 4 largest blobs, because normally there are 4 dividers visible. In this case there is an error. The small blob on the far right is classified as a divider even though it is just some other red thing in the background, because the leftmost column was mostly cut out of the frame and wasn’t lit very well. It ended up being erased by this pipeline.

    Stages 6 & 7 – Moment Statistics – Moments are calculations that can help to classify parts of images. We’ve used Hu Moments since our first work with machine vision on our robot named Argos. They can calculate the center of a blob (center of gravity), its eccentricity, and its area. Here the center of gravity is the little red square at the center of each blob. Now we can calculate the midpoint between each blob to find the center of a column and use that as a navigation target if we can do all this in real-time. We may have to reduce image resolution to speed things up.

    Gripper Construction

    Gripper Construction By Tycho

    Task: Making the Gripper

    Standard parts were used to create the backbone. Then, we bent some tetrix parts to connect the backbone to the servos. We used continuous rotation cervos to solve the issue mentioned earlier. This was a fairly easy build but we still have a ways to go before V2 is completed.

    This gripper will be far superior to our prior designs in that it will be lighter, as we are substituting wood and rubber for metal parts, which will solve our string breakage issue. As well, we will be able to grasp objects more securely, due to the rubber's larger coefficient of friction and that the gripper arms themselves have more surface area than our original design. Finally, our gripper will be more dependable due to slightly better wire organization than before.

    This helps our strategy in that it will be far easier to pick up individual blocks, and helps us achieve our goal of grabbing multiple blocks at once. The wider gripper arms will make it so that we can stack blocks on top of each other before bringing them to the CryptoBox, which makes our robot 1.5x as fast in operating time.

    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.

    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.

    REVolution Pulley

    REVolution Pulley By Tycho

    Task:Build an Army Worthy of Mordor

    This GT2 pulley has rounded teeth that engage nicely. GT2 pulleys and timing belts are the most common in use with 3D printers - but those are usually of the 2mm pitch variety. We didn’t think our printer would be able achieve the fine detail accuracy needed to print at that size, so we went for the 5mm pitch belts. On our printer we can take this part off and use it right away with only the most minimal cleanup. This is a 24 tooth pulley.

    REVolution Simple Dual Rail Plate

    REVolution Simple Dual Rail Plate By Tycho

    Task: Power to the REVolution

    The dual rail plate allows you to couple the rotation of two REVrails together. The distance between the holes should be based on how you are coupling them together. This model is designed to use GT2 5mm pulleys and a 46 gap timing belt.

    REVolution Basic HingePlate

    REVolution Basic HingePlate By Tycho

    Task: Power to the REVolution

    This is our most used hinge plate. The 4 holes can take M3 screws to attach to a REVrail on one side at the end.

    REVolution Narrow Inside Washer

    REVolution Narrow Inside Washer By Tycho

    Task: Power to the REVolution

    This washer is a stackable spacer that can be used to adapt standard bearings/sprockets/pulleys to thinned base plates.

    REVolution Thick HingePlate

    REVolution Thick HingePlate By Tycho

    Task: Power to the REVolution

    This is our most used hinge plate. The 4 holes can take M3 screws to attach to a REVrail on one side at the end.

    REVolution Pillow Block

    REVolution Pillow Block By Tycho

    Task: Power to the REVolution

    This is a standard pillow block. We had to add adhesion pads to the ends because the nylon would curl away from the print bed. But these are easily cut off with a hobby knife.

    REVolution 15x20 Tooth Sprocket

    REVolution 15x20 Tooth Sprocket By Tycho

    Task: Power to the REVolution

    This is our REV0lution 20 tooth sprocket for #25 chain. This took a lot of trial and error to get right, because it was the component most sensitive to our print settings. We had to inset the tooth profile quite a bit because any extra material created by perimeter settings would cause the gaps between teeth to be too small for the chain to fully engage, and because nylon is so slippery, this would radically increase the likelihood of the chain slipping. Or you would have to make the chain super-tight and that would increase the friction at the bearing. It still requires a pretty tight chain. And it requires a lot of post-print cleanup. The lip where the lowest layers spread out on the build plate have to be trimmed with a hobby knife - all the way around. And then the chamfers at the tip of the teeth have to be rebuilt. We used a reciprocating sander to do this. Nylon is one of the hardest materials to sand effectively, but fresh 220 grit paper will eventually do the job. We only need 2 sprockets for our new Glyph System, so it was worth the effort. This would be the first component that we would recommend replacing with a regular flat aluminum sprocket if you have the means to accurately broach a 15mm square hole in it. Or switch over to timing belts entirely - the timing pulley works fine right off the print bed.

    REVolution Rail End Cap

    REVolution Rail End Cap By Tycho

    Task: Power to the REVolution

    End caps are stops placed at the end of a REVrail. Five of the holes are for M3 bolts that can be screwed into the standard holes in the cross section of the extrusion. We highly recommend tapping these holes and then using threadlock to retain the bolts. So far we’ve only had to use a single bolt since we haven’t experienced very large forces The other 4 bolts are for attaching to a bearing on the far side of an attachment plate.

    REVolution Thin Bearing

    REVolution Thin Bearing By Tycho

    Task:Build an Army Worthy of Mordor

    This is the standard bearing / bushing that allows a REVrail to rotate inside a plate. It is typically coupled with a glide washer and two stops to bind it to an attachment plate or pillow block.

    REVolution Rail Stop

    REVolution Rail Stop By Tycho

    Task: Power to the REVolution

    This stop can be placed anywhere on a REVrail to trap mounting plates inside bearings. They are usually used in pairs.

    REVolution Custom Dual Rail Plate

    REVolution Custom Dual Rail Plate By Tycho

    Task: Power to the REVolution

    This shows customized version of the Dual Rail Plate. This is for our 4th generation rolling gripper system. The small ears are designed to hold a long M3 bolt that have a stack of mini ball bearings on them. These ball bearings squeeze our timing belts together, forcing them into a more oval shape, but still allowing them to glide. This reduces friction quite a bit. Otherwise we had to put a lot more tension between the pulleys to get the belt to fully engage. This plate also has grooves to attach servo pulled wires to control the plates angle one of the REVrails and it has a flange to mount our beater guards.

    REVolution Narrow Bearing Washer

    REVolution Narrow Bearing Washer By Tycho

    Task: Power to the REVolution

    Washers can be used as spacers. They are also used to smooth out the rough top layers. Keep the bed very clean and smooth and the bottom surface of parts should be very slippery against other nylon. Put these in between the rough top bearing surface of one part (with rough surface facing rough) and the smooth bottom surface of the next part, and the friction will be substantially reduced.

    REVolution Inside Washer

    REVolution Inside Washer By Tycho

    Task: Power to the REVolution

    This is an inside washer. It will fit entirely inside the standard plate hole. We don’t use these much, but they can be useful as spacers.

    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.

    Introducing Kraken

    Introducing Kraken By Abhi and Tycho

    Task:Design the robot model

    We have finally completed assembly modeling Kraken, Iron Reign's Relic Recovery robot. Named after the sea creature due to the robot's OCTOPUCKERS, Kraken stands as a fierce competitor in FTC.

    To the chassis, we added the glyph system mounting. We first designed a linear slide replica and constrained that to a small TETRIX U connector piece which attached to the REV rail base. On the other side of the linear slide was a TETRIX bar attached by distance and coincident contrains. Onto this, we mounted the grabber system, and assembly done with a combination of normal, distance, and coincident contrains.

    As on our robot, this linear slide system is supported by a small TShaped piece with two aluminum bars. This required tangency constrains with the inside of the T piece along with angle offset to the REV rail base.

    Finally, we attached the jewel thief mechanism via subassembly, We first attached servos to either side of the custom designed pentagon piece. Then, these servos were constrained to the REV rail base and partly to the phone mount bar extruding out.

    All of this went over our amazing chassis design. To see more info on the chassis assembly, refer here

    What's next?

    We hope this chassis provides an alternate testing mechanism for sizing of our future prototypes. Another version of the chassis is underway based on changes to our robot.

    Chassis Model

    Chassis Model By Abhi and Janavi

    Task: Use Creo Parametric to CAD the chassis

    After making significant development on our robot, we decided to model it. So far, we have developed the chassis of the robot seen below

    To develop this, many types of contraints were used.

    The entire model is dependent on this tetrix bar. The bar was constrainted using the Default feature since it was the base of the model. To this, the lift motor was attached as well as the battery box. These two were constrained by the Distance feature to the end of the bar.

    Four REV rails were attached to the TETRIX bar. These supported the wheels and their motors. They were constrianed through the Coincident to the bottom of the tetrix bar and Distance to the side of it.

    There are custom designed motor mounts constrained to th side of the REV rails using Coincident and Distance measurements. To this, there are TETRIX wheel mounts attached onto which the mechanum wheels are attached. On the outside, wheel guards were attached. The motors that drive the wheels are attached to REV motor mounts which were constrained to the underside of the REV rails. Attached to the motor is an axel which connects to a sproket to turn the wheel.

    The REV hubs were the hardest to constrain in this model because they didn't have typical sides. To mount them, we used a combination of Distance, Coincident, and Angle Offset features. The final part of the model was the phone mount which was simply constrained using coincidents.

    The next steps of this robot is to complete the robot model. This chassis was actually reused from last year. Due to licensing issues, we had to redevelop this model. We hope to experiment with this model to make space for the new, larger gripper arms.

    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.

    Friction Coefficients of Various Materials

    Friction Coefficients of Various Materials By Ethan

    Task: Test Friction Coefficients of Various Materials

    Introduction:

    Iron Reign has used many different materials in years past. In those years, we usually preferred materials which were more durable. We started with ABS, but while hard, it was relatively brittle. We attempted to use Filoflex and Ninjaflex, and they were more durable, but too soft. Finally, we had used nylon for the past seasons, as it was extremely durable but also was hard enough to get the job done.

    However, our needs have changed. In this challenge, we have to consider not only durability, but also how well the material works with other materials. And, the most important dynamic we must consider is the interaction with the foam blocks and the gripping material, since it is the major point-scorer.

    The coefficient of friction determines the power of the force in the opposite direction of motion. While friction is determined by ƒ=µn, we can ignore the normal force when using the same object repeatedly.

    Procedures:

    In this, we created an inclined plane that rotated around the base so that we could change its angle slowly from 0 à 90. The coefficient of friction is equal to the tan(ɵ), where ɵ is equal to the angle of slippage. We had to overcome some hurdles, most notably the higher center of gravity of a standard foam glyph, so we cut it down to one-inch of height so that it wouldn’t slip. Another way to restate the tan(ɵ) is the opposite/adjacent of the triangle formed by the incline.

    We slowly increased the slope’s angle until the block slipped, then recorded the angle of slippage to calculate the coefficient of friction, µ.

    Data:

    Surface

    Opposite Edge

    Adjacent Edge

    µ

    Standard Polycarb

    8.925

    8.125

    1.098

    Sandpaper (120 grit)

    9.5

    8.25

    1.152

    1-layer Ninjaflex, no ridge

    10.925

    5.5

    1.986

    1-layer nylon, no ridge

    10.25

    6.125

    1.673

    Nylon ridged

    6.75

    10.5

    0.643

    Drip Silicone Sheet

    6.25

    8.6

    0.727

    Full-Thickness Ninjaflex

    12.2

    less than 1

    Immeasurably High

    Results:

    We found, as we expected, that the Ninjaflex sheets have the highest coefficient of friction. The most important thing to do to further increase the coefficient of friction is increase the area of the contact. While we obviously can’t increase the surface area of the block, what we can do is increase the contact points between the sheets and the glyphs. The main way we can do this is decreasing the quality of our prints, counterintuitively. The reason for this is that the decreased quality creates little fibers that stick up from the print which create more contact points.

    The meaning of the coefficient of friction is how easy it is to slide an object across a surface, and as it gets higher, it gets harder to push across the surface. When the coefficient becomes greater than 1, it becomes easier to lift the object vertically than slide it horizontally (This can be qualitatively confirmed by touching the test block). And, for the conveyor belt, we need a high coefficient of friction.

    In the future, we should test multi-layered prints, as that ought to further increase the number of contact points. We also plan to impregnate the prints with fine garnet dust, which will hopefully make the sheets more abrasive, and therefore have a higher coefficient of friction.

    A critique of this experiment could include that the actual type of friction in the robot game is kinetic, or rolling, not static. In this case, the friction would be higher than rolling friction but lower than kinetic. This is due to the grippers pushing the blocks in, increasing the normal force. However, most coefficients of friction are proportional, so we can extrapolate from the static friction we gained to assume that the material with the highest coefficient of static friction will also have the highest coefficient of kinetic/rolling friction. In the future, we will also test kinetic friction with a spring scale.

    References:

    This source serves to prove the higher coefficient of friction of Ninjaflex – our experiment varies as we leave the 3-D printing artifacts on the sheet. As well, this measures a different type of friction than ours.

    https://ac.els-cdn.com/S2212827117300793/1-s2.0-S2212827117300793-main.pdf?_tid=0b998c36-02ac-11e8-bb23-00000aacb361&acdnat=1516980039_4970d0ef82d6f5d0a8bdd886b6005602

    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.

    Designing Grabber V. 4.5

    Designing Grabber V. 4.5 By Ethan, Evan, and Austin

    Task: Build an Updated Grabber System

    So, we probably won't finish both the Grabber V.5 and the Flipper designs by the North Texas Regional this Saturday, but we really need to improve our grabber system so that we have a chance of doing well in the robot game. From our last post-mortem, we decided that while our grabber performed *well*, it obviously could have been better. So, in comes our new design.

    Our main problems with our last grabber were twofold. First, our internal conveyor belt did not work as well as we had hoped. The point was to deliver blocks to the upper areas of the grabber, and it wasn't really doing that. The first cause of this was that it wasn't catching the block in the first place, as we had designed the internal lift too high off the ground to catch. The second issue occured when the block happened to be in the lift system. It was supposed to stay in place due to friction, and to have friction of an effective magnitude, the normal force must be reciprocated. And, ours wasn't, as the only thing that the block was able to push off of was the rubber mesh we designed, which had a high coeffiecient of friction, but not the rigidity needed so that the normal force was reciprocated 100%. So, so solve that, we installed a backer plate behind the mesh that the block can push off of, which has a higher reciproccal force than before. A final, more minor problem was that the block weren't always staying in the lift at the top, so we designed new Octopuckers to both push them in, and damage the glyphs less.

    Part 2

    Our eventual intention is to do away with this system, and move on to the v5 system which carries the blocks over the robot entirely, but for now, this should do.

    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.

    Intake Stars

    Intake Stars By Tycho

    Task: Improve the functionality of the gripper

    Our grabber is good, but it isn't achieving 100% of the potential it could. One thing we're doing is creating the Grabber V.5 previously blogged about, but we also want to increase the speed of the grabber in other ways, in order to get every single bit of performance out of our robot, since we want to really impress at Supers. So, we designed star-grabbers. The purpose of these are twofold. First, the unique star design we made allows the gripper to fish single blocks out of a pile of blocks so that we no longer have to fully align ourselves with blocks, which reduces the time we spend retrieving blocks. As well, these grab blocks more securely.

    Next Steps:

    The next step is to mount the modified grabber system with the stars on the newer Kraken chassis.

    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.

    Meeting with Advanced Waterjet Cutting

    Meeting with Advanced Waterjet Cutting By Tycho and Austin

    Advanced Waterjet Cutting

    Today we visited the Advanced Waterjet Cutting office and spoke to Sal Copado and Chris regarding our side shield designs. We had called a couple days in advance to set up this meeting, and we brought both our robot and our Mobile Learning Lab to demo. They were impressed by our work and were happy to support a local team competing at the Supers level. Sal agreed to cut out the side shields for our robot, though because of their heavy work backlog, they said that the side shields would not be complete until next Wednesday. While this is before Supers, we decided to go to the Dallas Makerspace to laser cut the design out of high density fiberboard so that we can start assembly based on the new design during our Saturday meeting and the following evenings. These cut-outs are pictured below.

    After the demo of our robot, we discussed the design of the side shields. At first they assumed that we needed assistance in putting together the design, but we had already prepared a design and had it ready for the meeting. After having a look at it, they identified a mistake that we had made. We are used to designing files for manufacturing - mostly on our 3D printer. We typically include machine adjustments into our designs so we can upload them right to the machines. For example we adjust our designs to compensate for 1st layer spreading or for material expansion into small holes. In designing our side shields for waterjet machines, we figured out the kerf we needed to work with and made adjustments accordingly. They saw this and said that there was no need for these adjustments, as they recommend that they make those adjustments themselves due to the variance in kerf for the different machines they use. They can cut industrial sized parts with either their waterjet or their laser for finer tolerances. We told them we wanted them cut out of 1/8" thick 6061-T6 aluminum and they confirmed that this was a good choice. The final files we sent them include designs for our side shields, mounting plates for our new 6in Mechanum wheels, and internal wheel mounts. We're basically covering the cost of the material and they are covering all other expenses.

    Next Steps

    We hope to pick up the new parts next Wednesday and get them on the robot that evening. We would also like to return with the full team to AWC and get a tour of their manufacturing facilities and machine shop. But we'll need to look for a student holiday to get that done since we're always at school during their opening hours. We'd also like to show them the updated robot and see if they have any ideas for further improvements.

    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.

    Progress of the Octopuckers Over Time

    Progress of the Octopuckers Over Time By Ethan and Tycho

    Task: Chart the progress of the octopuckers over time


    This design was too rigid, we overlooked the fact that triangles tend to be the strongest shape, and therefore this octopucker wasn't as compliant as we wanted, damaging the blocks.

    This design was really good, and we used it for 3-4 tournaments. Our initial design of these wouldn't damage the blocks significantly at the levels we used, but at extraordinary conditions they would gouge the blocks, and under normal conditions they would leave superficial scratches.

    This design was really bad. They would catch on each other and get stuck on themselves, and as a result wouldn't pick up blocks. However, they did not damage the blocks in any conditions. We never brought these to tournament.

    This was a step in the right direction. They didn't grip the blocks that well, but they worked and didn't get stuck on each other or jam.

    This is the design we're currently using. It's impossible to damage the blocks with them, and with the slightly larger cylinders, they grip the block really well. We're going to use these going into the South Super Regionals.

    These aren't octopuckers, but they deserve an honorable mention. We're using these intake stars at the bottom of the grabbers to securely grip the glyphs before fully loading them into the grabber system. As well, these have the added bonus of slightly increasing the speed at which we can take in blocks.

    Gripper Physics Diagrams

    Gripper Physics Diagrams By Ethan

    Task: Describe the physics of the gripper

    We always struggle a little with describing our robot to the judges. So, this post will be the third in a series of posts describing the physics of our robot (four if you count the coefficients of friction). First, we have the free body diagrams of the gripper.

    Next, to further describe this, we created an expiriment in which we determined the maximum force one octopucker can apply. We took a traditional octopucker and rotated it so that the arms of the pucker would barely impact the sides of the scale. From that, we applied force until the octopucker moved to the next arm. We then averaged the forces recorded to determine the maximum force an octopucker arm can apply.

    Under these circumstances, we recorded an average maximum of 4.125 oz of force, which translates to 1.147 N. This translates to an increase in the normal force of +6.882 N. This, in turn, increases the frictional force of the internal lift by fk=uN, where u is the coefficient of friction of the internal lift to the glyph. fk=1.96*6.882=13.489N. So, the simple creation of modified intake octopuckers allowed us to increase the frictional force by +13.489N, which allows our internal lift system to operate.

    Force exerted by the octopuckers vs time

    Next Steps

    On Saturday, we will continue this series of posts, finding the series of constants in infopost #2.

    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.

    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!

    Autonomous Updates, Multi-glyph

    Autonomous Updates, Multi-glyph By Abhi

    Task: Score extra autonomous glyphs

    At super regionals, we saw all the good teams having multi glyph autonomi. In fact, Viperbots Hydra, the winning alliance captain, had a 3 glyph autonomous. I believed Iron Reign could get some of this 100 point autonomous action so I sat down to create a 2 glyph autonomous. We now have 3 autonomi, one of which is multiglyph.

    I made a new methods called autonomous3(). For the starting settings (like driving off balancing stone and jewel points), I copied code from our existing autonomous program. After that, I realized that 10 seconds of the autonomous period had already been used by the time the robot had driven off the stone. That led me to think about ways to optimize autonomous after that point. I realized that if the gripper deployed as the robot was aligning itself with the balancing stone, it would save a lot of time. I also sped up the drive train speeds to lead to maximum efficiency. I had many runs of the fix though.

    First time through, I ran the code and nothing happened. I realized that I forgot to call the actual state machine in the main loop. Dumb mistake, quick fix.

    Second run: The robot drove off the balancing stone properly and was ready to pick up extra glyphs. Unfortunately, I flipped the motor directions to the robot rammed into the cryptobox instead of driving into glyph pit. Another quick fix.

    Third run: The robot drove off stone and into glyph pit. However, it went almost into the Blue zone (I was testing from red side). Also, the robot would rotate while in the glyph pit, causing glyphs to get under the wiring and pull stuff out. I had to rewire a couple things then I went back to coding.

    Fourth run: The robot drove off stone and into pit and collected one more glyph. The issue was that once the glyph was collected, the bot kept driving forward because I forgot to check the speeds again.

    Fifth run: All the initial motions worked. However, I realized that the robot didn't strafe off as far as I needed it to reach the glyph pit. I added about .3 meters to the robot distance and tested again.

    Sixth run: I don't know if anyone says 6th time is the charm but it was definitely a successful one for me. The robot did everything correctly and placed the glyph in the cryptobox. The only issue I had was that the robot kept backing away and ramming the cryptobox during end of auto. I fixed this easily by adding another autoState++ to the code.

    Before I made the fix after the 6th run, I decided to take a wonderful video of the robot moving. It is linked below.

    Next Steps:

    Everything is ready to go to do a multiglyph autonomous. However, the robot doesn't score by the codex for the correct column. I need to implement that with IMU angles before Champs.

    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

    Relic Recovery Reveal Video

    Relic Recovery Reveal Video By Abhi and Austin

    Task: Publish Robot Reveal

    After a season of work, Iron Reign has the final version of Kraken ready for Championships. With it comes a video showing off its features. We filmed it moving in all sorts of ways. We also found pictures from this season of the team's design growth and outreach events, including having fun. You can view it here below!

    Purpose:

    The purpose of this video is to represent Iron Reign as a whole. FTC is not only about the robot but also about the journey there. We showed our thoughts over the season, including outreach events, scavenging polycarb, or illustrating the engineering process of grippers.

    Position Tracking

    Position Tracking By Abhi

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

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

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

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

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

    Next Steps

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