Articles by tag: journal

CNC Machine Rehab 1

By Ethan and Charlotte


Task: Refurbish an Apple II CNC Mill and Lathe Set

We were helping our school's FRC team clean out their parts closet, which hadn't been cleaned in 10-ish years. Under the layers and layers of FRC junk, we found an Apple II-operated Patterson/Paxton CNC Milling Set. These were meant to run off of a long-since-gone Apple II in a classroom setting. But, it had long been auctioned off, leaving the set useless. But, Iron Reign, as a collective of hoarders, decided to bring these machines over to the house to refurbish.

The first idea we looked at was emulating the Apple II with an Arduino, as seen here. However, this implementation didn't have the response rate needed for an accurate CNC machine, so we scrapped it. Then, we found this post. The problem that people mainly encounter is that, for some strange reason, Paxton\Patterson used a proprietary parallel port pinout, and deviating from that pinout (read: using a standard parallel cord) would fry the optidriver board in the machine. So, we bought a ethernet-to-parallel port jumper box (UC300eth).



We then sliced a parallel cable in half, and rewired the wires to the pins, treating the left column of that of the port numbers on the board and the right as the pin numbers of the cables.





We then made a power supply for the UC300eth. We attempted to use a 10V DC power supply, and use a voltage splitter. Unfortunately, the power spiked, and probably fried the UC300.



Next Steps

We need to buy a new UC300 board and hook it up to a laptop with Mach3 to test the power.

DISD Scrimmage at Hedrick MS

By Charlotte, Janavi, Ethan, Evan, Justin, Karina, and Abhi


Task: Compete at the Hedrick MS DISD Scrimmage



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

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

First Season Scrimmage at Hedrick MS

By Trey, Bhanaviya, Ben, Jose, Justin, Aaron, Karina, and Cooper


Task: Compete and observe important things needed to continue the build of circle robot and for future competitions.



This Saturday Iron Reign attended the scrimmage at Hedrick Middle School. This scrimmage was for many rookies, the first exposure to a competition environment and the basic structures of team communication. Both the rookies and the returning team members had an opportunity to communicate with different teams and to get exposed to different ideas and their respective thought processes. Iron Reign used this scrimmage as a way to look at what robot designs were most effective and a lot of key aspects of the game we may have glossed over earlier in the season.

Many things determined a robot's effectiveness, for example, we noticed that the robots in the competition that did the best were the ones that had the most direct routes and were able to manipulate the stones efficiently and effectively. We also noticed that positioning and placing the stones on the towers was very difficult for us and the teams without programs that automatically line up the stacks. This strengthens our need for circle robot which when finished should be able to stack with much more precision than the average robot. The other thing that the circle robot would help with is lining up the arm to pick up stones which also proved to be very challenging for teams with grippers that need to grab a block in a certain orientation like us.

There were a lot of unexpected penalties that can change the tides of a game, for example, the human player can not place an object in the quarry if there is already an object in it. Doing this awards 15 points to the opposing team. Another thing we learned is that to receive the points from delivering a stone the robot must fully cross over the tape under the bridge. A lot of people with push-bots lost points because their robots didn't fully cross the tape. Overall, penalties and losing points were easy ways for a team to lose a match quickly and if we don't watch what we do we can potentially lose an entire competition because of them.

Next Steps

Our next steps are to keep working on the circle robot because it should be able to better complete the challenge. We also see like never before that even though this robot is not done, we still have Frankendroid and we still need to perpetually do driving practice with it because ultimately, the best teams will have the most driving practice. However, the biggest next step we are taking is that we are coming to practice more often because our first qualifier is so close but we are so far from a good robot. There is still a lot of work to do.

Meeting Log 3/29

By Anuhya, Georgia, Trey, Gabriel, Ben, Cooper, and Paul


Task: Getting in some serious drive practice at Woodrow



We took some time out of our week to get in some drive practice at Woodrow so we would be able to practice working together with another team and collaborating with a make-shift alliance.

Drive Practice at Woodrow

Practice matches run: 16 The main purpose of our drive practice at Woodrow was getting drive practice with another team, the Mechanicats. This would be one of our only opportunities before UIL to practice with another team and play in a full practice field with another team working as an alliance. One of the challenges we faced today was with our drivers learning how to work together. There were many kinks with having two people drive, including having two separate controllers with their own unique functionalities. One controller deals with the intake inside the warehouse while the other deals directly with the alliance shipping hub and the arm. Learning how to collaborate while using both was a difficult obstacle to overcome, especially because we didn’t have as much drive practice overall as we would have liked. Another major challenge we faced was getting the team shipping hub to not tip over. Our arm would extend too low and it would tip over the team shipping hub if we weren’t careful. Right now, we are working on maneuvering so it doesn’t tip it over, or only slightly nudges it. We also started working on our duck game, because we realized we didn’t have our duck spinner as efficient as we would have liked. The band which held the duck spinner back from deploying early snapped when we were setting it up, so we had to make do while practicing.

Next Steps

We are planning on getting even more drive practice as the days progress and we’re getting closer to UIL. We also need to work on not tipping over the alliance shipping hub, because that is a major penalty and it also makes it nearly impossible to get any points afterwards. We also need to figure out how to “double duck” with our current duck spinner, meaning we have to spin the duck off the duck spinner and then deposit them in the alliance shipping hub. Trey is currently working on redesigning the duck spinner so it has a wider range of compliance. This is so we can maintain our goal of “double duck”, which needs a larger range of motion and a robot which can reach further. We also need to keep working on strategy, so we can finalize what we’re running with at UIL and have time to practice it.

Meeting Log 4/01

By Vance, Georgia, Trey, Gabriel, Bhanaviya, Leo, and Mahesh


Task: Replace Crane Servo with a Motor

After six broken servos amounting to around 240 dollars worth of funding, it became apparent that the current model of servo we were using wasn't up to the task that it needed to fulfill.

First came the issue of figuring out how to mount the motor. An HdHex Motor was decided upon as it was able to support additions to increase the gear ratio, while a CoreHex motor had around the same power as the servos previously used. We were able to use a 90 degree mount in order to attach the motor as to not allow it to jut out of the robot, which would break the proper sizing restrictions. After assembly, it was found to solve most issues found with the servos, though did introduce the issue of leaning due to the unequal weight distribution. So far, it has had a better performance than the servos did

Next Steps

Figuring out how to mount on a counterweight to offset the weight of the motor so both the crane and the robot no longer lean off to one side

Last Practice Before UIL!

By Anuhya, Georgia, Bhanaviya, Ben, Mahesh, Gabriel, Aarav, Trey, Shawn, and Leo


Our Last Meeting Before UIL!

This marks our final competition of the Freight Frenzy season.



Getting in our final drive practice

Trey, Georgia, Ben and Gabriel got in their last couple hours of drive practice at the RoboDojo. Knowing this was our last time we would be able to practice in our home field, we made sure that we knew exactly what we would be doing at UIL. Mahesh was cleaning up the code, tuning up the arm and getting it so that when you press dump, it goes up and then goes down so it doesn’t run into the shipping hub.

Yesterday's meeting

Yesterday, Trey and Georgia got a lot of drive practice. They tested the robot with the sizing cube to make sure that it fits within the regulations. Trey also installed a grasp rivet on the bucket which allows the distance sensor wire to go through the pivot point so it doesn’t tangle and so the bucket’s auto dump works. The bucket’s auto dump wasn’t working because the distance sensor’s wire couldn’t be plugged in without getting tangled. The grasp rivet helped the wire go through the pivot point without it breaking, so we could use the distance sensor seamlessly.

Packing for UIL

We had to pack up all the necessities for the UIL trip. We worked on ensuring that we were fully prepared for success at the UIL competition and we tried to foresee any unexpected circumstances and prepare for them. We were fully ready to stock up the bus tomorrow morning before heading for Houston.

Designing the New Workshop

By Aarav and Anuhya


Task: Design a floorplan and model for the new workshop

With the limits of our current workspace reached and the need to expand with more recruits and machinery; Iron Reign set off on a new summer project. The objective: design a new workspace for Iron Reign to be constructed further into the property. This new workshop would help Iron Reign improve our fabrication and machining capabilities and expand our program. It also served as a productive way to spend our summer and improve our CAD skills.

A few major constraints and requirements had to be fulfilled by the new workshop, mainly increased capacity for teams and equipment. 2 full-size playing fields were needed to accommodate both Iron Reign and its growing sister teams, and more space for machines, tools, and storage to help delay the workshop's inevitable descent into chaos would be ideal. Finally, we also decided to include brainstorming areas, basic amenities, and a garage for vehicles.

With our concepts and ideas somewhat straightened out, we began developing a floor plan that fits in the cleared-out patch of land on the property. After a few days of work and revision, we had a basic floorplan complected with dimensions. Below is our preliminary floorplan, which included all of the requisite areas.



After that, we decided to take the design to the next level by turning our 2D design into a 3D model, using Fusion 360. Here we had to add components like doors, windows, hallways, walls, and roofs to our design. This helped better prepare it for construction and allowed us a chance to include model furniture to help verify our dimensions and make sure we have enough space. After a couple of weeks, we had a preliminary 3-D model. It is still not finished, and we are continuing to iron out any issues and add more components.



Next Steps

After finishing the 3-D model, the next step would be to think about construction and start contacting contractors to help sort out any potential issues, along with potentially finding ways to fund this project.

Dallas City of Learning at Frontiers of Flight

By Aarav, Anuhya, Gabriel, Trey, Vance, Leo, and Georgia


Task: Connecting with the communoity through the Frontiers of Flight

This morning, Iron Reign demoed at the Dallas City Learning event at the Frontiers of Flight Museum, which had over 550 attendees. This fair featured STEAM activities from local organizations and the museum, along with local industry professionals.



At this event, we demonstrated our previous year’s robot, The Reach, and its capabilities on the field to the public and industry professionals from Waymo. Waymo is a subsidiary of Google that focuses on autonomous driving in order to transform lives in a safe and effective manner. We were able to talk to them about our robot and get small bits of feedback on its design and code. Here, we are both able to motivate the community while also connecting with industry professionals.



Additionally, we also engaged in a LEGO Mindstorms robotics activity with young children where they were able to build and code LEGO robots and then battle each other’s robots. This should help spark interest in children about the world of STEM and possibly motivate them to consider it in the future.



Recruiting at Flight School

By Aarav, Anuhya, Gabriel, Leo, and Georgia


Task: Recruit new members at the TAG Flight School

Earlier this afternoon, at TAG's flight school event for new freshmen, Iron Reign had a club booth for all the new freshmen to check out. There was a quick recruitment presentation for all the people who showed interest. Potential members also received information about the first meeting at our offsite location. Recruitment efforts like these are important to fill up our sister teams Iron Core and Pandemonium and help ensure the sustainability and longevity of the Iron Reign program. With a decent amount of the current iron Reign team being incoming seniors, it is important to keep recruiting potential members who can move up the ranks and eventually replace those who graduate.



Next Steps

The next steps would be to have all the new members attend the informational meeting offsite and be divided among our sister teams if they do commit to the program. Further recruitment efforts at SEM would also be welcome.

FLYSET Workshop

By Anuhya, Gabriel, Trey, Vance, Leo, and Aarav


Task: Give a presentation at the FLYSET Workshop



At the FLYSET Workshop, hosted by team 8565, Technicbots, and team 20313, Mustang Robotics, we were tasked with introducing our remote controlled excavator, Mechavator, to the advance track attendees.

Gabriel was tasked with making the presentation and script for the workshop, in which we would also include teasers about our video, Duck Hunt. Each of us were given certain slides to memorize and learn everything about, so we would all have enough experience to answer any and all questions about the Mechavator. The Mechavator was our project over the summer, and we were very excited to introduce it to the FTC community.

Reflections

As we reflect back on our presentation earlier, we have come to the consensus that the delivery was alright. However, we recognized that we didn't make our presentation for the audience. Since we were presenting for the advanced track, we should have gone more in depth with more technical aspects of creating the Mechavator, such as coding the Mechavator and the GPS RTK system. We only had 15 minutes for a presentation about a concept that hasn't been tried within FTC before, so we had to condense our content and this was the best outcome we could have hoped for. Nevertheless, most people enjoyed the presentation, because it was introducing a fresh idea of how robotics could be implemented. The presentation overall went well, and we connected the content from slide to slide seamlessly.

Next Steps

Our next steps are to post the videos where we showcase our Mechavator, as well as a parody of the FTC reveal videos. Unfortunately, we no longer have the Mechavator, but it's legacy will forever be a part of Iron Reign Robotics.

Interest Meeting

By Anuhya, Aarav, Georgia, Gabriel, Vance, Leo, and Trey


Our Interest Meeting at TMC

To gain more members for our sister teams, Team 15373, Iron Core, and Team 3734, Pandemonium, we held an interest meeting at Townview Magnet Center earlier today. It was crucial to get more members so we could continue the Iron Reign legacy for the future years, as our members are all from our sister teams.

Our new sponsor, Mr.Florczak, kindly let us use one of his rooms to host our interest meeting. We had an incredible turnout from all the grades, and we're all looking forward to forming new relationships with the new members of our team. We gave a presentation on what FTC is about and what an incredible opportunity joining this robotics team will be. We explained how our team works and showed them our accomplishments, including the Mechavator. The new recruits were very curious about Iron Reign Robotics, so we happily answered all their questions. We also presented our robot from the most recent season, The Reach, and demonstrated the innovative design. After we had finished everything scripted, we all split off to get to know all our new teammates.

Next Steps

The official kick off for the new game, Power Play, is happening this coming Saturday. The first thing we have to do is organizing the RoboDojo so it's robot-ready, and making sure the team, including the new members, are prepared for the new season.

Season Reveal

By Anuhya, Aarav, Georgia, Gabriel, Vance, and Trey


The Season Reveal of 2022-2023's Game: Power Play!



Today was the season's official kick off the 2022-2023 game, Power Play! However, Gabriel, one of our members, gave a wonderful keynote speech, taking inspiration from Steve Jobs, for the reveal of our Mechavator.

Initial Thoughts

Our first thoughts when we saw the new game, which is about capping yellow poles mounted on springs throughout the game field, was that we would have fewer options when it came to innovative designs. We also knew we would need to read the game manuals very thoroughly, memorizing small details so we knew exactly what the rules were and so we wouldn't have any issues with inspection in competitions. One of the main challenges would be getting a mechanism which would be able to grab the game pieces and place them onto the tallest poles, which are 30 inches in height. This is 12 inches more than the tallest height our robot is permitted to be at the starting position, meaning we would have to make a collapsible mechanism, such as a linear slide. We also need a method of picking up the game pieces which doesn't require too much precision so our drivers have more freedom. We are experimenting with beaters as well as different shapes of claws so we have a variety of options.



Next Steps

We will begin working on making a robot for Robot in 2 Days, which will be a base robot we will build on and adapt so it will be usable throughout the season. This is a way for us to brainstorm our ideas into a functional robot and see it in action.

Robot in 2 Days

By Anuhya, Aarav, Georgia, Gabriel, Vance, Trey, and Leo


Our First Ideas: Robot in 2 Days!



Our Ideas with Build

As a base robot, we started with an 18 inch cubic frame. This was the frame we'd most easily be able to modify and build upon as we progressed further into the year. For an initial brainstorming session, our Robot in Two Days would let us get some ideas into place which we could then bring up to our standard and innovate on.

First, we noticed that our motor placement would make it harder to retrieve any of the cones. We knew we would need a mechanism to bring the cones up at varying heights to deposit on top of the poles, so we decided on using a gripper and linear slides. We moved all the motors back to create space in the front for our linear slide and gripper. We also had to clear up any obstructions, such as beams, control hubs, our expansion hub and battery to make some more space. We attached the control hub, expansion hub, and battery to the back of the robot. We fixed inconsistencies in the frame, such as misalignment in beams, to improve the stability and quality of construction. Working on wire management was cumbersome, but necessary, so our robot would be able to get as many points as possible without getting tangled up in wires.



System for Intake

Because the highest beams are 30 inches, we designed a linear slide which can reach a maximum height of 30 inches. This means it will be able to score on all the poles: low, medium, or high. The linear slide was attached to the middle of the robot, in the space which was just cleared out. We also made a pair of tweezers which would help grab game elements from the top and latch on inside the game elements. These were then attached to an angle control servo, which would make it easier to grab the cones and also increase the reach height slightly.

Because we needed more accuracy, we used a flexible material to make a funnel to better intake our game elements. We had to fix and align the funnel a few times for greater efficiency. Next, we got to wiring up the motor for the actual lift. We realized that the linear slides stick out of the sizing cube by a 1/2 inch, but we purposefully ignored the problem because we'll have more time to get the technicalities correct by our first league meet.



Finally, we covered all the sharp corners of our robot with gaff tape and added the LED panels we're using for team markers.

First Implementation of Code

Our team has a lot of new coders this year, so we spent most of this time getting used to the interface and re-examining and interpreting code from past years which we could then use as a template. However, we got all the motors and servos to work, as well as coding the Mecanums to navigate the game field.

Meeting Log 9/24

By Aarav, Anuhya, Georgia, Gabriel, Trey, and Leo


1. Game strategy 2. Tombot as sparring partner. 3. Gripper Designs. 4. New recruit build teams.

Game Strategy



Iron Reign engaged in an exercise to better understand the game and create an optimal strategy when multiple robots are on the playing field. Two team members were blindfolded and acted as “robots,” while two others were the “driver” and voiced instructions. The blindfolded members followed their instructions and effectively played the game. This helped us better understand how the game evolved and the best ways to score points efficiently.

With the season coming up quickly and the first league meets scheduled for about a month away, we needed to prepare robots for competition and help the recruits begin.

Fixing up Tombot

One of the critical action points was fixing up Tombot, one of our older competition robots that utilized a linear-slide crane to score pieces at high altitudes. Tombot could potentially be used as a competition partner to simulate gameplay better and improve drive practice. However, TomBot had a couple of issues that needed to be resolved. Specifically, the Omni wheels at the ends of the chassis were getting caught in the junctions, so we raised them to allow for cleaner movement. We also fixed a loose chain that kept coming off and practiced driving around the poles and over the junctions.



New Recruits Progress

Next, the new recruits started working the chassis for their root, using a mecanum-based drivetrain and vs-shaped chassis. They also split into two teams and started building prototypes of their cone gripper. The first prototype(shown below) uses a conventional gripper that wraps around the cone from both sides and picks it up. Driven by a single servo, it uses two gears to move the two gripper parts.



The second prototype currently only has the two sides of the gripper, which use metal pieces and rubber bands to wrap around the cone. The new recruits also started working on the chassis for their robot, which uses the metal REV rails and a mecanum drivetrain. They were able to conceptualize it and started cutting the REV rails to the correct lengths for assembly.

Iron Reign Gripper

Iron Reign began modeling potential grippers for testing, including designs that packed up the cones from the top song with a few to grab the cones from the side. A greater variety of options will be helpful when creating the robot. In addition, work began on a cone-adjusting mechanism to right fallen cones and adjust the position of picked-up ones to score them properly.

Code Development

A few recruits interested in coding were taught the basics of programming the robots with Java, and our senior coders created basic mecanum and tank drive code for the teams to use. This should help us get a head start on coding and better help the rookie teams later in the season.

Next Steps

The next steps for the rookie teams would be to start building the chassis, attaching additional components, and continuing to develop their grippers. For Iron Reign, our next steps are continuing to design and prototype the gripper iterations and optimizing TomBot.

Overall Progress From the Past Two Weeks

By Anuhya, Georgia, Gabriel, Vance, and David


Tasks:
1. Working on path following with Code
2. Creating prototypes to optimize the Build design
3. Gaining experience with 3D Modeling using Fusion 360

Code



Our main coders, Vance and David, have continued working on reqriting the code base to make it easier to understand. We have many new recruits on our sister teams who are interested in learning how to code, so a lot of time has been spent on making the code base more user-friendly.

One major issue we were having is that there was a lag between operating the robot and the robot function. While scouring the code to find and address the problem, we noticed that there was a 1 second loop time. By eliminating this loop time, which may have initially been added to add a buffer period, our robot began to work much faster and was far easier for our drivers to operate. We also added custom PIDs for the turret and crane, giving us smoother movement with controlled speeds.

The coders are also working on using different methods of path folowing, such as straight orthogonal line following versus Pure Pursuit, to determine which would be the optimal method. Straight orthogonal line following would be far simpler to use and code and is already well aligned with the field set up and game design for Power Play, while Pure Pursuit is more often used in collegiate-level robotics and is a common path following algorithm. Once you get it right, it is very reliable and can be manipulated well.

We hope to get the path following and code base overall testable as soon as possible so we can work through specific motions and rotations as well as making it easier for our drivers to get in more practice before the first league meet.

Build



One of the major components of our robot is the extension of the arm, which enables us to reach even the tallest of poles with no difficulty. However, the set screws on the pulley system, which control the arm extension, were very loose, caused the axle to come off and render the whole arm useless. The first thing we did was tighten the set screws and work on many of the other regular repairs which were needed to keep the robot in optimal working condition.

Our robot uses a coiled extendable wire to operate the servo which controls our gripper system. However, due to the length of the wire, it got in the way of a lot of robot function and was just inconvenient overall to work around. We created a simple cardboard prototype to set our extendable wire so it wouldn't inhibit the rest of the robot and would allow all functions to occur freely.

So we would be able to automate the process of depositing cones, we installed a webcame which allows us to see how far the arm is extended.

Our gripper system needed a way to conveniently attach to the arm, so we had to create a component which would attach and align the gripper system properly. The gripper system has 4 main parts: a distance sensor, a servo, an expandable bulb and a cone guide. The component, appropriately named the Servo Clamp, was designed to be able to attach the bulb, servo, cone guide, and distance sensor separately while also aligning them so the robot would be able to use the sensor to detect the cone and pick it up using the bulb and cone guide.

Next Steps

There are always more improvements and more progress we can make in code, and we also need to make a separate intake system for the cones because it's more efficient and would allow us to score more points quickly. We also want to rebuild the robot piece by piece to make it more resilient and fix each individual aspect.

Meeting Log 10/22

By Georgia, Aarav, Gabriel, Leo, Trey, Anuhya, Aarav, and David


Task: Drive Practice and Getting Code to Work

Today was mainly focused on getting proper drive practice and getting the path following for the April Tags to go to the correct locations. As such, in between commits, our drivers Leo and Georgia were able to get some familiarity with the controls, while our coders Vance and David worked on PID tuning and autonomous corrections.



We ran a few practice matches of just teleop to measure and improve the skills of our drivers. This consisted of 2 practice matches each for both Leo and Georgia under the 2 minute timer. Leo scored 2 cones the first match and 3 cones the 2nd match, while Georgia scored 2 cones for both matches. This highlighted how little we had actually practiced driving the robot, but also sparked an idea in Vance and David.

Upon witnessing how slow going manually picking up a cone and scoring it on the tallest pylon was, the coders begun work on making preset values for picking up a cone and scoring it, implementing a memory element so that the robot would record where it picked up and scored a cone, and specifically return to those locations. In addition to working on the April Tag location to recognition, they also achieved being able to cut our scoring time basically in half, giving us more opportunities to score cones.

Next Steps

Creating a prototype LED battery holder for our panels and getting the April tag locations to work for both Autonomous points, as well as Tiebreaker points for the future.

Meeting Log 11/4

By Gabriel, Trey, and David


Task: Fixing Issues from the Screamage

After the Screamage, many different problems became apparent, including the fact that the robot just barely fit sizing requirements. In order to combat this, we decided to cut off .75 inches off the arm extension from the carbon fiber rod and added a new hole for the mount for the gripper system, which didn’t have an effect on the code or presets. Trey also continued to work on 3D modeling for the new robot.



