Articles by tag: mechanical

Articles by tag: mechanical

    Robot On a Hoverboard - Try 1

    Robot On a Hoverboard - Try 1 By Caitlin, Max, Tycho, Darshan, Omar, Evan, Ethan, and Jayesh

    Task: Try to drive the hoverboard with the competition bot

    In the middle of Saturday's event we decided it would be a GREAT idea to put the competiton robot on the hoverboard and try to drive it around. Theoretically if we got it centered correctly it could only drive forward and backwards. We could extend the cliff hanger to move our center of gravity forwards, and then retract to bring it back.

    Reflections

    We were able to make the board speed up by tilting the cliff-hanger out and extending it, but we couldn't control it enough to completely stop it or keep it steady. We believe that the robot frame isn't completely rigid and is torquing at the center, making the robot unbalanced left/right. Since it's only slightly off balance we can't really adjust it by hand. It seems doomed to drive in circles forever. We tried to turn the robot to a correct alignment by driving with the main treads a little, but the change in center of gravity was too dramatic. The robot quickly veered into Evan, who was sitting nearby.

    Hoverboards and PID

    Hoverboards and PID By Caitlin, Omar, Darshan, Tycho, and Max

    Task: Continue with the Hoverboard and tweak PID

    After the long weekend last week, today was a reasonably relaxed practice. We decided that we could work on anything, as long we stayed focused. The two main foci were the -Robot on a Hoverboard- and fine tuning our PID for autonomous.

    Reflections

    We experimented with balancing the robot more evenly on the hoverboard to keep it on a straight path and then getting creative with the controls to speed it up. We found that we could effectively rocket it forward by extending and angling the cliff climber while flipping the block dispenser forward at the same time. While it was easy to send the robot forward, there was little we could do to recover outside of just pushing it back by hand. This created a game of hot potato as we passed the robot around from person to person, but was ended rather abruptly when it careened into the table.

    If we're going to get our autonomous functional for UIL then we need to fix our PID. We used the parts of the current autonomous demo to check the straight line gyro drive, and went from barely correcting, to crazy oscillations, to a good level in between. This took a decent amount of tweaking for K-proportional, and when we felt we were straddling the line between too much and too little correction we messed around with K-Derivative to be better prepared. After the initial gyro guided line the robot is programmed to do a 45 degree turn towards the beacon, and then fine tune its angle using color blob. The color blob detection seemed to track the selected color accurately, outlining the area in neon green, but for some reason didn't turn to aim at it. If anything it turned away from the beacon. We found a mistake in our error calculation, where leftover error wasn't properly cleared before the guided turn, that we believe caused at least some of the odd turning behavior.

    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.

    First Official Practice of the Season

    First Official Practice of the Season By Omar, Caitlin, Jayesh, Darshan, Ethan, Evan, Janavi, Max, and Tycho

    Task: Pull ourselves together for the new season

    At this practice, our goal was to get everybody familliar with this year's game, Velocity Vortex, and to brainstorm some ideas for this year's robot. Some organization also needed to be done in terms of parts (everything is everywhere and nowhere at the same time) and also in terms of this year's meeting structure. Last year was somewhat unfocused and chaotic and we need to get a better grasp of things.

    Reflections

    We managed to get a decent amount done today. Jayesh described our new meeting structure: we begin with a group discussion of what we'd be doing that day, then would separate and work, then around mid-meeting we'd eat some food and while doing so talk about what we've done, then separate again and continue working. Hopefully we're able to stick to this schedule.

    Jayesh and I also made a small table of possible wheel base options, such as using either Mecanum wheels or returning to the omni-wheels of yore. Evan and Darshan disassembled the mountain from last year's field and put it outside near our tent. We discussed several things, such as some interesting rules about how our robot will not be able to grasp onto any part of the center structure, and therefore could not stop it from rotating by doing so. We also discussed League play, and it's advantages/disadvantages. A large weakness of ours is lack of testing, and these League meets would definitely let us get some more practice in before the big qualifiers.

    Evan and Tycho both tried to explain designs for this year's robot that they'd thought up. Evan, by using some loopholes in the rules, designed the premise for a robot that would park itself right in front of our Corner Vortex, having with it at least two Particles, and would cycle them through the Vortex over and over again. Even though each Particle that goes through would only be worth a point, Evan argues that these will add up since his design will be quick at cycling. Tycho's idea focuses instead on the Center Vortex; he explained that his robot would have ball intakes on opposite sides of the robot so direction wouldn't matter (unlike last year's robot, Geb), and would have some sort of mechanism in the center of the robot that would shoot Particles up and through the Center Vortex. So far, most of us are aligning more on Tycho's side of the design wars, but Evan's persistence might win us over. Who knows.

    One other thing Jayesh, Evan and I decided on (question mark?) is a general plan for this year's autonomous that we 100% need to work on to be successful: the robot will hit the beacon buttons, then move to the center of the field, hit the cap ball out of the center, then park in the center (not neccessarily fully). We thought this was realistically possible given the time that we have until competition.

    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.

    2016-2017 Robot

    2016-2017 Robot By Ethan, Omar, Jayesh, Evan, Tycho, and Max

    Task: To build the robot for the 2016-2017 season

    As much as we love our robot from last season, Geb, we need a robot that is better able to fit the season's challenges. Our needs for this year are:

    • Manuverable and fast
    • Able to play defensively
    • Can support attachments such as an intake system
    For manuverability, we decided to use mecanum wheels.

    The cool thing about these wheels is that they enable you to strafe side to side, instead of turning. However, they do require different coding than our normal wheels.


    To play defensively against other robots, our robot must be decently sized without falling into the same trap of last year, where are robot barely fit into the sizing limits, and in one tournament, did not at all. As well, it must be heavy enough to not be pushed out of the way by other robots, especially due to our strategy this year (blog post on that later).

    Finally, our robot must support attachments. Currently, we are considering a launcher, and intake system, a circulation system, and a yoga ball-lifter. And, to accommodate all of these attachments, our basic frame is a re-enforced square frame.

    Experimenting with a Mecanum wheel chassis! #ftcrobotics #omgrobots

    A photo posted by Iron Reign Robotics FTC (@team6832) on


    However, we are still experiencing problems, such as our chain falling off due to the supports moving toward each other. As well, we probably need to find a better place to put our motor controller and battery.

    Reflections

    We need to get our robot effectively finished within the next month if we are to go to the Arkansas tournament. As well, we need to add supports to our robot to stop the chain issue. Within the next two weeks, we should have made one or two attachments.

    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.

    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.

    A Thank-You to Tetrix

    A Thank-You to Tetrix By Ethan and Evan

    Task: To create a thank-you video to Pitsco

    We entered a contest to win a pack of Tetrix parts on Twitter, and we won! You can also enter the contest by following these instructions

    So, as a thank-you to them, we made this:

    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.

    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.

    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.

    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.

    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.

    Backups and Shields

    Backups and Shields By Caitlin, Omar, Max, and Tycho

    Task: Build a backup flywheel track and remount side shields

    Previously, our side shields were zip-tied through 4 bolt holes on tetrix pieces per side, and we had taken one off to reach our drive system. When putting it back on to fine tune autonomous we took the time to cut out space for a wrench and bolt it on. The holes were already the correct size, we just had to line them up with the mounting position.

    Omar spent a good amount of time inspecting our current track in order to replicate it accurately. Unfortunately, it took him a few tries to get it. We want to have a second copy available in competition if we get hit around too hard or something snaps. One weakness of our previous catapult design was that the bowl broke in a way we couldn't repair, andwe don't want to be in that situation again.

    Reflections

    While It was easy to mount one side of a shield, the other proved to be difficult. The pre-existing drill holes almost lined up, zip ties had enough give, but the bolts definitely didn't. We had to widen the area but it's much more secure now. When we got it to workon the left shield, we clipped the ties holding the right side up and did the same thing

    Inspire Award

    Inspire Award By Tycho, Jayesh, Caitlin, Omar, Max, Darshan, Evan, Ethan, Janavi, and Charlotte

    1st Place at North Texas Regional Championship

    Iron Reign members left to right are Ethan Helfman (Build, Communications), Janavi Chada (Programming, Communications), Tycho Virani (Programming Lead, Main Driver), Jayesh Sharma (Business Lead, Build, Communications), Darshan Patel (Build), Caitlin Rogers (Communications Lead, Logistics, Business) and Charlotte Leakey (Programming, Logistics), with Evan Daane (from BTW, Build, Photography) in repose. Not shown: Max Virani (Design Lead, Programming), Omar Ramirez (Build Lead) and Rohit Shankar (Programming).

    Wow, we did it. I mean, we were going for it, but wow - we did it! Out of 118 teams competing in our region, we got 1st Place Inspire (Top Award) at our regional championship! We finally earned the coveted Inspire Banner. We've been building toward this for 7 years! Ever since we started as an FLL team.

    Our total awards included Inspire 1st, Finalist Alliance 2nd, Motivate 2nd, Connect 3rd, Innovate 3rd.

    Not going to Disney World yet

    We are now qualified for the Texas State UIL Robotics Championship and the 12 State South Super Regionals. And we are preparing with the goal of making it to the World Championship. We have an extended season and while some of us have been to super regionals before, this is the first time the whole team gets to go. Our coffers are empty, we need a whole new round of fundraising to keep up the progress for the extended season. We need your help! Please consider contributing to support our extended season and help us represent North Texas at Supers.

    In case you don't know how the game works, it's broken into a 30 second autonomous phase followed by a 2 minute driver controlled period. Two alliances of two robots each compete in each match. Here is our division winning match with alliance mates Technibots. Autonomous:

    And Tele-Op:

    Editing the Reveal Video

    Editing the Reveal Video By Evan and Omar

    One man's harrowing journey through copyright free music lists

    The Robot Reveal video is underway. With most of the filming done, the sky grows dark and the day ends. A night time of editing sets in for the poor miscreant who volunteered for the task. Huddled in the corner with a raw fish and his precious computer, the boy opens premiere pro to begin. All is right with the world. The five hour long dramatic saga of trying to figure out the dang code to his Adobe account is through and the password has been changed. He knew he never should have let his family use his student status for a discount. But it's over and he's decided to leave it in his past. Time to edit...

    So the editing for the Robot Reveal video has begun and so far it's gone fine. I had an easy time getting it all in and except one crash(everything was recovered) it's been good. There won't be too much extreme editing to do. Nothing mind bending. Mostly cutting and arranging. The big problem now is finding a song to use that fits the video. I'm having trouble finding something pleasant sounding, fitting, un-copyrighted, and that lines up with the length of the video. I've been listening to a ridiculous amount of un-copyrighted music. An insane amount. It's not copyrighted for a reason. No man or woman or animal or object should have to endure this. The un-copyrighted playlists should be used as an enhanced interrogation technique and then banned by the UN for being a violation of basic human rights. Its all a bunch of extremely similar songs that should either be in the background of a shirtless guys vlog or the basis for an art students performance piece. A few outliers are some EDM and elevator music and I don't know which one makes me want to pour hot wax into my ear holes more. I'm listening to a song right as I'm writing this. I think it's the background music for the most generic cooking channel on YouTube ever. One way or another I'm going to get this done. Maybe I've made a few hyperboles throughout the post but the robot reveal will be finished. I've saved all the music I think could work into a playlist that I'll let everyone give a listen to at tomorrow's meeting. Now I must return to my hell.

    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:

    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.

    Strategies for Relic Recovery

    Strategies for Relic Recovery By Evan, Austin, and Abhi

    Getting Started

    We began our thinking process by isolating the various mechanisms which we believed would provide equally beneficial amounts of control, speed between intake of glyphs, and low weight to keep our robot agile. Preliminary discussions devolved into partially heated arguments about various designs implications and fesability. While "faction" may be to strong of a word for the groups that formed to prototype the various designs, there was an easily noticable division of team effort. The design that was finished first was the repurposed tank drive of an older robot (geb) mounted horizontally on to a sheet of plywood, with the intention of having the treads grip and accelerate the blocks through a channel. We discovered that not only would it move glyphs up an incline, but it could grab them and move them completely vertically: