Iron Reign

Welcome to Iron Reign

Iron Reign @ Science and Engineering Magnet

Team 6832 Members:

  • Dylan Chorley
  • Evan Daane
  • Trace Hamada
  • Ethan Helfman
  • Alisa Lin
  • Omar Ramirez
  • Caitlin Rogers
  • Jayesh Sharma
  • Darshan Patel
  • Maximillian Virani
  • Tycho Virani

Articles by section: engineering

Argos the Chromovore

29 Jun 2015
Argos the Chromovore By Max and Tycho

Task: Get some pre-season experience with Android controlled robots

We've been experimenting with Android controlled robots while we wait for our ModernRobotics modules. Argos is a chromovore - it seeks an identified color using OpenCV4Android machine vision processing. It tries to maintain a given distance from the colored object and follow it around. It's built using the IOIO-OTG for low level interface with the motor control electronics. The ZTE Speed phone is mounted on pan/tilt hardware from ServoCity and Actobotics. The chassis is a MaxStone 1/5 scale rock crawler by Exceed RC.


We are starting to learn a bit about using Android devices for controlling robotics. There seems to be a lot of potential here, but we are mostly finding that we have more and more to learn. Machine vision is not easy, and we don't even know if it will be useful in next season's challenge. We are also learning about the location and orientation APIs. Unfortunately it seems the ZTE Speed doesn't have an actual gyro in it, so we'll have to continue using an external gyro for heading management.

We don't plan to publish (meaning document and support) the source code. Our code is just a hack forcing two projects into one - plus you really want to build it from scratch to get a good idea of what is going on. It's pretty much a blend of the ColorBlobDetector sample that comes with OpenCV4Android, and the IOIOSimpleApp present in the IOIO Github project. Use the gradle branch for compatibility with Android Studio. But if you want to look at our implementation you can find it here.

Overview of new hardware and software

08 Aug 2015
Overview of new hardware and software By Max,Tycho,Caitlin,Alisa,Ethan,Trace

Task: Getting a first glimpse at the new motors and controllers with Imperial robotics

We continued our meeting at the Dallas Makerspace after the GitHub tutorial. We unpackaged the new motors and motor controllers for the first time and took out the phones to scan the hardware configuration. We added Anderson Power poles to some of the motors. Caitlin taught Alisa and Ethan how to crimp wires and attach the power poles.


Scanning the hardware configuration was very troublesome for us and the connections looked like a rat's nest and it was hard how it was going to fit together in a tidy bundle.

Back To Creo

29 Aug 2015
Back To Creo By Tycho

Task: Create preliminary designs for a new robot using a new build platform

Today I started making new designs for a competition robot based on extrusions and the new software platform.


I decided to make two different possible designs, one based on our robot that we had used for the past few years with 1 regular wheel on each side in between two omni wheels, and another based on our sister team's newer platform, which had one standard wheel on each corner. After a few hours of work and no saving, creo crashed and I lost all of my work. Moral of the story : save your work more often.

Field Navigation Speculation

05 Sep 2015
Field Navigation Speculation By Max

Task: Determine necessities of this year's field navigation code

Today was our very first meet of the year, and as such, not too much got done other than planning and experimentation. For the greater part of the meeting, I worked on concepts for an overhauled field navigation system (Mostly for autonomous, but possibly for tele-op as well). This would include the robot knowing where it is on the field when it starts, the field's and its own dimensions, the locations of potential obstacles, and even an approximation of how far the robot may have deviated from its planned path. The best bet so far is to make locations based on a Cartesian plane (like most graphs), with one corner of the field being the origin (0,0) and the other points being established based off of it. The picture above shows an estimated list of variables as required for the robot (as well as field dimensions). This is likely a minimum, as there will definitely be a rather complex system needed to show obstacles, including linking together groups of points and making sure that both the points themselves as well as the lines between them are avoided, but without making every obstacle point attach to one another in a spiderweb of confusion.


Although most of the team has taken several Java classes at school, this will undoubtedly be a challenge to develop. Since we also have a new physical system to work with, the development of the field control system will be time-consuming work. Regardless, with the new navigation challenge of having the field pre-loaded with debris every time, the development of the system will almost undoubtedly save time in the future that we would have spent on last year's process of fixing our autonomous by running it 5 times to work out tiny changes to single lines of code at a time, only to find more problems caused by the change. Since we know this alternative to the system all too well, At least incentives won't be a problem in getting started.

Designing Drive Trains

07 Sep 2015
Designing Drive Trains By Tycho

Task: Create preliminary designs for a new robot using a new build platform

After we got the new mechanum wheels, I had to start thinking about a new design that would be able to use them.


Not much progress was done on the design based on the mecanum wheels, but I remade part of the design based on our old robot from previous years. We will build one robot based on our proven omniwheel-drivewheel-omniwheel nacelle design, only using the REV extrusion building system being sold by Andymark. We will build a second robot using mecanum wheels. The plan is to see which robot works better and that will become our competition robot and the other will become our sparring partner. We think that our classic design will be better at pushing and resisting being pushed around. We also know it is very capable of accurate turning. But the mecanum robot will have more freedom of movement. Which should work better is probably dependent on what the challenge looks like when they release it. But we are also new to mecanum and probably won't have a rock solid implementation figured out right away.

Meeting After Game Reveal

13 Sep 2015
Meeting After Game Reveal By Dylan, Darshan, Alisa, Ethan, Evan, Caitlin, Tycho, Max, Trace

Task: Discuss robot design

Now that the game has been released, we as a group discussed the different amount of points per each possible game strategy that would give us the most ample amount of points during the given time limit. We also discussed the different ideas on the tracks and wheels that are possible for our design. The arm attachment was discussed for the grabbing of the highest mount of the mountain which would give us the most points.


In the future, we will probably test the different ideas we have brainstormed and discover which of these will probably be most efficient for us in our competition that will give us the lightest and most applicable design. In the following weeks, we will have obtained the color sensor and field pieces or items to practice with. This will lead us to reflect even more about what we have done today and what we have done in the weeks before.

Tank Drive Model

19 Sep 2015
Tank Drive Model By Tycho

Task: Design a new build platform more suited to this year's challenge

Since the robot game for this year came out about a week ago, we were thinking about which kind of drive system would work best for the challenge, which mostly involves climbing. Some of the concept we came up with were rocker bogies, rubber-banded tires and a tank drive with treads. Since we already had the preliminary design started for a tank drive, I started modeling that.


Throughout the early build of the tank drive's right nacelle, I used Creo to assist in the design of the robot, using the software to see how parts could fit together, and how they couldn't. For example, we were hoping to add an extra idler wheel into the tank drive between the motors, I found out through Creo that there was just barely not enough space to fit it.
I also came up with a way to connect both halves of the robot for when we build the left side of our tank drive, and modelled what that would look like when complete.

I hate tread inserts

19 Sep 2015
I Hate Tread Inserts By Omar

Task: Insert grips into alternating treads to boost traction of driving system

I am so done with these treads. For the past three hours I have worked to soak the treads and tread inserts in dish soap. *takes deep breath* The process is painstakingly slow and also literally painful. The process itself seems simple but after soaking both pieces the insert must be pushed in with a considerable amount of force. This is not user friendly and is not what the company who produces the inserts advertised as "ease of use". This process will be finished in a few meetings because it's ow and slow.


This tread insert reallllly needs to be effective given the trouble I've gone through. We don't think the Tetrix treads will be able to get up the mountain without this extra bit of grip. But if they still don't help - huuugge waste of time. At this rate it's averaging about 4 minutes per tread. And we have 100 rubber inserts across both tracks. Will do some tests with just one track when the motors are fully installed so we can decide whether to invest the time in the other track.


[Time Passes] We probably need a complete track drive (both nacelles) to properly test their ability to climb over the churros, so thought more about the problem and came up with some improvements. First we decided to use a lot more water to make it easier to get the slippery solution into the crevices of the inserts. We found a 10 to 1 mixture of water to dish soap was still very slippery.

We then decided to try controlling the temperature to shrink the rubber inserts and expand the treads. So we chilled some solution with ice and heated the other in the microwave. We are not sure if the chilled solution shrank the rubber, but it did make it much stiffer, making the initial push into the tread easier. The more important improvement was the heated solution - it definitely increased the gap temporarily, making it easier to slide the insert in. The hotter the better. We kept reheating to the point of discomfort because the tracks soaked up a lot of heat very quickly.