David then proceeded to work on fine tuning for the presets for picking up and scoring a cone, as the movements were a bit aggressive to say the least, and by the end of the day, while slower, had become much more manageable as testing would prove to us. He also continued to work on the April Tag recognition for autonomous.

Next Steps

Make use of polycarb to create a new LED battery holder than can be mounted directly to the robot and fix the pulley system to keep it from falling off the axel and rendering our robot useless.

Meeting Log 11/5

By Gabriel, Trey, Vance, Leo, and Georgia


Task: Fixing Issues from the Screamage Pt.2

In tandem with yesterday, the main goal of this meeting was to improve upon the robot after the Screamage. This consisted of two main aspects, being a new way to mount the pulley because of the set screw of the motor that kept untightening from the axel and falling off at the most inopportune times, and a new battery holder for the LED panels with better mounting, as it was just wedged into the robot at the Screamage

Fixing the Pulley System

After many failures of the pulley system and antics with threadlocker and set screws, enough was enough. We decided that using the CNC to directly drill into the pulley to attach that directly to the motor was a better idea, and after a careful process, the pulley was directly mounted to the motor and thus far has experienced no further issues.



Making a New LED Battery Holder

The cardboard battery holder was an okay temporary solution, but in no way was meant to be a permanent addition to the robot. Instead, we opted to make a new one out of polycarb and create a place for the wire to filter through, which required measuring the battery and bending a piece of appropriately sized polycarb. It worked well, and looked semi decent but may be replaced in the future



Meeting Log 11/8

By Gabriel and Leo


Task: Preparing the Robot for the Upcoming League Meet

General Fixes:

The LED battery holder from the previous meeting snapped, requiring us to rebend and make a new gate for the LED Battery holder from scratch, which took a bit of time. In addition to this, all the set screws on the robot for the shaft collars and the pulley systems, as well as using threadlocker on the right motor mount in order to keep the right motor from shifting out of place and causing the chain to fall off the gear. This also solved the problem of the chain not fully aligning with the gear, causing a gradual stray of the straight pathing.

3D Modeling a New Wire Holder:

As discussed previously, the current iteration of the wire holder for the arm extension made of cardboard isn’t practical, and so Leo worked on a 3D model for the new version of the wire holder. This version addresses the wire getting caught upon on the corners of the holder as well as a more durable design as cardboard is not good at keeping it’s shape, and will more easily fit over the 2 motors.



Meeting Log 11/10

By Georgia, Gabriel, Leo, Vance, Trey, and David


Task: Finishing Code for Upcoming Meet and Drive Practice

We fixed the turret heading PID so that it does not spin uncontrollably when the angle changes from 359 to 0, and adjusted and tuned ticks per inch. We integrated memory of drop off and pickup positions with the crane so our drives don't have to spend a lot of time precisely aligning the arm with the cones and poles, enabling us to quickly score more cones per match. In addition, we created a basic auton program that reads the AprilTag on our custom team sleeve, then parks in the correct location accordingly.

The drivers practiced pick up and drop off using the new presets, then ran timed matches to see how many cones they could score, averaging 3-4 cones per match. We also practiced positioning and setting up the robot before beginning auton.

Next Steps

Due to oscillation of the arm after calibration, the camera occasionally cannot read the April Tag, so we need to fix this before the meet. Additionally, we need to do more drive practice before the meet this Saturday, inorder to improve the number of cones we score each match.

Meeting Log 11/11

By Gabriel, Vance, Aarav, David, and Georgia


Task: Finalizing the Robot the Day Before Competition

The day before a competition always sees arguably the most productivity from all the teams in a rush to finish up what they hope to accomplish the next day. For Reign, this was getting autonomous working, final drive practice for Georgia, and the printing of the team beacons.

Finishing Auton:

The first few hours were filled with commits from both David and Vance in an attempt to get the April Tags basically perfect. The camera was able to read the tags only some of the time due to the oscillation of the arm after calibration, which would be frequent at low voltage levels. Fortunately, this was solved and the rest of the night was spent on simplifying the calibration sequence and PID tuning for the arm.

Drive Practice:

A few practice matches were run which included both autonomous and TeleOp with a timer to see our limits. The average performance saw autonomous working and around 3-4 cones scored, but some outliers saw no autonomous points and no cones scored, which was certainly worrying. In the end, further drive practice was sacrificed in order to get the autonomous code working.

Making and Dying the Beacons:

The final thing we finished that night was the beacons for additional scoring. This was modeled as a loose sleeve that fit around the cone initially, but then we cut around it and made just a tab protruding from the base in order to meet sizing requirements, as well as dying them red and blue respectively and writing the team number on them.



1st League Meet - Post Mortem

By Georgia, Aarav, Gabriel, Leo, Trey, Vance, and David


Tasks:
1. Review 1st League Meet
2. Analyze 1st League Meet Performance
3. Discuss Possible Fixes + Next Steps

Play By Play

1st Match - The first round went horribly wrong, as Gabriel touched the phone after randomization, netting a minor penalty. While autonomous did read the April Tags, the arm was outside the tile, so regardless we didn’t score the 20 points for autonomous. In an attempt to get the robot started and not have to do calibration, the sequence was skipped which caused the turntable and arm extension to fail completely. Our score was 2 points scored by our alliance partner, and was a loss.

2nd Match - The 2nd this time, the autonomous program worked, but yet again the arm was outside the confines of the tile, meaning no autonomous points. The new calibration sequence, which required a button press, was not completed, and so yet again, failure in the arm and turntable, and an additional crash of the robot. The score was 37 points scored by our alliance partner and a loss.

3rd Match - The 3rd match autonomous finally worked, netting us 20 points. The presets for cones, however, was not working and so had to be done manually. The score at the end was 38 points and resulted in a win.

4th Match - The 4th match autonomous succeeded yet again, gaining 20 points. Unfortunately, the calibration sequence again wasn’t completed, meaning we couldn’t score any elements. The match resulted in a 34 point win, a win that was barely gained, as we scored 1 more point than the opposing alliance.

5th Match - The 5th match was by far our best performance. The April Tag recognition worked again, netting us 20 points. The presets for cone scoring finally worked, and with it, our driver Leo was able to score 9 cones, one of which had a beacon on it, getting our alliance 93 points, the record for that meet, of which we scored 74 points.

What Went Wrong + How To Fix It

This past Saturday marked the first League Tournament for the University League and our first competition. Unfortunately for us, it did not go as we had hoped, but was instead more grounded in reality. There were a lot of problems that only reared their heads during the competition.

The beginning of the competition was the most problem intensive, with everything from the calibration sequence infinitely rotating the turntable, the belt slipping off the arm extension, and the presets for cone scoring going awry. Luckily for us, the end of the competition resulted in a fix to some of these issues which lead to us placing in 4th ranking wise, and getting the high score for point total in conjunction with our alliance partner. However, this does not mean that there were no persisting problems after the fact.

Starting off with build issues, our mount for the current iteration of our bulb gripper was able to shift slightly to both the left and right with enough force applied. The constant smacking down of the gripper onto cones was a likely culprit in the shift meaning its an issue that has to be further addressed by tightening the carbon fiber bar more. The belt for the arm also managed to slip off at one point, but luckily it was in between matches. It serves as a good reminder to replace old rubber bands, which do not age well at all. The robot was also getting caught on the pylons, even when they didn’t have cones on them, meaning that its a combination of the chassis being a bit too big even though it fits standard sizing and more drive practice needed. Also, while it didn’t present too big of an issue at the competition, our current wire holder for the arm extension is just impractical and arguably cardboard should never appear on a robot at a competition.

Moving onto code issues, the start of the competition began with a big scare. During the calibration sequence, the turntable would rotate uncontrollably and would persist through infinite rotations. Fortunately, Vance and David were able to address this before any of the matches actually started. The issue of presets also became apparent because of calibration. Once autonomous finished, the Teleop program had to be initialized and recalibrate itself, which for one reason or another, completely messed up the presets, which are designed to remember the locations that it picked up a cone, and where it dropped off a cone.

Next Steps

Our robot needs to be thinner in order to navigate this year’s field more effectively, which is currently being addressed with the modeling and future construction of basically a version 2 of our current robot. The cardboard wire holder is going to be replaced with a 3D modeled version, which hopefully will look sleeker and serve its function better than the current iteration. There is also the idea of custom wheels as last year set a standard that we should keep alive.

Meeting Log 11/18

By Gabriel, Trey, and Vance


Tasks:
1. Fix Issues from the Last Meet
2. Build Upon our Current Strategy
2. Continue to Develop TauBot 2.0

The League Meet was a rude awakening for all the things we needed to improve upon and start. This includes a better autonomous, as other leagues are already having regular 30-40 point autonomous programs, documentation as even though League Meets don’t require them, the Tournament is slowly encroaching on us, and it needs to be solid by then and the modeling of a version 2.0 for the current robot to further improve cone scoring.

Building Upon our Current Strategy

In order to be a competitive team, we need a stronger autonomous. The current strategy for this is just the April Tags, which nets us 20 points. However, since April Tags still leaves around 14 seconds of autonomous to be filled, Vance has been working on a pre-load cycle, which would read the April Tag with the preload, drive to the destination, score the preload on the tallest pylon, and then continue to take from the cone stack and continue to score, which could easily elevate us to a 30-40 point autonomous run. We also need to start thinking about capturing more pylons, as this early in the season it’s been noted that each team generally stays to their quarter of the field. In order to capitalize on this, we plan to change our strategy to capture all the pylons within our quarter of the field, as each junction/pylon captured is an additional 3 points, which would then be followed by scoring on the tallest pylon.

Version 2.0 of TauBot

Currently, there is a second version of Taubot being 3D modeled in order to accommodate a smaller sizing as well as a separate intake system. More details about this will be discussed in a future blog post.

Next Steps

Continue to build upon the autonomous program and learn a new drive strategy for the League Meet on December 3rd.

Meeting Log 11/19

By Georgia, Aarav, Gabriel, Trey, Leo, and Vance


Task: Drive Practice and Improving Code



Today, we spent time improving upon the code by fixing the odometry and fine tuning it, along with doing some much needed drive practice.

We fine tuned the PID and speed, as well as the pickup and drop speed and staging. We also fixed the odometry, which calculates the position of the robot based on how many times the wheels have turned. We changed the staging of the crane memory system to be more accurate and fix the angle of the shoulder before it extends, so it won't hit the poles or cone stacks when changing position.

Our drive team ran practice matches to improve precision and accuracy while also scoring as many cones as possible. We focused on picking up cones from a long distance, utilizing our crane's reach and scoring from afar. The arm tended to overshoot when fully extended, making it more difficult to score, so our drivers had to practice taking this into account when aligning the crane and turret with the cone and poles for pickup and scoring.

Next Steps

We need to finish our auton code so the robot will pickup and score cones from the cone stacks and drop them onto poles during the auton period. We also want to finish and tune code for grid drive. And, of course, more drive practice!

Code Progess for November

By Vance and David


April Tags



This year, using FTC 6547's tutorial on april tags, we developed a system to detect which parking location we should park in. The april tag system allows the onboard camera to detect the sleeve at a distance without it being directly in front of the camera unlike other systems. It also requires much less processing than QR codes which allow it to detect the sleeve faster and with greater accuracy.

Crane Memory System

One unique feature of this robot is the crane's memory system. The crane remembers its position where it picks up a cone and where it drops the cone. This memory allows the crane to take over positioning the gripper for picking up a cone and dropping it off. The driver now only has to finetune the pickup and drop position and initiate the pickup and drop sequence.

Grid Drive

One helpful feature that would make the robot more reliable is grid drive. Since the field this year has all the objects placed in a grid, the robot can navigate between the pylons relatively easily however we found that drivers could not be as precise driving than the robot’s odometry and as such we developed a system where the driver tells the robot where they want the robot to go and the robot creates and follows a path to get to its target location. This system decreases transit time significantly and makes driving more precise. This system can also be used with the crane to pick up cones from a specific location and drop them at a certain pylon of the driver's choosing.

Field Class



We've also developed a special class to keep track of the current state of the field. The Field class keeps track of all objects on the field and their location, height, and name by creating a separate fieldObject object for each. These objects are then stored in a list and that list can be sorted through to find for example the closest object to the robot of a specific height. The robot using grid drive can then drive to a location where it can then score on that object.

Meeting Log 11/26

By Georgia, Gabriel, and Leo


Task: Build, Modeling, and Drive Practice for Upcoming League Meet

We spent today's meeting fixing minor build problems, then ran timed practice matches. Additionally, we started modeling the prototype for the nudge stick.



We began designing a prototype for a nudge stick, which will help speed up cone drop off. The stick will touch the pole at one point of contact and will be able to move to either side, depending on which direction we are scoring from.

The arm and mount, specifically the set screws and shaft collars, will often become loose, so we used threadlocker to secure these and reduce its chances of becoming too loose during a match. We redid the connection for the LEDs because a wire had snapped out, then rewelded the mount for the LED panels, as it was beginning to split down the center and was revealing the inside of the panel.

We did lots of drive practice, running many timed practice matches. We managed to score the auton preload, along with about 3-6 additional cones and beacon. Unfortunately, auton was somewhat unreliable, as Taubot did not always score the preload cone on the pole and fully park in the correct space.

Next Steps

Our next step is to fix our auton code so Taubot consistently manages to score the auton preload cone and fully park in the correct spot. We also need to finish the nudge stick prototype so we can begin testing and finetuneing it.

Meeting Log 11/29

By Georgia, Anuhya, Gabriel, and Vance


Task: Code and Build Before League Meet

We partially remade the joint that connects the extension part of the crane to the turret, as we found that under high stress the gears were prone to slipping. We also changed the gear ratios on the shoulder to increase the torque produced at the cost of the speed of the crane. We did this because under most situations we were hitting the torque limit of the motor but we almost never hit the speed limit of the motor. This will make the crane much more controllable, especially when the crane is at maximum extension. Additionally, we began building the nudge stick for the crane.

As for code, we created two new methods. The first method takes in the robot's current position on the field and, using an IMU that is attached to the turret, calculates the position of the center of the turret. This is method is needed for inverse kinematics to work because the center of the robot is not aligned with the center of the turret. The second method takes in the desired X, Y, and Z coordinates that the turret should target. It first takes the turrets's position then uses that position to calculate the heading that the base needs to target inorder to align itself with the proper X and Y coordinates. It then calculates the horizontal distance needed to get to the target position. That distance, along with the Z target height, is then used to calculate the angle and amount of crane crane extension required to achieve the target position.



We began working on a model for the differential distance sensor mount, with the distance sensors mounted on the side pieces so we can adjust their angle inorder to pinpoint where the cone is located. We added a space in the middle for a laser, which we will use for testing the range of the distance sensor.

Next Steps

We need to finish building and coding the nudge stick so we can test it and practive scoring with it. As for the differential distance sensor mount, we need to finish modeling it and then build and test it.

Meeting Log 12/02

By Georgia, Anuhya, Gabriel, Leo, and Vance


Task: Prepare for Our Second League Meet

Today we worked on finishing the nudge stick and auton code, along with doing driver practice and other preparations for the upcoming meet.

We finished working on code for the nudge stick so it will rotate to the left or right of the pole in order to help the driver align the cone with the pole more easily and quickly. The stick is mounted to a servo which allows it to move to either side of the arm. Next we worked on code for auton and tuned it to be more reliable.

Our drivers spent lots of time practicing seting up the robot and diving it. We scored about 4 or 5 cones per match plus auton and a beacon.

Meeting Log 12/06

By Georgia, Anuhya, Leo, Vance, and Gabriel


Task: Improving code



Today we tuned auton, implemented inverse kinematics, and made driver controls more user friendly.

We implemented inverse kinematics with driver controls, auton, and the memory system. ​​We changed the driver controls to use height and distance rather than angle and shoulder. This makes it faster and much easier for the drivers to fine tune adjustments when dropping and picking up the cones. We also implemented this system in auton to make it easier to specify a target that the robot should aim for during auton.

Next Steps

Now that we have inverse kinematics working we can begin a scoring pattern code, which will allow the robot to memorize the field and move to score without driver input. This will make scoring quicker and easier for the drivers.

Townview Tournament

By Gabriel, Georgia, Anuhya, Trey, and Leo


Hosting the Townview Tournament



This Saturday marked the First Tournament of the season, and with it came the opportunity for us to host the event at our homeschool, Townview. Twenty seven teams showed up for the tournament, all displaying great levels of gracious professionalism and a wonderful sense of sportsmanship for the whole tournament.

What we learned

This was a great opportunity for us to learn how judging would work this year and truly see how a tournament would function ahead of time. It also gave us a chance to see some of the more than impressive robots and their unique designs and innovations, as well as some potential new strategies to test out for ourselves.

Overall, we had a great time hosting this event in collaboration with a lot of First representatives and alumni and we're very thankful to all the teams, volunteers, and judges that showed up and for having a great competition. We wish the teams good luck for the rest of the season!

Virtual DPRG Meeting 12/17

By Aarav, Anuhya, Georgia, Gabriel, Trey, Vance, and Leo


Task: Present TauBot to the Dallas Personal Robotics Group

Today, we virtually presented our robot to the Dallas Personal Robotics Group(DPRG) to showcase our progress for this season and hopefully get advice on our robot's design, code, and presentation. DPRG is a group of engineers and robot enthusiasts who meet multiple times a month to discuss robotics and share their personal projects in the field of robotics. These meetings allowed us to practice our presentation skills and receive valuable advice from mentors and professionals.

The meeting started with us briefly explaining Power Play to the members who tuned in and then transitioned into our initial Ri2D efforts and how that influenced our current design. We shared our initial idea of creating a "tall bot" that could drive over the poles and how that quickly shifted into the current robot focused on minimizing movement across the field.

We went over the critical subsystems of our robot, which included the bulb gripper, arm, turret, and chassis, and explained how all of these worked together to accomplish our game strategy. Then we transitioned into the code aspects of things and shared how we managed to automate much of the gameplay with our memory functions, inverse kinematics, and anti-tipping code while also stating how we planned to integrate OpenCV and grid drive in the future.

After that, we discussed our plans for the future iteration of TauBot and some of the significant changes we planned to make to the chassis to improve its efficiency and ability to score points. Finally, we presented a show demonstration of the robot driving around, scoring cones, and running the auton code. A lengthy question and answer session ensued, and we got lots of valuable feedback from the DPRG members that we will use to improve both TauBot 2.0 and our presentation.

Regarding the feedback we received on the robot, DPRG suggested that we consider the distribution of mass and a potential counterweight to prevent tipping(which happened a decent amount during the demo), as well as possible code changes to help better control the autonomous path of the arm during movements. They also pointed out the oscillation of our gripper and suggested we add a degree of freedom to prevent that. Finally, one of the biggest pieces of advice they gave was to consider utilizing a movement system that allowed us to “fly the gripper.”

On the presentation side of things, the main advice given was to consolidate our information, focus on the most impressive parts of our robot, talk slower, and create a correlation between our strategy and the implementation of our robot.

Next Steps

We are incredibly grateful to DPRG for letting us present and connect with professionals to improve our robot. We hope to meet with them in the future, possibly in January, as we develop our robot. Our next steps are considering their advice when designing and assembling TauBot 2.0, further automating our robot, and preparing our presentation and portfolio for the tournament in January.

Meeting Log 12/30

By Georgia, Leo, and Gabriel


Task: Driver Practice!

Recently, Vance implemented a new control scheme : scoring patterns. This required some changes to the way the cone is “transported” throughout the field when the driver operated, and we found it was best to “fly the gripper” by controlling the 3 dimensional position of the cone on a cartesian space superimposed on the field. Basically, we control the x,y,z, which is a big change compared to the old controls, which controlled extension, turret angle and shoulder angle independently of each other. We're down to 3 weeks from our next meet and the goal is to get affluent with these new controls, which will (hopefully) help us score more cones.

Next Steps

There's still some fine tuning to be done with the controls, especially at long distances. The robot is still prone to tipping and crashing, but as a proof of concept, scoring patterns are looking promising. There was also some progress done on the CAD for the new robot (epic reveal coming soon), and we're looking to start manufacturing some of our designs on the CNC in the coming week, stay tuned.

Meeting Log 01/04

By Georgia, Anuhya, and Leo


Task: Build and CAD

Today we focused on building and modeling our second iteration of Toubot. After designing and cutting out the parts for the underarm on the CNC we began assembly.

As for modeling, we worked on the shoulder drive for Toubot2. We are redesigning our motor mounts because we need the extension on the arm to be stronger. We are changing the design for the shoulder drive by using 8 mm axles and using four 30 tooth gears instead of the single 30 tooth gear currently being used. We are also using “bridges” to mount our motors, because they are stronger than the standard REV rails.

Next Steps

Our next steps are to print the motor mounts and continue build. And more drive practice!

Meeting Log 1/6

By Aarav, Anuhya, and Georgia


Task: Documentation and CAD

Today,we focused mainly on documentation and the continued CAD for the next iteration of TauBot. We worked on the outreach and Motivate sections of the Engineering Portfolio along with a few of the preliminary slides. Furthermore, we also made sure that the blog was all up to date.

On the CAD side of things, we finished the shoulder drive on the CAD model and began 3-D printing a few motor mounts for the next iteration of TauBot.

Next Steps

Our next steps are to continue finishing the CAD model of TauBot2, continuing to assemble the parts we have completed, and to continue working on the Engineering Portfolio in preparation for the Tournament on January 28th.

Presenting to DPRG

By Anuhya, Trey, Leo, Gabriel, and Vance


Task: Present a status update to Dallas Personal Robotics Group



You can watch our full presentation here. Today was our second meeting with Dallas Personal Robotics Group , or DPRG, this season. We updated the engineers at DPRG with our build and code progress. First, we ran through our newly assembled parts and subsystems. Then we showed our work in progress CAD in Autodesk Fusion 360 directly, and our main coder ran through our code. Finally, we had time for a small Q&A session with the engineers, where they asked us questions about our robot design and how it would achieve the goal put forth by the playing field.

Build

Newly Assembled Parts and Subsystems

We had 3 main things to discuss when it came to newly assembled parts and subsystems: the new wheels and the underarm/chariot, which included the lasso gripper. Gabriel introduced the new wheels, which are made out of carbon fiber, nylon and ninjaflex. We also demoed the new wheels, which had just been attached to an axle. Because the bearings weren't aligned properly, the wheel was slightly wobbly. However, it was a good demonstration of how the wheel would work when it would be attached to the second iteration of our robot, Taubot. We changed to a custom wheel because it would give us more control and would also be slightly smaller than the old wheels, allowing us to optimize the design.



Leo, who was the main designer behind all aspects of the underarm/chariot, was responsible for introducing it to the judges. Our underarm is designed to slot into the front of the robot, replacing the omni wheels with driven omnis which drive out the chariot. Our underarm is entirely made out of custom carbon fiber parts, and will be the intake system for Taubot: 2nd iteration. The chariot drives out, using the driven omnis, to the cone stacks and the substation. The underarm uses the lasso gripper to grip around a cone and passes through itself to hand the cone off to the main arm.



New CAD For Future Assembly

After displaying the custom parts of the robot which we had already assembled, we showed the parts of the modeling which were still in progress. I started by introducing the shoulder and turret assembly, which was still very much not completed. I talked about motor placement and gear alignment, and why we changed the design of the shoulder and turret. We wanted to stop using the standard REV rails and replace them with aluminum plates, which would be stronger and designed specifically for our purposes.

Trey showed the changes we would be implementing with the arm. We changed the linear slides to a lighter model so it would be possible for us to add a 4th stage. This would make it possible for the robot to move minimally and still reach the entire span of the field. We are using a belt system and a motor at the base of the arm to extend the arm. Trey then showed the base and the chassis of the robot. He talked about how we changed the design, and how we would be using carbon fiber for the base as opposed to polycarbonate, because of how much stronger carbon fiber is and because of the issues we were having due to the polycarbonate cracking when it hit the walls of the playing field.

