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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Update:

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

Reflections

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.

Reflections:

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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!!!

Reflections

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.

Reflections

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.

Reflections:

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);

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.


Reflections

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.

Reflections

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.

Reflections

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.

Reflections


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.

Reflections

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

Reflections

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.

Reflections

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.


Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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

Reflections

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

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.


Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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.

Reflections

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

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

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.

Reflections

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

Reflections

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

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

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.

Reflections

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

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.

Reflections

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.

Reflections

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

Launching Mechanisms

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

Flywheel

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

Catapult

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

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

Reflections

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

Ready the Artillery

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.

(herecomedatbowl.jpg)

Reflections

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

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

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

Yeah, it's probably gonna be me.

Launching Mechanisms Pt. 2

31 Oct 2016
Launching Mechanisms Pt. 2 By Ethan

Task: To improve upon launching mechanism designs

Catapult

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


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

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

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

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

Reflections

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

The Robot is a Nautilus Now

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.

Reflections

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

Parasyte

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.

Reflections

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

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.

Reflections

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

Reflections

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

Catapult Unfixes

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.

Reflections

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

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.

Reflections

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.

Reflections

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

Final Catapult

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.

Reflections

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

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.

Reflections

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.

Reflections

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

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

Beginning the build for the Cap Ball Trapper

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.

Reflections

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

Fixing Faulty Encoder

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.

Reflections

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

Cap Ball Lift

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.

Reflections

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

Motor Controller Mounts

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

Reflections

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

Introducing the New Particle Accelerator

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.

<infomercial>

Introducing: The Iron Reign Particle Accelerator 1.0

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

</infomercial>

Reflections

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

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.

Reflections

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

Building the Fly Wheel Launcher

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.

Reflections

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

Backups and Shields

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.

Reflections

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

Vuforia

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.

Reflections

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.

OpenCV

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

Reflections

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.

Balancing and PID

20 Aug 2017
Balancing and PID By Tycho

Task: Test and improve the PID system and balance code

We're currently testing code to give Argos a balancing system so that we can demo it. This is also a test for the PID in the new REV robotics expansion hubs, which we plan on switching to for this season if reliable. Example code is below.

public void BalanceArgos(double Kp, double Ki, double Kd, double pwr, double currentAngle, double targetAngle)
 {
     //sanity check - exit balance mode if we are out of recovery range
 
 
 
     if (isBalanceMode()){ //only balance in the right mode
 
         setHeadTilt(nod);
 
         //servo steering should be locked straight ahead
         servoSteerFront.setPosition(.5);
         servoSteerBack.setPosition(0.5);
 
         //double pwr = clampMotor((roll-staticBalance)*-.05);
 
         balancePID.setOutputRange(-.5,.5);
         balancePID.setPID(Kp, Ki, Kd);
         balancePID.setSetpoint(staticBalance);
         balancePID.enable();
         balancePID.setInput(currentAngle);
         double correction = balancePID.performPID();
 
         logger.UpdateLog(Long.toString(System.nanoTime()) + ","
                 + Double.toString(balancePID.getDeltaTime()) + ","
                 + Double.toString(currentAngle) + ","
                 + Double.toString(balancePID.getError()) + ","
                 + Double.toString(balancePID.getTotalError()) + ","
                 + Double.toString(balancePID.getDeltaError()) + ","
                 + Double.toString(balancePID.getPwrP()) + ","
                 + Double.toString(balancePID.getPwrI()) + ","
                 + Double.toString(balancePID.getPwrD()) + ","
                 + Double.toString(correction));
 
         timeStamp=System.nanoTime();
         motorFront.setPower(correction);
 

REV Robot Reveal

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

Argos V2 - a REV Robot Reveal

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

PID Calibration and Testing

27 Aug 2017
PID Calibration and Testing By Tycho

Task: Allow user to change PID coefficients from the controller

To allow each user to create their own settings, we're designing a way to allow the user to tune PID to their own liking from the controller. This also enables debugging for our robot.

public void PIDTune(PIDController pid, boolean pidIncrease, boolean pidDecrease, boolean magnitudeIncrease, boolean magnitudeDecrease, boolean shouldStateIncrement) {
 if (shouldStateIncrement) {
  pidTunerState = stateIncrement(pidTunerState, 0, 2, true);
 }
 if (magnitudeIncrease) {
  pidTunerMagnitude *= 10;
 }
 if (magnitudeDecrease) {
  pidTunerMagnitude /= 10;
 }
 double dir;
 if (pidIncrease) dir = 1;
 else if (pidDecrease) dir = -1;
 else if (pidDecrease) dir = -1;
 else dir = 0;
 switch (pidTunerState) {
  case 0:
   pid.setPID(pid.getP() pidTunerMagnitude * dir, pid.getI(), pid.getD());
   break;
  case 1:
   pid.setPID(pid.getP(), pid.getI() pidTunerMagnitude * dir, pid.getD());
   break;
  case 2:
   pid.setPID(pid.getP(), pid.getI(), pid.getD() pidTunerMagnitude * dir);
   break;
 }
}
public double getPidTunerMagnitude() {
 return pidTunerMagnitude;
}
public int getPidTunerState() {
 return pidTunerState;
}
public int stateIncrement(int val, int minVal, int maxVal, boolean increase) {
 if (increase) {
  if (val == maxVal) {
   return minVal;
  }
  val++;
  return val;
 } else {
  if (val == minVal) {
   return maxVal;
  }
  val--;
  return val;
 }
}

Meeting Log

09 Sep 2017
Meeting Log September 09, 2017 By Ethan, Evan, Abhi, Tycho, Austin, Karina, and Kenna

Meeting Log September 09, 2017

Today was the first meeting of the Relic Recovery season. Our main focus today was strategy, then organization and getting the robot ready for this year's challenges

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • Write blog post for Kickoff
  • Fix dates for indexPrintable
  • Blog post catchup
  • Strategy review

Software

  • Glyph recognition OpenCV
  • Aspiring programmer's code review

Build / Modelling

  • Teardown old robot
  • Design Competition - glyph grabber

Service / Outreach

  • Kickoff

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
EthanKickoff post2:002
EthanFix dates4:002
EvanDesign Competition2:004
AustinTeardown robot2:002
AustinDesign Competion4:002
TychoCode review2:004
KennaBlog review2:004
KarinaStrategy review2:004
AbhiStrategy review2:004
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001

Intake System Competition

09 Sep 2017
Intake System Competition By Evan and Austin

Task: Compare build designs for the cryptobox intake system

The block scoring system is going to be an integral part of the competition this year, and it will have to built sturdy. It’ll have to be reliable for us to have any shot of winning any matches. So we got to brainstorming. We spent a while at the whiteboard, drawing up various mechanisms and ways to pick up blocks. One idea was the idea of a block delivering system similar to those modern vending machines that have two degree of freedom movement. We began to design the contraption so that a conveyor belt could be placed on an up and down linear slide to position the blocks just right to make the different symbols. Another person came up with the idea to use our tank treads from Geb, our competition robot from two years ago, to push the blocks up a ramp and deposit them into the cryptoboxes. Neither of us could convince the other about what was to be done, so we both split off to work on our own models. Next week we will keep working on this build off of the century.

Meeting Log

16 Sep 2017
Meeting Log September 16, 2017 By Ethan, Evan, Karina, Tycho, Austin, Charlotte, and Kenna

Meeting Log September 16, 2017

Today we had a major outreach event at Conrad HS in DISD which served around 450 people. We also planned on continuing our building competition, working on strategy, the blog, and the robot teardown.

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • Conrad post
  • About page - new members
  • Strategy

Software

  • Code review

Build / Modelling

  • Complete robot teardown
  • Finish design competition
  • Install REV hubs

Service / Outreach

  • Conrad HS volunteering

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
EthanConrad post2:002
EthanAbout page4:002
EvanDesign competition2:004
AustinRobot teardown2:001
AustinREV hubs3:001
AustinDesign competition4:002
KarinaAbout page2:002
KarinaStrategy4:002
TychoCode review2:004
CharlotteConrad post2:004

Further Design of the Intake

16 Sep 2017
Further Design of the Intake By Evan and Austin

Task: Design the grabbing systems further

The sun came out and it was back to the field. We got started right away, both of us building our designs. Since the cryptoboxes were wider than the 18 inch sizing cube, we started by designing a fold out for the conveyor belt. This was entirely proof of concept, purely to see if it was at all aplicable in the game this year. We spent an hour or two gathering parts and put together an extending conveyor belt. This device would swing down, like the arrow suggests, allowing for more space to move the blocks back in forth, giving us accuracy in rune completion. This will be later attached to linear slides, allowing for an up and down motion.

Intake Systems

17 Sep 2017
Intake Systems By Austin

Task: Work on designs for the intake system

Over the past couple of days we’ve experimented with a horizontally mounted track system that we had hoped would serve to move blocks through the entire length of the robot and into the crypto box. Immediately we noticed a few issues, the primary one being that the tread was static in terms of mounting and therefore wasn’t accepting of blocks when feed at an odd angle. To correct our feeding issue, we widened the gap between the tracks and added rubber bands in hopes of maintaining traction and adding to on demand orientation ability.

Initial tests of our second prototype went fairly well, however the design suffered from some severe drawbacks; the first was its weight and size which would limit robot mobility and take up much needed space for other components, the second issue was that keeping the treads tensioned perfectly for long periods of time was nearly impossible and they would often sag leading to loss of grip, and finally the system was still fairly unpredictable especially during intake (blocks were flung occasionally). These finding lead me to believe we may scrap the idea in consideration of time.

Aside from our track intake we’ve also been working on a gripper and slide system that shows promise.

Meeting Log

23 Sep 2017
Meeting Log September 23, 2017 By Charlotte, Kenna, Tycho, Austin, and Evan

Meeting Log September 23, 2017

We started the day by volunteering at LV Stockard MS, another DISD event. During our practice, we planned to work on robot design, blog updates, and code testing.

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • About page updates
  • Stockard blog post

Software

  • Controller mapping

Build / Modelling

  • Cryptobox grabber - competition judging
  • Install chosen grabber
  • Reposition robot hubs

Service / Outreach

  • Stockard MS DISD

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
CharlotteStockard post2:002
CharlotteCompetition judging4:002
KennaAbout page2:002
KennaCompetition judging4:002
TychoController mapping2:004
AustinCompetition judging2:002
AustinInstall grabber4:002
EvanCompetition judging2:002
EvanMove hubs4:002

Narrowing Down the Designs

23 Sep 2017
Narrowing Down the Designs By Evan and Austin

Task: Redesign our grabber systems

In an attempt to get a working lift system before the coaches meeting we will be presenting at, a linear slide has been attached to the robot, along with a pair of grabbing arms. They work surprisingly well and aren’t as complicated as my idea. Plus the importance of speed has really taken hold on me this year. We need to be as fast as possible but my contraption is slow compared to the grabber arm. I think we'll be scrapping the idea for this grabber arm bandwagon everyone seems to be hopping on. While the grabber arm allows for quick pick ups and easy placement, our idea was only bulky and unnecessary because of our use of mecanum wheels which eliminate any need for a system to go side to side. Since the grabber was rudimentary, we’ll be making improvements and new iterations. We toyed with some materials earlier on in the season, and we’ll probably be implementing that into it.

Slide Designs

24 Sep 2017
Slide Designs By Austin

Task: Figure out slide mechanism

After determining that the treaded channel was much too buggy to perfect with the time we had, we shifted attention to other scoring systems like grabbers, however before finding the right grabber we decided we needed to get the track for it completed first. We’ve had experience in the past with all sorts of rails from Tetrix kits that convert their standard channels into lifts, to the newer REV sliding rail kits which we also toyed around with in initial prototyping shenanigans.

One of our key concerns was also wear and tear, in that we have had systems slowly breakdown in the past, such as our mountain climber and catapult, since they had plastic components that broke over time, we knew that long periods of use over multiple competitions would deteriorate the plastic components of either rail sets, and other rails that used full metal parts would simply be bulky and rough to fit in snugly with our robot. After a bit more research we settled on standard steel drawer slides from home depot, mainly because they were streamline and all around sturdy. The slides also provided us with easy mounting points for our future claw and attachments.

We understood that whatever option we picked for slides would have to be easily repairable or replaceable during competition, should something go wrong. Since the drawer slide were easy to come by and needed little modification we could easily make duplicates to act as stand by and demonstration parts during competition.

These positives came to form more than enough of a reason to continue prototyping our grabber that would eventually be attached once completed to the lift, which was now mounted to the robot and used a system of spools and pullies to extended above the minimum height for scoring in the top row.

Building Competition 2017

25 Sep 2017
Building Competition 2017 By Evan and Austin

Task: Find the best robot design

The games have begun and it’s time to build. So that’s what Austin and I did. A war had been declared. Legions of the indentured collided on the battlefield. Millions were slaughtered during this new age armageddon. Austin had his army. I had mine. Two different ideas to do the same task: lift glyphs into their correct positions. A simple job but one that caused a rift in Iron Reign, an incurable rift between the forces of light and darkness.

But then I decided to stop because his design had more speed than mine and speed is more necessary this year. My idea had been a lift that could move the glyphs back and forth but I realized that it would be a little too slow for the competition. Or, another solution would have had a side to side conveyor belt that moved glyphs back and forth to arrange them in the correct order, and then push them into the slots. This movement would have been separate from the four mecanum wheels that we are using in the chasis. His idea was simpler than mine, a conveyor belt that ran through the middle of the robot to bring the glyphs to the keybox, where they could be slotted in with the side to side movement provided by the mecanum wheels. So, like an outnumbered Supreme Court judge, I decided to join the winner so I could have a say in the early design. Once he got a prototype ofhis contraption working, it was able to pick up blocks effectively but it still needs improvement. It has issues with blocks at an angle, and it has trouble slotting the blocks into the keybox, but it's a nice step toward a working block system. We are currently planning to use the mecanum wheel base we used last year but this could change anytime. We left practice with a direction and that's better than nothing.

Meeting Log

30 Sep 2017
Meeting Log September 30, 2017 By Ethan, Evan, Tycho, Austin, Kenna, Karina, Austin, and Abhi

Meeting Log September 30, 2017

Today was based around prepping for our meeting with DISD adminmistrators, getting our robots in working order, and organizing parts for the season.

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • Fix stats page
  • Strategy

Software

  • Program lift
  • Program grabber

Build / Modelling

  • Fix lift string system
  • Add lift supports

Service / Outreach

  • DISD prep

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
EthanFix stats page2:002
EthanDISD Prep4:002
EvanLift supports2:004
AustinLift string2:004
TychoProgram lift2:002
TychoProgram grabber4:002
KennaLift supports2:004
KarinaStrategy2:004
AbhiStrategy2:004

Testing Materials

30 Sep 2017
Testing Materials By Austin, Evan, and and Tycho

Task: Test Materials for V2 Gripper

Though our current gripper is working sufficiently, there are some issues we would like to improve in our second version. The mounting system is unstable and easily comes out of alignment because the rev rail keeps bending. Another issue we've encountered is the cervo pulling the grippers so that they begin to cave inwards, releasing any blocks being held at the bottom. By far the biggest problem is our intake. Our drivers have to align the robot with the block so precisely to be able to stack it that it eats a majority of our game time. However, there are some advantages, such as light weight and adjustability, to this gripper that we would like to carry over into the second version.

    We tested out a few different materials:
  • Silicone Baking Mats - The mats were a very neutral option because they didn't have any huge advantages or disadvantages (other than not adhering well). These could have been used, however, there were other better options.
  • Shelf Liner - It was far too slippery. Also, when thinking about actually making the grippers, there was no good way to put it on the grippers. Using this materials would have been too much work with little gain.
  • Baking Pan Lining (picked) - It was made out of durable rubber but was still very malleable which is a big advantage. We need the grippers to compress and 'grip' the block without causing any damage.
  • Rubber Bands on Wheels - This material was closest to our original version and, unexpectedly, carried over one of the problems. It still requires very specific orientations to pick up blocks, which would defeat the purpose of this entire task.

The purpose of this is as a part of our future grabber design, which will need to be relatively light, as our string is currently breaking under stress due to weight. The material must also have good direct shear and direct strength, as the grabber will have rotating arms that move in and out to grasp blocks. As well, we're replacing the tetrix parts with REV, as they're smaller and a little lighter, with the additional bonus of more mounting points.

Designing the Grabber Further

30 Sep 2017
Designing the Grabber Further By Evan

Task: Design the grabber design and make future plans

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

Designing the Grabber

01 Oct 2017
Designing the Grabber By Austin

Task: Work on the grabbers more

With our single degree of freedom lift fastened to the robot we focused on the appendage that would grip to within an inch of its life any glyph we fed it. We initially toyed with simple tetrix channels to form a make shift rail that would hold axels for pivoting points, however we found tetrix to be a bit too cumbersome and decided to use rev rail instead. Using two tetrix U-brackets we built a makeshift grabber that used rubber bands and a servo to secure blocks without letting them slip through its grasp. To add extra grip to the long L-beams that formed the pincers of the claw, we added even more rubber bands, and moved on to testing.

Initial tests were very positive, the high strength servo coupled with a few rubber bands maintained enough of a grip on one or two blocks with ease, and because the entire system was mounted to a rev rail we could easily slide and size the pincers to the right distance. Feeling confident in our work we attached the grabber to the lift and attempted drive practice, which ended relatively quickly due to a surprising number of jams between the lift and glyphs.

The key issue we now faced was that as the lift returned to its home state blocks were getting stuck beneath the retracting claw causing jams. To fix this relatively simple problem we added a back plate to the claw that kept blocks from slipping to far into the robot, this was easily fashioned out of a bit of thin wood board we had lying around from the decks of other robots. The overall performance of our glyph wrangling device was astounding, so long as whoever was operating the robot was a well-trained driver.

Oh No! Dying Glyphs

02 Oct 2017
Oh No! Dying Glyphs By Abhi

Problem: Glyph Damge due to Robot Design

We were tearing up our glyphs like this because our wheels had no guard for their screws:

More specifically, we had multiple issues with damaging the glyphs. First, the exposed screws on the mechanum wheels (Fig 1) tended to cut into the glyphs as seen in the above picture. As well, you can see relatively sharp edges on the wheels where the block could also be cut, and that the blocks could be pinched by the wheels on the wheel. As well, the corners on the REV and TETRIX pieces cut into thr glyphs when they were rammed into the walls of the field (Fig 2).

Fig 1

Fig 2

V2 Hexifier and Parts

07 Oct 2017
V2 Hexifier and Parts By Tycho and Abhi

Task: Creating the Parts for V2

Today we continued our work on the second grippers. We talked about this in another post, but the gist is that we iterated through various materials to find something that would securely grip the block, without damaging it. At the beginning, that got rid of most of our options, but we tested various sprays, materials, and pressures to find the right material. The baking pan liner was the best, as it had some give without damaging the block, but had enough friction that slippage was a minor issue. So, we needed the baking pan liner to adhere to the large square dowel we chose to be the base for our grippers. In order to do this, we had to design and print a hexifier, as seen below, which makes the dowel's square shape into a hexagon. We also designed and printed square pieces to go on the top and bottom of the gripper to keep it in place.

Reflections

The new grippers are probably going to be much heavier than our previous ones. Not only because of the difference in material, but in sheer size. We may not be able to retain the lightness in V2 that we had hoped to.
We used PTC Creo for all of these parts. Abhi has some video tutorials on using Creo that can be found here and here. Soon we will start assembling our V2 grippers.

Meeting Log

07 Oct 2017
Meeting Log October 07, 2017 By Ethan, Evan, Austin, Tycho, and Charlotte

Meeting Log October 07, 2017

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • DISD post
  • Fix old post formatting
  • Stockard MS

Software

  • Begin autonomous

Build / Modelling

  • Fix robot - was dropped
  • REV hub relign 2
  • Realign square base

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
EthanDISD post2:002
EthanFix formatting4:002
EvanFix robot2:002
EvanRealign4:002
AustinFix robot2:002
AustinREV realign4:002
TychoAutonomous2:004
CharlotteStockard post2:002
CharlotteJournal review4:002

Chassis Upgrades

08 Oct 2017
Chassis Upgrades By Austin

Task: Upgrade our chassis

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

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

Meeting Log

14 Oct 2017
Meeting Log October 14, 2017 By Ethan, Kenna, Abhi, Austin, Janavi, Evan, Charlotte, and Tycho

Meeting Log October 14, 2017

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • Learn to blog
  • UTA post
  • Teach how to blog
  • Strategy post

Software

  • IMU testing
  • Autonomous

Build / Modelling

  • Install wheel mounts
  • Test string for lift

Service / Outreach

  • UTA volunteering

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
EthanTeach how to blog2:002
EthanFix formatting of posts4:002
KennaLearn to post2:002
KennaUTA post4:002
AbhiStrategy post2:004
AustinWheel mounts2:004
EvanString test2:004
CharlotteLearn to blog2:004
TychoIMU2:002
TychoAutonomous4:002

Grabber Code

16 Oct 2017
Grabber Code By Tycho

Task: Create a seperate class for the grabbers on the robot

Today, we created a new PickAndPlace class to isolate the code that controls the current gripper and lift system. I also added new methods to send the lift to max, min and stacking heights with manual override. It now prevents over extension or over unwinding by setting max and minumum heights. It also eliminates the problem of having to push the lift all the way down after lifting.

The code below describes the functionality of the robot. The class names should be self-explanatory as to what they do.

+package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.hardware.DcMotor;
import com.qualcomm.robotcore.hardware.Servo;

/**
 * Created by tycho on 10/15/2017.
 */

public class PickAndPlace {

    DcMotor motorLift = null;
    Servo servoGrip = null;

    private int liftMax = 4000;
    private int liftStack = 2500; //stacking height
    private int liftMin = 50;
    private int liftPlanck = 450; //smallest distance to increment lift by when using runToPosition

    boolean gripOpen = false;
    int gripOpenPos = 900;
    int gripClosedPos = 2110;

    public PickAndPlace(DcMotor motorLift, Servo servoGrip){
        this.motorLift = motorLift;
        this.servoGrip = servoGrip;
    }

    public void ToggleGrip (){
        if (gripOpen) {
            gripOpen = false;
            servoGrip.setPosition(ServoNormalize(gripClosedPos));
        }
        else {
            gripOpen = true;
            servoGrip.setPosition(ServoNormalize(gripOpenPos));
        }
    }


    public void stopLift(){
        motorLift.setPower(0);
    }

    public void raiseLift(){
        if(motorLift.getCurrentPosition() < liftMax) motorLift.setPower(.5);
        else motorLift.setPower(0);
    }
    public void lowerLift(){
        if(motorLift.getCurrentPosition() > liftMin) motorLift.setPower(-.5);
        else motorLift.setPower(0);
    }

    public void raiseLift2(){
        if (motorLift.getCurrentPosition() < liftMax && motorLift.getTargetPosition() < liftMax) {
            motorLift.setTargetPosition((int) Math.min(motorLift.getCurrentPosition()+ liftPlanck, liftMax));
            motorLift.setMode(DcMotor.RunMode.RUN_TO_POSITION);
            motorLift.setPower(1);
        }
    }
    public void lowerLift2() {
        if (motorLift.getCurrentPosition() > liftMin && motorLift.getTargetPosition() > liftMin) {
            motorLift.setTargetPosition((int) Math.max(motorLift.getCurrentPosition() - liftPlanck, liftMin));
            motorLift.setMode(DcMotor.RunMode.RUN_TO_POSITION);
            motorLift.setPower(.8);
        }
    }
    public void goLiftMax() {

            motorLift.setTargetPosition(liftMax);
            motorLift.setMode(DcMotor.RunMode.RUN_TO_POSITION);
            motorLift.setPower(1);

    }

    public void goLiftMin() {

        motorLift.setTargetPosition(liftMin);
        motorLift.setMode(DcMotor.RunMode.RUN_TO_POSITION);
        motorLift.setPower(1);

    }

    public void goLiftStack() {

        motorLift.setTargetPosition(liftStack);
        motorLift.setMode(DcMotor.RunMode.RUN_TO_POSITION);
        motorLift.setPower(1);

    }

    public int getMotorLiftPosition(){
        return motorLift.getCurrentPosition();
    }

    public static double ServoNormalize(int pulse){
        double normalized = (double)pulse;
        return (normalized - 750.0) / 1500.0; //convert mr servo controller pulse width to double on _0 - 1 scale
    }

}

Stopping Glyph Damage

21 Oct 2017
Stopping Glyph Damage By Abhi

Task: Stop Destroying Glyphs

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

Model:

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

Result:

The part itself is made out of nylon as usual. Our main issue was measuring the wheel accurately to create a functional part. The two parts hampering the design was that the U-shape must be off the ground slightly, and that the shape's semi-circle would not have the full radius of the wheel. So, we iterated through various designs of the U-shape, changing the height off the ground by ~1mm each time. We also varied the radius, until we realized that we could measure the width of where the semi-circle segued into the rectangle and get the estimated diameter of the semi-circle.

Meeting Log

21 Oct 2017
Meeting Log October 21, 2017 By Ethan, Tycho, Evan, Abhi, Charlotte, and Karina

Meeting Log October 21, 2017

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • Travis blog post
  • Work on presentation

Software

  • Work on openCV integration
  • Test out RoboRealm

Build / Modelling

  • Robot drive practice
  • Learn PTC
  • Jewel thief mockup

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
EthanWork on presentation2:004
TychoTravis blog post2:001
TychoOpenCV3:002
TychoRobotRealm4:002
CharlottePTC2:004
AbhiPTC2:004
KarinaDrive practice2:004
EvanJewel thief mockup2:004

Machine Vision Goals – Part 1

22 Oct 2017
Machine Vision Goals – Part 1 By Tycho

We’ve been using machine vision for a couple of years now and have a plan to use it in Relic Rescue for a number of things. I mostly haven’t gotten to it because college application deadlines have a higher priority for me this year. But since we already have experience with color blob tracking in OpenCV and Vuforia tracking, I hope this won’t be too difficult. We have 5 different things we want to try:

VuMark decode – this is obvious since it gives us a chance to regularly get the glyph crypto bonus. From looking at the code, it seems to be a single line different from the Vuforia tracking code we’ve already got. It’s probably a good idea to signal the completed decode by flashing our lights or something like that. That will make it more obvious to judges and competitors.

Jewel Identification – most teams seem to be using the REV color sensor on the arm their jewel displacement arm. We’ll probably start out doing that too, but I’d also like to use machine vision to identify the correct jewel. Just because we can. Just looking at the arrangement, we should be able to get both the jewels and the Vuforia target in the same frame at the beginning of autonomous.

Alignment – it is not legal to extend a part of the robot outside of the 18” dimensions during match setup. So we can’t put the jewel arm out to make sure it is between the jewels. But there is nothing preventing us from using the camera to assist with alignment. We can even draw on the screen where the jewels should appear, like inside the orange box below. This will also help with Jewel ID – we won’t have to hunt for the relevant pixels – we can just compare the average hue of the two regions around the wiffle balls.

Autonomous Deposition – this is the most ambitious use for machine vision. The dividers on the crypto boxes should make pretty clear color blob regions. If we can find the center points between these regions, we should be able to code and automatically centering glyph depositing behavior.

Autonomous glyph collection – ok this is actually harder. Teams seem to spend most of their time retrieving glyphs. Most of that time seems to be spent getting the robot and the glyphs square with each other. Our drivers have a lot of trouble with this even though we have a very maneuverable mecanum drive. What if we could create a behavior that would automatically align the robot to a target glyph on approach? With our PID routines we should be able to do this pretty efficiently. The trouble is we need to figure out the glyph orientation by analyzing frames on approach. And it probably means shape analysis – something we’ve never done before. If we get to this, it won’t be until pretty late in the season. Maybe we’ll come up with a better mechanical approach to aligning glyphs with our bot and this won’t be needed.

Tools for Experimenting

Machine vision folks tend to think about image analysis as a pipeline that strings together different image processing algorithms in order to understand something about the source image or video feed. These algorithms are often things like convolution filters that isolate different parts of the image. You have to decide which stages to put into a pipeline depending on what that pipeline is meant to detect or decide. To make it easier to experiment, it’s good to use tools that let you create these pipelines and play around with them before you try to hard-code it into your robot.

I've been using a tool called ImagePlay. http://imageplay.io/ It's open source and based on OpenCV. I used it to create a pipeline that has some potential to help navigation in this year's challenge. Since ImagePlay is open source, once you have a pipeline, you can figure out the calls to it makes to opencv to construct the stages. It's based on the C++ implementation of OpenCV so we’ll have to translate that to java for Android. It has a very nice pipeline editor that supports branching. The downside is that this tool is buggy and doesn't have anywhere near the number of filters and algorithms that RoboRealm supports.

RoboRealm is what we wanted to use. We’ve been pretty closely connected with the Dallas Personal Robotics Group (DPRG) for years and Carl Ott is a member who has taught a couple of sessions on using RoboRealm to solve the club’s expert line following course. Based on his recommendation we contacted the RoboRealm folks and they gave use a 5 user commercial license. I think that’s valued at $2,500. They seemed happy to support FTC teams.

RoboRealm is much easier to experiment with and they have great documentation so now have an improved pipeline. It's going to take more work to figure out how to implement that pipeline in OpenCV because it’s not always clear what a particular stage in RoboRealm does at a low level. But this improved pipeline isn’t all that different from the ImagePlay version.

Candidate Pipeline

So here is a picture of a red cryptobox sitting against a wall with a bunch of junk in the background. This image ended up upside down, but that doesn’t matter for just experimenting. I wanted a challenging image, because I want to know early if we need to have a clean background for the cryptoboxes. If so, we might need to ask the FTA if we can put an opaque background behind the cryptoboxes:

Stage 1 – Color Filter – this selects only the reddest pixels

Stage 2 – GreyScale – Don’t need the color information anymore, this reduces the data size

Stage 3 – Flood Fill – This simplifies a region by flooding it with the average color of nearby pixels. This is the same thing when you use the posterize effect in photoshop. This also tends to remove some of the background noise.

Stage 4 – Auto Threshold – Turns the image into a B/W image with no grey values based on a thresholding algorithm that only the RoboRealm folks know.

Stage 5 – Blob Size – A blob is a set of connected pixels with a similar value. Here we are limiting the output to the 4 largest blobs, because normally there are 4 dividers visible. In this case there is an error. The small blob on the far right is classified as a divider even though it is just some other red thing in the background, because the leftmost column was mostly cut out of the frame and wasn’t lit very well. It ended up being erased by this pipeline.

Stages 6 & 7 – Moment Statistics – Moments are calculations that can help to classify parts of images. We’ve used Hu Moments since our first work with machine vision on our robot named Argos. They can calculate the center of a blob (center of gravity), its eccentricity, and its area. Here the center of gravity is the little red square at the center of each blob. Now we can calculate the midpoint between each blob to find the center of a column and use that as a navigation target if we can do all this in real-time. We may have to reduce image resolution to speed things up.

Wheel Protector Correction

24 Oct 2017
Wheel Protector Correction By Abhi

Problem: Wheel Guard Innacuracy

Refering back to the design of the wheel guard, we decided it was time to actually mount it on the robot. At first, it seemed like the part was perfect for the robot since it fit just snug with the screws on the wheel. However, upon mounting, we discovered the following:

Turns out that the part is acutely shorter than the real height of wheel relative to the horizontal axis superimposed upon the vertical plane. As a result, a second and better trial for modeling needed to be conducted. For this run, I chose to measure the dimensions directly from the robot rather than a spare wheel.

Correction:

As seen above, the corrected version of the part looks and works much better. Though there is a slight margin of error in the success of the part due to the dynamic nature of the density of the field tiles , the part should be reliable for the most part

Working on Autonomous

29 Oct 2017
Working on Autonomous By Tycho

Task: Create a temporary autonomous for the bot

We attempted to create an autonomous for our first scrimmage. It aimed to make the robot to drive forward and drive into the safe zone. However, we forgot to align the robot and it failed at the scrimmage.

Instead of talking about the code like usual, the code's main functions are well documented so that any person can understand its functions without a prior knowledge of coding.

 public void autonomous2 (){

        switch(autoState){
            case 0: //moves the robot forward .5 meters
                if (robot.driveStrafe(false, .60, .35)) {

                    robot.resetMotors(true);
                    autoState++;
                }
                    break;
            case 1: //scan jewels and decide which one to hit
                if (robot.driveForward(false, .25, .35)) {
                    autoTimer = futureTime(1f);
                    robot.resetMotors(true);
                    autoState++;
                }

                break;
            case 2: //short move to knock off jewel

                robot.glyphSystem.ToggleGrip();
                autoTimer = futureTime(1f);

                robot.resetMotors(true);
                autoState++;
                break;
            case 3: //back off of the balance stone
                if (robot.driveForward(true, .10, .35)) {
                    autoTimer = futureTime(3f);
                    robot.resetMotors(true);
                    autoState++;
                }
                break;
            case 4: //re-orient the robot
                autoState++;
                break;
            case 5: //drive to proper crypto box column based on vuforia target
                autoState++;
                break;
            case 6: // turn towards crypto box
                autoState++;
                break;
            case 7: //drive to crypto box
                autoState++;
                break;
            case 8: //deposit glyph
                autoState++;
                break;
            case 9: //back away from crypto box
                autoState++;
                break;
        }
    }

Meeting Log

03 Nov 2017
Meeting Log November 03, 2017 By Ethan, Evan, Tycho. Austin, Charlotte, Karina, Janavi, Kenna, and Abhi

Meeting Log November 03, 2017

Today is one of the last full meetings until our tournament, so we need to get everything ready for judging. This post also includes the objectives for the next week.

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • 3 posts from each member
  • DISD Scrimmage post
  • Field build post
  • Strategy\Business plan
  • Print notebook
  • Finish presentation
  • Presention practice

Software

  • Autonomous
  • Drive practice

Build / Modelling

  • Respool string
  • Robot tuneup

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
Ethan3 posts2:002
EthanFinish presentation4:002
EvanTuneup2:004
TychoAutonomous2:002
TychoDrive practice4:002
EvanDrive practice2:004
AustinDrive practice2:004
AustinTuneup2:004
JanaviWork on presentation2:004
KennaPrint notebook2:004

Gripper Construction

04 Nov 2017
Gripper Construction By Tycho

Task: Making the Gripper

Standard parts were used to create the backbone. Then, we bent some tetrix parts to connect the backbone to the servos. We used continuous rotation cervos to solve the issue mentioned earlier. This was a fairly easy build but we still have a ways to go before V2 is completed.

This gripper will be far superior to our prior designs in that it will be lighter, as we are substituting wood and rubber for metal parts, which will solve our string breakage issue. As well, we will be able to grasp objects more securely, due to the rubber's larger coefficient of friction and that the gripper arms themselves have more surface area than our original design. Finally, our gripper will be more dependable due to slightly better wire organization than before.

This helps our strategy in that it will be far easier to pick up individual blocks, and helps us achieve our goal of grabbing multiple blocks at once. The wider gripper arms will make it so that we can stack blocks on top of each other before bringing them to the CryptoBox, which makes our robot 1.5x as fast in operating time.

How to make a part in PTC Creo Parametric

04 Nov 2017
How to make a part in PTC Creo Parametric By Abhi

Problem: How to Make a Part in Creo Parametric

PTC Creo Parametric is one of the best software to 3-D model tools that we can print out. I will detail how to create a part in Creo for both our team and any other teams who need help creating a piece. For this demo, Creo Parametric Academic Edition was used along with a pre designed model of the part.

To begin the model, create a new part. Make sure you are making the part in the right dimensions since the 3-D printer needs special requirements. For the 3-D printer that Iron Reign has, we chose to make all of our dimensions in millimeters. You can change this configuration by going into File>Prepare>Model Properties >Units.

Once your program is set to go, go under Model and press Sketch. This will create the base diagram which we will raise to make our part. Once the sketch menu appears, you will have to choose a plane on which we will draw. For this sketch, we will draw from the top plane since we want to raise it from the bottom. To do so, press on the top plane and press sketch. If the view is still in an isometric format, you can change the view by pressing the button indicated in the video.

Once the sketch is set up, we need to draw two concentric circles with the right dimensions. To find the dimensions, I refer often to the premade part. Once I have made the system, I set up centerlines vertically to be able to draw better. Next, I cut off the top two parts of the circle since we will put rectangles on them.

Next, select a line chain to draw two sets of rectangles with the bottom edge fused with the half circle. At the end, you should have a U shaped part. Now, we can draw another centerline along where we want the screw holes. After doing so, we can use the circle tool to make two holes in the rectangles.

We now need to extrude this part to the right size. After pressing the extrude took, we can change the size on the arrow. After doing so, we need to place two high radius thin circles on either sides. These are placed as weight pads so that when the part prints, it doesn't curve on the printing bed.

At this point, we can do some optional things to make our part..well lets say prettier. We can use the round tool so the edges look nicer and the screws are easier to place inside. After doing so, we can use the render tool to color all the edges. At the end, you will have a complete part to print

End result:

We hope you learned from this tutorial and are able to apply this to any future parts you make!

Designing the Jewel Thief

07 Nov 2017
Designing the Jewel Thief By Evan

Task: Design a part to remove the jewel

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

Relic Recovery Strategy Part 1

07 Nov 2017
Relic Recovery Strategy Part 1 By Austin

Task: Determine building strategy for Relic Recovery

Any well-versed team understands that, depending on the competition for the year, a robot will either be modified to compete or be built from the ground up. In any case, however, a robot often starts at its chassis, and teams have multiple companies that provide solutions to the common robot chassis’ needs and specifications. To name a few: AndyMark® has its standard kits that include all the parts and electronics needed to build a very basic frame that includes a few mounting points for the rest of the robot’s components, Tetrix has its standard kit that provides all the parts for an entire robot if used properly (however, we’ve discovered drawbacks to be mentioned later), and even REV has thrown its hat in the ring with new motor and battery types to add to the highly adjustable REV rail chassis kits. For rookie teams there is no lack of options for starting your robot chassis. However, as a team gains experience they find the flaws that come with each kit and move towards creating robots that harness equal amounts of parts from all companies. Here’s what we’ve learned about each company:

AndyMark: overall, AndyMark is a great supplier for all the standard parts you’ll need, however we wouldn’t recommend buying their overall chassis kits because they can be on the pricier side and come with few replacement parts and too many unnecessary parts. Most of our gears, wheels, pulleys, motors, and batteries come from AndyMark in batches of parts that we keep on hand to prototype with or replace failing parts. This keeps us from paying for parts we don’t need and having what we do need on hand. The overall quality of their parts is high, but they do decay quicker with use, especially when running the robot at multiple competitions without proper repair time.

Tetrix: Tetrix is highly standardized in all dimensions, making the connections between parts easy to grasp for basic builders who haven’t developed a mental 3D idea of what they’re working towards. Tetrix kits don’t include electronics. However, their brackets, channels, and joints are very useful for making connections between various components of your robot, so keep plenty on hand for quick fixes and prototyping. Our biggest concern with tetrix are their designated nuts; we find that they often are shaken completely off respective bolts, which can lead to mechanical failure and penalties. To combat the issue of robots quite literally shaking themselves apart, we recommend using nyloc nuts. They have a small amount of nylon in them that grips the threads of bolts making them almost immovable without a pair of pliers.

Rev: Iron reign loves our Rev rails. The ability to have a mounting point at any incident on a bar is amazing, and often allows us to pull off the crazy designs we create. Rev has created a system that is beyond flexible, meaning that the limits of your designs have expanded. For those who want a chassis that is easily maneuverable, Rev rail is extremely light as well. While Rev is expanding into providing parts like AndyMark, we find that they are still in development but we eagerly await upgrades.

Overall, Iron Reign wanted a robot chassis that was stable, maneuverable, and modular to our needs, so this is our compromise that we’ve applied to all aspects of our robot;

- AndyMark FRC Standard Omni-Wheels: we chose these because of their dependability and maneuverability. They provide standard motion as well as strafing for fine-tuning movements in front of cryptoboxes. While we had to print custom mounts, and modify tetrix channels for the necessary axels, the wheels pared nicely with the rest of our components once mounted.
- Rev Rail: our entire upper chassis is made from interconnected Rev Rails that serve as a smooth, easily adjustable, and light support for the massive omni wheels that rest below it. The rails provide plenty of room for future expansion, and can take quite a beating (we learned this the hard way by dropping our robot off a table).
- Tetrix Channels and Brackets: these are the middle men, the parts we change to fit those awkward angles and fittings, such as the axels for our wheels. Overall never a bad idea to have extras on hand.
- Hardware: we always use standard hardware sizes, but we make sure that the corresponding components are snug fitting and streamlined to minimize unnecessary snags and sharp edges.

While these are the typical components that make an Iron Reign base, we have seen other teams get extremely creative with raw material, although this usually requires heavy machinery such as laser cutters and lathes. Overall, we are a team that uses what companies provide and modify it to fit our needs (which has worked well for the past years of competition.) For smaller start up teams we recommend a similar approach of learning each system and its advantages over the course of multiple years, and finding what you feel works best for your needs.

Adding Code Fixes to the Robot

10 Nov 2017
Adding Code Fixes to the Robot By Tycho

Task: Add code updates

These commits add said functionality:

  • Pre-game logic - joystick control
  • Fix PID settings
  • Autonomous resets motor
  • Jewel Arm functionality
  • Autonomous changes
  • Tests servos

These commits allow better QoL for our drivers, allow our robot to function more smoothly both in autonomous and during TeleOp, allows us to score the jewels, and lets us test servos.

Jewel Arm


package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.hardware.NormalizedColorSensor;
import com.qualcomm.robotcore.hardware.Servo;

/**
 * Created by 2938061 on 11/10/2017.
 */

public class JewelArm {

    private Servo servoJewel;
    private NormalizedColorSensor colorJewel;
    private int jewelUpPos;
    private int jewelDownPos;

    public JewelArm(Servo servoJewel, NormalizedColorSensor colorJewel, int jewelUpPos, int jewelDownPos){
        this.servoJewel = servoJewel;
        this.colorJewel = colorJewel;
        this.jewelUpPos = jewelUpPos;
        this.jewelDownPos = jewelDownPos;
    }

    public void liftArm(){
        servoJewel.setPosition(ServoNormalize(jewelUpPos));
    }
    public void lowerArm(){
        servoJewel.setPosition(ServoNormalize(jewelDownPos));
    }

    public static double ServoNormalize(int pulse){
        double normalized = (double)pulse;
        return (normalized - 750.0) / 1500.0; //convert mr servo controller pulse width to double on _0 - 1 scale
    }

}

Autonomous

		public void autonomous(){
        switch(autoState){
            case 0: //scan vuforia target and deploy jewel arm
                robot.jewel.lowerArm();
                autoTimer = futureTime(1.5f);
                if(autoTimer < System.nanoTime()) {
                    relicCase = getRelicCodex();
                    jewelMatches = robot.doesJewelMatch(isBlue);
                    autoState++;
                }
                break;
            case 1: //small turn to knock off jewel
                if ((isBlue && jewelMatches)||(!isBlue && !jewelMatches)){
                    if(robot.RotateIMU(10, .5)){
                        robot.resetMotors(true);
                    }
                }
                else{
                    if(robot.RotateIMU(350, .5)){
                        robot.resetMotors(true);
                    }
                }
                break;
            case 2: //lift jewel arm
                robot.jewel.liftArm();
                autoTimer = futureTime(1.5f);
                if(autoTimer < System.nanoTime()) {
                    jewelMatches = robot.doesJewelMatch(isBlue);
                    autoState++;
                }
            case 3: //turn parallel to the wall
                if(isBlue){
                    if(robot.RotateIMU(270, 2.0)){
                        robot.resetMotors(true);
                        autoState++;
                    }
                }
                else{
                    if(robot.RotateIMU(90, 2.0)){
                        robot.resetMotors(true);
                        autoState++;
                    }
                }
                autoState++;
                break;
            case 4: //drive off the balance stone
                if(robot.driveForward(true, .3, .5)) {
                    robot.resetMotors(true);
                    autoState++;
                }
                break;
            case 5: //re-orient robot
                if(isBlue){
                    if(robot.RotateIMU(270, 1.0)){
                        robot.resetMotors(true);
                        autoState++;
                    }
                }
                else{
                    if(robot.RotateIMU(90, 1.0)){
                        robot.resetMotors(true);
                        autoState++;
                    }
                }
                break;
            case 6: //drive to proper crypto box column based on vuforia target
                switch (relicCase) {
                    case 0:
                        if(robot.driveForward(true, .5, .35)) {
                            robot.resetMotors(true);
                            autoState++;
                        }
                        break;
                    case 1:
                        if(robot.driveForward(true, .75, .35)) {
                            robot.resetMotors(true);
                            autoState++;
                        }
                        autoState++;
                        break;
                    case 2:
                        if(robot.driveForward(true, 1.0, .35)) {
                            robot.resetMotors(true);
                            autoState++;
                        }
                        autoState++;
                        break;
                }
                break;
            case 7: //turn to crypto box
                if(isBlue){
                    if(robot.RotateIMU(315, 1.5)){
                        robot.resetMotors(true);
                        autoState++;
                    }
                }
                else{
                    if(robot.RotateIMU(45, 1.5)){
                        robot.resetMotors(true);
                        autoState++;
                    }
                }
                break;
            case 8: //deposit glyph
                if(robot.driveForward(true, 1.0, .50)) {
                    robot.resetMotors(true);
                    robot.glyphSystem.ReleaseGrip();
                    autoState++;
                }
                break;
            case 9: //back away from crypto box
                if(robot.driveForward(false, .5, .50)){
                    robot.resetMotors(true);
                    autoState++;
                }
                break;
            default:
                robot.resetMotors(true);
                autoState = 0;
                active = false;
                state = 0;
                break;
        }
    }
    public void autonomous2 (){

        switch(autoState){
            case 0: //scan vuforia target and deploy jewel arm
                robot.jewel.lowerArm();
                autoTimer = futureTime(1.5f);
                if(autoTimer < System.nanoTime()) {
                    relicCase = getRelicCodex();
                    jewelMatches = robot.doesJewelMatch(isBlue);
                    autoState++;
                }
                break;
            case 1: //small turn to knock off jewel
                if ((isBlue && jewelMatches)||(!isBlue && !jewelMatches)){
                    if(robot.RotateIMU(10, .5)){
                        robot.resetMotors(true);
                    }
                }
                else{
                    if(robot.RotateIMU(350, .5)){
                        robot.resetMotors(true);
                    }
                }
                break;
            case 2: //lift jewel arm
                robot.jewel.liftArm();
                autoTimer = futureTime(1.5f);
                if(autoTimer < System.nanoTime()) {
                    jewelMatches = robot.doesJewelMatch(isBlue);
                    autoState++;
                }
            case 3: //turn parallel to the wall
                if(isBlue){
                    if(robot.RotateIMU(270, 2.0)){
                        robot.resetMotors(true);
                        autoState++;
                    }
                }
                else{
                    if(robot.RotateIMU(90, 2.0)){
                        robot.resetMotors(true);
                        autoState++;
                    }
                }
                autoState++;
                break;
            case 4: //drive off the balance stone
                if(robot.driveForward(true, .3, .5)) {
                    robot.resetMotors(true);
                    autoState++;
                }
                break;
            case 5: //re-orient robot
                if(isBlue){
                    if(robot.RotateIMU(270, 1.0)){
                        robot.resetMotors(true);
                        autoState++;
                    }
                }
                else{
                    if(robot.RotateIMU(90, 1.0)){
                        robot.resetMotors(true);
                        autoState++;
                    }
                }
                break;
            case 6: //drive to proper crypto box column based on vuforia target
                switch (relicCase) {
                    case 0:
                        if(robot.driveStrafe(true, .00, .35)) {
                            robot.resetMotors(true);
                            autoState++;
                        }
                        break;
                    case 1:
                        if(robot.driveStrafe(true, .25, .35)) {
                            robot.resetMotors(true);
                            autoState++;
                        }
                        autoState++;
                        break;
                    case 2:
                        if(robot.driveStrafe(true, .50, .35)) {
                            robot.resetMotors(true);
                            autoState++;
                        }
                        autoState++;
                        break;
                }
                break;
            case 7: //turn to crypto box
                if(isBlue){
                    if(robot.RotateIMU(215, 1.5)){
                        robot.resetMotors(true);
                        autoState++;
                    }
                }
                else{
                    if(robot.RotateIMU(135, 1.5)){
                        robot.resetMotors(true);
                        autoState++;
                    }
                }
                break;
            case 8: //deposit glyph
                if(robot.driveForward(true, 1.0, .50)) {
                    robot.resetMotors(true);
                    robot.glyphSystem.ReleaseGrip();
                    autoState++;
                }
                break;
            case 9: //back away from crypto box
                if(robot.driveForward(false, .5, .50)){
                    robot.resetMotors(true);
                    autoState++;
                }
                break;
            default:
                robot.resetMotors(true);
                autoState = 0;
                active = false;
                state = 0;
                break;
        }
    }

Greenhill FTC Qualifier

11 Nov 2017
Greenhill FTC Qualifier By Ethan, Evan, Tycho, Charlotte, Austin, Abhi, Tycho, Karina, and Kenna

Task: Compete at our first FTC qualifier

So, we were absolute failures. There's no way to get around that. We got 14th place out of 14, and our presentation flopped. But, its not the end of the world, even if it may feel like it. We have another qualifier in Oklahome in one week, and we need to analyze what we did wrong so that we can improve for the next round.

  • Match 1
  • We lost, 79-93. This was our closest match, and if we had managed our time in-game more wisely, we could have won by balancing. This was our only game in the margin-of-error.
  • Match 2
  • We lost 101-131. The other alliance outperformed us in scoring glyphs, and was able to knock an additional jewel off in autonomous.
  • Match 3
  • We lost 28-65. We failed on every level, even to balance our robot. Our bot was on for about 10 seconds for the entire match.
  • Match 4
  • We lost 111-181. We scored only 3 glyphs and underperformed in autonomous.
  • Match 5
  • We lost 61-203. Our robot was not on.

We had many failures in the robot game. Our first, main failure was lack of practice. We only really dedicated ourselves to driving practice two weeks before, and we had trouble aligning the blocks throughout the day. In prior years, we had started drive practice from over a month out, so this was a major failure on our part. A second failure that wasn't our fault was that we had connection issues between the phones, and weren't able to drive in two rounds. But, because of our collective failures, we managed not to win a single game. However, we ended up with the second heighest rank points in the whole tournament (380).

Our presentation was a failure too. We hadn't practiced our presentation enough, and it seemed a bit janky at points. In addition, our engineering journal was a bit rushed, as we'd printed the night before and had some issues printing. We also didn't turn the control award in. However, one highlight of the judging is that we were able to answer questions quickly and effectively, and the judges seemed to like that. We did end up winning the Connect Award.

Reflections

This tournament was one of Iron Reign's worst. However, we must learn from that so we don't repeat our mistakes. The silver lining of this tournament is that we can't really preform any worse :).

Driving Struggles

13 Nov 2017
Driving Struggles By Abhi

Task: Drive the Robot

Today we tried to drive the robot on the practice field for the first time since the qualifier last Saturday. However, we couldn't get in very much quality drive practice because the robot kept breaking down. We decided to dig a bit deeper and found some issues.

As seen above, the first thing that was wrong was that the lift was tilted. Due to the cantilever orientation of the plank of the grabber arm mounted on the vertical axis, the structure only had one bar for support for the lift. As a result, since the construction of our robot, the rev rail of the mount had been worn out constantly up to the point where it broke. Also because of the singular rod mounting, the lift system rotated on the vertical planar axis creating a need for drivers, such as myself, to rotate into the cryptobox every time we needed to mount. This was not a good way for the robot to function and had frustrated us.

Another issue we had was that the lift system string was caught often in all the wiring of the robot. Due to the friction created between this string and all the wiring, including the jewel system, it breaks the string and also creates a safety issue. As a result, we need to fix either the wiring of the robot or the lift system altogether.

Reflections

We hope to make improvements over this week before the Oklahoma qualifier. Hopefully, we will have a more proficient robot making it easier on our drivers.

Gripper Part 2

13 Nov 2017
Gripper Part 2 By Evan

Update:

The task today was simple. We replicated the prior work with the first gripper, as stated in the prior post, so we can begin connecting them. The biggest problem was finding all the parts to make it. We are hoping we can connect and mount them in the next couple days so it will be ready for the qualifier in Oklahoma. The improvement over last post was the addition of the rubber gripping material, as found in our "Material Test" post.

Code Fixes and Readability

13 Nov 2017
Code Fixes and Readability By Tycho

Task: Make the code more readable

So, we can't include all the code changes we made today, but all of it involved cleaning up our code, removing extra functions we didn't use, refactoring, adding comments, and making it more readable for the tournament. We had almost 80k deletions and 80k additions. This marks a turning point in the readablity of our code so that less experienced team members can read it. We went through methodically and commented out each function and method for future readability, as we will have to pass the codebase on to next year's team.

Control Award

15 Nov 2017
Control Award By Janavi

Task:

Last Saturday, after our qualifier, we had a team meeting where we created a list of what we needed to do before our second qualifier this Saturday. One of the tasks was to create the control award which we were unfortunately unable to complete in time for our last competition.

Autonomous Objective:

  1. Knock off opponent's Jewel, place glyphs In correct location based on image, park in safe zone (85 pts)
  2. Park in Zone, place glyph in cryptobox (25 pts)

Autonomous B has the ability to be delayed for a certain amount of time, allowing for better coordination with alliance mates. If our partner team is more reliable, we can give them freedom to move, but still add points to our team score.

Sensors Used

  1. Phone Camera - Allows the robot to determine where to place glyphs using Vuforia, taking advantage of the wide range of data provided from the pattern detection, as well as using Open Computer Vision (OpenCV) to analyze the pattern of the image.
  2. Color Sensor - Robot selects correct jewel using the passive mode of the sensor. This feedback allows us determine whether the robot needs to move forwards or backwards so that it knocks off the opposing teams jewel
  3. Inertial Measurement Unit (IMU) - 3 Gyroscopes and Accelerometers return the robot’s heading for station keeping and straight-line driving in autonomous, while letting us orient ourselves to specific headings for proper navigation, crypt placing, and balancing
  4. Motor Encoders - Using returned motor odometry, we track how many rotations the wheels have made and convert that into meters travelled. We use this in combination with feedback from the IMU to calculate our location on the field relative to where we started.

Key Algorithms:

  1. Integrate motor odometry, the IMU gyroscope, and accelerometer with using trigonometry so the robot knows its location at all times
  2. Use Proportional/Integral/Derivative (PID) combined with IMU readouts to maintain heading. The robot corrects any differences between actual and desired heading at a power level appropriate for the difference and amount of error built up. This allows us to navigate the field accurately during autonomous.
  3. We use Vuforia to track and maintain distance from the patterns on the wall based on the robot controller phone's camera. It combines 2 machine vision libraries, trig and PID motion control.
  4. All code is non-blocking to allow multiple operations to happen at the same time. We extensively use state machines to prevent conflicts over priorities in low-level behaviors

Driver Controlled Enhancements:

  1. If the lift has been raised, movement by the jewel arm is blocked to avoid a collision
  2. The robot has a slow mode, which allows our drivers to accurately maneuver and pick up glyphs easily and accurately.
  3. The robot also has a turbo mode. This speed is activated when the bumper is pressed, allowing the driver to quickly maneuver the field.
Autonomous Field

Intake Grippers Pt2

15 Nov 2017
Intake Grippers Pt2 By Evan

Task: Attach the new intake grippers

The basters are here and in full swing. We spent a late night putting together the two intake columns. They were attached to a backing by previously, allowing to finish it by attaching the final servo and tieing it to the two columns. Since the new intake needed new code, we whipped up some code to allow us to have control. Upon doing this he realized we needed two controllers, one for movement and controlling the lift, and a second purely to work the two columns as they spun. This allowed the operator to operate the whole robot just a little easier. The new columns are set on a majority REV base, allowing for more choices in design that normal tetrix doesn’t provide. The new grabber has already been placed on the robot and seems to be working smoothly, only time will tell if it is a long term solution.

Oklahoma Qualifier Recap

18 Nov 2017
Oklahoma Qualifier Recap By Ethan, Evan, Austin, Janavi, Charlotte, Kenna, Tycho, Karina, and Abhi
Task: Compete at the Oklahoma Qualifier

Once done, our postmortem post will be here.

On Nov. 17, we went to the Oklahoma Mustang HS qualifier. Our strategy for this tournament was to attempt to qualify in multiple regions so that we have more chances to get to the South Super Regionals. For this tournament, the DISD STEM Dept. funded the tournament fees for us to attend, as well as housing for our team. We drove down there on our RV, and also fixed it up so that we could convert it into tournament mode.

For out-of-area tournaments, we have to prepare ahead of time so that we can get everything we need, since we can't really go back to get parts we forgot. So, this time, we created a packing list in order to ensure that we have everything on the RV before we leave. The complete list is below.

Tent / Pits

  • Shield
  • Main robot Cart
  • Small carts (x2)
  • Banner stand
  • Main banners (x3)
  • Aquila
  • Inspire
  • Inspire mount
  • Monitor
  • Extension cord(s)
  • Power Strip(s)

Field Elements

  • Cryptobox
  • Foam blocks
  • Jewels
  • Jewel base
  • Vuforia pattern on stick

Tools

  • Staticide
  • Shamwow
  • Threadlock
  • Red (x3), Blue (x3), Green (x3) hex keys
  • Flat heads: Large (x2), Small (x2)
  • Phillips heads: Large (x2), Small (x2)
  • Modular screwdrivers + bits (Cyan wrenches)
  • Rubber bands / Hair Ties?
  • String for pulley system
  • Container store chest of drawers
  • Chain Box
  • Tape Box
  • Glue + putty Box
  • Large pliers
  • Needlenose pliers
  • Regular Pliers
  • Power pole Box + stuff with that
  • Xacto knifes
  • Regular knifes
  • Zip ties
  • Axles
  • Drills
  • Yellow Drill (x2)
  • Drill batteries + chargers
  • Electric screwdrivers + bits
  • Plugin drill
  • Wire strippers
  • Measuring tape
  • Dremel
  • Reciprocating Dremel
  • Circular Dremel
  • Sawblade
  • Evil sandpaper
  • Battery
  • Charger
  • Hack saw
  • Hammer
  • Mallet
  • Bolt cutters
  • Lighter
  • Core power distribution Box

Parts

  • Standard nuts + bolts
  • Extrusion nuts + hex bolts
  • Prototyping wire
  • Tetrix pieces
  • U pieces
  • Plates
  • Phone cases - ZTE + SG5
  • Extrusions (Cap lift size)
  • Extrusion brackets

Electronics

  • Phones
  • All cables that we can get our hands on
  • Phone cables(new and old)
  • Coding cables        
  • OTG cables
  • Printer
  • Computers
  • Battery Box - phone
  • Joysticks
  • 9-volt batteries
  • All wrenches
  • Spare Core Power Distribution Module Box
  • M-M cable
  • M-F cable

Organization (Boxes)

  • Judging Box
  • Damaged foam block
  • Example of abs 3-D printing
  • Drawer Slide                      
  • All grabber prototypes
  • Turkey baster ones
  • Conveyer belt one
  • Current one on robot
  • Tape Box
  • Foam tape
  • Gaff tape
  • Duct tape
  • Duct tape
  • Double sided
  • More + ........
  • Glue + Putty Box
  • Battery Box
  • Batteries
  • Phone cables
  • Phone + Charging Box
  • Joystick Box
  • Powerpole Box
  • Tri-Crimp
  • Powerpoles
  • Wire stripper
  • Wire clipper
  • Needle nose
  • Container store chest of drawers
  • Chain Box
  • Spare Core Power Distribution Module Box

Before leaving, we had already encountered problems. Our RV's generator refused to turn on, which meant that we couldn't get AC, chargers, or any electrical components on board to work. So, we had to do a last-minute oil change. As well, we had trouble finding several important tool parts, such as our box of drill bits and other things. Running about an hour late, we finally left for Oklahoma. The drive took the usual 4 hours, stopping to get Schlotzky's™, and we arrived at midnight. After we were all assigned to our rooms and all, we did another runthrough of our presentation, then went to bed

We woke up by 7am the next day, and slogged our way out of bed to the Mariott™ Contentental™ Breakast™. Over breakfast, we discussed our strategies and rules for the tournaments. Some of the major points are these:

  • Unless your work requires it, stay off the RV and in the pit
  • If possible, try to talk to as many teams as possible, hand out flyers
  • When you see judges roaming the tournament, try to flag them down to talk
  • Try to get as many people as possible to see the RV
  • Do scouting ASAP

Flyer

Inspection


We didn't manage our time well for inspection. We hadn't really prepared our robot back in Dallas, nor on the way, so we had to attach the side panels and the buttons right as we arrived. As well, we had to make sure the bot fit within the sizing cube. Overall, our preparation for this section of the tournament was 4/10.

Judging/Presentation


This was our largest improvement from last tournament. This was probably the best presentation we've put on yet. As well, our engineering journal was indexed a little bit better than last time. The judges also seemed receptive to our presentation and asked in-depth questions on our robot, which was very enjoyable and signalled that we would be considered for future awards. As well, we managed to get every judge in the tournament on the RV, every single referee, and about half the teams total. So, we did well on that front. As well, our strategy of trying to talk to every judge worked well, as we were able to cover a variety of subjects, ranging from our design process, to business, to our outreach, to women in STEM.

Robot Game

Our time-management overall here was not great. We'd rush to the practice field to try and fix parts, then get immediately called back to the round. I think we almost got disqualified 3 or 4 times because of this. However, this was our most successfull tournament in the robot game ever, since this was our first time getting 1st alliance captain.
Game 1
Game 1 was one of the two games we lost this tournament. We lost by 20 points, and we managed to both knock the opposing team's jewel off, as well as not balance in the end-game. This match highlighted the problems with our autonomous' reliablility.
Game 2
In game 2, we still had autonomous problems, but won a close game due to our stacking.
Game 3
Game 3 was our best game, as we didn't experience any connection issues and got almost 200 points.
Game 4
In game 4, our robot shut down throughout the game, but despite that, we ekeed out a close victory.
Game 5
We won game 5 by about 30 points, as we stacked 2 columns, got a jewel, and balanced our bot.
At this point, we became an alliance captain and chose team 3732 Technical Difficulties to be our partner. We had connection problems throughout the next games that hampered our ability to score.
Semi-Finals 1
We won 80-100, despite connection issues.
Semi-Finals 2
We improved a little and got about 120 points as we fixed a servo between matches.
Final 1
We lost this game due to connection issues.
Final 2
This was our closest game, as we won by 2 points, since we were able to stack blocks *slightly* faster.
Final 3
We won this game by 20+ points as the opposing team failed to balance one bot.

Ceremony

The first award we won was the First Alliance Captain award, a first for our team, so we were overjoyed about that. Then, we also won 1st place Control Award, another first for our team. This was especially suprising, as our autonomous failed quite a bit throughout the tournament. Finally, we won 2nd place Inspire Award. While this is still a great accomplishment, we'd like to work on this a bit more and get 1st place next tournament in January.

Grabber Arms v3

25 Nov 2017
Grabber Arms v3 By Abhi and Karina

Task:Develop a More Efficient System

At the Oklahoma qualifier, we saw numerous teams with similar systems to that of ours. However, since we had the mobilized gripper arms to stack with auto alignment, we were able to collect glyphs easier. In spite of that, after observing other teams in action, we realized our current gripper method had the issue of not being ready by the time we got back to the cryptobox. This is because we had to turn around everytime we needed to pick up glyphs and we also needed to pick up glyphs. This leads to longer time to fill the cryptobox, something that is not good if we plan on recovering the relic later in the season. As a result, we decided to upgrade our arms to a new level: a chain based intake system.

The idea behind this system is that the grabber arms would be on a mobilized chain system, kind of like a conveyor belt. One of the reasons this is much faster than our old system is that we don't need to turn our robot around as we approach the cryptobox. We can drive forward, pick up glyphs, and as we drive backwards, we can use a toggled button on our gamepad to move the grabber arms to the back of the robot upright. As a result, by the time we get back to the cryptobox, we have the glyphs ready to place.

Another benefit of this new system is that we don't need to stack glyphs. When we drive forward to pick up glyphs, we can tilt the grabber arms forward so that even if the pre stacked glyphs look far apart, they can still be in-took with the tilted system. Also, this system can be used for intaking the relic in the future. If the chain system is placed on an elevated level on our robot, the grabber arms will be taller than the field walls. Because of this, if we pick up the relic when it is on the ground, we can place it easily.

This picture represents our current progress. We hope to complete this system soon so we can test it on the robot.

Oklahoma 2017 Post-Mortem

27 Nov 2017
Oklahoma 2017 Post-Mortem By Ethan, Evan, Tycho, Austin, Janavi, Kenna, Abhi, Charlotte, and Karina

Task: Recap what went right and wrong in Oklahoma

Even though we did very well in the Oklahoma qualifier, we still encountered several problems, that if not addressed, could lower our chances of getting to Super-Regionals. So, we had a team discussion on what to do differently in the next tournament, and what to keep constant.

Problems

Time management
Our time management was Not Good. First, we had trouble coordinating with different parts of the team, which lead to disorganization. As an example, we nearly missed judging because we had to go to inspection, then we nearly got DQ'd from several matcvhes because we kept going back to the practice field instead of queuing. So we need to clearly schedule when to go to practice field and when to not, as well as coordinate the judging, inspection, and other important events.
Referring to coach
We didn't realize that the judges were judges in the pit and one of our members refered to our coach for help, which probably hurt our chances.
Preparedness
First, on the robot side, we hadn't prepped for inspection the night before, so we had to be in a rush the day of to get ready. As well, we still hadn't made a coherent model of our robot in Creo by OK, which hurt our judging chances. And, we didn't emphasize the design process enough.
Presentation
For some reason, our robot kept glitching out *only* during the presentation, which hurt us. And even though our presentation was better than last time, we still had a lot of pauses that could've been remedied easily with more practice.
Robot Stability
While our robot worked pretty well during the first 5 rounds, once we hit the final rounds, our robot started shutting down and being hard to operate. We still don't know the reason, but we're currently diagnosing now.

To-do

  • Static-proof robot
  • Fix wiring
  • Organize journal for award
  • 3D Model
  • Expand engineering section
  • Build 2nd field
  • Shock mount robot

Gripper v4, Octopuckers

03 Dec 2017
Gripper v4, Octopuckers By Tycho and Abhi

Task: Design a new piece for intake

Version 2 of our gripper arms worked much better than our original. Due to their silicone material and trianglular shape, we definitely had more control over the glyphs than our one degree of freedom grabber arms. However, we still had issues we needed to address. When glyphs were taken in, since the silicone surface did not have much mobility and compressibility, glyphs would often fall. Due to slight changes in glyph size, the bigger glyph would determine the space between the grabbers, meaning the other glyph would be mobile despite us wanting its control. This is when we develoepd the first version of our new rotators.

The first edition of our rotatory mechanism allowed us to play with ninjaflex printing and flexibility. They were 15mm extrusions designed to stack on one another on a REV rail or similar rigid structure. Since Ninjaflex can bend, we got more grip on the glyphs. It was definetely a well designed model but had many issues. First, each fin of the fan was very thick. Though it was able to grip glyphs well alone, the system was not able to grip much better when stacked together. We decided we needed more surface area contact with glyphs during intake.

This led us to create a new model with thinner fins and thin tabs at the end. The thin flaps allowed more grip area with the glyphs allowing us to work better. Though good in theory, when we went to print out the part, we discovered our 3-D printer didn't allow printing vertically of surfaces less than 1 mm. Since this idea didn't work, we started thinking of the idea of suction cups. This led us to our current design.

The design worked very well. We decided to name them Octopuckers since they had suction cup shape and there were 8 fins to a pucker. The surfaces of the octopuckers which would contact the glyphs were large and had a large area. Since this was heavier than the bridge connecting them to the center, the branches bent easily allowing for a grippy surface which was also flexible. After testing it on a small scale, it seemed to work well so we will continue development and implement it on our next edition of the grabber arms.

REVolution Simple Dual Rail Plate

11 Dec 2017
REVolution Simple Dual Rail Plate By Tycho

Task: Power to the REVolution

The dual rail plate allows you to couple the rotation of two REVrails together. The distance between the holes should be based on how you are coupling them together. This model is designed to use GT2 5mm pulleys and a 46 gap timing belt.

REVolution Basic HingePlate

11 Dec 2017
REVolution Basic HingePlate By Tycho

Task: Power to the REVolution

This is our most used hinge plate. The 4 holes can take M3 screws to attach to a REVrail on one side at the end.

REVolution Narrow Inside Washer

20 Dec 2017
REVolution Narrow Inside Washer By Tycho

Task: Power to the REVolution

This washer is a stackable spacer that can be used to adapt standard bearings/sprockets/pulleys to thinned base plates.

REVolution Thick HingePlate

22 Dec 2017
REVolution Thick HingePlate By Tycho

Task: Power to the REVolution

This is our most used hinge plate. The 4 holes can take M3 screws to attach to a REVrail on one side at the end.

REVolution Pillow Block

22 Dec 2017
REVolution Pillow Block By Tycho

Task: Power to the REVolution

This is a standard pillow block. We had to add adhesion pads to the ends because the nylon would curl away from the print bed. But these are easily cut off with a hobby knife.

Jewel Thief

23 Dec 2017
Jewel Thief By Austin and Evan

Task: Build a Functional Jewel Thief

The jewel thief we built before *worked* but that was about it. More often than not, it failed or, even worse, knocking off the wrong jewel due to instability. And, in the Greenhill Qualifier, we lost several rounds because of a problem that could've been easily fixed. So, we had to redesign it.

The jewel thief was initially intended to be simple. It was comprised of no more than a 180 degree rotation servo and an arm with a standard rev color sensor. The arm was foldable and collapsible so that it would fit inside our robot, and as the servo turned out to its extended position the arm would open up with the help of a single bungee cord.

This plan had a few inital downfalls: first, the arms were rather large, clunky, and never really folded well into position, second the arms was heavy due to the use of tetrix bars meaning that the servo would strain, and finally the overal position of the arm was inconvenient for our autonomous programing, so we moved on completely. Rather than focusing on a single arm that could extend to reach the jewels, we decided to focus on something that would conform well to our current setup and then focus on making it long enough to reach. We realized that the outer edge of the robot was open enough to contain a V-shaped device that would rise 180 degrees over the head of our robot. The immediate perk to this was the fact that the system would be 18 inches in length. We felt no need to update which sensor we were using at the end of whatever mechanisim we finally attached, since the rev color sensor served it purpose correctly and effectively each time we had tested it in the past. Our final design was the V-shaped rim that laid flush with our robots exterior and was made from cut and bent L-bracket and was moved with two continuous rotation servos.

REVolution 15x20 Tooth Sprocket

23 Dec 2017
REVolution 15x20 Tooth Sprocket By Tycho

Task: Power to the REVolution

This is our REV0lution 20 tooth sprocket for #25 chain. This took a lot of trial and error to get right, because it was the component most sensitive to our print settings. We had to inset the tooth profile quite a bit because any extra material created by perimeter settings would cause the gaps between teeth to be too small for the chain to fully engage, and because nylon is so slippery, this would radically increase the likelihood of the chain slipping. Or you would have to make the chain super-tight and that would increase the friction at the bearing. It still requires a pretty tight chain. And it requires a lot of post-print cleanup. The lip where the lowest layers spread out on the build plate have to be trimmed with a hobby knife - all the way around. And then the chamfers at the tip of the teeth have to be rebuilt. We used a reciprocating sander to do this. Nylon is one of the hardest materials to sand effectively, but fresh 220 grit paper will eventually do the job. We only need 2 sprockets for our new Glyph System, so it was worth the effort. This would be the first component that we would recommend replacing with a regular flat aluminum sprocket if you have the means to accurately broach a 15mm square hole in it. Or switch over to timing belts entirely - the timing pulley works fine right off the print bed.

REVolution Rail End Cap

23 Dec 2017
REVolution Rail End Cap By Tycho

Task: Power to the REVolution

End caps are stops placed at the end of a REVrail. Five of the holes are for M3 bolts that can be screwed into the standard holes in the cross section of the extrusion. We highly recommend tapping these holes and then using threadlock to retain the bolts. So far we’ve only had to use a single bolt since we haven’t experienced very large forces The other 4 bolts are for attaching to a bearing on the far side of an attachment plate.

REVolution Rail Stop

25 Dec 2017
REVolution Rail Stop By Tycho

Task: Power to the REVolution

This stop can be placed anywhere on a REVrail to trap mounting plates inside bearings. They are usually used in pairs.

REVolution Custom Dual Rail Plate

26 Dec 2017
REVolution Custom Dual Rail Plate By Tycho

Task: Power to the REVolution

This shows customized version of the Dual Rail Plate. This is for our 4th generation rolling gripper system. The small ears are designed to hold a long M3 bolt that have a stack of mini ball bearings on them. These ball bearings squeeze our timing belts together, forcing them into a more oval shape, but still allowing them to glide. This reduces friction quite a bit. Otherwise we had to put a lot more tension between the pulleys to get the belt to fully engage. This plate also has grooves to attach servo pulled wires to control the plates angle one of the REVrails and it has a flange to mount our beater guards.

REVolution Narrow Bearing Washer

27 Dec 2017
REVolution Narrow Bearing Washer By Tycho

Task: Power to the REVolution

Washers can be used as spacers. They are also used to smooth out the rough top layers. Keep the bed very clean and smooth and the bottom surface of parts should be very slippery against other nylon. Put these in between the rough top bearing surface of one part (with rough surface facing rough) and the smooth bottom surface of the next part, and the friction will be substantially reduced.

REVolution Inside Washer

27 Dec 2017
REVolution Inside Washer By Tycho

Task: Power to the REVolution

This is an inside washer. It will fit entirely inside the standard plate hole. We don’t use these much, but they can be useful as spacers.

Flipper Prototype

29 Dec 2017
Flipper Prototype By Evan

Task: Build an alternate glyph-placing mechanism

The world advances on innovation. We strive to make the most efficient devices and aparati to complete jobs for us. There’s a hundred different ways to work a task, but only one will be the best at functioning in the areas of efficiency and timeliness. Just as America runs on Dunkin, advancement runs on efficiency. That’s why the robot must be outfitted with a flipper system to intake and deposit blocks. It’s the only design that will make it to the world competition, and it’s the only way that we will make it out of local competitions. I personally have taken it upon myself to develop the prototype while the majority of the team is focussed on a new grabber arm.

While our grabber arms were *good*, they weren't great. The arms currently attached to the robot, which use the turkey-pans, didn't grip as much as we hoped, and while we're designing a new version which has specialized 3-D printed arms, we can't put all our eggs in one basket. So, we decided to make the flipper system. The advantages of the flipper system as compared to the other systems is that the flipper system:

  • Does not depend on friction to hold blocks
  • We had previous issues with block slippage with the arms model, and this should fix our dependency on high-friction materials.
  • Faster
  • Our old arms depended on stacking to get more than one block, while this one wheels blocks in, reducing the time needed.
  • Less precision needed
  • Before, we had to align blocks directly with the arms to pick them up, but this can just use the wheels to intake blocks.

So far I have built a flipper and an intake system, both that function well, but have yet to get the teams’ permission to attach it directly to the robot, as it would require a lot of dismantling. Since it won’t be able to be put on before the upcoming Wylie qualifier, it’s been put on a backburner as I also throw myself at the new grabber arm. The flipper is being held in a frame I built around it but as a system is comprised of a board attached to a servo attached to a drawer slide that works as a vertical lift. The intake system is composed of two intake wheels made of the same foam tiles that make up the field floor attached to two axles that are chained to two opposite rotating gears powered by one of the new REV motors. The intake works with the flipper well and only needs some side guards. I’m half of the way through designing. It should be on the robot before any regional qualifiers we go to.

Introducing Kraken

01 Jan 2018
Introducing Kraken By Abhi and Tycho

Task:Design the robot model

We have finally completed assembly modeling Kraken, Iron Reign's Relic Recovery robot. Named after the sea creature due to the robot's OCTOPUCKERS, Kraken stands as a fierce competitor in FTC.

To the chassis, we added the glyph system mounting. We first designed a linear slide replica and constrained that to a small TETRIX U connector piece which attached to the REV rail base. On the other side of the linear slide was a TETRIX bar attached by distance and coincident contrains. Onto this, we mounted the grabber system, and assembly done with a combination of normal, distance, and coincident contrains.

As on our robot, this linear slide system is supported by a small TShaped piece with two aluminum bars. This required tangency constrains with the inside of the T piece along with angle offset to the REV rail base.

Finally, we attached the jewel thief mechanism via subassembly, We first attached servos to either side of the custom designed pentagon piece. Then, these servos were constrained to the REV rail base and partly to the phone mount bar extruding out.

All of this went over our amazing chassis design. To see more info on the chassis assembly, refer here

What's next?

We hope this chassis provides an alternate testing mechanism for sizing of our future prototypes. Another version of the chassis is underway based on changes to our robot.

Chassis Model

06 Jan 2018
Chassis Model By Abhi and Janavi

Task: Use Creo Parametric to CAD the chassis

After making significant development on our robot, we decided to model it. So far, we have developed the chassis of the robot seen below

To develop this, many types of contraints were used.

The entire model is dependent on this tetrix bar. The bar was constrainted using the Default feature since it was the base of the model. To this, the lift motor was attached as well as the battery box. These two were constrained by the Distance feature to the end of the bar.

Four REV rails were attached to the TETRIX bar. These supported the wheels and their motors. They were constrianed through the Coincident to the bottom of the tetrix bar and Distance to the side of it.

There are custom designed motor mounts constrained to th side of the REV rails using Coincident and Distance measurements. To this, there are TETRIX wheel mounts attached onto which the mechanum wheels are attached. On the outside, wheel guards were attached. The motors that drive the wheels are attached to REV motor mounts which were constrained to the underside of the REV rails. Attached to the motor is an axel which connects to a sproket to turn the wheel.

The REV hubs were the hardest to constrain in this model because they didn't have typical sides. To mount them, we used a combination of Distance, Coincident, and Angle Offset features. The final part of the model was the phone mount which was simply constrained using coincidents.

The next steps of this robot is to complete the robot model. This chassis was actually reused from last year. Due to licensing issues, we had to redevelop this model. We hope to experiment with this model to make space for the new, larger gripper arms.

Fixing the Robot Chassis

08 Jan 2018
Fixing the Robot Chassis By Austin

Task: Redesign the robot chassis, fix issues

When we designed our new grabber with the octopuckers, one of the variables we neglected was the width of the new grabber once assembled and resting. After the grabber was completed it’s width was actually greater than that of the housing bay we had built into the current drive train, so to get the grabber to fit we actually had to widen the bay. We had know from past experience that the base was never truly square, so we took this necessary widing as a chance to resquare the base and drastically improve the efficiency of our mecanum drive. We added ¾ inch to the inside base and the resquared the frame before finally bolting everything down and attempting to mount the new grabber. Because the closed grabber barely fit within the new widened bay we had to cut away portions of the frame over the front wheels to allow the octopuckers room to actuate.

The other key chassis modification needed to accommodate the new grabber system was a lift bolstering. We decided that to handle the newly doubled weight of the grabber we would share the load across two strings and convert to a double pulley system. The lift was also strengthened with newly squared and adjusted cross beams similar in length and angle to the other iteration. Because of the double pulley, we also centered the drive motor and utilized a second spool. The pulleys rest on either side of the lift system and are both being run by the same motor.

The Grabber V. Kraken

08 Jan 2018
The Grabber V. Kraken By Austin and Evan

Task: Build a new version of the grabber

One of our issues with the previous iteration of the gripper was the fact that the material that coated the actual pincers weren't even and would often lead to blocks slipping from the bottom of the gripper and falling out. Our solution to this was to retest materials and in this process we decided to try our hand at 3D printing a circular and pliable material that could be part of our new rotating pincers. We designed the OCTOPUCKERS and built the rest of the grabber around that. Because the octopuckers were designed to slide onto typical rev-rail extrusions we also had to design a new system of bearings that could house the rails with skewered octopuckers.

We developed a “revolutionary” new 3D printed rev-rail bearing system that was liked with a series of chains and pulleys that could be attached to our current lift system and not severely alter the base and drive train. Previously the grabber was actuated via a system of servos controlled by a rev hub back on the main drive train, however in this newer iteration of the grabber, we decided that all of the necessary wiring would be kept inside the grabber to eliminate tangling by mounting the rev hub on the back of the grabber. While this grabber was a major upgrade that drastically improved our glyph handling capabilities, it did in fact double the weight that our lift had to bear.

Creo Parametric, a Learning Journey

09 Jan 2018
Creo Parametric, a Learning Journey By Abhi

Task: Learn Creo Over Time

Over the course of this past season, I have been learning how to use Creo Parametric to learn 3-D modeling. Since this is Tycho's last year on the team (so far he has been our main modeler), I decided to learn from him so the modeling legacy would continue.

The first project I was tasked to design was the wheel guard on the robot. As a very early learner, I ran into many issues. For example, I used to eyeball all my dimensions. This clearly didn't work out as evidenced by my epic fail of the first form wheel guard. However, after experimenting with the constriants, I jumped all the early hurdles and learned the basics.

My first assembly project was to CAD the conveyor belt we hope to eventually mount the grippers onto. As someone who had never dealt with assemblies before, I felt like someone going through a maze. Even assembling basic parts like an axle hub to the axle, it took me 10 minutes because I struggled changing dimensions and such. This project, though very basic, seemed impossible to me. However, after working through it, I was able to become more familiar with constraints to apply to the next biggest task, the robot model.

So far this is what we have constructed of the robot chassis. After training on the conveyor system, I was able to complete the chassis easier. By doing this, I have dealt with more constraints and have been moving faster.

Next Steps

After learning a lot so far from Tycho, I hope to finish the model soon and continue growth on the model. The only thing remaining on the model is the vertical bars connecting the lift and the lift itself.

Wylie East Qualifier 2018

13 Jan 2018
Wylie East Qualifier 2018 By Ethan, Evan, Charlotte, Janavi, Karina, Tycho, Austin, Abhi, and Kenna

Task: Compete at the Wylie East Qualifier

Introduction

It was a cold and dark morning. The howling winds of a cold front rushed through the grass. Under this cover of darkness, one car after another pulled up to a house, dimly lit. A car door would open for a second, letting a child out into the cold night. Under these auspicous conditions, each child wandered into the house, only for a moment, and left again, and boarded an RV. Thus began the Wylie East Qualifier.

Inspection

We arrived at Wylie about 7:50 AM, and unloaded. Unlike previous tournaments, we had actually prepared our robot the night before. So, we were able to get in and out of inspection pretty fast, which was nice and definently reduced our stress about time management. Our only worry was that our robot was too big for the sizing cube, as we had measured the robot to be 17.96875 inches in length, leaving 1/32 of an inch. And since that is *probably* within the production error of a sizing cube, we were mildly worried. Still though, our robot barely slid in. We passed the rest of inspection with flying colors.

Unloading

We had been preparing to pack Friday, so we had all our tools ready. However, we didn't use the packing list we had previously, and we felt the effects. We forgot encoder cables, and even a flathead screwdriver. While this really didn't hurt *us*, it hurt our sister team, and we weren't as helpful with other teams when they came to us. The one pro of forgetting a lot of our stuff was that the unload was really fast, and we set up our table and got it organized in under 5 minutes.

Judging

Next up was judging. We'd neglected working on our presentation previously, as we had to prioritize even more neglected items such as drive practice. And, it was pretty obvious. We had a few stumbles, a few missed cues, and we even managed to miss a slide. Despite that, we were able to convey our team's progress and history to the judges effectively, and they seemed to be enganged and asked relevant questions. If there was one thing we could change, it would not be the prior errors, but that we took too much time in the presentation, and didn't leave enough time for questions. NOTE: A judge later told us that we should clairify information about our MXP in the presentation

Scouting

Team # Team name Autonomous Glyph Jewel Safe Zone TeleOp Glyphs Columns Rows Pattern Balance Stone Relics
3734 Imperial                      
3899 Terror Bytes YES no yes no yes 6   2 r no yes mo
7172 Technical Difficulties ys 1 with view yes yes yes 24 full full full no no
7904 HSA Dallas Robotigers no       yes 6 0 2 no don’t know no
8418 The League of Legendary yes 1 no viewfoia no yes yes   1-20000   yes yes no
8565 Technicbots yes 1 with view yes yes yes 8 2 3 no yes no
8626 Prototypes yes 1 no viewfoia yes yes yes   3/2 col 0 yes yes no
9386 Elmer & Elsie Robotics yes 1 no viewfoia yes yes yes 24 3 4 no yes no
11097 Cybersurge yes no no yes yes 4-6g yes no no yes 3 and up maybe
11339 Williams Warriors Robotics yes no no ys yes     2-4 r no no no
11341 ViBoTs                      
11366 The Smarty Party yes no yes yes yes 4-5 g wonky 3-Feb no yes not focus butr can
11425 Murphy Maverick Robotics no       yes no test 4   1 no yes no
11563 Hedrick Garage yes no yes yes yes max 6   2 yes yes no
11594 FireCats no       yes 1   1 no yes no
11629 Todoians yes 1 no viewfoia no yes yes   0 2-3 r no0 yes no
11791 Marvin the Martian                      
11793 TRICERABOTS yes no yes no yes     max 2 no yes no
12061 Long Buccaneer Engineers                      
12430 Raider Robotics yes no yes yes maybe yes 5 no 2 no yes no
12810 QuantumX yes yes yes yes yes 8 2 0 yes yes 1-2 zone
12930 ScitoboRRobotics yes no no yes yes 6 1/3/2002 no yes no could try
13376 Cyber Wolves                      
13850 Raider Robotics 2 yes   yes yes yes 8   yes no no no

Robot Game

Game 5
We won this game by a large margin -> 122-40. Our autonomomous definitely pushed us over the top here.
Game 12
We lost this game. Our teleop speed and strtegy didn't work against our team, and our partner had connection issues.
Game 15
This was a surrogate match, but we were still very happy about winning this. We performed pretty well *and* the opponent's bot shut off.
Game 20
We won this game with our largest margin, 106-12. We performed well in all aspects of the game, and we should replicate this success.
Game 26
We lost this game by our largest margin, 236-76. We were outperformed in the autonomous and teleop by large margins, and failed to get on the balance stone.
Game 32
We won this game, again by a decent margen. We did very well in the autonomous, and the other team just couldn't catch up.
Semis Game 1 & 2
We lost both these marches by good margins, we couldn't really compete with Tech. Diff's teleop with our autonomous.

Ceremony

Usually, judges come and talk to your team if you're being considered for an award, so we have at least two people at our table at all times, and we sound an alarm so that the entire team can come and answer questions. And so, we sat, and we sat, and we sat, and no judges came. But then, with just five minutes left, we were blessed with an apparition of judges. We walked into the ceremony more confident than we were, and were reasonable impressed when we won 1st-place Inspire.

Friction Coefficients of Various Materials

24 Jan 2018
Friction Coefficients of Various Materials By Ethan

Task: Test Friction Coefficients of Various Materials

Introduction:

Iron Reign has used many different materials in years past. In those years, we usually preferred materials which were more durable. We started with ABS, but while hard, it was relatively brittle. We attempted to use Filoflex and Ninjaflex, and they were more durable, but too soft. Finally, we had used nylon for the past seasons, as it was extremely durable but also was hard enough to get the job done.

However, our needs have changed. In this challenge, we have to consider not only durability, but also how well the material works with other materials. And, the most important dynamic we must consider is the interaction with the foam blocks and the gripping material, since it is the major point-scorer.

The coefficient of friction determines the power of the force in the opposite direction of motion. While friction is determined by ƒ=µn, we can ignore the normal force when using the same object repeatedly.

Procedures:

In this, we created an inclined plane that rotated around the base so that we could change its angle slowly from 0 à 90. The coefficient of friction is equal to the tan(ɵ), where ɵ is equal to the angle of slippage. We had to overcome some hurdles, most notably the higher center of gravity of a standard foam glyph, so we cut it down to one-inch of height so that it wouldn’t slip. Another way to restate the tan(ɵ) is the opposite/adjacent of the triangle formed by the incline.

We slowly increased the slope’s angle until the block slipped, then recorded the angle of slippage to calculate the coefficient of friction, µ.

Data:

Surface

Opposite Edge

Adjacent Edge

µ

Standard Polycarb

8.925

8.125

1.098

Sandpaper (120 grit)

9.5

8.25

1.152

1-layer Ninjaflex, no ridge

10.925

5.5

1.986

1-layer nylon, no ridge

10.25

6.125

1.673

Nylon ridged

6.75

10.5

0.643

Drip Silicone Sheet

6.25

8.6

0.727

Full-Thickness Ninjaflex

12.2

less than 1

Immeasurably High

Results:

We found, as we expected, that the Ninjaflex sheets have the highest coefficient of friction. The most important thing to do to further increase the coefficient of friction is increase the area of the contact. While we obviously can’t increase the surface area of the block, what we can do is increase the contact points between the sheets and the glyphs. The main way we can do this is decreasing the quality of our prints, counterintuitively. The reason for this is that the decreased quality creates little fibers that stick up from the print which create more contact points.

The meaning of the coefficient of friction is how easy it is to slide an object across a surface, and as it gets higher, it gets harder to push across the surface. When the coefficient becomes greater than 1, it becomes easier to lift the object vertically than slide it horizontally (This can be qualitatively confirmed by touching the test block). And, for the conveyor belt, we need a high coefficient of friction.

In the future, we should test multi-layered prints, as that ought to further increase the number of contact points. We also plan to impregnate the prints with fine garnet dust, which will hopefully make the sheets more abrasive, and therefore have a higher coefficient of friction.

A critique of this experiment could include that the actual type of friction in the robot game is kinetic, or rolling, not static. In this case, the friction would be higher than rolling friction but lower than kinetic. This is due to the grippers pushing the blocks in, increasing the normal force. However, most coefficients of friction are proportional, so we can extrapolate from the static friction we gained to assume that the material with the highest coefficient of static friction will also have the highest coefficient of kinetic/rolling friction. In the future, we will also test kinetic friction with a spring scale.

References:

This source serves to prove the higher coefficient of friction of Ninjaflex – our experiment varies as we leave the 3-D printing artifacts on the sheet. As well, this measures a different type of friction than ours.

https://ac.els-cdn.com/S2212827117300793/1-s2.0-S2212827117300793-main.pdf?_tid=0b998c36-02ac-11e8-bb23-00000aacb361&acdnat=1516980039_4970d0ef82d6f5d0a8bdd886b6005602

Flipper+

31 Jan 2018
Flipper+ By Evan, Abhi, and Janavi

Task: Build a new glyph scoring system

As the season wears on, the robot game looms over Iron Reign since the bot we built scores only a fifth of the world record. To lessen the gap, we continue to invest in the flipper system I contrived earlier on in the season. As of late, we’ve furthered the project by building a chassis for it to rest in. It’s a slightly modified version of the one on the current robot because we want to still keep the lovely mecanum wheel drive for that extra mobility. We’ve had one major hiccup that has slowed progress which is that the spare set of mecanum wheels we have are all too thick. It turns out there’s about a centimeter of extra wheel depthwise, and this has made us have to try and refit the chassis to accommodate the discrepancy. We're going to rearrange the frame to fit the wheels.

The first thing we did when trying to design the new chassis to go around the flipper system was to arrange the different components of the flipper onto the base where they would go in the future. We were able to secure the intake system I designed a while back to the part where it would suck up the blocks. Then we started to rearrange the supports that are used to keep the robot base square to different places around the robot where they wouldn’t interfere with the flipper and instead utilize the space that would be under the flipper board.

To give the required room the flipper needs, we’ll have to rig the motors upward, so they won’t take up space in the center of the robot. Doing this will require gearing it in a one to one ratio, then allowing those to be connected to other gears what are then chained to the larger mecanum wheels. This is a necessary part of the design because there’s not many other places we can put the motors that won’t collide with another function of the robot. Since the last competition, I’ve been assisted by numerous members such as Ahbi and Janavi in the quest for a high performing robot, and it wouldn’t be as far as it is without them. The flipper has potential, and we're going to push it towards its full.

Building a new chassis

03 Feb 2018
Building a new chassis By Karina and Janavi

Task:

Janavi and I have started to build a new chassis for Kraken 2.0., modelled after Kraken’s current chassis.

First, we had to measure the chassis of Kraken, then cut REV rails to these measurements. Lastly, we assembled the pieces to look as it does above.

With this being the first build project Janavi and I have taken the lead on, we had to have some help from the more experienced builders on our team: Evan and Austin. The most difficult task we came across was having to figure out at which angle to cut the REV rails to fit diagonally on the main frame of our new chassis. After we found this measurement, it was easy cutting the pieces using the miter saw and safety equipment and then we assemble all the REV rails with handy-dandy brackets.

Our current plan is to use this chassis as a base for our fifth generation grabber system. Going forward, we have to figure out how we are going to mount our conveyor belt onto our chassis, and then how to mount grabber arms onto the conveyor belt. We also have a new set of mecanum wheels which we are going to attach to the chassis. However, it came to our attention that they are thicker, so we will have to adjust the rails that run parallel to one another so that the wheels can fit in between.

Normally during the season the build team, the programming team and the drive team all need the robot and this can be difficult. Often times this can hinder our performance since the drive team doesn't get the practice it needs. Therefore the team decided to build a new chassis because having a second base will enable us to dedicate more time to drive practice with Kraken while simultaneously testing out new designs on what will be our second robot. Additionally, having two robots will allow to choose which robot we will take to competition based on performance.

Conveyor Belt V2

03 Feb 2018
Conveyor Belt V2 By Abhi

Task: Develop Conveyor System 2

After analyzing the lack of speed from our last competition, we decided to continue the journey of attaching the gripper arms to a conveyor belt as previously designed. To do so, we realized that we needed to utilize the REVolution system to make the grippers work better. Also, we needed two points of attachment for our robot after seeing that one didn't work with the first version of the conveyor. To figure out how to do all this, we went to our best tool: Creo Parametric.

The assembly began with an assembly of two REV rails through distance and coincident constraints. To this, we mounted two bearing holders with bearings inside on either side of the bars. Inside, the plugs holding the REV rails were attached with coincident constraints. This combined assembly was added to the final assembly and was set with a default constraint. To the inside of the plugs, REV rails were attached using coincident constraints. Next, a copy of the bearing assembly was added and attached to the REV rails attached to bearings.

For the next part of the assembly, we had to make a couple of subassemblies. First, we attached a Sprocket hub that we custom designed for the REVolution system and attached it to a 35 Sprocket from Andymark. The other end was plugged into another hub. This sub-assembly was replicated 4 times so that it could fit on all of the conveyor belt pieces. Also, we had to make a similar subassembly for the 25 sprockets since those are what our motors were designed to do.

Finally, we mounted two motors on the insides of the REV rails. The sprocket attached to this motor would connect to the REV rails so that the whole system could actuate. This was constrained using coincidence.

Next steps...

We really liked how this model turned out. By starting to build it based on the model, we realized how useful Creo is to our design process. We hope to use it again soon for determining how to mount the grabber arms to the belt system.

Control Award Updates

06 Feb 2018
Control Award Updates By Janavi

Task:

In the past few months we've made a lot of improvements and updates to our robot and code. For example, we changed our gripper system again; it now includes an internal which makes it easier to despite out collected glyphs into the cryptobox. So we have decided to update our control award submission to reflect these changes.

Autonomous Objective:

  1. Knock off opponent's Jewel, place glyphs in correct location based on image, park in safe zone (85 pts)
  2. Park in Zone, place glyph in cryptobox (25 pts)

Autonomous B has the ability to be delayed for a certain amount of time, allowing for better coordination with alliance mates. If our partner team is more reliable, we can give them freedom to move, but still add points to our team score.

Sensors Used

  1. Phone Camera - Allows robot to determine where to place glyphs using Vuforia, taking advantage of the wide range of data provided from the pattern detection, as well as using Open Computer Vision (OpenCV) to analyze the pattern of the image.
  2. Color Sensor - Robot selects correct jewel using the passive mode of the sensor. Feedback determines whether the robot needs to move forwards or backwards to knock off opposing team's jewel.
  3. Inertial Measurement Unit (IMU) - 3 Gyroscopes and Accelerometers return robot’s heading for station keeping and straight-line driving in autonomous, while orienting ourselves to specific headings for proper navigation, crypt placing, and balancing.
  4. Motor Encoders - Returned motor odometry tracks how many rotations the wheels have made and converts into meters travelled. In combination with feedback from the IMU, can calculate location on the field relative to starting point.

Key Algorithms:

  1. Integrate motor odometry, IMU gyroscope, and accelerometer with trigonometry so robot knows its location at all times.
  2. Uses Proportional/Integral/Derivative (PID) combined with IMU readouts to maintain heading, corrects any differences between actual and desired heading at power level appropriate for difference and amount of error built up. Allows us to navigate the field accurately during autonomous.
  3. Vuforia to tracks and maintains distance from patterns on wall based on robot controller phone's camera, and combines 2 machine vision libraries, trigonometry, and PID motion control.
  4. All code is non-blocking, allowing multiple operations to happen at the same time. Extensively use state machines to prevent conflicts over priorities in low-level behaviors.

Driver Controlled Enhancements:

  1. Internal Lift System is a conveyor-belt-like system that moves blocks from the bottom the grippers to the top and makes it easier for the drivers to deposit the glyphs in the cryptobox.
  2. If the lift has been raised, jewel arm movement is blocked to avoid a collision.
  3. The robot's slow mode allows our drivers to accurately maneuver around the field as well as gather glyphs easily and accurately.
  4. The robot also has a turbo mode. This speed is activated when the bumper is pressed, allowing the driver to quickly navigate the field.
Autonomous Field

Relic Recovery

07 Feb 2018
Relic Recovery By Abhi

Task:Develop a relic arm

Now that we had developed a glyph game and a stable autonomous, it has come time for Iron Reign to conquer the true challenge of the 2017-2018 competition: Relic Recovery.

After seeing that many record setting teams have built "dump truck" robots that can fill both cryptoboxes with incredible speed and accuracy, we realized that if we developed an accurate relic arm, such teams would ally with us and our alliance would be able to maximize the RR score. At the start of the season, we prototyped this project a little but in the intensive time dedicated to the grabber, the prototype was left to rust. When I picked it up again, I realized a drawer slide system would be heavy and not preferable due to its unwieldy mounting. While the discussion continues on what the release mechanism of the arm should be, we developed a CAD model of the relic arm itself, as seen above.

The primary components of the arm are a TETRIX plate and small aluminum bar. The aluminum bar is made of the same material as the Jewel Thief. This bar is attached to a servo sticking at the end of the arm which can move to close in on the relic. The red material is a rubbery material we hope to use for better traction of the relic. We are considering the same silicone material as seen on grabber arms v2

Next steps

We hope to prototype this and place it on the robot as soon as possible (maybe in time for our regional tournaments). This would make us a good alliance partner for other teams so we are working hard to making this model a reality.

Designing Grabber V. 4.5

08 Feb 2018
Designing Grabber V. 4.5 By Ethan, Evan, and Austin

Task: Build an Updated Grabber System

So, we probably won't finish both the Grabber V.5 and the Flipper designs by the North Texas Regional this Saturday, but we really need to improve our grabber system so that we have a chance of doing well in the robot game. From our last post-mortem, we decided that while our grabber performed *well*, it obviously could have been better. So, in comes our new design.

Our main problems with our last grabber were twofold. First, our internal conveyor belt did not work as well as we had hoped. The point was to deliver blocks to the upper areas of the grabber, and it wasn't really doing that. The first cause of this was that it wasn't catching the block in the first place, as we had designed the internal lift too high off the ground to catch. The second issue occured when the block happened to be in the lift system. It was supposed to stay in place due to friction, and to have friction of an effective magnitude, the normal force must be reciprocated. And, ours wasn't, as the only thing that the block was able to push off of was the rubber mesh we designed, which had a high coeffiecient of friction, but not the rigidity needed so that the normal force was reciprocated 100%. So, so solve that, we installed a backer plate behind the mesh that the block can push off of, which has a higher reciproccal force than before. A final, more minor problem was that the block weren't always staying in the lift at the top, so we designed new Octopuckers to both push them in, and damage the glyphs less.

Part 2

Our eventual intention is to do away with this system, and move on to the v5 system which carries the blocks over the robot entirely, but for now, this should do.

Last Minute Robot Fixes

09 Feb 2018
Last Minute Robot Fixes By Ethan and Evan

Task: Add last-minute design changes to the robot

It was a temperate night. The waning moon shone overhead, a blazing reminder of the continuity of time, for as the moon dipped lower in the sky, our precious little time until the tournament dripped away. Under this oppressive, singular symbol, we labored, trying to outpace the continual march of time.

Over the past week, we had worked tirelessly on the robot. In Wylie, we had used the Octopucker Gripper System, but it didn't perform to our expectations, as the internal lift didn't work. However, in this week, we fixed that issue, and designed the Gripper 4.5, which can be found here. Now, all that was left was to actually attach this new gripper.

At 9PM, things were already going downhill. Apparently, "people have to sleep" or "the team should be well rested for the tournament", so we watched our members drip out the door, one by one, until only us two were left. The task still remained - attach the gripper to the robot. From the get-go, we experienced problems, most prominently that since we had extended the height of our grabber, our phone now stuck out of the 18x18x18 sizing box. Now, we as a team already have significant experience just *barely* passing the sizing cube requirements - before this, our robot was 17.5x17.96875x17, in width, length, and height respectively - so we had certain tricks to get our robot just under it. However, this time, our phone stuck a solid inch outside of the cube, so there was no reconfiguration with the parts attached to the grabber at the time that would allow us to fix this.

So, with traditional Iron Reign ingenuity,we had to devise a solution to our problem. In the words of of the legendary Lil Darsh', "First you gotta analyze\see the problem\conceptualize so you can solve 'em". And, we must follow in the words of our elders, as all good robotics members do. So, we devised these ways to fix our phone problem:

  • Position the phone under the grabber system
  • No, vision was hampered too much in this position.
  • Position the phone on another side of the robot
  • No, this autonomous would be too slow, as the robot would have to turn to locate blocks
  • Attach the phone to a servo, which then moves off the grabber after autonomous
  • This may have been the dumbest and the most difficult solution, but it was the best for our robot
So, we set out to create a moveable phone-mounting system. First, we designed the servo.

The next issue was attaching it. We had to find a position that could view the blocks, pattern, and cryptobox from the same angle. We ended up positioning the phone right in the middle of the grabber, about here.

Next Steps:

In our postmortem, we will talk about the issues caused by these last-minute changes.

Intake Stars

18 Feb 2018
Intake Stars By Tycho

Task: Improve the functionality of the gripper

Our grabber is good, but it isn't achieving 100% of the potential it could. One thing we're doing is creating the Grabber V.5 previously blogged about, but we also want to increase the speed of the grabber in other ways, in order to get every single bit of performance out of our robot, since we want to really impress at Supers. So, we designed star-grabbers. The purpose of these are twofold. First, the unique star design we made allows the gripper to fish single blocks out of a pile of blocks so that we no longer have to fully align ourselves with blocks, which reduces the time we spend retrieving blocks. As well, these grab blocks more securely.

Next Steps:

The next step is to mount the modified grabber system with the stars on the newer Kraken chassis.

Grabber V5. Diagrams and Pictures

19 Feb 2018
Grabber V5. Diagrams and Pictures By Austin

Task: Implement the new grabber system and record how it works

So, we've been talking about our new gripper system for a while - we've made prior 3D models and started it, hoping that we'd have it done by the Oklahoma Regional, since that was sort of a low stakes tournament for us. Unfortunately, we didn't get it just in time, so we had to go back to the basic Kraken model of our robot. We really don't want to repeat this mistake again, so we're doing a last-minute drive towards adding V5 to the robot.

First we had to build a new base, in case we had to suddenly revert back to the old bot. We've detailed that in the Building a Chassis post. Next, we had to make the design. We wanted something with more versatility than the static up-down gripper system, and looked at the flipper that our sister team had designed for inspiration. However, we didn't want to give up the whole design process that we'd used for the gripper. We decided on a comprimise, a gripper-flipper system that would intake blocks on either side of the robot, but then had the capability to flip over the entire robot and deposit blocks.

First, we made a model in Creo to see how we would get the gripper to be mobile over the entireity of the robot. This system continued to use the REVolution system that we'd previously designed. Described, the design was a gripepr system hooked to two chains which in turn moved the gripper system from one side to another. The default configuration is to let the gripper rest on top of the rotation system in order to relive stress on the chains.

Next Steps:

Next, we need to hook all of this up onto the robot and test them - we don't have much time, so we've got to act fast.

Designing our Wheel Mounts

20 Feb 2018
Designing our Wheel Mounts By Tycho

Recall the discussion and design strategy regarding our wheel mounts

The side shield design process involved much thought and discussion. We have experienced difficulty with the wheel mounts we have been using, which are the ones from last year. These are made of a composite of nylon and aluminum, but they are too thick and consume a lot of space on our already large robot. Also, the our new Mecanum wheels are thicker than before, so it was about time that we use a thinner material that is just as strong. We decided to use 1/8th inch thick 6061-T6 aluminum plate. We then designed the mounts in such a way that the axles of both of the wheels on a side are joined to increase the stiffness of our robot.

In the beginning of the season, we noticed that the Mecanum wheels would damage glyphs, so we designed shields to protect that from occuring. In this design we also had to protect against glyph damage, so the lower circular areas cover the Mecanums, and there is an indent in the bottom between the two wheels so the mounts don’t get in the way of parking on the balancing stones. Additionally, the middle region is thinner so we can move the mounting regions of the robot inward if need be due to sizing restraints or if we change intake design.

Beyond mounting the wheels, we decided to extend the design into the upper region of our robot as attachment support for the relic arm that we are currently building. In this upper region, we decided to incorporate a unique design based on the name we chose for our robot earlier in the season, “Kraken.” The choice of this name came from the “octopluckers” we designed and use in our intake system. Often, teams will make circular or triangular cutouts to remove weight for the robot, but to remain consistent with a design motif, the cutouts we made show silhouettes of tentacles, like a Kraken.

Making our design a reality

Now that we have a completed design, we intend to schedule a meeting with Advanced Waterjet Cutting to discuss the possibility of them cutting out our design for us. We have incorporated tolerance for a waterjet machine so after sending our design to them they can put it right on one of their machines. Hopefully we can also share our robot and our Mobile Learning Lab with them.

Revolution Flyer

22 Feb 2018
Revolution Flyer By Tycho

Task: Create a flyer for our Revolution system

We've talked to REV before about our unique REVolution system that we've detailed in other posts, but for those who are unaware, its a system that we've personally designed to turn REV extrusions into axles, which enable us to have more flexibility in design. But now, we've designed a flyer to get people on board with the system.







Relic Arm V2

22 Feb 2018
Relic Arm V2 By Abhi and Christian

Task: Revise Relic Arm

As were continuing development of the relic arm, we realized we needed to make several modifications. That resulted in the following design.

This demonstrates the latest version of the relic recovery arm. You may be saying "WOaH that doesn't fit in sizing cube!" Good news: The servo in the middle folds out the second part of the arm to that the entire mechanism fits in the sizing cube but can extend to reach over the field perimeter to zone three.

One modification we made from the previous version is the grabber itself, pictured below

We realized that the long TETRIX plate from before wasn't exactly the most efficient tool as a grabber. Though we will eventually design a claw for the relic, we temporarily decided to use two small aluminum pieces.

One final new addition we made was the servo on which all of this lies on.

We added a servo mounted upwards in the last stage of the arm. This makes the arm swing out from the top of the robot, allowing for a rotating degree of freedom when perfecting the relic placement.

Next Steps:

As stated previously, we will need to design the relic claw. Doing this will allow us to get better grip of the relic.

Relic Arm Design

24 Feb 2018
Relic Arm Design By Ethan, Abhi, and Shaggy

Task: Design and implement a new Relic Arm mechanism

At the North Texas regionals, we realized that if we really want to go further in the robot game, we need to significantly improve. Part of this is designing the new grabber-flipper system detailed in a later post, but another good way to score points is to score the Relic. So, we designed v1 of the Relic Arms, as detailed in this post.

However, designing a model and designing a real-life part are much different. First, we didn't have the Tetrix piece needed for a backing plate, and it is easier to say you can attach unrelated materials than actually doing it. As well, having a single 18-inch deploying arm would test the size limits more than we already do.

In comes Relic Arm V.2. This version is twice as long as the previous version so that we can score in the third zone for 40 points. As well, we have an updated relic-grabber that uses the silicone sheet from our Grabber V.2, so we can grip the relic more securely. Finally, we have a new mounting point on the robot that allows us to extend even farther than before.

Next Steps:

We now need to build and attach this design before Supers, in less than a week.

Polycarb Deformation

27 Feb 2018
Polycarb Deformation By Ethan

Task: Find a constant for polycarb deformation

Recently, we've been having an issue with our gripper in that the shielding for the sides of the intake have been bending torsionally, so that they deform and interfere with our glyph take-up. So, we created a lab to find the torque required to cause this deformation.

We cut a length of polycarb with a similar width but different length to test this (thickness 3/32 of an inch), hooking it into a vertical vice. Then, we attached a vice grip of length 8.75 inches to the side, then attached various weights to the vice until the polycarb deformed.

Under a ten-pound weight, the polycarb finally deformed. Using calculations, we can determine:

d = length of moment arm = 8.75 in = .22225 m
x = 0 degrees
F = 10 lbs = 44.482 N
Torque = Fdsin(x) = 9.886 N*m
Since torque to create deformation is roughly inversely proportional to the length of any object in a single dimension (keeping thickness and width constant): L' = expiremental length = 4.5 in
L = actual length = 14.5 in
T' = T(L'/L) = 3.068 N*m

This amount of torque isn't hard to generate at all, which explains why our gripper shields bend so easy. To prevent this, we must reenforce the shields with something with a higher resistance to deformation, such as thin metal strips.

Next Steps:

We're going back and recording many of our robot's constants so that we can be better able to predict how our robot functions in various situations. This is the first of many posts.

Progress of the Octopuckers Over Time

02 Mar 2018
Progress of the Octopuckers Over Time By Ethan and Tycho

Task: Chart the progress of the octopuckers over time


This design was too rigid, we overlooked the fact that triangles tend to be the strongest shape, and therefore this octopucker wasn't as compliant as we wanted, damaging the blocks.

This design was really good, and we used it for 3-4 tournaments. Our initial design of these wouldn't damage the blocks significantly at the levels we used, but at extraordinary conditions they would gouge the blocks, and under normal conditions they would leave superficial scratches.

This design was really bad. They would catch on each other and get stuck on themselves, and as a result wouldn't pick up blocks. However, they did not damage the blocks in any conditions. We never brought these to tournament.

This was a step in the right direction. They didn't grip the blocks that well, but they worked and didn't get stuck on each other or jam.

This is the design we're currently using. It's impossible to damage the blocks with them, and with the slightly larger cylinders, they grip the block really well. We're going to use these going into the South Super Regionals.

These aren't octopuckers, but they deserve an honorable mention. We're using these intake stars at the bottom of the grabbers to securely grip the glyphs before fully loading them into the grabber system. As well, these have the added bonus of slightly increasing the speed at which we can take in blocks.

The Kraken Awakes

04 Mar 2018
The Kraken Awakes By Abhi

Task: Develop a new robot model

After continual development and adding the fifth grabber, it became time to make a new model.

With some sick upgrades, Kraken has become reborn just in time for Super-Regionals. With some new mechanisms and constraints, we developed a better and more efficient robot.

Gripper v5 was added to the chassis via 4 small REV rails which could keep the grippers attached to the conveyor belt. These were constrained using coincidents.

The relic arm was constrained onto the model using a REV rail on the side of the robot. Though the arm may look longer than in the 18 inches, the current picture demonstrates it at its extended distance.

And last but certainly not least, we added cool new side shields. Cut from AWC, the shields will replace our current wheel mounts and wheel guards to create a protective metal layer and look awesome on the field.

Next Steps:

At this point, we have everything on the robot. However, we need to figure out what to do with the jewel arm before we go to Athens. That will take time to develop and place onto the robot. Upon completion, we can complete the robot model.

South Super Regionals Day One, 2018

08 Mar 2018
South Super Regionals Day One, 2018 By Ethan, Evan, Kenna, Charlotte, Austin, Karina, Janavi, Abhi, Tycho, Justin, and Christian

Task: Set up and present at SSR 2018

A placid stillness hung over the dark, cold room. The early sun flashed through the pale window curtains, ineffective against the onslaught of light. Outside, birds started to chirp and sing, starting off the new day. All over the city, teams were waking up, walking to the Classic Center (the Thunderdome of Robotics), to see their fate, either as champions of the last ever Super Regionals, or to go home defeated and never again see the light of Dean Kamen and his vision. However, through all of this movement and energy, this hotel room stayed quiet. Slowly, a beeping slowly grew more loud, blaring its morning call throughout the room until no one could deny its existence. In spite of the warm and soft Holiday Inn™ beds calling their users back to slumber, the team members had to wake, under the threat of death by coach. Thus started the journey of Iron Reign's 2018 Supers.

The Pits (Setup and presence)

This day marked the first official day of the 2018 South Super Regionals, the last one ever being held. With FIRST moving to the Qualifier-Reigional-Worlds system, we wanted to make a good impression and show off, and thats exactly what we did. First, we overdesigned a robot that impressed judges and looked nice to other teams, as well as making sure we had little goodies to hand out. But, we really worked on our pit presence, to make ourselves really known to other teams. We made posters detailing Iron Reign's season and hung them up; we brought LEDs and lights to give our tent that good old rustic Roman Feeling™; we had business cards to hand out; we went around and talked to other teams and took pictures of their robots. All of this served to make it feel as if Iron Reign was really *there*. While this eventually proved ineffectual to get picked, this still was a good strategy - it got us noticed - and we will feel its effects at Worlds. We still could've done more with the pit setup though, it would've helped to find a place for posters and the like beforehand, and we ran into some placement issues of our robot and award carts that irritated the safety officials. But, overall, 9/10 would do again. (We will)

Judging

Our judging didn't go that well. Our presentation was fine, we still had breaks and pauses like usual, and we got the majority of information across, but we didn't deliver on important information correctly. Our energy was a little low, we had a power outage while going over our outreach which distracted the judges, and on top of that, the judges' paradigms were a little closer to the engineering side of things. Now, this isn't necessarily a bad thing - having a skewed mindset makes a judge more likely to defend for some awards - but for an outreach-heavy team like ours, we were at a disadvantage for the Connect and Motivate awards. In the questioning, we only had one connect-related question, with the rest on Innovate and Design, so we knew we probably wouldn't be up for our usual awards from the get-go, which is a shame as we've gotten the Connect Award at every level of competition this year.

That was the end of the night, so like all Good and Responsible Teams™, we went to bed early and got enough sleep to be rested for the next day /s.

South Super Regionals Day Two, 2018

09 Mar 2018
South Super Regionals Day Two, 2018 By Ethan, Evan, Kenna, Charlotte, Austin, Karina, Janavi, Abhi, Tycho, Justin, and Christian

Task: Complete the first day of competition at SSR

After finishing judging and setup, all we had left to do was the entire robot game. Knowing this, we stayed until 12, tattooing pictures of Minions™ on each other. Thus, we were perfectly prepared for the tournament the next day.

Match 5
We won this match, 207-256. We mainly won due to the autonomous, our partner and ourselves scored 170 points and the other side couldn't catch up.
Match 16
We lost this match, 236-297. We suffered as a result of having a broken relic arm and not focusing on the end game. We really need a relic arm for Worlds.
Match 23
We lost this game, 412-105. We were up against two of the top ten teams in the tournament and we couldn't compete on any level. We didn't even get the balancing stone point because our robot turned off on the field.
Match 29
We won this game, 285-351. While we were outclassed in TeleOp, our combined autonomii were able to overcome that and give us a win.
Match 38
We lost this game, 109-286. We were outclassed on every level, and it didn't help that our robot was unresponsive. This was a wake up call for our team to improve.
Match 49
We lost this match, 572-221. This wasn't even close and was a huge disappointment.
Match 56
We lost this match, 196-374. Again, we underperformed in every aspect of the game and ended our day with a 2-5 record.

Besides our subpar performance in the robot game, we were also interviewed by a team of judges that we guessed were responsible for the Innovate or Design awards. They asked a little more in-depth questions than what we were used to, but we were able to answer them effectively and demonstrate our engineering process. The judges were reasonably impressed by our robot - our design was fairly uncommon - and it made us canidates for the Innovate award by our estimation.

Janavi, Karina, Abhi, and Tycho stayed up to work on driving and autonomous to prepare for the final day while the rest of us slept so that we would be restful and awake for the next day.

South Super Regionals Day Three, 2018

10 Mar 2018
South Super Regionals Day Three, 2018 By Ethan, Evan, Kenna, Charlotte, Austin, Karina, Janavi, Abhi, Tycho, Justin, and Christian

Task: Finish SSR and attend awards ceremony

It was the final day. Tumbleweeds drifted over the land, rolling and turning through the abandoned Athens streets. Over the horizon, a dust cloud rose, brown and shifting and twisting, speckled with the detritus of an abandoned city, flashing and siezing, lighting up the city through its inky blackness, devoid of all light. Under these auspices, with the flashing lights of the looming cloud highlighting every crack, every pore of our grim, stone-cold faces, we trekked through these dark streets, against the cold, whipping winds blowing in, through the debris and detritus of the lost, fallen FTC teams that succumbed to the biting winds and the shooting lightning. Through these harrowing conditions, we perservered and arrived at the fabled Classic Center, the home of all southern FTC teams' dreams, and their doom.

We started out with our 2-5-0 record, so we didn't have a great outlook on alliance selection or for the tournament in general. However, through our discussion the night before, we decided to give our newer team members a shot at driving and working on the robot. So, Justin and Karina became the main drivers for the day, since we didn't have much to lose.

Match 70
We lost this match, 379-267. Even though we lost, we did way better than expected, so this is still a win in our hearts. Had we executed our autonomous correctly, we could've won this match, or at least gotten closer and impressed more people.
Match 78
We won this match, 388-348. It definitely helped that we were partnered with the top team in our division, but it was certainly a morale booster overall. This ended the SSR with a 3-6 record.

With the fresh feeling of defeat in our hearts, as we didn't stand a chance of actually getting picked, we went to a nice italian restruant and talked about potential plans while eating good food. If you ever have the chance, eat at Depalmas Italian Cafe.

We walked back to the tournament, bellies full of prosciutto and cheese, reasonably not confident for our chances to advance to worlds. So, we sat in the stands, waiting, hoping that our names would be called (except for the Promote Award, ours is kind of embarrassing). As we slowly slipped into deep slumber, we heard a but a whisper from the announcer, "And the 2nd place Innovate Award goes to............Team 6832 Iron Reign!". And so, we advanced to Worlds, and rode off into the sunset.

Kraken LED Installation

10 Mar 2018
Kraken LED Installation By Ethan, Austin, Evan, and Abhi

Task: Install LEDs on our robot

This has been a low-priority task for the robot throughout the season. We wanted to be able to a) look cool and b) signal team color and problems with the robot with LEDs. And, at Supers, we just happened to have access to a Fender switch, servo, and a roll of LEDs, so in our downtime we decided to take advantage of it. If we knew we weren't going to win, we could at least make our robot look cool.