We also improved our technique. The chilled treads still go in only part way when pushing them into the hot tread. The rubber insert starts warming up quickly and the heat makes them even more squishy - so you can't push them in. But you can pull them in with very pointy needle-nose pliers. You have to get the pliers between tread and the insert - digging in pretty agressively. The inserts can take a surpising amount of abuse. We didn't tear a single one of them. It also helped that we had assembled the tracks before and weren't trying to do this with individual treads. One more piece of advice - pull the insert away from you so you don't stab yourself when you lose your grip.

Now the process went much faster. In a kind of assembly line, we can get one insert done every 30 seconds:

  • add an insert to the chilled solution while taking the previsously chilled one out
  • remove the track from the heated solution
  • shake the solution out
  • insert the cold tread from the far side toward you
  • dig under the rubber with the pliers
  • grab and pull the insert fully in as fast as you can
  • Repeat

We managed an 8x increase in assembly speed and will be able to mount both tracks at our next meet.

Post Kickoff

19 Sep 2015
Post Kickoff By Jayesh, Omar, Caitlin, Ethan, Alisa, Evan, Max, Tycho

Task: Build FTC field and begin tank tread mirror side

After the 2015 kickoff, Iron Reign conducted a meeting to construct our game field and also construct our mirror side for the tank treads. Taking turns on placing the grips on our treads, we managed to get a good portion of the grips placed as well. Construction of the field also commenced and the majority of the field is finished, providing an important recource for us in testing the robot for competition.


Field materials like the ramp gave us difficulty in assembling them because of confusions such as where to thread each screw. Watching the building videos on Andy Mark's website let us know how to solve most of these nuances. With the mirror side of the tank thread just about done, we can also start building on the main chassis and start discussing our main scoring mechanism.

Building the 2015 Field

19 Sep 2015
Building the 2015 Field By Evan, Dylan, Alisa, Trace, Ethan

Task: Cleaning and building the Field

Today we were charged with the task of building the FTC field. There was one problem. The tent we were setting it up in was in a state of decay. We cleaned out the area to make space while others put together the field. It was changed comletely from when it started. When cleaning we discovered many cool things like cassettes and floppy disks. The mat of the field was a little old but we're going to replace it once we get to the fine tuning of the robot. All in all it was a productice day.


We continued our journey and improved the team in a fun and appropriate way. The building of the field contributed to team bonding. Next week, we should be able to start practicing on the field.

sad robot

Building the Field - Part III

03 Oct 2015
Building the Field: Part III By Ethan, Trace, Alisa, and Evan

Task: Building the field for the third week in a row!

Today, for the third time, we worked on setting up the field. We finished the mountains and the climber setup. We made several mistakes along the way. Firstly, we screwed the mountain climber mounts in wrong, not one or two times, but three times. Then, we realized that the mountains couldn't even fit inside the tent and the wooden boundaries. So, we had to dissasemble it, rotate each board 45 degrees, and reassemble it. After everything was put back together, we tested the robot on the mountain. It was unable to climb the first section, and then, it failed miserably.

We have to go back to the drawing board on our robot design.


Today, we learned we still have a long way to go with the robot. Tomorrow, we should be able to finish the field and start testing on the mats.

Circle Time

10 Oct 2015
Circle Time By Jayesh, Ethan, Omar, Darshan, Evan

Task:Discuss multiple possible solutions to climb steep incline on field

We held a team meeting outside on the field discussing multiple possible solutions to the problem of the robot ascending to the top of the ramp. While we are already able to climb the ramp, the robot strafes significantly as it climbs above each rung on the ramp. This can be accounted for during the driver-controlled period, but the strafing can't be accounted for during autonomous, unless we have each side of the robot respond to the other's actions.


Having each side account for each other allows for error corrections and also greatly improves the strafing in the robot. Possible solutions included the use of two ultrasonic sensors on the bottom of the robot that detect the distance from the ground. As a side passes over a rung, the distance value changes and the other side adjusts until it reaches the same value. The use of an IMU (Inertial Measurement Unit) to detect differences between each side also fixes the strafing, but the IMU would detect the robot moving as one unit, compared to splitting the robot in half using the ultrasonic sensors. The difference between the two solutions is in efficiency and we will explore these and other options to ensure most success in the autonomous period.

Driving up the mountain - test 2

10 Oct 2015
Driving up the mountain - test 2 By Caitlin, Darshan, Jayesh, Omar, Max, Tycho, Evan

Task: Test how the condition of the mountain changes robot performance

After last week's fail we decided that we should change a couple of variables of the environment. The first and easiest to fix being the condition and cleanliness of the mountain ramp. Having dust on the ramp would severely lessen the friction holding the robot in place, so we wiped it down with glass cleaner and started up the robot.


Since the chassis is still in design flux, we went up the ramp both ways. Both were able to get onto the low zone and held their place when motors turned off. This was already a success in comparison to last week's practice. However, when attempting the mid zone, the orientation of the robot made a difference. When we drove up heavy side first, the robot was unable to go up the first bar. When we put the heavy motor controllers and batteries at the back and went up, the robot made it past the bar, but lost its balance soon after. We can't rely on the balance as attachments will definitely change the weight and center of mass.

