Let's not do this!

Intrinsic Hazards and Safeties
Primary Safety
Backup Safety
Site Safety
Operational Safety

Intrinsic Hazards and Safeties

Intrinsic Hazards

It’s important to keep in mind that with a 3 to 4 ton class mini excavator we are dealing with forces that can crush and pull down trees, destroy structures and potentially end lives. There is no place for any lack of vigilance and caution for safely operating this machine.

Intrinsic Safety

The machine has two emergency stop controls and we employ them redundantly in fail-safe modes. The only intrinsic safety lies in the reliable slow motion of the machine. The engine will only be run at idle speed. Its normal ground travel speed is equivalent to a slow walk and it cannot move faster than an able bodied person can run. There are still cautions around this. Swinging the arm when extended can cover a lot of ground quickly. People need to maintain safe distances. Therefore, we have established Operational Safety and Site Safety protocols.

Primary Safety

The Primary Safety functions as a lock-out of the hydraulic pump. When the safety is engaged, no part of the excavator will move with the possible exception of a very slow sag of heavy components to the ground. For example, the bucket and arm may sag by a few millimeters per second if they were left off the ground.

The Primary Safety is constantly engaged by a rugged bungie. To disengage the safety (UnSafed – therefore hydraulics activated) a servo can actively hold the safety lever down.

Fail Safes

We can’t say it’s impossible for the control software stack to crash in a state where it continues to send a safety-disengage PWM position signal. We’ve never seen it happen and we believe it’s prevented by the interaction of the firmware and the app – but we can’t say it’s impossible. It’s also possible to imagine a freak condition where the servo gearbox breaks and locks up in the safety-disengaged position. So we decided to create a redundant backup safety.

Backup Safety

The Backup Safety uses similar fail-safe design principles as the Primary, but it is completely independent of the normal control system.

The Backup Safety is operated through an independent standard RC (digital radio control) transmitter and receiver.
• The Backup Safety kills the engine when it is Safety-Engaged.
• The Backup Safety is also normally pulled into its Safety-Engaged position by a tensioning system.
• To suppress/disengage the Backup Safety, a servo can hold the kill switch in the down position.
• The servo is configured as a deadman switch – the operator (a different operator than the Primary Safety operator) needs to continuously squeeze the throttle on the RC transmitter for the servo to remain in the Safety-Disengaged position. The throttle is spring loaded to return to Safety-Engaged.
• If the servo or loses power or browns out, the bungie will pull the safety back into the engaged position.
• If the RC receiver stops receiving active disengage commands from the transmitter, the safety will re-engage. This covers out-of-range conditions. It also applies when the transmitter is turned off.
• We specifically chose a digital servo that does NOT have a memory of the last good position signal. Some digital servos will continue to hold the last position they received if they continue to receive power. The servo we chose does not have this feature, so if the PWM position signal fails for any reason, but power remains on, the servo will fail to hold position and the safety will re-engage.
• All of the above have been tested

Site Safety

Site safety speaks to conditions of the site and surrounding properties that informs the risk to people and property.

The site is the backyard 3 acres of our coach’s residence and the primary structure on the site is the home itself (blue oval, below). The site slopes downhill fairly steeply from the back of the house to the creek that cuts all the way across the property at the bottom (right side in the image). The site is heavily forested with the exception of an open glade, a clearing for a future workshop, and a gravel driveway connecting them uphill to the main driveway for the residence.

The future workshop site (white oval) is the only area that the Mechavator will be allowed to operate in. The ground there is mostly loose soil but does have rocks, mounds and branches that should be treated as trip hazards. Team members need to be aware of the terrain at all times. We will refer to this area as the arena.

Operational Safety

Operational Safety consists of the training and protocols that will be followed to assure minimal risk to the participants.

• Mechavator will only be operated in the arena.
• Our coach will always be present and supervising operations. The machine may not be started without an OK by coach.
• There will be a minimum of two operators, a driver and a safety operator. The primary driver will operate either the arm or the chassis as well as the primary safety. The safety operator will operate the backup safety and is primarily responsible for nothing but safe operations of the vehicle.
• A secondary driver is required if the plan calls for operating the chassis and the arm at the same time.
• Every session will begin with a meeting to discuss all planned movements to be sure that everyone in the area knows what to expect as well as what could go wrong and to address specific safety concerns.

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.

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.

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.

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.

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.

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.

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.

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

Game Strategy

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.

Task: Design and Think about possible robot ideas after Ri2D

After Robot in 2 Days, we decided to brainstorm and create more robots to test out ideas. One of those preliminary robot ideas was TallBot. This design involved using linear slides to increase the robot's height in order to allow it to drive over the poles. However, as you can see in the video below, it was not structurally stable and often collapsed on itself. It's wires also easily unplugged, which is not ideal for competition scenarios. Embedded above is a video showing our initial testing of a prototype TallBot, and you will see exactly why we chose to scrap it. However, it did represent our effort to stretch outside the box, literally.

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.

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.

Screamage at Marcus High School Overview

Today, Iron Reign attended the Screamage at Marcus High School to play a couple of practice matches. This event allowed us the opportunity to better understand the game flow and further develop a strategy, finally get some drive practice, and point out any flaws in the robot and its design to help improve the next iteration of TauBot.

Initially, we were faced with a lot of structural issues regarding the build of the robot. The wire connection on the arm had to be properly secured to ensure that cables did not get tangled or caught whenever the crane extended, and minor modifications to the chassis were required to properly secure the LED Panels to the robot.

Then came the software troubleshooting. The robot struggled to properly drive without drifting and our drivers needed minor modifications to the mapping of the buttons to streamline gameplay. However, we were able to get tons of solid drive practice at the practice field and were able to consistently score multiple cones on all 3 levels of the poles by the end of the scrimmage. We also utilized our memory functions to help automate the pickup and drop-off process and taught our drivers how to best use those capabilities.

Then came the actual practice matches, and let's just say, they did not proceed as smoothly as expected. Our lack of drive practice was evident, as we often dropped cones short of the poles and were barely able to score successfully. At one point, we managed to pick up around 6-7 cones, but only succeeded in scoring 1-2 cones onto the actual pole. Evidently, this is something that will need to be addressed before the first league meet.

Robot reliability also proved to be a major concern and created a lot of issues during gameplay as our robot would often break down during the game, rendering it useless and incapable of doing anything. After ramming our robot into a junction during gameplay, part of the polycarb chassis cracked where the screws were attached to the Rev Rails, which also locked up our front set of Omni wheels that we used for stability. We managed to restore the robot to a usable state, but the cracked polycarbonate will remain until we build the new robot. These issues continued to plague our robot, and during a match, the axle holding up the crane dislodged from the motor mount, which caused the entire crane to shut down mid-match, and led to us replacing the axle and the screws used to secure it.

Next Steps

The first thing we need to do is shave off part of the arm so our robot will fit within the sizing cube. Secondly, we need to redesign the configuration of the LED panel and battery mount, bottom battery wire, and the arm wire holder, so the wires do not hinder the robot's movement and ability to perform. Thirdly, we must find a way to keep the left motor from slipping out of its mount. We also need to adjust the height of the front Omni wheels, using spacers to allow for more movement and prevent them from locking up. Finally, we need to add polycarb plates to the chassis to prevent furthur damage.

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.

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

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.

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.

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.

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.

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.

Task: Drive Practice and Improving Code

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!

April Tags

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

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.

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.

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.

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.

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.

Task: review the progression of matches in our latest League Meet

Team 6832, Iron Reign, and our sister teams, Iron Core and Iron Giant had our second league meet earlier today. Overall, it was a very good learning experience and we got to see the functional robots of many of the teams in our league in action. After observing many unique robots, we learned a lot about the differences in strategies between us and other teams and how we could use our differing strategies to work together in a cohesive alliance.

Play by Play

Match 1: Win

We got a total of 45 points, but we got a 20 point penalty for our human player placing a cone in the substation at the same time the robots were in the substation. In the autonomous section, Taubot's arm wrapped around the pole, which got stuck in the wires. We were unable to get a cone or parking. During driver control, we got 3 cones, and we got 1 cone with the beacon during the end game. Our robot scored 28 points by itself.

Analysis: During autonomous, our robot was overshooting while trying to place the cone, so it would get stuck around the pole.

Match 2: Win

We got a total of 88 points, but we got a 10 point penalty for our human player, once again. In the autonomous section, we were unable to get the cone, but the overshooting issue was resolved and we got the points for parking. During driver control, we got 4 cones, and we got 1 cone with the beacon during the end game. Our robot scored 53 points by itself.

Analysis: Our autonomous section needed to be tuned, and our drivers need more drive practice so the arm can be more reliable.

