Please help support our team! $25 buys a motor, $50 buys a new battery, $150 adds controllers and sensors, $500 pays tournament fees, $750 upgrades our drivetrain

Iron Reign

Welcome to Iron Reign at Dallas ISD's Science and Engineering Magnet

Articles by section: engineering

Finishing the Chassis

29 Apr 2018

Finishing the Chassis By Kenna and Janavi

Task: Build a Chassis

We have been working on this chassis, on and off, for over three months. Just about every part of it has been built, disassembled, and rebuilt more than twice. In out last post, we had thought the wheels were ready to go. However, various parts had been put on backwards or were unusable so we had to do everything over again. Once we had rebuilt, we realized that there were even more issues. So we fixed those and built them again. Both of us could probably assemble wheels, motors, and chains in our sleep.
Now that the robot has wheels, we started on attaching the REV expansion hub and battery. The chassis is square, but has an asymmetrical structure of tetrix bars. Attaching the battery was the simple part since previous version of the robot had a 3D-printed battery holder that would be screwed on. After a short search, we found it in a box of 3D-printed parts whose prime was long over. There was no way to effectively place the expansion hub on the tetrix rails. Instead, we attached a thin plank of wood to two parallel bars, drilled a couple holes, and screwed the hub on.
Overall, it is a very no-frills chassis. We had to cut most of the side shields off because they were becoming more of an obstruction than an aid. Though it was a pain to build and rebuild every aspect of the chassis, we gained a lot of building experience out of one robot. We chose a relatively difficult design to built for the first time but, in the end, it was functional and that's all we can really ask for.

Next Steps

Though the physical robot has been built, it has no code. Both of us will be learning how to program a basic pushbot.

UIL 2018

18 May 2018

UIL 2018 By Abhi, Karina, Evan, Janavi, Austin, Justin, and Shaggy

Task: Attend the 2018 UIL Robotics Competition

Background

For those who don't know, UIL Robotics is the premier state robotics competition for Texas. Iron Reign has been a beta-testing partner since its inception, and this year was the event's first year as a full-fledged program.

To participate in UIL, a team must win at a Regional level, and have a good overall showing. This year, since we got 2nd Inspire at Regionals and 3rd Inspire at Oklahoma Regionals, we were a shoo-in for an invitation. Being a state event, the DISD STEM Dept. supported us through transportation, food, and lodging along with other DISD teams such as Mechanicats.

The Night Before

As with all Iron Reign tournaments, we stayed up way longer than we should have. But, unlike other times, we had a purpose: to help fellow teams.

We assisted the other DISD team, Mechanicats with programming and driver practice. In particular, they didn't have a working autonomous to begin with. But, with our half-field and glut of programmers, we helped them create a basic autonomous for the next day. As well, we collaborated on their TeleOp to make it more driver-friendly.

The Day Of

We walked into the tournament, tired, but excited for the last tournament of the season, led by our two robots, Kraken and C.A.R.T. BOT. Kraken is our Relic Recovery robot; a tank on wheels with specially cut aluminium sideplates and our proprietary REVolution system. So, it got plenty of looks. Then, we also brought the newest addition to the Iron Reign family: CART BOT. CART BOT is the automated corpse of our robot cart. For the past month, we've been tearing it down, replacing its wheels, motorizing it, adding a power source, and so much more. It tops out at 20 MPH and can carry 300 lbs without blinking an eye. Naturally, we thought UIL was the perfect place to bring it out.

Since UIL is the last tournament of the season and has no real consequences, we use it as a trial field for next year's changes. First, we had Evan lead our pit crew team as practice for next year. As well, we used the competition to practice driving for next year as well as improve our scouting strategies after worlds.

One of the best things about UIL is the ability to really interact with other Texas-area teams that we normally wouldn't see until Supers. A lot of the teams came over to see our robot, which is kind of understandable because it's probably the best robot we'll ever build. But, we had a suprising number of teams come up to talk to us about our Engineering Journal, including people who had already seen our journal online and wanted to talk about it to us in person (Vitruvian Voltage).

Robot Performance

Even though we enjoy UIL, its never our best competition of the year. Some of this is due to exhaustion; we tend to run out of steam by then, but it can also be attributed to that UIL is a robot-game intensive event, and Iron Reign tends to focus more on awards. So, we tend to comparatively underperform as compared to a theoretical Iron Reign standin.

We started off the day amazingly, as one of the chains on the robot snapped for the first time in the season. However, we still managed to win the match as we were carried by our partner. Somehow, we managed to do decently in the next four matches. This wasn't entirely due to luck, it was just that we had more competition experience than some of the other teams due to Worlds, and were able to perform more effectively.

Luckily, our scouting paid off, and we were chosen as the first pick of the #1 alliance. We won our first final match, but then lost the next two due to "alliance unreliability," meaning that the gremlins inside of our robot started acting up

The UIL Difference

Unlike FTC, UIL puts much less of an emphasis on judging. First, there aren't any presentations: everything is done at the pit. In addition, UIL judges are FRC first, and FTC second, so they weren't aware of many differences between the two. Finally, the awards mean nothing, and UIL realizes this, so all of the awards are "funny" awards.

Next Steps

This was the last competition of the season, so now Iron Reign will go into Funding, Outreach, and Recruitment mode for a while for the next season, but keep track of our blog to see what we'll do next. Relic Recovery '17-'18, signing off.

Swerve Drive Experiment

02 Jun 2018

Swerve Drive Experiment By Abhi

Task: Consider a Swerve Drive base

During the entire season of Relic Recovery, we saw many robots both in and outside our region that had a swerve drive. As Iron Reign, we never considered a swerve drive in the past but seeing all the robots, I wanted to see if it was maybe possible. One motivation was that I didn't like how slow mechanums were. Swerves generally use traction wheels and create a faster speed than usually can be found with mechanum. Also, it seemed as if swerve could provide the mobility neccessary that a mechanum drive provided. This is why I wanted to consider the possibility of a swerve drive and why I did more investigation.

I first came across the PRINT swerve for FTC by team 9773. They had a very detailed explanation of all the parts and assebly tools. After reading into it more, I decided that the system they created wasn't the best. First, the final cost of the drive train was very expensive; we did not have a very high budget despite help from our sponsors. If this drive train didn't work for some reason after playing with it over the summer or if the chassis didn't make sense to use in Rover Ruckus, we would have almost no money for an alternate drive train since we wanted to presearve Kraken. Also, they parts used by 9773 invovled X-rail rather than extrusion rail from REV. This would cause problems in the future as we wold need to redesign the REVolution system for X-rail. In the end, I decided this was not worth it to pursue.

After further investigation, I found a chassis by team 9048. The swerve they developed looked like a more feasible option. By using REV rail and many of the parts we had, I thought this would be a possible prototype for Iron Reign. Because they didn't have a parts list, we had the find the rough estimate of cost from the REV and Andymark websites. Upon further analysis, we realized that the cost, though cheaper than the chassis of 9773, would still be a considerable chunk of our budget. But I am still motivated to find a way to make this happen.

Next Steps

Possibly scavenge for parts in the house and Robodojo to make swerve modules.

Swerve Drive Prototype

09 Jun 2018

Swerve Drive Prototype By Abhi and Christian

Task: Build a Swerve Drive base

During the discussion about swerve drive, Imperial robotics, our sister team, was also interested in the designs. Since we needed to conserve resources and prototype, I worked with Christian and another member of Imperial to prototype a drive train.

Due to the limited resources. we decided to use Tetrix parts since we had an abundance of those. We decided to make the swerve such that a servo would turn a swerve module and the motors would be attached directly to the wheels. This system would be mounted to a square base. We decided to go ahead and make the base.

Immediatly we noticed it was very feeble. The servos were working very hard to turn the heavy module and the motors had trouble staying aligned. Also, programming the train was also a challenge. After experimenting further, the base even broke. This was a moment of realization. Not only was swerve expensive and complicated, we also would need to replace a module really quickly at competition which needed more resources and an immaculate design. With all these considerations, I ultimately decided that swerve wasn't worth it to use as a drive chassis.

Next Steps

Wait until Rover Ruckus starts so that we can think of a new chassis.

Position Tracking

18 Jul 2018

Position Tracking By Abhi

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

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

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

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

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

Next Steps

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

Chassis Flyer

22 Jul 2018

Chassis Flyer By Ethan

Kraken

This is Iron Reign’s world-championship robot from last season. The basic rundown is this:

  • Weight - 42 lbs
  • Size - 18x17.8x17.5 inches
  • Drive - Mecanum
  • Main parts kit - REV

Iron Reign uses two design processes in conjunction with each other to create efficient and reliable parts. First, we use the Kaizen design process, also used in industrial corporations such as Toyota. The philosophy behind Kaizen is the idea of continual improvement, that there is always some modification to each system on our robot that will make it more efficient or more reliable. As well, design competitions are a focal point of Iron Reign’s design process. In these design competitions, team members choose their favored designs that all complete some field challenge, and build them individually. Upon completion of each mechanism, the designs are tested against each other, considering weight, maneuverability, reliability, and efficiency.

An example of these design processes working in conjunction is the process of designing our cryptobox intake system. One person had the idea to build an arm-style grabber seen on many current competition robots. His design, however, included shorter arms for space’s sake and a more compact lift system than normal. The second person decided to build a unique conveyor-belt system which used friction to hold blocks in space and move them vertically. Through the competition, we determined that the prior design was more efficient and took up less space than the latter, so we settled on his design, adding in a linear slide for lifting at the end of the process. Then, Kaizen comes in. Through firsthand experience in scrimmages, we learned that the grabber system isn’t as reliable as we thought when first testing. So, we have designed a new grabber system that moves like the arms did previously, but also rotate with soft spikes attached to hold blocks with friction better without damaging them.

As this soft-spike system ceased to perform to our expectations, we looked to other mechanisms to pick up and deliver blocks effectively. We created a new grabber that still used the rotating systems of the soft-spike, but instead, we used custom 3D printed “octopuckers” which had a much tighter grip on the glyphs. As well, inside the gripper, we created a custom “lift” made out of NinjaFlex so that the blocks could be moved up and down internally in the gripper, eliminating our need for stacking.

Later, we further improved upon the grabber design, attaching it to a conveyor belt so that we could move glyphs all across our robot in order to score higher, using our REVolution system. This is the most ambitious use of our REVolution system yet, and we strongly encourage the reading judges to view it at the pits.

BigWheel

The main purpose of this robot is to see if larger wheels will give us an advantage in the competition. Right now, we’re guessing that the competition field will have debris, and we hope that the large wheels will perform better in this environment.

  • Size: ~18x18 in
  • Wheels - 8in large, regular omni wheels in front
  • Part System: Custom parts

Garchomp

For skill development we have newer builders replicating the chassis portion of our competition robot (Kraken). This one will not be weighed down by the additional upper structure of the competition robot and so should be a closer comparison in weight class to most of the other chassis designs under consideration here. Garchomp has a simplistic design and is nothing more than mechanums, rev rails, motors, sprockets, wires, and a rev hub. The large mechanums are held together using side plates from the 2017-18 competition season. These are geared up to neverest 40:1 motors.

  • Size: ~18x18 in
  • Wheels: Mechanum
  • Part System: REV
  • Motors: Neverest 40:1

Technicbots Chassis Project - July Meeting

22 Jul 2018

Technicbots Chassis Project - July Meeting By Kenna, Ethan, Charlotte, Karina, Shaggy, and Abhi

Task: Compare & Collaborate on Chassis

At Big Thought's offices in downtown Dallas, three teams met. Technicbots (Team 8565), EFFoRT (Team 8114), Schim Robotics (12900), and Iron Reign are all part of Technicbots' Chassis Project. The goal is for each team to create any number of chassis and improve their building skills by learning from the other teams.

The meeting began with an overview of all teams' progress. Each team presented their thought process and execution when creating each bot and discussed why/how everything was done. At the end, we all reviewed the rule changes for the 2018-19 season. Once all questions had been asked and answered, testing began.

Austin Lui of Technicbots gets their chassis ready for testing.

Using leftover tiles from last season, we set up a small field in Big Thought's blue room. Technicbots provided a ramp to do enhanced testing with. All teams plan on testing:

  • Forward speed
  • 3 second turn
  • Up/Down ramp
  • Balancing stone
  • Weight-pulling
  • Straight line drift
  • 90/180° turn offset

Connor Mihelic of EFFoRT adds some finishing touches.

We know from Google Analytics that our website has about 200 visitors a month but we rarely meet the people who read and use our blog posts. Today, we got to meet the mentors of Team 12900 from a middle school in Plano, TX. When they and their students were starting out as a team, they utilized our tutorials and journal. Apparently their teams members are avid followers of our team, which was very meaningful to hear. Some non-FTC friends visited as well and were introduced to cartbot.


Terri and Grant Richards of Schim Robotics.

Next Steps

Using what we learned from the other teams, we will begin to improve all of our chassis. Most of them are at varying levels of completion so now we want to concentrate on getting all of them to the same level of functionality. Garchomp is, notably, the most behind so he will be getting the most attention from here on out.

Replay Autonomous

28 Jul 2018

Replay Autonomous By Arjun

Task: Design a program to record and replay a driver run

One of the difficulties in writing an autonomous program is the long development cycle. We have to unplug the robot controller, plug it into a computer, make a few changes to the code, recompile and download the code, and then retest our program. All this must be done over and over again, until the autonomous is perfected. Each autonomous takes ~4 hours to write and tune. Over the entire season, we spend over 40 hours working on autonomous programs.

One possible solution for this is to record a driver running through the autonomous, and then replay it. I used this solution on my previous robotics team. Since we had no access to a field, we had to write our entire autonomous at a competition. After some brainstorming, we decided to write a program to record our driver as he ran through our autonomous routine and then execute it during a match. It worked very well, and got us a few extra points each match.

Using this program, writing an autonomous program is reduced to a matter of minutes. We just need to run through our autonomous routine a few times until weare happy with it, and then take the data from the console and paste it into our program. Then we recompile the program and run it.

There are two parts to our replay program. One part (a Tele-op Opmode) records the driver's motions and outputs it into the Android console. The next part (an Autonomous Opmode) reads in that data, and turns it into a working autonomous program.

Next Steps

Our current replay program requires one recompilation. While it is very quick, one possible next step is to save the autonomous data straight into the phone's internal memory, so that we do not have to recompile the program. This could further reduce the time required to create an autonomous.

One more next step could be a way to easily edit the autonomous. The output data is just a big list of numbers, and it is very difficult to edit it. If we need to tune the autonomous due to wear and tear on the robot, it is difficult to do so without rerecording. If we can figure out a mechanism for editing the generated autonomous, we can further reduce the time we spend creating autonomous programs.

C.A.R.T. Bot Summer Project

12 Aug 2018

C.A.R.T. Bot Summer Project By Evan, Abhi, and Janavi

Task: Enhance our robot-building skills

At Iron Reign, we hate to waste the summer since it’s a great time to get all the ridiculous builds out of the way. Thus, we created C.A.R.T. Bot (Carry All our Robotics Tools). Our constant companion these last few seasons has been our trusty Rubbermaid utility cart which has been beaten and abused, competition after competition, as it carried all our tools and robots. Because of all of this, we decided it was time to show the cart a little love, and in typical Iron Reign fashion, we went all out and turned it into a robot.

Our first step was to switch out the back wheels on it to elf-sized bicycle wheels, allowing us to take on the mightiest of curbs and motorize it. To attach the wheels, a four foot or so cylinder of threaded steel was inserted in holes on either side of the cart. Two slots were cut out in the bottom for the wheels and they were eventually slid on, but not after 3D printed mounts for sprockets were attached to the wheels, enabling us to gear them in a one to one ratio with the sprocket attached to the motors, which consisted of two SIM motors commonly found on FRC robots.

Before we used SIM motors, we attempted to power the cart using two Tetrix motors which were geared for speed but, due to load, barely moved at all. Besides a lack of power, they also tended to come out of alignment, causing a terrible noise and causing the cart to come to a stall. This was quickly scrapped. To mount the motors, we used two pieces of aluminum bars and bolted them to the motors, then screwed them to the floor of the cart, aligned with the wheels. We chained them together and got about powering the system. We got two 12-volt batteries and chained them in parallel so as to not overload the system, and hooked them up to a REV hub. Then, we ran them through a switch and breaker combination. We connected the motors to the rev hub and once we had it all powered up, we put some code on it and decided to take it for a spin.

It worked surprisingly well, so we went back in and put the finishing touches on the base of Cart Bot, mainly attaching the top back on so we could put stuff on top of it, and cutting holes for switches and wires to run through, to make it as slick as possible. We added a power distribution station to assist with the charging and distribute current to any device we decided to charge on the cart. We will eventually hook this up to our new and improved battery box we plan on making in the few spare moments we’ll have this season, just a quick quality of life improvement to make future competitions go smoothly.

Next Steps