After watching the robot fail going up battery side first, we believed that the battery holder was getting caught on the bar. after a closer look we saw that the plates that the batteries were resting on were just low enough and stcking out enough to get caught. if given a push then the robot kept driving up without any problem. This also meant that going down was impossible after driving up in the other orientation. The battery mount would just catch in that direction The battery mount was temporary anyways and after the strategy meeting (Jayesh's post) a new controller setup was started.

Arrangement and Rearrangement of Motor Controllers

10 Oct 2015
Arrangement and Rearrangement of Motor Controllers By Omar, Darshan

Task: Find better configuration of motor/servo controllers and power distribution module on the robot

Today, we tried to figure out the best possible way to stick all the motor controllers and the PDM together to minimize the amount of space they take up on the robot. Fitting the finished product into the gap on the back end of our robot would also be a bonus. We had previously thought of one way of doing it: When placed on the robot, this arrangement fit well and did not take up that much vertical space. However, the wires connecting everything were packed up inside and were ungainly, so we took it apart and started over. The next arrangement we came up with was this: (INSERT PICTURE HERE LATER) This one takes very little vertical space, but no longer fits inside the robot and is quite long.


We will continue experimenting with these different configurations, since our robot is nowhere near its final form. We might even have to disassemble the entire thing quite a few times in order to get it as good as it'll get for the competition. After further testing the current arrangement of the motor controllers and PDM, we'll decide whether we need to change it up again. Better arrangement will make debugging on the robot during code testing much easier, while also increasing overall organization of the apparati on the robot. To other teams looking into wire management, we suggest to choose an easy-to-reach system that can be easy to adjust to allow for accurate debugging. The system we use fits these guidlines and should be a good baseline for other times hoping to achieve the same type of system.

Gyro-IMU Case

11 Oct 2015
IMU Case By Tycho

Task: Make a 3D Printable case for the Adafruit BNO055 IMU

We're used to having gyros to help maintain heading, but we've never been fans of the Hitechnic gyro sensor. Now we have more options and the BNO055 looks pretty good. But our testing has been off robot so far and we need a way to securely attach the sensor to our robot which bounces around like crazy when climbing the mountains. So in PTC Creo, I'm designing a 3D printable case for this sensor that we can share with other teams. I decided to build a model of the sensor first, so I could play with it in an assembly with other tetrix parts while designing the case. The goal is to have a case that bolts securely to Tetrix channels, doesn't need special screws to hold the sensor in place, is strong enough and is easy to print with no overhangs.


The design I came up with is pretty simple - it's a box with a lid that clamps over the sensor and makes an air gap for the sensor components to sit in:

My first test print shows some issues:

  • The standoffs are not perfectly centered under the holes in the board. In one direction it was probably a measurement error. In the other direction I must have made a mistake with a centerline reference when I mirrored the holes on the sensor model.
  • For the same reason, the sensor is not centered in the air gap.
  • The pins on the standoffs took too much filing to get to the right size. I need to make them smaller or turn them into cones or get rid of them and just leave a hole for tiny screws.
  • It only has bolt holes for the Tetrix pattern (compatible with extrusions). Should probably add holes for the Actobotics pattern as well.
  • The bolt holes should be bigger so they don't have to be drilled out to proper size. They were sized correctly in the model but most 3D printers tend to spread filament into the gaps.
  • Should add some kind of strain relief for the sensor wires going back to the DCIM.
  • Fully enclosed, heating could be a problem. Might require venting the air gap or making room for a heat sink.

So while I was able to mount the sensor in the test print by breaking two standoffs and demo that at least it securely holds the sensor to a channel, I'm improving the design and should have an STL we can share with other teams by next week. I'll add an update to this post when it's ready.

Gyro-IMU Case V2

19 Oct 2015
IMU Case V2 By Tycho

Task: Improve our 3D Printable case for the Adafruit BNO055 IMU

Last week I designed a case for our IMU sensor in Creo and wrote up how it could be improved. I've fixed most of those issues and we are ready to share the results. There is one version with Tetrix hole spacing and another that works for Actobotics channels. Either can be used with aluminum extrusions though you might have to drill out the mounting holes depending on your bolt size.

You can download the STLs. The Creo models are available on request - just ask in the disqus below.


My first write-up showed a number of issues. Here's how those issues were addressed:

  • There were measurement errors. I guess I need to work on my caliper skills. This time I found a diagram of the board's designed dimensions that removed these errors.
  • I did make errors by not properly using centerlines for mirroring features in my sketches. Cleaned that up.
  • I made the pins on the standoffs smaller to reduce the time needed to clean them up for a proper fit. Now a minute of filing top layer sloppiness makes for a nice snap-on fit. The sensor presses right into place. We tried it with two different IMUs. This is optimized for our Ekocycle Cube, so might not be the right solution for other printers.
  • Added a separate set of print files for Actobotics mounting.
  • The bolt holes were widened so we don't have to drill them out for 6/32 bolts.
  • Added a strain relief column for the sensor wires going back to the DCIM. The column contains a groove to secure a ziptie.
  • We don't have good data on whether heat build up could become a problem.
  • This design is meant to be mounted to the underside of a structural beam if you want the sensor to maintain its standard notion of "up". You can always change that definition in code if you need to mount it with the wires coming out the top.

We hope this design proves useful and please let us know if you can think of any improvements.

Before Scrimmage basic tests

07 Nov 2015
Before Scrimmage basic tests By Caitlin, Tycho, Omar, Max, Darshan

Task: make sure the robot can run

There's a scrimmage next Saturday that we may or may not be going to based on Dallasisd technicalities with our team. Our goals for today were to get a basic autonomous going to dump climbers and maybe some mountain climbing tests. However, the controller apps needed to be updated and we got a lot of errors when connecting.


If the controller gives an error mentioning "USB UART" apparently the only fix is to completely restart the robot controller phone :0 It took us maybe 20 minutes to restart everything, but the robot is moving around. It feels like we have to do this at least every other practice.

Rocker Boogie Tank

07 Nov 2015
Rocker Boogie Tank By Trace

Task: Design and build a basic rocker boogie tank

A few weeks back, I designed a new chassis. It was a combination of the rocker bogey and a tank to make the rocker boogie tank! With the advantage of sturdiness from a tank and the ability to adjust to surfaces from the rocker boogie. This combination is unstoppable!!!


The task proved to be easy (just added tank treads to a rocker boogie) but worked. After I tested the prototype on a number of surfaces, it was able to move with ease.

Autonomous Code Part 1

08 Nov 2015
Coding for Autonomous Pilot Program By Tycho and Dylan

Task: Program Pilot Code

Our task was to begin programming for our first version of the Pilot class of the robot using other classes for our angle, position, and controller that we created. The controller class known as PID controller used part of the controller set given to us from the repository but was recalibrated to be in terms of time and independent of all else. This we need to integrate in our pilot class which we will use to tie all programs together for our autonomous program.


We still have a long way to go for our program and how we are going to use methods from the private class for the PID controller. We have a few ideas we should follow up on as well as test with our robot. With so many variables we need to make sure that we can have the ability to name each differently but also describe what each variable is describing. In reflection, we have done many of the methods for our pilot program and only need to add a few more so that the variables describing values of other classes changes when necessary. The main parts of the particular pilot program version one are complete and we should be done with the rest of our program next week.

Addition of Beater Bar to Robot

08 Nov 2015
Addition of Beater Bar to Robot By Omar, Ethan, Darshan, Caitlin

Task: Fix and alter robot to include sliding beater bar

Since the robot's last run, several fixes and adjustments had to be made in order to make the robot operational again. All we had to do was tighten a couple of bolts, so it wasn't that big of a deal. We'll probably have to do a quick check from now on to make sure nothing's falling off. Afterward, we set to using the same beater bar we used last year (the first version, at least) on our new robot to sweep up blocks/balls. The small plates on the front of each of the sides are meant to guide the beater bar's sliding off the robot when being deployed.

Next, we added sliding platforms on which the beater bar is attached so that we can deploy them. [INSERT PICTURE HERE] The mechanism slides back and forth, with the beater bar sliding off the chassis and dropping down to the appropriate height. No motors to run it have been connected yet.


This beater bar is the first step on our way to adding everything necessary to the robot's chassis to allow it to compete. It was somewhat difficult getting all the bolts to line up since we're using some parts from a different building system. With a scrimmage next week on Saturday, hopefully we can slap some motors on it to get it moving by then.

Writing Pose

09 Nov 2015
Writing Pose By Max and Eliot

Task: Create a rough draft of the code for the Pose class

Starting just a few weeks into the competition year, we thought up ideas for a system of classes to allow the robot to navigate to a location on the field on its own, including the Pose class, which we would use to keep tabs on where the robot was on the field at any particular time. With this, it would be possible to make a system where we could simply give a set of coordinates to a function in the code and the robot would work out a route on its own. This has limited use beyond the autonomous phase, but nevertheless would be useful in premade routines (such as automatically ascending the mountains at the press of a button in the End Phase). This code would also be recyclable for next year; two components would change - the specs for the robot and the locations of the obstacles - but unless the entire game takes a drastic turn next year, all of the rest of the code should apply just as it will this year.

In any case, we have been working on a skeleton for a few weeks, and Pose now has some functionality. In our amazing list of features, we have:

  • More variables than the human mind can perceive without flinching at the thought of perceiving so many variables
  • Memory of location, speed, angle, dimensions, and more
  • Three different constructor functions, two of which will likely never be used
  • Read and write functions, because of reasons
  • An update function for telling the class what we're doing
  • Odometry and trigonometry and Euler angles, oh my
  • Being almost useless until we make the partner classes that use Pose's info to navigate

double displacement = (((double)(ticksRight - ticksRightPrev)/ticksPerMeterRight) + ((double)(ticksLeft - ticksLeftPrev)/ticksPerMeterLeft))/2.0;
poseSpeed = displacement / (double)(currentTime - this.timeStamp)*1000000; //meters per second when ticks per meter is calibrated
timeStamp = currentTime;
ticksRightPrev = ticksRight;
ticksLeftPrev = ticksLeft;
double poseHeadingRad = Math.toRadians(poseHeading);
poseX += displacement * Math.cos(poseHeadingRad);
poseY += displacement * Math.sin(poseHeadingRad);


Since the robot itself isn't fully built (or fully designed, for that matter) we won't be able to fully finish the Pose code very soon, as the class relies on knowing the robot's dimensions, having access to sensors, etc. We can still improve on what we have now and code for what we plan to have on the finished robot, but final testing won't be possible for a while. We also have yet to tackle the two biggest challenges for the multi-class concept. The first of these will be figuring out a way to tell the robot where static obstacles (field elements) are in a way that human beings can understand. The second will be finding out how to get the robot to use what we've given it and actually figure out directions on its own; I can forsee problems with trying to account for errors like the robot stalling because it thinks it's in a wall, trying to take overly complicated routes, etc.

As it stands, the clearest path of action is to work on a way to model the field and obstacles, and then update Pose with robot specs once the design is finalized. Afterwards, we will use Pose and our obstacle-mapping code to design the navigator class. We are, however, keeping in mind that the tele-op code is as incomplete as the robot is. Coding the tele-op isn't as hard as this amalgamate of classes due to the fact that the tele-op only needs to be updated whenever we add a motor, and even then only a few lines of code are added at a time. Chances are, we work on Pose and its companion classes most of the time, and just make quick changes to the tele-op whenever necessary.

Starting up our Autonomous Code

14 Nov 2015
Starting up our Autonomous Code by Jayesh, Tycho, Max

Task: Get started on autonomous coding

We spent some of the time at the scrimmage today starting up our autonomous code in android studio. The main basis of our coding was put around climbing the ramp, which is our main function of our robot without the rest of the hardware in place. The main point of the code was put around PID and Pose, as PID helped give us our position on the field and Pose helped in giving our heading.


The coding differences between this year and last year are mostly in the mainframe of the code. While there are similarities in the defintions of motors and variables in hard coded movement, the new use of Pose completely replaces the use gyro functions such as GoYonderGyro and GyroTurn. Also, with the new interface comes the differences between basic C language and Javascript. We plan to explore these similarities and differences further as we continue to improve both our Autonomous and user-controlled code.

Beater Bar Launch Mechanism

21 Nov 2015
Beater Bar Launch Mechanism by Omar, Darshan, Evan, Max

Task: Design deployment mechanism for beater bar

Similarly to last year, the beater bar on our robot needs to be deployed in order to stay within the size limit. Using motors would make the robot heavier, and potentially too heavy to go up the ramp anymore. Bungee cords are something that we've always resorted to in order to save weight, so we decided to use them once again. By tying them to the back of the beater bar sliders and wrapping them around the robot to create more tension, we managed to make a crossbow-like mechanism that launches the beater bar forward. Small stand-offs were also used to make sure the beater bar doesn't rotate backwards.


As you can see from the video, the launcher actually works pretty well. There are a couple of problems with it though. Firstly, the force required to pull the beater bar back to the correct position is is very large, and might not be practical. Secondly, the knots we made, although certified by Boy Scout knot-master Evan, might undo themselves during competition. Thirdly, the beater bar might break due to it repeatedly smacking on the end of the track. Although we're probably going to redo the entire thing eventually, it's a good start towards making similar mechanisms, such as our idea for how we're going to hang on the cliff. We may decide on a design where the launch is done by motors rather than potential energy, but that will be a decision to make later.

Bumper Shields

22 Nov 2015
Bumper Shields By Ethan and Evan

Task: To create bumper shields for the robot.

We needed to create bumper shields because the debris on the field interfered with the tread. We had a prototype on the left,
Evan and I cut the bumper shields out of polycarbonate with two made for the front and two for the back. To do this, we were trained how to use a bandsaw. We cut them down so that they will be moveable.


Evan and I will attach the bumpers, and expect them to work well against debris. We do still need to test it on the ramp. The robot's previous state without bumper shields was too gradually damaging to the robot, especially to the things on the very edges of the robot. Now that we have the shields in place we have relatively safety from debris on the field causing damage to the robot.

Driving That Robot

22 Nov 2015
Driving That Robot By Evan, Darshan

Task: To try out the robot in a competition setting

Last weekend Darshan and I tried to drive the robot in a small scrimmage with eight other teams. Even though we hit a few bumps along the competition we were able see how the robot drove and handled. We also saw what we could do easily and what was hard for us. Among the bumps was an incident involving a tread falling off the track because we hit a block at a bad angle. The other bump that happened in the second round was when our robot turned itself off because one of the chains got near the power switch and rubbed it the other way. The things we learned were that there is a small delay between the command and the controller and what we could do on the field. At our stage we can push blocks and get up on the midway zone. We also were able to hit the first lever and make one guy drop. We still have a way to go but with what we know now, we can solve our problems with the system.


During the scrimmage we hit a few easily fixable bumps. We are already working on side shields to protect the treads and a bit of something to space out the distance to add space between the chain and the power switch. We are slowly progressing ad should have these issues fixed within the next few practices. As we continue to add new attactchments and overall increase the capabilities of our robot, we also need to increase our driving practice. This will help us perfect our strategy for competition and give us a better chance to win.

Autonomous Code

22 Nov 2015
Autonomous Coding By Dylan and Tycho

Task: Updating and Working on Autonomous Code

Today we continued working on the code involved for the first ten seconds of motion in the tournament known as autonomous. In this period we hope to reach the other side of the field towards the Res-Q beacon to dump our figures from the beginning and then trying to go as high as we can up the mountain. We coded this using our IronDem and the Pose classes to calculate the range and angle of our current location. We are using switch statements to accomplish this and have coded for much of the autonomous period now.


The main problem we have run into in our coding is readability and understanding the code thoroughly when we write it. Making simple careless errors must be found easily in this code like semicolons and mispelled variables. Otherwise, we still need to test the autonomous code and make sure that it works correctly. Next week, we plan to finish autonomous and test it completely. After autonomous we plan to start reviewing and coding navigation and the non autonomous code.

Hell On Reels

28 Nov 2015
Hell On Reels By Max

Task: Make a prototype grappling hook of doom.

As the point values make clear, managing to get the robot to hang on the end of the "cliff" is likely worth the effort. As such, we've worked on making a strange grappling-hook type contraption to pull the robot up. This first version works rather like a crossbow. A telescoping fishing pole has its largest loop hooked up to a long "bolt" which extends beyond the pole to a bungee cord tied to a pair of arms on the sides of the fishing pole. A 3D-printed grip is attatched to the bolt, and allows it to socket into the bungee cord and be pulled back by a person. When pulled back and released, the bolt pushes the telescoping portion of the fishing pole, causing it to extend.


This part is by no means complete yet. There are 3 main issues to tackle before this can be considered finished. First is a trigger. As of yet, the bolt fires as soon as it is released, so we need a mechanism to hold the bungee taught until the robot is ready and in position to release it. The second issue is making a hook. The telescoping portion of the fishing pole hasn't been modified much yet, but we will need to put a hook of sorts on the tip of the pole. Instead of a more cliche three-pointed hook, the most likely solution for us will be something more like a carabiner, so that we can extend the hook directly towards the churro on the cliff and the hook will clasp around it with a spring-loaded bar. The third and final problem will be closing the gap. We have made a way to propel the pole up to the cliff, but we haven't made a way to pull the robot along after it. To solve this, we will probably just use a cable and a winch, like what is commonly on a fishing pole in the first place. This will likely involve tying one end of a string or fishing line to the hook, and then wrapping the other end around a spool on a DC motor mounted on the main chassis of the robot, so that reeling in the line will cause the telescoping fishing pole to collapse back down to its compacted length.

Prototyping the ramp for the intake system

28 Nov 2015
Prototyping the ramp for the intake system By Jayesh, Omar, Ethan, Evan

Task: Make a physical prototype to plan out the next step in our ball/block intake system

We held a post-Thanksgiving meet to focus on the mechanical side of our robot, as we had been devoting a majority of our time to software and other such things. The problem we faced with our beater bar being installed on two sliding extrusions is that we had to have an incline adjusted to going up two levels and not just one like we had last year. Using an old soda box, we were able to make a flat, tin rectangle and experimented in angle and material until we found a comfortable range for the intake ramp. We will make a more permanent ramp, most likely out of a polycarbonate sheet, soon, now that we have our measurements.


Using a prototype before making our actual materials helps us to minimize error as we improve our robot. This simplistic design of a ramp allowed us to experiment and adjust our design until we had reached a desirable range. Our idea for our more permanent final design is to use two pieces, similar to the polycarbonate we use for our border walls, and have it elevate with our beater bar. The bottom piece will be only connected to the base and the top piece. With the flexibility of this plastic, we can make our desired curve and incline for our balls to travel up the intake system. Our next step, after finalizing our design for the ramp, is to make our collection device for the balls/blocks and make that available for us to obtain more points on the way up the ramp. This brings us closer to our eventual goal of scoring as we go up the ramp.

Why we should measure twice, and cut once

29 Nov 2015
Why we should measure twice, and cut once By Ethan, Evan

Task: To redo our bumpers

"Measure nonce, cut twice," is Iron Reign's unofficial slogan, as hidden in our html.

the image's spelling is entirely on purpose

We especially learned the error of cutting hastily today, as we errored in the production of our bumpers.

Evan and I spent multiple practices on working on the front and back bumpers. We easily took ten hours cutting them into their perfect shape. However, after we had placed the bumpers, we found a very unfortunate error; our perfect, hand-crafted bumpers both set us outside the size limit, interfering with our treads and motors.


In summary, we should remember to measure before we cut. Before making any apparatus in the future, we need to make sure to measure and calculate the size of what we are placing on the robot. This will both ensure our design works as expected, and our valuable time isn't wasted.

Design and prototype a churro latch mechanism

06 Dec 2015
Design and prototype a churro latch mechanism By Caitlin, Darshan

Task: Design an alternative churro climber mechanism

Currently Max and Tycho are working on a beater bar 3D part that is stiff enough to pull in blocks, and will hopefully double as a churro catcher when spinning. However, since the parts take 4 hours per set to print, and are harder to rapid-fire test and change and tweak relative to some other options we're going for other options till they're tested. The churro catchers help us to secure holding up the ramp but we are thinking of a similar design we can make with the parts we have.


For testing purposes, the stiff flexible part is a very large ziptie, and we're using steel wire as the hook. A motor rotates the axle, extending and pulling back on the hook. The motor is driving the axle with chain and sprockets. The angle allows the wire to go over the churro initially and then hook when pulled back. The angle is changing and we believe that as we develop the idea we will need a one way latch that flips over easily, as there is some trouble with the initial push.

Slide Trigger

13 Dec 2015
Slide Trigger By Max

Task: Model a part that lets us hold back the slide with a trigger to release it

The beater bar mechanism was put on a slide so that we could restrain it until some point during the match, but we had yet to actually build a restraint and trigger to serve this purpose until now. Since the mechanism would likely include rubbing pieces and need customized parts, we chose to model and 3D print the part in nylon to minimize friction and allow for easy customization. The first version (seen below in PTC Creo) consists of 3 printed nylon parts, one being a restraint and the two others (the same model, printed twice) acting as the trigger, pushing up the restraint when pulled back by a string (or something similar) and allowing the slide to move forward.


The mechanism generally works well, but the trigger will occasionally fail to push the restraint far enough for the slide to break free. This will need fixing at some point in the future with a new version for the trigger.

General Improvements

19 Dec 2015
General Improvements By Jayesh, Omar, Darshan, Max, Caitlin

Task: Perfect and improve multiple of our main characteristics of our robot

Iron Reign held its first Christmas break parade today and we decided to focus our time on making multiple small improvements, rather than adding one big part on our robot. Omar, Darshan, and I spent our time on rewiring and fixing our side motors. We found that one side was greatly lagging behind the other, so we tested to see which motor was failing, and rewiring the system fixed our driving system. We also cut out a long piece of Balsa wood to have a platform for our robot to making testing and machanical debugs easier. Needing space for our Churro catchers, we also cut holes in our front bumpers. Trace made a new moving cart for us that is much larger and sturdier. What's even more impress is that he made it without instruction (which he found later were right in front of him).


We've spent a good amount of the last few practices on our big ideas, so before we move on to our next big part, taking time to perfect what we have is necessary to ensure that nothing breaks and throws off everything on the robot. Doing these small improvements helps prevent us from doing a lot less work in the future. The cuts in the front actually give us a form of a door flap that we can optimize for future use in our Churro Catchers. Cutting the platforms for the robot gave some trouble, due to the thickness of the wood and the need for us to make two triangular shaped holes for our motors.

Improving the Catcher Design

20 Dec 2015
Improving the Catcher Design By Dylan, Darshan, Omar, Jayesh, Evan, Alisa

Task: Add Improvements to the Catcher Design

Today our team worked on improving the methods of capturing and holding blocks and balls. Our first design involving zip ties had major difficulties including that it had little strength to pull objects in. For this reason, we redesigned the beater bar using a 3-D printer that had stronger materials to capture materials along with frictionless tape which did not cause the blocks to become stuck. Through our tests we can see that the blocks can go up the ramp from the beater bars we created and can easily be stored in our designed holder trough.


Our catcher as a whole is only about half way finished. Our beater bars work well yet our holder trough has not been fully added to the robot meaning the blocks being launched up the ramp have yet to be slowed and contained. Once they are, and we add these to the motors our catcher prototype will be mostly complete and only the finer details of making sure the beater bar does not disrupt the ramp or nearby screws on the robot will be needed.

Prototyping the Trough

22 Dec 2015
Prototyping the Trough By Jayesh, Omar, Darshan

Task: Prototype the trough using materials such as cardboard to give us a baseline


The team had a meet before the busy Christmas period to focus on the main part of of our scoring mechanism: the trough. We discussed possible courses that would be easiest for us to score points and code at the same time. We went through multiple ideas of how the trough would work. One idea was to have our trough consist of rotatable base to account for both balls and blocks. However, as in the top scoring box of the ramp, blocks are the most effiecient way of scoring. Based on that, we decided to make our design to only hold blocks and able to dispense accidently aquired balls. Our final decision was on a rectangular prism with an elevated back side to serve as a kind of backboard for projectiles thrown by our beater bar. The smaller opposite faces will serve as flaps to open or close to dispense blocks to their respective crates.


With our final ideas in mind, we went through our supply of boxes and found one that best fit our idea. Then, using a sheet of cardboard we figured out the actual measurments we needed for the trough and cut out the best model possible. With our model finished we can get started on actually making the trough and designing the systen needed to score our blocks. An early idea is to have a pulley system that can be exchangable depending on the side we are on. For example, if we are on the blue alliance, our pulley system will be right dependent and vice versa. We will have to also make code respective to both sides and switch out before our next match. Now with the prototype done, we can simply recreate the trough using better materials and begin construction of the pulley system.

Churro Hook

24 Dec 2015
Churro Hook By Max

Task: Model a part to help the robot climb the churros on the mountains

Most of the big-value items in terms of points have to do with the mountains, so climbing mechanisms are a must have. Since the tank treads have problems scaling the churros on the middle and upper mountains, we need another way to pull the robot higher. Our solution was to put hooks on the ends of long, heavy-duty cable ties that we could extend and retract using a DC motor. We decided to make the hook a 3D printed part so that we could fold it and store it inside the robot until first deployed. We ended up making three different versions (all are below, as they appear in PTC Creo) as problems showed up with the first and second version.


The final version of the churro hook works well, and with two hooks mounted on one motor (geared down for extra torque), the robot is able to reliably pull its own weight up the ramp after hooking on to a churro. Unfortunately, the axle that controls the movement of the hooks gets in the way of the trigger for the slide mechanism, so a remake of the trigger model is due some time in the near future.

Optimizing the Churro Catcher

27 Dec 2015
Optimizing the Churro Catcher By Jayesh, Omar, Darshan

Task: Improve and fix our Churro Catcher + finalize design for trough

The team met up on Sunday and we focused our meeting on finalizing our trough design and making our churro catchers usable. Beginning with our trough prototype, we put in an angled metal piece to the main box compartment and shortened the height of the box. This height was specific to the height of the blocks, allowing us to shave off blocks that become stacked upon those that we've already collected and allow us to stay under the five-object limit during the match. After testing the perfected design, we moved onto testing the churro catchers. We found that we needed alignments along the ridges of the metal beams that carry the catchers to make sure the catchers actually extended past the robot. Past that, we found that the beam holding the motor controlling the in/out motion of the catchers was causing the beam to bend inwards. This caused the two gears to progressively bend the drive chain between the two and stalling the entire system. We fixed this problem by making a mechanical stop by rotating the motor and placing to larger gears with a 3:1 ratio.


With our model for the trough finalized, we can begin construction of the actual trough with much more sturdy material. Our design, which includes the bottom semi-ramp, will most likely be a cut T-shaped container that is directly connected to the ramp. This design allows the blocks we pick up to go on a singular path to our container and minimize the chance of the blocks getting stuck on one of our side beams. We plan to place small spacers throughout the upward path of the ramp to prevent these posibilities. We figured out the reason our catchers weren't working at first was because the motor wasn't initialized in the hardware map on the robot controller phone. Figuring out the mechanical error, the churros now run purely on a gear based system and doesn't use a drive chain anymore. Now the main objective is to place our actual trough and the robot and finish up this year's scoring system.

Improvements to Churro Catcher and Ramp

29 Dec 2015
Improvements to Churro Catcher and Ramp By Jayesh, Caitlin, Omar

Task: Make improvements to Churro Catcher and Ramp and make blog more accessible

Iron Reign held our first of two meetings before the New Year season to concentrate on improving our main designs to ensure they worked as expected. Starting with our Churro Catcher, we found that as the motor moved the two arms down, the tension in the two churro climbers was two low to actually push out the latches forward from the robot. We built two small metal segments that ensured the two long strips didn't get pushed out and that tension transferred to the lower part of the wire, fixing the problem and pushing out the strips to the desired range. Relating to the intake system, we found that as the blocks were pushed up the ramp, on rare occasion, they would become stuck on the side beams of the robot. Realizing this, we cut out small cardboard pieces and inclined them on the ramp, covering the side beams and they acted as guides to the offending blocks, pushing them back on to their desired course.


Our usual strategy of designing our main aspects of the robot, and then spending time to perfect them saves us a lot of future time wasted. Once we finished up the ramp and churro systems, we immediately set to figuring out what was wrong with each system. Finding the errors, in this case the blocks falling on the side and the incorrect spread of tension in the strips, we can add or take away certain things to perfect our design. With these two scoring mechanisms done, we now need to concentrate on distributing our weight on the robot and ensuring our churro catchers can actually help us climb the field ramp. With our first qualifiers fast apporaching, we need to concentrate on what we can do well and make those things secure in our strategy.

Climber Restraint

30 Dec 2015
Climber Restraint By Max

Task: Model a part to keep the churro climber cable ties on path

As we continued to work on the churro climber mechanism today, we decided that the cable ties bowing out would be a big issue that needed fixing. By making a small guide piece, we could ensure that the cable tie actually extends from the front of the robot instead of flopping around like overcooked spaghetti on the other side. So, I've made a rather simple model that can be bolted over the cable tie and on to the extrusions of the sliding mechanism.


It works well; after running some tests, it seems to have resolved the issue entirely, and the cable ties reliably extend from the front of the robot. The movement of the sliding mechanism doesn't affect the ties in any bad way, which is a nice plus.

Slide Lock

30 Dec 2015
Slide Lock By Max

Task: Model a part to keep the slide from going too far forward

Since we mounted the beater bars on a slide, we have been keeping them from going too far and falling off their rails either by obstructing them with a couple of bolts or with a bent piece of steel wire, but neither method is fool proof. The wire can get bent out of shape as the slide moves forward and collides with it, and the bolts can fall out or damage the metal of the slide itself as they collide. To solve this, we decided to make a 3D printed part to serve as a lock. This went through several iterations in design (all can be seen below) before we were satisfied, and we printed out two copies of the final version in nylon so that they would be strong, but still a bit flexible so that we could pry them up and remove the whole slide mechanism for maintenance if need be.


The parts serve their purpose well. The only issue with the version we are using is that the thickness of the beam connecting the hook and the attachment point is so thick that prying up the pieces is more difficult than originally intended, but it is still possible and further revisions to the part will likely be too time-consuming for their benefits to oughtweigh those of putting the same time into programming the robot's autonomous routines.

Rebuilding the Churro Climber System

30 Dec 2015
Rebuilding the Churro Climber System By Omar, Darshan, Max

Task: Fix bending axle on churro climber permanently

After further testing of the churro climbers, we noticed that the axle the gear is rotating on had been bent severely due to the strain on it of the arms pulling. If we left the axle as it was, it might wreck something else later and become unusable, so we tried to figure out a way of creating something that served the same function as the axle but wouldn't bend as easily. We decided on using long, slender aluminum tubes that Max put together with the gear that drives the arms forward and backward. They will most likely retain their integrity, but one flaw with them is that if they do fail, they will fail much more catastrophically than the axle would have, and would be much more difficult to replace. We're riding on our confidence that they'll hold throughout the strain.
We also 3D-printed and installed a couple of things (Max-designed): first, small guides that the arms can move through so that they push forward and pull back the way we want them to; and second, longer pieces that hold the beater bar back while it's waiting to be released.
As a small quality-of-life improvement, we have added a couple of pieces of cardboard to the sides of the beater bar today to block game elements from getting stuck in the empty spaces that are there.


After further testing, we found that the axle actually did crack at a weak point it had. It's been fixed and hopefully the same thing doesn't happen again since we fixed its weak point. With our first competition approaching, this new mechanism is a very good step towards the completion of our robot, but we still have a lot to do. We might not have even needed to replace what we had had we given it a few more supports, but this is overall a better design anyway and was worth the time. Little improvements are also nice whenever they can be made. Our design of the supporting churro axle caused it to not hold up to the tension the churro catchers, which caused it to gradually bend inwards. This new design rids us of that problem, as the tension is now spread throughout the axle rather than at one point.

Prototyping and Making the Flipper

02 Jan 2016
Prototyping and Making the Flipper By Jayesh, Omar, Darshan

Task: Design an apparatus to deposit the climbers in the beacon bucket.

One of the methods to score in this year's competition is depositing the two climbers in the bucket behind the beacon. This being relatively simple, we decided to concentrate this practice on creating something to get us these easy points. We discussed possible ways to deposit the climbers and came up with a design that used some of the scoring mechanism we already had on our robot. The idea was to have a long thin, box-shaped platform to hold our two climbers and have it held down by bungie cords. Using the spinning motion of our churro catchers, we would release the cords holding down the platform and thus releasing the potential energy created from the cords. This would cause our boxes to incline down and the climbers to slide down into the bucket.


After finishing our thoughts on the design, we first measured out the minimum space required to hold our two climbers. Then, we added a little extra to each of our dimensions to allow for error in the down motion of the climbers. First making a prototype made our of cardboard, this allowed us to test if our idea actually worked. Then, with the errors fixed using our prototype, we made our actual platform using the prototype as a base model out of plastic. Then we attached our metal platform to hold it over our top center beam and shaved off the top edge of the platform to keep it under the size limt. Now we have relatively easy points in the form of our climber depositing system, which will help us in our competition.

Slide Trigger (Revisited)

03 Jan 2016
Slide Trigger (Revisited) By Max

Task: Remodel the slide trigger mechanism to compensate for mechanical problems


Starting Color Blob Detection

05 Jan 2016
Starting Color Blob Detection By Omar, Max, Tycho

Task: Implement color blob detection on the robot for detecting beacons

Even though this was very long overdue, we now have a way to turn towards a certain color similar to what Argos does. What we're basically doing is calculating the angle that the robot is off-center of the blob it's tracking, and letting it correct for the error and straighten up with our PID code that's already in place. Right now, it doesn't actually move backwards and forwards, only turn on its axis, but we can soon get it moving around following colors. --NEEDS VIDEO HERE--


This year's competition gives teams that can detect the colors of the beacon a huge amount of points, which includes dumping the climbers in the baskets and pressing the buttons. It's very important for us to be able to do this if we hope to be successful in our first tournament that's less than two weeks away. With the ablity to now direct our robot towards the colors, we can have more overall points during autonomous and tele op.

Functions of our controller

09 Jan 2016
Functions of our controller By Alisa, Ethan, Trace

Task: Listing out the functions of our game controller

In order to find a button for our argos mode drive, we made a rough draft of our game controller listing the functions of each button. For example, the 'X' button is for the churo climb, the 'A' button is for our beater to stop, etc. We had about 5 unused buttons so in the end, we decided on using the top left button for argos mode drive. Now that we have all our function per button lsited out, it will be a lot easier to use this diagram for reference if we ever need to add another function or forget what a button does.


From now on, we should well-document everything about our robot, as we had to look in the code to actually see what our controller layout is. As well, we really, really need to let our drivers practice because they should have known the buttons as well.

Tape Measure Attachment

13 Jan 2016
Cliff Hanger - Tape measure based climber By Trace and Max

Task: Creating an attachment to climb the mountain

We have recently been working on a new approach to climbing the mountain. Our strategy so far was to have one system customized for climbing the mid and upper mountain (Churro Climber), and a separate system for climbing the cliff (Crossbow Grapple). The Churro climber system was beginning to work but it was floppy and we were thinking about stiffening the nylon extensions with measuring tape material. The Crossbow Grapple was working by hand, but we still hadn't mounted it to the robot and hadn't figured out how to rig it with a winch and servo trigger.

Then while researching grapples we stumbled on robots using tape measures as self-supporting winches. Brilliant! Many FRC robots have used this type of solution where it goes back at least as far as 2010:

And FTC teams are using the idea this season. We were inspired by how well team 6081 does this

This approach lets us simplify from two separate systems into one system that is much more compact. It also lets us switch to climbing the mountain in the opposite direction than we had been, which can extend the reach of our debris trough and maybe let us deposit in the highest debris container. It also seems like this approach could be more durable than what we what we've been working on.

Our design is composed of a tape measure and motors to pull or release with a hook at the end to grab the churros and upper bar. Team 6081 posted about their design, but we wanted a lighter version so we tried direct drive and Max designed a new 3D printed spool without a retracting spring in it. We bored large holes through the sides to allow motor hubs to stick out. We had to saw off a corner of the original case because it was limiting its own rotation to the elevation angles we needed. Then we drilled more holes in the case to attach the servo linkage that controls the elevation angle. Max designed a custom hook to go on the end and printed it.


In our first test, the tape measure broke (because we over-retracted it). It also has a problem where the tape extends out through the hole we made in the case when the tape is physically prevented from pushing outward. But if you avoid these situations, the tape measure seems very successful and was able to pull the robot all the way up the mountain. We plan to use this in our competition this week (yay!!).

This system is very important and will help deliver many points in the near future. In contrast to our previous pair of climbing systems, this is very practical and will be easier to use for the driver and it will work most if not 100% of the time. I hope this will be just as helpful to everyone else too.

Conveyor belt

21 Jan 2016
Conveyor belt By Jayesh, Max, and Darshan

Task: Create continuous method of scoring blocks

Since we have a semi-reliable form of going up the ramp (which we are working on to make closer to 100% efficiency), a priority for our team robot-wise is to establish an effective method of scoring blocks. We've designed a preliminary model with our old plastic trough that uses a conveyor belt made of fabric and foam sewn together that we tried to use before but decided not to. The foamy material proved perfect to drag the blocks. Basically the beater bar drives blocks into the trough, which flips up due to rubber bands and a servo.. The blocks drop into the bottom (before on the top since it hadn't been flipped) conveyor belt portion and turn another servo to move the belt to make the blocks head towards whichever side we wish to score in.


