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.

Task: To talk to prospective SEM students about robotics

Every year W.B. Travis, a 4-8 has an open house for magnet schools to attend and convince students that $school1 is better than $school2. And, since it is Iron Reign's former school, we attend and try to pull students SEM. We present to about 5 groups and field questions from parents.

Unsurprisingly, we ran into issues, just like we always do. First, our chain kept on falling off of our new robot as we had forgotten to re-enforce the motor and wheel mounts. So, while our robot was still impressive, it was a bit disappointing. Second, we had our color-following robot, but we had forgotten the controller phone. Despite all this, Jayesh gave a great presentation to the prospective freshmen.

Reflections

Task: Reduce clutter from summer

We made real progress in sorting the good and dead batteries after UIL, and we've streamlined the charging process. The phones are harder to charge because their cords can disconnect without warning, and they slide around more. If we don't want to waste time in competition, it's important we make the system easy to use and reliable. Janavi and I worked on Powerpole-ing the last few batteries so we could test and charge them, and I made something like a file cabinet for the phones to rest in.

Reflections

The battery box already has some internal organization, charged batteries in a separate box, to-be-charged in the main section. The phones seem like they'd be easy to keep at maximum, but we've noticed that their cords aren't as reliable, even if we have multiple. Stacking the phones works to keep them charging in a smaller space, but if one in the middle disconnects we can't tell which. Then we have to reconnect each one while listening for a disconnect tone to sound. I used some extra prototyping cardboard to make a row of slots for the phones so we could charge them without them affecting each other. Hopefully this will survive the travel stress and

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.

Task: Applying for Grants

As the season begins, we have started to apply for grants. Grants are important to us because 68% of students in our home school receive free-or-reduced lunch, and we are underfunded by the district. It is our responsibility to seek the money required for our team to thrive.
Here is an excerpt from a letter we sent to a local business:

"Unfortunately time is money and the time it takes us to contribute to each of these events costs us dollars we don’t have. We all love teaching young children who are interested in robotics and technology and we hope what they receive is beyond value. But we also need to raise our competitive game and new parts cost money. When jerry rigging and reusing parts unsuited for the job, we waste time that could be used to make more progress and continue the advancement of our robot. As we continuously refine our design, new parts are needed and some need to be replaced as we strive for an efficient and reliable entry. The other piece of the financial puzzle is transportation costs. This year we plan to take part in multiple competitions including out-of-state competitions in order to deepen our competitive potential and improve our chances of advancing to the next level. Competition expenses beyond the standard local track are some of the hardest expenses to fund."

Reflections

In the future, we wish to reach out to more businesses for grant opportunities. We have already applied to the FTC grant and others, and we have set up a Paypal page where anyone can donate any amount of money. For example, you can donate

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

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.

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.

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.

Task: Stablize Meccanum wheel base so the driving is more stable and consistent

Our Meccanum wheel base idea started off on a shaky note. While we had a good amount of success in the tass we wanted to complete, like driving right or let without turning the entire robot, including the basic driving functions. However, as we went on with testing, we found that over time, the force the meccanum wheels were exerting on the chain was actually causing the motors driving the chains to come inwards. This was thereby loosening the chain and weakening their effect on the driving chassis. To fix this, we decided to mount angled beams between the motor and Meccanum wheels to stabilize and prevent the motion. We then further strengthened the system by 3D printing trapezoid-shaped mounts that have more surface area and strength to stabilize the system.

Reflections

As we go on improving the robot, we keep finding that our new designs have an incredible amount of errors and small bugs that need to be looked at before moving on to the next big design. Now that we have a stable and relatively reliable driving base, we can now focus our attentions to the scoring mechanism. Through our redesigns of the motor stabalizers we have found the use of testing on both the ground and in stationary conditions. We need to design a new mount to make stationary testing more efficient. This will especially be important for the testing we'll have to commit to for our scoring mechanism. (which will be discussed in a future post)

Task: To improve upon launching mechanism designs

Catapult

Flywheel

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.

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.

Task: Obtain knowledge and share work done on Moon base project

A contigent from Iron Reign participated in a space competition at the NewWorlds Conference. The idea was to form a interstellar base to self-maintain and extend humankind's reach into the universe. After winning the previous year's competition with a Mars base, the team did a sort of prequel, committing to a Moon base. Involving writing a 21 page research paper, developing a minecraft-modded map, and work in Google Sketchup, the team presented to a group of Space researchers, genetic scientists, and privately-funded space companies over our work. We recieved 1st place for our work and garnered a lot of interest in STEM and space.

Reflections

The convention allowed us to present both to the aforementioned specialists and children who took a field trip to come to the convention. These children were especially attracted by the minecraft design. We led them through walking in the base and testing out our designs. We were able to garner a lot of interest of their concept of space and STEM was. When the judges came to our area, we mentioned how the topics we learned in SEM and in robotics helped us to finish a lot of the fact-checking for the base. In the end there was a lot of interest and praise for our work, even going as far as to convince a researcher to ask in running a molecular biology summer camp at our school. We're excited to build off our success at the competition and use it to help us in FTC as well.

Meeting Log November 06, 2016

We've been blogging/journalling at the sub-team level, which allows us to share our work at a deeper level on specific subjects. This ends up creating a need to have many posts in a single practice. That's great for our journal, but we also end up failing to document some of our sub-team work because we can't find enough time to write up every break-out project. We are also regularly missing out on documenting a lot of our organizational work, like the planning session at the beginning of practice and the list of tasks we assign ourselves. So from now on we will be adding a practice log for each meeting - starting it as an open template on our main shared computer and just asking team members to log their start-stop times there. Publish right at the end of practice. This is meant to be a light-weight log - it doesn't need great writing. Members, add your time to person-hours in this post only for planning time plus any time you worked that will not be captured in a detail post. This will be the first such post.

Today's Meet Objectives

Organization / Documentation / Competition Prep

• Review Journal - not started
• Review Robot Status - completed

Software

• Fix pose class - import from last year is incomplete and broke code - completed
• Calibrate forward and crabbing motions of the robot - not started
• Turn current teleop mecanum mixing into a method that can be used across teleop and autonomous - completed
• Begin Autonomous motion sequences - not started

Build / Modelling

• Add outside collectors to collector system - minor progress
• Begin modelling the full robot assembly - not started

Service / Outreach

• Blog about SEM open house - TBD, delegated for homework

Today's Work Log

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.

Task: To create a thank-you video to Pitsco

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

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

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.

Task: To test our robot and gauge other team's progress

First, the team arrived at the Virani's house and boarded the MXP for a Arkansas dry run. We learned that it's pretty bumpy for passengers when you're driving on the highway, making the experience a bit uncomfortable. We'll need to fix that for the 8-hour drive to Arkansas.

When we arrived at the scrimmage, it was laid out like a normal tournament, though there were only nine teams to compete against. The matches were laid out so that each team competed five times, but only four of those five matches counted towards your actual score. During the first match, things were looking up. Our catapult and intake system were looking great, we had scored two or three balls, and our driving was pretty nice. We ended up winning that match. Then, everything went downhill. First, we had a issue with a loose chain, which we were able to fix. After that, however, our robot's catapult jammed so we had no useful way to score. This led to us losing our other three matches.

Despite all this, we ended up 6th place out of nine teams, which isn't *horrible*. We were also picked for an alliance.

Reflections

There are teams very ahead of us, so we need to step our game up for Arkansas. Our next goals, in order, should be to fix the chain system permanently, stop the catapult from jamming, add the beacon presser, and add the yoga-ball lifter. However, our collection system was really nice and worked >95% of the time. The only problem with it was that balls occasionally got stuck on top of the robot delivering to the catapult.

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.

Meeting Log November 22, 2016

Main focus for the day is fixing the problems encountered at the scrimmage and making autonomous progress.

Today's Meet Objectives

Organization / Documentation / Competition Prep

• Review Journal
• Pre-Match checklist
• Continue Presentation

Software

• Autonomously score
• Put collection system in same class as flinger

Build / Modelling

• Mount new particle bowl
• Build button pusher

Service / Outreach

• Update connection totals

Today's Work Log

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.

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.

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.

Meeting Log November 26, 2016

Today marks one week until our Arkansas Tournament. God help us all.

Today's Meet Objectives

Organization / Documentation / Competition Prep

• Review Journal
• Work on Presentation
• Do Blog Posts

Software

• Autonomous
• Testing Code

Build / Modelling

• Finish 2nd Level
• Improve Catapult

Service / Outreach

• Blog

Today's Work Log

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.

Task: Build a frame to increase available surface area on robot to rewire current configuration

The wiring, which had been on the robot, had been a constant issue. The wiring tangled, interfered with the scoring mechanism, and led to some inefficiencies in electrical output. In order to increase the available space to reconfigure the inner workings of the robot, we built a second testrix layer, which also conveniently serves as a handle.

Reflections

The new level on the robot has given us a lot of much-needed flexibility for arranging the different parts. Now the core of our robot isn't a jungle of tangled cords. As we continued building the layer, we found it could be used for various other purposes besides simply space control. The back layer simultaneously stabilizes our scoring mechanism, allowing us to control our shot more. Besides the modules, the phone and power switch are also attached to the upper layer for ease-of-access. As we only made layers for the front and back, the sides of the robot are left open, nonetheless more free without the wires, for our cap ball lift (which is currently in progress, more on it in future posts).

Task: Design potential beacon scoring mechanism

Up to this point, we hadn't given much attention to a beacon scoring mechanism that we could use in both autonomous and tele-op. At the scrimmage we learned that scoring the beacons was almost vital to winning the match, and we couldn't do that. We rigged up a short u-channel on a plate and attached it to our robot, hoping we could just ram into the wall and it would work. It didn't. We started designing potential button pushers. We figured a servo would have enough power and saw a few robots using either a large flat plate or some type of wheel to score the beacons. We thought that a hard-foam wheel would work best, but aren't entirely sure how we would mount it with our limited space, so we'll have to see what best fits our needs and capabilities.

Reflections

Whatever our solution is for this problem, with our first qualifier really soon, we have to come up with it quickly. We realize that if we plan to be a contender for the top seed, we need to be a consistent beacon scorer.

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.

Task: Compete in the 2016 Arkansas State Competition

This year, to give our team a better chance of going to super-regionals for the first time, we decided to enter the Arkansas regional. We were actually pretty far ahead compared to our last seasons. We had a finished robot, a working autonomous, and good drivers.

To Arkansas pic.twitter.com/spvHb17vyo

— Iron Reign Robotics (@team6832) December 2, 2016

Upon arrival, we had to make some last minute changes to our robot in order to pass inspection, as it was too bumpy in the RV. So , we huddled in the school's band room and attached our side shields and team number, making it just in time for inspection. We set up our table for the competition as well.

Upon arriving to the hotel, we realized that we hadn't really practiced our presentation at all, so we had to hold a last minute session until 12. After that, a few team members fell asleep for the next day, but most boarded the RV and worked on the robot and autonomous until ~2 in the morning.

We woke up refreshed (totally), and went to the tournament. In order, we had: opening ceremony, the presentation, and then the four games. First, right before the presentation, we found that our robot, despite working the night before, now refused to accept any motor commands. This was due to the way our code handled controller events, so we had to change that last minute. Also, due to just having last minute practice in the presentation (and being tired), we didn't preform as well as we would have liked.

The Game

In the first match, we performed way better than we expected, and actually won the game. However, we discovered that our robot has a static issue due to the way the wheels slide, so we had to reboot it during the match.
In the second match, we lost. This was partially due to the static issue and partially due to the fact that we were paired with an inexperienced team. We helped show them the ropes, however, and saw a lot of the origins of our team in them. We wish them the best and hope they can progress.
In the third, fourth, and fifth match, we won all our matches, even though our static issue got worse. Our relatively consistent autonomous, paired with the beacon and ball scoring fared us well against our opponents. We need to build on these strengths, while also introducing end game flexibility with cap ball scoring.

We did not get picked for alliances, even though we were in 8th place with a 4-1 record. this was probably a knock on our scouting and relation building with the other teams. We'll make sure to build on that for future competitions.

Reflections

We had issues at the tournament due to static and scouting issues. The scouting issue was particularly bad due to these reasons:

• Staying on the RV and not interacting with other teams
• Alliance negotiations were started too late
• Misjudging other teams

This tournament gave us valuable experience for the qualifiers we have coming up. We have now fixed the static and controller issues. We were also able to judge the progress of other teams and compare it to ours. By the time of the qualifier, we should have some advantages over the other teams.

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.

Task: Analyze what went wrong and right at Arkansas

We spent a good hour and a half analyzing what we needed to do differently at upcoming competitions, and how to better prepare in the upcoming school break.

Notes

Mechanical:

• Anti static spray
• Shorten wires and close wire ends
• Stabilize USB connections to controllers
• Cap Ball lift

Competition:

• Driver Practice!!
• Organize sub teams during competition
• Scouting more and building connections
• Stay aware and alert, no zoning out while in the pits especially
• Line up robot based on tile mat seams
• Control Award checklist done beforehand
• RV shifts, no more than 1 onboard at a time

Presentation and Presence:

• Mechanical demos
• Videos of demos easily available if robot stops cooperating
• Team costume and cart chariot
• RV video PSA - Pay it Forward
• Be more active on Twitter and link videos to judges
• Have a fundraiser in the neighborhood

Reflections

The Arkansas competition taught us a lot about the system of success for this years competition. We are ahead in terms of progress relative to other years, now we can focus on scoring elements like the cap ball, along with the presentation.

Task: To test our robot in a tournament setting

On Dec. 18, we came to QD Academy to test our robot under tournament conditions. At Arkansas, we had frequent static issues on the mats provided, and we had trouble recreating the static in practice to prevent it, so we wanted to try to find a cure for it. As well, we've been improving our autonomous code, so we were excited to try that.

We did well at the scrimmage, compared to the teams that we went against (4-1). We were lucky to already have been to a tournament - and a regional at that, so we ended up placing 3rd, and our sister team placed 5th. However, we still ran into new, and worse, issues. First, the static issue reemerged, and became worse than when we were at the Arkansas tournament. As well, when we bumped into the beacons with enough speed, our robot would turn off, and we would have to completely reboot the robot at the end of the match.

To solve the static issue we had bought Staticide(TM), but we forgot to bring it, so we have no idea if it works for our robot or not. We tried rubbing down our robot with dryer sheets, but it just exacerbated the issue if it did anything at all. The beacon issue seemed also to be caused by the static discharge, but we haven't determined it conclusively yet.

Reflections

We scored a lot of points, but we need to optimize our autonomous for both sides to score even more. As well, we still need to solve the persistent static problem, as it will really harm us in January if it continues.

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.

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:

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.

Meeting Log December 31, 2016

Today's Meet Objectives

Organization / Documentation / Competition Prep

• Blog Fixes

Software

• Test autonomous changes

Build / Modelling

• Add swinging arms to the robot

Today's Work Log

Task: Disassemble the tent covering our field

Dallas has been experiencing some bad weather for the past couple of weeks. Unfortunately, our field was outside, with a tent that was supposed to have "protected" it from the elements. That did not happen. When a particularly bad windstorm came, it tore down our tent and ripped holes in the top, so our field tiles were damaged. As well, it snowed/rained later that week, intensifying the damage, and bending the metal posts.

So, today we had to break it down in ~30°F weather. The metal was so bent that we had to cut the tent into pieces to remove it, and ice had frozen over the plastic siding in multiple areas, making it hard to move. There was also snow still on the roof of the tent, so we inadvertently dumped snow onto our field, probably further hurting our tiles.

Reflections

We need to find a secure way of keeping our field safe. As of now, we are just replacing the tent with another tent, which will most likely just be destroyed in the next windstorm.

Task: Make some Roman helmets for the team

A post shared by Iron Reign Robotics FTC (@team6832) on Jan 12, 2017 at 6:20pm PST

We’re following a Roman theme this year, but nobody’s gonna know it if we don’t look the part. So, we decided it was time to make some Roman soldier style helmets. The most Roman helmets cover the top of the head with the body of the helm, with two additional plates on hinges that cover the cheeks, a protrusion at the back similar to the bill of a ball cap to protect the back of the neck, and of course the iconic curved crest, which would point forwards on the common soldier’s helmet (if the soldier could afford it) or from side to side on the helmet of a centurion (the best soldier of in a group of 100). While it would be nice to mimic the helmet entirely, we don’t have the time or the funds to do that ourselves, and instead opted for a more homespun version.

Our helmets each consist of a construction helmet, the sawn-off head of a broom, and a single screw holding the two together. It’s simple, but it’s cheap, easy, and definitely gets the job done.

Reflections

The helmet has most of the features of a Roman helmet already, but it is still missing the hinged cheek guards. We likely won’t add hinged ones because they could be distracting to drivers wearing them and they would take too long to build, but I have a plan to cut stationary ones out of foam board and socket them into a pair of empty slots I noticed on the sides of the helmets. Also, Tycho suggested that, at least for the drive team, we could fit a few helmets with safety glasses mounted on hinges to reduce the chance that the drivers accidentally go to the playing field without their protective wear.

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.

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.

Task: Plan Bake Sale

During our winter break, we worked on our robot, but we also planned to gain funding for our continued progression. We had applied for multiple grants but we thought crowd souring would be also be beneficial. One way we thought we could accomplish this was through a bake sale at our school. We found out that we are not recognized as a nonprofit by the IRS which means we can't do fundraising through companies like Chipotle. We also have a PayPal, but online funding can also be very tricky. At this point we've planned out who's bringing what to sell. Although our date hasn't been confirmed, we have planned for the 19th or 20th of January.

Reflections

We realize that funding is obviously a major part of running our robotics team. Doing things such as this bake sale throughout the season could help put a dent in our tab.

Task: To go to the Wylie East robotics tournament

On Jan. 14, we headed out to Wylie East HS for a North Texas qualifier. Our main goal was to test our new code and additions to the robot - we've added static shields and staticide to protect ourselves from the issues that we suffered from last tournament. We had high prospects this tournament, with a robot further ahead than we've ever been before and a "fun" presentation.

We ended up 3-2 in the main rounds, and at 4th place. The first round we lost was a magestic, catastrophic failure. Our robot ran into the metal sides and short circuited. Then, within ten seconds, every other robot had shut off. We were gettting destroyed at that point, but the powers-that-be decided to call a redo. So, we restarted, and insted of getting destroyed, we got massively, absolutely destroyed by a huge margin. The second time we lost, our robot tipped over, and we couldn't get it back up.

We advanced to finals, and we won the semi-finals round easily. Then, in finals, we faced a combo-team of Technical Difficulties and Technibots, which proceeded to stomp the floor with us and set a new world record in the process.

Reflections

Our main failures through the tournament were that we just can't currently score enough points as higher ranking teams. However, we have a cap ball lift in progress, so well be able to score way more soon. And, we did advance to Regionals, so we've got that going for us.

Task: Analyze what we did wrong and right at Wylie

At Wylie, we did decently. We were mildly surprised that we actually qualified for regionals, but we did, so that's pretty nice.

Mechanical Problems

• Static shocks
• Catapult reliability
• Program unpredictability
• Autonomous issues

Others