Leo showed the model of the underarm and the chariot so the engineers could get a better understanding of how it would extend and operate. He also talked about how the battery would be in the moving section so we could counteract the tipping problem due to the weight of the arm.

We also touched on our manufacturing process, and how we turned modeled parts into physical parts which would be used on our robot.

Code

Vance took the lead on showing what he'd been working on with code. The auton wasn't fully tuned up so everything was slightly off. In an ideal autonomous game, we would have gotten around 3 cones. Currently, reliability is a bit of an issue because of cone placement, because cones are very close to the wall. This makes the margin of error we have very little. The robot tipped over while we were trying to demonstrate autonomous, but it was an easy fix, along with a reset.

Scoring Patterns

The first thing Vance demonstrated was the scoring patterns. They were a very new addition, and they were good for drivers because it meant the drivers would only have to make a few micro adjustments to the arm placement instead of moving the arm the whole way around the game field.

What is a scoring pattern?
A scoring pattern is an array of field positions that the arm targets.

1. The arm goes to a substation.
2. The arm automatically goes to a different pole every time a new cone is picked up.


The arm gets pretty close, but the driver has to line it up perfectly manually themselves. The reason we go to a different pole every time a new cone is picked up is because that gets us a lot of poles, which results in possible points for controlling poles. Each cone which is controlled is 3 extra points. This is very helpful strategically. There are 8 scoring patterns, because there are 2 cone sources. The driver can swap between any of the scoring patterns mid-match.

While we were demonstrating scoring patterns, a pulley on the robot fell off. This took a while to fix, but the show must go on!

Feedforward for PID

The PID brings the shoulder to the correct angle at the correct speed and time. Our robot now uses feed forward, which calculates how much torque is on the arm and how much torque is needed for the motor to hold position or counteract the torque of the arm/gravity. This is entirely based on the current angle and position. If we fully extend the arm using PID but not feed forward, the arm would always slip down slightly. However, now the arm holds position, even when it's fully extended.

Q&A

The last portion of our meeting with DPRG was the Question and Answer session. The engineers asked us questions about our design and the game itself.

Q. Why do you score during autonomous?
A. We get double the points for every cone we score in autonomous, because it counts during both autonomous as well as driver control. We also get 20 additional points for parking the robot, which is quite reliable.

Q. How many of you design the robot?
A. There are 7 total people on the team. 3 of us model, and we mainly communicate through Discord and TickTick to divide the work. We also have design meetings to find mistakes in our models and discuss what needs to be fixed. Subsystems and different assemblies are organized into folders, and we each take responsibility for one main part. To sum it up, it's organized chaos.

Q. What is the scoring estimate/target with the new pattern?
A. We don't have one with the current pattern, because we don't have any testing. We got 8 - 9 cones with the old pattern.

League Meet #3 Review

By Aarav, Anuhya, Gabriel, Leo, Vance, Trey, and Georgia


Task: Review our performance at the 3rd League Meet and discuss possible next steps



Today, Iron Reign and our two sister teams participated in the 3rd League Meet for the U League at UME Preparatory for qualification going into the Tournament next week. Overall, we did solid, going 4-2 at the meet; however, we lost significant tiebreaker points in autonomous points due to overall unreliability. At the end of the day, we didn’t do as great as we would have liked, but we did end the meet ranked #2 in the U League in #5 between both the D and U Leagues, and got some valuable driver practice and code development along the way.

We entered the meet with brand new autonomous code that allowed us to ideally score three cones in autonomous and park, equating to about 35 points.

Another main issue that plagued us was tipping, as our robot tipped over in practice and in an actual match due to the extension of the arm and constant erratic movement, which we will elaborate on in the play-by-play section.

We also want to preface that much of our code and drive teams were running on meager amounts of sleep due to late nights working on TauBot2, so a lot of the autonomous code and river error can be attributed to fatigue caused by sleep deprivation. Part of our takeaways from this meet is to avoid late nights as much as possible, stick to a timeline, and get the work done beforehand.

Play by Play

Match 1: 46 to 9 Win

In the autonomous section, our robot missed the initial preload cone and fell short of grabbing cones from the cone stack because there was an extra cone. Finally, our robot overshot the zone and got no parking points. Overall, we scored 0 points. In the tele-op and endgame sections, because of a poor quality battery that was overcharged at around 13.9 volts, our entire shoulder and arm stopped functioning and just stood stationary for the whole period. In the end, we only scored 2 points by parking in the corner. However, due to the extra cone on the cone stack at the beginning of autonomous, we were granted a rematch. In the autonomous of the rematch, our preload cone dropped to the side of the tall pole, but we could grab and score one cone on the tall pole, missing the second one. However, it did not fully move into Zone 3, meaning we didn’t get any parking points. Overall, 5 points in auton. In the tele-op and endgame, we scored two cones on the tall poles and one on a medium pole, which equates to 20 points in that section, including six ownership points. Total Points: 29

Analysis: We need to ensure that our battery does not have too high of a voltage because that causes severe performance impacts. More autonomous tuning is also required to score both cones and properly park. Our light battery also died in the middle of the second match due to low charge, which will need to be taken care of in the future since that can lead to major penalties.



Match 2: 68 to 63 Loss

In the autonomous section, our robot performed great and went according to plan, scoring the preload cone and 2 more on the tallest cone and parking, equating to 35 points. However, in the tele-op and endgame, the robot’s issues reared their ugly heads. We did score one cone on a tall cone and one on a medium cone. However, after our opponent took ownership of one of our tall poles, we went for another pole instead of taking it back, and that led to us tipping over as the arm extended, which ended the game for us. We did not incur any penalties but had we scored that cone and taken back our pole, we would have won and gotten to add a perfect autonomous to our tiebreaker points. We ended up scoring 9 points in this section. Total Points: 44

Analysis: Excellent autonomous performance marred by a tipping issue and sub-par driver performance. The anti-tipping code did not work as intended, and that issue will need to be fixed to allow TauBot to score at its entire range.



Match 3: 78 to 31 Win

In the autonomous section, we missed the preload cone and couldn’t grab both the cones on the stack, and we also did not park as our arm and shoulder crossed the border. As a result, we scored 0 points total in this section. In the tele-op and endgame section, we scored a lot better, scoring two cones on the tall poles, one on the medium poles, and two on the short ones. This, including our 15 ownership points, equates to a total of 35 points. Total Points: 35

Analysis: The autonomous does need tuning to at least park because of the value of autonomous points. Our lack of driver practice is also slightly evident in the time it takes to pick up new cones, but that can be solved through increased gameplay.

Match 4: 40 to 32 Win

In the autonomous section, we scored our preload cone on a tall pole, but intense arm oscillation meant we missed the first cone from the stack on drop-off and the second cone from the stack on pickup. We also overshot parking again, bringing our total in this period to 5 points. In the tele-op and endgame section, we scored two cones on the tall poles. So with ownership points, our total in this section was 16 points. We did miss one cone drop-off, though, and our pickups in the substation could have been better as we tipped over a couple of cones during pickup. Total Points: 21

Analysis: Parking still needed to be tuned, but the cone scoring was a lot more consistent, but still requires a bit more work to achieve consistency. Other than that, improved driver practice will help cycle times and scoring.

Match 5: 51 to 24 Win

In the autonomous section, our arm never engaged to go and score our preload, and the robot did park, meaning we scored 20 points in this section. In the tele-op and endgame section, we scored two cones on the tall poles, one cone on the medium poles, and missed three on drop-off. We also scored our beacon, bringing our total point count in this game portion to 30 points. Total Points: 50

Analysis: Pretty solid match, but the autonomous still needs tuning, and driver practice on cone drop-offs could be better.

Match 6: 74 to 50 Loss

In the autonomous section, our robot missed the drop off of 2 cones but parked, bringing the total to 20 points for autonomous. In the tele-op and endgame section, miscommunication with our alliance partner led to them knocking our cones out of the substation and blocking our intake path multiple times. We scored three cones on the tall poles and missed two on drop-off. In the end, we scored the beacon, scoring 30 points in this section. Total Points: 50(we carried)

Analysis: Communication with our alliance partner was a significant issue in this match. Our alliance partner crossed onto our side and occupied the substation for a while, blocking our human player from placing down cones and blocking our intake path. This led to valuable seconds being wasted.

Overall, our main issues revolved around autonomous code tuning; although our autonomous performance did improve, poor driver practice we chalk up to fatigue, along with minor tipping and communication issues. However, we plan to understand what happened and solve our problems before the next week’s Tournament.

Then, for a quick update on TauBot2, parts of the manufacturing and build have begun, and we hope to incorporate at least part of the new design into the robot we bring to the Tournament on the 28th. Currently, parts of the Chassis and UnderArm have been CNC’ed or 3D printed, and assembly has begun.



Next Steps

Finish up the design of Tau2 and start manufacturing and assembling it, tuning our autonomous and anti-tipping code, and attempting to get more driver practice in preparation for next week’s Tournament.

Overview of the past 3 weeks

By Anuhya, Aarav, Leo, Vance, Trey, Gabriel, and Georgia


Task: Recount the developments made to the robot in the past 3 weeks



The past three weeks have been incredibly eventful, as we try to beat the clock and finish TaBbot: V2. We had a lot of work to do in build and code, since we were putting together an entirely new robot, coding it, and getting it competition-ready for the D&U league tournament on 01/28/2023.

Build:

We were making many changes to the design of our robot between TauBot: V1 and TauBot: V2. We had a lot of build and assembly to do, including putting the rest of the UnderArm together, adding it to the robot, CNCing many of the carbon fiber and aluminum components and assembling the new tires. Our 3D printer and CNC were running constantly over the span of the past 3 weeks. We also had to make sure the current iteration of the robot was working properly, so we could perform well at our final league meet and cement our league ranking going into the tournament.

Leo focused on assembling the UnderArm and attaching it to the robot. The UnderArm was fully designed, CAMed and milled prior to the tournament, but we didn’t get the chance to add it to the robot or test the code. We were still having a problem with the robot tipping over when the Crane was fully extended, so we decided to attach the omni wheels and “chariot” for the UnderArm to the robot, to counterbalance the Crane when it was fully extended. We experimented with it, and this almost completely eradicated our tipping problem. However, while testing it separately from the robot, we got an idea for how the UnderArm would work with the Crane, and how we should begin synchronizing it.



Because the majority of the new iteration of Taubot is entirely custom parts, designing the robot was all we had the chance to do prior to the tournament. However, we managed to get the basic chassis milled with carbon fiber and a sheet of very thin polycarbonate. We also began assembling parts of the new Shoulder and Turret assembly, but decided to not rush it and use the old assembly with the new chassis of Taubot: V2.



Before the tournament though, we incorporated the new UnderArm assembly, carbon fiber chassis, and newly-printed TPU wheels with the Shoulder, Turret, and Crane from TauBot in preparation for the upcoming tournament.

Code:

On the code side of things, we mainly worked on fine tuning the code for the scoring patterns and feedforward PID. Most new things which we will be adding to our code will be done after we have completely attached the UnderArm to the main body of Taubot: V2, because that is when synchronization will occur.

Vance updated auton so it would calculate how many points were feasible and go for the highest scoring option after 25 seconds. He also sped up auton, so it wouldn’t take as long to get a cone and score it. The preloaded cone was scored consistently, but grabbing new cones from the conestacks and scoring them was still unreliable.

When he wasn’t making auton more stable and reliable and working through the scoring patterns, Vance was working on coding the parts of UnderArm which would be independent of the rest of the robot. He added a simulation so it would be possible to test UnderArm off the robot, and changed UnderArm servo calibration. Limits were also added to UnderArm so it wouldn’t continuously loop through itself.



Next Steps:

We need to perform well at the Tournament to ensure our advancement. If all goes well there, the next steps would be a Post-Mortem and the continued development of TauBot2 and the portfolio in preparation for either a Semi-Regional or Regionals.

D&U Tournament Play by Play

By Aarav, Anuhya, Gabriel, Leo, Vance, and Trey


Task: Narrate the events of the D&U Tournament



Today, Iron Reign and our two sister teams competed in the D&U League Tournament at Woodrow Wilson High School, the culmination of the previous three qualifiers. Overall, we did pretty well, winning both Inspire 1 and Think 2, which means we will be directly advancing to the Regional competition in about a month. There will be a separate blog post about the tournament Post-Mortem, and this post will cover the play-by-play of the matches.

The robot we brought to the tournament was a mix between TauBot V1 and V2, with the V2’s Chassis and UnderArm and the V1’s Turret, Shoulder, and Crane. Unfortunately, there were some robot performance drop-offs, as we slipped from 5th to 9th in the qualification standings, going 2-4 overall at the tournament.

Play by Play

Match 1: 84 to 17 Win

In autonomous, due to arm wobble, we missed both the preload cone on drop-off and the cone on the stack during pickup. However, the robot was still about to get parking. Then in the tele-op and endgame, our robot scored three cones on the tall pole and one cone on the medium cone. However, rushing during cone drop-offs led to us missing a couple, and a decent amount of time was wasted during intake and arm movements. Finally, we also scored a beacon. Overall, this was a solid match, but there could be improvements. One important thing to note was that the UnderArm almost went into the substation while the human player was inside due to an issue with the distance sensor that regulated chassis length. This is something that we will have to diagnose and fix quickly.

Match 2: 86 to 48 Loss

In the autonomous section, our robot almost collided with an opposing robot when attempting to score the preload cone. In the end, we did not score any cones and lost parking when the UnderArm did not fully retract and traveled past the edge of the area. In the tele-op and endgame, our robot scored two cones on the tall poles and one on a medium cone. However, poor gripper positioning on intake led to time-wasting as cones kept getting tipped over, and we missed a low cone on drop-off due to rushing. In addition, the LED battery went out during the match, which could have caused a penalty and is starting to become a recurring issue. Finally, we lost due to the 40 penalty points that we conceded by pointing at the field during gameplay four times, which was a major mistake and should serve as a valuable lesson for the drive team. Overall, this match was messy and a poor showing from both our drive team and robot.

Match 3: 74 to 33 Loss

This match did not count toward our ranking since we were filling in. Regardless, we didn’t view this as a throwaway game. In autonomous, the robot got off track when driving toward the tall pole to drop off the preload, meaning the entire autonomous section got thrown off. We didn’t score any points or park at all. Then, in the tele-op and endgame section, a major code malfunction threw off the arm for a while. We missed multiple cone intakes by overshooting the distance, and the arm was frequently caught on the poles. Our human play was also quite sloppy and there were a few times we got close to being called for a penalty for the human player being in the substation at the same time as the robot. In the end, we only scored 1 cone on a tall pole in this section, and luckily this game did not count towards qualification rankings, but it did reveal a code issue that we quickly corrected.

Match 4: 97 to 18 Loss

In autonomous, our robot got bumped, missed both cones, and did not park because the arm and shoulder ended up outside the zone. Then, in the tele-op period, quickly into the start of the driver-controlled proportion, the servo wire on our bulb gripper got caught on our alliance partner’s robot. This caused the plate on which the arm was mounted to bend severely and left us out of operation for the rest of the match. Immediately after, we had to switch to the arm and gripper for TauBot2 that we had assembled but not yet attached, and this required slight modifications to the shoulder to allow all the screw holes to align. Thankfully we were able to get it working, but we faced issues later on with the movement of the new gripper limiting our cone intake.

Match 5: 144 to 74 Loss

In autonomous, the arm wobble caused our preload to drop short, but we parked. We also accidentally “stabbed” our opponent’s preload cone out of their gripper when they were about to score it. Since this was in autonomous, we were not penalized, but it was quite funny. However, in tele-op and endgame, we missed multiple cone pickups and drop-offs and went for the cone stack instead for intaking at the substation, which was a major tactical blunder and increased our cycle times. We did score two cones on the tall poles and one cone on a small pole that allowed us to break our opponent’s circuit at the very end, but we still lost. Overall not a bad game, but we had a questionable strategy, and the pains of a newly assembled robot did show.

Match 6: 74 to 66 Win

This match was a great way to end the qualification matches, as we escaped with a narrow and intense win. Because our left-side start code was broken and our alliance partner heavily preferred standing on the right side, we started our robot on the right and stood on the left, which was quite a novel strategy. It did come with drawbacks, as during the start of tele-op, we wasted valuable seconds crossing the field with our robot. Anyways, in autonomous, major arm wobble led to us missing the preload by a mile, the stack intake code was off, and we did not park. Tele-op and endgame were quite an intense competition, and we scored three cones on the tall poles, including a clutch beacon cone in the last 10 seconds of endgame to win the game. Overall this was a great game, although we still had autonomous issues, and it was a good ending to an overall poor run in qualifications.

We ended the qualification portion with an overall standing of 9 and a record of 12-3. Thanks to good connections with our fellow teams, we were picked by the 3rd-ranked alliance as their 3rd pick. Therefore, we did not play the 1st match of the semifinal, which we lost, but we did play the 2nd match.



Semifinal 2 Match 2: 131 to 38 Loss

In autonomous, the arm wobble led to us missing the preload and the cones from the stack, and we did not park either. Then, during tele-op and endgame, we scored one cone on a tall pole. Unfortunately, though, our alliance partner’s robot tipped over during intake, which led to ou5t gripper getting stuck to their wheel and causing yet another entanglement. This led to the shoulder axle loosening, and the entire subsystem became unusable after the match. This isn’t that bad since we plan to replace that with the new, redesigned Turret, Shoulder, and Arm, but it wasn’t the best way to go out.

Overall, though, we did okay, considering we were running a new robot with a partially untested subsystem in the UnderArm and still won a few matches and made the semifinals. In the end, though, our portfolio and documentation pulled through as we won Inspire. However, this tournament exposed many flaws and issues in our robot, which will be discussed in the Post-Mortem Blog post, and we will need to fix these issues before Regionals next month.

Meeting Log 2/3

By Jai, Aarav, Anuhya, Leo, Trey, Georgia, Vance, Gabriel, Alex, Sol, Tanvi, and David D


Task: Onboarding New Recruits, Organization, CAM, and Connect



Today we onboarded most of the new recruits and continued to work on fixing our broken shoulder from the last tournament. We also organized a lot of the RoboDojo and brainstormed more ideas for how we can reach out to professionals to better prepare for the upcoming Regionals competition.

We welcomed a couple of new recruits from some of our JV sister teams, Iron Giant and Iron Core. Today's new recruits were Alex, David, Jai, Sol, and Tanvi. We helped them get acclimated to the Iron Reign environment and taught them things like how to write blog posts, our organization system, and everything else they need to know to be a contributing member. This came with its own set of changes to the website to include them. Their performance over the few weeks leading up to Regionals will decide future team composition as we prepare to deal with our current seniors graduating.

As far as TauBot2 build progress, we began CAM (Computer Aided Manufacturing)on the shoulder, which controls the arm and its extension. CAM allows us to create custom pieces to fit our use case effectively. We also made progress on the secondary turret on the UnderArm, which should help increase our intake speed and score more points through a "handshake" between the grippers, although it still remains a daunting task.

We also organized much of the RoboDojo prepping for Regionals and any future competitions, specifically most of the screws and building materials. This should make building and robot maintenance much easier in the future as TauBot2 is built and developed.

Finally, we drafted a couple of emails that enabled us to set up calls with professionals. We hope to get some responses so that we can get some expert guidance on how we can improve our robot's code and design, as well as improve our connections with professionals for our portfolio.

Next Steps

Our next steps are to continue to teach the new members what they need to do and to continue the assembly of TauBot2 in preparation for Regionals. Additionally, we would like to expand our outreach to both our community and corporations.

CONNECTing with Professionals at the DISD Stem Expo

By Aarav, Anuhya, Jai, and Georgia


Task: Explore Possible Connection Opportunities at the DISD STEM Expo

Today, Iron Reign presented at the DISD Stem Expo in the Kay Bailey Hutchison Convention Center. Here, we both demoed TauBot and hosted a STEM activity for young children which involved building LEGO Mindstorms EV3 robots and then battling them SUMO style in a battle hexagon.

While this event was a great opportunity to motivate and interact with the community as a form of outreach, with the 100+ STEM exhibits and multitude of universities and corporations, it was an amazing opportunity to connect with professionals in order to receive valuable feedback on our robot.

Although with the hustle and bustle of the actual EXPO, not much assistance could be received as we also had a booth to manage, but we viewed this as a great time to go around, meet some professionals, build connections, and hopefully schedule future sessions where we could properly present and explain the robot.

First off, we were able to talk to some students from both the Texas A&M Engineering Program and SMU’s Lyle College of Engineering. Both programs seem quite interested in our robot, we are hoping to be able to get a meeting with a professor and some graduate students in order to present our robot to them, but those are still in the works.

In terms of corporations, we met a local startup called Strawbees, which focuses on developing STEM Building kits for children. They told us that they could potentially get us in touch with their lead “inventor”, who designed most of the product line. Since these projects incorporate both mechanical, electrical and software components, this could be a great opportunity for us.

We also were able to talk to representatives from Jacobs, Lenovo and NASA. Jacobs is a local engineering and architecture firm that is headquartered in Dallas, while Lenovo and NASA are both well-known organizations that could provide relevant hardware and software advice.

Next Steps

Our next steps will be following up with the people we talked to at the Expo in order to possibly schedule a session where we can interact with professionals, present our robot and receive feedback.

Meeting Log 2/10

By Tanvi, Sol, Gabriel, Trey, and Alex


Task: Attend to TauBot2 and transfer knowledge to the new recruits



Today was another day of onboarding recruits. For the next few weeks, along with regional preparation, we will be focused on the transfer of knowledge from seniors to recruits. Today the recruits shadowed the senior Iron Reign members, Trey and Gabriel.

Gabriel was working on TauBot 2. Trey was working on soldering a new cable harness for the arm. Tanvi shadowed Trey and practiced soldering; Sol shadowed Gabriel and learned the mechanics of previous Reign robots and TauBot while also helping Gabriel work on the UnderArm. 2.

While learning to solder, Tanvi learned the specific applications of this tool and the different materials used, as well as safety precautions. She practiced soldering with a spare plate and insulated wire. With further practice, she hopes to solidify her skills with this tool. Sol and Gabriel fixed the double motor tester today, and Gabriel reconfigured the Tau 2 UnderArm. Another recruit, Alex, studied the Iron Reign code base to become familiar with it. He hopes to further his coding knowledge by working with Vance.

Overall we helped the recruits learn skills needed to be efficient on the Iron Reign team, and continud the build of TauBot2 in preperation for Regionals, which is in 2 weeks.

Next Steps

We are working to further our recruit's knowledge and to further our progress on TauBot2. Throughout the next few weeks, our recruits will become acclimated to the Reign environment, and this will be crucial for us in order to complete the variety of tasks required to optimally prepare for Regionals. Specifically, we need to begin the code of the UnderArm and observe how the two subsystems interact to ensure that we have adequate control of the robot when it comes time to drive it. We also have to assemble the new Turrent and Shoulder and attach those to the new Chasiss. Finally, Motivate and Connect could always be improved to refine our award-winning ability.

Meeting Log 2/11

By Jai, Anuhya, Arun, Sol, David D, Georgia, Vance, Gabriel, Aarav, Alex, Tanvi, Leo, and Krish


Task: Continue to assemble TauBot2, work on portfolio, and prepare for Regionals



First off, we began assembling and wiring the UnderArm system. In the process of putting the UnderArm together, we ran into a couple of hurdles. The alignment on our parts was incredibly difficult to get right, and in the process of aligning them, we discovered that one of our servos was stripped. After tons of trial and error, we wired the servos that control the joints of the underarm. This was incredibly exciting because this was the first bit of functional mobility that our UnderArm system would be capable of. We strung the wires for connecting the servos, the new power switch, and the camera wire in a wire sleeve. We color-coded a lot of our wire management so that it's much easier to organize and understand for further replacement and continual maintenence.

Then, a seperate team worked on assembling the newly designed Shoulder and Turret. Our new Shoulder and Turret are custom-made and improve our robot in many ways. They make our robot lighter through the use of carbon fiber over aluminum. However, this mechanism is very similar to the initial iteration of TauBot. We switched to using an 8mm axle on the shoulder drive because our original shaft was too fragile and would bend under the pressure of the arm. We also worked on sourcing the right-sized bearings for our shoulder. During this meeting, we managed the slip ring wires and attached the slip ring to the carbon fiber base of the turret.



We also attached the nylon 3D-printed motor mounts for the motors that drive both the angle of the shoulder and the extension of the crane and began assembling the new motors with their required gear ratios. Preliminary work on the linear slide system also began as we 3D-printed the requisite spacers and cut the slides down to their proper length. We hope to have both these redesigned subsystems on TauBot2 as quickly as possible.



We continued to cut custom carbon fiber parts using our CNC machine, such as our belt tensioner and one of the motor mounts. In the process, we talked a lot of our new recruits through the CNC process and trained them to be proficient in using the CNC. This will help make our work with custom parts much quicker, as more people are capable of doing it. In doing this, we practiced a lot of problem-solving as we learned the hurdles that came with using a CNC machine. One such problem stemmed from the fact that step motors can't retain their positions. This led to the machine constantly losing where it was and slipping, which called for lots and lots of head-scratching and problem-solving.

Next Steps

Our next steps are to continue to train our new recruits to help make them more valuable assets to the team. With their help, we want to fully assemble and code the UnderArm system, the new Shoulder and Turret system and the new Crane. Once that's done we'd like to test the code and optimize it with the drive team so that we're ready to go for Regionals.

A Deep Dive into the Shoulder and UnderArm

By Aarav, Anuhya, and Krish


Describe our Implementation of the Shoulder and Turret Subsystems

With our primary game strategy for this season being to limit our movement around the playing field, the ability to quickly and easily rotate our intake and deposit systems is vital. Additionally, the ability to reach a variety of poles and scoring options is also crucial if we are to remain stationary. This is why we implemented a Turret and Shoulder on both versions of TauBot. This post will be a deep dive into the mechanics of both these subsystems on TauBot2.

First, let's talk about our Turret, which allows the Crane to move a full 360 degrees independently of the actual differential drivetrain. First off, we have the Slip Ring, a crucial part of the Turret since it allows the Turret to rotate continuously without interfering with the wire runs. Below is a simple breakdown of the new Turret assembly, which consists of turning curricular rings with ball bearings. Inside is a custom Nylon 3D-printed planetary ring used to drive the entire Turret and motorize it.



Finally, on top is a carbon fiber base plate upon which the entire Shoulder assembly rests. The Turret uses two main motors that synchronously drive its turning motion. The addition of another driving motor is what separates TauBot2 from the one lonely motor driving the TauBot Turret.



As seen in the image above, near the front, the two TauBot2 turret motors lay horizontally on the carbon fiber cover under the REV channels. These motors use bevel gears to direct power downward towards the turntable and the planetary gear, allowing it to turn twice as fast as its previous iteration.

On top of the REV channels, we have the entire Shoulder assembly, which is the basis for the Crane and allows our robot to score on various poles of all sizes from one stationary spot on the field. The two main functions of the Shoulder are to rotate the entire Crane up and down, and to power the extension of the linear slide.



As you can see, the slide extension is controlled by the front motor and a belt drive. A gear ratio and second motor control the rotation. The gear ratio allows one motor to drive the entire elevation process and ensures easier positioning.

The axle housing the largest gear is also a co-axial joint, allowing it to drive the extension and rotation through two separate systems. The Shoulder uses the shaft as an axle, but the main arm rotation gear pivots freely due to two attached ball bearings. Overall, this allows us to combine multiple responsibilities into one design and save space.

The motor used for rotation and elevation is assisted by two springs and a custom-designed logarithmic spiral to provide a consistent upward force to counter the force of gravity on the extended Crane, helping to reduce torque.



And that's a brief overview of the entire Shoulder and Turret system. This is also where our main Control Hub and our webcam are housed on the original version of TauBot. All in all, these two subsystems are crucial to the functionality of our robot and are the results of loads of careful and meticulous design by our team.

UnderArm Inverse Kinematics

By Jai, Vance, Alex, Aarav, and Krish


Task: Implement Inverse Kinematics on the UnderArm

Inverse kinematics is the process of finding the joint variables needed for a kinematic chain to reach a specified endpoint. In the context of TauBot2, inverse kinematics, or IK is used in the crane and the UnderArm. In this blog post, we'll be focused on the implementation of IK in the UnderArm.



The goal of this problem was to solve for the angles of the shoulder and the elbow that would get us to a specific field coordinate. Our constants were the end coordinates, the lengths of both segments of our UnderArm, and the starting position of the UnderArm. We already had the turret angle after a simple bearing calculation based on the coordinates of the field target and the UnderArm.

First, we set up the problem with the appropriate triangles and variables. Initially, we tried to solve the problem with solely right angle trigonometry. After spending a couple hours scratching our heads, we determined that the problem wasn't possible with solely right angle trig. Here's what our initial setup looked like.



In this image, the target field coordinate is labeled (x, z) and the upper and lower arm lengths are labeled S and L. n is the height of the right triangle formed by the upper arm, a segment of x, and the height of the target. m is the perpendicular line that extends from the target and intersects with n. We solved this problem for θ and θ₂, but we solved for them in terms of n and m, which were unsolvable.

After going back to the drawing board, we attempted another set of equations with the law of sines. More frustration ensued, and we ran into another unsolveable problem.

Our Current Solution

Finally, we attempted the equations one more time, this time implementing the law of cosines. The law of cosines allows us to solve for the side lengths of non-right triangles.









Using this, we set up the triangles one more time.



Our goals in this problem were to solve for q₁ and for α.

We quickly calculated a hypotenuse from the starting point to the target point with the Pythagorean Theorem. Using the radius and our arm length constants we determined cos(α). All we had to do from there was take the inverse cosine of that same equation, and we'd calculated α. To calculate q₁, we had to find q₂; and add it to the inverse tangent of our full right triangle's height and width. We calculated q₂ using the equation at the very bottom of the image, and we had all of the variables that we needed.





After we solved for both angles, we sanity checked our values with Desmos using rough estimates of the arm segment lengths. Here's what the implementation looks like in our robot's code.



Meeting Log 2/17

By Aarav, Anuhya, Jai, Alex, Tanvi, Georgia, Gabriel, and Krish


Work on build, code, and presentation in preparation for Regionals next week.

With the Regional competition coming up quite soon, we needed to get to work finishing up the build for TauBotV2, optimizing the code with new inverse kinematics for the double-jointed UnderArm, finishing up some subsystem blog posts, and practicing and preparing our presentation.

Presentation:

With a heavily below-par performance than the Tournament presentation where we skipped the entire Connect and Motivate section, we needed to stress practicing the performance this go around. We condensed the information into quick lines for each slide, but also expanded the overall amount of content to allow us flexibility.

After that, we got in valuable presentation practice to ensure that we don’t run over the 5-minute mark and miss out on sharing valuable information to the judges. At around a medium-ish pace, we finished the entire presentation in about 4:15. Pretty good, but that does mean that a few more slides of content could be added to maximize the time.

Build:

The new shoulder, turret, and linear slides need to be fully assembled and attached to TauBot2. We made the decision to move the entire shoulder assembly up a centimeter because of size restrictions and requirements, which meant we needed to reprint most of the motor mounts for the extension and rotation motors. We also finished assembling together all the linear slides and their carriages.



Code:

This is where most of the progress for today was made. Because of the double-jointed nature of the UnderArm crane, we needed new inverse kinematics equations in order to derive the proper angles for both sets of servos. From a given (x,y) point and the constants a1 and a2, which each refer to the length of each section of the crane respectively, we should be able to calculate the requisite servo angles. Through both right triangle trig and the law of cosines, we could find angle ɑ, the angle for the servos mounted by the turret, and angle β, the angle for the servos mounted between the two sections. This should allow us to move the crane to any position we desire simply with a set of coordinates.



We plugged both equations into Desmos to find the acceptable movement distances for the entire crane and added these calculations to the codebase, although we were not able to test them tonight. This is sort of a brief overview, but there will be a more detailed blog post covering the inverse kinematics of the UnderArm soon.



Next Steps:

With Regionals next week, we need to finish the full build of TauBot2 and begin coding the UnderArm so our two “intakes” can work together effectively in union. The UnderArm is still heavily untested, and there is a chance it fails miserably, so we need to start working on ironing out its issues and getting the entire robot to a functional state where it can cycle and score a few cones as intended. Our portfolio still needs to be converted into landscape and additional content added to fill up the vast amounts of empty space that remain. We also need to start working on possibly designing a custom binder out of carbon fiber to house the entire portfolio. With only a week left, we need to start acting now in order to finish everything before Regionals. The presentation is also a little bit low on content and slides, especially for pit interviews and Q&A, so we will be transferring more of the portfolio content to the presentation. To be competitive at Regionals for an award and advancement, we will need to tier documentation, which means sorting out any potential issues and lots of effort and practice. Overall, we made lots of progress, but there is still a lot of work left to be done.

Meeting Log 2/18

By Alex, Anuhya, Sol, Gabriel, Aarav, Jai, Leo, David D, Georgia, and Krish


Task: Regional Prep, Portfolio Development, Underarm Wiring and new Shoulder and Turret Assembly



To start we began to bring the wiring for the UnderArm through our wiring sleeve. The current UnderArm wiring situation was less than ideal and it needed to be reworked. About half of our UnderArm’s wires were in a wire sleeve and today we added the rest to it. We need a flexible wire sleeve that can collapse in and extend out so the underarm system can extend properly without being limited by the wires and prevent tanglement. This particular design of sleeve with interlocked fibers provides that functionality and with some extra attachment points that were added today it effectively holds the wires in place during UnderArm extension. However, there was a slight mishap with one of the servo wires coming loose from its plastic case, so we had to take a quick detour and fix that, but we were able to fully finish rewiring the UnderArm.

Currently in terms of our portfolio we have been redesigning the layout to switch from a portrait to landscape orientation to hopefully better present out robot and create some buzz. In addition, we made some additions to the portfolio to increase its thoroughness, detail, and remove extranous blank space. We also made some changes and updates to the TauBot build guide to improve its quality and detail when it gets added to our Engineering Notebook for Regionals. Much of the new Shoulder and Turret assembly was not there, so we added the instructions along with a couple helpful pictures. Finally, we completed many more blog posts to catch the blog up to date in time for the Regional competition.

In terms of build, we attached our new motor mounts that we printed overnight and are a lot closer to finally finishing the whole Shoulder and Turret assembly, although both axles still require significant work.



Next Steps

Our next steps are to continue to train our new recruits to help make them more valuable assets to the team. We also need to finish TauBot build as well as to finish code testing and preparing for Regionals in both presentation and portfolio, as well as start thinking about our Regional booth.

Meeting Log 2/21

By Jai, Anuhya, Vance, Leo, Gabriel, and Georgia


Regionals Prep: Work on Build, Code, and Presentation



With regionals just 4 days away, we had a lot to work on for TauBot2. Today, we focused on implementing a new Joint class in all of our joints in the UnderArm, soldered wires for the new Shoulder and turret assembly, and continued to wire the robot.

Code:

One issue that we had run into before was that whenever our Servos were given angles or positions that they couldn't reach, they would run themselves as fast as they could, often into other parts of the robot, which caused a lot of damage and undid a lot of our progress. Our solution to this was to run the Servos through another Class layer that did all of the calculations for Servo position given a target angle in degrees. Most importantly, it gave us the ability to control the speed of each individual Servo, which would make testing a lot less risky.

Build:

We also soldered the wires onto the slip ring and used heat shrinks to hold the wires together. This made it so that the slip ring can rotate, thus giving our robot the ability to rotate. However, the wires were incredibly thin, which led to constant failure in the soldering of the slip rings. After many many tries, however, we were able to finally get the wires fully soldered onto the slip ring. We continued to wire the UnderArm, and used heat shrink to secure wires on the Shoulder and Turret assembly. These were both exciting developments in the build progress of the new Shoulder and Turret assembly of TauBot2.

Next Steps:

With Regionals coming up soon, we are making good progress, and we need to continue to build, code, and test the robot, as well as work on our presentation.

NTX Regionals Play-by-Play

By Aarav, Anuhya, Jai, Alex, Sol, Georgia, Gabriel, Trey, Vance, Leo, Arun, and Krish


Review the events of the NTX Regional



Today, Iron Reign participated at the NTX Regional Championship in Flower Mound. Even with major robot performance issues, we were still able to advance to both the UIL State Championship and the FTC State Championship by winning the Motivate award after a strong presentation and portfolio showing. We ended up with a record of 1-5, which ranked us 39th out of 40th. Obviously, given the late night and lack of planning and preparation, this was partially expected, but there needs to be significant progress made in order for us to remain competitive at State and have a chance to advance to Worlds.

First, we will review the documentation events, specifically our presentation and our pit interviews. We had a new custom-designed portfolio using a ninja flex hinge, an aluminum body, and a carbon fiber cover, which was definitely unique. Our presentation was a lot smoother and more concise than the Tournament and we were able to impress the judges and involve the entire team. Our pit interviews also went decently well but could have been better, as we accidentally turned down an Innovate panel over time concerns, something that almost cost us an opportunity to meet with them. At the end of the day, our outreach and presentation ability was enough to win Motivate, allowing us to advance on from State.

Now we will go over the play-by-play for all of our matches, which did not go very well in terms of a robot performance perspective.

Match 8: 80 to 63 Loss

In our first match, we did not score any points in autonomous, instead focusing on maneuvering our robot to a spot where it could score optimally and grab cones from the same position. We are able to score one cone on a high pole. Our alliance partner parked and cycled multiple cones, but they received two major penalties for handling multiple cones at once, which led to us losing the overall match. Our robot also did become dysfunctional in the endgame as part of the arm got caught on the nudge stick attachment, preventing us from moving our crane. After the match, we removed the nudge stick guide since we were not using the nudge stick at this competition.

Match 20: 93 to 10 Loss

In the next match, we were able to fix the nudge stick problem, but then a massive code issue during gameplay and a minor mechanical issue essentially shut down the robot for the entire game. Our alliance partner also did not show up at all because right before the match, their linear slide broke. This led to one of our worst performances, as we scored 0 points and got 10 from an opponent penalty. Our robot essentially stood there for the majority of the match, unable to move its crane. We later found out that there was a shaft collar issue, which we promptly fixed, but this was quite frustrating and disheartening.



Match 30: 152 to 63 Loss

The next match went slightly better, but we still ended up with a loss. Initially, we did not score any autonomous points, and it took a while for us to get into position, which shaved valuable seconds off. We missed 2 high cones for scoring, but our alliance partners were able to score on both the low and the medium poles. We ended up not scoring at all, but this was not due to code or build, we just needed more driver practice. Our opponents were scoring very fast, and our alliance partners’ circuit attempt was not enough to subdue them. They almost even tipped trying to circuit. The loss wasn’t very bad numerically, but it stung that we couldn’t score anything.

Match 38: 152 to 63 Win

In the next match, we just parked for autonomous. Our alliance scored two high cones and parked as well. During the driver-controlled section, we had a problem with the robot and had to reinitialize the robot, while our partners cycled. While our partners fought for possessions, we managed to score 1 cone on the middle pole and got our element on a cone for the low pole. At the end of the day, we won the match comfortably, mainly due to the efforts of our partner alliance.

Match 48: 171 to 138 loss

In our 5th match, our autonomous ran, but we stumbled over a ground junction during parking, so we weren’t lined up. For TeleOp, we had to spend lots of time getting in position, but we scored on a middle and tall pole. For one cone, we tried to score while the opponent was already trying to score on it, resulting in a penalty. We got another penalty because our gripper flipped and wrapped on a pole, which was deemed a major penalty. There was, though, a penalty on the other team for moving the cone stack during their intake. After all the penalties were determined, we lost the match, which was unlucky, but the gripper issue will be something we look into.



Match 55: 112 to 68 loss

For our last match of the day, we managed to get positioned for scoring during autonomous, but missed by a hair, then parked along with our partners. Our opponents scored up to three high cones and double parked. During TeleOp, we once again spent considerable time positioning ourselves. While our partner struggled to score, we scored one cone on the nearest high pole and scored on a different high pole for spread possession. We missed a 3rd high cone but scored a cap on an opponent-possesed pole during the endgame. We even had penalty points from an opposition penalty.

Our poor time management was seen in our lackluster robot performance, but our portfolio and outreach was enough to advance us to State. We hope to use the 4 weeks we have gained to finish our robot design and code, while also expanding our connections with professionals and outreach in general.

NTX Regionals Post-Mortem

By Aarav, Anuhya, Georgia, Gabriel, Trey, Vance, Alex, Krish, and Jai


Discuss the events of Regionals, analyze our performance, and prepare future plans

This past Saturday, team 6832 Iron Reign participated in the NTX Regionals Championship at Marcus High School. Overall, despite some robot performance issues, we won the Motivate award, meaning we advanced to both the UIL State Championship and FTC State Championship. Today, 2 days after the competition, we had our Regionals Post-Mortem, and below are our main strengths, weaknesses, potential opportunities, and threats.

Strengths:

• Motivate game was quite strong -> Figure of 1500 kids at two outreach events was quite impactful
• Presentation
• Should work on arrangement of members, some were off to the side and couldn’t do their slides -> Potentially utilize CartBot and a monitor
• Meeting with judges went generally pretty well
• Portfolio is quite well constructed and unique
• Well-practiced portfolio/presentation team(lots of improvement from last time)
• Shoulder of the robot was strong
• Rails were bending; tension too tight.
• Switching to carbon fiber resulted in a far stronger robot that did not crack
• Turret was much more capable of moving the extended crane
• Even worked well in fast mode -> probably could increase the speed of our articulations

Weaknesses:

• The need to sleep
• Team burnout
• Significant under planning
• Entanglement of springy cable on junctions during auton
• Arm does wide arcs sometimes, articulations not working half the time
• Lack of driving practice
• Cone placement accuracy
• Navigation to final position speed
• Connect game compared to other top teams
• Turning down an Innovate panel
• Robot Demo in judging
• No reliable auton
• If auton goes bad, effects extend into tele-op. The dependence is nice when auton is working but a hindrance when it needs to work.
• No reliable wheels that rotate straight which messes up auton
• Underarm wheels not working well and the cable management is still out of wack
• Placement of certain components on the robot
• Should have made it more clear to new recruits that this was crunch time and expectations for attendance are way up
• Coordination in pre competition prep
• Our funding situation is really bad. We are way over extended on deficit and Mr. V is not putting more money in

Opportunities:

• Booth at the pits with detailed banners
• Good robot == good judging
• Completing the robot puts us in the running for more technical awards
• Build Freeze
• A fully functioning robot with the transfer that can win matches would put us in Inspire contention somewhat
• Synchronization with transfer would be impressive in a control sense as well
• Strengthening our motivate outreach
• Spring Break
• A larger team to better spread the workload leading up to State
• Curved Nudge hook
• Drive practice
• Need more on the left side. We are becoming a liability for our partners to side limitations in terms of driver practice.
• Code Testing
• Maintenance for parts that were previously underdone/not to our standards
• Live robot demo
• Time to improve our connect game
• Judges for control award wanted to see more sensors
• Nudgestick + cone gripper
• Mechavator Reveal
• Cart Bot
• Matching shirts and hats

Threats:

• Our Connect game is significantly weaker than the competition
• Technic Bots won Inspire twice
• They had good outreach as well
• They also have an underarm & it is very much working well
• We have 3 weeks to code an entire robot
• 9 advance from state to worlds so we cannot rely on Motivate again, we need a stronger award, also most likely cannot just place 2nd for any award so Think Winner should be our absolute minimum goal or Inspire 3r
• Mr. V unavailable for a number of days leading up to State

Meeting with the Head of the Dallas College STEM Institute

By Aarav, Anuhya, Georgia, Arun, Jai, Krish, Trey, Vance, Leo, and Gabriel


Task: Meet with the Dallas College STEM Institute



Today, team 6832 met with Jason Treadway, Head of the Dallas College STEM Institute and a former structural engineer. We virtually presented our robot and outreach efforts and were able to both intrigue him and received important input from him.

Overall, Mr. Treadway was quite impressed with our presentation, robot, and efforts to not just “design for ourselves,” but also educate the community on robotics. He was a large fan of the recruitment pipeline we established with Dealey Robotics and our 2 JV teams.

In terms of advice on the presentation, he suggested that we focus on adapting our images to help better highlight the differences between V1 and V2, possibly a side-by-side comparison that would appeal to visual learners and help them better see the evolution. He also found some of the diagrams of the drivetrain potentially confusing, and stated that adding dimensions and more detail would make them clearer and add a point of reference.

Finally, we discussed our outreach and motivate efforts, and Mr. Treadway asked about how we found out about outreach opportunities. As a team, we definitely do a lot of networking and make an effort to talk to people and build strong relationships. We also have mentor connections, utilize cold emails, and personal connections that we do our best to take advantage of. We were also advised to follow up with our Waymo connection and possibly get a tour of their local Dallas location.

Mr. Treadway also offered us a possible later connection opportunity, where we could come to the Dallas College Brookhaven campus to present our robot to college students in early April. Overall, it was a very informative session and we would like to thank Mr. Treadway for his time and advice, and we will definitely take it into account as we head to State.

Meeting Log 3/3

By Jai, Anuhya, Aarav, Alex, Tanvi, Georgia, Gabriel, Sol, Trey, Krish, Arun, Vance, and Leo


Task: Plan and strategize for the Road to State

Finally back from a much-needed break after regionals, the team got back together for a more strategy-focused meeting, and we did some preliminary work on code, build, and portfolio.

Planning:

To help us use our time efficiently, we focused the first couple hours of the meeting on planning. We created a spreadsheet with tasks, task descriptions, and deadlines. Learning from our experience at regionals, we decided to have a build freeze two weeks from the state tournament to make sure that our coders have enough time to fully integrate our new subsystems. With Spring Break coming up, we created a Doodle to help us find the best times to meet.

Code:

The main code task for today was creating collision detection for the UnderArm and the main Crane. This would add another layer of safety to make sure that our robot doesn't hit itself while it's controlled by Inverse Kinematics. We initially started by creating a line of no pass halfway between the main chassis and the chariot. We then realized that we needed more maneuverability with the UnderArm, so we created a box of no pass instead. We did this by checking if the field coordinates at the end of the UnderArm were outside the coordinates of a virtual box that we drew around the UnderArm. We also planned for the rest of the code that needs to get done before state.

Connect and Outreach:

For Connect and Outreach, we started with drafting grant applications. We need more funding to keep building the robot and attending the tournaments, and this was our first step toward acquiring some. After this, we reached out to some companies that we had connections with as a team. We talked to some people that were close with our team members so that we could get to them before state. We also emailed and contacted some newer companies with a connection to STEM.

Build:

On the build side of things, we reattached the UnderArm. We also tested new gear ratio motor speeds to find the most efficient one for our robot. We made more progress on the wiring harness for the crane and we created a couple of new custom pieces to help implement it. We also came up with a possible new solution to stagger the movement of each stage of our slide to improve predictability.

Next Steps:

Now that we have a clear plan and we've gotten some good work done already, it's just a matter of executing and polishing on the road to state.