As we are aiming for the 80 points in hanging off the top bar, we wanted to ensure that we score as many points as possible to make our victory more assured. The conveyor belt, similar to our system from last year (except horizontal), gives us a continuous scoring mechanism as we ascend the ramp. We hope to test the utilization of both our conveyor belt and our (new) climber system before the new week begins and get some driver practice in before next Saturday. Our scoring system should help us win more games, especially with the hang and blocks in place.

It's a Bloodbath

23 Jan 2016
It's a Bloodbath By Ethan, Alisa, Max, Darshan, Jayesh, and Tycho

Task: To dye all our nylon parts red

Today, we took every single 3D-printed part off our robot to dye them. We used RIT clothes dye, which worked because our parts are nylon. The purpose of dying all our 3D-printed parts red was so that they would stand out from Tetrix parts while demonstrating the robot. It was a bloodbath. The color was the color of the Nile during the Plagues of Egypt. It seemed as if we were in the bible. But, like the Israelites, we prevailed, and came out with really cool red parts.


Last season, all of the parts on our robot that were 3D-printed were orange, which made us very noticable and memorable. We didn't have anything like that this year, so dyeing all the parts red will hopefully help the judges and other teams remember us at future competition(s). Red is also darker than orange, which means we're more serious. Grr.

The Double-Wide Experiment