• We need to be more motivated
• We need to practice driving

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.

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.

• How to integrate OpenCV into an Android Studio Project
• How to get access to camera data from Vuforia
• Forum post on grabbing frames from Vuforia. This shows a concrete example by Corban987 on how to use the preferred vuforia.getFrameQueue method in the current api.
• Complete Video Series on Vuforia Somehow we missed this until later in our research, but Team 3491 FIXIT are clearly the authorities on the subject of vufuria integration in FTC. Check out their videos 4 thru 7.

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.

Task: Help Imperial Robotics before their qualifier

As said in previous posts, we have a sister team, Imperial Robotics, and it would be really nice to see them advance to regionals alongside us. In their previous qualifier, they got really close. So, with help, we should be able to push them over the qualifying line.

Tycho, our lead programmer, helped Rohit and Abhi with their code. Imperial was having servo control issues in which they couldn't continuously rotate their ball-intake servo when pressing a button, and Tycho fixed that, along with other control issues. Tycho also worked on their bass launcher, making it more reliable.

A post shared by ImperialRobotics (@imperialrob3734) on Feb 2, 2017 at 5:27pm PST

Evan and I helped Imperial with building and driving. We fixed their wheel and turning issues as referenced in this post. Their problem was that a motor wasn't working at 100%, and it interfered in driving. As well, Evan gave Imperial advice on driving, and demonstrated driving techniques. As well, we helped with general fixes of their robot, as most of their team members were focussing on the presentation.

Reflections

Imperial ended up not advancing to regionals, unfortunately. :(

Task: Build a solid drive team.

One of the leading problems Iron Reign faces is our ability to allot time to effective driving practice. Driving practice is essential for our success in the robot game, but it is sometimes difficult to find time to practice due to other team members working on various robot improvements. We have created two different drive teams, a main team and a backup team, so that despite who is available at meeting we can always have some kind of drive practice going on. The bulk of the time spent in driving practice is spent practicing putting glyphs in the cryptobox, trying to better our previous time and complete as many columns as we can. We focus on performing and scoring timed runs, and sometimes when our sister team 3734 is available, we scrimmage our robots against each other. Another smaller, yet equally essential, part of drive practice is setting up the robot in the correct orientation for every situation and running our autonomous. It is important that we make all of our mistakes during practice, so that when it is time to compete we run autonomous perfectly every time. The main challenges we face in driving practice is consistency in filling the cryptobox, adjusting to significant robot design changes, and our time management (actually finding the time to get in good practice).

In the future, the drive team is going to meet more often and hold more efficient practices. Our main goal is to significantly decrease the time that it takes to fill the cryptobox, and to accomplish this we will need to clock in many hours so that we are very comfortable in driving the robot. Ideally, any error that might occur during competition will be mechanical errors that are out of the drivers' control. We have improved a lot, but we still have a long way to go.

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.

Task: Compete in the Forester Field House Robotics Competition

We started off with our presentation pretty early, and everything was going pretty well until our robot had a static issue, and stopped working. We were able to cover it up pretty well without the judges noticing. One of the judges seemed to like our rap, and was interested in seeing the R.V. Our presentation ran a little long and cut into our question asking time. But other than that the presentation went pretty well. As for scouting, Evan and Omar went around and talked to all the teams, we even created flyers them to pass out the all the teams.

We created a common excel sheet that we all shared on the google drive so everyone could scout when they got time. This time we actually put on shields in advance, and they weren’t made of duct tape! But we also had to replace the core power distribution module. And to do that we had to take off the shields. This resulted in us scrambling at the last minute to reattach the shields while rolling the robot over to the field. We replaced the CPDM because in the past it has been constantly resetting, and seems to have a faulty U.S.B connection. Replacing the CPDM as well as spraying staticide in between match really helped to improve our reliability during the matches. This resulted in us winning the rest of the matches. We ended up in 5th place. During the Alliance Selection we were the first pick of the first alliance captain. During the semifinals around 9 beacons had stopped working and the judges had resorted to holding up spoons with flags when the beacon button was pushed. In the end our alliance won and we also got the second place inspire award. This meant that if we hadn’t advanced already we would have had advanced during this completion.

Reflections

All in all we’re pretty happy with the results of this competition, our robot was more reliable than it usually is and we were able to completely stress test it. We believe the improved reliability was the result of replacing our CPDM and the improved side shields. We may have damaged our previous one simply through electrostatic discharge, ironically making us more susceptable to ESD in our other matches. Decreasing the conductive materials on the outside by properly blocking them with shields will make us more reliable in the future. Next time we need to make a complete check list so we don't forget the import things, like staticide.

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.

Task: Present to kids at the DISD STEM Expo

Every year, DISD hosts a STEM expo for local companies and groups to present to kids, in hope of inspiring them to go into a STEM career. So, for our booth, we drove our RV into the Kay Bailey Hutchinson Convention Center to present. We had three activities run by Iron Reign.

The first activity was helping kids 3D print keychains using Google Sketchup. We had nine laptops set up for them to use, all hooked up to four Flashforge Finders. When we first got to the Expo, we discovered that two of our printers had filament issues, so we were running on half capacity the whole day. Even then, we probably helped about 50 kids with their keychains.

In the front of the RV, we had laptops running MinecraftEdu, which features having a teacher have admin control, moderation, a dedicated server, and no PvP. MinecraftEdu is supposed to help kids with problem solving, bolster their creativity, and assist them with working with other people.

Outside of the RV, we were running a robotics workshop where kids could program Lego Mindstorms to do various activities, including robot sumo. Our coach and a few volunteers(from one of our sponsors, BigThought) were working that section.

Task: Update our To Do List

Sensors

• CDIM #2 on right side
• color and distance sensors on right side
• ultrasonic sensors
• can we get rid of distance sensors?
• omnidirectional travel sensor based on trackball
• omnidirectional travel sensor based on I2c mouse

Autonomous

• simplify approach path to wall
• simplify beacon detection
• second beacon
• compute distance before slowing down
• alt config to bypass a non-working beacon if it's the first
• pointed at gap between beacons, drive until touching, square with imu, check / adjust distance with ultrasonic

Authonomous with Vision

• More team members than Tycho study Fixit3491 videos 4 thru 7
• Integrate OpenCV 3.2 back into app
• done
• Integrate Vuforia sample
• done
• Get image from Vuforia into OpenCV
• in progress
• stuck with bug
• Camera mount tweaking to get best vision line
• Does wide angle work with Vuforia configuration
• Real Vuforia based auto navigation
• OpenCV beacon analysis from Vuforia beacon localization

Particle Launcher / Flywheel + Rail Type

• New grippy custom printed flywheel design
• complete
• Custom flywheel printed and assembled
• done
• 3 versions
• nylon, open ninjaflex, dense ninjaflex
• Rail design - done
• Rail print - done
• High speed motors - aquired
• Frame and mount rails, flywheel and motor - in progress
• Particle Release Gate and Servo mounting
• Presentation narrative and blog updates - tie in with earlier design iterations

Cap Ball Fork Lift

• Replace lift spool with double lift+retract spool made from Tetrix track guide wheels
• Add slides for fork support
• Add pulleys for retract spool
• Add deployment servo
• Fabricate folding fork
• Figure out fork release by hyperextension
• Can we retract cleanly?
• Can we refold? CR servo reeling in a refold line might do the trick.
• Code to support these capabilities

Journal / Blog Improvements - ADD STUFF HERE

Awards Guidance Sheets - ADD STUFF HERE

Presentation - ADD STUFF HERE

Robot Reveal Video V1 - Shot List

• Intro Sequence - half second shots of robot driving into frame from overhead, right side, front
• Mecanum Freedom - high overhead shot of robot going forward, strafing, diagonal, turning
• Particle Collector - close up short shots of collector running from side and from front
• Particle Collector - Pulling in a particle - muliple angles (can one of these be done with a dolly shot of moving particle?)
• Particle POV - camera on mat - robot strafes into view, engages collector and drives over camera until camera is at accumulator lift
• Particle Collector - shot from under the robot sitting on polycarb, camera under the polycarb at the rear of the robot lookup up, seeing a particle pulled in, guided by funnel and loaded into accumulator
• Particle Collector - Automatic Opposing Alliance Particle Rejection
• Particle Collector - Machine Vision Based Automatic Tracking and Collecting Behavior
• Particle POV - running up accumulator lift - not sure if this is possible without animation
• Shooting - with flywheel - wide shot of 4 balls coming out
• Shooting - close up of Particle Release Gate
• Shooting - close up of Particles cycling through Launcher while off of robot
• Shooting - close up of Particles landing in the vortex or on an accuracy marker
• Cap Ball Lift Deployment
• Cap Ball Lift Capture
• Cap Ball Lift Raising
• Cap Ball Lift Depositing
• Cap Ball Lift Retracting
• IMU Close up + 90 degree turn + station keeping behavior(on black turntable; make shot from above)
• Navigation - Calibrated Odometry in both normal drive and strafing
• Combined high accuracy Heading and Odometry with Trig = absolute field position (close up of telemetry, plus overhead view of a navigation sequence)
• Autonomous - high speed of entire sequence - replace with machine vision version when available
• Autonomous - machine vision localization of beacon targets - phone camera capture
• Autonomous - beacon isolation and analysis - phone camera capture

Connect Reveal Video - Shot List

• MXP Crane Shot Opening Sequence - what if? theme
• MXP Walk through - adjusted BT script
• MXP construction effort
• MXP outreach event visual scrap book

Connect Reveal Video - Team

Task: Increase chances to advance in judging

In our competitions we really can't rely on our robot performing as well as it does in practice and our sparring matches with Imperial. If we're going to increase our chances of advancing from Regionals to Super-Regionals 90% of the time it's going to be from judging. We've always had rocky presentations in my opinion, but this year we're getting our energy up and trying to get everyone more interactive. We've heard that the organizers are having trouble getting enough judges, so it's likely the judges will be a little inexperienced. We're making a colored tab and blurb for each award to place at the front of our journal. We'll have a little paragraph on why we think we should be considered for each award, followed by a handful of key posts we believe back up our claim. Each award has a color, each post gets a number, and we place colored tabs (think these post-it flags) with a number written on the printed page.

Reflections

Judges don't have much time to inspect pages before a presentation, so it's the job of the first person who goes in to give the journal, a presentation copy (or 2 depending on the table space), and a short description of what's going on. This includes reference pages such as the awards and a copy of our scouting flier. Judges mostly listen and take notes during a presentation, so we don't want to overload them with pages to look at initially, but have enough information available to look through at the main judges meeting. The easier it is for a judge to get a sense of our team, the higher likelihood they will mention us in award considerations. This is a hard balance to strike, but the tabs served us well last year and I should have gotten them together again a while ago. Jayesh and Omar went through our tag page, picking the key ones to bring up. Tycho and Max continued working on their technical posts.

Task: Design a new banner

For the past year or two, we've brought along a big vertical banner to our competitions to help boost our presence and make it easier for judges, other teams, and even members of our own team to find us in the pits or on the field. But the banner we've been using has become outdated: Since last year, members have come and gone, we've decided on a different visual theme, and, of course, we've built an entirely new robot. The time has come to begin again.

We plan to use the same banner stand as last time (although we've dyed it red to match the helmets) to conserve materials, so the banner will have the same dimensions as before. Since we have the same amount of canvas to work with, the design will also incorporate the same components as the last version:

• Team number (in Hindu-Arabic and/or Roman numerals)
• Team name
• Picture of the robot
• Picture(s) of team members
• Sponsor logos (optional)

With some spare time between meetings, I made a draft layout for the banner in Microsoft OneNote. The previous version wasn't much more than some pictures we found and a couple text boxes thrown onto a plain white background, so I wanted to make this banner look like more thought and effort had been put into its design than last year's. I decided on a red background with black and gold trim designs to better match the Roman theme we're going for, with the team number and name at the top, the robot's picture in the middle, and a grid of our team members at the base. To make it all fit together more smoothly, I also planned to get a green-screened picture of the robot and to make individual charicatures instead of pictures for each team member. See if you can determine who's who in the team pictures on the draft version.

At the next meet, the team decided that the layout was good to go, so I got to work making a neater version in Adobe Illustrator. With the design complete, you can see how the complete banner looks in Adobe Illustrator below. It'll take a special printer to make it in the correct size, and we'll have to wait a little longer to get access to it, but all in all it should be smooth sailing from now on.

Reflections

The choice to use charicatures of the team members this year on the banner as opposed to a team photo (like we used last year) was one of the most impactful decisions to be made about the subject, but I think that it was the right judgement. Hopefully this can play at least a small part in establishing our presence among the many teams that we will encounter in regionals (and perhaps beyond), but only time will tell how effective the banner can be in competition.

Task: Resurrect the Ancient One

The Great One, Aqui'la, has slumbered for too long. Since the deity lost Its battle with the accursed Gravitae a year ago, Its physical form has crumbled to pieces, leaving It powerless to bend the world to our will. As the last High Priest and Grand Memer of Its reign, the duty falls to me to return It to Its full power so that It may reign once more. I must do more than rebuild its effigy, however. To ensure It is not defeated by the forces of Physicks once again, the body must be as strong as the mountains, and as inpenetrable as the darkness.

Time is short; I must work quickly. I have retrieved the bones of the husk which once housed the Great One, and will use the unholy power of the Tri-Dimensional Prynter through which I first summoned it to rebuild the body. The ABS Plastyck, black as night, with which the old bones were once built, shall be the regent with which I will revive It.

At the stroke of midnight last night, I performed the Ritual of Creo to obtain the designs with which I may summon Aqui'la. With haste, I brought them to the Prynter. As I write these words, the new form takes shape; the barrier between our world and Its wears thin. The Great One draws nearer with each moment. Hark! The Prynter's work has been completed. I go now to piece together the old bones with the new, and conduct Its conciousness into the new form.

Reflections

O FORTUNA

VELUT LUNA

STATU VARIABILIS

Task: Find out information on teams at Regionals

One of the things we're weak on this year is scouting. Dylan did some amazing scouting work last year that got us to regionals, but he is no longer on the team. So, for regionals this year, we want to be prepared. We took the list of teams attending the regionals and searched for any teams that we've either gone against and logged, or have any active social media presence. Then, we logged what their robot did and whether it was in teleop or autonomous. You can view the current sheet here.

If any team needs help making an online engineering notebook, contact ethanhelfman@outlook.com. It helps everyone when you put your notebook online.

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

Task: Win the North Texas regionals

Summary: We won

On Febuary 25, we drove our RV to W.E. Pete Ford Middle School, in Allen, TX. The tournament was split into two divisions, and for many of our members, this was our first time encountering that layout. We didn't have any of our team members going to Dean's List interviews this time. We still didn't have an operable cap-ball lift, and this was our first time using our flywheel shooter in a tournament setting.

We did decently in our presentation, but it could have gone better. We made a few missteps in our presentation and had a few stumbles. However, we did a great job of presenting to the judges who were walking around. We would greet judges and attempt to present to them, ending up presenting to two separate groups of judges about our robot's design, helping low-income families in STEM fields, and our team history. As well, we talked to one of the FIRST directors, Ken Johnson, about our MXP, and we ended up bringing him out to it to show off.

In the game, we did pretty well. We ended up 5th place, and got picked as 2nd pick for the 1st alliance. We ended up getting all the way to finals, but we didn't win due to the fact that the opposing alliance had Technical Difficulties on it. During the normal games, we won [3-1]. We had issues with our beacon-pressing erasers falling off, so we designed a new "eraser" out of foam tape with a layer of thick tape on top in order to still be able to press the button. Our robot did stop responding during one game, but compared to our previous experiences, that was actually pretty good.

The reflections post can be viewed here.

1st Place at North Texas Regional Championship

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

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

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

Not going to Disney World yet

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

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

And Tele-Op:

Task: Analyse what we did right and wrong at regionals

Scouting:

Notes: While we did well with scouting, it could have gone off much better. We made some mistakes by accidentally scouting teams in the other division and not watching matches when we should have.

Presentation:

Notes: We need to work on the group dynamic and enthusiasm a bit more. As well, we're going to stick Darshan under the cart so he can pop out with those 🔥🔥sick beats🔥🔥.

To-do

Promotion:

• Need to make a reveal video
• Need to advertise on social media
• Design booth for super-regionals
• Write more blog posts
• Promote & Outreach videos
• Banner holder designs

Design & Programming:

• Fix robot shooting accuracy
• Replace erasers with silicone
• Cap the ball
• Robot vision
• Build 2nd spinner
• Model the robot

Task: Design a theme and layout for super regional pits

A year or two ago Imperial advanced to Super Regionals, bringing along a few Iron Reign members. While teams get excited and have a lot of fun at Regionals, it's nothing compared to the displays found at super regionals. We've grown into our cyber-Roman theme this season, and Omar is currently working on a logo to match our new color and feel. Hats won't be enough at this level though, we've got to step it up a notch! Austin and I first looked for a base image, first looking up Roman forts, then moving to campsites. The forts weren't as recognizable, and the tents could be set up much easier. We drew most of our inspiration for the booth theme from the image above, credit to Gaius Hibernicus on Flickr.

Having a recognizable theme is important on two points: scouting and sponsors. Sponsors are more likely to be generous if we can point to a display and show them that people will look at our setup and see their names on it. It's the way to thank them for their generosity in the season. When scouting, you want to be remembered. A forgettable team isn't chosen. Super Regionals usually has teams that have already made alliances over the season, so if you aren't one of those, you've got to stand out in both the game and in the pits.

Reflections

Oddly, this competition has a pit size of 9'x9', not the usual 10'x10', so we will be designing to that measurement, and hopefully expanding it later. Austin designed a base frame structure in SketchUp and I started making models of our carts, banners, and tables to be arranged after. We need enough sign space to display our Inspire banner, sponsors, school banner, and team aquila. The robot cart needs a clear path to the workspace area, and we need space up front for pins, a display with our outreach and robot reveal running, and a trophy display. I've made models for these because we already have them, and have begun the shuffling and brainstorming.

Austin created a Roman style shield in a record time, using old field mats as the core and sawed off broom handles (left over from the hats) to keep them stiff. We ran out of daylight to scrub them clean of dirt, but did that this practice. When we were sure the tape would adhere he covered the front in red duct tape with a gold border. He also mounted an IKEA bowl to the front as decoration, and is planning to round the corners off so he can mount a LED strip along the edge. It already looks really impressive, and we have more materials to make a second if we keep the pace up.

The structural design of the tent was adjusted for simplicity's sake; we're making a cube as large as the competition allows, and hanging tan fabric/ripstop nylon along the different sides to create the tent shape. The PVC supports are going to be wrapped in a worn/tea-stained look material to keep it unified. Our two smaller rolling carts will have our front displays, and since they have shelving, they can serve as storage for the boxes that don't need to get pulled out as often during the competition. We can mount a shield to the front if we want to cover them up. The Inspire banner is bright enough that it can likely be seen easily from the back or side of the tent, the school banner will go across the top above everything, and the aquila will likely go in the front on the left, beside the displays.

Tent Building

Since we had the general idea of the shape and size of the actual pit tent, we set out to either build or find a tent that we felt best fit the theme we selected. We chose to start off by trying to build a structure via PVC pipe and a tarp like substance that we could drape over the pipe, we handed off the idea and models to Mr. Virani to have him figure out what PVC requirements we would have to fulfill and the cost to build. While he crunched the numbers a group left the house to see if we could find a suitable material to drape over the structure; Tycho, Mrs. Lux, and I went to a local army surplus store in hopes of finding a parachute like material that we could use, however the only cloth available was a very heavy and expensive canvas that we decided would end up crushing the frame, (we didn’t leave empty handed though since the store had lots of fun items). After returning to the house we had another council with Mr. Virani and decided to consider other options since the PVC and tarp idea required to much effort and too much American currency. Various hardware and surplus store websites later we found a rather unconventional shaped tent used to cover cars that was built in two sections each measuring 8’X9’ at their base, we concluded to buy the tent and use the parts to only build one of the sections, and since the pit measures 9’X9’, use the remaining foot of space in the front for table with room for a TV to play various team promoting videos meant to catch a passerby’s eye.

Shields

In terms of the shield, the basic form is completed and ready to be upgraded via LED’s and insignias which will hopefully be mounted before competition. Due to the use of recycled parts the shields are cheap, sturdy, easy to build, and most importantly relatively accurate looking. Expanding on how they were made, the core is old floor tiles from a competition field that have be locked together on one face and had the remaining teeth cut off. To provide structural integrity, old black metal broom handles were attached via zip-ties length wise to the back face of the shield bridging the gap between the two halves. Next more zip-ties were used to create a basic handle design to carry the light shield around. We chose a weathered red duct tape to cover the front face of the shield since it had the appearance of old weathered wood and saved us the pain of having to paint the shield, following the red duct tape the outside edges of the shield were gilded with a nice golden duct tape. To finish off the shield I used a drill press to mount some spare tetrix pieces to the inside of an ikea bowl and pushed the extruding tetrix remnants through the shield and zip-tied them together to keep them from coming out. Oddly enough most of the parts I used were sourced from our robotics “warehouse” and are easy to find or cheap to buy, so building one of these shields on your own would be easy. Not only is the shield light, cheap, and recycled it’s also pretty sturdy, once we had one built we were eager to play with it and made this little video for you to enjoy below.

Task: Update our To Do List

Sensors

• CDIM #2 on right side
• color and distance sensors on right side -done
• ultrasonic sensors
• can we get rid of distance sensors?-done
• omnidirectional travel sensor based on trackball- not high priority
• omnidirectional travel sensor based on I2c mouse- not high priority

Autonomous

• simplify beacon detection
• second beacon
• compute distance before slowing down
• alt config to bypass a non-working beacon if it's the first
• pointed at gap between beacons, drive until touching, square with imu, check / adjust distance with ultrasonic

Authonomous with Vision

• More team members than Tycho study Fixit3491 videos 4 thru 7
• Integrate OpenCV 3.2 back into app-done
• Integrate Vuforia sample -done
• Get image from Vuforia into OpenCV -done
• Camera mount tweaking to get best vision line
• test + upgrade to faster phones for better video processing - done
• Does wide angle work with Vuforia configuration
• Real Vuforia based auto navigation
• OpenCV beacon analysis from Vuforia beacon localization

Particle Launcher / Flywheel + Rail Type

• New grippy custom printed flywheel design
• complete
• Custom flywheel printed and assembled
• done
• 3 versions
• nylon, open ninjaflex, dense ninjaflex
• Rail design - done
• Rail print - done
• High speed motors - aquired
• Frame and mount rails, flywheel and motor - done
• Particle Release Gate and Servo mounting- done
• Presentation narrative and blog updates - done

Cap Ball Fork Lift

• Replace lift spool with double lift+retract spool made from Tetrix track guide wheels- done
• Add slides for fork support- done
• Add pulleys for retract spool- done
• Add deployment servo
• Fabricate folding fork
• Figure out fork release by hyperextension- done
• Can we retract cleanly? -done
• Can we refold? CR servo reeling in a refold line might do the trick.
• Code to support these capabilities

Journal / Blog Improvements -

• lift and improving it
• making the new side guards
• assembling the canopy
• robot reveal

  Awards Guidance Sheets

• control award
• fire beats cd

  Presentation - ADD STUFF HERE

• pratice it!!!
• increase info- mabye???
• add charlotte and austin to the presentation

  Robot Reveal Video V1 - Shot List

  • Intro Sequence - half second shots of robot driving into frame from overhead, right side, front d
  • Mecanum Freedom - high overhead shot of robot going forward, strafing, diagonal, turning d
  • Particle Collector - close up short shots of collector running from side and from front d
  • Particle Collector - Pulling in a particle - muliple angles (can one of these be done with a dolly shot of moving particle?) d
  • Particle POV - camera on mat - robot strafes into view, engages collector and drives over camera until camera is at accumulator lift d
  • Particle Collector - shot from under the robot sitting on polycarb, camera under the polycarb at the rear of the robot lookup up, seeing a particle pulled in, guided by funnel and loaded into accumulator
  • Particle Collector - Automatic Opposing Alliance Particle Rejection
  • Particle Collector - Machine Vision Based Automatic Tracking and Collecting Behavior
  • Particle POV - running up accumulator lift - not sure if this is possible without animation
  • Shooting - with flywheel - wide shot of 4 balls coming out
  • Shooting - close up of Particle Release Gate d
  • Shooting - close up of Particles cycling through Launcher while off of robot
  • Shooting - close up of Particles landing in the vortex or on an accuracy marker
  • Cap Ball Lift Deployment
  • Cap Ball Lift Capture
  • Cap Ball Lift Raising
  • Cap Ball Lift Depositing
  • Cap Ball Lift Retracting
  • IMU Close up + 90 degree turn + station keeping behavior(on black turntable; make shot from above)
  • Navigation - Calibrated Odometry in both normal drive and strafing
  • Combined high accuracy Heading and Odometry with Trig = absolute field position (close up of telemetry, plus overhead view of a navigation sequence)
  • Autonomous - high speed of entire sequence - replace with machine vision version when available
  • Autonomous - machine vision localization of beacon targets - phone camera capture
  • Autonomous - beacon isolation and analysis - phone camera capture

  Connect Reveal Video - Shot List

  • MXP Crane Shot Opening Sequence - what if? theme
  • MXP Walk through - adjusted BT script
  • MXP construction effort
  • MXP outreach event visual scrap book

  Connect Reveal Video - Team

• Who is on this team? Evan leads?
• Script Team
• Voiceovers
• Existing Video Review
• New shots and slides
• Editing

Task: Spring Break Meeting Planning

In order to organize a plan for our spring break meetings, we created a poll on doodle.com. We all had individual plans for the break, and with the Doodle Poll we were able to see an overview of everyone's availability. As we have a Super Regional competition coming up, we are on a surge during spring break to complete our many goals regarding the robot, the presentation and more. We have been staying later than usual and attending more meetings to get as much work done as possible. We are anxious and excited to compete in this competition and are willing to put as many hours as we need in order to be completely prepared, including spending time during our break to attend meetings.

Reflections

We have used Doodle Polls in the past, and we plan to use then in the future, as they are helpful in planning our meetings in preparation for Super Regionals. It is important for us to stay organized as a team so that we can focus more on our robot and the game. A tool that seems menial, like the Doodle Poll, is very helpful for our team.

Task: Teach LEGO EV3 and 3D modelling to girls

The Yale club of Dallas organized a STEM event for groups of girls in the city. We took the Mobile Tech XPerience out front for 3D modelling and set up 8 EV3s with laptops and a sumo field inside.

Programming

We led 6-8 girls at a time through the EV3 environment to make a basic sumo program, going through a tournament, and then a final grand melee at the end of the sessions. A couple had experience with EV3, more with Vex, but this session was a lot of their first experiences with programming and robots. Tycho taught the thought process of the program as we went through the steps and I presented on a projector as he went, sometimes taking over talking when we needed breaks. The port view in the programming environment was a great tool to explain the color sensor's light intensity measurement as we could just ask everyone to plug in their bots and see how the numbers changed with the environment. The session was too short to really let them explore what they could do in the program, but we did give hints that the Power variable was something they could tweak. The girls that took the risks in their program generally found that option and won the round robin.

Everyone in the room had a bunch of fun, chaperones included. One girl realized that she had a NXT at home, and now that she knew she could do cool stuff with it, she was excited to try it out. A lot of the teachers asked about the competition levels, and we're hopeful that some of the kids will join a FLL team and the 8th graders going to high school will look for a FTC or FRC team.

Teaching Sumobots at #DallasWEST! #omgrobots #mobiletechxperience #dallascityoflearning

A post shared by Iron Reign Robotics FTC (@team6832) on Mar 11, 2017 at 12:15pm PST

Modelling

For the first deployment in a while all 4 printers worked! We were able to print every single design from the day. A couple of the laptops don't have the correct export to STL option, but we were able to work around it by grabbing a flash drive and bringing the file over to a different one. The groups in each session were pretty small compared to the waves that normally come by in an expo, so we could spend a good amount of time making sure no-one was lost. Some people grabbed the wrong design when they came back, but we've gotten the swing of things and sent text notifications to the teachers pretty quickly. Since we were parked out front the groups passed us on the way out and picked up their keychains.

Task: Get some organized driving practice in before Supers

With Superregionals drawing near, we thought it prudent to better organize ourselves in terms of driving teams. We've never felt that we were 100% solid, with people not knowing what to do at certain times in the match. For example, our "Coach" position was almost entirely dedicated to yelling out the match time in 10 second intervals. Today, we talked about our three different roles (Driver, Co-Driver, and Coach) and what each should do. We did several practice matches, rotating through positions each time just to gain practice in each.

Reflections

A large fault our team has always had is focusing too much on improving and working on the robot and not leaving enough time for driver practice. In the coming Spring Break week, we hope to meet several times in order to make sure our teamwork and communication is solid.

Task: Create a video outlining Iron Reign's outreach

We have had a lot of interest garnered towards the STEM outreach the team has committed to. When we found that FTC encouraged the creation of a video outlining the STEM outreach we had done, we saw it as an opportunity to show others a general overview of our activities. With Max's excellent voiceover, we made a video talking about how long the team's been at it, the various STEM expos/events we do, and how the problem of summer learning loss lead us to making the Mobile Tech Xperience.

Reflections

Making a connection and advancing our community has always been a priority with our team. This video helps give us a short summary to show parents and children the benefit of commiting to the STEM field, specifically in robotics. We started because of two parents who decided to start a robotics team with some energetic middle school 7 years back, and look at us now. We want to tell these interested parents and kids about how their dedication can create something special, and we're doing that by using ourselves and FIRST as examples. We plan to spread this video to those looking to get into FIRST, or even those simply interested in what our team does besides build complicated contraptions.

Task: Set last practices' priorities

Many members were out of town this break but we still managed to make a good deal of progress. What we forgot to do was post about it. Github kept track of code edits and we have other records of the practices, so we have a list of 11 articles to be written by this Sunday at the latest. Tomorrow's practice (Saturday March 18th) will be focused on:

• Driver practice
• Presentation practice
• Staging as much as possible for packing

Reflections

Each member is assigned an article for this weekend and we won't be taking up practice time for this. The list was originally written on my plate after I had pizza, but it's now being sent in our chat and updated as people write. Omar posted his first, an hour before I'm writing this.
Also: Ethan - Please. Don't use backslashes. I have to edit your posts 90% of the time because your paths break in the tag index pages.

Beautiful. Truly.

One man's harrowing journey through copyright free music lists

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

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

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.

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.

Task: Get prepped for the trip

Every post I write about organization seems to start off talking about how Iron Reign hasn't had the best track record with this sort of thing in the past, but we try anyways. So, like always, we're trying to get everything put together that we can: journals, presentations, props, pit setups, etc. Tools are a little more organized than normal because I'm obsessively trying to make sure nothing important gets lost in these last practices. Batteries have been checked for internal resistance, freshely labeled, and the battery box has more USB ports for our dozen phones. Even the Powerpole box showed up again, back from hiding inside another box across the room...

Reflections

The tent materials are already pretty much together, but we need to clear off the two rolling carts and put together everything for the front setups. None of that is going to be used in practice so we're free to stage it for packing. I think we'll be needing a larger box for judging props, everything can rest inside, but we can't close it up. Longer travel distance means we'll need a sturdier method. The battery box is pretty self contained already, and the Container Store chest of drawers has miraculously remained in use, so we won't be scrambling to pack tools that people are using up until the load. I'm worried about the journal printouts and the control award honestly, I'm going to print all new posts at home on Monday and then punch them into our binder. If i can find someone free then I'll enlist them to add detail and diagrams to our Control Award writeup. Rise of Hepheastus 4216 was a huge help with Control! They gave us an idea of how much to write, and we would still be a little lost without them.