UIL and State Play-by-Play

By Aarav, Anuhya, Jai, Alex, Tanvi, Georgia, Gabriel, Trey, Vance, Leo, Arun, and Krish


Review the events of the UIL and FTC State Championships



This past week we participated in the FTC state championship and UIL state competition in Belton, Texas. Overall, we were successful, winning the Think Award at State and thus advancing to Worlds despite less-than-ideal robot performance. First, we will discuss judging and then transition into our game-by-game account. There will also be a post-mortem that will be uploaded later.

Regarding judging, all of it was done the week before the competition remotely. This meant we had to ensure that we remained on schedule because robot demonstrations are essential to virtual judging. Unfortunately, we could not show a live transfer, but we did have embedded videos depicting our robot’s functionality. Our main presentation and callbacks went well despite a few mishaps, especially regarding the key points we wanted to hit. Overall though, we were able to show our innovation and iteration processes and how TauBot connected with our game strategy and our team’s story as a whole.

As for gameplay at both events, it did not go as smoothly as we would have liked. We did face some trouble during sizing but managed to get the robot to fit. Here is a game-by-game account of each of our matches. Overall we went 1-11 and managed to transfer and score 3 times in total across both days. Some key notes to mention were that we did not have a working autonomous at all and thus did not run one in any of our matches.

Texas UIL

Match 4: 60 - 47 Loss

In the autonomous period, our robot did not move at all. During the teleop period, our robot hit one cone out of the substation, scored one cone, knocked another cone down, and grabbed the cone in intake, but the transfer didn’t work, and during the endgame, we were not able to score our beacon.

Match 7: 181 - 73 Loss

During the autonomous period, our robot did not move at all. In the teleop period, we had issues controlling UnderArm and determined that our driver synchronization needed to be worked on. In addition, our Crane was acting glitchy, and our flipper gripper wasn’t working. In the endgame, our robot was completely stationary the whole time.



Match 16: 251 - 75 Loss

During the autonomous period, our robot did not move at all. In the teleop period, we picked up a cone, put it back down, picked up a cone, and dropped it. During the endgame, the transfer worked, and we scored a cone. Some additional notes we took include that while transfer worked, it was inconsistent and slow (15-20 seconds for transfer, not including scoring).

Match 25: 144 - 20 Loss

During the autonomous period, our robot did not move at all. During teleop, our Crane was glitching again, and our UnderArm picked up a cone, but the Crane dropped it while trying to deposit it. Our Crane kept glitching in the endgame, but UnderArm worked to some degree.

Match 29: 171 - 83 Loss

During the autonomous period, our robot did not move at all. During teleop, our UnderArm struggled to pick up cones more than usual, and the transfer messed up. During the endgame, the robot demonstrated the same behavior as in teleop.

Match 34: 107 - 55 Loss

During the autonomous period, our robot did not move at all. During teleop, something went wrong in the shoulder of the UnderArm, and the robot stopped operating. During the endgame, the robot was stuck and couldn’t move due to the prior issue.

FTC State Championship

Match 9: 226 - 97 Loss

During the autonomous period, our robot did not move at all. During the teleop, we lost 20 points in penalties (our side). Our alliance partner wouldn’t let us go to the substation for cones, but we picked up a cone from the ground and scored. We picked a cone up from the substation, but the transfer didn’t work. During the endgame, we were not able to score our beacon..



Match 18: 280 - 29 Loss

During the autonomous period, our robot did not move at all. During teleop, the robot took long to recalibrate and transfer and couldn’t fully grab a cone. During the endgame, the turret started rotating. One thing to note was that referees said our sizing wasn’t proper (even though it was). We had to turn our robot 45 degrees, which contributed to the late start of recalibrating, which we later challenged but did not amount to anything.

Match 26: 110 - 97 Loss

During the autonomous period, our robot did not move at all. During teleop, we picked up a cone, the transfer worked, and a cone was scored; a cone got stuck but was transferred after a cancellation, and we scored a cone. During the endgame, the Crane got stuck on a pole.

Match 32: 111 - 79 Loss

During the autonomous period, our robot did not move at all. During teleop, we picked up a cone, but the transfer didn’t work, and this happened multiple times. We pulled from the cone stack during the endgame, but it didn’t land on the pole when we deposited them.

Match 39: 242 - 165 Loss

During the autonomous period, our robot did not move at all. During teleop, the robot wasn’t moving; it was completely stuck. However, during the endgame, the robot was still stuck in position. Some things to note are that we queued late and didn’t have time to run the full calibrate sequence and ended up stopping to stop the robot from breaking itself. We also started without calibration because we were told we would incur penalties. This is definitely something we can improve on.

Match 48: 144 - 88 Win

During the autonomous period, our robot did not move at all. During teleop, the robot got into position, grabbed a cone, and hyperextended the wrist, so we switched to using the Crane as both intake and depositing. Unfortunately, during the endgame, we couldn’t get the beacon. One thing to note is that the wrist went limp and couldn’t be corrected through manual control.

Even though TauBot was not up to par, we hope to spend the next 4 weeks fine-tuning it and truly turning it into a Worlds-level robot. More information on our takeaways and future plans will be discussed in our post-mortem, but we made it to Worlds at the end of the day.

Texas State and UIL Championship Post-Mortem

By Aarav, Anuhya, Georgia, Gabriel, Trey, Leo, Vance, Alex, Krish, Jai, and Tanvi


Discuss the events of Regionals, analyze our performance, and prepare future plans

This weekend, Iron Reign participated in the FTC UIL Championship, which was mainly robot game, and the FTC Texas State tournament, where we advanced to FTC Worlds with the Think award, an award granted for the engineering portfolio and documentation. We learned a lot from our gameplay and communications with our alliance partners, and got the chance to see our robot in action properly for the first time. This is our analysis of our main strengths, weaknesses, and future opportunities and threats we will have to deal with before competing at Worlds.

Strengths:

• fast maintenance when things went wrong, both build and code related
• sticking to our own strategy
• being able to access all the junctions/ cover a lot of ground
• communication with alliances
• not being a hindrance to our alliance partners

Weaknesses:

• penalties for wrapping around poles and extending out of field
• long time required to recalibrate if setting up goes wrong
• no consistent gameplay
• turret movement is very choppy
• lack of time to modify UnderArm
• less time for testing because of complicated design
• cone gets dropped, especially during transfer

Opportunities:

• further optimizing transfer and transfer speed
• working on auton parking and cone scoring with transfer
• automating transfer
• we will have time to further finetune the robot

Threats:

• Nudge Stick is still a hindrance to game play
• lack of drive practice because design was prioritized
• robot pushes itself past what is mechanically possible
• robot relies on calibration, which isn't convenient

Meeting Log 4/1

By Sol, Georgia, Trey, Anuhya, Gabriel, Leo, Krish, Tanvi, Jai, Vance, Alex, and Aarav


Task: Gripper Redesign and Build Fixes

Trey redesigned the gripper stopper on the underarm to limit the degrees of movement so that the underarm gripper will not get stuck. The original design of the gripper stopper did not fully stop the gripper because it did not limit the gripper's movement as much as we wanted it to.

The tensioning belt on the shoulder attached to the crane became too lose, and started skipping at lot, so Krish and Georgia re-tensioned it again by moving the motor on the turntable farther away from the other.

The omni wheels on the bottom of the underarm kept breaking, so we replaced them, and worked on ideas about how to stop breaking the wheels. We figured out what was happening was that there was so much pressure being put on the wheels that the spokes for the small wheels kept falling out of the seams. The problem with this was that the wheels would damage the field, and the underarm wouldn't smoothly move across the field. To solve this problem, we melted the plastic so that the seams were no longer open and the spokes wouldn't be able to fall out.

Our code team continued to tune and debug autonomous, while our build team asynchronously worked on the robot. Later, Georgie and Tanvi worked on pit design for Worlds. They designed the pit and figured out how much it would cost. After deciding on what materials we would need, they reached out to companies to ask about sponsorships. In addition, we worked on updating our portfolio and designing banners for Worlds.

Next Steps:

Our next steps are to continue tuning code, more drive practice, and finish pit design.

Meeting Log 4/9

By Georgia, Sol, Trey, and Leo


Task: Prepare for Worlds through Build and Drive

Today, we did drive practice, and worked out some of the smaller issues with transfer.

While doing robot testing, the servo on the underarm shoulder joint broke. We took apart the joint in order to fix the servo, but the servo's gearbox was not accessible, rendering us unable to diagnose the problem, so we had to replace the old servo with a new one.

Trey redesigned a new transfer plate bridge, then milled it on the CNC. While milling this piece, we pushed the CNC too much, causing a drill bit to break. After that, we cut the part again, but the cutouts got caught between the drillbit and the plate, causing the CNC to crash. Twice. Eventually, we fixed the issues, and successfully cut out the new transfer plate bridge.

By the end of the meeting, we had successfully tested underarm.

Next Steps:

Our next steps are to finish making transfer work, remove the shoulder support spring, get more drive practice, and prepare for State and UIL.

Consequences of Removing the Shoulder Support Spring

By Anuhya, Trey, Leo, Gabriel, and Vance


We learned the consequences of making small changes to build without fully knowing the outcome

A small change can make a huge difference: we have learned that we really should have put the shoulder spring back in place after we rebuilt Taubot. The Crane arm fails to maintain its shoulder angle, and this is an issue which has only started since we built Tau2. We're probably hitting the thermal cutoff for the motor port, which causes the control hub to stop sending power to the shoulder motor and the whole arm crashes to the ground.

This also means that its stalling the motor and it pulls a huge amount of Amps. We also have horrendous battery management, which leads to short battery life and permanent battery damage. The Crane being held out fully extended further damages it.

A lot of Tau2 is an inherited, yet modified, design. We aren't fully aware of the considerations that caused a spring to be in Tombot, the original robot we based part of our design on. We also changed the gear ratio of the shoulder motor so we could power through lifting the shoulder at extremes, and we're pulling many more electrons to compensate for something which was built-in initially.

The original reason was a design goal - whenever you make an arm, you want as little motor force as possible dedicated to maintain the arm against gravity. The motor should just have been changing the position, not maintaining it. Real world cranes use counterweights or hydraulics to fix this problem, something which we don't conveniently have access to.

The spring was meant to reduce the burden of maintaining the crane's weight against gravity. It wasn't perfect by a long shot, but it definitely did help. Our batteries would also last longer in matches and have a longer life.

Thankfully, we still have access to the original CAM we used for the log spiral, and a spring could easily be reintroduced into our robot if we messed with some of the wires. It's a high priority and needs to be done as soon as possible.

However, hardware changes like these are incredibly annoying for coders. We recently added a custom transfer plate too, and it was very helpful to increase transfer efficiency. It also changed the angle of the initial transfer plate to the flipper gripper, which added 3 hours of extra coding time to retune transfer and grasping the cones so it didn't get knocked off. It will be better once fully tuned, but it doesn't change the fact that small changes in physical build are incredibly annoying for the coding team. Adding the shoulder support spring will also have this kind of cost, but it's crucial for further success.

Scrimmage Before Worlds

By Anuhya, Jai, Alex, Trey, Gabriel, Vance, and Leo


Attending a Final Scrimmage Before Worlds

Today, we attended a scrimmage that team 8565, Technic Bots, graciously invited us to. The point of this scrimmage was to get some time seeing the changes which the other Worlds-advancing NTX teams had implemented, and to get some ideas of strategies and alliances. This was the first time we were able to get proper driver practice with the newly designed Transfer Plate and Nudge Stick.

One of the main problems we experienced was our cable harnesses malfunctioning. The servos kept getting unplugged or the signals just weren't sending properly, which was a large issue. This meant that our Gripper Flipper assembly wouldn't flip into place, so the cones which the UnderArm was depositing onto the Transfer Plate would remain on the Transfer Plate and act as a hindrance. This also increased the chances of double cone handling, which is a major penalty. The Bulb Gripper was unable to get cones off the Transfer Plate because the servo which controlled the Gripper Flipper wasn't working. However, we learned that UnderArm to Transfer Plate mechanisms worked incredibly effectively and consistently.

We also learned an important lesson about calibration; without realizing there would be consequences, we started calibration of our robot with the robot in the starting position, against the walls of the playing field. During calibration, the Turret does a full 360, during which the nudge stick kept hitting the walls of the playing field, causing one end to completely snap off at the joint which connected the REV channel to the nylon.



The scrimmage also gave us a chance to work on auton. During our autonomous drive, we use a timer separate from the one on the driver station to make sure that we can complete or abort our auton safely before the driver station timer kills power to our robot. In our auton testing, we found that this time-management system was not properly iterating through the stages of our autonomous. To solve this, we reviewed and edited our code to work with our timer system and performed repeated trials of our autonomous system to ensure reliability. Once we fixed these bugs, we had the chance to begin working on improving the accuracy of our parking procedure. Our parking procedure hadn't been modified for our new cone-stack-dependent autonomous strategy, so we changed the code to account for it. We are now well on the way to a consistently performing autonomous mode.

Next Steps:

We will continue working on building and code, especially auton. We need to make sure that our Nudge Stick works in practice, and we need to make sure our drivers get time to get used to having a Nudge Stick to control. Overall, we need drive practice, and we need to make parking and getting cones from cone stack consistent in our autonomous period.

FTC World Championship 2023

By Anuhya, Jai, Alex, Trey, Gabriel, Vance, Leo, Tanvi, Georgia, Krish, Arun, Aarav, and Sol


Our Experience This Year at Worlds



Over this past week, we had our final preparations for the FTC Worlds Championship in Houston, Texas, which was our final destination after everything we’d done this season. This Championship was an incredible opportunity for us to interact with teams from around the world, and establish relationships with teams we never would have been able to meet otherwise. It was an incredible outreach opportunity, where we talked to teams from Romania, India, Libya, and other countries with different approaches to how we did robotics. At the Regional Edison Awards, we won 2nd place Motivate!

What was productive at worlds?

The build of the robot was much closer to being done than it had been at previous tournaments. We were also relatively confident in the capabilities of our transfer system, especially with the implementation of the Transfer Plate. We were also prepared with replacement parts fully made and manufactured, so we knew we would be able to replace the UnderArm if something went wrong with one of the arms.

What was beneficial to our team?

The time and effort we put into our portfolio as a team was definitely one of our strongest points. We were prepared for how to interact with judges, and we had also practiced our answers to some possible questions we could get. By showing the judges how our team was set up and the true nature of our compatibility and cooperation, we were able to leave a lasting impression.

We also had a pit design which was made to help our productivity, with shelving to organize our tools and supplies, tables set aside for different purposes and stools to maximize space within the tent. It also helped us convey a good team image to the other teams who were present at Worlds, and gave us a place to talk about our robot design and game strategy. The posters which were put up in our pit were also very effective, because they were great conversation starters. Teams were very interested in seeing our robot design and getting an explanation for some of our decisions when they saw the engineering banners which were put up at eye level.

How do we want to improve?

One large issue that we had throughout the entire season was our robot was never fully prepared when it was time for the tournament. We didn’t have the opportunity to have driver practice throughout the season, especially with the new robot and the new design, so we found a lot of issues at the actual Worlds Championship that we should have found and fixed way earlier. We also burnt out many of our axon servos at the tournament, and scrambling to find more because they were the basis of our UnderArm was not a good look for the team. One of our primary goals for next year will definitely be finishing the robot on time, so our drivers have a good opportunity to get drive practice. At the Championship, we also barely passed inspection. Because we didn’t have enough time to ensure that our robot fit under sizing when it was initialized, we had to get inspected a second time. Overall, we want to make sure that we are fully prepared for all tournament procedures in the upcoming season, so we don’t have as much of an issue during the actual tournament.

Our packing and organization also left something to be desired, because we didn’t start packing until 1 or 2 days before the tournament. While our pit design was effective, we didn’t have a chance to practice it beforehand, and we could have made some design changes and improvements if we had practiced it prior to the tournament. Even though we had shelves, it took us 20 to 30 minutes to find tools and that was incredibly frustrating when we were in a time crunch.

Something else we were lacking in was communication between different subteams. One of our largest problems was that the coders weren’t given enough time to work on the robot because the modelers and builders weren’t entirely sure about when prototypes would be available. We also sacrificed a lot of sleep because we weren’t ready to compete when tournaments came around, and it wasn’t sustainable throughout the year and led to a lot of burnout. Our morale was also low because of deadlines and not having a sustainable work ethic.

Next Step:

The next season started the day Power Play ended. Over the summer, we have plans to start recruitment and outreach early, and set up boot camps to get the new members of our team more specialized and ready for the next season. We also wanted to get the MXP up and running, so we would have more mobile opportunities to teach kids how to code and use 3D printers and just set up more outreach events. We’ve also started setting up organization softwares and setting up different team roles to maximize organization in the following seasons.

Recruiting at Flight School

By Aarav, Anuhya, Tanvi, Jai, and Georgia


Task: Recruit new members at the TAG Flight School

Today, Iron Reign presented at TAG’s Flight School in order to recruit new members in preparation for the upcoming season to fill out our sister teams, Iron Core and Iron Giant. There was a quick recruitment presentation and a demonstration of basic REV components for interested freshmen. The idea was to generate hype and interest in order to ensure attendance at a more in-depth meeting later during the school year with more logistical information and a live demo of TauBot. Efforts like this are important to ensure the sustainability of the Iron Reign program to help replace our members who graduate with ones who already have FTC experience through our sister teams.

Next Steps

Host a more in-depth informational meeting with a live demo of TauBot and a meeting at our workspace. Additionally, recruitment efforts aimed at SEM students are also a significant priority.

Flyset - R2V2 and Dashboard

By Anuhya, Jai, Krish, Alex, and Sol


Task: Give presentations at Flyset about progress made this summer

This weekend, we participated in the FlySet workshop, graciously hosted by team 8565, TechnicBots. We gave two presentations: one on our summer project, R2V2, and one on changes we made to FTC Dashboard.

R2V2 - A Center-Stage Drive

Aarav and Anuhya were tasked with creating the presentation, with Anuhya focusing on the steering wheel while Aarav focused on the braking mechanism. During our presentation, Jai and Alex split all the code slides, as they were the ones who worked on steering wheel and braking mechanism coding, calibration and testing. Anuhya, Krish and Sol focused on build and assembly based slides, because the build team designed and built the steering wheel and braking mechanism.

Overall, the presentation went well! However, because of a lack of practice in the presentation, there were hiccups with passing the microphone from person to person and lines were not entirely memorized. The team didn't seem as put-together as we could have and we want to ensure that we get more practice before our next presentation.

FTC Dashboard

Alexander and Jai created and presented a presentation detailing the changes Iron Reign made to FTC Dashboard with the assistance of Mr Brott. Some of the changes included translation and rotation of the origin in FTC Dashboard as well as the addition of image and text support for the graph and field in the Dashboard. These changes were made to enhance the useability of Dashboard for teams and to enable more flexibility in Dashboard's display. There is a more detailed description of these changes in the blog post(hyperlink this) dedicated to this topic.

Alexander and Jai created and presented a presentation detailing the changes Iron Reign made to FTC Dashboard with the assistance of Mr Brott. Some of the changes included translation and rotation of the origin in FTC Dashboard as well as the addition of image and text support for the graph and field in the Dashboard. These changes were made to enhance the useability of Dashboard for teams and to enable more flexibility in Dashboard's display. There is a more detailed description of these changes in the blog post dedicated to this topic.

An Overview of the R2V2 Braking System

By Aarav, Tanvi, Krish, Sol, and Gabriel


Task: Design a subsystem to control the braking of R2V2



An essential part of effectively remote controlling R2V2 is the developing a method for controlling the brake autonomously. We decided, for safety reasons, to not involve the accelerator at all, so the movement of RV2V would be reliant on the application of pressure on the brake.

Our main requirement with the system's integration with R2V2 was a quick installation process and no permanent changes, meaning that the entire assembly would have to be removable but also rigidly installed for reliability. Additionally, for safety purposes, the resting state of the mechanism would need to be with the brake pushed down, and with power, the brake would be released and the vehicle would move forward. For more information about the safety protocols implemented to protect us, check out this blog post.

Here is an image of the brake pedal(the larger one) and the area immediately around it. There were size restrictions due to a large center console on the right and the driver’s seat assembly.



Our initial idea was to use a series of pulleys and bungees to manipulate the brake pedal; however, this applications would require the use of the driver’s seat itself, making us unable to have a driver physically present in the case of emergency. For safety reasons, we pivoted and decided to attempt to emulate the natural movement of a foot and ankle that a human uses to driver.



Engineering

The braking subsystem consist of an approximately 2.5 foot by 7 inch REV rail frame that slides in under the driver’s console and lines up with the brake pedal. It attaches to points drilled into the flooring of the RV, and can be quickly installed. This allied for no significant permanent alterations that could interrupt our ability to drive the RV “normally.”

On the frame, there is a “foot” mechanism mean to simulate the movement of a foot that presses the brake by rotating on an axle attached to the frame. This “foot” is what we manipulate in order to press and release the brake.

In order to set the default position of the foot mechanism to down, a system of bungees and pulleys are used to create tension and pull the brake down. This way, if the system ever loses power or fails, the foot will revert to pressing the brake and stopping the vehicle. The bungees are tied to the front of the foot and pass through a set of pulleys that send them to the back of the frame, where they are securely tied down. These bungees create a significant amount of tension in order to ensure the foot presses the brake far enough to stop the vehicle.

To lift the foot, we used heavy-duty twine that could withstand the forces put upon it. The twine was tied to the back of the foot and passed through an elevated pulley(allowing us to more effectively lift the foot through mechanical advantage) to a spool. We used a REV ultraplantery motor connect to a gear train to rotate the spool and lift the foot. Our usage of gears and an elevated pulley system allowed to to counteract the tension of the bungees and release the brake.

The diagram below highlights the major components of the system as described above.



Coding

The code for the “unbreaking” mechanism consists of two parts: calibration and running. Additionally for the code of the robot we refer to the braking system as the unbreak as it only runs when we want to stop breaking.

First we perform the calibration where we run the motor until we have tightened the string pulling the unbreak up and we set this encoder position to 0 and are not able to go lower then this. Then we run the break until a human sees that the break has stopped being depressed; this is the maximum for the unbreak, and we cannot go higher than that. That finishes the calibration sequence now we can run the unbreak.

The way that the unbreak runs is a two-fold controller system. One person must depress the deadman switch or the unbreak will automatically run to its lowest position. Once the deadman switch is depressed then the unbreak can be lifted. When the trigger to unbreak is pressed when the deadman switch is active then the unbreak will raise until it reaches its max or until the trigger is released. When the trigger is released the unbreak runs back down to ensure that we are always breaking when not actively unbreaking.

A majority of the system is comprised of REV parts, illustraring how we can use the parts on our FTC robots for larger and more complex applications. The system itself, after lots of code tuning, worked pretty reliability throughout our testing.

Next Steps

We are hoping to further test R2V2 and extend upon its capabilities and further share our progress through our blog, socials, and Youtube.

An Overview of the R2V2 Steering Wheel

By Anuhya, Vance, Trey, Leo, Alex, and Jai


Task: Design a subsystem to control the steering wheel of R2V2



One of the main components of our mission to make a remote-controlled RV was figuring out how to automate our steering wheel.

Step 1: Designing the plywood base for the steering wheel

Our first plan was to attach a sprocket and chain to the plywood base for the steering wheel. We knew we needed a plywood base because it would be both lightweight enough to easily be removable and attachable onto the steering wheel, and sturdy enough to handle a motor with high torque without splitting. While trying to screw in the sprocket to the base, we realized we didn’t have a convenient way to attach the motor assembly and the chain would most likely “lock up” if we tried to constantly move it forward and backwards.