23 Jan 2016
The Double-Wide Experiment By Jayesh, Max, Dylan, and Evan

Task: Strengthen our tape-measure climber against folding and sideways forces

Our tape measure is constantly under stress, which usually isn't a big problem if the driver is positioned with a straight 90 degree angle, but when twisted can result in cracks.

While our tape-measure design worked decently at our competition last week, with multiple mid zone scores and one high zone score, we are going to need more consistency to be a valuable ally in our matches. At competition we saw the tape fold multiple times, requiring a new retract/extend cycle that wasted time and often required reposositioning heroics from our driver. Mostly this was due to the hasty replacement of the dead servo that controlled the tape's elevation. The replacement didn't line up with the previous one and might have had a different programmed response range. As a result the preset angles were all wrong and it took us a few matches to reprogram usable elevation angles. In the mean-time drivers had to jockey the robot into weird positions that challenged the stability of the tape. So we'll fix the problem with better servo maintenance, but in the mean-time we thought that maybe we could also stabilize the tape by adding a buddy. Thus the double-wide (slit) experiment.

Now we have two custom printed tape spools on a shared axis. Max designed a new 3-D printed case to hold both. The case floats on the axis and rotating the case is what sets the elevation of the tapes. Since our design does not use the original spools of the tape measures with their counter-springs, our tapes naturally want to extend out of the case. This simplifies our design so that we don't have to push the tape out with a drive wheel, but it also increases the power needed to retract the tapes. Now with two tapes there is even more resistance to retracting the tape even when the robot is not lifting. So we switched from two regular Neverest motors to two 60:1 versions with increased torque. With two tapes, there is also less strain on each. Ripping tape was another competition experience that we want to minimize.