The installation was relatively simple. We attached a servo to a Fender switch so that we could automatically toggle between colors, and rewired our servos to accomidate that. We threaded the LEDs above the wheels so that we could have a nice backlit effect on our robot.

Next Steps:

Next, we need to code the appropriate signalling for the colors and the servo to move the switch.

Kraken LED Modes

12 Mar 2018
Kraken LED Modes By Tycho and Janavi

Task: Attach and Code LEDs

We added LED's to Kraken's base. After that, we coded the lights to change color depending on which mode we are in. Though a small addition, it helps take stress off of our drivers. By glancing at the robot, they can immediately tell what mode we're in and can adjust accordingly. It also keeps us from making an crucial mistakes like activating our autonomous for blue alliance when we're on red.

  • Cyan - End-game mode, changes control scheme to support relic arm control. Resets forward direction so drivers can think of relic gripper as forward. Enables automatic balancing mode.
  • Magenta - Glyph-scoring mode for higher rows. Reverses which way motors are and slows down motors.
  • Blue/Red = Blue or red depending on alliance. Regular driver mode, collects glyphs for lower columns.
Here is Kraken in end-game mode:

Which Cipher?

13 Mar 2018
Which Cipher? By Abhi

Task: Find which cipher works best

By this stage of Relic Recovery, we have finally discovered an efficient strategy for the glyph game. At this point, it is important to get consistent driver practice. While doing so, it is important to think of the cipher patterns. Seeing that world records are being set by teams who can double cipher efficiently, it is important that we can complete ciphers at Worlds. But which pattern should we choose? At first glance, all the ciphers seem just as hard (or easy) to do. However, after some analysis, we found some will work better for our team than others.