Match 3: Win

We got a total of 68 points, with no penalties. Our human player was incredible at telling the other team to not put their robot in the substation as she was placing cones. In the autonomous section, we scored a cone and got parking. This was the most we were capable of in autonomous. In driver control, we got 3 cones and we got another cone with the beacon in the end game. Our robot scored 53 points.

Analysis: We could have gotten more points during driver control if our gripper mount wasn't so loose and didn't need to be constantly tightened, and we needed more drive practice for more precision/reliability.

Match 4: Win

We got a total of 78 points, with no penalties. In the autonomous section, we scored a cone and got parking, once again. In driver control, we got 5 cones, and we got another cone with the beacon in the end game. We scored 63 points with our robot, which is the highest score we got individually the whole tournament.

Analysis: This match was the limit of both our autonomous and driver control, which means we need to push the limits and make the robot more efficient so more points are possible.

Match 5: Loss

We got a total score of 67 points, with no penalties. In the autonomous section, our robot couldn't score the cone, but we got parking. In driver control, we got 3 cones, but we didn't manage to get a cone with the beacon during the end game. We got a total score of 35 points with our robot.

Analysis: We need more driver practice and precision, because adjusting the arm slightly when it's fully extended is incredibly inaccurate as it has very high momentum. We also need to practice different strategies, specifically defense, and not get distracted from our strategy by the strategy of the opposing team. Our autonomous section also needed to be more reliable.

Post Mortem

Strengths:

• Not having to move the placement of the robot to score
• Flexibility - we can score across the field and change where we pick up our elements without interfering with our alliance's strategy or robot
• Human player - very good at telling teams not to move into box when she's placing things
• Communicating with alliance partners

Weaknesses:

• Robot is bad at making circuits due to design of the robot
• The big arm is too shaky to score quickly because of the weight
• Cycle time is too long

Opportunities:

• Doing some defensive play
• Scoring on multiple poles
• Adding a fourth extension stage by decreasing the weight of the already present rods
• Increasing the motor count to 5 on top of the turntable to support shoulder joint with more torque for the 4th stage of the arm

Threats:

• Letting the strategy of our alliance team interfere with our strategy
• Getting distracted by the opponent's strategy, limiting how well we can perform
• The cables of the robot getting tangled around itself or poles

Task: Improving code

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.

Hosting the Townview 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!

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.

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.

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!

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.

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.

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.

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.

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.

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.

Task: Discuss the events of our first tournament of the season

Team 6832, Iron Reign, and our sister teams, Iron Core and Iron Giant had our first tournament to qualify for Regionals or Semi Regionals. Overall, it was an incredible learning experience for our newer members. This was our first opportunity this year to talk to judges and leave a lasting impression with our presentation skills and our robot.

Strengths:

• The speed and success with which we replaced the gripper
• We won Inspire and 2nd place Think so our portfolio was definitely well constructed
• We did a good job of selling the team's story, its role in the larger ftc community, and how tau is the pinnacle of that story

Weaknesses:

• Less emphasis on outreach
• Distance sensor detected wire, messed with underarm
• Need new place to mount power switch to make room for underarm
• Coordinating with alliance partners
  • Collisions were avoidable, high scores more achievable
  • Have to get better at concisely explaining strategy, maybe with a short video
• Drive Practice: Not enough, excusable since it was a new robot, but not going forward
  • Time to train with multiple drivers for scoring patterns

Opportunities:

• UnderArm
• New Crane which can extend farther
• A more versatile gripper: Flipper Gripper
• Prioritize presentation for proper emphasis
• Mechavator reveal video
• Taubot Reveal Video
• Subsystems video
  • Linear slide video
• STEM Expo
• Better cable management
• Reliable UnderArm distance measurement - need ideas
  • Odometry wheels on linear slides
  • Encoder on a spring-powered retractable string (like the ones you would use for an id badge)
  • Tape measure with sensor to read numbers
• Using sensors for autonomous period and tele-op

Threats:

• Robot capability
  • Release the Flipper Gripper - we need to see the dynamics in action, it might not be viable
  • Flipper gripper damping - we need to try different friction materials
  • Bulb gripper wrist - we may need to do active wrist control, which needs to be figured out asap
  • Flipper Gripper elbow - we may need to do active elbow control, which needs to be figured out asap
  • New Crane/Shoulder/Turret - need to avvelerate the build
  • Crane bouncing needs to be fixed on the new system
  • New Crane wiring harness with distance sensor and 3 servos - can't wait for full custom board manufacturing - need prototype
  • New IMU for new Crane (ordered)
  • Nudge stick distance sensor - will it work over the ultra long cable?
  • UnderArm
    • Mount onto robot and get unfold and articulations right
    • Anti-collision code with Crane
    • Better distance sensing and control for chariot extension
    • May need wrist control for conestacks
  • Lasso gripper needs to be tested, might not be viable
    • Make an alternate gripper design for UnderArm, as a fail-over option
  • Sensors
  • Cone and Cone Stack detector
  • Junction pole detector
  • Differential Distance Sensor as alternative to vision
  • Team number labels if LED Panels get rejected
  • Huge amount of drive practice needed
• Team Composition - will onboarding new members at this time cause confusion and harm productivity?
• Teams
  • Technic Bots
  • Mark X
  • Technical Difficulties
• New sponsors and connect opportunities
• Prep
  • Poor battery planning
    • Missing a multimeter
    • LED panel batteries not charged
    • Batteries not properly labeled
    • LED Switch and battery not properly secure
    • Batteries need to be tested for internal resistance
  • Rank what would be best to talk about, so talk about what benefits our stationary robot