A consequence we didn't predict is how much weight the second tape adds. When testing the new design we discovered that this extra weight adds considerable force against the servo that controls elevation - particularly when the tape is extended out to the 3 feet or so that we need to disengage from the last churro prior to coming back down the mountain. We need a way to counter this extra weight and relieve the servo of the burden. Probably more elastic materials.

We also discovered that the servo linkage point on the custom case needs to be moved to give a better range of articulation based on where the servo is mounted. Max has already made the design improvements and we are printing a new case overnight. It takes our printer 11 hours to print both halves of this case design.

We are hoping that all this effort leads to a reliable 80-point hang for next week's competition. We are trying to make our control scheme as easy to interpret by our driver as possible, so we are implementing a mountain mode that should simplify things. Now, we need to focus on our conveyer belt system to score blocks as well as climb the ramp.

Pushing my Buttons

28 Jan 2016
Pushing my Buttons By Ethan and Max

Task: To build a button-pusher for the beacon

Today, we realized that the tape-measure attachment that's supposed to push the buttons on the beacon could have multiple functions instead So, we designed an attachment to the tape measure that can push any buttons, including people's. Max designed it in PTC and then printed it. We have yet to actually test it on the robot, but it works in-hand.


This is just our first design, and it has not been tested much. We feel that we should redesign the spikes to be deeper in the next version, and also not as densely packed. Further testing will reveal what the next step needs to be.