Based on our current design, the bird cipher is the easiest to complete for drivers. This is because of the pick up pattern of our grippers. For each column, each pair of glyphs can be picked up with the same color order. For example, if we start with a gray glyph during autonomous and put it into the center column, after placing a brown one on top in teleop, we can pick up another gray then brown. Then, when we go to the left column, we pick up brown then gray for first two rows then brown gray again. This makes it easy on our drivers to remember which glyph colors to pick up.

The next easiest cipher is the snake cipher. Though this may conventionally seem hard since mirror snakes are not allowed, it is easy for us because we have the ability to pick up stacks. We would start the same way as the bird in the center column and then pick up pre-stacked same color glyphs.

Finally, we have the frog. The frog is the hardest to do because though the first two rows are the same as the bird, the final two rows have flipped pickup of glyphs. This can cause a high chance of error for our drivers. This is why we will try to stray away from this cipher but can do it if necessary.

General Advice:

Though we focus on specific ciphers, we can setup our cryptobox to allow multiple ciphers. The best thing to do is setting up the center column in a 1221 pattern (each number represents either gray or brown). This sets us up to do either a bird or frog cipher, our two favorite ciphers to do. If this isn't possible or if we are focusing on rows, we have to set them up with an alternating glyph pattern, like the frog and bird bottom two rows. This allows us to set up the cipher for our alliance partner if they choose to complete both cryptoboxes.