We settled on a design using a worm gearbox and the REV ultra planetary motors. We used a paddle to keep the worm gearbox and motor stationary so the steering wheel could move. The paddle was latched onto the window using REV bars and attached to a carbon fiber plate, which was then secured onto the worm gearbox. We used a second carbon fiber plate to attach the shaft collars on the axle of the worm gearbox to the plywood base, and made sure the shaft collars were tight enough to not spin on the axle when high amounts of torque were applied with the worm gearbox.

Step 2: Attaching the plywood base for the steering wheel



We didn’t want to make any permanent changes to the RV, so we devised a system to attach the plywood base to the steering wheel using straps and buckles. We attached the buckles to 2 sides on the top of the plywood, and attached one end of the straps onto the back of the plywood. To attach it, the straps go under the steering wheel and latch onto the buckles on the top of the steering wheel, securing the plywood to the steering wheel.

Step 3: Coding and calibration!

After we finished the design portion of the steering wheel we had to get it to actually move. We needed to not only map the left and right motion of the steering wheel to buttons on the logitech controller we are using for the R2V2 but also to know where the wheel is in relation to its maximum rotation to either side at all times.

In order to find the maximum rotation of the wheel we had to spin it all the way to one side. We need to find a way to know in the code that we reached the end of how far we could turn. For this we decided to test to see if the motors stalled because when the motor cannot move the wheel anymore in a direction its amperage spikes. This makes up our calibration mechanism. We spin the wheel all the way to the left and when it stalls we record the encoder position as the max left we can go. Then we spin the wheel all the way to the right and do the same thing but with the max right. We then find the distance between the max left and right and assume the middle of those numbers is center. To finish the calibration we run the wheel to center and then set that encoder position to 0 for easy readability for the driver. Left is negative and right is positive. Finally as a sanity check we make sure the encoders were recording values and if they were not we stop the robot as a safety precaution.

This procedure gets us the precise location of the wheel relative to where it is, and we can safely run the robot using the controller.

Next Steps

We are hoping to further test R2V2 and extend upon its capabilities and further share our progress through our blog, socials, and Youtube.

Center Stage Game Reveal and Ri2D Day 1

By Aarav, Anuhya, Georgia, Sol, Tanvi, and Alex


Task: Assess the Center Stage Game and begin Ri2D



Today, Iron Reign attended the season reveal for the new FTC season and began working on this year’s Robot in 2 Days, a tradition where we prototype a preliminary robot the weekend after the reveal to experiment with ideas and concepts. Unfortunately, because of the complexity of this year’s field, most of today was spent attending the reveal, tidying up the workshop, and assembling the Center Stage field. This post will be a distillation of our thoughts about the game, strategy interpretation, and commentary about the field setup and assembly.

This year’s game is quite a bit more complicated and convoluted than those of previous years. There are multiple scoring methods and multiple objectives during the game, and the field layout itself will test the communication of alliances and the referees. Here’s a list of some key things we noted during the reveal:

• At first glance, a small, light, and fast robot seems to be the most effective tactic. There is very little strength required due to the hanging aspect and lightweight pixels.
• Lightweight pixels mean the intake system/gripper can be quite weak.
• The right of way on the stage door also limits the value of defensive play.
• Short robots will probably be what is utilized by most teams this year to avoid using the stage door and robot traffic
• It is 11” between the bottom of the closed stage door and the ground, so this effectively cuts maximum height by a third. The 14” truss will also be used in this same manner.
• There will be a heavy emphasis on video pipelines and object recognition for the autonomous portions.
• We also cannot use April Tags for recognition like we did last year; we will need to differentiate on other aspects.
• Grippers need to be able to pick up 1-2 pixels at a time, potentially adding to an already captured pixel, and drop them off one at a time.
• Turns and rotations can be reduced by building two separate subsystems of intake and deposit to reduce cycle time.
• The less-than-ideal placement of the wing will lead to intense competition for the white pixel stacks.
• The drone aspect leaves a lot of gray areas in the rules and what qualifies as a legal “drone.” There will need to be experimentation to determine the ideal shape.
• It can be tough to score pixels in the background. They have a tendency to bounce off if placed with too much power or placed too high up.

After the reveal, we headed back to the dojo, tidied up, and began the grueling task of assembling the game field, which took multiple hours(around 5) to build. Certain aspects of the game, such as the assembly for the C channels and A-frames on the rigging posed significant challenges. Additionally, one of the rigging tubes had stoppers stuck in both ends, proving it difficult to be further used in the construction of the field. As a result, Sol had to cut down one of the tubes from last year’s field components as a substitute. Because of these issues, we were unable to start on Ri2D today, but we did have a fully assembled Center Stage field. A second blog post detailing our Ri2D efforts will be posted tomorrow, along with an overview of Ri2D.

For now, here are a couple of key questions we had about the game that could potentially influence design decisions:

• What is the highest point where a pixel will need to be placed?
• Can the drone be more like a dart?
• Is a simple arm-based drone launcher enough?
• Could we just pop the pixel up using a “spatula” like motion/object?
• What is the smallest paper airplane that can be made with a single sheet of 20 lb paper?
• Could you make a drone follow a U-shaped path?
• What would be an effective team prop that could be easily identified?



Next Steps

Use the newly assembled field and our fresh ideas to create a preliminary Robot in 2 Days that can score points and complete a couple of basic tasks. Experiment with methods for hanging and drone design as well. Finally, we would like to capture footage and produce a video in order to share our work and findings with the FTC community.

Center Stage Robot in 2 Days(Ri2D) Overview

By Aarav, Anuhya, Krish, Sol, Tanvi, and Alex


Task: Build, Code, Test, and Film our Center Stage Ri2D

This blog post will serve as a more in-depth analysis of Ri2D, including dives into specific subsystems and rationale.

The Chassis

In order to save time, we repurposed a basic mecanum and REV rail chassis from our sister team, Iron Giant. It is a basic REV rail frame with mecanums driven by motors and chains, along with all the requisite electronics. We built all of our additions on top of this base; however, we did spend a sizable amount of time fixing the chains on the chassis. Mecanums were the clear-cut choice because of their simplicity to use, the lack of on-field barriers that could interfere with them, and their strafing capabilities(which we unfortunately did not get working due to balance issues). One of the critical issues with this chassis was its lack of weight balance. The Control/Expansion Hub and Battery were located on the front side, preventing our Ri2D from strafing and causing the opposite side to pop up when driving.



The Gripper

We found that a prototype of our old UnderArm gripper from TauBot(last year’s robot) fit the pixels relatively well, which allowed us to adapt it to this competition. It features a pincer grip articulated by a single servo between 2 carbon fiber plates. There are also custom Ninjaflex squinches on the pincers to allow for better gripping. Since we wanted to implement a transfer strategy, we gave the gripper limited mobility, allowing it to only pick up 1-2 pixels from the ground and then lift them for transfer.



The Scoopagon/Transfer System

In order to limit the need for our robot to turn in order to pick up pixels and deposit them on the backdrop, we implemented a basic transfer system into our Ri2D. The primary mechanism that deposits the pixel is an arm with a pixel holder built out of tape and polycarbonate, which we call the “Scoopagon”(it scoops the pixel up and is shaped like a hexagon). The gripper flips up and drops the 1-2 pixels into the Scoopagon during the transfer. This allows us to reduce cycle time by reducing the amount of driving we have to complete; however, sometimes pixels can get stuck on the edges of the Scoopagan or get tangled with other parts of the robot.



Scoring System

In order to score the pixels, our Ri2D uses the Scoopagon in combination with a rotatable arm and extendable linear slide. The Scoopagon is mounted on an arm that can be rotated by a servo, creating a “catapult-like” motion. The entire servo and arm assembly is then placed on a linear slide that can extend out to allow us to place pixels higher on the backdrop and from farther away. One potential issue with our implementation is that the arm may accidentally propel pixels, which is not allowed by the rules, so the arm must be close enough to ensure the pixels are placed onto the backboard.



Expansion Ideas and Limitations

Because of time constraints and the extended field assembly time, we could not attempt the drone and hanging aspects of the game. However, we found a hanging mechanism used by previous year’s robots(pictured below) that relies on tape measures. Due to the massive amount of weight imbalance, we were unable to attach it to our robot, but we hope to be able to test it out on future robots. As for limitations, the robot itself was very tough to drive due to the weight imbalance and general lack of driver practice, and the linear slide was poorly built and ended up being quite unreliable.



Overall, though, Ri2D served as a valuable learning opportunity for us, and we will be using everything we have learned over the past 2 days as we move forward into the season.

DPRG Meeting Presentations

By Aarav and Anuhya


Task: Share R2V2 and Ri2D with mentors at DPRG

Throughout this month, Iron Reign has been presenting its recent work at DPRG(Dallas Personal Robotics Group) meetings on Tuesday evenings. On August 22nd, Iron Reign presented our summer project, R2V2, to DPRG. We received lots of great feedback about improving and expanding our project, including vision-based object tracking to allow the RV to follow specific objects. You can watch a recording of that linked below:

Then, today, we presented our Robot in 2 Days and the Ri2D video we produced at the DPRG meeting. We discussed our design process, prototype, and general strategy for the match. We discussed the importance of communication on the playing field, possible origami techniques to incorporate into our drone, and deposit systems on the backdrop. Here is a recording of the presentation:

Thanks to DPRG for allowing us to present. Overall, meetings with DPRG are great opportunities to get feedback on our work, brainstorm new ideas, and practice presentation skills. We plan to meet with DPRG further into the season once we progress more on our competition Robot.

CenterStage Introductory Meeting & 9/16 Meeting Log

By Aarav, Anuhya, Krish, Tanvi, Sol, Alex, Vance, and Georgia


Task: Welcome Recruits to the Workshop and begin Robot Ideation



Today, Iron Reign hosted our introductory meeting for all new recruits at our workshop. We also began planning and brainstorming for our competition robot and potential subsystem ideas.

We had approximately 20 recruits in attendance, and we initially showed them the Center Stage reveal video and discussed potentially confusing aspects of this year’s game. We then talked about potential strategy while also sharing our Ri2D video. We tried to highlight the importance of building small and fast and decreasing cycle times and communication over more complicated designs. Lastly, we reviewed the main robotics subteams: build, cad/design, code, and the editorial team, along with logistical information about tournaments and the awards categories.



After, we split up the recruits into code and build teams and introduced them to the software/hardware used in FTC. Those interested in code were exposed to our repository structure, FTC Java syntax, and methods, and we were able to walk them through a basic program that makes a motor run. The build and design recruits started by learning about essential components such as motors, servos, control hubs, and REV rails, and we talked to them about basic building structure(how to connect nuts/bolts to rails), chain-breaking, control hub wiring, and the critical differences between motors and servos. Next week, we hope to be able to split them up based on previous experience into 2 teams and have them begin brainstorming, discussing strategy, and starting on assembling their robot chassis.



As for Iron Reign, we began with an ideation session with a whiteboard where we thought about chassis and gripper ideas. At this moment, we are leaning towards a mecanum-based chassis to allow for strafing, but we came up with various potential gripper ideas, from a beater bar to a box-shaped design. Finally, we came up with some ideas to allow our robot to suspend from the rigging, and we started working on CAD prototypes.



Next Steps:

The rookie teams will soon begin to split up into teams and start working on their robots. For Iron Reign, our next steps are to begin CADing a preliminary version of our robot and the requisite subsystems while also considering other ideas.

9/23/23 Meeting Log

By Aarav, Anuhya, Jai, Krish, Tanvi, Vance, and Alex


Task: Prepare R2V2 for Filming and begin Designing Subsystems

Today, Iron Reign had an extended meeting to focus on preparing R2V2 for video production and to start designing and testing robot ideas. We plan to produce a complete walkthrough of R2V2, with footage of the individual subsystems and the entire RV driving around autonomously. We were hoping to begin filming today, but we needed to repair both the Steering and Braking subsystems, which took some time.

We tightened the bungees on the Braking and increased the gear ratio of the motors from 15:1 to 120:1 to deal with the increased tension on the “foot” mechanism. We decreased the gear ratio on the Steering system to accommodate the increased ratio in Braking. Unfortunately, once all the planning for the shoot and subsystem adjustments were complete, we did not have enough time to film before the meeting “officially” started for all the recruits.

The recruits split into teams and started working on chassis for their robots, creating REV rail frames, and Iron Reign had multiple design meetings to create a clear plan for our competition robot.



We decided that for the first iteration of our robot, we would focus on a mecanum chassis to allow for a quick build and strafing capabilities. Anuhya began designing an assembly with a wheel and an integrated motor(sketch shown above). For the drone launching mechanism, Tanvi began creating and experimenting with a catapult-type system and designs for the drone itself(sketch shown below). Vance started to work on an intake system modeled after the Ringevator(our ring intake system from Ultimate Goal), and Krish began to manufacture a prototype for our hanging system.



Code-wise, Alex and Jai refactored the codebase and began working on integrating Roadrunner with our drivetrain and teaching the new coders some basics.

Next Steps:

We aim to have a functioning robot quite soon in preparation for the first qualifier so that we can begin coding. To do so, we will need to keep working on the various subsystems and starting to manufacture and iterate them. We will ramp up our connect and motivate efforts as the season progresses.

9/30/23 Meeting Log

By Aarav, Anuhya, Tanvi, Georgia, Vance, Krish, Jai, and Alex


Task: Start prototyping our robot

Today, Iron Reign continued working on designing and prototyping our robot in preparation for scrimmages and our initial meets. We began working on an intake system for the pixel stack, based on Ringevator, our 2019 intake system. It involves custom ninja-flex belts that grab the pixels and propel them to a collection point for further manipulation. We finished designing it in CAD and began 3D printing the belts and assembling the motor and belt subsystems needed to move the belt. The chassis and drone launcher are also still being designed.

On the code side, we continued working on coding the classes for our 2023 and dividing it into subsystems and classes to streamline it for us in the future once our robot has been designed.

Finally, we finished up preparation for shooting the R2V2 walkthrough and videos, which we plan to do tomorrow.

Solar Prep for Girls Recruitment

By Sol and Vance


Task: Recruit Future Members at Solar Preparatory for Girls



Today, Iron Reign members Sol and Vance represented Iron Reign at a recruiting event at Solar Prep for Girls in Dallas. This was an event to recruit new members for the program from middle school and recruit students to attend Townview next year. We had a booth set up with TauBot, our Power Play robot, which we showed off to the students. Overall, events like these are a great way to foster early interest in robotics and specifically FIRST/FTC, and ensure that we have a stream of new recruits coming in for when we graduate.



10/7/23 Meeting Log

By Aarav, Anuhya, Tanvi, Sol, Vance, and Jai


Assemble and Test our Pixel Intake System

Today, Iron Reign focused on turning our ideas and designs on CAD into real-life prototypes in preparation for our first scrimmage on October 28th. We began assembling our beater-bar intake system that relies on a custom ninja-flex belt with protrusions that bring in pixels from the ground and from the stack. The ninjaflex belts on the prototype are controlled by a motor and chain system, but when further refined, we intend to replace them with belts.



The subsystem is shaped like a triangle, with one large ninjaflex belt in the center and two secondary belts that feed into the main belt. The triangle shape allows for a wider range of intake locations for the pixel and more flexibility for our game strategy when intaking.

The entire beater system is intended to be placed on an intake tray to hold the pixels as they slide in. Our current prototype has a cardboard version, but we intend to manufacture a carbon fiber version for further iterations. Our goal is to use this new intake system with a redesigned version of the Scoopagon with a transfer system.



Next, we continued prototyping and designing multiple drone launching mechanisms, including a trebuchet-like mechanism and a slingshot release by a servo. We plan to test both these ideas and continue to design and test throughout the season to develop the mechanism that is the most accurate and consistent.

Next Steps:

We will finish assembling and testing the subsystem for the beater-bar intake system, then begin redesigning the Scoopagon to hold 2 pixels and attaching the intake to our prototype Robot in 2 Days chassis. Additionally, continuing to design the chassis and drone mechanism is required to be able to field a complete robot by the scrimmage. On the code side, we need to start working on creating pathways and sensing for auton and integrating the new subsystems into the Robot in 2 Days code. A completed prototype of the robot also allows us to engage with local mentors in the coming months to get feedback on our design.

Scrimmage Review

By Anuhya, Vance, Alex, Sol, Georgia, Krish, Tanvi, Jai, and Aarav


Task: Review our performance at the first scrimmage of the season



Earlier today, we had our first scrimmage at Woodrow Wilson! This was our first proper opportunity to interact with other teams and their robots this season and we got a chance to troubleshoot any design issues with our robot. We entered this scrimmage with our beater bar system in the vague shape of a triangle and a linear slide with a “scoopagon” as our outtake. Overall, because of a lack of driver practice, we experienced quite a few issues without our linear slide and beater bar system, but it was an incredible learning opportunity!

Play by Play

Match 1: 9 to 0 Win

Our auton wasn't enabled. We also had a bad servo configuration on our beater bar so we were essentially a “push bot” for this first match. After the autonomous period, when our drivers went to pick up their controllers, they noticed a driver station issue, rendering our robot useless for this match. We scored 0 points and our alliance partners scored the other 9 points.

Match 2: 13 to 16 Loss

Our auton wasn't enabled again because we thought it would cause our robot to crash. Our outtake wasn't working so we ended up using our beater bar to score. We managed to score two pixels but, because of a lack of driver practice and an unconventional and unplanned method of scoring, we knocked them off the backdrop into backstage. Instead of our initial plan of getting pixels from the pixel stacks, we took pixels from the wing. We wanted to take pixels from the pixel stacks because we wouldn't have to go diagonally through the opposing team's area but it wasn't possible because of the level of precision needed to score from the pixel stacks using a beater bar.

Match 3: 18 to 46 Loss

Once again, our auton wasn't enabled. We continued using our beater bar to score. We were able to score 2 pixels on the backdrop this time and we took pixels from the stacks like we had initially planned instead of from the wings. We got a lot more pixels but in the process of transferring them through our beater system, we ended up loosing quite a few of them. Our opponent got 30 points in the way of penalties, so they won. We haven't found the right balance in speeds for our beater bar's rotations, nor do we know how stiff the tabs should be. We need to do a lot more experimentation so the beater bar can be used properly to both retain pixels, take pixels from both the wings and pixel stacks and possibly score pixels on the randomization lines and the backdrop.

Match 4: 37 to 17 Win

Our auton still wasn't enabled but we had hopes we could get it to work before the next match. We continued using our beater bar to score, and we got 3 pixels on the backdrop and one backstage. By picking up pixels from the wings, we also got some level of precision with our beater bar and human player because we managed to successfully create a mosaic on the backdrop! This was our first mosaic of the season!

Match 5: 19 to 15 Loss

The highlight of the scrimmage was definitely the last match. Our auton was enabled but didn't end up working as we intended and we scored one pixel on the backdrop but we managed to drop it by hitting the backdrop with too hard a force.

Next Steps

One of the biggest issues we had throughout this meet was with our beater bar system. The “tray” we were using to keep the pixels moving through the beater bar is made out of MDF with a chiseled tip so it can lay flat against the mats. However, because of friction with the mats, it kept fraying, meaning it acted as a slight barrier for the pixels entering the beater bar. As soon as possible, we need to replace the MDF with both a thinner, more sturdy and frictionless material. Our outtake is also notoriously unreliable, especially because of how bad our servo configuration and wire management is. Our motor placement for extending the linear slide could also be improved. Overall, we want to work on improving this current iteration of our robot for now instead of completely changing our build.

Woodrow Scrimmage Presentations

By Aarav, Jai, Vance, Krish, Sol, Alex, Tanvi, Anuhya, and Georgia


Task: Share our Portfolio Advice and Summer Adventures with other Teams



Today, at the Woodrow Scrimmage, in addition to participating in mock inspections and matches, Iron Reign hosted two workshops for Scrimmage participants, one on constructing effective portfolios and another detailing our summer activities. These workshops were significant successes, with 25+ attendees in two sessions, each lasting 30-50 minutes.

The portfolio “how-to” guide involved us walking through our portfolio from last year, explaining major design/content decisions, and sharing a couple of tips and tricks along the way. Some key points we stressed were taking pictures, sorting portfolio sections by the 7 award categories, clearly showcasing the engineering-design process, and adding (at minimum) rudimentary drawings to enhance understanding. Because most of our attendees were from rookie teams, we also discussed the types of content that would work well in a rookie portfolio, such as talking about starting logistics, failed ideas, and experiences as a new team to FTC.



In the summer activities workshop, we talked about our summer project, R2V2, and the details behind its planning, creation, iteration, and eventual testing. We also noted the specific operational safety protocols we used, which can be found in an earlier blog post.

We want to thank the organizers of the Woodrow Scrimmage for allowing us to present. We love sharing our enthusiasm for robotics with other teams and inspiring them in the process. There will be a separate blog post detailing our performance at the Woodrow Scrimmage and our major takeaways.

AWS Solutions Architect Connect Meeting

By Aarav, Krish, Anuhya, Jai, Alex, and Georgia


Task: Get Advice from a AWS Solutions Architect



Today, 6 members of Iron Reign virtually connected with Bilal, an Amazon Web Services (AWS) Solutions Architect, in order to present our team and gain some valuable advice. As a Solution Architect, Bilial focuses on designing, setting up, and troubleshooting client-server solutions through the AWS infrastructure, which involves technical skills, teamwork, and a lot of problem-solving.

In our meeting with Bilal, we first talked about our team and the robots we build. We touched on team structure, our core team principles, and some of our recent successes. However, with Bilal’s knowledge of robotics, the Internet of Things(IoT), and work experience, we quickly moved on to discuss our recent projects and team struggles.

One central point of emphasis was our summer projects from the past 2 years: Mechavator and R2V2, which we spent a hefty amount of time discussing. These projects, in which we used REV hardware and FTC software to automate 2 modern vehicles, are heavily related to modern IoT practices in companies like AWS.



Additionally, we focused on our core team’s recent open-source work, where they contributed to the FTC Dashboard repository, adding features such as field transformations, expanded image and text handling, and a variable origin.

Finally, as a team, we brought up many of our shortcomings and points of improvement in hopes of gaining some advice. We identified a few key issues: a lack of cohesion between the build/design and code subteams (we often have serious time crunches around competition), poor time management, an absence of proper planning, and the need to transfer knowledge between seasons.

On these topics, Bilal gave some great advice. Regarding knowledge transfer, Bilial noted that this was also a significant issue at AWS since the technical landscape is constantly changing and information grows outdated quickly. He says even AWS internal documentation and blog posts can often be inundated. For us, he suggested we expand existing documentation and knowledge base, such as adding more blog posts, creating CAD walkthroughs/tutorials (AWS does a lot of digital panels and videos), and further engaging our vast alum network.

Moreover, on time management, Bilal mentioned the Kanban method and the tool Asana as pathways we could test. Finally, he suggested that to allow for greater coordination between build and code; we look at simulation services such as AWS Robomaker, which would allow code to get started earlier and could serve as a valuable addition to our documentation efforts.

Overall, though, thanks to Bilal for taking the time to meet with us. We had a great conversation and took away a lot of great feedback. We hope to meet with Bilal in the future and show him our CenterStage Robot!

League Meet 1 Review

By Anuhya, Vance, Sol, Georgia, Krish, Tanvi, Jai, and Aarav


Task: Review our performance at our first league meet!



Today was our first league meet, which means all our wins, losses, overall points and points gained in autonomous would count towards league tournament rankings. This was a good opportunity to see how we'd hold up against other robotics teams who all had the same amount of time to prepare for this season's game. Overall, it was a good experience and we were pleasantly surprised by our robot's capabilities as well as our luck!

Play by Play

Match 1: 26 to 10 Win