Fixing Up Our Climber and Trough Attachments

13 Feb 2016
Fixing Up Our Climber and Trough Attachments By Jayesh, Max, and Omar

Task: Replace servo on CliffHanger with a motor

At both competitions we've been to so far, we've noticed that the servo that controls the cliff hanger's elevation often stresses and heats up due to the strain being put on it, especially near the end of the match. It has already scorched quite a few of our fingers. To remedy this, we decided to replace it with a full-blown NeveRest 60 motor so that there's no worries of blowing it out. Additionally, we've also done some readjusting to our trough mechanism.


The new motor will take away a lot of the problems we've been having with the cliff hanger being inconsistent. We won't have to worry about taking the robot off of the field as quickly as possible after a match to prevent killing the servo now. The motor is also plenty strong enough to turn the tape measure even with it extended. Although we'll have to tune the motor to turn to the correct angles again like we did with the servo, it'll be worthwhile since we won't ever have to replace it and re-tune.

Hoverboards and PID

09 Apr 2016
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.


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.

Making a Ports Map

28 May 2016
Making a Ports Map By Omar and Jayesh

Task: Create a list of motors/servos and what ports they're connected to

Very often, when we disconnect a motor or servo (maybe on accident), we forget what port we got it from. This even happened to us today when we unplugged the servo that lifts the trough. Because of this hassle, we decided to write out a list of all the motors and servos on our robot and what port they're connected to so we can refer back to it if we ever forget where we took something from again.


This didn't take us much time at all and was easy to do, so we might want to make a lot more of things like these in the future to keep ourselves organized. Organization is definitely something we need to work on for this next competitive year, and even small things like these help out with that.

New tread material test

11 Jun 2016
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


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.

2016-2017 Robot

15 Oct 2016
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.


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.

Programming our New Robot

15 Oct 2016
Programming our New Robot By Tycho, Caitlin, Ethan, and Jayesh

Task: Program our new mecanum wheel driving platform

Now that our new robot has been built with a mecanum wheel platform, we can start write our drive code and figure out how to make our robot preform three basic motions: forwards and backwards, side-to-side and to rotate. We decided that, in order to get the best understanding of our robot, how it moves and our code, that we would try to write our drive code through trial and error. However, we did reference some guides written by other various FTC and FRC teams if we got stuck on something and needed to figure out where to start in solving the problem.


In order to drive our mecanum wheels properly, we need to first discuss how each wheel is placed on the robot, and also how each wheel needs to move in respect to the others in order move in a certain direction. Each wheel has small rollers that point 45 degrees off of the larger wheel itself. In order to properly set up mecanum wheels, the rollers on each wheel have to point towards the center of the robot.

This is important, because if these wheels are not pointing in the proper direction, then the rollers will begin to fight against each other, causing strange driving patterns that aren't very useful. We learned this the hard way, because when reconstructing the wheel mounts, the positions of two wheels on robot were flipped, causing the robot to drive in circles when we tried to drive sideways.

The main reason we decided to go with mecanum wheels is because they open so many different ways to navigate the field. Robots that properly use mecanum wheels can not only go forwards, backwards and turn, but they can also make a robot move side to side. These three types of movement can be mixed with each other to do even cooler things like move in diagonals or even strafe, which is when a robot moves in an arc while moving sideways. Of course, we cannot use mecanum wheels to their full potential if we do not first understand the first three basic types of movement. Driving forwards and backwards is pretty simple, and it's the same as any other robot; all of the wheels have to move in the same direction. Turning also remains unchanged from other platforms; the left side of the robot has to move one way, and the right side of the robot has to move the other.

However, moving side to side is not really intuitive compared to the others. In order to move side to side, the wheels on either side have to move opposite of each other. For example, if I wanted to, from a top-down perspective, drive to the right, the wheels on the left side of the robot would have to drive away from each other, while the wheels on the right side of the robot would have to drive towards each other. The rollers start spinning away from the center and to the right on the left side of the robot, or towards the center and to the right for the right side of the robot. The forwards and backwards components of the wheels and the rollers cancel each other out, and the robot moves to the right.