Our cart box isn’t done yet, as we intend to make a mount for a solar panel, which we will be able to charge the cart during the downtime in competitions (only if there’s a good window we can park it next to). The cart wasn’t just about having a cool new and improved cart that we don’t have to push (which it is), it also was a test of our engineering skills, taking things that never should have been and putting them together to make something that we will utilize every competition. We learned so much during this experience, I for one learned how to wire something with two batteries as not to destroy the system, as for everyone else, I can’t speak for all but I think we learned a very important lesson on the dangers of electricity, mainly from the height of the sparks from an accidental short that happened along the way. Despite this, the cart came out great and moves smoother than I ever could have hoped. The thing is a real blast and has provided a lot of fun for the whole team, because yes, it is rideable. We predict the speed it’s set at is only a fifth of its full potential speed, and since it already goes a tad on the fast end we don't intend to boost it anymore while there’s a rider on it. Overall, the project was a success, and I’m personally very proud of my work as I’m certain everyone else is too. Come to see it at our table, I really think it’s worth it.

Garchomp Part 2

18 Aug 2018

Garchomp Part 2 By Janavi and Kenna

Task: Build the Chassis

So, we thought we finished but we were wrong, oh so wrong. As you saw in our last post, we thought our chassis was functional. However, after leaving it alone for over a week, Garchomp decided that it didn't want to work any more and 3 out of 4 of the chains came off. First, Kenna and I sat and cried.

Then we started to diagnose the problem. We noticed that the old tetrix rails we were using had dents in them, which caused the motors to shift, therefore causing the chains to come off the gears.

We decided to replace the tetrix rails. First we loosened all of the screws on the current bar, carefully slid it out, and replaced it with new bars. This solved one of many problems that we had somehow missed when building our chassis. After fixing all of the chains and confirming that each of them were individually working, we re-attached all of the cables to the robot and ran the code. We discovered that not all of the wheels were running at the same speed because our robot kept on moving in circles. After checking that the motors were working, we discovered that it was our encoder cabels that were plugged in wrong. But finally... After fixing that, and after many, many hours of trying to fix the chassis, we finished! Now, I think, we can safely say our chassis is complete.

Next Steps

We will try out more tests on the robot and make sure that it is up to par with our past robots.

BigWheel CAD

21 Aug 2018

BigWheel CAD By Ethan

Task: Create a mockup for BigWheel

We've been working on a design for the chassis workshop for quite a while now. We already presented it at the first meeting, and now we need to work on the other components of our presentation: the weight testing, torque calculations, speed testing, and finally, a chassis model. To do the last one, we made a simple model in PTC Creo.

Rover Ruckus Brainstorming & Initial Thoughts

08 Sep 2018

Rover Ruckus Brainstorming & Initial Thoughts By Ethan, Charlotte, Kenna, Evan, Abhi, Arjun, Karina, and Justin

Task: Come up with ideas for the 2018-19 season

So, today was the first meeting in the Rover Ruckus season! On top of that, we had our first round of new recruits (20!). So, it was an extremely hectic session, but we came up with a lot of new ideas.

Building

  • A One-way Intake System
  • This suggestion uses a plastic flap to "trap" game elements inside it, similar to the lid of a soda cup. You can put marbles through the straw-hole, but you can't easily get them back out.
  • Crater Bracing
  • In the past, we've had center-of-balance issues with our robot. To counteract this, we plan to attach shaped braces to our robot such that it can hold on to the walls and not tip over.
  • Extendable Arm + Silicone Grip
  • This one is simple - a linear slide arm attached to a motor so that it can pick up game elements and rotate. We fear, however, that many teams will adopt this strategy, so we probably won't do it. One unique part of our design would be the silicone grips, so that the "claws" can firmly grasp the silver and gold.
  • Binder-ring Hanger
  • When we did Res-Q, we dropped our robot more times than we'd like to admit. To prevent that, we're designing an interlocking mechanism that the robot can use to hang. It'll have an indent and a corresponding recess that resists lateral force by nature of the indent, but can be opened easily.
  • Passive Intake
  • Inspired by a few FRC Stronghold intake systems, we designed a passive intake. Attached to a weak spring, it would have the ability to move over game elements before falling back down to capture them. The benefit of this design is that we wouldn't have to use an extra motor for intake, but we risk controlling more than two elements at the same time.
  • Mechanum
  • Mechanum is our Ol' Faithful. We've used it for the past three years, so we're loath to abandon it for this year. It's still a good idea for this year, but strafing isn't as important, and we may need to emphasize speed instead. Plus, we're not exactly sure how to get over the crater walls with Mechanum.
  • Tape Measure
  • In Res-Q, we used a tape-measure system to pull our robot up, and we believe that we could do the same again this year. One issue is that our tape measure system is ridiculously heavy (~5 lbs) and with the new weight limits, this may not be ideal.
  • Mining
  • We're currently thinking of a "mining mechanism" that can score two glyphs at a time extremely quickly in exchange for not being able to climb. It'll involve a conveyor belt and a set of linear slides such that the objects in the crater can automatically be transferred to either the low-scoring zone or the higher one.

Journal

This year, we may switch to weekly summaries instead of meeting logs so that our journal is more reasonable for judges to read. In particular, we were inspired by team Nonstandard Deviation, which has an amazing engineering journal that we recommend the readers to check out.

Programming

Luckily, this year seems to have a more-easily programmed autonomous. We're working on some autonomous diagrams that we'll release in the next couple weeks. Aside from that, we have such a developed codebase that we don't really need to update it any further.

Next Steps

We're going to prototype these ideas in the coming weeks and develop our thoughts more thoroughly.

Testing Intakes

09 Sep 2018

Testing Intakes By Ethan, Evan, Aaron, and Freshmen as to be determined

Task: Design a prototype intake system

In our first practice, we brainstormed some intake and other robot ideas. To begin testing, we created a simple prototype of a one-way intake system. First, we attached two rubber bands to a length of wide PVC pipe. This worked pretty well, but the bands gave way a little too easily.

For our next prototype, we attached a piece of cardboard with slits to a cup approximately the size of a cube or block. It operates similarly to a soda cup lid with a straw hole. An object can go in, but the corners of the hole spring back so that it can't escape.

Next Steps

We probably won't go with this design - we'd have issues seperating the different kinds of game elements, and it may be too slow to feasibly use. But, its a first step and we'll see what happens.

Rover Ruckus Strategy

10 Sep 2018

Rover Ruckus Strategy By Ethan, Kenna, Charlotte, Evan, Abhi, Justin, Karina, and Aaron

Task: Determine the best Rover Ruckus strategies

Challenge Game Timing Points Level of Difficulty (1 - 3 [hard]) Priority Idea
Landing Autonomous 30 2 Medium
Claiming Autonomous 15 1 High
Parking Autonomous 10 1 High
Sampling Autonomous 25 2 Medium
Latching End Game 50 3 High
Robot in Crater End Game 15/25 1 High
Mining [Depot] Tele-Op 2 per item 1 High
Mining [Cargo] Tele-Op 5 per item 2 High

Brainstorming Two - Enter the Void

15 Sep 2018

Brainstorming Two - Enter the Void By Evan, Abhi, and Janavi

Task: Have a 2nd brainstorming session

Last week, we had a lot of new recruits show up for the FTC kickoff. In fact, a bit too many. Luckily for us, we either scared them off or they realized that they'd like to move to FRC. So, today's session was a bit more managable, and we were able to break down into some new building tasks.

Intake System 3 - TSA Bag Scanner

If any of y'all have ever been on an airplane, you've gone through airport security. This part of our robot is inspired by the bag-scanning machine, more specifically the part at the end with the spinning tubes. The basic design would be like a section of that track that flips over the top of the robot into the crater to intake field elements.

Intake System 4 - Big Clamp

This one is self-explanatory. Its a clamp, that when forced over a block or a cube, picks it up. It's not that accurate, but it's a good practice idea.

Lift 2 - Thruster

We want to make lifting our robot easy, and we're thinking of a slightly different way to do it. For our new lift idea, we're installing a vertical linear slide that forces the robot upwards so that we can reach the lander.

Next Steps

We're working on building these prototypes, and will create blog posts in the future detailing them.

Vision Discussion

15 Sep 2018

Vision Discussion By Arjun and Abhi

Task: Consider potential vision approaches for sampling

Part of this year’s game requires us to be able to detect the location of minerals on the field. The main use for this is in sampling. During autonomous, we need to move only the gold mineral, without touching the silver minerals in order to earn points for sampling. There are a few ways we could be able to detect the location of the gold mineral.