Our auton actually worked! Our robot's auton is designed to move the robot back slightly and deposit a pixel onto the middle randomization line. We scored 20 points for auton! The beater bar was slow to start, so we were at a bit of a disadvantage of our own creation, and the linear slide servo wire came out, meaning we had to rely on the beater bar for depositing our pixels. We ended up with one pixel backstage, and we parked during the end game but we were almost outside the field.

Match 2: 20 to 26 Loss

Our robot moved in auton but the beater bar didn't release the pixel. This was similar to an issue we were having at the scrimmage, where the beater bar wasn't able to get a good hold on the pixels. We scored one pixel using the beater bar but one issue we noticed was that the beater bar was getting stuck on the tape which demarcates the wings. This can be both problematic for our game because it can give the opposite team penalties and it also takes away from our ability to get pixels from the wings. We parked in end game. Some possible solutions we may look at to help with the tape issue is curving the edge of the tray of the beater bar or adding some frictionless tape so it doesn't catch as much.

Match 3: 15 to 39 Loss

Our robot, once again, moved in auton but didn't release the pixel. Immediately after auton, our robot's battery died so we couldn't move it at all. It was also a hindrance to our alliance team because it died right in front of the backdrop. We got some points from a penalty, but it was still a resounding loss. In many of our previous robotics' seasons, our robots' dying has been a major issue. As a team, we need to do a better job of ensuring that we have charged batteries available and the voltages are at the optimal amount for a fully functional robot.

Match 4: 14 to 28 Win

Our auton deployed properly but luck was not on our side; the pixel placement didn't match randomization. We scored 4 pixels on the backdrop, picking up the pixels from the wings and using our linear slide and scoopagon to score on the backdrop, but they didn't form a mosaic. In end game, both of the robots on our alliance parked!

Match 5: 54 to 60 Win

Our auton deployed properly and the pixel fell on the randomization line! Our alliance partners parked during the autonomous period as well. We scored five pixels on the backdrop but two of them got knocked off. During end game, both our alliance teams got parking! Pixels getting knocked off the backdrop are a recurring issue throughout our matches this season. We need more driver practice to make sure the scoopagon hits the backdrop with the correct amount of force to deploy the pixels but also doesn't knock off any pixels already on the backdrop. We also need a strategy to make mosaics instead of placing random pixels on the backdrop because mosaics get far more points.

Next Steps

Our outtake is still not as reliable as it could have been, especially because of the wire management and how wobbly our linear slide is overall. We have made clear progress from our scrimmage, where the outtake didn't work at all, to now, where the outtake works but isn't reliable, but there is still a lot more work to do. We've seen that our “scoopagon” is quite reliable and don't have any plans to change it at this moment, other than to secure our counterweight in a better way. We also know that using the vision pipeline is very possible for our autonomous and we want to implement that by the next league meet. We are also going to experiment with different materials for the tray of the beater bar, with it currently being a very thin sheet of aluminum.

League Meet 1 Post-Mortem

By Aarav, Krish, Jai, Sol, Tanvi, Alex, Vance, Georgia, and Anuhya


Task: Analyze our performance at our 1st League Meet

After Meet 1, Iron Reign met to discuss their performance as a team and make plans for the next month in preparation for Meet 2. Here are our takeaways and analysis, divided into strengths, weaknesses, threats, and opportunities.

Strengths:

• Our drive team communicated quite well, and we could score pixels very well and turn those points into match wins.
• A better auton performance than we expected. We only coded it for the middle region, but it consistently scored that. However, we were lucky with the region selection during this meet. Adding code for the two side zones is near the top of our to-do list right now.
• No hang-ups on the stage door while crossing the playing field. Our strategy this year involves building a robot shorter than the stage door so that we can freely transit across the center rigging, and during this meet, our robot was quite successful at that task.

Weaknesses:

• A mediocre gameplay robot that does not stand out innovation-wise. Generally speaking, this year's robot will not be super innovative compared to the previous year's robot. This means that we need to put effort into improving the gameplay capabilities of the robot to stand out.
• The outtake got stuck and missed the pickup location. Because of the tight spacing near the transfer point, our outtake would get stuck on wires and bungees around there and not reach all the way down, leading to failed transfers.
• Wire management limited our usage of the outtake. Often, when we extended the outtake, the wire connecting the servo at the end would get caught on the chassis and unplug, rendering us unable to score. We need to cable manage the entire robot and test to ensure nothing gets caught when the robot moves.
• Intake catching on tape/tiles. When we were picking up the robot on the wings, the front edge of the beater bar would get caught in the tape and not pick up the pixels. That is something we will have to experiment with and fix.
• Erratic movement and a lack of control sometimes led to us hitting the backdrop and descoring pixels. A better understanding of our scoring positions and outtake positions should help us avoid this.

Threats:

• Lack of organization. So far during the season, we have not communicated well between subteams and as a team in general. We must ensure everyone is on the same page and up-to-date on what is happening, especially across subteams.
• Careless placement of expensive parts. We often misplace motors and servos, and these costs increase over time. This ties into being more organized, both in our workspace and as a team.
• Only working on the robot at the Robodojo(not emphasizing design and portfolio). Editorial work, CAD, and code(to an extent) can be done off-site, and our ability to stay on schedule relies on us putting time outside our formal meetings.
• We have not thought about what we want our portfolio to look like or put much effort into our documentation efforts.
• We simply have not put much effort into finding and getting donations/sponsorships. We must focus on that to continue the program's sustainability and fund the parts we need for the new robot.

Opportunities and Next Steps:

• Seeking out mentorship and connect opportunities. Building relationships for the long-term. For example, we could have more meetings with DPRG.
• A new chassis for the next robot version with a potential 3-wheel drive.
• We have yet to tackle the lift or drone aspect. Getting designs underway for those and testing them on the robot to increase our point-scoring capability.
• We could experiment with a shortened linear slide and Scoopagon to solve some of our problems with a reliable transfer system. Also, adding a way for the robot to detect the backdrop for depositing pixels should allow us to automate the process and reduce our chance of descoring pixels.
• Expanding auton to all 3 regions and adding the yellow pixel
• Blending innovation and gameplay strength for future competitions
• More driver practice, which is something we have neglected in past seasons.

Explaining Drone Launcher V1

By Tanvi and Aarav


Task: Explain how we arrived at our current drone launcher design



The first iteration of the drone launcher is a simple servo-powered elastic launcher that is controlled like a switch. A linear slide has a servo mounted to the back end and a V-shaped nylon airplane holder is attached to surgical tubing which is attached to a zip tie held by the servo. The system is set on a linear slide, resulting in easy change of the amount of power being transferred to the plane. We opted for a compact drone design so it can easily be held by our airplane holder, which allows for a more consistent launch by reducing impact of draft. Hopefully, our final plane design will have very few open folds, resulting in minimal aerodynamic drag.

The Design Process

Our first step for creating the plane design was to look at multiple videos on YouTube explaining paper airplane design, in the hopes of getting some inspiration. Our initial thoughts for the trajectory of the airplane was that we wanted it to shoot out to the side, and basically make a U-turn so that it lands parallel to the lines of the landing zones. This way we would lower the chance of the plane flying past the scoring zones. However, as we looked more and more into the physics behind how airplanes work, we realized it wasn’t feasible. Our current plane design was achieved mostly through trial, error and research about lift, drag and thrust.



First, we figured we wanted our launcher to be spring-controlled. Our initial thoughts for the design were to use a holder and a spring that would be stretched and released to launch the plane, but springs are better at launching objects over a short distance and we wanted the plane to be pushed down a longer runway to reduce errors during launching. Next, we turned our attention to rubber bands as a launching medium. This would eventually lead to us using surgical tubing as our mode of tensioning.

Another initial design was a trebuchet-esque design, pictured below. This consisted of a base plate with a beam on a pivot. The beam would be controlled by servo and tension would be applied through surgical tubing. There would be adjustable axles at the stopping points. Additionally a “sling” would have to be constructed to cradle the airplane. Challenges with this design regarding how to keep the plane in an aerodynamic position and mounting.



Strategy

Our goal for the launcher was to be as straightforward as possible. During the endgame, the drone has to be launched from behind the truss to one of the three distinct launch areas. The launch area closest to the field is the area with the most points allotted. Due to this complication, the drone cannot be launched as far as possible. It must stay within a set distance. As a result of the adaptable design, the mechanism can be coded with a simple on-off type code and can be adjusted mechanically by hand (in tiny adjustments).

Next Steps

Over the course of the season, we expect to keep experimenting with models and shifting them to find the best one for us. Eventually, we hope to have a fully 3D-printed design. As our robot goes through iterations, so will the launcher!

League Meet 2 Play-By-Play

By Aarav, Krish, Jai, Sol, Tanvi, Alex, Vance, and Georgia


Task: Review our performance at our 2nd League Meet

Today, Iron Reign has its second league meet. It was, in general, a helpful experience and a great chance to compete with local teams. Overall, we went 3-3 and ended up ranked 9th due to our high tie-breaker points. Even though our record was slightly worse compared to the first meet, our robot performance was significantly worse, and multiple helpful alliances gave us our wins. Code bugs and poor packaging made the meet a significant struggle for us, leaving us with a lot of ground to make up during winter break. However, before we look at some of our takeaways, here’s a brief play-by-play of our matches.

Match 1: 118 to 15 Win

We ended up not running an auton due to reliability issues. Our alliance partner scored 30 in auton through a combination of placing the purple pixel in the randomized location, a pixel on the backdrop, and navigating backstage. During tele-op, we started slowly due to a long initialization cycle. Unfortunately, the axes on the field-oriented drive made the robot almost undrivable, and it took a good 45 seconds to cross the stage door. This was a recently added feature that had not been fully tested before the competition. When we reached backstage, the preloaded yellow pixel fell out of the Scoopagon, meaning we had to go all the way back to our wing to pick up a new set of pixels - costing us time. On the way across the stage door, we got caught on our alliance partner and yanked off their drone from their launcher. Despite this, our alliance partner performed well, cycling 2 pixels onto the backdrop and hanging from the rigging.

Match 2: 40 to 31 Loss

Auton successfully placed the purple pixel on the right tape based on our team element, albeit because of a somewhat favorable noise, but we took those. After the buzzer rang, we promptly switched modes, quickly crossed underneath the stage door, and cycled two pixels on the backdrop. However, our driver Krish had trouble maneuvering back through the rigging posts, an issue that could be fixed through driver automation in tele-op. We hurried back for parking in the endgame, but our opponent managed to hang from the rigging, which gave them the win.

Match 3: 38 to 48 Loss

During this match, our robot successfully scored the purple pixel in auton, and our partner parked backstage. We cycled 1 pixel onto the backdrop, but the messed up driving system, combined with a lack of communication during pixel intake, meant that’s all we were able to score. During the meet, we tried to solve the communication issue by creating a simple hand gesture system. Unfortunately, we ended up losing because of a penalty our alliance member incurred for interfering with the pixel stacks.

Match 4: 71 to 51 Loss

Before this match even started, we had struggles with initializing the robot and setting it up for match play. Because our outtake slide was not fully retracted, we also had issues complying with the sizing requirements, which took a bit of time to sort out. A comprehensive “pre-match checklist” that we adhere to could help fix this. In auton, we deposited the purple pixel properly; from there, things worsened. Because of a code bug in the transition between op-modes, we remained stationless for the final 2 minutes. We could not solve the code error during the meet, so this issue continued to hurt us. One potential reason for this was how many code changes we were making at meet, often at the very last minute, which left us unable to fully take the time to test out the changes.

Match 5: 30 to 34 Win

Here, we missed the auton pixel and fell victim to the same code bug that happened before, which left us static for all of teleop. We got very lucky as our alliance partner scored their drone and a couple of pixels, carrying us to victory(we scored no points in this match). We thought we had fixed the code bug during testing on the practice field, but we simply didn’t have enough time to verify that.

Match 6: 37 to 26 Win

In our final match, our auton remained consistent, but yet again, the code issue reared its ugly head. This meet was very much the tale of two halves. A sort of successful first 3 matches led to us pushing new code and build changes to get features such as the lift working, which eventually

We'll be posting another post with our post-mortem thoughts, takeaways, deeper analysis, and some plans for the future.

League Meet 2 Post-Mortem

By Aarav, Krish, Jai, Sol, Tanvi, Alex, Vance, Georgia, and Anuhya


Task: Analyze our performance at our 2nd League Meet

After our performance at Meet 2, Iron Reign sat down as a team and discussed what happened. Here’s an overview of our takeaways and next steps as a team, divided into our strengths, weaknesses, potential threats, and opportunities/next steps.

Strengths:

• Our autonomous scored the purple pixel consistently when set up correctly. This significantly helped us with the tiebreaker and is a significant reason for our high ranking.
• When it worked, the field-oriented drive was quite helpful and simplified things for the drivers.
• When the robot functioned in tele-op, we could consistently and accurately cycle pixels to the backdrop.

Weaknesses:

• The transition to Teleop was unreliable because of a code bug we could not fix during the meet. Late code changes near our queue-up period meant we could not properly test them, and because of this, we sat still in Teleop for the last 3 matches.
• Over the week of the meet, we burned through about 3-4 servos for the intake lift. We kept shattering their gearboxes through hazardous driving and not correctly setting up the robot. This isn’t sustainable, and we currently don’t have the budget to replace servos as they get destroyed.
• Our init cycle at the beginning was too long and held up a couple of our matches, and we needed to remain aware and properly reset our robot each time.
• Sizing remains a problem, mainly because we have little room for error. Even when our lift was slightly out, we failed to size and held up a match because of it. We need to focus more on sizing in the next iteration of the robot instead of being an afterthought until the night before a meet.
• When we traveled under the door, the Scoopagon ran the risk of getting caught under the door if it was not entirely down. A way to combat this would be to create a travel position for the Scoopagon that can be toggled when moving under the stage door.
• Wire management and the packaging of the robot are also issues with the current robot. The Scoopagon will often get stuck on the surgical tubing holding up the intake, the lift will de-spool, or wires will get caught on the chassis and unplug our servos. Issues like these end our matches, but we can fix this with a robot that is designed and visualized first.
• Finally, in general, we have been behind as a team, especially on CAD for the next version of the robot, and that means more people getting involved to support our design efforts so that we can have the next version of the robot by Meet 3.

Threats:

• Our slow progress on V2 of the robot due to a lack of design participation.
• There are fewer connection opportunities than in years before at this time.
• A lack of funding, especially with the need to build an entirely new robot and deal with broken servos.
• Becoming complacent with documentation and completing the portfolio at the very last minute.
• Not expanding our industry connections and using them to get advice on our robot design.

Opportunities and Next Steps:

• We were able to get the hanging mechanism functioning the week before the meet, but we could not get it working at the meet. Specifically, it needs more angled support bars, and the motor placement needs to be redone, as they keep messing up pixel transfer. However, it did serve as a proof-of-concept, and we can adapt the same concept to the lift for the next version of our robot.
• We could also experiment with a kinetic lift that uses the momentum of the robot instead of motors.
• Similarly, we had a drone launcher that could score points the week of the meet, but when we attached it to the lift mechanism, it conflicted with the outtake and was too heavy. However, the concept is a strong starting point for incorporating a drone launcher into the next version of the robot.
• The Scoopagon hinge currently wiggles and is not stable, so we need to replace it with a stronger material, such as carbon fiber.
• A second hinge to allow the outtake to tuck away in a position that doesn’t interfere with as many components.
• A new custom-designed chassis that is not built on rev rails and is lighter/faster will decrease our cycle times. It will also be designed with the complete robot in mind, helping deal with some of the packaging issues we have been facing.
• A swerve drive is an idea that we could implement later in the season for maneuverability.
• Adding the yellow pixel drop-off to our current autonomous routine
• Automating driver paths and the intake/outtake articulations to reduce errors caused by the driver
• Earlier and more consistent driver practice. This is important with a more straightforward game that requires robot performance.

UPDATE: We did find out what the code bug was that messed up a couple of our matches. It was an error in the transition between the autonomous state and the tele-op state.

Positioning Algorithms

By Jai and Alex


Task: Determine the robot’s position on the field with little to no error



With the rigging and the backdrops being introduced as huge obstacles to pathing this year, it’s absolutely crucial that the robot knows exactly where it is on the field. Because we have a Mecanum drivetrain, the included motor encoders slip too much for the fine-tuned pathing that we’d like to do. This year, we use as many sensors (sources of truth) as possible to localize and relocalize the robot.

Odometry Pods (Deadwheels)

There are three non-driven (“dead”) omni wheels on the bottom of our robot that serve as our first source of truth for position.

The parallel wheels serve as our sensors for front-back motion, and their difference in motion is used to calculate our heading. The perpendicular wheel at the center of our robot tells us how far/in what direction we’ve strafed. Because these act just like DC Motor encoders, they’re updated with the bulk updates roughly every loop, making them a good option for quick readings.

IMU

The IMU on the Control Hub isn’t subject to field conditions, wheel alignment or minor elevation changes, so we use it to update our heading every two seconds. This helps avoid any serious error buildup in our heading if the dead wheels aren’t positioned properly. The downside to the IMU is that it’s an I2C sensor, and polling I2C sensors adds a full 7ms to every loop, so periodic updates help us balance the value of the heading data coming in and the loop time to keep our robot running smoothly.

AprilTags

AprilTags are a new addition to the field this year, but we’ve been using them for years and have built up our own in-house detection and position estimation algorithms. AprilTags are unique in that they convey a coordinate grid in three-dimensional space that the camera can use to calculate its position relative to the tag.



Distance Sensors

We also use two REV distance sensors mounted to the back of our chassis. They provide us with a distance to the backdrop, and by using the difference in their values, we can get a pretty good sense of our heading. The challenge with these, however, is that, like the IMU, they’re super taxing on the Control Hub and hurt our loop times significantly, so we’ve had to dynamically enable them only when we’re close enough to the backdrop to get a good reading.

Meet Our Field Class

By Jai and Alex


Task: Explain how we map the field and use it in our code



A huge focus this season has been navigation; each scoring sequence spans the whole field: from the wing or stacks to the backdrop, and it’s crucial to make this happen as fast as possible to ensure high-scoring games. To do this, the robot needs deep knowledge of all of the components that make up the field.

Enter: The Field

Our field class is a 2D coordinate grid that lines up with our RoadRunner navigation coordinates. It’s made up of two types of components: locations & routes. Locations include our Zones, Subzones, and POIs.

The field's red, blue, and green colors demarcate our overarching Zones. Zones are the highest level of abstraction in our Field class and serve as higher-level flags for changes in robot behavior. Which zone the robot is in determines everything from what each button on the robot does to whether or not it’ll try to switch into autonomous driving during Tele-Op.

The crosshatched sections are our Subzones. Subzones serve as more concrete triggers for robot behaviors. For example, during autonomous navigation, our intake system automatically activates in the Wing Subzone and our drivetrain’s turning is severely dampened in the backdrop Subzone.

The circles in the diagram are our POIs. POIs are single points on the field that serve mainly as navigation targets; our robot is told to go to these locations, and the navigation method “succeeds” when it’s within a radius of one of those POIs. A good example of this occurs in our autonomous endgame: the circle in front of the rigging serves as the first navigation target for hang and the robot suspends itself on the rigging at the lower circle.

A combination of Zones, Subzones, and POIs play into our automation of every game, and our field class is crucial to our goal of automating the whole game.

League Meet 3 Play-By-Play

By Anuhya, Krish, Jai, Sol, Tanvi, Alex, Vance, and Georgia


Task: Review our performance at our 3rd League Meet

Today, Iron Reign had its third league meet. It was more successful than our last league meet, with more success with both the drone launcher and our autonomous code. Overall, we went 5-1 and ended up ranked 3rd due to our relatively high tie-breaker points. We ended up perfectly tying with the 2nd place team when it came to autonomous points, and we had a lower score than them for end-game. We saw huge improvements in driving from our previous league meets to this league meet, and learned many valuable lessons about being prepared for matches. However, before we look at some of our takeaways, here’s a brief play-by-play of our matches.

Match 1: 77 - 23 Win

We scored a 45 point auton this round, which is the highest we can score alone. We placed a purple pixel where it was supposed to go, but a bug that started happening with our auton so it could detect placement is that it starts spinning. This can lead to an issue because of how short the autonomous period is, but it wasn’t an issue here. We placed the yellow pixel on its appropriate location on the backdrop and then parked. Driving during the Tele-Op portion started out rocky and we hit the rigging a few times. We were also having issues working together with our alliance partner, as they ended up in front of the backdrop many times as we tried to score and they would be in the wings at the position we needed to be in. One of our wheels was also stuck in a pixel for the majority of the match, which is a problem that could easily have been avoided if we had side shields on the robot. Our alliance team got hung, resulting in our win.

Match 2: 88 - 102 Loss

We got a 28 point auton, where we placed the purple pixel correctly but the yellow pixel was on the wrong section of the backdrop. We also got parking. Our partner was a push bot but they could get the drone as well. We ended up getting a total of 6 pixels on the backdrop by the end of Tele-Op, and we got hang but couldn’t get the drone launched because the drone hit the rigging. Our opponent launched their drone, resulting in their win.

Match 3: 106 - 31 Win

Once again, we got a 28 point auton, where we placed the purple pixel correctly but the yellow pixel was on the wrong section of the backdrop. We also got parking. In this match, none of the other robots had an auton. During Tele-Op, we got a mosaic by placing an additional purple and green pixel. With the help of our alliance partner, Iron Core, we got 6 total pixels on the backdrop by the end of Tele-Op. By the end game, our drone had already fallen off, which was a great missed opportunity for points which remained throughout this entire league meet. The Skyhooks weren’t set up prior to the match, so they were already locked and we couldn’t hang. This showed us how much we need to have a pre-match checklist. We also got 30 points in penalties.

Match 4: 67 - 17 Win

We got a 6 point auton. The purple pixel missed the tape and the yellow pixel fell before it could reach the backdrop. We got parking, however. In Tele-Op, we knocked over the pixel stack so our alliance partner could pick up pixels from the ground. We scored a purple and green pixel in addition to a yellow pixel, resulting in a mosaic. The stage door broke as we went through the center because it was already bent and our robot hit the lowest part, resulting in it bending even further. While we were taking in new pixels, we dropped the drone. At the end of tTele-Op, we had a total of 4 pixels on the backdrop. In the end game, we hung but because our drone dislodged, we couldn’t score the drone. Our alliance partner got parking.

Match 5: 112 - 29 Win

We got a 26 point auton because we scored the purple pixel properly, but the robot dropped the yellow pixel because of the “spin sequence”, which ensures that we are pointing directly at the backdrop but takes too much time. We also got parking. In the Tele-Op portion, we hit the stage door but it didn’t mess us up too badly. Some traffic by the wings also slowed us down. We almost got a mosaic but there was a very small gap between two of the pixels, and all the pixels have to be perfectly touching to be a mosaic. We failed to try for a second mosaic even though there was time. We scored a total of 7 pixels on the backdrop, 1 on the backstage. In the end game, we scored the drone to get a full 30 points and we hung as well! This was our most successful drone launch of the league meet!

Match 6: 85 - 34 Win

We got a 25 point auton, with the purple pixel barely touching the tape. The robot did the “spin sequence” again, but timed out completely so the yellow pixel wasn’t dropped at all. We also got parking. In Tele-Op, we first scored the yellow pixel we couldn’t score because of the weird auton. One of our alliance partners also knocked one of our pixels off the backdrop. Placing one of the pixels resulted in a ricochet so we couldn’t score a mosaic. We had a total of 6 pixels on the backdrop by the end of teleop. In end game, we couldn't score a drone because the drone launcher wasn’t tensioned. This was the second match where we noticed this issue.

We'll be posting another post with our post-mortem thoughts, takeaways, deeper analysis, and some plans for the future.

League Meet 3 Post-Mortem