• Judging
  • Didn't have powerpoint up for initial judge motivate
  • More practice/preparation beforehand
  • Lack of presentation practice and timing(couldn't finish connect and motivate)
  • Don't oversaturate with information/gloss over other parts
  • Lack of people ready for judging panels
  • Lack of enthusiasm
  • Need Cart with display ready to go
  • Practice entering the room with the robot running
  • Practice in-judging Demo
  • Whenever we mention a specific part of subsystem, let judges interact with it
• Inspection
  • Capstones were too close to being out of sizing - reprint
  • Robot close to out of sizing (Inspector was young, careless, and did not thoroughly check sizing)
  • Missing power switch label and full initialization label (they let us replace it, it was fine)

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.

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.

Task: Motivate the community at the DISD Stem Expo

Today we hosted a booth at the Dallas ISD STEM Expo at the Kay Bailey Hutchinson Convention Center. There, we taught kids coding, introduced them to robotics and the FIRST community, and demonstrated TauBot to the public. Not to mention, we also got some decent driver practice in, which is always a plu. For the coding section, we used LEGO Mindstrosm EV3 Sumo robots to teach kids about block coding and spark interest in robotics and STEM in general. Overall it was a hit and a lot of kids enjoyed the activity.

At the Sumo Bot portion of our booth, we set a up table with laptops, Sumo EV3 robots, and two sumo rings. We taught kids basic block coding and allowed them to expirement with their code and see how the robots execute their code. They then got to use the robots in Sumo showdowns against each other.

Alongside our Sumo Robotics station we had an FTC competition field set up, in which we gave kids a demonstration of the Iron Reign, Iron Giant, and Iron Core robots. We allowed the kids to drive them and get firsthand experience with a robot, which they really enjoyed. We also answered a lot of questions about our robot, betterng both our understanding of the robot itself and our presentation skills, which will come in hand at Regionals.

Our team talked to both parents and children about how to get involved in the FIRST program, explaining how it works and the opportunities it creates, and why we love participating in the FIRST program. We talked about our experiences in robotics, joining the Iron Reign program, and shared personal stories about how we got into robotics. Not only did we share information about our own program, but also how to get into FLL, FTC, FRC, and other robotics programs based on their age and interests.

Overall, it was quite a rewarding experience and we got to interact with a lot of people of a lot of different ages. We also were able to connect with some professionals in a somewhat limited manner, but there will be a seperate blog post about that coming soon.

Task: Help the Sudie Academy FLL teams prep for Regionals

Today, Iron Reign attended a meeting with multiple local FLL teams from Sudie L Williams TAG Academy to help them practice their presentation for upcoming Regionals competition.

The three teams, 43326 The Tin Men, 46425 Electric Spuds, and 51997 Lithium Ions all advanced to the FLL Regional Competition that will be taking place this Saturday, 2/11. To help them prepare for this competition, we hosted a virtual session where they could practice their presentation and a few of our members could listen in and offer feedback.

Overall, the kids did a really good job, showing us not only their innovate project but effectively describing their robot and hitting all their talking points in regards to iteration and design. They also talked about their core values and how they managed to work efficiently as a team to complete all their objectives. Finally, they managed to do all this while also tying it back to the overall FLL theme of renewable energy.

However, their presentation still had some things they could iron out and improve on, and our members made sure to constructively point these out. The kids could definitely do a better job of spreading the speaking around, as we felt that occasionally one person would come to dominate the entire thing while the others just stood around silent. They also could prepare more for the core values questions that we asked that sometimes led to an awkward silence. Finally, with all the great technical knowledge the teams had about their robot and their project, we felt that they could do a better job integrating that with the purpose and impact that their project had.

Overall though, it was great helping out these FLL teams, and there are a lot of good things that they did that could serve as a takeaway for some of the new recruits that joined in our preparation for Regionals.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

FIRST Robotics is an incredible opportunity for kids of all ages to get involved in STEM! It starts with FIRST Lego League (FLL), which uses LEGO robots to teach kids the basics of robotics and STEM-based activities. FLL has 3 levels for different age ranges.

FIRST Lego League Discover: Grades PreK - 1: This is the introductory level of FLL, which introduces kids to robotics using LEGO® DUPLO® bricks.
FIRST Lego League Explore: Grades 2 - 4: This is the second level of FLL, which introduces kids to solving real-world problems using engineering and logical thinking skills.
FIRST Lego League Challenge: Grades 4 - 8: The third level of FLL is competitive, and teams of kids learn how to program and design a LEGO robot to navigate a robot game and engage with other teams.

For older kids, such as middle and high school students, they can participate in the FIRST Tech Challenge, or FTC, and FIRST Robotics Challenge, or FRC.

FIRST Tech Challenge: Grades 7 - 12: Students design, build, program and drive robots to navigate a robot game and beat their opponents. They learn important time management, problem solving and teamwork skills while participating in friendly competition. In FTC, they also uphold FIRST's core value, Gracious Professionalism, where kids learn how to compete but maintain good relationships with their opponents.

FIRST Robotics Challenge: Grades 9 - 12: Students work alongside engineering mentors to create robots under strict guidelines. FRC is meant to be similar to the real-world engineering environment, where students must find funding, resources and ideas by themselves, and create a robot which can compete in a difficult robot game against opponents.

What Steps Should I Take?

• Talk to your principal and PTA to see if your school has pre-existing robotics opportunities. If not, you can start a team yourself! You can create robotics opportunities within your school or community through FIRST! Click the following links to find out how to start an FLL team, FTC team or FRC team.
• Sign up to talk with coaches and other parents through the North Texas FLL google group
• For middle and high school students, sign up with the North Texas FTC google group

Today, Iron Reign presented at the 15th annual Frontiers of Flight Museum “Moon Day” celebration, meant to honor the anniversary of the first moon landing in 1969. There were around 1,150 attendees, many of whom were kids. There, we hosted demos of both TauBot and our sister team, Iron Giant’s competition robot, and engaged with child attendees in LEGO Mindstorms programming activities in order to promote STEM and FIRST.

We taught kids the basics of block programming as they coded the basic Mindstorms robot to fight in the round “Sumo” circle. They used a color sensor to detect the black tape and stay within the circle as they battled each other’s robots. Afterward, they could experiment with the software and use their creativity to code whatever functions they wanted. We also introduced FIRST to them and their parents, how they can get involved in organizations such as FLL, and information about Iron Reign. We assembled a guide on getting your child into FIRST and posted it to this blog, which we shared at the event.

Additionally, we set up an entire game field to demo our robots and allow attendees to drive around Iron Giant’s robot. Many kids enjoyed driving around, scoring cones, and watching TauBot’s transfer. Along the way, we answered questions about our robot design and implementation and were able to talk to many adults in related fields about our work.

Finally, we had CartBot and the air cannons, which drove around the Museum, bringing joy to guests’ faces. Participants could “feed” the canon and watch as a Coca-Cola can be launched. Everyone had lots of fun catching the cans and even driving CartBot themselves.

Overall, presenting the museum for Moon Day was a major success and extremely fulfilling. For all the Iron Reign members, giving back to the community and sharing our love for robotics is a significant part of why we do FTC, and we are grateful for the ability to do so on a yearly basis.

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.

Let's robotify this!

What if you took an RV, converted it into a mobile learning lab, and then turned that into a droid? What would you call it? We call it R2V2

Intrinsic Hazards and Safeties
Primary Safety
Backup Safety
Site Safety
Operational Safety

Intrinsic Hazards and Safeties

Intrinsic Hazards

It’s important to keep in mind that our mobile learning lab is based on a Class A motorhome chassis. As such it weighs on the order of 16 tons and represents a real danger with any kind of untrained operation. There is no place for any lack of vigilance and caution for safely operating this vehicle.

Intrinsic Safety

R2V2 has multiple emergency stop overrides and we employ them redundantly in fail-safe modes. The only intrinsic safety lies in the reliable slow motion of the vehicle with max speed under normal human control. The engine will only be run at idle speed and the PSO will only apply acceleration if needed to get the vehicle moving at a walking pace ground travel speed. The acceleration pedal is not automated. People in the test zone will still need to maintain safe distances. Therefore, we have established Operational Safety and Site Safety protocols.

Primary Safety Operator

The Primary Safety Operator (PSO) is our coach, who is the owner and operator of the vehicle and who will always be behind the wheel while the vehicle's engine is on. Only he has the authority to start the engine and operate the gear shifter. He also has the ability to physically override the primary brake and independently operate the parking brake. He is the only one able to apply any force to the accelerator via normal foot control. He is also able to kill power to the whole control system, thereby engaging passive braking and locking the steering.

Remote Safety Operator

The remote safety operator will be a student trained and solely assigned the task of the ensuring safe operations from the outside. Their mandate is to stop the vehicle if they see anything wrong. Their interface is a normal gamepad where they have only two controls, either of which will stop the vehicle. The left trigger is configured as a deadman switch and has to be held in order for unbraking (and therefore motion) to happen. They can also press the red button on the gamepad to stop the opmode, thus idling the unbrake.

Remote Driver

The remote driver also has access to a kill button on their gamepad. They are responsible for starting and stopping automation by controlling the opmode. They can engage in remote steering or enabling automated steering, and can unbrake the vehicle, thereby allowing overrideable movement.

Fail Safes

We can’t say it’s impossible for the control software stack to crash in a state where it continues to send a safety-disengage PWM position signal. We’ve never seen it happen and we believe it’s prevented by the interaction of the firmware and the app – but we can’t say it’s impossible. It’s also possible to imagine a freak condition where the servo gearbox breaks and locks up in the safety-disengaged position. So we decided to create a redundant backup safety.

Site Safety

Site safety speaks to conditions of the site and surrounding properties that informs the risk to people and property.

The site is the backyard 3 acres of our coach’s residence and the primary structure on the site is the home itself (blue oval, below). The site slopes downhill fairly steeply from the back of the house to the creek that cuts all the way across the property at the bottom (right side in the image). The site is heavily forested with the exception of an open glade, a clearing for a future workshop, and a gravel driveway connecting them uphill to the main driveway for the residence.

The future workshop site (white oval) is the only area that the R2V2 will be allowed to operate in. The ground there is mostly level and compacted. Still, team members need to keep this area clear of possible stumbling hazards. We will refer to this area as the arena.

Operational Safety

Operational Safety consists of the training and protocols that will be followed to assure minimal risk to the participants.

• R2V2 will only be operated on a closed course like the arena. Closed means that we have good control and awareness of all souls on a private course and no other vehicles are moving.
• Our coach will always be present and supervising operations. The vehicle will only be started by coach.
• There will be a minimum of three operators, the Primary Safety Operator, a Remote Safety Operator and a Remote Driver. These roles were defined above.
• Additional spotters will be able to call out safety concerns by issuing a Halt call and hand signal.
• Every session will begin with a meeting to discuss all planned movements to be sure that everyone in the area knows what to expect as well as what could go wrong and to address specific safety concerns.
• While we may use "movie magic" to make it appear otherwise, no participant will be allowed to approach closer than 25ft to the path of the (slowly) moving vehicle
• The vehicle will be kept to a maximum speed of about 5mph (jogging speed) when under automation

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.

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.

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.

Task: Update FTC Dashboard to better suit our needs

During our PowerPlay season, we used FTC Dashboard extensively. However, because of some suboptimal code and some limitations of the platform, we were unable to use it to its full potential, especially in regard to the Field View component. We contributed to the repository with some quality-of-life changes that impact the hundreds of FTC teams that use Dashboard.

What is Dashboard?

FTC Dashboard is an open-source repository at https://github.com/acmerobotics/ftc-dashboard. It’s a tool that creates a webserver on your Control Hub and opens up a port that any web browser can connect to. Once it’s up and running, you can use it to visualize telemetry with plots and graphs, edit configuration variables, view feed from the camera, run op modes, and visualize your robot in the context of the field, all live.

Why’d we change it?

During our PowerPlay season, we had conflicting origins used by FTC Dashboard’s field visualization, RoadRunner, and our native pathing solution, which led to headaches and near-impossible navigation debugging. This season, we’ve committed fully to RoadRunner’s navigation system, but the lack of flexible origin and origin heading in the field visualization component was a hurdle for our development.

Because of this, we set out to implement a setTranslation() function to make development with dashboard much more flexible. It was a bit more ambitious than we’d initially thought, though, and we needed to speak to the original author, Ryan Brott, to truly understand the inner workings of dashboard.

Once we got setOrigin() working, however, we understood the true potential of this field visualization tool. We implemented support for image drawing, text drawing, scaling, transparency changes, editing the grid lines, and more.

Next Steps

Ultimately, we’ve succeeded in making an incredibly useful tool even more useful, and many of these changes are incredibly convenient for tons of our fellow FTC teams. We also always love the opportunity to give back to the community and contribute to the libraries that are lifesavers for teams like us. We’re looking forward to making more open-source contributions to make FTC more accessible for everyone.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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!

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.

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.

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!

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.

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.

Task: Give portfolio tips to 9161 Overload

Today, Iron Reign held a portfolio workshop for team 9161 Overload from Aledo, TX. During this meeting, we presented our old Power Play portfolio page-by-page and relayed advice we have from our past experiences and meetings with professionals. We emphasized the importance of the balance between readability and detail along with formatting. We have learned that word usage and the layout of pages can impact how the content is relayed to the reader so we made sure to discuss with the team. Lastly, we participated in a Q&A session to answer all the questions the team had.Thanks to 9161 for letting us work with them!

Task: Help the Sudie L. Williams Academy FLL teams

Today we met with four FLL teams at Sudie L. Williams TAG Academy: the Code-iators (11978), Mechanical Mammoths (43326), Robotic Robloxians (51977), and the Artsy Armadillos (46872).

We split up and had each team give a mock portfolio presentation to us as if we were judges. This not only let us help these FLL teams work on and improve their presentation skills, and give them feedback to further improve their presentation content, but also let us observe presentations to see how we could improve upon our own.

We gave feedback on four categories: Research, Robot Game, Robot Design, and Core Values. After each section presentation, we would ask questions pertaining to the section. For example, for robot design, we might ask “Explain the most Innovative part of your robot and code” if they haven't already answered it. We took notes on how well they answered the question, and anything interesting in their answer.

After we had asked our questions and finished judging, we went to give individual feedback to each of the teams we met with. The first part of this process was asking the teams what they wanted feedback on. Surprisingly enough, the teams had a good understanding of what they needed help with and asked some pretty insightful questions. Luckily, a lot of FLL portfolio knowledge applies to FTC, and we were able to answer their questions thoroughly.

Next, we worked through a judging rubric with the teams, giving them scores, explaining why they earned that score, and explaining what they might be able to work on to raise each score.

Additionally, we talked with the teams about FTC and Iron Reign, and answered their questions and any questions coaches/parents had.

Overall, we had a great time helping these four teams, and we can't wait to meet with them again!

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.

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.

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.

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

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.

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.

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.

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.

Task: Help the Sudie L. Williams Academy FLL teams

Today, 3 Iron Reign team members met with three Sudie L. Williams FLL teams to provide feedback on the presentation. Each member was assigned a team to guide throughout the meeting. The teams were Code-iators (11978), Robotic Robloxians (51977), and Mechanical Mammoths (43326).

We focused our feedback on 4 major categories: research, robot game, robot design, and core values. Each team decided which presentation to show us and we acted as mock judges to create a realistic atmosphere. We were each given judging rubrics to note growth points, which we shared with the teams for their future use. This was great preparation for their upcoming meet. The teams did a wonderful job and their dedication to FLL was very clear! Their presentations/projects were very creative and on theme. We did notice a few things the teams could work on, such as making more eye contact and being more familiar with their scripts. To help out with this, we encouraged the kids to understand the gist of their lines more than the exact wording so that they can relay the content without getting caught up with the specifics of the script. After we provided feedback for their presentations, many members of the FLL teams asked us individual questions regarding future FIRST opportunities in FTC. We were able to share our experiences and encouraged them to join an FTC team in the future.

Overall, major thanks to the Sudie Academy for allowing us to help out and we wish their FLL teams the best for their upcoming tournament. We had a fantastic time and look forward to meeting with them in the future!

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!

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

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.

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.

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.

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!

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!

On Thursday, June 13, our robotics team presented a Girls in Robotics presentation to Code/Art. Code/Art is a non-profit organization that introduces young women from underrepresented backgrounds to STEM. They specialize in teaching programming using art, such as Processing. We started the meeting by discussing robotics as a whole, along with our roles on our team. We emphasized the skills we have gained, such as programming, engineering, documentation, marketing, outreach, and design. Going into depth on each skill, we explained how to start coding with block coding, the FTC game format(autonomous, driver-controlled, and end game), how to ideate designs, how to start with tinkerCAD, and the importance of documentation.

Since many of the students were new to robotics, we explained these skills in the context of FIRST Robotics. We showed the students our robot and explained last year’s challenge. We also discussed the importance of marketing and outreach in FIRST as it allows us to get funding, sponsorships, and meet professionals. Furthermore, we explained how meeting with professionals in the industry allows us to expand our knowledge and receive feedback on our robots.

Overall, we discussed the comprehensive engineering process, including ideation, problem solving, development and much more. The students had lots of questions which we answered and were very interested in FIRST robotics.

We will be hosting more meetings in the future to increase awareness of FIRST Robotics!

This past Saturday, we had a very fulfilling day at the 16th annual Moonday, honoring the anniversary of the first moon landing in 1969, hosted by the Frontiers of Flight Museum in Dallas. There were approximately 1,150 attendees, primarily kids, who we introduced to robotics concepts like programming and designing. We were joined by team 7172, Technical Difficulties, who demonstrated their robots from Center Stage and Freight Frenzy.

We had 5 main stations we were presenting this year: our Hovercraft, our Air Cannon, our past season robots, Lego Sumo Robots and 3D printers.

We designed a hovercraft out of trash bags, a large circular piece cut out of plywood, copious amounts of duct tape, plastic and foam tubes and an industrial leaf blower. Kids were allowed to sit on our hovercraft and were guided around using a small rod, acting like a small carnival ride. They had a lot of fun feeling like they were floating on the hovercraft, and we learned a lot about being patient, especially when the kids weren’t listening to what we were telling them.

We also had an air cannon, which could “suck in” coke cans and then throw them out. Everyone enjoyed trying to aim the air cannon and then dodge the coke cans that came flying, and it became a game we all played.

We taught kids how to do simple block coding on Lego Sumo robots, where they learned how to use color sensors and how to detect whether the robot was on black ground or white ground. We taught them how to make the robots “fight” on the robot platforms, and they learned how motor functions can change how the robot moves and how adding wait times and loops can change how long the robot runs and what the robot can do automatically.

One of our most popular stations were the 3D printers. We taught the kids how to use a basic CAD software called SketchUp, where they learned how to make small keychains with their names on them. They learned how to create a sketch, how to extrude patterns, how to add text to their patterns, and they also watched us troubleshoot when problems arose on the 3D printers. They got to take their keychains home, and we ended up talking to a lot of parents about affordable 3D printer options and how they could keep teaching their kids about engineering.

We got a lot of questions about how parents could get their kids involved in more STEM activities, so we were able to introduce many of them to the FLL and FIRST community overall. We talked to them about starting their own FLL teams and talking to their school teachers about sponsoring robotics teams.

Overall, presenting at Moonday was a huge success and an amazing opportunity, because it’s incredible to interact with the community from which we get a lot of support. We also get to share FIRST with other kids, and hopefully they’ll grow to love the program from FLL to FTC, the way many of our members have.

These past three days, we hosted a Robotics camp focused on CAD and coding Lego Sumo robots at Kinwest Montessori, a school in Irving.

We introduced them to basic block coding with Lego Sumo robots. They started step-by-step by figuring out how the motors made the wheels move and messing around to make the robot move in circles and squares. They then moved to understanding the color sensor and how light refraction works, and eventually they learned how to battle on the sumo fields, where they would lose if they were pushed out of the white lines. For the kids who wanted more of a challenge, they attempted to write line following code, where the robot had to stay on a black line which had twists and turns on the path.

On the CAD side of things, kids started with creating simple circle keychains with their names on it and eventually progressed to creating designs like dinosaurs and unicorns. Some of their keychains also had sweet messages like “get well soon”s for their sick siblings or presents for their families. For the kids who got the hang of the beginner software we were using, called SketchUp, they progressed to designing on Fusion.

Next Steps:

We had an amazing time at Kinwest, which was one of our alma maters. It was incredible, watching these kids figure out how to code and CAD in real time, and they had so much fun seeing what we do. We are so glad we got to establish this relationship with Kinwest, and a huge thank you to them for letting us host their robotics camp there and create such good friendships with their kids.

On August 6th, we presented to Code/Art. Code/Art is a non-profit organization that introduces young women from underrepresented backgrounds to STEM. They specialize in teaching programming using art, such as Processing. Specifically, we presented to their “Virtual Creative Coding Camp” which had 2 teachers and 12 students. Initially, we presented our team and explained the various roles on the team. We discussed roles in code, design, build, drive, and portfolio team. Along with the roles we discussed skills acquired through robotics such as CAD proficiency, documentation, and marketing. Skill by skill we explained how to get started.

Programming-wise, we introduced the students to block coding, as it is a great starting point. We also showed the students uses of programming and explained its use in FIRST, specifically during the autonomous period.

Engineering-wise, we explained the process of development: brainstorming, prototyping and ideation. We told the students how to get started in design, by starting out with TinkerCAD. We explained the importance of design in an engineering environment and the benefits of CADing mechanisms prior to building them.

Documentation-wise, we discussed the use of an engineering journal and the importance of keeping track of problems, solutions, ideas, and progression.

Marketing and outreach-wise, we mentioned how these skills help us find funding, apply for grants, find sponsorship, and develop professional writing skills. We also discussed how we were able to meet with professionals throughout the field through our outreach skills. We also explained how meeting with these professionals allowed us to further our knowledge and skills.

Lastly, we ended the meeting with a Q&A portion. The students asked us about our favorite parts of robotics, how to build robots at home, projects we have done, and how to start out in FIRST robotics.We were able to introduce the children to FIRST and robotics in general, which was an incredibly fulfilling experience.

This past Saturday, we presented at the 10th annual Flyset Workshop, hosted by team 8565, TechnicBots and UTD.

We were given the opportunity to watch many interesting presentations from other teams around Texas and the country, including a presentation on Kalman Filters from team Area 52 and the KISS design process from Terrabats. We also presented about the thought process behind our engineering portfolios and presentations, as well as some experiments we've conducted this summer!

How to Portfolio: the Iron Reign Way.

Our portfolio presentation featured our main goals when we draft our engineering portfolios. We started with giving general advice, like organizing the pages on the portfolio by award (Innovate, Motivate, etc.) as well as colorcoding pages to make it easier for judges to flip through and understand content. We then showed them our portfolio from last season while passing around a physical version of the portfolio for them to physically see. We went through the details in our portfolio, including color choices, why we chose handdrawn diagrams, and our font size choices and bullet choices.

Summer Studies

Our summer studies presentation included 3 main projects: InchWyrm, SimplySwerve, and HoverCraft.

InchWyrm was one of our member's deep dive into the robotics application of a spine, and they spent the summer researching different ways to develop a subsystem which functioned similarly to a spine. They ended up recycling field elements from past years (the yellow poles from PowerPlay) and adding TPU plugs to create a spine, which could be operated using winding string.

We also developed a swerve module off robot which we could eventually put into use during the season. Our swerve module consists of a motor, servo, and a belt drive which controls the rotation of the wheel, while the motor powers the actual rotation of the wheel.

The HoverCraft was our shot at letting our mentors childhood dream of having a hovering bean bag chair come to life. While we didn't quite manage that, we did design a plywood platform which can “hover” using air pressure from a leafblower and be very fun to ride.

Next Steps:

As the season reveal is coming very soon, we are going to keep innovating our summer projects until we can use them on our actual game robots! We want to implement the swerve on our robot, no questions asked, but we still need to see how much load the spine mechanism can bear, and will continue testing until we are able to prototype our first game robot.

Yesterday, we hosted our first interest meeting! We were able to introduce a lot of kids to robotics, and got a lot of new recruits who had no experience as well as recruits who have done VEX, FTC and FLL before. We're very excited about our new season and sharing robotics with kids who will be able to keep the legacy of Iron Reign ongoing!

We talked to them about what we do as a team and gave them a quick overview of FTC: outreach, connecting with engineers, designing and building robots, programming and documentation. We then talked about Iron Reign values: innovation and (over)engineering. We gave them a rundown of the expectations for joining this team, as well as what commitment to a robotics team could look like.

A lot of them were very interested in the customizability of our robots. We presented PPE and Taubot, from the CenterStage and PowerPlay seasons, and they were fascinated by the carbon fiber on our robot and wanted to know how many of the robot parts we made ourselves. We elaborated on one of the best aspects of FTC: the amount of freedom and creativity you get with building robots. We don't just rely on kits, we have the ability to design our own parts and learn skills like CNCing and 3D printing.

We can't wait to teach these kids, who will be joining our junior varsity teams, all we know about robotics, starting with basic code on OnBot Java to Android Studio, but also things like teamwork, conflict resolution and time management!

Robot in two days (Ri2D) is an ideation process Iron Reign goes through to explore the new seasons and brainstorm designs and ideas for the game. One key aspect of this year's robot in two days was the chassis. A part of the chassis included was the system too ascent onto the first level, so we repurposed the Skyhooks from last year's Center Stage season to do so. The skyhooks rely on a custom ratchet latch to hook onto the rung and lift the robot up. They are tensioned by a bungee and their height is adjusted by a spooled string. Thinking about the high ascent, since the rules only prevent touching the high rung while touching the ground, theoretically the robot can jump off the ground for a brief moment and then grab the high rung which would allow the robot to score all 30 points. Unfortunately, we were only able to accomplish the first ascent instead of the jumping robot, but the ideas we did in Ri2D will help us as we progress through the season.

Since we chose to build on the swerve platform that we developed over the summer, we needed to make some additions to the code for the swerve platform. The swerve module is built up of two separate rotating parts, a platform, or as we like to call it, a frame, and we have the swerve module itself. While coding the swerve module in the summer, we decided to ignore the rotation of the frame and just focus on translation in the direction that we wanted for simplicity’s sake. We could accomplish this with just one encoder; however, in order for Swerve to be competition ready we need to be able to control the rotation of the platform too. To accomplish controlling the rotation, we decided to drive one of the Omni wheels that were there previously to balance the mono swerve platform. We accounted for this by implementing an unwrapping function based on input from the IMMU in the control hub that helped maintain global bearing despite platform rotations due to the driven Omni wheel. This gave us the ability to decouple the direction of the swerve module and the platform and naturally created a field-oriented driving system.

One major component of the intake system we designed during robot in two days was a pincer gripper claw. Attached to a linear slide outtake, there is a claw with two separate 3-d printed parts that pinches the specimen. This design worked fairly well and it effectively secures the samples. The second part to the intake system was a beater-bar to intake the samples from the field. The beater bar we built used rotating tubes to intake samples onto a platform. This was a simple design, but we are planning to add a color sensor and diverter to only keep the samples of the color we want to make the beater bar system more efficient.

Today marked the first full program robotics meeting of the Into the Deep season. We had about 20 new recruits come into the Dojo for the very first time, and we had returning members from other sister teams. We started the meeting by going over the season reveal, talking about the basic rules, and as a whole team around 35 of us started ideating robot and subsystem ideas. We discussed with the new recruits about the specific important parts of this Season. Most importantly, we talked with the new members about Gracious Professionalism and the core values of FIRST robotics.

After a full group discussion, the new recruits split up into different teams based on their interests. We had two main divisions, one for coding and one for build and design. As two separate groups, we had socratic discussions and Iron reign started teaching foundational skills. In the build and design section, we talked about how to initialize the design process and we started drawing out ideas on a white board. Later on, we discussed basic building skills like how to use simple materials and parts such as rev-rails and hex nuts. After learning and discussing the build and design section split into two subunits and started playing around and applying the skills they learned. They started prototyping subsystems such as linear slides and basic ways to access the samples in the submersible.

On the other hand, with the code section, they learned about github and source control, specifically how to commit, push, and pull requests. They learned about servos and motors and how they work and the basics to coding them. Finally, they discussed an overview of the interactions between the driver station, the control/expansion hubs, and Android Studio on their development machines, with a brief foray into FTC Dashboard and RoadRunner. Overall, we helped new recruits dip their toes into the basics of robotics and helped them start building a foundational base of knowledge depending on what they were interested in.

Today, Anuhya started modeling the full bridge and then moved on to designing the plate that attaches to the bridge structure. The next steps will be refining the attachment to ensure it integrates seamlessly with the rest of the design.

Nalin and Ren filled up two Motivate pages in the portfolio in preparation for the Early Qualifier. They also took photos for our upcoming jewelry catalog and shared information about the portfolio creation process with our recruits.

Jai and Elias worked with recruits to set up Android Studio. They focussed on introducing them to programming a basic mecanum drive and began working their way up to more complex topics. Elias also explored the Limelight documentation and is currently writing a recap to capture the code progress from today.

Sol took charge of teaching new recruits how to 3D model using Onshape and Fusion 360. The recruits were introduced to the basic requirements of being a modeler and given a starter task: modeling and printing keychains to get used to CAD.

Our team’s focus is now on getting the robot and documentation ready for the upcoming Early Qualifier.

Task: Make Progress in Prepreation for the Early Qualifier

Today, the team made substantial progress both in building and portfolio development. We began working on the Ideas Festival page (previously known as Robot in Two Days) and brainstormed fresh ideas to enhance our portfolio. We also engaged with new team members about outreach strategies and portfolio improvements. To boost our presence, a new Instagram post was created, and we plan to expand our social media presence further.

On the code and build side, we tackled several key improvements. We started with the Limelight camera, diving into color blob detection for better visual tracking. A new attachment was added to ensure the linear slide stays perfectly parallel, and modifications were made to reinforce the structure and prevent it from getting caught. The failed 3D-printed bridge connection point was also adjusted, and some unnecessary parts, including the skyhook motors, were removed to streamline the design.

We worked on suspending the linear slide and participated in an Iron Core meeting to share insights. On the design front, we brainstormed ideas for a new roller claw but may initially focus on simpler sample gathering methods.

In terms of teaching, we continued with Java basics, controlling drive speed, and servo operations. I also started coding autonomous routines and developing an intake/outtake system.

Task: Work on Integrating Limelight and Build the Linear Slide

Today saw a creative leap forward with a prototype for an A-frame and pulley system, designed to rotate the linear slide from a parallel to a perpendicular position relative to the ground. Though the design is still rough, it’s an important first draft to explore the concept. Plans are underway to improve the bridge-to-A-frame connection, potentially using a Ninjaflex hinge or a GoBilda hinge adapter, if suitable. The overall frame and bridge design will be refined through iterations, with a focus on making the linear slide’s rotation smooth and quick.

Additionally, initial work began with the Limelight camera for color blob detection. Key observations on the camera’s performance include its high saturation levels and challenges in distinguishing adjacent samples of the same color, even with contour filtering. While it can detect one or two blocks at a time under specific conditions, samples in close proximity often register as a single blob. The camera’s rectangular shape fitting, sensitivity to lighting, and reliance on the Erosion Function for contour refinement were noted as areas for improvement.

Recently, one of our readers, a girls STEM club, reached out to express their appreciation for our online blog and how they used it for their robotics research project. We’re really glad that people find the content we publish useful because that’s what our blog is all about: making robotics more accessible. They also shared a great robotics resource with us, a glossary of commonly-used robotics terms, which we want to share with everyone. Here’s the link: https://www.qualtrics.com/blog/robotics-terms/

Task: Refine Intake for the Early Qualifier

This week, the team made significant progress on multiple fronts. On the portfolio side, members worked on slides focusing on team organization, financial management, and sustainability of skills. Jewelry project images were organized and refined, and an Instagram post was prepared for the Jewelry. Additionally, an earring order form and website layout were created to expand our online presence.

The build team mainly made structural improvements. TPU slabs were melted and shaped to replace the tape hinges on 3D-printed parts, providing a more robust solution. Adjustments to the linear slide included redesigning the bridge for better stability. This redesign allowed the control string to split across two spools mounted on a single axle, enhancing the “crane” rotation’s functionality. A motor was attached, and initial coding was set up to control the crane's movement.

In development, members worked on the belted beater bar, redesigned rollers, and initiated a polycarbonate version for better durability. A deflector holder and color sensor mount were added, alongside ideation for a “door” on the beater bar. Meanwhile, the sister teams received training on basic drive, codebase structure, and robot-opmode interactions, positioning them for independent learning through trial and error.

Task: Present to engineers from Eli Lilly & Co.

Today, we met with Robotics Application Engineers from Eli Lilly & Co, a pharmaceutical company that manufactures medicine using biotechnology and machinery.

We first started off by going over our Summer projects (Simply Swerve and RoboSpyne). We talked about how we came up with the swerve’s design and refined it over the summer. Then, we discussed how we could orient our swerve modules on the chassis to be as effective as possible. With the RoboSpyne, we talked about how we were inspired by the human spine and many parts of the Spyne directly correlated with specific parts of the human spine. Having a game strategy in mind, we talked about how useful the Spyne would be in actual game play this year. Ultimately, we decided that the Spyne would not be useful this season since it can not carry large loads and since it despools easily.

Lastly, we demoed the Nacelle Chassis and talked about how the subsystems would be implemented in the chassis. We finished by presenting our new limelight system for object detection and how it could help us moving forward.

Overall, we had several interesting and engaging conversations with our mentor and we received a lot of helpful feedback. For the future, we set up a plan with our mentor to have consistent meetings to talk about progress and receive constant feedback that we can incorporate. Thank you so much to our mentor from Eli Lilly & Co!

Task: Scrimmage Preparation

This week, the team had both portfolio development and robot improvements. The Ideas Festival (previously known as Robot in Two Days) portfolio slide was completed, and a recent Lilly meeting was added to the Connect portion, along with a dedicated blog post.

On the build side, progress included attaching the power switch, adding a physical stop for the hinge, and making minor tweaks to improve functionality, such as adjusting screw placements. Work continued on manufacturing and assembling Anuyah’s active intake design, while another team member assembled parts of a new concept.

Intake and outtake articulations were refined, and autonomous pathing was adjusted, providing team members with more experience in handling the robot’s movements. Discussions on sequencing and best practices for articulation helped streamline operations.

To prepare for future adaptations, brainstorming began on a hot-swap process for attachments, starting with an attachment selector. The carbon-fiber tube-to-linear slide attachment was strengthened, and initial modeling of the current bridge was done, setting the foundation for future improvements in stability and functionality.

Task: Experiment with Claw Designs

Today we built a proof of concept for a roller claw concept that we came up with. This claw took inspiration from a passive rubber band pincer gripper designed by a team on the unofficial FTC Discord server. It also took inspiration from a previous roller/beater intake designed by Iron Reign for the Relic Recovery season (see below).

Some changes we had to make were the beater bar and the walls of the intake system. We experimented with different sized beater bars and the amount of them. We finally decided to go with thin beater bars that are 15mm and 10mm and use 1 beater bar belt to continue the intake process, while 2 beater bars are on the first axel. This setup allows the samples to be taken in by a multitude of angles, yet continue through the intake until it needs to be ejected. The build of the intake was changed from a rectangle, to having a triangle-like entrance. This change allowed the edges of the samples to get caught and slowly turn the sample to the correct position, creating more intake positions of the sample.

So far this intake system works well. It can intake samples in almost every position, except completely horizontal. This can be fixed by slightly hitting a sample to turn it in-game. It does however allow some samples to eject unknowingly. Another issue we have found is it intakes slowly, causing cycle time to be relatively slow compared to other teams. Overall these are minor issues, and it is an effective intake that we will continue to develop.

Task: Scrimmage Preparation

Today brought exciting progress on both robotics and jewelry fronts. On the jewelry side, we transformed all current charm designs into silver earrings, creating a complete set of each design.

In terms of code, we made more progress with Limelight, focusing on translating pose data from the Limelight to the robot. We also consulted the FTC Discord for additional insights. For our ongoing bridge design, we completed the initial model, incorporating the current dimensions. While spools and axles still need to be added, this model will help us improve the bridge’s stability, durability, and functionality.

We also started brainstorming a new lift mechanism using a tape measure, with early CAD models underway. We are gradually refining this concept and plan to create a drawing to better visualize the design.

Task: Analyze our performance at the Full Moon Scrimmage

Today, Iron Reign attended the annual Full Moon Scrimmage hosted by Marcus High School. We competed in two matches and won both, but they were primarily due to our alliance partners since we faced lots of problems with our robot.

The biggest issue we faced was our wiring management. Since our pincer claw was attached the night before the scrimmage, the wiring was very unorganized. In the morning of the competition, we tried to fix the wiring quickly, but we were unable to do so and the wires ended up getting more tangled and confusing. By the time our first match came, the claw was inoperable due to the wiring being done incorrectly. We tried to make last minute efforts, but in the second match as well the robot was only able to push samples in the bucket zone. Even though we were unsatisfied with our performance, we were able to learn a lot about how to fix similar problems in the future. Now, we plan to organize our wiring, replace the claw with our beater bar system, and to design a new chassis using our swerve modules that were developed this summer.

Task: Making Changes Based on Scrimmage Performance

Today was packed with advancements and challenges. We drilled and attached the intake mechanism onto the arm and completed the real wiring for the arm, marking an essential step forward in functionality. Although we faced some issues with the protective sleeve, we tied it up temporarily, and once the sleeve is in place, the setup will be complete.

There was a need for more extension on the sensor cables, so we added a redundant servo and sensor cables for increased reliability. The intake prototype we began last week was further refined, aiming to optimize performance for the next trial.

Beyond assembly, we focused on collaboration and skill-sharing. We created a blog post to share highlights from our recent scrimmage, helping us reflect on our performance and share insights with the broader robotics community. Additionally, we spent time working with our sister team, Iron Core, to assist with wiring and mentor them in more advanced robotics skills. By the end of the week, we had Iron Core moving and working toward their goals, ensuring a stronger, more connected robotics family.

Task: Improve our Roller Claw Concept

We’ve made progress on the 2nd version (V2) of the roller claw that is more structurally sound and has an improved intake. To improve the structural stability we added a second standoff between the plates of the claw halves to stop them from twisting while intaking. Additionally, we added a large pyramidal structure in the center of the claw in order to help align samples during intake. This structure also doubles as a physical stop for the claw halves so they can’t move past their intended minimum limits, an issue we observed during testing of the prototype.

We decided to test a variety of springs, moving away from surgical tubing, and ultimately landed on a 1.1cm x 3.8cm x 1.2cm extension spring. This spring produces enough tension to properly clasp onto samples and specimens alike even when encountering “turbulence”. Despite it still losing tension overtime, like surgical tubing, it cannot untie itself and will take a longer time to lose enough tension for the impacts to be noticeable. A con of having this increased tension is that the claw does require more precision during intake and more force than the previous version due to the spring’s higher tension, something that is an unnecessary burden. While we are confident this will be our final form of tension, we may test out different spring strengths or other forms of tension. Another change we made was to increase the number of rollers, from 2 to four. While some of the rollers were iffy, the increased number of them made intake more efficient. After further testing, we came to the realization that the stiffness, material, and current roller profile worked well for what we wanted. We also decided that stiffer rollers are not needed; however, testing rollers with more walls and/or higher infill percentage is not out of the question as it could produce improved results.

For the next version we will focus heavily on the coding aspect. We plan on adding a color sensor to locate preferred color samples. Additionally, we want to embed a color sensor into the tip of the aligner to detect whether we have collected the preferred sample or not. We will also finalize the servo mounting system to start powering the rollers. Despite this version requiring more precision due to the spring, by adding rotational movement to the rollers the intake will require less precision. We also want to begin printing parts out of nylon to test durability and tolerances. We believe this change in material will cause some revision on the design due to the difference between nylon and PLA.

Task: Build and CAD Progress for Meet 1

Today, we experimented with a potential lift mechanism, refining ideas to improve its functionality and stability. Additionally, we worked on upgrading an older swerve drive module so it can meet the latest requirements of our design.

A big milestone was achieved with our new joint for the robot’s elbow, which we call the "Axle Oreo." The team retrieved parts, assembled the joint, and tested its fit within the existing framework. A future plan with this part of the robot is to create a system that will relieve some load off lifting the elbow from the servo with the use of string. We also dedicated time to small but essential details, such as sorting screws and creating a mount for the color sensor on the intake mechanism, which will improve detection accuracy and response time.

On the digital side, we created spatial models to help visualize our designs, and we made social media updates.

Task: Analyze our performance at the League Meet 1

Today, Iron Reign went to our first League Meet of the season. We made it to 7th place out of 29 teams, and improved heavily from the Screamage.

Match Recap

Match 1: 29 to 9 Win

Scored 1 sample into the low basket during Auton. 1 sample fell out of the claw because it went through the color sensor but we picked up a 2nd one from the spike marks and scored. Finally, we scored 1 sample from the submersible. However, we did get a penalty because while we were scoring, we pushed 1 sample into the net zone, resulting in a double control penalty.

Match 2: 46 to 35 Win

We scored 4 total samples, including 1 in Auton, including 2 from the submersible. However, the elbow seems to also be having a little bit of trouble.

Match 3: 31 to 21 Win

We scored 3 total samples, including 1 in Auton. Slow sensor response times limited how fast we could intake samples, and our linear slide was quick wobbly leading to poor accuracy at the basket.

Match 4: 48 to 70 Loss

In this match we forgot to adjust the alliance color we were on, so we could only intake yellow samples, but we still scored a couple including our preload.

Match 5: 73 to 75 Loss

We scored 4 samples, including in Auton and all 3 from the spike marks. However, at the end of the match, we got confused and tried to touch the first bar instead of going to the observation zone.

Game Analysis

Our Auton was very consistent throughout all 5 matches, and we scored a sample in the low basket each time without fail. However, while the Auton worked well, it only scored 4 points each time. Code-wise, our next steps for the upcoming League Meet involve scoring on the high basket and picking up neutral samples from the spike marks.

In Tele-op, our cycle times for the low basket varied from 15 to 33 seconds, with a mean of 23.2 seconds and a mean of 22.5 seconds. Oftentimes, the robot got the sample up to the low basket but the sample would end up outside the bucket. For our slower cycle times, we noticed that alignment between the robot and the sample was the biggest problem. Even though there was not an issue with picking up samples of the other color due to the color sensor, the alignment had to be somewhat accurate for the beater bar to intake the sample.

There were some outlier cycle times because in one of the matches, we forgot to change what color samples the beater bar picks up. This resulted in only letting the robot pick up yellow samples. Also, the beater bar is too slow, and we noticed that for yellow samples it took a longer time for the belt to stop rolling so that the sample would stay in place.

During the end game, we struggled with scoring points and deciding on a strategy. For two of the matches, the drive team was able to quickly maneuver the robot to the observation zone at the last few seconds to score parking points. Other times, we tried to touch the low bar to get the first level hanging points, but we were never able to. One of our limitations was that the robot needed to slowly approach the bar so the arm would not break.

Our strategy was also poor at times. In our last match, we were very close to touching the low bar, but the timer ran out once second to early. If we had been prepared and instead traveled to the observation zone, we would have won that last game by one point.That is why one of the biggest goals for our team before the second league meet is to give the code and drive teams about a week each to make sure simple mistakes like that don’t happen.

Task: Analyze our League Meet 1 Performance

After every competition, the team sits down and runs a SWOT(Strengths, Weaknesses, Opportunities, Threats) analysis on the robot and its performance. Here is a breakdown of everything we learned using the SWOT technique after League Meet 1.

Strengths:

One of the biggest strengths that our robot has was auton reliability. In every single match we played, the auton always worked. Having this reliability allowed us to have a strong foundation and build off of this base auton in a more efficient manner. Another strength we possessed was good time management. The team was not late to complete any of the inspections, and we were always on the queueing table on time. The team was organized allowing us to run smoothly.

Weaknesses:

There was a missed opportunity on the code part since we were never scoring in the high basket in TeleOp or auton. If the build team had finished a little bit earlier, the code team would have been able to code the robot to score samples in the high basket. Scoring in the low baskets made auton almost pointless even if it was reliable. Specifically in the beater bar, the window for the color sensor was not optimal. This made tuning inconsistent, and the problem was very obvious when it came to yellow samples since the belt stopped much later than it would have for red or blue samples. Overall, the belt of the beater bar was also much slower than we wanted since the belt was small.

Opportunities:

We want to better segment the time before competitions to make sure the build, code, and drive team all receive almost the same amount of time with the robot. Allocating time in this manner will allow the drive and code team to have an adequate amount of time to make sure other things are not lacking such as fine tuning in the code or not enough practice time driving. We want to practice driving under competition conditions to gain the most accurate data. We want to increase the speed of the belt and try to hang on the low bar with a new arm.

Threats:

The biggest threat to the team was a lack of coding time. If the code team received more time we could have scored the high basket. Scoring on the high basket would have let us receive almost double the points than we were actually scoring. Another major threat was not giving the drive team enough time with the robot. We would have won our last match if we gave the drive team more time since they would be able to figure out how to touch the low bar during endgame.

For the second meet, we want to make the following changes: We want to have two separate linear slides, a worm gear shoulder, be able to achieve 2nd level ascension, getting rid of the bridge, and continue to plan a new swerve chassis.

The SWOT analysis gave the team insight on what went well and what needed improvement. This feedback will allow us to have a base plan to follow for meet two. Ultimately, performing a SWOT analysis gives us very valuable and important information to help us develop the robot and the team.

Task: Create a reliable intake system for the Submersible

We developed an intake system using a 3D printed beater bar out of ninjaflex. The beater bar is used to pull the sample onto the platform. We used clear 1 mm polycarb to form the walls of intake. The walls curve slightly allowing samples faced in many angles to correctly position itself to enter the intake via the beater bars. The beater bars move via an axel connected to a servo. We also connected a color sensor to be able to detect the color of the sample. This will ensure we have either a team sample or neutral sample. If we collect something else, we are able to easily eject it. Due to the light from the sensor, the driver is able to view the color of the sample through the polycarb during tele-op.

Some changes we had to make were the beater bar and the walls of the intake system. We experimented with different sized beater bars and the amount of them. We finally decided to go with thin beater bars that are 15mm and 10mm and use 1 beater bar belt to continue the intake process, while 2 beater bars are on the first axel. This setup allows the samples to be taken in by a multitude of angles, yet continue through the intake until it needs to be ejected. The build of the intake was changed from a rectangle, to having a triangle-like entrance. This change allowed the edges of the samples to get caught and slowly turn the sample to the correct position, creating more intake positions of the sample.

So far this intake system works well. It can intake samples in almost every position, except completely horizontal. This can be fixed by slightly hitting a sample to turn it in-game. It does however allow some samples to eject unknowingly. Another issue we have found is it intakes slowly, causing cycle time to be relatively slow compared to other teams. Overall these are minor issues, and it is an effective intake that we will continue to develop.

This past Thursday, Iron Reign went to William B. Travis Middle School to help and mentor their First Lego League robotics team. Iron Reign first was established as an FLL team at Travis, and it was a full circle moment to go back and mentor the current team there. Primarily, we helped out with building challenges, starting the code for their robot, and their presentation.

Presentation wise, we taught the team how to make their presentation more formal, organized, and techniques to convey information in a better way. For example, we helped them reorganize some parts of the presentation so instead of big chunks of words, there were bullet points so it would be easier for the judges to understand. Another part of their presentation we helped with was specific wording. We helped them understand how to identify unclear or awkward parts and how to fix them. After mentoring them over specifically the information, we taught them how to clean up the presentation and make it neat, but also making it unique to themselves and their team. One specific part of their presentation that we helped out with was picking better pictures to capture the meaning of their slides. Another thing we helped them with was better formatting and color/font selections.

Our code team helped Travis’s code team mainly with the basic code for the drive train. Since most of the team was composed of 4th and 5th graders, we were able to teach them something new and complex for elementary schoolers: Circular Geometry. First, we derived a formula for the distance traveled by the robot per revolution. We calculated the circumference of the wheels, the diameter of the drive base, and used both pieces of data to create custom EV3 Mindstorms blocks that would make the robot drive forward precisely 10cm and turn (roughly) 90 degrees. We taught them how to apply the math and geometry they were learning in the classroom in a much more real-world setting by contextualizing physics in robot code.

Finally, the team had recently received their challenge map, so we helped them build and place the challenges on the map. Also, we helped them brainstorm ideas for attachments on the EV3. We helped them place the built challenges on their map as well as building. Brainstorming wise, we showed them videos on some ideas they can use for this year, and we gave them some ideas that may help form the first iteration of their robot. The build team also helped the team with organization and gave them tips and techniques to keep an organized space.

Near the end of their meeting, we had a quick presentation for them about FTC and all the changes between FLL and FTC. We talked about how FTC has more freedom in terms of parts available, and we talked about the complexity difference. We also showed the amazing outreach opportunities Iron Reign got to be a part of. The main purpose of the presentation was to spark interest in continuing FIRST robotics and moving onto FTC when they are older.

Overall, we had an amazing time helping out the FLL team at Travis. It was a fulfilling experience going back to where the team started and mentoring the current team. Thank you so much to Mr.Delgado, the team’s coach, and all the team members for being wonderful people. We can not wait to go back soon!

Task: Analyze our performance at League Meet 2

We had our second league meet today at UME Preparatory Academy. Overall, we had a satisfactory performance because there were definitely parts of our performance that could be developed, but some of the things worked relatively well.

Match Recap

Match 1: 31 to 18 Win

One of the teams on the other alliance did not show up. We did not run auton since if we did, we risked self destruct. With our alliance team, Iron Core, we were able to score 28 points. The robot was mainly operating as a push bot while our sister team was scoring specimens. At the end game we got three points since Iron Core got first level ascension.

Match 2: N/A

Sadly we missed this match because the whole team was at the practice field and did not realize that we had a match. Luckily since our alliance team won, this round did not affect our standings.

Match 3: 9 to 104 Loss

We were unable to move during this match. During auton, we were unable to run auto, and our partner team, Iron Giant, tried to score a specimen but failed. Our opponent team placed a specimen and parked. During teleop, we were pushbot again and placed 3 samples in our net zone. Iron Giant continued to practice scoring specimens.

Match 4: 43 to 24 Win

No teams had auton during this match. We were unable to fix our intake, so we continued as pushbot. Unfortunately we became static due to our battery connection and could not move during the rest of the match. Our partner team, 22344, placed 5 samples in the high bucket. During the end game, our partner team touched the rung scoring 3 points.

Match 5: 21 to 39 Loss

No teams had a working auto. During tele-op we operated as a pushbot and effectively placed 13 in our net zone. During the endgame, we were able to touch the rung scoring 3 points.

Match 6: 45 to 22 Loss

During auton, our opponent side were able to gain parking points. Neither of us, in our alliance, had a working auton. During Teleop, both of us were push bots scoring around 7-10 points. During the endgame we were able to score 6 points since both robots got first level ascension. We were able to win since we got 25 foul points (2 major and 1 minor by the opponent team).

Analysis

We never had an auton working in any round since the code team only had a few hours with the robot. During practice time, we had to figure out wiring and other issues meaning we did not have time to calibrate the auton for it to work properly.

For every Teleop our robot was only able to push samples into the net zone since our linear slide or beater bar did not work. We were able to get four or five samples into the net zone consistently which only contributed to four or five points to our score.

In the endgame we never got any points either except for two of the rounds. We were able to get first level ascension twice when our linear slide worked slightly.

Task: Analyze our League Meet 2 Performance

After every competition, the team sits down and runs a SWOT(Strengths, Weaknesses, Opportunities, Threats) analysis on the robot and its performance. Here is a breakdown of everything we learned using the SWOT technique after League Meet 2.

Strengths:

In our conversation, everyone could agree our key strength was the structure of our linear slide. Earlier on we decided to change our linear slides from string to belts. This change so far has proven our slide to be sturdy and effective. It had little to no shake when lifting, which was a key issue in earlier versions. It also extended easily using belts. We are confident in this subsystem's ability to function.

Weaknesses:

One of the main reasons we were not able to properly function our linear slide or beater bar was a weakness that we have had time and time again: Wiring. Even at the last meet and scrimmage, we spent a lot of our practice time rewiring the robot. At this meet the wiring was not properly done which meant our robot could not retrieve samples or properly use the linear slide. Another reason why the arm did not work was because the build was only 90% there. The arm was very wobbly at the point where it was connected to the beater bar every time we tested it. Finally, code only got a few uninterrupted time with the robot to perfect the code for the new version of the beater bar and the new linear slide. Overall, we can fix our weaknesses if we can create a better coordination system and focus ourselves on hard deadlines.

Opportunities:

After our discussion, we talked about the opportunities necessary to take, so we can effectively better our robot. An issue many people noticed was the bearing on the slide motor. These bearings are necessary to hold the belt and insure it does not slip. The current bearings are too small and do not effectively do this job. We believe these bearings need to be thicker or squeezed closer together. Another opportunity we discussed was our next goals for winter break and for League Meet 3. We hope to finish the quick issues this week, to give our coders time to code leading into winter break. We also have dedicated a few members to work on our new chassis and robot design while further improving this one. We hope to implement our swerve summer project into our new robot and have 2 arms by League Meet 3.

Threats:

During our discussion, we talked about how sometimes the team lacks a sense of urgency and how we get sidetracked easily. We reflected upon this threat and tried to figure out ways to fix this problem. We knew that socializing time was important because it helped creative juices to flow, but at the same time it is necessary to focus and make sure stuff gets done. To combat this, we created a specific calendar for specific goals. This will allow us to see exactly what needs to be done and hopefully allow us to have a better sense of urgency.