First, we could possibly use OpenCV to run transformations on the image that the camera sees. We would have to design an OpenCV pipeline which identifies yellow blobs, filters out those that aren’t minerals, and finds the centers of the blobs which are minerals. This is most likely the approach that many teams will use. The benefit of this approach is that it will be easy enough to write. However, it may not work in different lighting conditions that were not tested during the designing of the OpenCV pipeline.

Another approach is to use Convolutional Neural Networks (CNNs) to identify the location of the gold mineral. Convolutional Neural Networks are a class of machine learning algorithms that “learn” to find patterns in images by looking at large amounts of samples. In order to develop a CNN to identify minerals, we must take lots of photos of the sampling arrangement in different arrangements (and lighting conditions), and then manually label them. Then, the algorithm will “learn” how to differentiate gold minerals from other objects on the field. A CNN should be able to work in many different lighting conditions, however, it is also more difficult to write.

Next Steps

As of now, Iron Reign is going to attempt both methods of classification and compare their performance.

CNN Training

22 Sep 2018

CNN Training By Arjun and Abhi

Task: Capture training data for a Convolutional Neural Network

In order to train a Convolutional Neural Network, we need a whole bunch of training images. So we got out into the field, and took 125 photos of the sampling setup in different positions and angles. Our next step is to label the gold minerals in all of these photos, so that we can train a Convolutional Neural Network to label the gold minerals by learning from the patterns of the training data.

Next Steps

Next, we will go through and designate gold minerals. In addition, we must create a program to process these.

Chassis Brainstorming

22 Sep 2018

Chassis Brainstorming By Ethan and Evan

Task: Brainstorm chassis designs

At the moment, we've used the same chassis base for three years, a basic mechanum base with large wheels. However, we don't really want to do the same this year. At the time, it was impressive, and not many teams used mechanum wheels, but now, its a little overdone. So, as the true hipsters of FIRST Tech Challenge, we want to move onto something new and fresh.

Thus, we have BigWheel. We used this as a practice design, but we ended up really liking it. It starts off with two large rubber wheels, approx. eight inches in diameter, mounted at the back and sides of the robot. Then, we have two geared-up motors attached to the motors for extra torque and power. In the front, we have a single omniwheel that allows our robot to turn well.

Proposed Additions

First, we need to add an intake system. For this, we're considering a tension-loaded carwash that can spring out over the crater wall. It'll pull elements in and sort them through our intake using our seperator, which we will detail in a later post. Then, the robot will drive over to the lander and lift itself up. Since the main segment of the robot is based off of two wheels, we're attaching a telescoping slide that pushes off of the ground at the opposite end and pivots the front of the robot upwards. Then, the intake will launch upwards, depositing the elements in the launcher.

Next Steps

We need to create a proof-of-concept for this idea, and we'd like to create a 3D model before we go further.

Autonomous Path Planning

26 Sep 2018

Autonomous Path Planning By Abhi

Task: Map Autonomous paths

Ahhhhhhh! Rover Ruckus has been around for a while now and it's time to figure out our autonomous plans! This year's autonomous is a lot more hectic than last year's since there is the detaching from the lander component which can take an unknown amount of time right now. That cuts down the potential speed for the rest of the auto but only time will tell.

Until then, I can only dream of the potential autonomous paths our robot can take. First, we need to know some basic facts. One, the field is the exact same for both red and blue aliance, meaning I don't need to rewrite the code to act on the other side of the field. Second, we have to account for our alliance partner's autonomous if they have one and need to adapt to their path so we don't crash them. Third, we have to avoid the other alliance's bots to avoid penalties. There are no explicit boundaries this year for auto but if we somehow interrupt the opponent's auto we get heavily penalized. Now, with this in mind, lets look at these paths

This path plan is the simplest of all autonomi. I assume that our alliance partner has an autonomous and our robot only takes care of half the functions. It starts with a simple detaching from the lander, sampling the proper mineral, deploying the team marker, and parking in the crater. The reason I chose the opposite crater instead of the one on our nearside was that it was shorter distance and less chance to mess with our alliance partner. The issue with this plan is that it may interfere with the opponent's autnomous but if we drive strategically hugging the wall, we shouldn't have issues.

This path is also a "simple" path but is obviously complicated. The issue is that the team marker depot is not on the same side as the lander, forcing us to drive all the way down and back to park in the crater. I could also change this one to go to the opposite crater but that may interfere with our alliance partner's code.

This is one of the autonomi that assumes our alliance partners don't have an autonomous and is built for multifunctionality. The time restriction makes this autonomous unlikely but it is stil nice to plan out a path for it.

This is also one of the autonomi that assumes our alliance partners don't have an autonomous. This is the simpler one of the methods but still has the same restrictions

Next Steps

Although its great to think these paths will actually work out in the end, we might need to change them a lot. With potential collisions with alliance partners and opponents, we might need a drop down menu of sorts on the driver station that can let us put together a lot of different pieces so we can pick and choose the auto plan. Maybe we could even draw out the path in init. All this is only at the speculation stage right now.

Hanging Hook Prototype

26 Sep 2018

Hanging Hook Prototype By Abhi, Ethan, Justin, and Janavi

Task: Design a hook for pulling the robot on the lander

Today, we designed a basic prototype to hang the robot. We designed it, like all our parts, in PTC Creo, and printed it in nylon with ~80% infill. The hook was designed to minimize material used while also being strong enough not to stretch over time. First, we tested it by hanging ~20 lbs of material off of it for one minute. This worked, but a little too well. While the nylon piece remained undamaged, the metal bracket it was supported by bent at a ninety degree angle. So, we had to pursue further testing.

For our next test, we plan to hang a mass outside for a week. Dallas weather has been extreme lately, with a lot of rain, humidity, and heat. This will be the ultimate stress test; if one of our pieces can survive the outdoors, it can survive just about anything.

Next Steps

We're probably going to have to reprint this to be a bit more fitting for our robot, but its a good start and it works great so far.

BigWheel Chassis

29 Sep 2018

BigWheel Chassis By Evan

Task: Work on a possible chassis

We have our first qualifier coming up real soon, and to get ready we decided to get a robot into gameworthy shape. So far we have a few chassis from our work over the summer, so I decided to start on a neat little competition bot out of the one we called Bigwheel, named for its two big drive wheels in the back. The idea for this robot is that it has a collection system that extends into the crater, and folds up on top of the robot. It reaches in with the collection arm, and grabs the blocks/glyphs, drives backwards and flips vertically using the drive wheels as a point of rotation. Here’s a basic sketch of what that looks like.

The way this will be achieved is with a spring loaded lever connected to the omni wheel that makes up the holy trinity of wheels. So far I have pieced together the arm that reaches into the pit, which is powered by two NeverRest 60s and geared in a two to one ratio to significantly increase the torque. Between the two arm I plan for a horizontal beater bar to intake blocks and a slide attached to a servo to separate blocks and balls based on their size. The idea is to have a way of sorting based off of the physical shape rather than by digital sensing means. The more that can be done purely off the shape of the elements, the better.

Next Steps

So far, not much has gone into materializing the lever since this was made while the rest of the team was at an outreach event. Next week, the team will have to make some serious progress since there will be more hands to build. My hope is that the lever will come about soon, even if in its most infant stage, and that some semblance of a functioning robot can be game tested in the next few weeks, just in time for a scrimmage and potentially an early qualifier.

CNN Training Program

29 Sep 2018

CNN Training Program By Arjun and Abhi

Task: Designing a program to label training data for our Convolutional Neural Network

In order to use the captured training data, we need to label it by identifying the location of the gold mineral in it. We also need to normalize it by resizing the training images to a constant size, (320x240 pixels). While we could do this by hand, it would be a pain to do so. We would have to resize each individual picture, and then identify the coordinates of the center of the gold mineral, then create a file to store the resized image and coordinates.

Instead of doing this, we decided to write a program to do this for us. That way, we could just click on the gold mineral on the screen, and the program would do the resizing and coordinate-finding for us. Thus, the process of labeling the images will be much easier.

Throughout the weekend, I worked on this program. The end result is shown above.

Next Steps

Now that the program has been developed, we need to actually use it to label the training images we have. Then, we can train the Convolutional Neural Network.

Intake Sorter

29 Sep 2018

Intake Sorter By Abhi

Task: Design a sorter for the balls and blocks

We've been brainstorming ways to sort the gold and silver pieces, and here's our first one. It's a little bulky, but it's a start.

The way this works is that when this piece is mounted and both blocks and balls are run over it, the balls run down the top and don't fall in the collector, but the blocks fall in the holes. We modelled this design in PTC Creo, then printed it in ABS.

Next Steps