By Aarav, Krish, Jai, Sol, Tanvi, Alex, Vance, Georgia, and Anuhya


Task: Analyze our performance at our 3rd League Meet

After our performance at Meet 3, Iron Reign sat down as a team and discussed what happened. Here’s an overview of our takeaways and next steps as a team, divided into our strengths, weaknesses, opportunities, and potential threats.

Strengths:

• Pretty consistent robot performance as we went 5-1 and were able to score points in all 3 games stages
• Improved mosaic scoring
• More accurate when scoring pixels on the backdrop and when dropping pixels off during auton
• Good time management. Less last-minute code changes or queue delays

Weaknesses:

• Goofy, careless mistakes
  • Not loading drone for launch
  • Not setting up skyhooks
  • Not having a writtenm checklist to go over before match starts
  • Robot spinning around in auton
• Occassional mishap when placing pixels on the Backdrop
• Unreliable drone launcher. Only cleared the game walls once

Threats:

• Not having PPE V3 built or coded in time
• Less innovative design compared to older iron Reign robots
• Giving up on R2V2 and Mechavator videos
• Slacking and not getting portfolio done on time/rushing it the week before Tournament

Opportunities:

• Cleaning up our minor mistakes(ex. Pre-Match Checklist)
• Portfolio and Presentation
• Connect Meetings for Feedback
• Motivate Opporunities

Meeting with the Director of R&D at Hoya

By Tanvi, Aarav, Anuhya, Jai, and Alex


Task: Meet with the Director of R&D at HOYA



Today, Iron Reign met with the Director of R&D at HOYA ITC, Abhi Patnaik. This meeting was focused on discussing the team’s portfolio and materials usage. We presented our work and participated in a Q&A style period to receive feedback, including on our own presentation styles.

Takeaways

Portfolio

Overall, we lacked proper presentation practice and this was very evident during the meeting. We were advised to put more effort into practice beyond only our individual lines. When presenting we were often redundant in some of our vocabulary (ex. Carbon Fiber) which took away from the presentation by creating a monotonous tone. We were advised to make our wording more diverse. Similarly, we were advised to be less redundant in our content as we brought up events such as Ri2D too much. For more readability, we were encouraged to make our portfolio less “wordy” and include more labels on diagrams, because judges don’t have time to read paragraphs on each of the slides. Each of the presenting members received personal presenting advice such as avoiding the statement “if we had more time”, focusing on positives more than negatives during questions, being consistent in explanations, and more!

Materials

Throughout this season we have struggled with various material components of our robot, and implementing feedback we received was very helpful. We were advised to create a materials database for new members and consistently do stress analyses to reduce strain on our materials. Regarding our concern about string strength, we were encouraged to check string materials for reliability before using them, because we have such high quality materials everywhere else on our robot. We also discussed friction caused by carbon fiber and how to ensure our 3D printed parts also had less friction, possibly by changing the direction of the print on the topmost layer to align with the movement.

Meeting with the Director of the Dallas College STEM Institute

By Georgia, Anuhya, Sol, Aarav, Krish, Alex, and Jai


Task: Meet with the Dallas College STEM Institute



Today, we met with Dr. Jason Treadway, Director of the Dallas College STEM Institute and a former structural engineer. We virtually presented our progress throughout the season, demoed our robot, and shared our work on Mechavator and R2V2. From him, we received valuable feedback about our robot design and game strategy.

We started by detailing the CenterStage game and highlighted the point scoring opportunities that we focused on. Starting from our work at Robot in 2 Days, we talked about how we iterated our robot up to the current version, mentioning components like scoopagon, our intake pixinerator, and the skyhooks.

Dr. Treadway is a structuralist engineer, so much of the Q&A was about our engineering and material choice. We discussed the amount of stress placed on the robot(especially when he hung on the rigging), and he gave us advice on how to lessen this issue, such as reducing the weight of the robot. We showed him our design for a future iteration of our robot, which will be made of carbon fiber in order to reduce the size (and weight) of the robot, as well as adding stability. This feedback will be especially valuable for hanging, which puts a lot of weight on our robot.

Additionally, we talked about our outreach and motivate efforts with Dr. Treadaway and showed him our summer project, R2V2, and our efforts to automate it and revitalize it. We shared the railers we made and specifically focused on our efforts to incorporate object-tracking.



Overall, it was a very informative session and we thank Dr. Treadway for his time and advice.

U^2 Tournament Play-By-Play

By Aarav, Anuhya, Krish, Jai, Sol, Tanvi, Alex, Vance, and Georgia


Task: Review our performance at the U^2 Tournament



Today, Iron Reign competed in our U^2 League Tournament. We won Think 1 and Inspire 2, advancing us directly to the North Texas Regionals competition on February 24th. Although we could not get V3 of Purple Pixel Eater(our robot) built in time for this competition, we performed well on the field and in judging. But, there will be a post-mortem that goes into more detail about our analysis and identifies areas of improvement. For now, this post will focus on a summary of our judging efforts and matches.

Judging:

Unfortunately, we did not practice our presentation as much as we should have the week before the competition, but a late judging slot gave us time to practice beforehand. Overall, our judging session was pretty strong, but we struggled with rambling too much and talking too quickly. This led to our judges not understanding everything we said and not being able to ask all the questions they wanted. We still got a solid number of judging panels in the pit though.

Matches:

Match 1: 88 to 40 win

We scored a 45-point auton, placing both the purple and yellow pixels and parking in the backstage area. Then, at the start of teleop, we initially waited for our opposing alliance to move before scooping up the purple pixel placed in auton and scoring it next to the yellow pixel. Then, we cycled multiple yellow pixels but regularly conflicted with our alliance partner. However, while crossing the stage door, we dropped our drone, which would continue throughout the day. Overall, we scored 7 pixels and 1 mosaic in teleop. In endgame, we did not hang because one of the skyhooks twisted up too early because of incorrect tensioning, and we lost our drone, so we could not score that either. It was a comfortable win, and we also decided that if we were ever allied with a push bot again, they could knock pixel stacks down and bring us pixels to score.

Match 2: 66 to 17 win

In this match, auton ran properly, but we got caught on the team element, leading to us losing our position and not scoring anything. Our team element was too stiff and did not slide properly, which we must fix. On a positive note, our alliance partner did manage to park. Then, we lost significant time at the start of teleop initializing our robot before the outtake stopped working, most likely because of something with the servo or lift. We lost the drone again, and in endgame, we hung. Overall, it was a solid win, but our performance left a lot to be desired.

Match 3: 68 to 64 win

We correctly placed the purple pixel in auton but missed the yellow one. Throughout the match, we struggled with poor coordination and rushed driving. We constantly rammed into the walls and collided with the rigging, leading us to lose our drone again. During intake, poor pixel placement and rushed attempts ended with us not entirely securing pixels. Our alliance team also descored a couple of pixels, which was unfortunate. In endgame, we hung. Our drive team struggled in this match and was under constant pressure from our alliance team. We need more support and direction from our coach to help our driver Krish focus and not have to strategize himself. Luckily, we squeaked out a narrow win.

Match 4: 64 to 63 loss

In a poor display of game awareness, we forgot to load our drone before the match. This could easily be rectified with a pre-match checklist. In auton, we scored purple but missed the yellow pixel. We struggled with driving and coordinating with our alliance partner in this match. Throughout the match, opposing robots constantly blocked our wing, limiting us to scoring only 4 pixels in teleop. In endgame, we missed hang and could not launch the drone because we forgot to load it before the match. After the match, we went to contest the match and advocated for the referees to penalize our opposing team for blocking our access to the intake. After much discussion, our opponent was penalized 20 points(two minor penalties), which was not enough for us to win the match, as we lost 1 point. Throughout this match, we observed that our outtake was moving too fast(leading to missed pixels). We also saw how our lack of flexibility with intake positions(we could not pick up from pixel stacks) hurt us in a match scenario since the wing was blocked off.

Match 5: 94 to 94 tie

In auton, we scored both the purple and yellow pixels. However, in teleop, we got our intake stuck on the wing tape, which made it difficult to intake pixels. Despite this, we scored 1 green, 1 purple, and 2 white pixels(just shy of a mosaic). In endgame, because of time-wasting and our driver pressing the wrong button, we missed hang. This was a major mistake since the match ended in a tie, and hanging would have gotten us the win. Issues like this indicated the strategy oversights we consistently made during this tournament. By the end of the qualifying matches, we were ranked 4th, going 13-1-1.

Match 6: 73 to 66 win

We were selected by the 2nd seed(22008 RoboBison Knowledge) to join their alliance for the elimination matches. In the first semifinal match, our auton was delayed, and we scored nothing. In teleop, yet again, our drone was dislodged while we traveled through the stage door. We picked up a green pixel from the wing and went to score a mosaic with the pixels our alliance partner had placed. Even though one of the skyhooks was tensioned wrong in endgame, we still managed to hang. We won the match and went up 1-0 in the semifinals. However, our alliance partner broke a servo during this match, which meant they would be out for the next match.

Match 7: 26 to 64 loss

In the 2nd semifinal match, our auton did not sense the team prop and thus scored the pixel in the wrong position. At the beginning of teleop, our drive team accidentally started our auton, which led to us wasting time and banging into the rigging. During the match, our struggle continued as we kept missing pixels when intaking from the wing. Even in endgame, hang did not work, and we lost the drone again. Overall, this sloppy match allowed the opposing alliance to even things at 1-1.

Match 8: 123 to 114 win

In the final match of the semifinals, we were partnered with RoboBision Knowledge. We missed both pixels in auton and accidentally ran into our alliance partner. However, in teleop, we scored multiple pixels(even though we missed a mosaic) along with our partner. In endgame, we hung and managed to launch the drone but it did not clear the field wall. We won due to a clutch set bonus we gained during teleop, sending us to the finals.

Match 9: 255 to 100 loss

This match turned out to be a tough loss. Our auton did not detect the team prop again, and we could not keep up with our opponents' cycle times. We started 35 seconds late in teleop and got penalties for going into our opponent's backstage and knocking over a pixel stack. We didn't hang, and the drone fell off again. After this match, we were replaced by the 2nd pick in our alliance for the 2nd match, which we lost. Regardless, we were delighted with our robot performance, finishing as the 1st pick of the Finalist alliance, which advanced us to Semi-Regionals.

Pit Interviews

Throughout all the robot action, we received 4 pit interviews from the panels for Design, Innovate, Connect, and Motivate. We discussed our plans to rebuild our robot and why we were not at that stage yet. We also discussed our team's non-technical parts.

All of this culminated in us winning Inspire 2 and Think 1 at the awards ceremony, which sent us straight to the North Texas Regionals. This gives us 4 weeks to build PPE V3 and get it working to advance to UIL and State. Stay tuned for our post-mortem post detailing our analysis of this event and highlighting a few key takeaways.

U^2 Tournament Post-Mortem

By Aarav, Krish, Jai, Sol, Tanvi, Alex, Vance, Georgia, and Anuhya


Task: Analyze our performance at the U^2 Tournament

After we advanced to Regionals by winning Inspire 2, we sat down as a team and discussed our performance as a team. Although we advanced, we are not as far as we want, with PPE V3 not built. If we want to advance to State, we need to show up to Regionals with a fully-built V3 that hopefully works. With that being said, here’s an overview of our takeaways as a team, divided into our strengths, weaknesses, opportunities, and potential threats.

Strengths:

• Transfer between outtake and intake worked efficiently
• Strong pit interviews. Were able to engage the judges and cover our main points. Can still be improved
• Virtually no coding during the meet, which is a welcome change
• Implemented a driver checklist by the end, which should help us in the future
• Skyhooks displayed a surpising amount of reliability

Weaknesses:

• Dislodging of drone when we hit obstacles
• Difference in skyhook tensions (ex. Types of rubber bands) (get blue rubber bands!)
• Rushed portfolio(completed mainly during the week before)
• Lack of communication in presentations and a lack of practice
• Talking too fast in the presentation
• New team props did not have prior testing with the robot
• Subpar and inconsistent auton by our standards
• Starting auton/teleop multiple times, messing up field position and driver controls

Opportunities:

• New redesigned robot(PPE V3)
• More Fundraising/Connect/Outreach
• New organizational system in Clickup
• More driver practice
• Banners/Posters/Booth
• Less content in presentations so we can talk slower
• Distributed speaking topics
• More presentation prep(specifically for questions)

Threats:

• Falling behind on blog
• Time management
• Auton
• Not finishing PPE V3 in time

Next Steps

Get to work cutting and assembling PPE V3 and working through any design flaws. Start working on aotnomous teleop navigation in code and adapting to the new chassis. Documentation wise, we need to update both the portfolio and presentation, and work on connecting with local engineering professionals.

Meeting with the Stanford Salisburg Lab

By Aarav and Nalin


Task: Meet with the Salisbury Robotics Lab and discuss their work



Today, Iron Reign met with four members of the Salisbury Robotics Lab at Stanford University. During this meeting, we discussed project ideation and making the design process more efficient. One piece of advice we received was to split the design process into three parts: synthesis, analysis, and judgment. The synthesis portion is creating the model/design after initial ideation. The analysis portion is theoretically testing the design’s ability. The judgment portion is deliberating what needs to be changed in the design. In addition, they answered design questions we had from this season. Lastly, the members of the lab discussed their work in bio-robotics and remote surgery! Many of our team members are interested in biomedical engineering as a future career path, so this was a great opportunity to learn about the work being done in that field. We thank these mentors for taking the time to work with us!

Lessons We’ve Learned Switching from CAD to a Physical Model

By Anuhya, Sol, Krish, and Fernando


Task: Overview the issues with PPE V3 and the changes that need to be made.



This past weekend, we had our regional competition! We were incredibly fortunate to have gotten Inspire 3 and were the 5th advancements to the FTC Texas State Championship in a couple weeks! However, we went into Regionals with a robot we had barely finished building due to an incredibly long design season, and we had barely any robot game, except for our Skyhooks. There were also a lot of challenges that came up as we built our robot from machined parts. Here are some of the problems we noticed and steps we are going to take to fix them.

Intake (Pixinerator):

• The new robot is way too wide, the two main causes are 1. Intake width and 2. Electronic plate wiring(where the control & expansion hub are mounted)
• Solutions:
  1. We can narrow the intake because the current size is completely random (<3 pixels, >4 pixels) and it probably won’t have the worst repercussions
  2. Drivers may decide that the width isn’t an issue because of the new corner deflectors and we can continue using this iteration of the chassis
• Pixinerator is intaking unevenly (thinner carbon fiber plate isn’t as rigid as the 2 mm aluminum plate we were using initially, the side without servo power isn’t being pushed into the mat with enough force)
• Routing cables also needs to be improved, not enough space for a second servo because of how things were routed
• Solution: Use two intake servos as opposed to one so both sides of the Pixinerator will receive servo power

Outtake (Ralph):

• Ralph is getting caught on the surgical tubing used to assist Pixinerator
• Solutions:
1. Possibly move the surgical tubing to the inside of the nacelle (side wise) and attach to back plate
2. Create new attachment point for longer bolts which attach further back on the Pixinerator side plates so it doesn’t interact with the inside of the nacelles
• Many issues occurred with Crook moving while we were trying to outtake pixels(electrical problem, bad connection between the Crook servo) → we generally have wiring problems/power injection problems, need to be sorted out
• Hinges and Clamps (Joints)
  • The carbon fiber tube clamps allow sideways movement → too much wiggle (cf tubes are not held square towards robot)
  • Pillow blocks and how they accepted bearings also had a lot of wiggle
  • Solutions:
    1. Switch over to using bearing blocks as opposed to bearings
    2. Possibly moving the REV bearings to the inside of the pillow blocks to lock them in place
  • Nothing is retaining the axle on far side of pillow blocks (axles twisted and slid)
    • Solution: Switch to using locking hubs

Chassis:

• Support for cable management/cable runs was not properly considered by design team because of a time crunch
  • Hand-held drilling may be our only option
• LEDs
  • Back camera LEDs need a place to mount to as well as wiring and battery solutions
• Battery Compartment
  • Current battery compartment “door” doesn’t open fully because the back plate doesn’t have enough clearance
  • The hinge for the battery compartment is incorporated within a structural element which results in a very weak design
  • Solution: Redesign battery compartment door so it can open fully and is stronger

Dock:

• Dock flaps were interacting with Pixinerator when it is completely vertical
• The forward boundary for Ralph wasn’t effective in real life even though it looked like it was in CAD. It also doesn’ seem necessary because Ralph can bottom out by itself
  • Parallel alignment with Pixinerator can be done w just pins instead of forward wall
  • Either it retains pixels or the pixels will slide out of robot by way of dock so we won’t get penalized
• Passive dock roof doesn’t seem feasible → just too many problems :(
  • Solution: Possibly attach dock roof to inward facing inner nacelle walls, operated by micro/mini servos
  • Test high speed intake to see what kind of hand-held roof placement prevents pixel ricochet
• Bridge needs to be 8-10 mm lower because Scoopagon doesn’t get low enough to intake from pixel stacks
  • Solution: pacers can be printed which go between the L beams that connect the bridge and the inner nacelle walls
• Camera was too high: it could not see when scoopagon was up and could not interact when scoopagon came down
  • Solution: We need to redesign a front camera mount and possibly illuminate it

Drone Launch:

• Drone clamp is too weak, doesn’t stop the drone from being knocked off the robot by rigging or interaction with anoth
• Solution: Drone clamp should cover at least half of the drone, or double as a hangar for the drone - cover it completely
  • Physical prototype and test first

Skyhooks:

• Still having rubber band/tensioning issues but that’s more of a set-up thing, doesn’t necessarily need a design change
• Had to abandon the concept of the limit switches to detect when they're fully up due to having to manually drill holes to increase clearance of Skyhooks with Pixinerator side plates
• Mount the IMU

DPRG Presentation Review Meeting

By Aarav, Nalin, Anuhya, Elias, and Jai


Task: Meet with the DPRG and review our judging presentation



Today, Iron Reign mock-presented at the DPRG weekly meeting and received tons of valuable feedback. We went through our typical presentation for competition, albeit at a slightly slower pace (we took about 7 minutes as opposed to the traditional 5). After the presentation, we had a long review session where we went through the presentation again and all the DPRG members gave input on how the presentation could be improved.

Some of the major issues include unclear labeling on CAD models, slides with too much information, and a lack of pictures on certain slides. Major thanks to DPRG for helping us out in improving our presentation before we head off to the States.

2nd Meeting with the Director of R&D at HOYA

By Aarav, Anuhya, Sol, Krish, Jai, Elias, and Fernando




Today, we had our second meeting this season with the Director of R&D at Hoya, Abhi Patnaik. This past weekend, Mr. Patnaik was able to attend the North Texas Regional Championship, where he watched our robot and many others in action. Our meeting today mainly consisted of a Q&A session where Mr. Patnaik asked us questions about choices we made on our robot, why we made them and possible solutions to problems he saw at the tournament.

The first question Mr. Patnaik asked us was about our intake. At the tournament, even when the Pixinerator tank tread was moving, it wouldn’t intake pixels or would only intake pixels from the left side. However, we had already solved this problem by using two intake servos as opposed to one intake servo, because our issue was due to the bottom intake plate not pushing into the playing field with enough force. He also recommended sanding the tip of our intake plate down like a knife so it sits completely flat to the playing field as opposed to at an angle.

He then asked us questions about our outtake and how confident we were in its ability to score pixels. We told him that this iteration of outtake was an incredibly new addition to the robot, and we were confident in the previous iteration and Scoopagon, specifically, but the changes we made, such as adding a new passive hinge, the Twist, as well as two new actuated hinges, the Lift and Wrist, were so we would have increased reliability and be able to score from more angles. He told us to pay attention to be careful about the amount of jerk on Outtake, especially because there are a lot of vibrations when it takes in pixels and deposits them onto the backdrop.

Finally, Mr. Patnaik commended us on our use of carbon fiber because it’s great at shock absorption and is very sturdy, which was a problem we had discussed in our previous meeting.

Main Takeaways:

The most important things he said to work on were to make sure our intake actually works, whether that means ensuring the 2 servos work or switching back to a 2mm aluminum bottom plate. Organizing cable management will also be very important, ensuring that we’re using the minimum viable wire length instead of having a lot of extra length on wires. We also need to account for inertia in our outtake.

Meeting with a Program Management Director at Lockheed Martin

By Anuhya, Sol, Krish, Elias, Alex, Nalin, Fernando, and Aarav


Task: Meet with the a professional from Lockheed Martin for advice



On March 8th we had a meeting with Luis Sanoja, a Program Management Director of Precision Fires Development and Transformation at Lockheed Martin, with a mechanical focus. Our plan for this meeting was to introduce him to the CenterStage game and talk about particular strategies we have, as well as running through our engineering and code processes.

When running through our presentation, he was proud of us for showing our preliminary ideas because they showed we had a plan before moving forward and designing our actual robot. We also talked through our thought process of our intake and outtake, including why we have so many degrees of freedom.

We also talked through our code, including the number of sensors we have as well as how our navigation and pathing works. He was impressed about our robot performance when we don’t use too many sensors, especially because of our field-oriented drive.

Next Steps

Most of the notes we got were on our presentation. We were told to add labels on the ideation slide for more readability. On the diverter slide, we need to show diverter action, so we added a pixel. Similarly, to show twisting motion in the scoopagon, we added an indicator. We were told to update all the videos on intake to outtake so they no longer show v1 of the robot. We added the degrees of freedom to the “Ralph” slide and updated the desmos model in the slides. We were told to change the corner deflector to an overhead shot to make it more meaningful. We were advised to redo the transfer to show the path of the pixel, add pixel sensors, use the term relocalization more, indicate how many parts we make by making a slide which includes all our 3D printed and CNC’d parts, show mecanum location correction, and change the CAD of the drone launcher to a side view. Lastly, we were told to put a lot more work into the autonomous slide.

Support for the FTC State Championship

By Aarav and Anuhya




Iron Reign’s state bound! At NTX Regionals, we proudly got Inspire 3, and were the 5th advancement to FTC Texas UIL and the State Championship! With the State championship coming up in only a few weeks, we have a lot of work to do to get our robot up to par, including buying new parts and increasing our outreach efforts. New motors and servos are expensive, and we want to put more money into sustaining our program past just this season. However, we need your help and support to do so.

While we welcome donations any time of the year, they are especially appreciated as we prepare for this upcoming challenge. Any and all support is deeply appreciated, including warm wishes and DMs on our Instagram account. If you have any questions, feel free to reach out via email at ironreignrobotics@gmail.com or through our instagram, @team6832.

Thank you for all your support and we hope to see you cheering us on at FTC State and beyond!

Applying Forward/Inverse Kinematics to Score with PPE

By Elias and Alex


Task: Explain how we use kinematics to manipulate PixeLeviosa (our Outtake)



This year’s challenge led Iron Reign down a complex process of developing an efficient means of scoring, which involved the interaction between the intake and outtake. Currently, we are in the process of implementing Forward and Inverse Kinematics to find and alter the orientation of our outtake, known as PixeLeviosa.

Forward and Inverse kinematics both revolve around the part of a robot’s subsystem, known as the end-effector, which is essentially what the robot uses to score or achieve certain tasks (that being PPE’s scoopagon). The simple difference between forward and inverse kinematics is that forward is the method of find the end-effector’s position given the angles of each respective joint and using geometric principles to find its position from there, whereas inverse kinematics has you finding the angles of each joint given the position of the end-effector. Typically, one will use the methods and formulas derived from forward kinematics to then apply them for inverse kinematics.

For PPE, we use inverse kinematics to set PixeLeviosa’s orientation given a point in relation to the backdrop such that the outtake maneuvers itself for effective scoring and reducing cycle times. We hope to have this fully fleshed out by State!