Articles by tag: design

Articles by tag: design

    Sumobot Tips and Tricks

    Sumobot Tips and Tricks By Tycho

    Let's assume you are building a LEGO Mindstorms or Vex IQ based Sumobot, but you want to skip some of the basic mistakes beginners will make. Here are some tips and tricks.

    • Know the rules. It's silly to get disqualified because you didn't pay attention to the rules. Know the size and weight limits. Know the allowed construction materials and techniques. Know the startup behaviors. For example, your robot must not move for 5 seconds after you activate it. This simple rule has tripped up many competitors. And make sure you get to the competition on time to register and get your robot inspected for weight, size and any other requirements.
    • Stay on the field. For this you will almost certainly need at least one light sensor to detect the ring's white edge. We highly recommend two such light sensors placed at the front corners of your robot. This will increase your chances of detecting the edge when coming at it from an angle. You can also adjust your retreat behavior so the robot will be less likely to exit the ring. A retreat behavior usually consists of backing up and turning back toward the center of the ring or scanning for your opponent. You can back up curving away from the sensor that detected the edge first. A third edge detector could be placed at the back of your robot - but this is almost never needed. It would be only useful if you have a behavior that could trigger backing up when the rear of your robot is close to the edge. Theoretically you could detect the edge when being pushed backward by your opponent and try to twist out of the way, but we've never witnessed anyone pulling off this advanced behavior.
    • Build to the maximum weight for the competition. If your bot is heavier than your competitor's, you will have an advantage in traction and with inertia. You will be harder to push around and can more likely push them around. We've seen teams use extra unpowered motors to help maximize weight. Use a scale to be sure you don't exceed the allowed weight.
    • Build compact. Your robot should be as small and dense as possible. Air gaps within your robot and on the exterior should be kept to a minimum. The larger your robot is, the more likely that your opponent will contact a part of your robot far from its center of mass. When it pushes against this part, it will very easily turn your robot in a different direction. Most likely this will be to your disadvantage. You will also be very unlikely to push your opponent in the correct direction when in this condition. Also, the rules say that the first robot to have any part touch the surface that the ring is sitting on is out. If you have a large robot, it is much more likely that part of it will touch-out.
    • Build Low. The lower your center of gravity, the less likely your opponent will be able to topple you or force your wheels to lose traction.
    • Build a Skirt or Shield. A Sumo Shield is a smooth ramp that decends from the front of your robot down to the surface of the ring. The purpose is to create a wedge that will go under your opponent when you come into contact. The wedge will lift your opponent, transferring their weight to your robot. As a result your wheels can increase traction while theirs will decrease. A skirt is a shield that surrounds your entire robot, making it look like a cone or pyramid, so it works wherever the contact point is. But a skirt can be much harder to engineer. They have to be very sturdy, not impede your own movement, and not get in the way of any sensors you might use. Skirts and Shields also increase the size of your robot, so you have more risk of touching-out. Particularly if you have a hinged shield. Hinged shields are great for staying as low as possible to get under your opponent, but they need to be prevented from dropping down when over the edge of the ring. A floating skirt is a wall built around your robot that is only loosely connected or not connected at all to your robot. Instead your robot pushes the skirt around the ring and the skirt's weight keeps it flat against the floor. This makes it unlikely that your robot's motions will create a gap that your opponent can get under. And if your opponent does get under the skirt, they haven't necessarily started lifting your robot to steal traction. You could also have a sensor that detects if your skirt is lifting and back away when that happens.

    We've seen well-engineered robots with only edge sensors win big competitions. A solid, heavy and low robot with a great skirt will conquer when none of its opponents has the same features. Once you are in this category you can consider advanced tips.

    • Locate your prey. Actively seeking your opponent creates an advantage. It's also fun. Usually a forward-facing ultrasonic sensor is a good choice. You can scan for your opponent by making your robot turn in place while checking the sensor to see if it detects something close. Calculate the maximum distance your opponent can be from your ultrasonic sensor. Simply place your robot backed up to the edge of the ring and measure the distance from the front of your ultrasonic sensor to the opposite edge of the ring. Subtract the minimum size of an opposing robot. For LEGO sumos that would be about 6 in. or 15 cm. If you see anything closer than this you can assume that you've detected your opponent. (Or you've detected humans if you've failed to keep everyone at a proper clearing distance from the ring, including the operators) Continue your turn for a fraction of a second and turn on your charging behavior. Make sure you are aware of the minimum distance your sensor can deal with. You will probably want to recess your sensor from the front of your robot so that it will continue to register your opponent even when you are right up against each other.
    • Organize your software. Beginners will often design software that will do one thing at a time and be unable to react until those things are complete. For example, on detecting an opponent, charge for X rotations of the wheel. While the robot is trying to complete those rotations it's not looking at sensors, so it doesn't detect the ring and drives off if it was too close to the edge. We will post a complete lesson on designing software that always lets the highest priority behaviors (back-away-from-the-edge) interrupt the lower priority behaviors (scan-for-prey).

    New tread material test

    New tread material test By Caitlin, Tycho, Max, and Evan

    Task: Initial tests for new tread material

    The standard Tetrix treads and tread inserts aren't nearly as sturdy as we would like. When they snap it's a real effort to put back together stretched over the idlers, and the inserts peel apart, bringing our traction down. The new material is a rubber conveyor belt material from Andymark, and the underside track chain is 3D printed in nylon to mesh with the track drive gears. Outside: high strength high traction rubber Inside: 3D printed nylon to mesh with gears

    Reflections

    We first glue the nylon sections to the treads, laying them out flat so that some of the nylon hangs over one end and let them set overnight. The next day we bend it into a loop and glue the overlapping nylon and rubber together, and then let that set overnight. This isn't strong enough alone, so we ended up using the awl (used previously in Cascade Effect's game) to stitch at the boundary between two nylon strips, sort of like a thread staple.

    Initial tests showed that this design was a huge step up from the tetrix treads, and we're working to make another to complete the pair. One downside is that this design is a much thicker design, and rubs on the underside of other parts that weren't previously a problem.

    Geb Fixes and Adjustments

    Geb Fixes and Adjustments By Jayesh, Omar, and Caitlin

    Task: Prepare Geb for competition and get it into running condition

    With all of the large projects and events that Iron Reign have been commiting to (with more still to come), we have unfortunately been neglecting Geb and as we came to find a few weeks ago, many of the running parts that give us the majority of points in competition were falling in disrepair. We found that the tape measure system was repeatedly falling out of alignment, the beater bar rungs were getting tangled with each other, and our wire mapping was off in multiple locations. Besides those major problems, we had multiple set screw issues, tread dislocation, and syncing issues with our phones. Going periodically through the problems, we were slowly able to get our robot into its previous condition and replaced multiple older parts that wouldn't have held up in competition.

    Reflections

    Finding time to go through and bring Geb back to its previous condition is obviouslly vital for our upcoming UIL competition in Austin. Despite the obvious need for these fixes, we were able to see which mistakes could've been prevented and we made new guidlines to keep up Geb's condition. For example, on our tape measure system, we created a series of marks on each adjoining motor to match up and ensure they don't fall out of alignment. Caitlin also color coded the opposite sides of all the wires so we wouldn't have to keep tracking from one end to the other when we got confused as to where each wire was supposed to go. Combining this system with the wire map Omar and I had made (as discussed in an earlier post), we should now waste a lot less time on wire management and make major fixes much easier to carry out and finish from now on. With Geb's major part's in pristine condition, we need to focus on autonomous and driver practice for UIL.

    Building the Robot Base

    Building the Robot Base By Jayesh, Omar, and Darshan

    Task: Design and test implementation of a driving base

    We have spent the last few practices formulating a new driving base for our robot this year. We went through various possibilities: tank-based drive using both tracks and the omni-regular system (both of which are systems that we have utilized in previous years). However, both systems showed inefficiencies with this year's competition. We decided to go to a system using mainly Mecanum Wheels, complemented by an extrusion-based attachment system.

    Reflections:

    The three options that we had for the driving base(Mecanum, omni, tracks) all had different strengths and weaknesses that we judged as important for this year's competition. The omni wheel system is good for maneuvering and strength, but the low-set nature of it would interfere with scoring in the competition. The tracks are good for strength and base durability, but the competition doesn't necessarily emphasize those characteristics. The size, manueverability, and low center of gravity, of Mecanum Wheels all complement this years competition. The high altitude of the wheels will allow us to go over the scoring balls, perhaps having some form of collection underneath. The extrusion-based structure gives more ease-of-access and stability compared to our previous Tetrix-centered versions.

    Need for ZTE Speed - The Movie - The Game

    Need for ZTE Speed - The Movie - The Game By Max

    Task: Make a case for the ZTE Speed controlling the robot

    While we are still in the early stages of design and it's not wise to make a permanent decision about where the robot's controlling phone will be, we can't let it float freely around the robot like a brain in a jar for much longer or it'll start getting caught in the developing systems. Normally, we could solve this easily by drilling a few holes in an off-the-shelf phone case and bolting it to the robot, but both the robot's design and the phone's code are constantly changing, so this would be far too permanent. We decided that the best way to house the phone would be a custom-made case with plenty of bolt holes to make it easily mountable and removable as well as a front which can be taken off at any time so we can take out the phone to reprogram it without driving ourselves insane.

    I decided to make the case a pair of 3D-printed parts: a sturdy base made of t-glase which can be bolted to the robot and can easily socket the phone, and a flexible nylon cover plate which is kept in place by tabs which wrap around the base component but can be pulled out of the way when the phone needs to be put in or taken out.

    Reflections

    It took a few iterations before we printed the pieces, but the system as a whole is working smoothly. The phone is easy to replace and so far we haven't seen the cover come off once while the robot was driving. The only forseeable issue is with the tabs. Although they are flexible enough for our purposes, they are thin enough that they can be broken if bent too far. Since the face plates don't take too long to print and the 3 tabs left over after one breaks are still entirely capable of holding the phone in anyways, this shouldn't be too much of an issue, but it's still something to keep in mind for the future.

    Launching Mechanisms

    Launching Mechanisms By Ethan

    Task: To build a launching mechanism for the particles

    For the 2016-2017 season, particle scoring is really important. During autonomous, balls that are launched into the center vortex earn 15 points each, and balls that are launched into the center vortex earn 5 points. If done quickly enough, the particle scoring can negate most of the advantages another team has - just 8 particles scored during the driver-controlled period is equivalent to scoring all 4 beacons. With a good scoring mechanism, the only thing that your team must contend with is the other team scoring autonomous beacons and/or moving the cap ball off of the field.

    So, we must seriously consider all of our launching options. We narrowed our options down quickly:

    • Slingshot - Easy to make, but wouldn't hold up
    • Air launcher/Pneumatics - With our team, bad idea waiting to happen
    • Crossbow - Dangerous, but accurate.
    • Flywheel launcher - Accurate, requires least maintenance, but huge battery load
    • Catapult - Less accurate, but simple and powerful
    Of these options, we narrowed it down to the Flywheel and Catapult

    Flywheel

    Above is an example of a fully functional flywheel. The pros of that design are that it is efficient, accurate, and requires little upkeep. On the other hand, it needs at least 2 motors unless someone is willing to do gear witchcraft. As well, two extra motors will drain the battery (bigly), as we learned from last year's mountain climber. Finally, it can take up quite a bit of space on the robot and weigh it down a lot.
    Also, my initial model of it did not function well.

    Catapult

    We had trouble deciding on a catapult design. Initially, we were considering a more complicated flipper design, but after seeing our sister team's struggle with their design, we decided on a simpler, bungee cord design. The pros of this design are accuracy, simplicity, and strength, but the cons are that it isn't *as* accurate and that the elastic band will need to be replaced.

    The coolest thing about this design is that it can be simulated before I change anything, using a catapult simulator. A sample of our catapult can be found here.

    Reflections

    This add-on is the first of many that we must make to prepare for competition. Next, on the build list, we need to create a capping attachment and intake system. In the future, we should probably speed up our development process if we are to head to the Arkansas regional tournament.

    Ready the Artillery

    Ready the Artillery By Max

    Task: Design a bowl for our upcoming catapult system

    We've been experimenting with catapult systems for a little while now, but we're still sorely lacking one of the core ingredients of any catapult system: the ability to throw things. I mean, technically we're lacking the ability to hold what we're trying to throw, but it's the same effect.

    In any case, it's an issue we have to deal with, and our solution is good ol' nylon. I went through a few designs for a bowl to hold balls, and the one we're using is pretty much a semicircular shell with a handle which mounts to the arm of the catapult and plenty of holes to lower the weight while keeping it sturdy.

    (herecomedatbowl.jpg)

    Reflections

    The bowl is a great fit for the ball and doesn't seem to interfere with the strength of the catapult, but there are still two issues which we can't address yet.

    Firstly, we haven't gotten a loading mechanism planned out yet. We can make the catapult as strong and reliable as we want, but beyond the first ball we're allowed to load for autonomous, it won't do us any good until the robot can actually take balls from the floor and load them into the bowl. That might not seem very pertinent to the design of the bowl, but since it's the only physical interface between the loading mechanism and the catapult, it'll be the first thing to change if the two don't fit together on the first try.

    The second issue is just that cleaning out the printed model is an utter pain. Again, this is no reason to change the model right now (and it probably won't be one later on, either), but since we're likely to have at least one more version in order to solve whatever issues we encounter while developing the loading mechanism, there's at least a 90% chance that another catapult bowl will need to have its support structure gouged out over the course of an hour. I just feel sorry for the poor bugger who has to do it.

    Yeah, it's probably gonna be me.

    Stabilizing Our Driving Base

    Stabilizing Our Driving Base By Jayesh, Omar, Max, and Darshan

    Task: Stablize Meccanum wheel base so the driving is more stable and consistent

    Our Meccanum wheel base idea started off on a shaky note. While we had a good amount of success in the tass we wanted to complete, like driving right or let without turning the entire robot, including the basic driving functions. However, as we went on with testing, we found that over time, the force the meccanum wheels were exerting on the chain was actually causing the motors driving the chains to come inwards. This was thereby loosening the chain and weakening their effect on the driving chassis. To fix this, we decided to mount angled beams between the motor and Meccanum wheels to stabilize and prevent the motion. We then further strengthened the system by 3D printing trapezoid-shaped mounts that have more surface area and strength to stabilize the system.

    Reflections

    As we go on improving the robot, we keep finding that our new designs have an incredible amount of errors and small bugs that need to be looked at before moving on to the next big design. Now that we have a stable and relatively reliable driving base, we can now focus our attentions to the scoring mechanism. Through our redesigns of the motor stabalizers we have found the use of testing on both the ground and in stationary conditions. We need to design a new mount to make stationary testing more efficient. This will especially be important for the testing we'll have to commit to for our scoring mechanism. (which will be discussed in a future post)

    Launching Mechanisms Pt. 2

    Launching Mechanisms Pt. 2 By Ethan

    Task: To improve upon launching mechanism designs

    Catapult

    First and foremost, we now have one completely functional, terrifying, catapult. The motor mechanism is cannibalized from our sister team's attempt at a catapult, which broke apart on testing.


    Flywheel
    So, while we don't have a functional flywheel as of yet, we have done the math in order to get it up and working on the first try.

    For reference, we need to launch the ball ~1 meter, the frequency of the motor is 2.53 s^-1, and the radius of our gear is 2.65cm.
    velocityfinal^2 = velocityinitial^2 + 2*acceleration*change in y
    velocityfinal = sqrt(2*9.8m/s^2*1m)
    velocityfinal = sqrt(19.6m^2/s^2)
    velocityfinal = 4.427 m/s

    actual final velocity = 4.427 * 1.25 = 5.534m/s
    actual final velocity = 2*pi*radius*frequency
    (5.534m/s)/(2*pi*2.53s^-1) = .348m

    gear ratio = gear1radius/gear2radius = 2.65/.348 = 1:7.615
    However, for simplicity, our needed gear ratio is 1:8.

    Reflections

    We should advance in building our attachments - if we go to Arkansas, we have <6 practices to go. And, from now on, we need to do the math behind them so we know we're doing them right.

    The Robot is a Nautilus Now

    The Robot is a Nautilus Now By Max

    Task: Make a conveyor shaft to guide particles to the catapult

    We’ve thoroughly proven that the tread of rubber bands is an effective method of ball collection, but as of yet it can only move the balls along the ground. We’ll need a way to move them upwards to the catapult bowl’s level. While we could use another motor to push the particles up and over the belt, it could get caught and we’d rather not take up another motor port. We decided to instead make a semicircular tube to guide the balls, with no motors of its own, but instead simply keeping each ball in contact with the center belt as it turns around to move back to the front of the robot.

    After measuring how large the tube would have to be to house the ball, it was clear that it couldn’t be printed in one part (not that I would have if I could - the infill would be a nightmare to remove), so instead I made a model for a segment of it which can be printed several times and then bolted together at a few built-in sockets. Each segment accounts for 30 degrees of the 180-degree arc we plan to build. A segment can be seen below.

    Reflections

    The model prints well, connects easily, and sockets the particles perfectly, but it lacks the friction required to keep them from spinning in place instead of moving up the tube. We were able to solve this by applying a stripe of memory foam to the inside of the tube with double-sided tape.

    Parasyte

    Parasyte By Jayesh, Omar, Darshan, Caitlin, and Max

    Task: Design a collector for the balls

    We've spent the last few practies creating a ball collector. The idea was to have our track with the gripping rubber bands reach from the bottom of the robot to our 3D designed ramp. The path would guide the balls to a higher position on our robot to the launching mechanism. We needed to adjust the correct orientation of the support beams guiding the balls, needing to drill new holes and adjust beam lengths.

    Reflections

    There have been a lot of adjustments we have had to made to the this tread-based system. Starting from an eyeball test of the length, we had to eventuall lengthen the whole tread to fit the whole system. With our length being about finalized, and our entire path about done, We are about ready to attach our launching mechanism and start adjusting the scoring mechanism.

    Intake System Improvements

    Intake System Improvements By Caitlin and Janavi

    Task: Replace rubber bands with smaller versions and add wider intake area

    New intake area is wider than before


    At the Scrimmage we noticed that the rubber bands would get tangled as they rubbed against the underside of the catapult bowl, and so didn't reach as far down at the bottom. We untangled them before each match but decided to test out the smaller ones when we had the chance at practice. We were planning on adding a wider area for intake with some circles of treads and rubber bands, but with the long rubber bands they just got completely tangled in each other. So this practice we replaced the long rubber bands with the shorter versions and looked at differences

    Reflections

    It took a little while to physically pull out and replace each band, but the rubber bands we use are stiff enough that they can be pulled thin enough to slip in without getting twisted up. The single conveyor with the smaller rubber bands wasn't any noticeably worse than the same conveyor with longer ones, and our load rate stayed pretty much the same. We then added the smaller side brushes/spinners on that axle. Originally the longer rubber bands tangled up and threatened to break the belt, but this made it easier for Tycho and Omar to score. The added wheels on the axle make the intake area almost as large as the robot, stretching from wheel to wheel.

    Catapult Unfixes

    Catapult Unfixes By Ethan

    Task: To bring the catapult within size limits and improve it

    What Actually Happened: Abject failures

    So, the original catapult, when not stuck, performed pretty well at the scrimmage. However, since we opted not to measure our robot at the scrimmage, we didn't realize that our robot was not within the FTC size limits. When measured after the fact, it was 18x19x20 in x, y, and z axes respectively, due to the catapult's position on the robot. To rectify this, we decided to cut the catapult down, and add a new ball-scoop while we were at it.

    So, we cut down the catapult arm, and that's where the critical error occurred. I forgot how a lever lever-ed, and completely removed the pull-down part of the lever. And, since I didn't check it afterwards, I continued to make modifications, cutting down the top to 18 inches, and reattching it to the robot. Also, these modifications prevented testing of the robot.

    And finally, in the moment of truth, the robot failed to work.

    Reflections

    In the future, I should probably have someone check on my work to make sure I'm not fouling everything up. As well, I probably should try to not make modifications the week before the tournament.

    Catapult Upgrades

    Catapult Upgrades By Max

    Get Nostradamus on the horn, there’s a new prophet in town.

    Task: Imbue the catapult bowl with infinite power

    As I predicted in the article about the first version of the catapult bowl, it’s gonna need a rework. There’s enough room for the catapult system and the conveyor system to fit together on the robot, but the lip of the bowl is too high for a ball to roll into the slot. This is a tough issue to solve: we’ll have to slice a chunk out of the hemisphere of the bowl, but doing so will make a bunch of sharp corners in the area of the catapult which is closest to the rubber bands, and the potential repercussions of the belt and catapult getting snagged on each other in the middle of a competition are catastrophic. I’ve solved the problem as best I could with a very generous rounding over of the points left over after removing the section of the bowl which is blocking the balls.

    Reflections

    This has solved our problems in interfacing the two systems, but I’m a bit concerned that taking so much material out of the outer end of the bowl may affect the flight path of the particles by providing less resistance to the centrifugal momentum of the ball as it accelerates. We won’t go back to the original bowl based on that knowledge, but it’s still an important detail to keep in mind as we consider our options for scoring points.

    Final Catapult

    Final Catapult By Ethan, Evan, Omar, and Jayesh

    Task: Finish up the catapult before Arkansas

    Today marks six days until Doomsday (AKA Little Home, Arkansas), so we needed to finalize everything. For the catapult, Jayesh and Omar fixed my catapult "fixes". However, with the new fixes, the catapult was more powerful, and required recalibration. To adjust to the new fixes, we removed the old stop-mechanism, and replaced it with a wooden one that stops it on the 2nd level of the robot.

    As a result of these changes, the arc of the catapult is more horizontal while preserving the height of the launch. This actually gives us a slight advantage in where we can fire the balls from. The only downside of the new design is that it tends a bit to the left.

    Reflections

    The catapult is good for this tournament, but we need to pursue alternate designs, such as the flywheel in the future. We should also make better prototypes to test.

    Robot Frame and Rewiring

    Robot Frame and Rewiring By Jayesh, Omar, and Evan

    Task: Build a frame to increase available surface area on robot to rewire current configuration

    The wiring, which had been on the robot, had been a constant issue. The wiring tangled, interfered with the scoring mechanism, and led to some inefficiencies in electrical output. In order to increase the available space to reconfigure the inner workings of the robot, we built a second testrix layer, which also conveniently serves as a handle.

    Reflections

    The new level on the robot has given us a lot of much-needed flexibility for arranging the different parts. Now the core of our robot isn't a jungle of tangled cords. As we continued building the layer, we found it could be used for various other purposes besides simply space control. The back layer simultaneously stabilizes our scoring mechanism, allowing us to control our shot more. Besides the modules, the phone and power switch are also attached to the upper layer for ease-of-access. As we only made layers for the front and back, the sides of the robot are left open, nonetheless more free without the wires, for our cap ball lift (which is currently in progress, more on it in future posts).

    Designing Button Pusher

    Designing Button Pusher By Darshan and Omar

    Task: Design potential beacon scoring mechanism

    Up to this point, we hadn't given much attention to a beacon scoring mechanism that we could use in both autonomous and tele-op. At the scrimmage we learned that scoring the beacons was almost vital to winning the match, and we couldn't do that. We rigged up a short u-channel on a plate and attached it to our robot, hoping we could just ram into the wall and it would work. It didn't. We started designing potential button pushers. We figured a servo would have enough power and saw a few robots using either a large flat plate or some type of wheel to score the beacons. We thought that a hard-foam wheel would work best, but aren't entirely sure how we would mount it with our limited space, so we'll have to see what best fits our needs and capabilities.

    Reflections

    Whatever our solution is for this problem, with our first qualifier really soon, we have to come up with it quickly. We realize that if we plan to be a contender for the top seed, we need to be a consistent beacon scorer.

    Time to Skip Version 9

    Time to Skip Version 9 By Max

    Task: Make some changes to the catapult bowl

    The apocalypse is at hand.

    Chaos reigns as the world is thrown into peril; whole nations are thrown into anarchy by the second; and the superpowers of the world, once bitter enemies, have no choice but to band together as a horrid product of our own hubris, a threat more devastating than any which mankind has ever before seen, appears to put a grisly end to humanity:

    The catapult bowl is too floppy.

    Cut to black. Text appears: VERSION 8.

    So, we got a problem. And as the guy who does the bulk of the 3D modeling around here, I’ll be fixing it. In case you didn’t gather what that problem is from the intro sequence, the catapult bowl is a bit too flexible for our liking, which is causing a bit of inaccuracy. To remedy this, I’ve added some simple buttress-type structures to the underside of the bowl to put some more support on the thin section where it seems to be flexing the most.

    Reflections

    The supports are just what the bowl needed. It’s flexing far less, and there’s been a noticeable increase in the accuracy of the catapult since it’s been added. All in all, this was a box-office blockbuster.

    See VERSION 8 starring Adam Sandler as Catapult Bowl this summer in DVD and IMAX.

    Beginning the build for the Cap Ball Trapper

    Beginning the build for the Cap Ball Trapper By Jayesh and Omar

    Task: Give Deadshot flexibility in end game scoring by designing Cap ball launcher

    One of the issues we saw in Arkansas was in the lack of flexibility we had in terms of the end game. We efficiently scored balls and beacons, but when our teammate for a specific match could do the same, we lost possible points scored. This led us to conclude that a Cap Ball Trapper, would be necessary for the sole purpose of flexibility. We focused on an extrusion-based system, based on a set from AndyMark. We've rigged up a pair of basic stairway systems, which will form the main lifting mechanism for the Cap Balls, now we have to figure out where to place them.

    We followed the Youtube video above to figure out how everything was put together initially, and then expanded from there.

    Reflections

    The idea of flexibility is a luxury we can consider due to the progress made for the Arkansas competition. The idea is in scoring the maximum amount of points, regardless of the capabilities of our respective partners. The rigs themselves (although they do need some end covers so they don't fall apart) work fine, but we need to figure how it's going to fit into the general scheme of our robot. We have concluded that the rig will require two motors (we're at our limit; hooray traditions). The main goal in finishing this system is in figuring out both its deployment and placement.

    Fixing Faulty Encoder

    Fixing Faulty Encoder By Tycho and Jayesh

    Task: Fix a faulty encoder on our robot

    This shows a test of our encoder issues. It might have been a month ago that we noticed a strange behavior in our autonomous code when the robot was moving forward at low speed. It would curve to the right when we were telling it to go straight. We probably would have noticed the problem earlier if we had any kind of subtlety in our driving. But we didn't, partly because the problem goes away when driving at full speed. We did suspect that the problem was in the encoder feedback of the front left drive wheel. In this video you can see how it ramps up to full speed much faster than the other motors. Here we are driving the robot with encoder PID active. But when driving backward, the motor/wheel behaves properly. This indicated to us that one channel of the encoder was working normally while the other was skipping ticks. But the problem could be in the encoder, the encoder cable or the motor controller. Since our motors take some time to change out and we were heading off to the Arkansas State Championship, we decided to simply turn off PID control. The problem goes away when we are simply driving the motors with open loop power levels - proving that the encoder is the culprit and that motor imbalance was not an issue. The problem with just turning of PID control is that we were still getting bad odometry since our method of calculating distance traveled is based on averaging the encoders across the four motors. So we had to adjust our target distances in autonomous based on trial and error instead of proper calculations.

    Here we are trying to identify the source of our encoder issues. We swapped the encoder cable and and ports on the motor controller, but the problem stayed with the front left motor. That told us that it was the motor's encoder that was the issue. We confirmed through telemetry that the encoder was giving no ticks when driving forward, but worked fine in the reverse. So we replaced the whole motor and this time it sped up faster than the other motors in both directions. That really mystified us for a bit. Turns out the substitute motor had an encoder that was dead on both channels. What were the odds of that? We'd simply pulled a motor from our inventory and assumed it would be OK. But it must have been one we hadn't needed to be encoder controlled. We finally found a third motor, this time tested its encoder before throwing on the robot, and all is well now. We can now drive the robot under PID control and it drives as expected at various power levels. We need to re-calibrate our blended travel distances with the working encoder, but feel much better about our performance. We can even reliably use run to position commands if we want, though our navigation code doesn't require that.

    This just shows the proper behavior of the robot after our encoder troubles were resolved:

    Mapping Out Autonomous

    Mapping Out Autonomous By Janavi, Tycho, Omar, Evan, and Darshan

    Task: Mapping Out Autonomous

    To tell the robot how far to move forward we had to calculate our motors RPM. We did this by telling the robot move to 10 rotations forward and calculating how far it travelled. After he RPM we created a model field upon which we designed a set path for the robot during autonomous. One path for red and then one for blue. Both of these paths allowed the robot to shoot two balls and then push the beacon buttons.After testing this we realised that our alliance partner may be better or worse than us at shooting the balls. So we created a method that allowed us to push a,b, or x to change the number of times the catapult fired.

    Reflections

    We are constantly working to improve the design our Autonomous. Before this, while our autonomous may have worked. It didn't allow us to collaborate with our alliances to create the best path, stopping us from earning the most points possible. Now with these changes we can work together with our alliance partners to complement each others strengths and weaknesses, helping us earn more points. This will also encourage us to scout around and interact with other teams before and in-between the matches, letting us create a even more detailed scouting sheet.

    Cap Ball Lift

    Cap Ball Lift By Omar, Jayesh, Darshan, Evan, and Max

    Task: Build a lift to try cap-ball scoring

    Although we're confident in our robot's ability to shoot balls and press beacon buttons, we decided that in order to be competitive, we should try to score the cap ball. The lift would have to be strong enough to lift the surprisingly heavy ball, but also not take up too much space. Our robot, as like every year, is very close to the 18 inch size limit in all directions, so we needed to think of a volume-saving method of mounting the lift. After considering several methods and remembering other lift mechanisms that we'd seen at previous competitions, we decided to use a series of sliding extrusions. It's a common design and not up to our usual standard of flair, but it's relatively small, flexible in terms of mounting, and only requires one more motor, bringing our total up to seven. We first visualized how we'd mount the lift:


    (We went with a mix of both)

    Using a YouTube video guide, we were able to assemble two columns of four extrusions each that slide up when pulled by a tough string, which is wound around a spool connected to the new motor. It is mounted on top of the robot rather than on a side because we had the most clearance in the vertical direction. It then rotates forward and stands in the correct position, the motor rotating with it. After several rounds of testing, we decided to use a faster motor, and it proved to be successful in speeding up the lift's ascent.

    Reflections

    Although it won't be ready for our qualifier, we've made very solid progress on this lift. There are several problems which still need to be tackled. First, we need to figure out what we're going to use to actually grab the cap ball. The lift is useless without it, and even if we use some simple pieces of wood and a servo, there needs to be something there. Second, there is a large space between the rotation point of the lift and the ground, which means that it must somehow reach down in order to wrap around whatever claws we devise around the ball.

    Motor Controller Mounts

    Motor Controller Mounts By Ethan, Darshan, Max, and Tycho

    Task: Prevent static shocks to our robot

    Throughout the year, we've dealt with static issues with our robot, as shown here and here. And, now that we've pretty much gotten autonomous and the lift out of the way, the static was our only remaining issue.

    To prevent the static shocks, we needed to isolate the motor controllers and other parts from the metal section of the frame. This was achieved by adding a polycarbonate shield on each side, and mounting the corresponding motor controllers. However, we had to partially remove the swinging arms that we created in the last post in order to mount the siding. We plan to add LEDs on each side of the robot to give the robot some "bling".

    Reflections

    The polycarbonate siding in conjunction with staticide should give us a huge advantage in the robot game for the Jan. 14 tournament. As well, it may net us some design points, as it is a solution to a problem that many FTC teams suffer from.

    Introducing the New Particle Accelerator

    Introducing the New Particle Accelerator By Max

    I was going to make a Windows 10 joke but then we stopped using the catapult at version 8.

    Task: Design a flywheel for a new system replacing the catapult

    So while our catapult was good, we needed something better. It frequently missed and had other issues due to it being dependent on elastic bands that can lose tension over time. It would occasionally miss balls from areas it would usually be able to shoot from. As well, it was just a little dangerous with the metal arm snapping up and down.

    At the beginning of the year, we had toyed with the idea of using a flywheel on our robot, inspired by videos such as this, as well as other competing teams at our Wylie and Ellis Davis Field house qualifiers. So, finally, we decided to create a flywheel launcher.

    We tested numerous versions of this flywheel. We printed out the same design with three different materials, high density nylon covered in foam tape, high density ninjaflex with 35% infill, and low density ninjaflex with 20% infill. We decided on the last one, as it accelerated the ball the fastest without slipping. We also designed a particle guidance system so that the balls would be more accurate in making the vortex shots.

    <infomercial>

    Introducing: The Iron Reign Particle Accelerator 1.0

    This beautiful piece of machinery is a particle accelerator, which has a huge, ninjaflex, 20% infill flywheel to take all of the particles off the field, and jettison them to the moon (and back down into the vortex). We've revamped our intake system so that we can control the balls going into the accelerator. All of its important parts are designed and 3D-printed by Iron Reign. It is quite literally the best attachment we've ever designed for our robot, and probably could launch people into space faster than NASA can at the moment.

    </infomercial>

    Reflections

    We still need some finetuning in our code for the flywheel, as our autonomous isn't designed for it yet. As well, we'll probably run into some unexpected issue at the tournament, like we always do.

    Fly Wheel 2 - Fly Harder

    Fly Wheel 2 - Fly Harder By Max

    Task: Create a backer rail to guide the particle as it fires

    Our work on the flywheel design has been an effective proof of concept, and now we need to work it in to the rest of the robot. However, just like with the catapult, there’s a couple issues to iron out before all the pieces can start moving in a way that doesn’t make the robot implode.

    Most notably to the 3D modeler in me, I fear that our current rails which we use to guide the ball as it is sped along by the flywheel might get caught on the rubber bands of the belt which collects the balls. Both ends of the rail have sharp angles which can easily catch on the bands, and it doesn’t really help that the flexible nylon of the rails means that a rubber band that is particularly stubborn in releasing it could turn our launching system back into a catapult of sorts again.

    The fix was quite simple: I used Creo to take out the piece of the rail which ran the greatest risk of being caught, and got rid of some extra bolt holes too since I happened to be in the neighborhood.

    Reflections

    Not much to report on this one. We’ve printed and tested the model with no catches, and it also seems that the changes to the rail have had no effect on the speed or accuracy with which we can fire the ball. Overall, this one was a simple success.

    Building the Fly Wheel Launcher

    Building the Fly Wheel Launcher By Jayesh, Omar, Darshan, Evan, Tycho, and Max

    Task: Create a particle launcher with a higher scoring rate

    The first particle launcher we saw by another FTC team was actually a crude flywheel and rail design back in October where the rail was a cut up PVC elbow. Back then we considered a number of different designs including impact launchers, catapults, flywheel + rail systems and dual flywheel shooters like our sister team built. We decided to go with a catapult design because Max had experience with catapults and knew that they could create very repeatable trajectories.

    Our catapult has achieved those reliable trajectories. We operated it with a choo-choo mechanism that allowed us to fire and re-cock without having to change direction, so that made reloading easier and faster that it might otherwise be. It accurately scored, with consistent ballistic trajectories, however, the system had problems with ball loading when our 3D printed catapult bowl kept failing due to layer separation. As a result we had a lot of misfires and had to replace our bowl often. So our moderate cycle rate and our misfires meant we actually scored only about 4 balls during our average teleop phase. As the season progressed it became increasingly clear that we would have to radically improve our center vortex game and that was driven home when Technical Difficulties and Technibots crushed us with their world record score in the finals match at our first qualfier.

    So we decided to move on to a flywheel-based design, knowing that we would likely be sacrificing some accuracy for a much greater cycle rate. We knew that dual flywheels tended to have even greater issues with accuracy due to their extremely short contact period and the chance that one or both wheels would hit a slot in the wiffle ball. We saw direct proof of this as our sister team, Imperial Robotics, struggled to get their dual-flywheel design to work consistently. And Ethan had attempted to build one very early in the season, but never really go it working. So we decided to design with a single wheel with a semicircular ball guide or rail. Max created a custom 3D design for both the flywheel and for the rails. The rails were printed in nylon, our preferred structural plastic. He printed three different flywheels for testing. One was in nylon meant to be covered with foam for compliance. The other two were printed in Ninjaflex (urethane) at different infill densities. The foam on the nylon version shredded at the RPMs we were using. We probably could have found a better adhesion solution, but found that the low-density Ninjaflex version worked beautifully and has stood up to extensive testing.

    Reflections

    The continuous improvement of designs is a constant focus we adhere to. Previously we'd gone through two major revisions of our catapult system, with a whole bunch of minor modifications, and that system got us qualified for the North Texas Regionals. We saw the pros and cons, and eventually saw fit to change the system to score more points in the long run. We are now able to score around 75% of the balls we shoot. The key is in how quickly we shoot now. Before we would have to collect balls, turn the robot around, load a singular ball into the scoop, and shoot. Now, we can shoot 4-5 balls right after another without turning around. This will allow us a much greater center vortex scoring rate as we aim to be one of the top teams at Regionals.

    Super Regionals Booth Design

    Super Regionals Booth Design By Caitlin, Austin, and Omar

    Task: Design a theme and layout for super regional pits

    A year or two ago Imperial advanced to Super Regionals, bringing along a few Iron Reign members. While teams get excited and have a lot of fun at Regionals, it's nothing compared to the displays found at super regionals. We've grown into our cyber-Roman theme this season, and Omar is currently working on a logo to match our new color and feel. Hats won't be enough at this level though, we've got to step it up a notch! Austin and I first looked for a base image, first looking up Roman forts, then moving to campsites. The forts weren't as recognizable, and the tents could be set up much easier. We drew most of our inspiration for the booth theme from the image above, credit to Gaius Hibernicus on Flickr.

    Having a recognizable theme is important on two points: scouting and sponsors. Sponsors are more likely to be generous if we can point to a display and show them that people will look at our setup and see their names on it. It's the way to thank them for their generosity in the season. When scouting, you want to be remembered. A forgettable team isn't chosen. Super Regionals usually has teams that have already made alliances over the season, so if you aren't one of those, you've got to stand out in both the game and in the pits.

    Reflections

    Oddly, this competition has a pit size of 9'x9', not the usual 10'x10', so we will be designing to that measurement, and hopefully expanding it later. Austin designed a base frame structure in SketchUp and I started making models of our carts, banners, and tables to be arranged after. We need enough sign space to display our Inspire banner, sponsors, school banner, and team aquila. The robot cart needs a clear path to the workspace area, and we need space up front for pins, a display with our outreach and robot reveal running, and a trophy display. I've made models for these because we already have them, and have begun the shuffling and brainstorming.

    Austin created a Roman style shield in a record time, using old field mats as the core and sawed off broom handles (left over from the hats) to keep them stiff. We ran out of daylight to scrub them clean of dirt, but did that this practice. When we were sure the tape would adhere he covered the front in red duct tape with a gold border. He also mounted an IKEA bowl to the front as decoration, and is planning to round the corners off so he can mount a LED strip along the edge. It already looks really impressive, and we have more materials to make a second if we keep the pace up.

    The structural design of the tent was adjusted for simplicity's sake; we're making a cube as large as the competition allows, and hanging tan fabric/ripstop nylon along the different sides to create the tent shape. The PVC supports are going to be wrapped in a worn/tea-stained look material to keep it unified. Our two smaller rolling carts will have our front displays, and since they have shelving, they can serve as storage for the boxes that don't need to get pulled out as often during the competition. We can mount a shield to the front if we want to cover them up. The Inspire banner is bright enough that it can likely be seen easily from the back or side of the tent, the school banner will go across the top above everything, and the aquila will likely go in the front on the left, beside the displays.