This is a little too bulky, so we're going to have to find a smaller and simpler way to sort game pieces, but it's a start. In the future, we're going to minimize this and probably move to a smaller sorting mechanism.

Designing Wheel Mounts

29 Sep 2018

Designing Wheel Mounts By Justin

Task: Create wheel mounts for our Mini-Mecanum chassis

Today, we modelled two possible designs for mini-mecanum wheel mounts. The purpose of the mounts is to hold a churro or hex shaft in place to mount mecanum wheels to. The first design was a 6cm by 6cm square with rounded edges that was 5mm thick. A hexagon was removed from the center to hold the churro that supports the mecanum wheel. This design, when printed on low infill, allowed the churro to rotate when enough force was applied. We modeled this design off of the wheel mounts on Kraken and Garchomp; the only differences are the size and material. Because we will be 3D printing these mounts, material efficiency is very important. This mount design used a lot of material to make a prototype, meaning a finished stable mount would need even more material to prevent the churro or hex shaft from slipping.

Taking these problems into account, we designed a different way to mount the wheels. The new version can mount underneath a REV Rail and hold the shaft or churro perpendicular to the rail. This design uses much less infill than the previous one because of how small the mount is, and because the REV Rail also acts as support to prevent the churro or shaft from spinning. The mount also allows the mini-mecanum wheels to be mounted as close to the frame as possible, which can help make the robot more compact. This design will allow us to easily mount mini-mecanums to our frame, while using minimal filament and taking up very little space.


Next Steps

We need to build the full mini-mecanum robot to judge whether these designs will fully work.

Designing the Corn Cob Aligner

05 Oct 2018

Designing the Corn Cob Aligner By Ethan and Abhi

Task: Design an aligner for the beater bar

The ice cube tray is 9 holes wide and each hole is 16.50mm wide and long. Using these measurements, we created an aligner that would cause the ice cube tray to roll into a cylinder.

However, this system has issues. First, we wanted the edges to still be mildly compliant, and this wheel filled out the edge rows to full depth, making them a little too tough. Plus, they made the silicone height too variable, so that we couldn't solely pick up the balls. So, we designed a second aligner with shorter spokes so that the edges would be fully compliant while still being held securely.

Next Steps

We need to finish up the corn-cob beater bar, but after that we'll be able to start testing.

Corn-Cob Intake

06 Oct 2018

Corn-Cob Intake By Ethan and Abhi

Task: Design an intake system unique for balls

Right now, we're working on a static-deposit system. The first part of this system is having an intake mechanism that passively differentiates the balls and cubes, reducing complexity of other parts of the design. Thus, we created the corn-cob intake.

First, we bought ice-cube trays. We wanted a compliant material that would grip the particles and be able to send them into a larger delivery mechanism. Last year, we looked at a silicone dish-drying tray as a compliant way to grip the blocks. This year, we're thinking about doing the same with the ice cube trays.

First, we designed a wheel which' spokes would fit into the holes on an ice cube tray, allowing the tray to stay static while still being compliant in a cylindrical shape. Then, we can put axle hubs through the center of the wheel, allowing us to mount the wheels on a hexagonal shaft. Then, we can mount a sprocket on that, allowing the bar to be rotated for intake.

Next Steps

We need to mount this on our robot and design a way to deliver the field elements. We're also going to go into more detail on the ice cube mounts in a later blog post.

Team Marker Fun

06 Oct 2018

Team Marker Fun By Karina

Task: Create the Team Marker

Last week, we decided to take up the task of creating the team marker, a simple project that would surely be overlooked, but can score a significant amount of points. We wanted the marker to be meaningful to the Iron Reign, but also follow the team marker rules. To start, we made a list of ideas, and considering how ridiculous we all are at Iron Reign, this is what we came up with:

Last season, Ducky (as seen in idea #4) brought Iron Reign good luck whenever the drivers squeezed them, and so we knew that we wanted to incorporate Ducky into whatever the final product would be. Some team members suggested fusing together multiple rubber duckies to fit the dimensions in the rule book. I had a better idea. I thought, "Why not put Ducky in a box?" However, trapping Ducky in a box would prevent us from ever squishing Ducky again (as long as they are trapped in the box). But then an even better idea came up: "Why not put Ducky in a cage?" And so we got to work making a cage for Ducky, one that we could release them from or reach in to whenever we need a squish for good luck.

We cut two pieces of 3.5 inch x 3.5 inch polycarb to serve as the ceiling and floor of the cage. Then we used 8 standoffs, in pairs of two at each corner of the cage, to serve as the bars. To not waste anymore standoffs, we used zipties as the cage bars. Additionally, the flexibility of the zipties allow us to squeeze Ducky out of the cage from inbetween the bars. In the end, Ducky looked like the most happy prisoner we've ever seen:

Next Steps

With the team marker built, we need to test how well it does its job (staying in one peice for the duration of a match hopefully). It's survived many nights now in the our coach's house, which is no small feat, with all the children running about and constantly misplacing things. Once we have an intake system working for the minerals, we will need to test how compatible it is with Ducky in a Cage. Lastly, we need to decorate Ducky's cage, including our team's number (6832).

Another Design Bites the Dust

06 Oct 2018

Another Design Bites the Dust By Ethan

Task: Discuss a new rule change

At one point, we were thinking about creating a "mining facility" robot that stays static within the crater and delivers the blocks into the mining depot. In our eyes, it was legal as it would hold as many blocks as possible inside the crater but only deliver two at a time outside. It would be super-effiecient as we would be able to stay within the crater, and not need to move.

However, fate has struck. Earlier this week, we recieved this message:

The rule limiting control/possession limits of minerals has been updated to indicate that robots may _temporarily_ hold more than 2 minerals in the crater, but must shed any excess over prior to performing any other gameplay activities (which would include scoring).
says that "Robots In a Crater are not eligible to Score Minerals". Per the definitions of "In" and "Crater", if _any_ portion of a Robot is in the vertical area above the crater (extending from the field walls to the outside edge of the Crater Rim), then scoring a Mineral results in a Major Penalty.
says that Robots may not obstruct another Robot's path of travel in the area between the Lander and a Crater for more than 5 seconds.

This means that we couldn't do a static mining facility as we cannot score within the crater. Since we'd have a portion of the robot always in the crater, the existence of our robot would be a major penalty.

Next Steps

So, we need to rethink our robot. We still want to create a semi-static robot, but we need to redesign the intake portion.

Labelling Minerals - CNN

06 Oct 2018

Labelling Minerals - CNN By Arjun and Abhi

Task: Label training images to train a Neural Network

Now that we have software to make labeling the training data easier, we have to actually use it to label the training images. Abhi and I split up our training data into two halves, and we each labeled one half. Then, when we had completed the labeling, we recombined the images. The images we labeled are publicly available at https://github.com/arjvik/RoverRuckusTrainingData.

Next Steps

We need to actually write a Convolutional Neural Network using the training data we collected.

Upgrading to FTC SDK version 4.0

06 Oct 2018

Upgrading to FTC SDK version 4.0 By Arjun

Task: Upgrade our code to the latest version of the FTC SDK

FTC recently released version 4.0 of their SDK, with initial support for external cameras, better PIDF motor control, improved wireless connectivity, new sensors, and other general improvements. Our code was based on last year's SDK version 3.7, so we needed to merge the new SDK with our repository.

The merge was slightly difficult, as there were some issues with the Gradle build system. However, after a little fiddling with the configuration, as well as fixing some errors in the internal code we changed, we were able to successfully merge the new SDK.

After the merge, we tested that our code still worked on Kraken, last year's competition robot. It ran with no problems.

Mining Base 2.0

07 Oct 2018

Mining Base 2.0 By Ethan

Task: Rethink our static robot idea

So, our dream this year is to create a static robot. Last week, we found out about a rule change that would prevent our mining robot from staying within the crater. Naturally, we found a way around this, leading us to the Mining Base 2.0.

The robot will be fixed under the lander's hooks, and have a horizonal and vertical linear slide attached to it. The horizontal linear slide would reach over the crater walls and pick up the silver balls, and shoot them up towards the lander. On the lander, our vertical linear slide would create a backboard that would allow the balls to fall into the lander. This wouldn't violate the rules as we wouldn't be in the crater.

Next Steps

We need to start on the designs of this robot, but to do this, we first need to create a working chassis.

BigWheel+

13 Oct 2018

BigWheel+ By Evan

Task: Continue work on BigWheel

Since the last time we have discussed Bigwheel, the robot has gone through a few major changes. First and foremost, it now has a flipper arm. Since the robot itself is the lift mechanism, we had to put a lot of work into the design of the flipper. Right now it is a 10 inch REV rail attached to two of the largest REV gears you can buy, with a custom 3D printed mount housing an omni wheel pair. Right now it’s turned by two pairs of the smallest REV gears you can buy creating a 3:25 gear ratio. It’s a bit odd, but it increases torque which is what we’re going for, the philosophy being that it’s better to be smooth than to be quick, as a quick robot is weaker and less controllable. On top of the flipper, we’ve added extra supports on the arm mounts, as when we went to the Hendricks scrimmage, we found that the two sides were out of alignment, and one was bending more forward than the other, making the arm bend unevenly to one side and throwing the whole robot out of alignment. The next step is to strengthen the arm itself, as the two sides have a tendency to want to do their own things, mainly the side with the intake motor mounted to it. Since the supports have been put in though, Bigwheel has been functioning much better, and the arm no longer flops to one side. General wire management has also taken place, as previously the wires went every which way and created an infuriating mess that had the potential to get caught in the gears. Personally I’ve noticed that we’re a tad out of touch with gears right now, none of our other robots have sported them to much degree. We’ve been really in touch with sprockets though, since they’ve featured heavily in our designs the past two years. That’s just an observation, and since my first awareness of this, I’ve seen our gear savvy grow.

Next Steps

Bigwheel was built on a bit of a shabby base, mostly being made of a piece of polycarb and some aluminum bars, and not giving much in terms of change. We’ve cut here and there, drilled a few holes, unattached and re-attached a couple of things, but in all it’s a very stiff robot, and doesn’t lend itself to fluidity of design. That’s why we plan on making a second version of this base, hopefully with thinner polycarb and more secure sides that have been welded together but can be removed more easily. The exact design is still being modeled, but we have a direction to jump off from, and I believe we can make that leap to a better robot.

Developing a CNN

13 Oct 2018

Developing a CNN By Arjun and Abhi

Task: Begin developing a Convolutional Neural Network using TensorFlow and Python

Now that we have gathered and labeled our training data, we began writing our Convolutional Neural Network. Since Abhi had used Python and TensorFlow to write a neural network in the past during his visit to MIT over the summer, we decided to do the same now.

After running our model, however, we noticed that it was not very accurate. Though we knew that was due to a bad choice of layer structure or hyperparameters, we were not able to determine the exact cause. (Hyperparameters are special parameters that need to be just right for the neural network to do well. If they are off, the neural network will not work well.) We fiddled with many of the hyperparameters and layer structure options, but were unable to fix the inaccuracy levels.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
model = Sequential()
model.add(Conv2D(64, activation="relu", input_shape=(n_rows, n_cols, 1), kernel_size=(3,3)))
model.add(Conv2D(32, activation="relu", kernel_size=(3,3)))
model.add(MaxPooling2D(pool_size=(8, 8), padding="same"))
model.add(Conv2D(8, activation="tanh", kernel_size=(3,3)))
model.add(MaxPooling2D(pool_size=(8, 8), padding="same"))
model.add(Conv2D(4, activation="relu", kernel_size=(3,3)))
model.add(Conv2D(4, activation="tanh", kernel_size=(1,1)))
model.add(Flatten())
model.add(Dense(2, activation="linear"))
model.summary()

Next Steps

We have not fully given up, though. We plan to keep attempting to improve the accuracy of our neural network model.

Mini Mechanum Chassis

19 Oct 2018

Mini Mechanum Chassis By Janavi and Justin

Task:

To everyone's suprise, Garchomp didn't pan out. But, practice makes perfect, and that’s what we are going to do: create new chassis until we find one that works!

When looking for inspiration for a new chassis, we found the mini mechanum wheels that we had been fiddling with last season but eventually scrapped in favor of the larger wheels that can be seen on Kraken.

In the past, Iron Reign has been infamous for creating robots that barely fit within the sizing cube by a fraction of an inch, so we decided to take a different approach this time. We built a low-laying 6" x 6" robot to counter our older approaches. However, this new design meant that many of the pieces we had created in previous competitions would be unusable due to the changes in size and structure. For example, the way we affixed the wheels to the frame didn't work, as the axles were too big and the wheels were too small to use with our former wheel mounts. As well, these new mini mechanum wheels came with almost frictionless bearings, but the axle that fit within these bearings was hexagonal, unlike the round ones we usually use.

Justin first designed the axle plate below to solve this, but discovered that it raised the robot off the ground quite a bit, something we wanted to avoid, and it was very flimsy since it was so far away from the frame. We discussed these issues with our coach and brainstormed various methods we could use to attach the axle the frame in a more secure way; he suggested that we use a pillow block design that would have one side of the axel touching the frame. That way we would save space, while also having a lower-lying robot. This design worked out beautifully, leading to the design we are currently using.

The axles and wheels aren’t the only new thing about our robot: we're using motors with a gear ratio of 20 rather than 40s and 60s. This is another reason that we wanted to create such a minute robot. The gear ratio combined with the size will make this robot a speed demon on the field and allows us to dart between the minerals and the depositing location quickly.

Next Steps

In the upcoming weeks we will continue to tinker with this chassis design by adding a linear side and our gathering mechanism, and hopefully, we will be able to demonstrate it at the scrimmage next week.

Rewriting CNN

20 Oct 2018

Rewriting CNN By Arjun and Abhi

Task: Begin rewriting the Convolutional Neural Network using Java and DL4J

While we were using Python and TensorFlow to train our convolutional neural network, we decided to attempt writing this in Java, as the code for our robot is entirely in Java, and before we can use our neural network, it must be written in java.

We also decided to try using DL4J, a competing library to TensorFlow, to write our neural network, to determine if it was easier to write a neural network using DL4J or TensorFlow. We found that both DL4J and TensorFlow were similarly easy to use, and while each had a different style, code written using both were equally easy to read and maintain.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
java
		//Download dataset
		DataDownloader downloader = new DataDownloader();
		File rootDir = downloader.downloadFilesFromGit("https://github.com/arjvik/RoverRuckusTrainingData.git", "data/RoverRuckusTrainingData", "TrainingData");
		
		//Read in dataset
		DataSetIterator iterator = new CustomDataSetIterator(rootDir, 1);
		
		//Normalization
		DataNormalization scaler = new ImagePreProcessingScaler(0, 1);
		scaler.fit(iterator);
		iterator.setPreProcessor(scaler);
		
		//Read in test dataset
		DataSetIterator testIterator = new CustomDataSetIterator(new File(rootDir, "Test"), 1);
			
		//Test Normalization
		DataNormalization testScaler = new ImagePreProcessingScaler(0, 1);
		testScaler.fit(testIterator);
		testIterator.setPreProcessor(testScaler);
		
		//Layer Configuration
		MultiLayerConfiguration conf = new NeuralNetConfiguration.Builder()
				.seed(SEED)
				.l2(0.005)
				.weightInit(WeightInit.XAVIER)
				.list()
				.layer(0, new ConvolutionLayer.Builder()
						.nIn(1)
						.kernelSize(3, 3)
						.stride(1, 1)
						.activation(Activation.RELU)
						.build())
				.layer(1, new ConvolutionLayer.Builder()
						.nIn(1)
						.kernelSize(3, 3)
						.stride(1, 1)
						.activation(Activation.RELU)
						.build())
				/* ...more layer code... */
				.build();

Next Steps

We still need to attempt to to fix the inaccuracy in the predictions made by our neural network.

Intake Update

20 Oct 2018

Intake Update By Ethan, Abhi, Justin, and Kenna

Task: Update the intake for the new robot size

So, we created the corn-cob intake a few weeks ago. Unfortunately, it was a little too big for the Minichassis, so we had to downsize. Thus comes Intake Two. Continuing our history of using kitchen materials to create robot parts, we attached two silicone oven mitts to a beater bar equipped with the Iron Reign signature REVolution system. Then, we attached a REV Core Hex Motor to the design, then added a 2:1 gear ratio to increase the speed, as the motor wasn't exactly what we wanted.

Then, we attached our new passive sorting system. Instead of being the old, bulky sorting system, the new system is just three side-by-side bars spaces 68mm apart with tilted wings to move blocks upwards. The 68mm number is important - the size of a gold block. This allows the balls to be struck and fly upwards into the intake while sliding the blocks through the system.

Next Steps

We need to attach this to the robot to test intake. The most likely way this'll be done is through a pivot over the walls of the crater from the top of the robot.

DISD Scrimmage at Hedrick MS

27 Oct 2018

DISD Scrimmage at Hedrick MS By Charlotte, Janavi, Ethan, Evan, Justin, Karina, and Abhi

Task: Compete at the Hedrick MS DISD Scrimmage

Today, Iron Reign competed in the DISD scrimmage at Hedrick Middle School. This was the first scrimmage of the year, so experienced teams and rookie teams alike struggled to get a working robot on the field. We go to this scrimmage every year, and it helps us gague just how much needs to be done to have a qualifier-ready robot. This year, that is a lot. We actually had two robots relatively pieced together, a main chassis and a backup, but we didn't account for many different problems that rendered them unoperable. In the case of the backup robot, the linear slide fell apart easily and was threaded so that it could only extend, and not retract. In the case of the actual robot, most of our problems stemmed from the intake system. Since we built it so recently, we were never able to write any code until in the final few days of preparation. We weren't able to debug the code and it has caused many complications in our robot. Our drive train also had many issues which we have been trying to fix and fine tune.

Due to these many issues, we did not compete for most of our matches. We spent a lot of time working on our bots and talking to other teams about their progress and plans for the season, as well as see all of the interesting ideas they have put together in fruition in a game setting. In the match we did compete in, we did very badly due to driver error and mechanical errors in the drive train.

BigWheel Arm

02 Nov 2018

BigWheel Arm By Evan

Task: Design an arm for BigWheel

Bigwheel’s arm is going tied with the lifter arm as the most integral part of the robot. It wouldn’t work without it. Since our scrimmage, we have learned how to make this arm much more efficient, starting with some supports. The arm was made of two disconnected Tetrix rails scavenged from the bottom of our scrap bin, lending itself to weakness and instability, much like a country that recently won its independence. The worst part was how the two sides of the arm would be out of sync with one another, creating a twist in the arm that caused it to drive in an odd path. Since then it has been stabilized with cross beam REV rails that have significantly straightened out the robot. Why we hadn’t done it before is a mystery to me, and something we should have recognized as an issue sooner, but hindsight is 20/20 and since we can’t change the past we can only vow never to make the mistake again. Always support your attachments. The next upgrade on the arm is going to be the box to hold the minerals. Right now it’s made of cardboard off an amazon box, and it kind of sucks. I can say this because I cut it out and made it. The plan is to make it out of polycarb but we only came to this conclusion after a bit of debate. The reason polycarb was not our immediate solution is because it’s unfortunately quite heavy, and instead the first thing we came to think of was thin plywood and duct tape. Thin slices of plywood would be taped together to create a fabric like box that still had form. This idea still lent itself to breakage, and we next went to a design using a thin plastic sheet, the same kind of plastic that is used inside milk cartons. The only issue is that it’s super weak and doesn’t form well, so we would have to build a frame for it, much like the plywood and tape. Finally we came to the polycarb and decided upon that. So far it works as a nice way to hold the blocks as we transport them into the lander.

Next Steps

Right now we’re toying around with the idea of an arm that not only flips out but also extends using a gear and tooth track made from Tetrix parts of days gone by. The reason for this is to gain a little extra height that we were lacking before in the robot and a little more flexibility when we grab minerals from the crater. To do this I had to take apart the arm from our first ever FTC robot, and use the toothed track and gear plus the extra long tetrix bars to create the slides. So far the slides are surprisingly smooth and we have high hopes for the future of the arm.

Pose BigWheel

03 Nov 2018

Pose BigWheel By Abhi

Task: New Pose for Big Wheel robot

Historically, Iron Reign has used a class called "Pose" to control all the hardware mapping of our robot instead of putting it directly into our opmodes. This has created cleaner code and smoother integration with our crazy functions. However, we used the same Pose for the past two years since both had an almost identical drive base. Since there wasn't a viable differential drive Pose in the past, I made a new one using inspiration from the mecanum one.

We start with initializing everything including PID constants and all our motors/sensors. I will skip all this for this post since this is repetitive in all team code.

In the init, I made the hardware mapping for the motors we have on BigWheel right now. Other functions will come in later.

Here is where a lot of the work happens. This is what allows our robot to move accurately using IMU and encoder values.

There are a lot of other methods beyond these but there is just a lot of technical math behind them with trigonometry. I won't bore you with the details but our code is open source so you can find the neccesary help if you just look at our github!

Torque

03 Nov 2018

Torque By Karina

Task: Calculate the torque needed to lift chassis

After seeing how well the robots that could latch onto the lander performed at the scrimmage, Iron Reign knew that we had to be able to score these points. We originally tried lifting with a linear slide system on MiniMech, but it was not strong or sturdy enough for the small chassis, and would definitely not be a functional system on BigWheel in time for competition. And so we thought why not use this opportunity to *flex* on the other teams with an alternative design? An idea was born.

We decided we would latch onto the lander using the same arm used for intake, and then pivot the main body of BigWheel up off of the ground about an "elbow joint", much like how humans do bicep curls. To do so, our motors would need to have enough torque to be able to lift the loaded chassis off the ground once the arm hooked onto the latch. First, we measured the mass of BigWheel. Then we found where the center of mass was located. The distance from the pivot point to the center of mass became our lever arm, also known as the radius.

Calculating torque required knowing the forces acting on BigWheel at its center of mass. In this case, there was only the force due to gravity (F = mg). Before we could plug BigWheel's mass into the equation, we converted to units of kilograms (kg), and then used the value to find the newtons of force that would oppose the upward motion:

Finally, we plugged the force and radius into the torque equation:

Next Steps

The next step is to test which gear train will output this torque value based on the motors used and the gear ratio.

RIP CNN

04 Nov 2018

RIP CNN By Abhi

Task: Farewell Iron Reign's CNN

So FTC released a new software update that added Tensorflow support. With it came a class that implemented Tensorflow to autonomously detect both minerals. This meant all our progress was undercut by a software update. The silver lining is that we have done enough research into how CNN's work and it will allow us to understand the mind of the FTC app better. We're still gonna need an F in the chat tho.

Next Steps

We gotta figure out how to use the autonomous detection of the minerals to path plan.

Lift

04 Nov 2018

Lift By Janavi

Task: Design a lift for MiniChassis

So we need to lift the robot. There are multiple ways to accomplish this including a linear slide or an arm; we decided to begin experimenting with the linear slide method. I created a linear slide using Tetrix bars and the standard linear slide kit. Instead of putting nuts with bolts on the end as stops I took an aluminum plate with holes on it and had Max, one of our mentors, assist me by cutting the plate into small squares to screw into the end of the bar. We planned to test out the tetrix bar at the scrimmage we attended, but two things went wrong. First, I forgot to make the linear slide stronger by attaching side plates, and we only brought 3 of the four needed REV hubs to be able to use both our MiniChassis and our big wheel chassis. Since BigWheel required more testing, we decided to give up one of our two REV hubs so that BigWheel would be able to get some much-needed testing. Since we were not running mini chassis I attempted to strengthen to linear slide by adding side plates but was unsucessful due to a lack of parts availiable. We relized that if we were to include a linear slide on our robot it would require too much maintaince and would soon become too finicky.

Next Steps

In the end we decided to scrap the standard linear slide in place of a geared linear slide with a different bar. By usingthe geared slide we would eliminate the need to deal with complicated string and would need to simply reverse the difrection of the motor to move it up and down. Working with the previous linear slide though showed us that it was not the best implementation to use with our robot design and allowed us to try better more efficient variations.

BigWheel Upgrades

05 Nov 2018

BigWheel Upgrades By Evan

Task: Get BigWheel ready for the tournament

Sunday and Monday were good days to be an intake system for big wheel. Mounts were built to attach both types of intake to the rack and pinion tetrix slide and a new way of mounting the arm to the chassis. The original corn on the cob intake was sized down for the system, and stitched to a REV rail design as opposed to the tetrix and REV rail hybrid it was before. It has yet to be chained up but that should happen soon. The idea is that since it’s attached to the rack and pinion track, it reaches high enough for the robot to put the minerals in the lander. The only issue is that it that we have yet to find an ideal gear ratio for the arm, but we imagine that what we have now will suffice (a small 12 tooth gear to a large 86 tooth gear for that extra torque). We have to work on the actual mount that the arm will attach to, the only issue being space and that there may not be enough of it without either switching to bevel gears or chaining the motors to the small 12 tooth gears. We have yet to decide exactly what we’ll do, but since we may not have the bevel gears we want, it might end up being a chained mechanism. Another addition that is simple enough but quite necessary, is a tail for the robot to be able to stop itself from flipping backwards, something that is a very real danger of the design. It will probably be made of polycarb with aluminum or steel support on either side, just incase the polycarb is not enough to support the push of the robot. Part of this process will involve some code tuning so that the robot stops itself, but the tail is necessary as a preventative measure.

Next Steps

There’s still a lot of stuff we will have to do to prepare the robot physically for the competition this saturday, but I believe it will get done.

Code Post-Mortem after Conrad Qualifier

10 Nov 2018

Code Post-Mortem after Conrad Qualifier By Arjun and Abhi

Task: Analyze code failiure at Conrad Qualifier

Iron Reign has been working hard on our robot, and we expected to do fairly well at our last competition. However, we couldn't be more wrong, since our robot came last place in the robot game. While we did win the Inspire award, we still would like to make some changes to ensure that this doesn't happen again.

Our autonomous plan was fairly simple: perform sampling, deploy the team marker, then drive to the crater to park. We planned to use the built-in TensorFlow object detection for our sampling, and thus assumed that our autonomous would be fairly easy. Unfortunately, we didn't begin writing the code for our autonomous until the Thursday before our competition.

On Thursday, I worked on writing a class to help us detect the location of the gold mineral using the built-in TensorFlow object detection. While testing this class, I noticed that it produced an error rather than outputting the location of the gold mineral. This error was not diagnosed until the morning of the competition.

On Friday, Abhi worked on writing code for the driving part of the autonomous. He wrote three different autonomous routines, one for each position of the gold mineral. His code did not select the routine to use yet, leaving it open for us to connect to the TensorFlow class to determine which position the gold mineral was.

On Saturday, the morning of the competition, we debugged the TensorFlow class that was written earlier and determined the cause of the error. We had misused the API for the TensorFlow object detection, and after we corrected that, our code didn't spit out an error anymore. Then, we realized that TensorFlow only worked at certain camera positions and angles. We then had to adjust the position of our robot on the field, so that we could

Our code failiure was mostly due to the fact that we only started working on our autonomous two days before the competition. Next time, we plan to make our autonomous an integral part of our robot, and focus on it much earlier. I plan to fix our autonomous sometime soon, well before our next competition, so that we do not have to come to our next competition without a working autonomous.

Next Steps:

Spend more time focusing on code and autonomous, to ensure that we enter our next competition with a fully working autonomous.

Materials Testing Planning

16 Nov 2018

Materials Testing Planning By Ethan

Task: Design a lab to test nylon properties

So, Iron Reign is used to using off-the-shelf materials on our robot: silicone oven gloves, ice cube trays, nylon 3D-printed parts, and more. But, we've never actually done a thorough investigation on the durability and efficacy of these parts. Because of this, we've had some high-profile failures: our silicone blocks breaking on contact with beacons in RES-Q, our nylon sprockets wearing down in Relic Recovery, our gears grinding down in Rover Ruckus. We're a little sick of it. So, we're going to do an investigation of various materials to find their real properties.

Nylon Testing

A majority of the 3D-printed parts on BigWheel are nylon - we find it to be stronger than any other material save ABS, but much less prone to shattering. Still, we still deal with a substaintial amount of wear, and we want to find the conditions under which damage happens.

So, to start, we are printing a 4.5" x 1.5" block with a thickness of 4mm with an infill of 60% out of nylon. We chose these values as our average part is about 4mm thick, and our high-strength nylon pieces are about 60% infill. Then, we are going to test it under a variety on conditions meant to simulate stressful operation. As well, we're going to measure other values such as coefficient of friction using angle calculations.

Silicone Testing

Similarily, we use the silicone oven mitts on our intake; we find that they grip the particles pretty well. The main thing that we want to test is the amount of energy they have while rotating and then the amount of energy they lose upon collision. We plan to test this through videoanalysis. In addition, we wish to test the coefficient of friction of the mitts to see if a better material can be found.

Next Steps

We are going to perform these labs so that we can compare the constants we recieve to commonly accepted constants to test our accuracy.

Chassis Mark Two Planning

20 Nov 2018

Chassis Mark Two Planning By Ethan

Task: Plan a new BigWheel chassis

Our next tournament is a while away, in about two months. So, we have a little bit of time to redesign. And, our current chassis has plenty of faults.

Our original BigWheel base.

First and foremost, our chassis was built for a testing competition, not to be a full fledged competition robot. As such, it's a little lacking in features that would be normal on such a robot such as mounting points for other components, durability, and free space. So, we need a redesign.

We're starting from the ground up; our current base is a square metal frame with a polycarb bottom. While this is a good start, it has some issues: the base seems to be a little wobbly due to the polycarb, there's only one level of construction, so our motor mounts, REV hubs, and supports compete for space, and we have to add all the counting points ourselves. This being Iron Reign, the logical solution to this is maximalism.

The main way to prevent the wobbliness is by replacing the polycarb with something a bit sturdier, as well as not having everything simply bolted together. Thus, we're going to dive headfirst into the next step - welding. We plan to cut a base out of aluminium as well as four side plates to create a dish-like shape. Then, we plan to TIG weld these plates together (TIG welding uses a tungsten electrode in contact with two seperate metal plates in combination with a filler metal that melts and joins the two plates together).

Basic design for the newest version of BigWheel.

Next Steps

We plan to cut the aluminium next week, and TIG weld the pieces together the week after that. We're beginning to train a few of our members on TIG welding and we already have some of the safety equipment to do so.

Friction Coefficient and Energy

01 Dec 2018

Friction Coefficient and Energy By Ethan

Task: Measure the coeffiencent of friction of our oven mitt intake

So, we wanted to measure various constants of materials on our robot. Earlier this season, we found that a nylon-mitt collision on our intake sapped the rotational energy of our intake. But, that was just a build error, easily fixable. But now, we plan to measure the energy lost from particle-mitt collisions, and the first part of this is to find the coeffiencent of friction of the silicone mitts.

To measure the coeffiencent of friction, we first had to simplify an equation to determine what values to measure.

From these calculations, we determined that the only factor to measure to determine the coefficient of friction between blocks and the mitts is the angle of incline. Therefore, we created a simple device to measure the angle at which slippage begins to occur.

The angle was about 27 degrees, so the coefficient of friction is equal to arctan(27)=0.44. This is a pretty good coefficient of friction, meaning that the intake is very effiecent in bringing the particles in, but it also means that the intake loses more energy on collision.

Next Steps

We need to measure further constants such as stretch and wear of nylon. To do so, we're printing a simple testing nylon block.

Nylon Strength Test

02 Dec 2018

Nylon Strength Test By Ethan

Task: Determine what circumstances wear down nylon

We've had some issues with our nylon sprockets, mainly through excessive wear and tear. So, we want to test what circumstances cause what deformation.

Linear Deformation

This one was simple. We printed this block with 60% infill (the highest infill we tend to use), measured its length (3.75") and hung one end from our deck. On the other end, we inserted a bar and had a member (182 lbs) hang on it, then we measured its new length (3.8"). Thus, the constant of deformation is [weight]/[change in length] = 650 kg/cm. This demonstrates that linear transformation isn't Iron Reign's issue, as the highest possible weight put on any nylon piece on our robot is ~27 lbs/12.25kg.

However, there is other damage. After testing, we found internal damage in the nylon from where it was hanging.

Next Steps

Next, we need to test the rotational damage that nylon incurs through friction. We plan to design a simple rotational sprocket and run it on a motor for a set amount of time and measure the wear to determine wear per unit time.

Nylon Materials Testing 2 - Wear and Tear

07 Dec 2018

Nylon Materials Testing 2 - Wear and Tear By Ethan

Task: Test the amount of wear on a moving nylon part over time

So, here's the next article in the material testing series. After our last tournament, we noticed several 3D-printed sprockets that had worn down significantly. So, we wanted to meaure how much wear one of our nylon sprockets takes per second.

First, we printed out a model of one of the REV sprockets, using the STEP file here. We printed it with ~45% infill, our average for sprockets and other parts. Then, we attached a REV Core motor to an extrusion, then mounted the nylon sprocket on the other side. Then, we measured the length on one of the teeth. We ran the motor for 1:05:45, and then measured the length afterwards.

So, the tooth length before was 5.3mm, and after, it was 5.23mm, for a difference of 0.07mm. Then, we ran the system for 1:05:45. This results in a wear rate of 1.77*10^5 mm/sec. So, given that we use our robot for about an hour, cumulatively, in a tournament, 0.0638mm, or 1.2% of the sprocket. This is enough to be noticeable and indicates that we should keep extra sprockets at tournaments so that we can do a quick replacement if needed.

Next Steps

We plan to perform more materials testing in the future; in particular, we'd like to determine the wear rate of the regular REV sprockets as well, but this requires a more rigorous expiriment.

Contact Us

E-Mail: ironreignrobotics@gmail.com Website: In the address bar