Gripper Physics Diagrams

15 Mar 2018
Gripper Physics Diagrams By Ethan

Task: Describe the physics of the gripper

We always struggle a little with describing our robot to the judges. So, this post will be the third in a series of posts describing the physics of our robot (four if you count the coefficients of friction). First, we have the free body diagrams of the gripper.

Next, to further describe this, we created an expiriment in which we determined the maximum force one octopucker can apply. We took a traditional octopucker and rotated it so that the arms of the pucker would barely impact the sides of the scale. From that, we applied force until the octopucker moved to the next arm. We then averaged the forces recorded to determine the maximum force an octopucker arm can apply.

Under these circumstances, we recorded an average maximum of 4.125 oz of force, which translates to 1.147 N. This translates to an increase in the normal force of +6.882 N. This, in turn, increases the frictional force of the internal lift by fk=uN, where u is the coefficient of friction of the internal lift to the glyph. fk=1.96*6.882=13.489N. So, the simple creation of modified intake octopuckers allowed us to increase the frictional force by +13.489N, which allows our internal lift system to operate.

Force exerted by the octopuckers vs time

Next Steps

On Saturday, we will continue this series of posts, finding the series of constants in infopost #2.

Field Oriented Control

16 Mar 2018
Field Oriented Control By Abhi