Need for ZTE Speed - The Movie - The Game

22 Oct 2016
Need for ZTE Speed - The Movie - The Game By Max

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

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

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


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

Launching Mechanisms

26 Oct 2016
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


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.


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.


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

Ready the Artillery

29 Oct 2016
Ready the Artillery By Max

Task: Design a bowl for our upcoming catapult system

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

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



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

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

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

Yeah, it's probably gonna be me.

Launching Mechanisms Pt. 2

31 Oct 2016
Launching Mechanisms Pt. 2 By Ethan

Task: To improve upon launching mechanism designs


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.

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.


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

The Robot is a Nautilus Now

02 Nov 2016
The Robot is a Nautilus Now By Max

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

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

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


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


06 Nov 2016
Parasyte By Jayesh, Omar, Darshan, Caitlin, and Max

Task: Design a collector for the balls

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


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

Mecanum Driving

13 Nov 2016
Mecanum Driving By Tycho

Task: Code driving under mecanum wheels

Today, I wrote the whole code for controlling our mecanum wheels. It is entirely fron scratch, and works perfectly right off the bat. This code allows us to strafe, move backwards and forwards, and rotate, in one method.


We still have a lot of coding to do, as we're currently working on a particle-launching system. As well, we need to consider autonomous soon.

Intake System Improvements

21 Nov 2016
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


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

22 Nov 2016
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.


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.

Autonomous Setup Options

23 Nov 2016
Autonomous Setup Options By Tycho

Task: Create a basic autonomous

Autonomous is one of the things that we tend to be weak on every year, and this year, we really want to get to super-regionals. So, to start off this year's autonomous, we first mapped out a potential path for the robot on the field. We then followed up with programming, using our previous methods like driveForward and driveCrab. So now, we have a basic autonomous program in which we can push the cap ball and attempt to shoot the vortex.


We still have a long way to go in working on our autonomous - we need to be more accurate in shooting the vortex, we would like to hit the beacons, and we want to get parking points as well.

Catapult Upgrades

23 Nov 2016
Catapult Upgrades By Max

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

Task: Imbue the catapult bowl with infinite power

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


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

Final Catapult

27 Nov 2016
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.


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.

Combining TeleOp and Autonomous

01 Dec 2016
Combining TeleOp and Autonomous By Tycho

Task: Combine TeleOp and Autonomous code

Today, I combined the autonomous and teleop so that we can demo both more easily. As well, during testing, we now can switch between them seamlessly so that our testing is power. The most important part of this code is that we can configure the autonomous before we launch - telling the robot how many balls we have, how many to shoot, what side the robot is on, and other pertinent options.


We still need more code and fixes - our robot keeps having random errors while launching. As well, we have intermittent lag.

Time to Skip Version 9

10 Dec 2016
Time to Skip Version 9 By Max

Task: Make some changes to the catapult bowl

The apocalypse is at hand.

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

The catapult bowl is too floppy.

Cut to black. Text appears: VERSION 8.

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


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

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

Beginning the build for the Cap Ball Trapper

24 Dec 2016
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.


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

Fixing Faulty Encoder

26 Dec 2016
Fixing Faulty Encoder By Tycho and Jayesh

Task: Fix a faulty encoder on our robot

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

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

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

Mapping Out Autonomous

30 Dec 2016
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.


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

12 Jan 2017
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.


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

12 Jan 2017
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".


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

Introducing the New Particle Accelerator

22 Jan 2017
Introducing the New Particle Accelerator By Max

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

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

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

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

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


Introducing: The Iron Reign Particle Accelerator 1.0

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



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

Return to Machine Vision

29 Jan 2017
Return to Machine Vision By Tycho

Task: Prepare to reintegrate machine vision

A year and a half ago while the new Android-based platform was still in pre-launch, we were the first team to share a machine vision testbed on the FTC Forums. That color-blog tracker was implemented with OpenCV on Android, but with a different low-level control system and robotics framework. Then we integrated OpenCV into our implementation of ftc_app, which was in turn based on the great work of rgatkinson's team supporting Swerve Robotics. Our main game repo for FIRST RESQ was also open sourced and we gained a lot of experience using it. But we had many issues that prevented full usage of the capability. There were problems with the whole control system that created extremely variable loop times which really challenged our custom PID implementation. On top of that, we found that in many tournaments the beacons were not working, or the lighting was too bright and our camera was being flooded by the white shell of the beacons. That made it an unreliable solution.

So this year we switched to the modern robotics color sensor as a slightly more reliable method of detecting the current color while up close. This also gave us the ability to add color sensors to both sides of the robot so we no longer have to turn around when on the blue alliance. And we found we had good-enough navigation based on calibrated odometry so that we could get into position without color tracking.

But now we need to go ahead and try to re-integrate our previous machine vision code and see if we can improve on the situation. We also need to at least try out the Vuforia object tracking capabilities, even though we've set that as a lower priority because we know that specular reflections are likely to be a problem under varying lighting conditions at different competition spaces. We've noticed this problem at a couple of spaces due to the marker placement behind the planar polycarb of the border walls. So we don't actually plan to rely on this as a primary means of navigation and positioning, but we should try it out and see how robust it might be.

We still want to use machine vision to possibly track beacons and particles. We are hoping to track particles to create an autonomous behavior that triggers during teleop so that a particle near the front of our particle collector can be automatically approached and pulled in without operator intervention. This should help since picking up particles on the far side of the robot from the drivers is very difficult because of blocked sight lines. We want to use color tracking to make sure we don't pick up opposing alliance particles.

Research / References

I checked out Vuforia and there is no ability to track based on color. So we need to use OpenCV again, but when Vuforia is present it also locks up access to the camera. Fortunately there is now a way to get a frame from Vuforia and reformat the image data for OpenCV's use.

I plan another post to document the actual steps we went through. Stay tuned. If Vuforia proves troublesome, we might revert to getting our image from a camera preview just like last year. Though that would mean messing around with the Android manifest and the layouts in the main FtcRobotController folder.

Fly Wheel 2 - Fly Harder

08 Feb 2017
Fly Wheel 2 - Fly Harder By Max

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

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

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

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


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

Building the Fly Wheel Launcher

10 Feb 2017
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.


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

21 Feb 2017
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.


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


18 Mar 2017
Vuforia By Janavi and Tycho

Task: Use Vuforia to enhance autonomous

We use Vuforia and Open CV vision to autonomously drive our robot to the beacon and then click the button corresponding to our team's colour. We started this by getting the robot the recognize the image below the beacon and keep it within its line of vision. Vuforia is used by the phone's camera to inspect it's surroundings, and to locate target images. When images are located, Vuforia is able to determine the position and orientation of the image relative to the camera.

To start setting up our robots vision, we watched Team 3491 FixIt's videos on Vuforia to help us understand how to set it up. After finishing the code for following the image, we went to go test it out. We found out that we had accidentally coded the robot to follow the picture by moving up and down, as we had coded the phone for portrait mode instead of landscape. After fixing that, we tested out the robot and it ended up attacking Tycho by running at him and the image at full speed. Apparently, we had accidentally told the robot to go much farther than it was supposed to go by placing a parenthesis in the wrong spot. We tested the code one more time, only this time I held the picture while standing on top of the chair. Luckily the robot worked this time and was able to follow the image both ways.


We would like to explore the uses of Vuforia+OpenCV. We are considering using it to determine particle color as well as using it to view the images beneath the beacons.


18 Mar 2017
OpenCV By Ethan and Tycho

Task: Implement OpenCV in autonomous

Last year, we had some experience with OpenCV to press the beacons, and this year we decided to do the same. We use OpenCV to find the color we are looking for on the beacon in conjunction with Vuforia. First, it detects the search pattern in the view with vuforia, then isolates that area and finds the side of the beacon with the correct color. Our code is based off of FTC team 3491, Fixit.

In a previous post, we talked about OpenCV and Vuforia research, as well as how we plan to use it in the robot game. And now, I am happy to say, we have implemented it partially in our autonomous. We can now figure out what side a specified color is on the beacon using our new phones, the Galaxy S5. (Side note - do not update them to Android Lolipop if you want to use OpenCV, it will not work.)


In the future, we would like to implement OpenCV so that we can detect the color of a particle during autonomous and pick it up to shoot it. However, we probably don't have time to program it before Super Regionals.

Contact Us

E-Mail: Website: In the address bar