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.

    REV Robot Reveal

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

    Argos V2 - a REV Robot Reveal

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

    Intake System Competition

    Intake System Competition By Evan and Austin

    Task: Compare build designs for the cryptobox intake system

    The block scoring system is going to be an integral part of the competition this year, and it will have to built sturdy. It’ll have to be reliable for us to have any shot of winning any matches. So we got to brainstorming. Me and Austin spent a while at the whiteboard, drawing up various mechanisms and ways to pick up blocks. I became set behind the idea of a block delivering system similar to those modern vending machines that have two degree of freedom movement. I 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. Austin came up with the idea to use our tank treads from Gebb, 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, I 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. I 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 griper 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 i'll be scrapping my idea for this grabber arm bandwagon everyone seems to be hopping on. While the grabber arm allows for quick pick ups and easy placement, my 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, I’ll be making improvements and new iterations. We toyed with some materials earlier on in the season, and I’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 to 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, 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. My solution would have had a side to side conveyor belt that moved glyphs back and forth to arrange them in the correct order, and then push them into the slots. This movement would have been separate from the four mecanum wheels that we are using in the chasis. His idea was simpler than mine, a conveyor belt that ran through the middle of the robot to bring the glyphs to the keybox, where they could be slotted in with the side to side movement provided by the mecanum wheels. So, like an outnumbered Supreme Court judge, I decided to join the winner so I could have a say in the early design. Once he got a prototype ofhis contraption working, it was able to pick up blocks effectively but it still needs improvement. It has issues with blocks at an angle, and it has trouble slotting the blocks into the keybox, but it's a nice step toward a working block system. We are currently planning to use the mecanum wheel base we used last year but this could change anytime. We left practice with a direction and that's better than nothing.

    Designing the Grabber Further

    Designing the Grabber Further By Evan

    Task: Design the grabber design and make future plans

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

    Designing the Grabber

    Designing the Grabber By 5

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

    Chassis Upgrades

    Chassis Upgrades By Austin

    Task: Upgrade our chassis

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

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

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

    Fixing the glyph breaking

    Fixing the glyph breaking By Abhi

    Problem: Stop Destroying Glyphs

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

    Model:

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

    Result:

    Designing the Jewel Thief

    Designing the Jewel Thief By Evan

    Task: Design a part to remove the jewel

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

    Reflections

    While not completely finished, I intend to have it done by the first qualifier, fully functional. It should allow us to knock the jewel off during autonomous effectively and efficiently, although that’s all to be seen. We also should make a fully functional version and test it with autonomous.

    Intake Grippers Pt2

    Intake Grippers Pt2 By Evan

    Task: Attach the new intake grippers

    The basters are here and in full swing. I spent a late night putting together the two intake columns. They were attached to a backing by Austin and Kenna while I was away, allowing me to finish it by attaching the final servo and tieing it to the two columns. Since the new intake needed new code, Tycho 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.