Task: Implement a drive system depending on field perspective

We are always looking for ways to make it easier to drive. One way to do that is to modify our code such that no matter where the front of the robot is, moving the joystick in a certain direction will move the entire robot in that direction. This allows our drivers to only think about the field and align with the cryptobox easier. I knew that some FRC teams used libraries developed by WPLIB to implement this sort of drive. Reading their code, I figured out how to implement field-oriented drive in our codebase.

The code began by getting the joystick axis readings. This data then needed to be processed to account for the heading of the robot. This needed a special method depicted below.

Some math needed to be done for the angle. This is no easy feat so I will explain it in case if any other teams want to use this code. The first thing we need to do is the find the sine and cosine of the heading. This allows us to find the power to the x-axis and the y-axis respective to the angle.

Now that the trig is done, we needed to apply these values to the joystick axes. In this method, x represented the forward direction and y represented the strafing direction. That is why, when we look at out[0] which would tell the output forward direction, it considers the joystick's y direction and modifies it with the x-direction so that the joysticks get converted to their respective axes. This applies to the strafing direction as well.

Going back to the original method, the directions output from the method are applied to the actual powers of the motors. Before this happens, in case if any dimensions are over 1.0 (the max speed), they need to be scaled down to to 1. This is what the normalize and clampMotors methods do. Therefore, in the end, the code allows drivers to control the bot respective to the field.

Next Steps:

Now the drive team just needs to test the code out and see what happens.

Engineering the Flag Holder

17 Mar 2018
Engineering the Flag Holder By Abhi

Task: Find a place to put the flag

When we went to Super Regionals, we forgot about where to put our flag with the new design. That led us to strapping a zip tie to a side shield, ruining the aluminum aesthetic. We decided we need a specially designed part to put our flag in since duct tape didn't look nice (we're classy like that). I embarked on a mission to create a 3-D printed part for it. That led to the part you see above, which has worked very well. It didn't always look that nice though. The part endured a very special process, one that Iron Reign has used for years and has carried us through the hard times. If you guessed the engineering process, you are correct.

This was the first iteration of the flag holder. The reason it looks so circular was that it was originally going to stick into the Relic arm so that when it extended, the flag would go with it. I built it around those specifications. However, when I went to print it, I realized that there was no good way to print it without supports (nylon doesn't clean very easily for big supports). I also saw that the holder wasn't modular enough to encompass different flags and had to be mounted only one way. I threw this design in the trash and started over.

Inspired by REV's pillow blocks, I decided to make something similar to that. I wanted the part to be able to mount in different ways in case if robot design modifications were required. That led me to the the design above. It worked much better than the previous design. However, the holes for the flag weren't big enough to fit even a pencil. This is a problem because we don't know how flags will be at worlds. I went back into Creo to make a new design.

As many other people have said, third time is the charm. After enlarging the flag circles and making overall dimension modifications to fit this change, the holder ended up accomplishing both tasks I need it to do. It was big enough to fit a pin with some wiggle room and actually held the flag as seen the first picture. We will use this at worlds and possibly hand them out to teams like us at Supers who are using zip-tie holders.

Motor Constants and Future Plans

20 Mar 2018
Motor Constants and Future Plans By Ethan

Task: Find constants for the motors for future calculations

In order to better predict how our robot will work, we first need to find a few constants to do calculations. Luckily, our school has an engineering class, so many of us have the skillset to do these calculations.

The base data we needed was:

NeverRest 40s:
&tab;160 rpm\16.755 rad/sec
&tab;369 oz-in\2.6057 Nm

NeverRest 60s:
&tab;105 rpm\10.996 rad/sec
&tab;593 oz-in\4.188 Nm

REV Servos:
&tab;.14 s/60°\7.143 rpm\.748 rad/sec
&tab;187.8 oz-in\1.326 Nm

Next Steps:

We are going to record these variables using the calculations or by video analysis next:

  • Mass of robot
  • Acceleration curve
  • Max speed
  • Max turning speed
  • Center of gravity
  • Chain speed on gripper-flipper mechanism and drivetrain
  • Gear ratios of gripper and drivetrain
  • Bungee elasticity under various conditions
  • Torque of various motors on the robot

Business Plan Updates

22 Mar 2018
Business Plan Updates By Ethan

Task: Update the Business/Strategic Plan

See the first and second posts here.

Cumulative Updates as of 3/22/2018


MXP

To make Iron Reign’s history entirely clear, we built the RV last year. We do not claim any credit for the actual construction of the RV; however, the goal of this year was to make our Mobile Learning Lab run year round, make it sustainable, and expand the programs to more communities around the nation. We have done all of this.

BigThought, our programmatic sponsor for the Mobile Learning Lab, is helping educators and professionals in five cities across America create their own programs like the ones we run.

Business and Funding

This year, we went further in finding local businesses by looking up relevant companies that can directly benefit Iron Reign as mentors and sponsors. So far, one company has come to our aid: Advanced Waterjet Cutting. We contacted them over phone and asked about an initial meeting to see if they would sponsor us for creating side-shields and other specialty parts. They agreed immediately and we created a mentor partnership that assists us in materials research and design.
Recently, we have designed our own 3D-printed-parts kit, called REVolution. Our intention was to convert a normal REV bar, as seen on our robot, into a usable driveshaft for design flexibility. Upon finishing, we went to the REV headquarters and presented our design to them. We also have shared the basic designs on Thingiverse so that any interested FTC or FRC team can print them out and use it themselves. Note: The main REVolution discussion is in the building section.

Building

Iron Reign’s pinnacle of design and building so far this year is our REVolution system. We were sick of stripping set screws and twisting axles, and wanted something dependable that also was reusable. Thus came the REVolution system, the purpose of which was to turn REV extrusions into driveshafts so that we could have a solid base and more adaptability in our robot. To these ends, we created a library of parts: mounts, bearing holders, and connectors so that we could use extrusions to do almost anything on our robot. Attached in our engineering journal is a complete list of parts with names, descriptions, and pictures.

Design Process

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

You can download the full plan here.

Iron Reign Engineering Journal Summary

22 Mar 2018
Iron Reign Engineering Journal Summary By Ethan

Task: Write a summary page for the engineering journal

The generic engineering journal rubric given to teams by FIRST heavily recomends having a season-summary intro page at the front of the journal. As well, every winning example journal includes the summary. So, we figured out that it might be a good idea to actually make one.

Summary

Iron Reign has been a FIRST team, in one form or another, for eight years. In prior seasons, we have gone to South Super-Regionals and won the North Texas Inspire Award.

We often participate in outreach events. Last year, we fully renovated an old 90’s RV to turn it into a mobile workshop for low income neighborhoods. We now drive the RV all over the Dallas Metroplex in order to reach kids who normally wouldn’t have access to STEM programs, in hopes of inspiring them to go into STEM one day. We have also presented on the national stage in hopes of spreading our RV program to other cities. We recently travelled to the National Science Teachers’ Association Convention in Florida so that we could represent our school as well as inspire educators in other areas to adopt our ideas.

We program our robot in Java, using the Android Studio IDE. We have integrated Vuforia and OpenCV to use our phone’s camera for computer vision to identify the field patterns. OpenCV was an Intel computer vision technology that recently spun off into its own company, and Vuforia is a PTC-owned augmented reality library.

We use a variety of parts in our robot design. For example, in past years we have used a combination of AndyMark and Tetrix parts, using AndyMark materials for our drivetrain, and Tetrix for the rest. However, we are increasingly integrating REV parts into our design, as they let us be more flexible and pull off tougher designs. We also have switched from using the basic power distribution module to using the REV PDM and two expansion hubs.

In our engineering process, we use the Kaizen process, which means that we continually improve each individual part of our robot. We also have design competitions, in which two or more team members each create a part made to solve the same issue. When we were designing our cryptobox grabber, we started with a design competition. Evan built an arm-grab system for the cryptobox grabber, and Austin created a conveyor belt to grab cryptoboxes. Through testing, we determined that the grabbers were more efficient and reliable at picking up blocks than the conveyor belt. As well, the arm-grabber was more compact than the conveyor belt, which was unstable and unwieldy. Then, as we used the arm-grabber, we realized that it still needed work, as the grabber missed some blocks and the driver had to be extremely accurate. So, we designed a new rotating grabber, with soft spikes to hold blocks better, to grab blocks quickly and grab more than one at a time, then one with 3-D printed arms. Afterwards, we decided this wasn’t efficient enough and created a new system with an octopucker design, then mounted the new gripper to a 270° conveyor so that we could move glyphs around the robot with enhanced speed.

We also utilize 3D printed parts throughout our robot. We design parts using PTC Creo, and can print parts in a variety of materials, including nylon, ABS, Filoflex, and Ninjaflex. Usually, we opt to use nylon, as it is flexible enough as not to break under stress, but is strong enough to handle our needs during the game without breaking. Printed parts on our robot enable us to create more flexible designs and circumvent issues that pop up. For example, originally, our robot’s mecanum wheel would damage blocks when hitting them, so we had to design wheel guards to protect both our robot and field elements. We iterated through multiple designs, eventually settling on a u-shape that covered our wheels while not affecting mobility. Then, we changed the height until the part wouldn’t cut into the mats while turning.

More specifically, we have created a personalized library of parts called REVolution for REV extrusions to turn them into driveshafts. We have had great success with these and have shared them with other teams to spread our parts. Refer to our additional handout and presentation for a more in-depth idea of what these do. This is the best part of all of Iron Reign’s designs this season, and we think it is very useful and important.

This year has been an extremely successful year for our team as far a business goes. Normally, we receive FIRST sponsorships, and other minor sponsorships to cover tournament fees. However, this year, we have received sponsorships from a variety of sources. First, in building our RV, we received money from BigThought, a Dallas nonprofit, to run our RV, as well as money from a Dallas initiative called Dallas City of Learning. We also received a grant from Best Buy for 4 onboard 3D printers and 20+ laptops to educate on. Then, we received $3000 of REV parts, two practice fields, and a sponsorship from our school district in exchange for hosting a qualifier and running a DISD scrimmage. We also partnered with AWC to cut our side shields out of aluminum.

Our strategic + business plan is on the next page, and then our Tables of Contents follows, with exceptional posts that we would like you to read highlighted.

Download the pdf here.

Lab Planning

28 Mar 2018
Lab Planning By Ethan

Task: Design labs to find more physical properties of our robot

Lab #1: Batteries

Procedure

  1. Obtain a fully charged REV battery - should say ~13V on our battery charger
  2. Record the voltage upon being plugged in to the robot
  3. Start a timer at the same time as drivers practice starts - this should be intensive practice
  4. When done driving, stop the timer and record the final voltage

Data

Vi Vf Runtime(t) ΔV
Run 1
Run 2
Run 3

After recording the voltages, we will calculate ΔV=(vf-vi)/t for each run, hopefully totalling 10 runs so that we can safely use statistical analysis to calculate standard deviation and outliers for each battery. The purpose of this is to find our best batteries for use in competition as well as set a baseline for future batteries.

Lab #2: Videoanalysis

Procedure

  1. Record videos of the robot accelerating to full speed and rotating at full speed
  2. Put the videos into LoggerPro
  3. Perform videoanalysis, finding the acceleration curve, max linear speed, and max angular speed

Data

Vmax Wmax Amax

Next Steps

We will perform these labs on Saturday; as well, we will find the gear ratio numbers.

Controller Mapping

02 Apr 2018
Controller Mapping By Janavi

Task: Map the controller layout

At this point, we are training the next generation of the drivers on our team, and since we have so many buttons with so many different functions it can often become difficult for the new drivers to determine which button does what, so Karina and I created a map of the controller. By doing this, we not only assist others in determining what button they need to press to do what, but also help the coders in understanding the wants and needs of the drivers. This is because often times when we are coding we will set any function to any available button, just to test if it works. But oftentimes we don't change the button value after that and then there are either far too many buttons for the driver to easily control the robot, or the buttons are too far apart for easy access. Now, after creating this map the drivers were able to sit down together with the coders and map out the most effective controller in their minds together.

Next Steps:

We have planned that now as a part of our post-mortem discussion as well as discussion what could have been done to improve the robots functions as pertaining to code. We will also sit down and take out the controller map and determine if any of the buttons can be switched for easy driver control. This will not only lead to better, more efficient driving but will also lead to better communication between groups.

Elastics Testing

02 Apr 2018
Elastics Testing By Ethan

Task: Test wear and tear on our robot's bungees

This is the fifth or so article in our series on robotics testing. Today's spotlight will be on the constants of our robot's bungees, and how they're affected by various wear and tear. So, we took three bungees from the same set as the ones on our robot, and placed them in various places: stretched outside, stretched inside, and a control sitting in the robot room. The purpose of this is to see whether or not our bungees merit periodic replacements.

Procedure

  1. Cut three identical elastics
  2. Leaving one unstretched inside, place the other two stretched inside and outside
  3. Attach your chosen bungee to a 10 lb weight
  4. Positioning your hand 8 cm from the knot, pull upwards, recording this inital position as xi
  5. When the weight barely moves off of the ground, measure the knot-hand distance and record it as xf
  6. Using these values, calculate the elasticity constant for each bungee

Data

Run x-initial (m) x-final (m) Δx (m)
Normal .08 m .151 m .071 m
Inside .08 m .155 m .075 m
Outside .08 m .162 m .082 m

Calculations

W = 10 lbs = 44.482 N
x1 = .071 m, x2 = .075 m, x3 = .082 m
ΣF = Fsp - W = 0
Fsp = W
kx = W
k = W/x
k = 44.482/x
k1 = 626.51 N/m, k2 = 593.09 N/m, k3 = 542.46 N/m

Calulated Data

Run Elastic Constant (N/m)
Normal 626.51 N/m
Inside 593.09 N/m
Outside 542.46 N/m

Analysis

Assuming a standard deviation of 5%, we can perform a one-sample t-test to see if our results are statistically significant. We will test the inside/outside values against the contol.
Mean = 626.51 N/m
SD = 31.32
N = 3
α = .05
Ho: There is no significant difference between the unstretched band's elasticity and the stretched bands inside or outside Ha: There is a significant difference between either the band left unstretched and the bands left stretched inside or outside

For the elastic left inside, we found a p=.2058. For those not accustomed to statistics, this means that there is a ~20% chance that our results come from chance. This is too high of a probability to say whether or not to say that staying inside affects the elasticity of a band.

For the elastic left outside, we found a probability p=.0433. This means that there is a 4.33% probability that these results come from chance. For most journals, the minimum p-value, or α, is .05 = 5%. Thus, we can safely say that elastics left outside can be damaged and will not work on the same level as the untouched bands.

Conclusion

Given that we only found a statistically significant result for the band left outside, we cannot safely conclude much. That being said, these results suggest that we should replace bands before Worlds, as we leave our robot outside, but covered. As well, even with a 20% probability that there isn't a difference for the inside bands, it is still uncomfortable to say that there is absolutely no correlation. For these reasons, we suggest regular switching of the elastics on the robot.

Importance of Documentation

03 Apr 2018
Importance of Documentation By Abhi and Tycho

Task: Explain commits

As explained in a previous post, we were having many issues with git commits and fixing our errors in it. After a lot of the merging conflicts, we had to fix all the commits without exactly knowing what was being changed in the code. Part of the reason this was so hard was our lack of good naming conventions. Though we always try to make a title and good description for all posts, this doesn't always happen. This is precisely why it is important to check in all changes at every session with good descriptions. Someone had to spend their time mechanically trying to do merge conflicts without understanding the intent behind the code. So it took them longer, they may have made mistakes, an issue fixed by good documentation in the first place.

This post is dedicated to explaining some of the errors and what the commits true intentions were.

Stuff:

That one is mostly about code for the 3rd servo in the gripper open/close methods. It created the servo in pose and added code for it in GlyphSystem2.

4a6b7dbfff573a72bfee2f7e481654cb6c26b6b2:

This was for tuning the field oriented code to work. There were some errors with arrays in the way power was fed to the motors (null pointer exception) so I (Abhi) had to fix that. Also, I made some touch up edits with formatting in the methods. After all this, Tycho made (may have edited existing) a method in Pose for Viewforia demo. Minor changes were made to account for this.

c8ffc8592cd1583e3b71c39ba5106d48da887c66:

First part was all Argos edits at the museum to make it functional and fine tune some measurements. Second part involved the conveyor belt flipper. Tycho made changes to the dpad up and down to return to the home position rather than carry out complete motion (not sure if this carried over in all the commit mess but it was done theoretically). Driver practice will have to confirm changes.

Next Steps

Don't name things badly so this doesn't happen.

Build Kraken 2

07 Apr 2018
Build Kraken 2 By Janavi and Kenna

Task: Build a Pushbot (Kraken 2)

Building. It seems so simple but alas I was wrong, so wrong. During our post mortem, when we discussed our roles on the road to worlds, Kenna and I volunteered for building a pushbot. We both wanted to get more experience in building and thought this would be a perfect way to becoming well-versed in building. Our task was to create a drive base that, when placed on the field, would emulate a real robot on the field allowing our drivers to get more realistic practice. Our design for the pushbot imitates an earlier version of Kraken, just with side shields.

  1. To cut the pieces for the drivetrain, we needed to get trained for using the miter saw. Austin showed us and Abhi how to properly use one.
  2. After cutting the tetrix pieces, we followed an earlier design to create a square upon which we attached the wheels.
  3. We printed 3D custom motor mounts to mount the motor on. Often times the real motor mounts are very expensive, so we decided to used a CAD model. Now unbeknownst to both of us, we attached these lovely lads backwards. We did not realize our mistake until all motors and chains were already on the robot.
  4. The next step was to find the lazer cut side shields, which work as our wheel mounts. On our last robot we created custom 3D mounts for the mecanum wheels but these proved to be large, bulky, and limiting in terms of building space. So this year we designed side-shields that would hold the wheel in place while maximizing the 18 by 18 by 18 space we have. After searching for the shields for about 3 hours, we finally found them and placed them on the robot. Putting the wheels on after that was a breeze.
  5. Kenna and I set out the look for motors, sprockets, and motor collars. Sadly neither of us knew that both axle and motor collars existed and, after searching for so long, we had to go back and begin our search anew for motor collars. Finally, we were able to locate the required supplies and set to attaching the motors to the drive train.
  6. Finally, it was time to put on the chains connecting the wheels and motors. We learned how to find and remove the masterlink, as well as how to put the whole thing back together. For a short period of time, we flew into a panic because we couldn't find the masterlinks we had put aside, but soon we found them and put them onto the robot.

New Skills Learned:
  • Miter Saw
  • Handheld Drills
  • Chain Assembly
  • Trial and error is key

Next Steps: Finish and Code Chassis

Once we put the finishing touches on the chassis physically, we can begin coding it. Expect a new post on how we code it soon! Both of us are relatively new to coding robots so this should be interesting.

Upgrading Kraken

09 Apr 2018
Upgrading Kraken By Abhi

Task: Update CAD model

With FIRST Champs right around the corner, we needed to update our CAD model to match our current Kraken. After all, Kraken can't be lackin' any features. I decided to reopen Creo and make some modifications.

One of the most important things I needed to put on was the Relic arm. After planning on it for the whole season, we finally finished it recently. I made a quick CAD model for it in a separate assembly. The servo horn with a custom made circular disk for holding spool was attached via co-incident constraints. The linear slide system was represented with coinciding a set of REV rails to do this job. The elbow joint with actual grabber was done previously in another assembly. Once I finished the Relic arm assembly, I constrained it to the Robot model using coincident and distance constrains. I also made a small modification to the existing Jewel arm to account for the alignment on our actual robot. I used angle offset for this.

Next Steps:

Present this model to anyone who is interested in the specifics of our robot!

Autonomous Updates, Multi-glyph

10 Apr 2018
Autonomous Updates, Multi-glyph By Abhi

Task: Score extra autonomous glyphs

At super regionals, we saw all the good teams having multi glyph autonomi. In fact, Viperbots Hydra, the winning alliance captain, had a 3 glyph autonomous. I believed Iron Reign could get some of this 100 point autonomous action so I sat down to create a 2 glyph autonomous. We now have 3 autonomi, one of which is multiglyph.

I made a new methods called autonomous3(). For the starting settings (like driving off balancing stone and jewel points), I copied code from our existing autonomous program. After that, I realized that 10 seconds of the autonomous period had already been used by the time the robot had driven off the stone. That led me to think about ways to optimize autonomous after that point. I realized that if the gripper deployed as the robot was aligning itself with the balancing stone, it would save a lot of time. I also sped up the drive train speeds to lead to maximum efficiency. I had many runs of the fix though.

First time through, I ran the code and nothing happened. I realized that I forgot to call the actual state machine in the main loop. Dumb mistake, quick fix.

Second run: The robot drove off the balancing stone properly and was ready to pick up extra glyphs. Unfortunately, I flipped the motor directions to the robot rammed into the cryptobox instead of driving into glyph pit. Another quick fix.

Third run: The robot drove off stone and into glyph pit. However, it went almost into the Blue zone (I was testing from red side). Also, the robot would rotate while in the glyph pit, causing glyphs to get under the wiring and pull stuff out. I had to rewire a couple things then I went back to coding.

Fourth run: The robot drove off stone and into pit and collected one more glyph. The issue was that once the glyph was collected, the bot kept driving forward because I forgot to check the speeds again.

Fifth run: All the initial motions worked. However, I realized that the robot didn't strafe off as far as I needed it to reach the glyph pit. I added about .3 meters to the robot distance and tested again.

Sixth run: I don't know if anyone says 6th time is the charm but it was definitely a successful one for me. The robot did everything correctly and placed the glyph in the cryptobox. The only issue I had was that the robot kept backing away and ramming the cryptobox during end of auto. I fixed this easily by adding another autoState++ to the code.

Before I made the fix after the 6th run, I decided to take a wonderful video of the robot moving. It is linked below.

Next Steps:

Everything is ready to go to do a multiglyph autonomous. However, the robot doesn't score by the codex for the correct column. I need to implement that with IMU angles before Champs.

Robot Video Analysis

10 Apr 2018
Robot Video Analysis By Charlotte

Task: Determine the acceleration and max velocity experimentally

To find the acceleration and maximum velocity of our robot we decided to use a method we have learned in our physics class at school: video analysis with Logger Pro. The procedure is like so: Take a video of the robot head on with a still camera. In the video, in the same frame of movement as the robot, hold a known measuring device (ruler/meter stick). Insert the video into Logger Pro, use the ruler tool to set the distance of the measuring device you used to its length and use the point tool to place a point on the same part of the robot (like the front wheel) for every frame. You can see the collection of points in the image below:

Logger Pro automatically makes a displacement and velocity graph for X and Y. We are interested in the X direction unless your robot is flying. To make an acceleration graph, create a new calculated column that takes the derivative of the X velocity graph. Both graphs are shown below:

Finally it is time to analyze our data. To find max velocity: use the stats tool on the point where the velocity is done increasing and has become constant. To find the acceleration: in this case the acceleration is not constant, so we are looking to find the average acceleration in the beginning when the robot is speeding up from rest by using the stats tool again on the portion of the acceleration graph that occurs at the same time as the velocity initially increases, right before it becomes constant. These were our results:

Max Velocity: 1.67 m/s | Average Acceleration: 2.58 m/s^2

We did this video analysis in order to better understand our robot. We will use this information when we are making code changes to the robot in these last days before Worlds.

Next Steps:

We have made determined many aspects of our robot experientially, the coefficient of friction of our internal lift, etc. In the future we will use these skills to find out more abour our robot.

Relic Arm

12 Apr 2018
Relic Arm By Karina and Evan

Task: To have a working relic arm in time for Worlds

For weeks now, Team 6832 has been working hard to have a functional relic arm designed and mounted on the robot. We feel that it is absolutely necessary to be able to complete relic recovery at Worlds if we do not want to be crushed by the competition. Well, fear not, our relic arm is here!

Now, as you probably already know if you have seen our robot, Kraken is big and heavy. There’s not much space left to fit much of anything before different parts of the robot start interfering with each other. There is very little clearance left vertically and from the front to the back of the robot before we exceeded the 18 by 18 inch size limit.

Due to this, there was a bit of hesitance when it came to mounting the darn thing because it had seemed at first as if we would have to cut our beautiful side shields to be able to fit the relic arm onto the robot. However, we found a way around this.

First, I will briefly explain the design. There are two major components to the relic arm: the linear slide system and then the final metal bar that the “hand” of the relic arm is mounted on. The linear slide of the relic arm provides most of the extension length to the robot, and is what gets the “hand” across the walls of the field. A servo on the end of the linear slide system extends the final length of the arm, the part which grasps the relic. We felt that having this part at the end of the arm would give us more control when grabbing the relic, and help make it easier to balance the relic in endgame.

Anyway, because the final extension of the robot attached via a servo, this creates a distance between the two major components of the arm, which allowed us to fit the side shield in between the two. We still had to drill holes in the side shield, sadly, but this was much better than the alternative. We did not mount the arm directly by the slide system, of course. Instead, we attached another REV rail to the bottom of the slide system using double brackets, which created extra space for the side shield to fit in between the two components of the arm. Also, surprisingly enough, when we tested the grabber system, we found that despite the tight fit, the relic arm did not get in its way of the octopuckers when flipping upward or downward.

Where will we go from here?

Just because we finally have a relic arm does not mean we are done working on it. From now until Worlds, we will continue improving our relic recovery and tweaking the design of the arm along the way. We will have to fit time in for completing the challenge, but we have faith in our drive team!

REVolution on Thingiverse

13 Apr 2018
REVolution on Thingiverse By Abhi

Task: Publish REVolution Parts

Tired of slipping set screws? Want a rigid drive shaft as long or tall as your robot? Have a bunch of REV Rail lying around? Have we got a solution for you...

Turn your REV Rail into a beater-bar, a drive shaft or a heavy duty hinge with our Spintastic Axializer System … The REVolution System

Iron reign has developed these parts over the course of this season and they have served as essential pieces of our robot. Now you don't have to worry about snapping axles and those darn set screws. Choose your attachment plate, your internal pieces, and assemble them together! With this system, you robot can be efficient and flashy.

The parts are avaliable at

https://www.thingiverse.com/thing:2859442

If you need help with part assembly or printing, please contact us and we will be glad to help. Tutorial videos are in the process of being made. Details about the parts are listed below

Autonomous Updates, Multiglyph Part 2

15 Apr 2018
Autonomous Updates, Multiglyph Part 2 By Abhi, Karina, and Tycho

Task: Develop multiglyph for far Stone

We had a functional autonomous for the balacing stone close to the audience. However, chances are that our alliance partner would want that same stone since they could get more glyphs during autonomous. This meant that we needed a multiglyph autonomous for the far balancing stone. We went on an adventure to make this happen.

We programmed the robot to drive off the balancing stone and deploy the grippers as this occurred. To ensure the robot was off the stone before deploy, we utilized the roll sensor in the REV hub to determine whether the angle the robot was at was flat on the ground. This made our autonomous account for the error we could have on the balancing stone in terms of placement in the forward backward direction respective to the field. Next, we used an IMU turn into the glyph pit to increase our chances of picking up a second glyph. Then, we backed away and turned parallel to the cryptobox. The following motion was to travel to the field perimeter for a long period of time so that the robot will be pushing the field perimeter. This was done to correct any wrong angles and make grippers perpendicular to field wall. Then the robot backs up and scores the glyphs. Here is a video of it working:

Next Steps

Now we are speeding auto up and correcting IMU angles.

REV Rail Deformation and Faults of Design

15 Apr 2018
REV Rail Deformation and Faults of Design By Karina, Austin, and Abhi

Task: Analyze Source of Gripper break

As you can see from the video above, the REV rail twisted when the gripper rotated. Due to the high torque caused by intaking glyphs (4.02 Nm), the rails were required to turn very quickly. When we were designing the gripper, we didn't consider the friction among the nylon parts. Before we noticed the rails twisting, we heard squeaking noises (now we know its because of the high friction). The twisting led to the much slower grippers and a twisted frame.

To fix the issue, we needed to create less friction in the REVolution parts. We don't have enough time to remove the grippers and switch out the parts so we just used Teflon powder to lube the REVolution parts. It wasn't necessary to switch out the REV rail because since the twisting occurred uniformly. After testing the grippers again, the grabber moved properly.

Next Steps:

In order to not replicate the same issue, we must switch out the REVolution parts frequently. Even after Championships, we have Texas UIL so we can fix the gripper by then. Next year, we hope to use REVolution for our drive train, so we must be extremely careful with the parts.

Finishing the Chassis

29 Apr 2018
Finishing the Chassis By Kenna and Janavi

Task: Build a Chassis

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

Next Steps

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

Swerve Drive Experiment

02 Jun 2018
Swerve Drive Experiment By Abhi

Task: Consider a Swerve Drive base

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

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

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

Next Steps

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

Swerve Drive Prototype

09 Jun 2018
Swerve Drive Prototype By Abhi and Christian

Task: Build a Swerve Drive base

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

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

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

Next Steps

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

Position Tracking

18 Jul 2018
Position Tracking By Abhi

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

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

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

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

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

Next Steps

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

Technicbots Chassis Project - July Meeting

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

Task: Compare & Collaborate on Chassis

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

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

Austin Lui of Technicbots gets their chassis ready for testing.

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

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

Connor Mihelic of EFFoRT adds some finishing touches.

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


Terri and Grant Richards of Schim Robotics.

Next Steps

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

Replay Autonomous

28 Jul 2018
Replay Autonomous By Arjun

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

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

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

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

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

Next Steps

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

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

C.A.R.T. Bot Summer Project

12 Aug 2018
C.A.R.T. Bot Summer Project By Evan, Aaron, Abhi, and Janavi

Task: Enhance our robot-building skills

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

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

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

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

Next Steps

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

Garchomp Part 2

18 Aug 2018
Garchomp Part 2 By Janavi and Kenna

Task: Build the Chassis

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

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

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

Next Steps

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

Relic Recovery Brainstorming & Initial Thoughts

08 Sep 2018
Relic Recovery Brainstorming & Initial Thoughts By Ethan, Charlotte, Kenna, Evan, Abhi, Arjun, Karina, and Justin

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

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

Building

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

Journal

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

Programming

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

Next Steps

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

Testing Intakes

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

Task: Design a prototype intake system

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

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

Next Steps

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

Rover Ruckus Strategy

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

Task: Determine the best Rover Ruckus strategies

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

Brainstorming Two - Enter the Void

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

Task: Have a 2nd brainstorming session

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

Intake System 3 - TSA Bag Scanner

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

Intake System 4 - Big Clamp

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

Lift 2 - Thruster

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

Next Steps

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

Chassis Brainstorming

22 Sep 2018
Chassis Brainstorming By Ethan and Evan

Task: Brainstorm chassis designs

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

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

Proposed Additions

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

Next Steps

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

Contact Us

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