Talking Heads: Summary July 11, 2020

Task: Prepare for the 2020-2021 Game Reveal season

Today kicked off our first meeting for the new Ultimate Goal season. Since the actual challenge for this year hasn't been released, the most we can do is to speculate what the new challenge might pose, and what we can do to prepare for it.

As most of our members have moved on to our Junior year, our team is now primarily upperclassmen-led. This means that within 2 years, we will need to recruit enough members to keep the team sustainable after our graduation. Unfortunately, due to the current pandemic, we will need to ensure that the Iron Reign program has the funding needed to maintain 3 teams in addition to ours. At the moment, our focus has been on keeping our own team viable over the virtual season, and this may mean that we will have to cut back on our recruitment and pick it back up closer to our senior year on the team.

In an earlier post, we went over the plans for a new mobile learning lab. To clarify, the Mobile Tech xPansion program is owned by Big Thought, a non profit organization dedicated to education, but its outreach events are executed by Team 6832 Iron Reign. During these events, our team travels to low-income areas around the Dallas community with little access to STEM education, and teaches younger students about robotics and CAD to improve their interests in STEM which can sometimes be hard to discover without the access to a strong STEM-based education. Recently, Big Thought approved the plans for funding and expanding this program and our coach was able to purchase a new vehicle for the second, improved version of this Mobile Learning Lab. However, due to the ongoing pandemic, the plans for this vehicle have been put on temporary hold since most of our outreach events happen over the summer. As the count for COVID-19 cases in Dallas has been relatively high, there is no safe way for our team to interact with younger students and teach them hands-on robotics. As such, we will be placing our MXP outreach program on hold until the pandemic has improved (which will be, hopefully, soon).

Jose has been working on modelling various robot designs in anticipation of the upcoming season. The first is a kiwi drive, with a triangular chassis with 4 omni-directional wheels on each side of the chassis which enables movement in any direction using only three motors. The render of the robot itself is built using custom and goBilda motors. Another design was for an Inspirenc CAD Challenge, which resembled our Superman design from two seasons ago, but with a more rectangular chassis. All of these designs created over the summer will be within their own separate entry - this is merely a summary of our summer progress. Since we don't yet know what the challenge this year will look like, nor how much we would be able to meet in-person in light of COVID19, we plan on starting our build efforts with CAD designs to streamline the engineering process with an online reference in hand.

Next Steps

One of the hardest things about this year's season will be trying to cover all our usual grounds virtually since the number of team members who can show up to in-person practices has been severly limited. In the meanwhile, we plan on using our Discord group to map out the skeleton of our new season - journal and CAD will, for the most part, progress business as usual but we'll need to rely on CAD and our planning calls much more heavily to go through with build, code, and outreach. We plan to keep up our pace as a World-class team as best as we can over quarantine, as uncertain as our plans for this season may seem.

Task: Print some game elements to get a kick start on the season

Recently, this year’s competition details were released, and while we couldn’t quite get started on a robot immediately like we did last year we were able to do some prototyping for ring launchers. The thing that we made which enabled us to do this was a rendering of the game element for the year. This was done by taking the model released on AndyMark’s website and 3D printing it. With this, we were able to start thinking about the size and proportion of our future launcher as well as its construction. The ring was printed in PLA at its exact size to best accomplish this.

The biggest problem with this method of construction is that the ring does not have the characteristic foam squishiness so we also made another ring out of foam tape to get a better idea of how the official game element might fly and how we can get it to fly. We were able to throw the two rings around and notice that there is a very noticeable spin that can be achieved and will likely be desirable in the future for maximum stability in the air. The realistic shape of the ring was helpful when we were trying to figure out how the ring would fly since different ring shapes would obviously fly differently so having a replica was nice.

Next Steps:

We are going to kick off our development of a robot soon and with the rings we made we should be able to develop better early on than if we were empty-handed. This development is of course being curbed by the pandemic since at the moment only a few builders can come in to build at a time. Being one of these builders, I think the goal for the first launcher prototype is to see how easy it is to get a ring to fly and what variables will be important in the future for trajectory and speed rather than actual functionality. We are excited to have a whole season of development ahead of us.

Task: CAD a robot for the Ultimate Goal Challenge quickly in order to get ideas for a final robot design and prototypes

A new season, a new design challenge, and more opportunities to compete. Last season we participated in the Robot in 3 Days Challenge where teams race to build a robot for the new season as quickly as possible in order to accelerate the brainstorming and prototyping phase of the season. Due to certain circumstances this couldn't happen this season but overcoming the situation the idea of transferring the challenge to CAD arose.

Day 1

The first step of course is to come up with a design for this robot. Many ideas came and went, many ideas were inspired by previous seasons' robots, but ultimately the main design was decided over a few hours and a basic CAD model was made. A time lapse of this can be seen here:

Since I was really lazy today, I mean since coming up with the design of the robot took a while and I was very busy today not much could be done in the first day. I began working on the claw to grab the wobble goal and taking inspiration from the one used in the xRC Sim version of the game(the sim can be found here: https://xrcsimulator.org/downloads/) I decided on a simple arm mechanism with a hook. The hook is designed to be passive, it's wide enough to go around the pvc pipe of the wobble goal, but small enough such that the top of the wobble goal can't escape as easily. Since the wobble goal isn't as heavy the arm doesn't need such a high gear ratio, so I went for a 30:1 final gear ratio.

Day 2

Day 2! Time to do everything I was too lazy to do yesterday, I mean too busy to finish. The first step today was to check how much length I had left over for the ring intake, this turned out to be a little over an inch, not much, but enough. Since I am going for a conveyor design for this robot a base is needed below it to not only support the conveyor, but to also make sure the rings don't fall since they will be travelling below the conveyor in order to feed into the shooter. Some supports were added with REV extrusions, which made things start to come together.

Up next was to actually have a way to power the wobble goal grabber. However, this was really simple as I just needed to add an ultraplanetary motor and a belt.

Next on the list for today was to actually make the conveyor belt, this will have "spikes" in order to grab the rings. The conveyor is about 6 inches long to allow for some extra room when intaking. Spikes are in pairs and spaced about 3 inches apart. This was a simple assembly and I was able to move on to adding the pulleys and bearing shortly after. As far as a gear ratio goes, a direct drive 19.2:1 should do.

It's the final countdown..[plays the final countdown music], time for the final sub-assembly, the shooter. This was very simple to make. Holes in the polycarbonate base were made to allow for the shooter wheels(I used the new goBilda Gecko Wheel) and these were also direct driven with a 5.2:1 goBilda motor. This may be too slow but since this is CAD, it isn't very easy to test this. The process of getting renders of this robot proved to be resource demanding but it got done and here is the final product:

Task: CAD a simple roller intake design

This intake design is the most plain of them all, just compliant wheels on a shaft. The idea with this is to have it low to the ground, and drive up to the rings. This design has been tried and tested on many robots by many teams, but it will not work on ROBOT as there is no realistic way to transport rings so low to the ground up to the turret, especially not with the entry angle of the rings.

Next Steps:

Continue prototying more intake designs.

Task: Begin creating intake systems on CAD to test their potential

The Archimedes Screw Intake, as the name goes, was based on an Archimedes screw. A screw shaped surface would draw the rings from the fields and transfer it directly to the launcher as the screw rotates. Similar to the Archimedes screw water pump, it makes use of positive displacement and would rely entirely on the screw's movement for the rings to travel upward towards the launcher.

While this is an intruiging system, our biggest concerns with it are size and timing. This system would take up most of the volume of the robot. Also, since the screw would have to rotate entirely for one ring to be taken upwards, this is likely not the most efficient system and even the mere drawing of the rings into the system is likely to be more time-consuming. It would also be very difficult to make. So, this intake ends here in the concept stage.

Next Steps

Our next steps are to begin brainstorming ideas for other, more efficient intake systems. We may still come back to the Archimedes system but as of now, it is of lower priority. Rest in Peace Archimedes.

Task: Create and Test a Arm Disk Launcher

One of the centerpieces of any robot this year is going to be the disk launcher. It’s likely that most robots in the competition are going to be built around their launchers, so one could logically conclude that that’s a good place to start when building a robot. This is no different for us; however, we didn’t just want to build a flywheel like most other people. Instead, we started to look into other designs. One of the designs that came into mind first was some sort of arm that is powered by an elastic or bungee cord that throws disks sort of like a clay pigeon thrower.

But why did we start with an arm design? Wouldn’t a flywheel be easier? We started with an arm because we thought it was interesting and customizable. Yes, a flywheel would be easier but that would be at the cost of customizability. With a flywheel, there is only so much to change. You can change pretty much only the motor, the wheel, or the speed of the motor. This is good for a team that just needs a launcher that works but we want to be able to make a customizable launcher that we can tailor to our needs easily. There is a lot of open space and customizability with an arm launcher. For example, we can change the arm material, length of the arm, strength of the bungee, the time the disk is in contact with the arm, and much more.

So that’s what we built and it works to a degree. Yes, it does launch a ring, in fact, it can launch a ring across the field to a height of 55 inches at an angle of 44 degrees with an easily retractable arm; however, in its current state it breaks easily, isn’t consistent, and is quite big. The first two are fairly easily fixable because they are mostly because the base of the launcher is made out of particle board which falls apart easily but the last one isn’t quite as easy to fix. Cramming this design into a smaller space could provide a difficult challenge. The function of the design is to accelerate a ring over a distance with an arm which can be difficult in a small area because with a smaller arm you have to use a stronger bungee to achieve the same results.

Next Steps:

I have only touched on a few major things to be improved. There are quite a few; however, the results that we observed from this design definitely warrant a second version, and there will be one. At the very least, I am thinking of new designs and improvements for this system. There are also many other things we can try and I know that regardless of what I have said about a flywheel launcher so far, it would have its advantages, mainly compactness, so I know we will definitely build one of those as well. There is still much more to be made and built for this robot.

Task: Plan changes to our codebase for the new season.

This year's game saw a significant boost to the importance of the control award, now being put above even the motivate and design awards in order of advancement. Therefore, it is crucial to analyze what changes we plan on bringing to our codebase and new technologies we plan on using in hopes of benefitting from the award's higher importance this year.

Firstly, the very beginning of the autonomous period requires the robot to navigate to one of three target zones, specified by the quantity of rings placed, being either 0, 1, or 4. Since the drivers will not be able to choose an opmode corresponding to each path, we will have to implement a vision pipeline to determine which of the three configurations the field is in. This can be done with OpenCV, using an adaptive threshold and blob detection to differentiate 1 ring from 4 rings through the height of the detected color blob.

Secondly, ultimate goal's disk throwing aspect opens up the opportunity for automatic shooting and aligning mechanisms and the software to go along with them. If a robot can use the vision target placed above the upper tower goal or otherwise localize itself, projectile motion models can be used to analyze the disk's trajectory and calculate the necessary angle and velocity of launch to score into the goal given a distance from it on the field. Such automation would save drivers the hassle of aligning and aiming for the baskets, allowing them to focus on more complex strategy and improve cycle time. Vuforia and OpenCV pipelines can be used to figure out the robot's location on the field, given the vision target's orientation and size in its field of view. If OpenCV is also used to allow for automatic intake of disks on the ground, then most gameplay could be automated, although this isn't as simple a task it may seem.

Asides from using the webcam, another localization technique we dabbled with this summer was using GPS. We were able to get +- 4 cm accuracy when using a specific type of GPS, allowing our test robot to trace out different paths of waypoints, including our team number, the DPRG logo, etc. If this level of accuracy proves to be viable in game, GPS could be considered an option for localization as opposed to the odometry sensors many teams employ currently. Another sensor worth noting is the PMW3901 Optical Flow Sensor, which acts similar to a computer mouse, in that its movement can be translated into a horizontal and vertical velocity, giving us more insight into the position of our robot. Regardless of how many different gadgets and sensors we may use, an important part of the code for this year's game will be automatic scoring, no matter how we choose to implement it.

As always, we hope to have this year's codebase more organized than the last, and efforts have been taken to refactor parts of our codebase to be more readable and easily workable. Additionally, although it is not necessary, we could use multithreading to separate, for example, hardware reads, OpenCV pipelines, etc. into their own separate threads, although our current state machine gives us an asynchronous structure which emulates multithreading fairly well, and implementing this would give us only a slight performance boost, particularly when running OpenCV pipelines.

Next Steps:

The most immediate changes to our codebase should be both working on refactoring as well as implementing bare bones for our teleop and autonomous routines. Next, we should work on a vision pipeline to classify the field's configuration at the start of the game, enabling the robot to navigate the wobble goal into the A, B, and C drop zones. Afterwards, the physics calculations and vision pipelines necessary to auto-shoot into the baskets can be made, starting with a mathematical model of the projectile.

Task: CAD a custom flywheel

Instead of using a grip wheel to launch rings we went with the approach to make a custom flywheel. The key concept of a flywheel is to maximize rotational inertia. This is done by putting as much mass towards the edge of the wheel as possible. To do this, a ring of ninjaflex was designed, from there, 5mm flaps were added as an experiment to see if it would give the wheel more points of contact to the ring. However, the wheel needs a center to be able to spin, so aluminum plates were added to sandwich the ninjaflex ring. To decrease the amount of mass not on the edges of the wheel, these aluminum plates were pocketed, leaving aesthetically pleasing curved spokes on the plates.

Next Steps:

The ninjaflex is to be 3-D printed and the aluminum plates will be milled on our CNC machine. Once that is done it will all be put together using M3 hardware.

Task: Design a mechanism to trasfer rings from the ground to a future ring launcher

The initial vision for this intake design was inspired by FRC team 1983’s Ultimate Ascent robot. The “ladder” pivots from the back of the robot to rotate out. The wheels in the front are very similar to the simple roller design, except here they extend out of the robot. The intial CAD was a very simplified model in order to get the idea across. After some discussion, it was decided that the design would be shrunk down as it was unnecessarily large.

After that, a more realistic CAD model was made, using aluminum side supports and REV extrusions. This was then taken to the chassis CAD model to check for mountabilty. There seems to be a spot on the front of the chassis that allows the intake to work as intended, however more testing is necessary.

Next Steps:

Physically build this intake in order to more acurately test for functionality.

Task: Layout a plan for auto paths this season

To begin, as you can see up above (a diagram that was generated on https://ftcchad.com/ ) our first auto path takes very little movement, and no turns whatsoever. This path assumes that on the robot we have some way to grab the wobble goal at the start of the match and can release it in a controlled manner during autonomous. In such, with the robot facing with the "front" of the turret and chassis facing away from the back wall, and the robot in the center of the outermost tape, the robot would use vision to figure out which of the 3 stacks of rings are present. After which, the robot will drive forward and park next to the correct spot, and turn the turret to release the wobble goal on the correct target location. To finish, all it has to do is drive backwards and end up on the shooting line.

After that is coded, we'll add in features gradually. First, we would look at going back and getting the second wobble goal first using odometry, then vision. Next, and by the time all everything already said has been coded, we should have our first launcher and intake done, making it evident that we should shoot them into the high goal from where we sit on the back wall, and then intake and fire the ring stack before moving on to moving the wobble goals. The final revision would to be to use vision to find and then subsequently pick up rings the human player puts in the field after the wobble goal segment.

Next Steps:

Get to coding!

Task: Model a projectile motion equation to approximate forward speeds of rings launched from a ring launcher

A key challenge in this year's game is finding the best possible position to launch rings to ensure optimal performance of the ring launchers. Part of this challenge includes approximating a potential forward speed for each ring as it is launched from the launcher itself. There was also height and distance constraints that needed to be taken into account before we could find these forward speeds. Modelling an equation to identify this forward speed would allow us to directly plug in this equation into the robot's code so it can automatically adjust itself to aim rings from an optimal angle and position.

In order to find the most optimal position and angle to launch the rings, we needed to first consider the angle of the launcher to be a variable to determine all possible forward speeds horizontally and vertically. We needed to look at the forward speeds both vertically and horizontally in order to attain the maximum distance (which would be tangential to the horizontal and vertical distance if we were to look at it like a right triangle). FTC constraints dictate that the maximum height a ring can be launched was 16ft we translated to 4.85 meters. While this was not a contant we inputted into our formulas, it was something for us to consider when we began. We knew that the height of our robot with the shooter mounted was roughly 0.41m and aiming to get the ring into the third level of the goals, we knew that the height the ring needed to reach was 0.88m. Subtracting the desired height from the initial height, we got 0.47m, and by placing that on one side of our projectile equation, we used simple algebra to find out that to isolate v0, 1/2(-a)t^2 needed to be subtracted from 0.47m for the vertical velocity. Since the final horizontal distance varies from launch to launch, we left it as xF (final horizontal distance) - 0 (inital horizontal distance) to reflect our steps for the vertical equation.

When we began planning our equation, there were 3 things we anticipated we needed to know. 1) Angle of launch - this was what we were intending to find but we wanted a formula so we wouldn't have to manually measure theta each time. 2) Initial vertical speed - this was another unknown which affected the distance our rings could travel, which, consequently, relied on the measure of the angles. Finally 3) time - there are two things we need to know about time. First, how long the ring stays in the air, and second how long it takes for the ring to reach zero vertical velocity (in other words, when does it reach its maximum height?) Another issue we needed to account for was how the end of our equation would be represented. Did we want the height of the third level goal to be the summit of the ring's arc or did we want it to be its final point? Since we knew that the ring were not being launched 0 meters away from the ground but rather 0.41 meters away, aiming for the goal to be the end of its arc past its apex would cause too much error in our model if we were to graph the ring's arc as a parabola. So, we settled for making the summit of our parabola be the third level of the goal. So, time in our equation was represented as t/2 since in a standard parametric equation, t for time represents the complete arc while t/2 cuts the arc off at the apex. With all this taken into account, we were able to model two different equations - one for the horizontal velocity of the ring and second for the vertical velocity of the ring.

Our equations were: Vertical: v0 = (0.47 - 0.5(-a)(t^2))/sinθ(t/2)) and Horizontal: v0 = (xF - 0.5(-a)(t^2))/cosθ (t/2)) t stands for time in seconds, a for acceleration due to gravity - 9.8 m/s^2 and xF for the final horizontal distance of the robot which will be calculated by the robot itself.

While having two unknowns in our equation in a concern, we plan to find the velocity of one, plug it into the equation for the other side and retrieve theta from there. We want theta to be the same for both the horizontal and vertical equation assuming that the distance they travel is the same.

Next Steps

The next step would be for us to plug in constants into our equations and check to see if the velocity and theta seem to be reasonable. We anticipate that these equations will undergo several changes as we continue to build the ring launcher. Even once the equation is finalized, we will need to figure out how to translate it into code and whether or not we can find values such as RPM and muzzle velocity in order to control our motor to provide us our desired launch.

Task: Create a prototype for a belt sander intake system

The so-called “FTC Legal” belt sander was an early iteration of the intake mechanism for this year's robot. It was composed of a belt, from a Ryobi belt sander, rev wheels wrapped in tape, to help center the belt, and a tensioning mechanism. The belt would provide friction, moving the disk game elements upwards towards the launcher mechanism. However, an issue we ran into was the distance between the bottom of the belt and the floor was hard to regulate, resulting in disks either not having enough space to be sucked up, or havag too much space and not enough friction to be dragged up. This was partially solved by replacing the belt sander belt with a Ninjaflex belt with flaps, which is the current iteration of the robots intake system, using many of the same parts and designs as the original “FTC Legal” belt sander.

Future plans include designing and constructing some form of leveling system, and a higher belt speed to more quickly collect disks. We are also considering using this sander design as an inspiration for a dual-tracked belt drive intake system and an elevator-like intake system with ninjaflex substituting for a traditional belt drive system.

Task: Build and prototype an intake system

One of the first intake systems we made was the Caterpillar intake assembly (Tetrix tread intake). The inspiration for this design came from an earlier bekt drive comprising of a sander (which you can read about in our earlier post). This was originally built off a c-channel extrusion with a motor attached to sprockets that drive treads. The purpose of this subsystem is to transport the rings from the field into the launcher loading area.

We first tested the assembly without the rubber bands and quickly realized that the treads couldn’t create enough friction to grip the ring and move it vertically. Our solution was to attach rubber bands within each tred piece. There were 2 reasons for this, the first being that rubber in general has high friction and good grip. The second reason is that the flinging rubber bands will conform to the shape of the ring at high speeds and drag the rings up the intake.

We did experience a few problems with the construction of the assembly. We found that the rubber bands would often get caught on the edges of the c-channel and either fly off at a high velocity, snap, or tangle and prevent the assembly from moving. Because of the way the band fits into a tread, there wasn’t a way to permanently attach the rubber band without damaging the thread, meaning we would have to scrap the idea or find a work-around. We eventually decided to rebuild the intake with REV extrusions because it would be more compatible with our robot and we could replace the large c-channel with the smaller REV extrusions.

Next Steps:

Although this prototype holds promise, we will continue to experiment with it and alternatives to find an alternative that doesn’t run the risk of tangling and disrupting the system.

Task: Design an intake with the NinjaFlex belt

So far we have made a few Intake assemblies including the belt intake and the Tetrix tread intake. However, as is Iron Reign tradition, we like to make systems that utilize custom parts to both help our robot’s aesthetic and functionality. To do this, we took aspects from the other two intakes to better design and make the one that is discussed in this post. To recap, the belt intake was a sanding belt on to barrels that spun at high speeds to pull in rings and the tread intake was made with Tertis tank treads with rubber bands and spun, in the same way, to grip and pull in rings.

The NinjaFlex belt intake takes the benefits of both systems without generating their issues. The NinjaFlex intake has the narrowness and form factor of the belt intake without the issues of the belt derailing which is caused by uneven pressure on the belt. Instead, the NinjaFlex belt intake is sprocket-driven with a custom belt to ensure that the belt stays on the rollers at all times as long as the two ends are aligned properly. Derailing was a big issue with the belt intake. Personally, I remember spending at least a few hours in total trying to get the belt to not fall off, with little success. That system would have needed much more work and improvement before we would have seen any results.

The NinjaFlex belt intake system also yields the benefits of the tread system in that the 3D printed belt provides sufficient grip on the rings in order to pull them onto the robot. Additionally, the NinjaFlex belt system also doesn’t use rubber bands as gripers that can tangle with nearby screws or protrusions, possibly causing the system to break. Instead, the belt has flaps which can also be changed or molded into different lengths or shapes. This brings up one of the biggest benefits, customizability. When we use 3D printed or CNC parts we enter this space of customizability which is always a good aspect because if a change needs to be made to a part, we can usually make a new custom part in a matter of days if not hours with our machinery which gives us a lot of flexibility in how we can build our robot.

Assembly-wise the intake is also super simple right now. It consists of 6 sprockets, 3 on each side that drive a belt with the sprocket spacing sits on to pulls in rings. The dimensions and specifics of how the belt was designed and made are in the post “NinjaFlex intake belt” but basically it’s just a belt with holes in it with the specific spacing of the REV sprockets. The motor right now has just been placed on one of the shafts but will be secured in a better location in the future, either parallel to the guide rails or perpendicular depending on how much space we have. If the motor is mounted parallel to the guide rails, then it will drive the belt with beveled gears, otherwise, it will be directly fitted onto the shaft.

Next Steps:

As mentioned previously, the motor has yet to be permanently mounted so that would be the next clear step and after that, there will likely be more testing and comparing of different intake systems. Then, we will interface the new intake with a ramp to see how we can assemble the two together to finish our intake system and start planning to put it on the robot. For now, though, we have made good progress.

Task: Update the model to plan Proteus' build

With our first qualifier being less than 2 months away, Iron Reign embarked on an ambitious project to create a robot with a circular chassis, an elevator-like intake system, and a fully automated launcher. While this robot is still in construction, we do have a name for it - Proteus. Named after the early-prophetic sea god who was also known for his versatility, this was the most fitting name for our robot given how flexible we needed to be this season and with only a few weeks left to construct a robot. In an earlier post, we detailed our decision to reuse our circular chassis in order to improve our robot's maneuvering abilities and get around other robot to avoid the traffic towards the goal posts. However, we are yet to decide which of our three intake systems to use as well as how the progression of our launcher might change considering that it is still in its CAD stage. To see how each of these intake systems look on the robot, we modelled the chassis design from the beginning stages and created multiple models to represent each launcher mounted on the robot.

Earlier in the season, we created a model of just the chassis itself to account for the fact that we are only reusing the chassis design from last year and nothing above it. The updated model still has the same base chassis design from the earlier model, but it now has three different iterations - one with the ladder intake, one with the caterpillar intake, and one with the elevator intake system (yet to be named). Since the elevator intake does not yet have a full-fledged design, we are holding off on a full robot model with it until we figure out how to make it compatible for a final design.

Next Steps

With our robot model in progress, we can now plan out all our steps ahead of time in CAD so that we will make less mistakes on the physical build. We will be updating the model as the season progresses.

Task: Physically build the ladder intake, based on the design in CAD

For the intake system of this year's challenge we first brainstormed several ways which a ring could be collected and transferred to the launching system. Through that and experimenting with CAD, the ladder intake system was developed. Essentially it functions by using the series of Omni wheels on its edge to collect the ring, and then pivot back up to the robot. As pictured below, the ladder intake will be mounted onto the back of the robot and pivot as needed to collect the rings.

Construction

The ladder intake was constructed using 8 REV extrusion bars connected by 6 plastic brackets, 2 servos, 7 Omni wheels, a shaft and its respective parts for the wheels to rotate on, a sheet of polycarb below the Omni wheels and shaft to support the rings, and 2 more brackets for the servos to be mounted onto. As shown in the picture below, the idea is for the rings to be reeled in by the Omni wheels and be held using the support of the sheet of polycarb below the shaft, and then be transported to their designated locations in the launching system by the intake pivoting back.

Testing

Although the system seemed promising on paper, it unfortunately did not work out as intended. When tested with some first draft versions of code, we found out that the system was unable to actually take in the rings, and instead could only hold them. There wasn't enough traction on the rings for them to be reeled into the system in the first place, which was an issue. We will use this experience to construct an intake that overcomes these issues moving forward.

Next Steps:

Start brainstorming a new intake mechanism possibly using some of the components of the current intake that can overcome the issues that hindered the ladder intake from functioning optimally.

Task: Begin designing a ring launcher

The initial vision for the ring laucher was to be a semi-circle in order to give the ring as much acceleration as possible. In this meeting, it was decided that instead it would be a quarter-circle for the following reasons: to save on space, since there will eventually also be an intake on the robot and a quarter-circle has been proven to give the ring enough acceleration, even if a faster motor is necessary.

With that decision made, the flywheel was placed in the CAD and the quarter-circle was brought into existance. There is a circular shaft in the center that will hold everything together, but the plate that the ring will rest on cannot be jointed to this shaft. This is because it has to clear the flywheel, so instead another aluminum plate will be placed below it to act as support. From there, walls were added to keep the ring within contact of the flywheel. These walls where also extended a bit beyond the quarter-circle, this is to prevent any variabilty in the lauching of the ring. Finally, a motor mount was extended out of the center aluminum plate to drive the flywheel with the use of a pulley and belt.

In the second meeting, some final design additions where made, namely screw holes were added(or removed, technically) from the plates and walls in preparation for 3-D prining and CNC milling. Additionally, any walls that were in the way of the belt driving the flywheel were split to make way for it.

Next Steps:

There are still many features to be added, such as a way to transfer rings from an intake to the launcher.

Task: Assemble the flywheel with the readily manufacured parts

Following the milling of the aluminum plates and the 3-D printing of the core of the flywheel, it is time to put it all together. The first step was to sandwich the ninjaflex core with the aluminum plates, and secure them together with long m3 screws. The plates have a spot for bearings, and those allowed for the addition of a 8mm circlular shaft. From there, the cut-out pulley was directly attached to the flywheel using more m3 screws. This pulley is how the flywheel will be driven, and it has a cutout to be able to fit bearing inside of itself.

Following the assembly was testing, initial spinning by hand revealed some shakiness in the flywheel. This is likely due to variability in any of the parts, as well as the bearings.

Next Steps:

Further investigate the reason for the shakiness of the flywheel when spinning, and modify the weight distubution as needed to correct any variability.

Task: Continue developing the ring launcher and do preliminary testing

Today we continued to further our progression on our ring launcher, finally getting to do some preliminary testing to see what the design might do. For starters, we started to get some of the walls off of the 3d printer which was the first piece of our flywheel launcher barrel design that started to come into real life. We also modified the pulley for the flywheel with the CNC that would eventually be used in the final construction. We had to do this because we want to be able to use our REV motors and driving belts to move the non-REV wheel. In order to make sure that we could do this we set up a machining path that would remove an inner circle of material from a standard pulley so that we can put bearings through it.

The machining of the pulley is actually fairly simple. All we did was set up a path that would mill a cylinder out of the pulley. What was more complicated was what we had to do before that since you can’t mount the pulley on the CNC since it doesn’t lie flat. Instead, we modeled and CNCed a divot for the pulley to fit into along with some holes for screwing the pully to the CNC. You can see both the divot and the final product above. This operation isn’t that difficult on the machine since it’s just plastic and wood but this is the first time that we have had to mill a divot to machine a part which is what makes it notable.

Then we put what we had together for the first time on a sheet of particleboard and spun up the wheel to see if we could even get a ring moving. We did get some success and the rings did launch several feet but we did have a few problems. Mainly that the walls were being held in place by people so they were moving and we couldn’t get enough grip on the rings. However, actually assembling the flywheel in housing will solve this problem. Honestly, we weren’t looking for problems in the first place though. This event would fall more under team bonding because we really just wanted to see a ring fly. We put in a lot of work and it was quite inspiring to see the ring actually move.

Next Steps

We still have a lot more manufacturing ahead of us. We still need to finalize the model and the CAM of all 3 of the plates in the barrel and 3d print more parts. We also still need to assemble and think about how we are going to get the rings into the launcher which will come and bite us in the butt at some point. For now, it was nice to see some progress as well as the first rings fly.

Task: Update the model to plan TomBot's build

With our first qualifier being around a month away, Iron Reign is currently in the midst of trying to put together a functional (or semi-functional) robot. In a previous post, we detailed the earlier stages of our CAD design. As of now, Iron Reign is still testing our intake systems but before we finalize the system we want to implement, we plan to construct a robot with just our launcher system mounted. The reason for this is that we have more or less finalized the CAD design for our launcher (which you can read about in one of our earlier posts) and before we can begin the actual assembly and mounting, we need to have it represented in our robot model.

So, we created a render with just the launcher itself mounted onto our robot Proteus. We anticipate that although the model will change substantially once an intake system has been mounted, the position of the launcher will be consistent and having this modelled allows us to plan out our articulations and strategy for scoring rings into the goalposts.

Next Steps

Once we have finalized which intake system we plan to use, the model will be altered accordingly to reflect these changes. As of now, this model will allow us to visualize and implement the addition of our launcher system which will streamline our ability to plan out how we want mount an intake in the future.

Task: Finalize code changes prior to the PvC scrimmage

Leading up to the scrimmage, many code changes happened, mostly in the area of auton. To start, I tried to run 10 runs of every auton path, to check reliability. Time and time again though, the robot would go off towards joneses, crash into the far wall, or knock over the wobble goal when placing it.

To address the robots tendency to not want to go straight forward, we wanted to start to use VUforia and the vision targets to help us know our relative angle. However, we had problems with VUforia, as it wouldn’t detect much past what was immediately in front of it. The problem probably has something to do with our abysmal lighting conditions on our field, and while there are solutions, we didn’t have time. So, we went analog and used a distance sensor on the front right of our robot, facing right. This was to basically just do wall following, with one ace up our sleeve. We decided to modify our existing movePID that uses the IMU, to make a moveGenericPID, where it could be used for more generic purposes, like this one. We pass the method our target distance, our current distance, plus all the other generic move variables, and with a bit of fiddling with input multipliers, it worked.

The next issue caught me off guard, and put me into a state of confusion. Or I guess rather. In all seriousness, all I needed to do was decrease the distance it went for the far. To go into a little more detail on the final issue, it was caused by multiple things at the same thing. Firstly, the arm that holds the wobble goal is shorter than the robot; its end is inside the circumference of the robot when the base and turntable are lined up. That lined up position is how we start, so it had been where the arm just turns to one side to drop it off. Even swung out, the wobble goal is still 40% over the robot, as to where the robot lets go of it and it topples over. We decided to fix it by turning the robot in the opposite direction the arm is turning, at the same time. Then we aren’t losing time to it, and it's a clean drop.

Next Steps

Given that we have attended to all outstanding issues prior to the scrimmage, the next steps mainly include testing the robot out during practice runs and being prepared to drive it through the week for all matches.

Task: Expand the ring launcher to begin accomadating for a controlled system of firing the rings

The first step in accomplishing this task is to expand the center aluminum plate to almost a complete semi-circle. From there the back of it was expanded to allow for a place for the rings to sit. Offsets were added to accomadate for any new walls that will be added. Finally, at the back is a place for a servo to be mounted, this servo will eventually be used to rotate rings into the flywheel.

In terms of the center shaft assembly, the goBilda hyperhubs were removed as there were unnecessary, however the holes made for them were kept, in case they are ever needed again. Spacers and bearing were added to allow for clearance and minimal friction.

Next Steps:

Finalize, the left side of the ring launcher, walls need to be added to prevent rings from falling off and a trigger needs to be attached to the servo to rotate rings into the flywheel.

Task: Finalize the ring launcher design

The main thing here is a huge wall on the left to guide rings to their resting position at the back of the ring launcher. But before that, the ring trigger needs to be made first, as it needs to be worked around. The trigger contours the ring perfectly by design, and only needs to rotate about 40 degrees to put a ring within contact of the flywheel. With that done, the guide wall was designed around it, encompassing the enitre left side and connecting to the back center.

The final step here is to create a better motor mount. This will be a seperate part that will then be attached where the original motor mount was. This is being done to more easily allow for the mount to be slotted: doing so lets the motor's position be shifted to keep the belt it drives as tight as possible.

Next Steps:

With the first iteration of the ring launcher design completed, it is ready to be manufacuted.

Task: Improve the Trajectory Calculations

As mentioned in our earlier posts, one of the biggest control challenges we face in this year's season is identifying a equation to model how the path of a ring launched from our launcher is affected by its angle of launch. 2 weeks ago, we were able to create a starter equation to model this trajectory. However, this time, we want to be able to identify time as not a variable but as a fixed constant and values for RPM, muzzle velocity and rotations per second of a motor. We want to be able to list these values in anticipation of our virtual meeting with the Dallas Personal Robotics this coming week where we will present both our Flywheel Launcher and the calculations we have derived so far. We anticipate that these calculations will be subject to change and our error as we go about the process of identifying how best to put our equations into code and as such, the values in this post are not final in any way.

Our main purpose for modelling this equation is to correct the efficacy of our launcher - primarily what motor it uses and how the motor's PID values need to be fine tuned in order to provide us an ideal launch. In our previous post, we stated that the variables and constants we needed to derive the equations were:

\(\theta\) - angle of launch

\(hv_0\) - initial horizontal velocity of launch

\(hv_0\) - initial horizontal velocity of launch

\(h\))- height of goal at the third level which we know to be 0.88m

\(d\)) - the horizontal distance between the goal and the robot

\(g\) (approximately \(9.8 \frac{m}{s^2}\)) - acceleration due to gravity

We initially created two equations - to represent the initial velocity of the robot horizontally and vertically. However, one key component which we originally considered to be manually calculated was time. In order to isolate time as a fixed variable, we needed to find the amount of time in seconds it would take a ring launched from the robot to reach 0 vertical velocity. We knew that for any shot that crosses through the goal with zero vertical speed, the ring needed to have an initial upward velocity such that the acceleration due to gravity brings it to zero vertical velocity at the point it reaches our target height. Regardless of what the horizontal component is, target time in this situation is governed by solely by gravity and vertical distance. Although we had initially modelled our equations to reach the summit in order to make the actual angle of launch more solvable since that would mean that we didn't have to consider "balancing" the initial height of the robot to derive the value of \(\theta\). However, seeing as the summit is the center of the portion of the trajectory with the least vertical travel for a given span of time or distance, we would not only be able to isolate time but also find \(\theta\) with the least vertical error. As such, we modelled an equation for time which can be found as shown below.

\[\displaylines{t = \sqrt{v_0/(0.5* \(g\))}}\]

In addition to time, we also needed to find the RPM of the motor of the launcher, for which we needed to find the circumference of the launcher, which was 0.48066m. From here, we found the radius to be approximately 0.076m, which we could use for our RPM equation which was RPM = v = \omega r, with r representing 0.076m. To find muzzle velocity, we plan on using our velocity formula as of now but this is likely to change as we continue to inspect our equation. Here are the overall equations we have developed so far now that we know how to look for time at the apex. \[\displaylines{d/cos(\theta)(t/2) = hv_0 \\ ((0.88 - 0.41) - 0.5(a)t^2)/sin(t/2)= vv_0, t = \sqrt{v_0/(0.5* \(g\))}}\]

Next Steps:

Using these equations, we plan to be able to identify angle of launch, RPM and muzzle velocity for a range of distances away from the goal. Mainly, we plan to derive values for a very specific range (likely 2 to 2.5m) to present our calculations as well as our equations to Dallas Personal Robotics Group in the upcoming meeting on Tuesday.

Task: Build and prototype the Flywheel Launcher

For this years new season we used an innovative flywheel-based launcher to score the disks into the goal. After 3 weeks of work, we also managed to come up with a name for it - The RingSlinger 9000. Any posts referring to our flywheel launcher refer directly to the Ringslinger itself. This launcher uses the properties of rotational inertia to propel the game pieces along a carefully calculated, fixed trajectory to ensure that the disks have the same launch trajectory every time, allowing both automation and driver control to more simple. The assembly is physically constructed from several sheets of aluminum and one sheet of polycarbonate, modeled by Jose and cut on our CNC mill. The spacers between the sheets are made of nylon due to its high strength and low friction, and we chose to use a custom ninjaflex ring around the CNC milled flywheel to ensure that the wheel could transfer the maximum amount of kinetic force to the disks. The launcher is designed in such a way as to impart rotational energy on the disks, spinning them. This helps maintain a constant trajectory, similar to how an NFL Quarterback spins the football when scoring a touchdown pass, or how the grooving on a rifle spins a bullet, ensuring in-flight stability. In tests, our design proved to be mostly effective, launching disks along a consistent trajectory. Our first firing test was during our video meet with the DPRG, and with a few tweaks, it was performing up to standards. However, there were some issues that needed to be addressed - mainly, we need to complete further testing to see if any of the rings experience damage as a result of our launch, where the general area the rings tend to cluster at, and fine-tuning an equation to model the launch. Correcting these issues will make the accuracy of the RingSlinger that much more accurate.

Next Steps:

Future plans to expand upon this design include integrating a voltage regulation module, to ensure that the disks are always spun at a constant velocity. In tests, we noticed that as time in a round passed, the drop in main battery voltage caused the disks to be launched at a slightly slower velocity, not enough to phase a human driver, but enough to render automated shooting protocols inaccurate. To remedy this, we will find out the lowest point the battery will reach during the course of a match, and regulate the voltage being fed into the flywheel motor to not surpass the aforementioned "low" voltage during the match.

Task: Design new parts to better mount the ring launcher and encoder

First thing to do in this CAD session is to design a secondary mounting point for the ring launcher. To do this, the existing mount was projected and any unecessary parts were removed. Only the holes for adding the REV extrusion as well as the holes for encoder pivot were left.

The next thing to design was a mount for the encoder, as it needs to be prevented from rotating with the shaft. The closest stationary location was the REV extrusion on top of the GoBilda U-channel. This part has three holes at the bottom to be mounted on the REV extrusion, as well as a hole at the top to reach the encoder.

Next Steps:

As for manufacturing, we need to mill out the ring launcher mount and 3-D print the encoder pivot and holder. As for programming, the new encoder should help with aligning the ring launcher.

Task: Correct the trajectory calculations after the DPRG meeting

In the past week, we've been experimenting with a series of equations to derive the angle of launch of our flywheel launcher when we need it to travel a certain distance. 2 days ago, we were able to present the calculations we'd derived so far to Dallas Personal Robotics Group. After feedback from DPRG and a little more testing ourselves, we've discovered the following corrections we need to make to our equation. For reference, this is a correctional post regarding our earlier calculations - you can find versions of our earlier equations and calculations in our previous posts.

Time

One of the biggest fixes we needed to make to our equation was identifying how to derive time as a fixed variable. We wanted to be able to find the exact time in seconds it would take for our launcher to launch a ring at 0 vertical velocity. We needed this because we knew that for any shot that crosses through the goal with zero vertical speed, the ring needed to have an initial upward velocity such that the acceleration due to gravity brings it to zero vertical velocity at the point it reaches our target height. Regardless of what the horizontal component is, target time in this situation is governed by solely by gravity and vertical distance. As such, finding time at 0 vertical velocity would allow us to model an equation for the summit of the ring's trajectory, which is where we expect the goal post to be in order to reduce variability and error in our calculations. This understanding allowed us to create the following equation for time with h representing the height of vertical travel:

\[\displaylines{t = \sqrt{h/(0.5* g)}}\]

Initial Velocity

Initially, we had planned on solving for the initial vertical velocity of the ring then plugging into the equation for horizontal vvelocity, work backwards and find angle of launch. However, in order to have the most accurate trajectory possible, we expect the horizontal and vertical velocity to be varying, especially since the vertical velocity is affected by gravity and the horizontal isn't. Thus, we expect the vertical and horizontal initial velocity to look like the following, wherein t is time, initial vertical velocity is v_0 and initial horizontal velocity is h_v0:

\[\displaylines{v_0 = g*t \\ h_v0 = d/t}\]

Muzzle Velocity

Initially, we had planned on using velocity on its own for muzzle velocity. However, now that we have two initial velocities, our equation for muzzle velocity changed to look sort of like the Pythogorean Theorem with us solving for c, since the muzzle velocity represents the "hypotenuse" or trajectory in this case, mV representing muzzle velocity.

\[\displaylines{mV = \sqrt{v_0^2 + h_v0^2}}\]

Initial Height of Launch

Previously, we measured the height of the robot - 0.41m - to be our initial height of launch. However, one issue with the vertical travel is that if we take 0.41 to be a variable which is affected by \(theta\) then we need to figure out how much that change is for the vertical travel distance - an error bar or the design of experiments chart might work well for this so we can make sure angle of launch doesn't confound our initial measures for time and muzzle velocity since both of which rely on 0.47m (the height of travel taken by subtracting the height of the robot from the height of the goal) being constant which in turn relies on 0.41m.

Fixed Values

Since we know the height of travel to be 0.47m and \(g\) to be 9.8 m/s^2, using our time equation, we found time to be 0.31s. Using time, we could then find the initial vertical velocity to be 3.055m/s and horizontal velocity dependent on the distance of the robot away from the robot, which we take to be our explanatory variable.

Our equation ultimately stays the same but the methods we used to calculate time and initial velocities have now changed, which should change our final values substantially. In our latest post, we had a set of very different values in our meeting with DPRG. However, with these edits, we now have the following calculations (which we simplified by plugging into a spreadsheet to get automated values.

In order to sanity-check our calculations, we also derived the following parabola to represent the arc of the trajectory:

Next Steps:

Our immediate next steps are to model initial height as a function of \(theta\). Since we know that initial height is susceptible to change as the elbow of the robot drops and raises in accordance with angle of launch, being able to model initial height as a function will allow us to reduce all possible sources of error and find an accurate measurement of trajectory calculations. This will likely require another process like the one we did here as we attempt to model initial height as a function. W'd like to thank DPRG for all their feedback and for their help in allowing us to fine-tune these calculations!

Task: Derive And Translate Trajectory Calculations Into Code

To ease the work put on the drivers, we wanted to have the robot automatically shoot into the goal. This would improve cycle times by allowing the drivers, theoretically, to shoot from any location on the field, and avoids the need for the robot to be in a specific location each time it shoots, eliminating the time needed to drive and align to a location after intaking disks.

To be able to have the robot automatically shoot, we needed to derive the equations necessary to get the desired \(\theta\) (angle of launch) and \(v_0\) (initial velocity) values. This would be done given a few constants, the height of travel (the height of the goal - the height of the robot, which we will call \(h\)), the distance between the robot and the goal (which we will call \(d\)), and of course acceleration due to gravity, \(g\) (approximately \(9.8 \frac{m}{s^2}\)). \(d\) would be given through either a distance sensor, or using vuforia. Either way, we can assume this value is constant for a specific trajectory. Given these values, we can calculate \(\theta\) and \(v_0 \).

However, without any constraints multiple solutions exist, which is why we created a constraint to both limit the number of solutions and reduce the margin of error of the disk's trajectory near the goal. We added the constraint the disk should reach the summit (or apex) of its trajectory at the point at which it enters the goal, or that it's vertical velocity component is \(0\) when it enters the goal. This way there exists only one \(\theta\) and \(v_0\) that can launch the disk into the goal.

We start by outlining the basic kinematic equations which model any object's trajectory under constant acceleration: \[\displaylines{v = v_0 + at \\ v^2 = v_0^2 + 2a\Delta x \\ \Delta x = x_0 + v_0t + \frac{1}{2}at^2}\]

When plugging in the constants, considering the constraints mentioned before into these equations, accounting for both the horizontal and vertical components of motion, we get the following equations: \[\displaylines{0 = v_0sin(\theta) - gt \\ 0^2 = (v_0sin(\theta))^2 - 2gh \\ d = v_0cos(\theta)t}\] The first equation comes from using the first kinematic equation in the vertical component of motion, as the final velocity of the disk should be \(0\) according to the constraints, \(-g\) acts as the acceleration, and \(v_0sin(\theta)\) represents the vertical component of the launch velocity. The second equation comes from using the second kinematics equation again in the vertical component of motion, and again according to the constraints, \(-g\) acts as the acceleration, \(h\) represents the distance travelled vertically by the disk, and \(v_0sin(\theta)\) represents the vertical component of the launch velocity. The last equation comes from applying the third kinematics equation in the horizontal component of motion, with \(d\) being the distance travelled by the disk horizontally, \(v_0cos(\theta)\) representing the horizontal component of the launch velocity, and \(t\) representing the flight time of the disk.

Solving for \(v_0sin(\theta)\) in the first equation and substituting this for \(v_0sin(\theta)\) in the second equation gives: \[\displaylines{v_0sin(\theta) = gt \\ 0^2 = (gt)^2 - 2gh, t = \sqrt{\frac{2h}{g}}}\] Now that an equation is derived for \(t\) in terms of known values, we can treat t as a constant/known value and continue.

Using pythagorean theorem, we can find the initial velocity of launch \(v_0\). \(v_0cos(\theta)\) and \(v_0sin(\theta)\) can be treated as two legs of a right triangle, with \(v_0\) being the hypotenuse. Therefore \(v_0 = \sqrt{(v_0cos(\theta))^2 + (v_0sin(\theta))^2}\), so: \[\displaylines{v_0sin(\theta) = gt \\ v_0cos(\theta) = \frac{d}{t} \\ v_0 = \sqrt{(gt)^2 + {\left( \frac{d}{t}\right) ^2}}}\]

Now that \(v_0\) has been solved for, \(\theta\) can be solved for using \(sin^{-1}\) like so: \[\displaylines{\theta = sin^{-1}\left( \frac{v_0sin(\theta)}{v_0} \right) = sin^{-1}\left( \frac{gt}{v}\right) }\]

In order to be practically useful, the \(v_0\) previously found must be converted into a ticks per second value for the flywheel motor to maintain in order to have a tangential velocity equal to \(v_0\). In other words, a linear velocity must be converted into an angular velocity. This can be done using the following equation, where \(v\) = tangential velocity, \(\omega\) = angular velocity, and \(r\) = radius. \[\displaylines{v = \omega r, \omega = \frac{v}{r} \\ }\] The radius of the flywheel \(r\) can be considered a constant, and \(v\) is substituted for the \(v_0\) solved for previously.

However, this value for \(\omega\) is in \(\frac{radians}{second}\), but has to be converted to \(\frac{encoder \space ticks}{second}\) to be usable. This can be done easily with the following expression: \[\displaylines{\frac{\omega \space radians}{1 \space second} \cdot \frac{1 \space revolution}{2\pi \space radians} \cdot \frac{20 \space encoder \space ticks \space per \space revolution}{1 \space revolution} \cdot \frac{3 \space encoder \space ticks}{1 \space encoder \space tick}}\] The last \(\frac{3 \space encoder \space ticks}{1 \space encoder \space tick}\) comes from a \(3:1\) gearbox placed on top of the flywheel motor.

To sanity check these calculations and confirm that they would indeed work, we used a desmos graph, originally created by Jose and later modified with the updated calculations, to take in the constants used previously and graph out the parabola of a disk's trajectory. The link to the desmos is https://www.desmos.com/calculator/zuoa50ilmz, and the image below shows an example of a disk's trajectory.

To translate these calculations into code, we created a class named TrajectoryCalculator, originally created by Shawn and later refactored to include the updated calculations. To hold both an angle and velocity solution, we created a simple class, or struct, named TrajectorySolution. Both classes are shown below.

public class TrajectoryCalculator {
        private double distance;

        public TrajectoryCalculator(double distance) {
            this.distance = distance;
        }
    
        public TrajectorySolution getTrajectorySolution() {
            // vertical distance in meters the disk has to travel
            double travelHeight = Constants.GOAL_HEIGHT - Constants.LAUNCH_HEIGHT;
            // time the disk is in air in seconds
            double flightTime = Math.sqrt((2 * travelHeight) / Constants.GRAVITY);
    
            // using pythagorean theorem to find magnitude of muzzle velocity (in m/s)
            double horizontalVelocity = distance / flightTime;
            double verticalVelocity = Constants.GRAVITY * flightTime;
            double velocity = Math.sqrt(Math.pow(horizontalVelocity, 2) + Math.pow(verticalVelocity, 2));
    
            // converting tangential velocity in m/s into angular velocity in ticks/s
            double angularVelocity = velocity / Constants.FLYWHEEL_RADIUS; // angular velocity in radians/s
            angularVelocity *= (Constants.ENCODER_TICKS_PER_REVOLUTION * Constants.TURRET_GEAR_RATIO) / (2 * Math.PI); // angular velocity in ticks/s
    
            double theta = Math.asin((Constants.GRAVITY * flightTime) / velocity);
            return new TrajectorySolution(angularVelocity, theta);
        }
    }
    

public class TrajectorySolution {
    private double angularVelocity;
    private double theta;

    public TrajectorySolution(double angularVelocity, double theta) {
        this.angularVelocity = angularVelocity;
        this.theta = theta;
    }

    public double getAngularVelocity() {
        return angularVelocity;
    }

    public double getTheta() {
        return theta;
    }
}

Next Steps:

The next step is to use PID control to maintain target velocities and angles. The calculated angular velocity \(\omega\) can be set as the target value of a PID controller in order to accurately have the flywheel motor hold the required \(\omega\). The target angle of launch above the horizontal \(\theta\) can easily be converted into encoder ticks, which can be used again in conjunction with a PID controller to have the elbow motor maintain a position.

Another important step is to of course figure out how \(d\) would be measured. Experimentation with vuforia and/or distance sensors is necessary to have a required input to the trajectory calculations. From there, it's a matter of fine tuning values and correcting any errors in the system.

Task: assemble different intake prototypes

Today we worked on different intake systems to place the rings in the launcher. We finished our first prototype for a belt type intake and lift. The 3d printed belt was able to slide rings along a vertical piece of polycarb to place rings into the launcher. The speed of the motor and belt makes this one of our quickest intake and delivery prototypes. Our other prototype was a spatula shaped "intake" that would scoop up disks, and flip them upwards into a basket on top of the launcher. We used aluminum CNC'd into a curved spatula that would perfectly fit around the disks to ensure an accurate launch. Rubber bands pull the spatula upward, where it hits stoppers and launches the rings upwards. This prototype created semi consistent flips, but it was hard to gauge how far down to pull the spatula to give a desired launch height. A problem with this method is the many different factors that can be changed to give an optimal launch. Different launch angles, distances from the launcher, rubber band tensions and lengths. This flipper would involve a lot of experimentation that would result in mostly failures. This method also requires a lot more driver skill to scoop up the relatively small disks.

We also tested our fully assembled launcher - the Ringslinger 9000 - with working code. We wanted to measure how consistent our launches were by shooting multiple rings at a target and measuring the furthest distance between impact points. We used flour on a flat surface to show where the rings were hitting, then circled the clusters for our trials to get an approximate radius of error. We found that our launches were mostly consistent within a small radius, but had outliers that were hitting the exact same outer lying spot. This indicates a consistent flaw with our launcher and requires a closer look at how it moves and launches the rings. We also repeated this test by identifying where the rings tended to cluster when they had been launched beyond the length of the goal-post - even though the Ringslinger 9000 was not supposed to launch rings at such a height, identifying where it tended to cluster after landing also allowed us to evaluate its general launch patterns and accuracy.

Next Steps:

The belt system can easily grab disks and brings them to the other end of the ramp very quickly. While it works well when we test it with our hands, we need to create a rigid structure to connect the belt and ramp, which will be mounted on the chassis. This will allow us to see how the belt will need to pivot to grab rings, and if our current belt still maintains grip without human assistance. We will also take a closer look at our launcher to see what's different about our outlier launches.

Task: Set up FTC Dashboard

We wanted to setup FTC Dashboard for graphing, configuration, vision, and later on, odometry. FTC Dashboard enables graphing of numeric variables, which can simplify PID tuning enormously through plotting the current position/velocity and the target. Additionally FTC Dashboard enables real-time editing of configuration variables, and in the context of PID tuning, this enables PID constants to be edited on the fly. With the later goal of implementing odometry for localization, FTC dashboard can be used to draw the robot's pose (position and heading) on a canvas, to easily confirm the accuracy of our odometry calculations. Dashboard also allows for images to be sent, allowing us to also debug our OpenCV vision pipeline.

We used FTC Dashboard during this coding session to tune the coefficients of our newly created flywheel velocity PID loop. This would ensure that our flywheel would be able to maintain the desired angular velocity we want it to, in order to consistently shoot the disk into the goal using our trajectory calculator.

Next Steps:

The next step is to harness the power of FTC Dashboard to verify our odometry calculations by drawing the robot's pose information onto the canvas, using vectors/arrows to signify the base's heading, the turret's heading, and the bearing from the robot to the goal. This would point out any glaring errors in our odometry calculations, and would serve to visually represent the degree of error our calculations would naturally experience as a result of slippage and other factors.

Task: review the progression of matches in our latest scrimmage

We participated in the “Pink v. Cyan Remote Scrimmage” over the week, wherein we submitted our matches at an appropriate amount of time before the cutoff time. Doing this scrimmage has given us good insight into how to tune the performance of what is on the robot already, and what needs to be added. We submitted the standard 6 matches, and I want to go in depth for each.

Before I delve into the weeds, I would like to explain our hypothetical perfect run for these matches. In auton, since we aren’t using vision quite yet, we had the robot always assume a 4 stack. The robot should put the wobble goal we are holding in the start ibn the appropriate corner tile, then backup to park on the line. In teleop we should retrieve the second wobble goal and put it across the line. With this all such that we can, in the endgame, put both of the wobble goals over the back wall. So therefore, in a perfect run, we could have 60 points max. An example can be seen in the video above.

Match 1: Starting off on the wrong foot, when we started auton things looked fine. However, our pink decorations on the front of the robot got caught in the front caster wheel, making us veer off and hit the wall. We were able to re-orient the robot since the next few steps of the auton were based on the imu. However we didn’t park due to being off of the expected final position of the first movement. During teleop we successfully moved both of the wobble goals over to the other side of the shooting line, and then in teleop we just barely ran out of time putting down the second wobble goal over the back wall.

Match 2: We got lucky in the second round and got the preferred 4 ring stack. However, we couldn’t make use of that luck due to a driver error when selecting the auton-- auton did not execute. So in teleop, we moved both wobble goals over to the correct side of the shooting line. Then, in the endgame, we successfully moved one wobble goal over the wall. The second we ran out of time trying to grab.

Match 3: This time around, we had the opposite happen from the last round in auton. The rings randomized to be a 1 stack, but auton performed perfectly. Teleop was nominal, but endgame posed a new problem. When trying to put the wobble goal over the wall, it got stuck on the turret, seen in the video below at 2:44. This costed us enough time to have us not score any of the wobble goals

Match 4: this is the video at the top of the post, because it was a perfect match.

Match 5: Like match 3, we were randomized 1 ring, and auton performed perfectly. Unlike match 3, teleop and endgame were normal, with us scoring 1 wobble goal.

Match 6: Final match, auton almost worked. The wall-following messed up at the very end of the first run, making us drop the wobble goal just out of the box, and miss parking. In teleop/endgame, we almost had a repeat of match 3, but we were able to shake off the wobble goal and score one.

To start on the subject of lessons learned, It is obvious we should practice more. Driver practice has always been a weak area for us.(Having said that, for the amount practiced the driver did excellent). One thing the driver should not have had to account for is that possibility to lodge the wobble goal on the robot. This is subject to change anyways, as when the launcher is mounted on the robot, the wobble gripper is going to have to move. Not only move, but change; the current gripper has too tight a tolerance to be used effectively. It isn’t possible to have it stay the way it is when drivers will also be tasked with picking up rings. Finally, we learned that we need to work out the kinks in the wall following what happens at the beginning of auton. We only really did this, because we are still working on a better way to square the IMU to the field, and the human error was too great and cumulative on that far run to have it work reliably.

Next Steps

Execute the solutions to the problems found.

Task: Go over our 5 intake iterations

This season, we experimented with 5 gripper models - both for our robot in three days project and for our competition bot. While we do not plan on using all 5 of these models, they allowed us to effectively implement the engineering process within our build season. Experimenting with each intake helped us to identify the potential of each design as well as how two individual designs could be combined to create a more efficient one. Each of these designs has its own article but this is just a summary of all of our intake designs so far.

1)Archimedes Intake

This was one of our first designs and it was based on an Archimedes screw. A screw shaped surface would draw the rings from the fields and directly to the launcher. While this would have been a great feeder, our primary issue was that would essentially be a slower system which could likely only draw in ring at a time so it never progressed past its CAD stage.

2) Ladder Intake

This gripper functions with a series of omniwheels mounted in between two rev extrusion bars, which in turn are connected to a ladder-like assembly with a control hub mounted on the first rung of the ladder and to the wheels. As the wheels rolled, they would slide on top of the rings and roll them into the system. The issue with this system was that it had significant delay in "rolling" the rings in since if the omni wheels spun too fast, they would lack the tracton to "grip" onto the wheel.

3) Belt Sander Drive

This system was far more simplistic than our earlier ones and had a faster intake speed during testing too. The actual drive would be mounted onto the robot with the "back" of the system sliding over the rings and carrying them across the conveyor belt to the top of the robot. Despite its efficacy, it had one main issue - it didn't have the gription needed to ensure the rings slid across the belt.

4) Caterpillar Intake

Luckily, the gription issue could be resolved pretty easily with the caterpillar intake. This system was dual tracked unlike the first one, and had rubber bands threaded through the tetrix tracks to improve gription with double the power. Ultimately, this was a pretty successful issue but it did not have as much speed as it could have and lacked the signature Iron Reign charm.

5) Ringevator Ultra Flex Unlimited Intake

This gripper, the Ringevator, for short was a combination of our two previous best systems - the belt sander drive and the caterpillar. It possessed the mono-drive from the belt sander and similarly drew in rings from its back and carried them across a conveyor belt to the top of the robot and like the caterpillar, had a means for increasing friction with the surface of the rings. While the caterpillar intake did this with rubber bands, the Ringevator accomplished it with ninjaflex "fins" layering the "belt" to sweep in the rings. Both sides of the intake are covered with polycarb to encase the conveyor built internally and to ensure the rings don't fall off when picked.

Next Steps

Now that we have analyzed all of our intake designs so far, it will be easier for us to streamline the best design to mount on the robot. While the ringevator seems to be our best choice, we still need to conduct further testing to see which one is the most efficient.

Task: Create a system to test our materials to better understand their grip potential

Here at Iron Reign, we're used to using off-the-shelf materials for our robot. For this season, these include pillowcases (front and back) and an Einstein wig, since we are looking for materials with lesser grip. However, we need to do a thorough investigation of these materials before we can determine their efficacy on the robot.

Specifically, we plan to implement these parts on a ramp connecting the intake and our launcher. Although we have not yet mounted our intake onto the robot, we expect to have a launch leading down from the intake to the launcher to enable to ring to slide down and then be launched. This requires a material with very less grip and a lot more slip. However, before we can decide which material would have the best grip, we need to test them to determine their on-robot properties. To do this, we will implement a slip test as shown below.

The main thing that we want to test is the amount of energy they have while sliding and then the amount of energy they lose upon collision. We plan to test this through the coefficient of friction of the mitts. Simply put, we will place the ring on top of the of the pillowcases/wig and will tape down the material being tested on a flat surface. Then, we will lift the surface and using simple inverse trigonometric properties, we will calculate theta, the angle at which the stone begins to slip from the material. The bigger the angle, the higher the friction coefficient of the material, which equates to it having better grip. Since we are looking for a material with the least grip possible, we will be looking for the material with enables the ring to slide down at the smallest angle.

Next Steps

With our testing planned out, we will next begin documenting the angle at which the ring slips from each type of material. The calculations from the actual testing, including the equation we used, will be inputted into a separate post.

Task: Summarize the key components of Ring Launcher 9000

A ring launcher is more than just a flywheel; it needs a barrel to give the ring a path to move through. A 90 degree barrel is the best fit for ROBOT as the intake will take up the other half of the robot. The plan is to later on add an indexer to transport rings from the intake to the barrel in a way that can be controlled, that is, allowing the driver to manually choose when to let rings into the barrel.

The barrel design looks simple, but there are lots of hidden things making it work as intended. For one, the motor driving the flywheel is attached via a slotted motor mount. The mount is then placed directly on the center plate through an extension to the center plate. Additionally, there is a plate below the one that the ring travels on top of. This plate is used to keep the shaft in place, it follows a similar shape to the others to preserve strength, as it is half of what keeps the flywheel in place. The bottom plate also supplies support to the center plate, this is due to the fact that the center place is not attached to the flywheel, instead it has 3mm of clearance in case of any vibration the flywheel may have. Finally, at the exiting end of the barrel, the side wall extends linearly to ensure the ring doesn’t spin off its intended path.

Over to the other side of the barrel is the ring feeder. A huge nylon wall guides the rings into the ring flipper. The ring flipper is composed of a a servo with a custom made flipper to push rings into the flywheel.

Next Steps:

With everything milled out and 3-D printed, the next step is to take this to programing as the idea is to have the ring laucher be almost completely automated.

Task: Test the intake now that it is on the robot

Today we performed proper field testing of the Launcher subsystem. While we have done many tests in the past with it, this was the first time we ran arrays of consecutive shooting with the launcher on the robot. Doing this meant some small modifications that led to an evolution of the “trigger” of the subsystem. Performing the tests was one of my friends, who we let drive the robot to gauge interest in being in the robotics program, and his ability driving.

First, lets cover the trigger evolution, which is what lets us more smoothly conduct the tests. As it stood, and as pictured above, the trigger was a single spike-like piece of 3-d printed nylon attached to a servo. Wherein it pushes rings into the flywheel to shoot them. It’s main body follows the contour of the shooter’s body that is directly above and below it, as to conserve space. We initially thought that this would be feasible to keep so small, however, we noticed in previous testing that the rings did not chamber correctly when fed by the in-built gravity-fed magazine. The ring would fall onto the trigger, and tilt backwards, leading to the ring getting jammed behind the trigger when it tried to return to its original position. That effectively meant that we could only shoot one ring before we would have to physically reload. To combat this, it was devised that a small plate would have to be added to the top of the trigger, protruding at the back top of the trigger. Since it was just me and the driver there that day, I fashioned a mock-up out of cardboard and painters tape, as seen in the video below. You might also notice a cardboard piece in front of the rings in the magazine, and this was another impromp-to thing, which addressed the unforeseen movement of the rings in the magazine during on-bot use. This ended up, later that night, for the resident CAD/CAM expert, Jose, to make adjustments to the model. The following day, a version of the trigger was printed that had the plate, and was tested/proofed to see that it worked as expected.

Moving on, let's talk performance. The shooter, after replacing the motor gears and removing an elastic band from the arm, did wonderfully. When firing consecutively in the same position, the effective spread of the shots was tight enough to actually hit whichever goal was being aimed for. The driver also came up with a test, where he would shoot a goal, move, and then return to the same position, to see if the turret auto-turn was fine enough. Turns out, having a different subsystem with different weight distributions means that the PID coefficients aren’t properly tuned. Of course this was to be expected, but it wasn’t too off, suggesting that all that needs to be done is to adjust ki and kd.

Next Steps:

Tune said coefficients, make a final version of the magazine retainer, and further test the driver.

Task: Account For Initial Height

In the previous trajectory calculations post, "Derive And Translate Trajectory Calculations Into Code", we did not take into account how the length of the launcher would effect our calculations. In reality, the height the disk would have to travel would be shortened by the launcher, since when titled at an angle the vertical distance would be shortened by \(lsin(\theta)\), where \(l\) represents the length of the launcher. This is because our launcher is mounted on a hinge, and therefore the rotation of the launcher affects the position where the disk leaves the launcher.

To take this into account, we would have to add \(lsin(\theta)\) to the vertical distance the disk has to travel, however, \(\theta\) depends on this distance as well. To solve this problem of circular dependency we can use an iterative method. This is because when \(\theta\) is calculated for a given trajectory, the initial height of the disk will be raised by \(lsin(\theta)\). This means the disk has to travel less distance vertically, meaning that \(\theta\) will be smaller with the new launch height. But, when \(\theta\) is decreased, so will the launch height, will in turn will raise theta, and so on. This process is convergent, meaning that iterating the process described above will eventually yield a \(\theta\) whose change in the launch height is reflective of the launch height's change in theta. The following process can be used to find the convergent \(\theta\):

1. Calculate \(v_0\) and \(\theta\) from the current launch height
2. Find the new launch height given the previously calculated \(\theta\)
3. Repeat steps 1-2

We graphed out the convergence of \(\theta\) to confirm that these calculations would work correctly. Below is an image of the convergence of \(\theta\) given a distance of 4 meters and a launcher length of 0.3 meters:

To exaggerate the effect here is another image with a launcher length of 1.8 meters:

Next Steps:

The next step is to implement this in code to account for the height of the launcher, a fairly simple task. Tuning the iterations for performance vs accuracy won't really be necessary since \(\theta\) seems to converge exponentially and iterations happen very quick on modern hardware anyway.

One concern still exists which is that the horizontal distance the disk has to travel is also effected by the launch angle \(\theta\). However, this would only effect the distance by a matter of fractions of a centimeter, so it is likely not a big problem. If significant errors are encountered which cannot be traced down to other hardware or software defects/bugs then we can consider taking into account the effect that \(\theta\) has on distance, and vice versa.

Task: Prepare the portfolio and intake before the qualifier

The three of us worked on the engineering portfolio, discussing what we needed to get done in these 3 weeks between now and the qualifier. It was agreed that Ben, Bhanaviya, and Jose would be largely responsible for the portfolio and having other team members add information when necessary. We also began drafting an email to a physics professor who may help us with our physics calculations.

Trey and Justin mostly worked on rebuilding the ring intake to make it easier to mount onto the robot. They also rebuilt parts of it to make it easier to service in the future. There were little issues with this, although access to the robot was limited at times during code testing. Time constraints also played a role in the progress that was made.

Next Steps

The next steps for the portfolio are to begin formatting and gathering information for all the subsystems and from team members. Once we have all the information, we will have to condense it into an easily-digestible 15 pages. We will also have to fix the LED lighting solution on the front of the robot, along with troubleshooting Vuforia.

Task: Add Margins Of Error To The Desmos Calculator

In order to visually represent the significance of placing the constraints we did, we modified our desmos trajectory calculator to include a margin of error box. This box would help to highlight the importance of keeping the summit of our trajectory aligned with the goal, and how deviations from the summit would result in drastically increasing margins of vertical error for the same horizontal error.

As seen above, even with the same theoretical horizontal margin of error, having the goal (which can be thought of as the center of the error rectangle) placed further from the summit of the trajectory results in a larger vertical error. This helps to visually justify why we chose to have the summit of the disk's trajectory at the height of the goal, because the disk's vertical margin of error is minimized with that constraint.

Additionally, we are able to minimize the energy required to launch the disk. This is because, by the law of conservation of energy, the energy at any point in the disk's launch must be equal to the energy at any other point. We can consider the point where the disk is about to be launched from the launcher and the point where the disk is at it's maximum height. The total mechanical energy (kinetic energy + gravitational potential energy) of the disk in these two points must be equal.

Kinetic energy is represented by \[\displaylines{K = \frac{1}{2}mv^2}\]

and gravitational potential energy is represented by \[\displaylines{U_g = mgh}\]

The higher the disk goes, the larger the total mechanical energy of the disk at the highest point in it's trajectory, since \(U_g\) is proportional to \(h\). And by the laws of conservation of energy, the energy at the start of the launch would have to equal this larger mechanical energy for the disk to reach a higher altitude. By having the disk only go as high as it needs to in order to reach the goal, we minimize the total energy we need to put into the disk and the initial velocity of the disk at launch (since \(K\) is proportional to \(v^2\)). This is ideal for our flywheel as the likelihood of it being not fast enough is minimized.

The link to the edited desmos calculator can be found at https://www.desmos.com/calculator/csxhdfadtm, with \(E_c\) being the variable to control the center of the error rectangle and \(E\) being the variable to control the margin of horizontal error.

Task: assemble different intake prototypes

The Ringslinger 9000 is a crucial part of the robot and requires careful planning to build. Although we have a relatively simple intake and launching mechanism, their components are a bit more complicated. After getting the individual pieces of our launcher system ready, we were able to start putting them together to form the system. This post will serve as a step-by-step guide on how the entire launching system was assembled.

The process starts with the launcher baseplate which was constructed using aluminum and was cut on the CNC mill. As shown in the picture above, several holes were strategically placed in various areas on the periphery of the plate for screws to go to hold the other elements such as the Ultraplanetary REV motor that powers the flywheel and the nylon guide wall which guides the rings as they move through the system. The plate itself is mounted onto 2 REV extrusion bars using several metal brackets as shown below.

The bars are mounted onto a hinge which carries the entire system and rotates as needed during the game.

Launcher Guidewall/extension

The custom-printed guidewalls are attached to the plates using retaining screws, and function to guide the rings to the flipper to be prepared for launching.

Motor Mechanism

The REV 3:1 Ultraplanetery motor which drives the flywheel is attached via a slotted motor mount as shown below. It is then placed on an extension of the launcher baseplate using 6 screws. The motor can spin its sprocket at 1,727 RPM and drives the wheel by a belt between the two sprockets.

As mentioned in the Ring Launcher Summary, our launching system essentially is made out of 3 levels: the mounting, driving, and ring levels. The pictures below show the driving level's center plate with 3D printed nylon spacers mounted to separate it from the ring level. The spacers closest to where the flywheel will be attached each contain 2 holes and are attached by screws. The larger spacers also contain 2 holes where screws are attached to mount the driving and ring levels together. After getting the two individual levels ready, they are put together using screws, as shown below.

Shown below is the custom-made servo spacer. The servo is mounted next to the opening that is next to where the motor is mounted. It is fixed into place using screws.

Pictured below is a bird's eye view of the center plate. The servo located on the back of the ring slinger essentially spins the ring flipper to exert motion onto the rings to prepare them for launching by pushing them into contact with the flywheel. The REV Ultraplanetery motor is mounted onto the platform using 4 screws and nuts and the servo is mounted also using 4.

The flywheel is composed of a NinjaFlex center wheel which is sandwiched between 2 custom aluminum plates.

The flywheel's upper aluminum plate works to keep the wheel from flying upward. A polycarbonate sheet works with its lower aluminum plate to fix the axle in place. The polycarbonate sheet is shown below. It also plays a role in keeping parts in place.

The Flywheel is attached to a pulley which drives it using the belt that runs from the wheel pulley to the REV motor. As seen in the CAD model above and the picture below, the wheel was assembled by connecting the 2 aluminum plates to the NinjaFlex wheel in the center using screws. The flywheel spins on the shaft that is locked into place with the shaft collar on each end.

As shown above, the whole launching system to the arm that sits on a pivot in the back of the robot which adjusts itself by rotating to the angle that is ideal for where a ring needs to be launched to.

Finally, a look at the robot after all the individual parts were assembled is pictured below.

Next Steps:

One of the highlights of this system is that it is completely custom-designed and built . All our parts were either 3D-printed or custom-machined on our CNC. Documenting its assembly allows us to keep track of all of the parts involved in its print. Being able to showcase the build stages of the Ringslinger 9000 is also incredibly useful for two more reasons. First, if we ever intend to build a second one, we have the progress of the first one fully documented for inspiration and/or to isolate potential causes of structural error. Second, if any teams who follow our blog want to create a similar model, they have ours for a source to help. As the launcher continues to undergo changes, it is likely we will create another such assembly post - likely after our first qualifier in 3 weeks.

Task: Achieve Continuous Targeting and Automatic Launching

With the goal of having the turret continuously aim towards the goal, the elbow tilt to the correct angle at will and the flywheel to ramp to the correct velocity at will, we began by verifying our odometry calculations using FTC dashboard. Our odometry calculations would be the cornerstone of our entire automatic launching system, since the distance between the robot and the goal as well as the bearing to the goal from the robot would both be determined using the robot's x and y position as given through odometry. Using FTC dashboard's field overlay, we were able to draw our robot as a circle onto the given canvas like so:

In the above image, the bottom circle represents the robot, with the top circle representing the goal. The longest black vector represents the heading of the drivetrain or base of the robot. The second to longest red vector represents the heading of the turret of the robot. The shortest blue vector, which is the same size as the circle robot itself, represents the bearing from the robot to the goal.

The blue and red vectors (bearing to goal and heading of turret) are equal in direction because of the PID loop running to continuously target the goal. We are able to accomplish this by setting the target heading of our turret PID controller to the bearing between the robot and the goal, which can be calculated with: \[\theta = tan^{-1}\left(\frac{y_{goal} - y_{robot}}{x_{goal} - x_{robot}}\right)\] The PID controller compares this target angle with the IMU angle of the turret and corrects for them to be equal.

As for the other part, automatic launching, we were able to achieve this using our previously made trajectory calculator. The input to our trajectory calculator, the distance between the robot and the goal, was calculated using: \[distance = \sqrt{(y_{robot} - y_{goal})^2 + (x_{robot} - x_{goal})^2}\] The outputs of the trajectory calculator, the angle of elevation of the elbow and angular velocity of the flywheel, were then set to the targets of the elbow PID and flywheel PID controllers, in order to consistently hold the desired articulation. When the flywheel ramped up to a velocity in a 5% error threshold of the target velocity, we toggled the trigger servo and launched the disk, with the ramping of the flywheel seen below through FTC dashboard:

Next Steps:

By testing our continuous target and automatic shooting system, we quickly realized our calculations were slightly off. The next obvious step is to diagnose any sources of error in our calculations and account for them appropriately. The main one being how the angle of the launcher affects the vertical distance travelled by the disk (initial height of launch), and vice versa. This can be done using the convergent, iterative process described in a previous post. Other sources of error could include the turret being offset to the right of the center of the robot, and a later discovered glitchy flywheel power cable. We can now advance from simply implementing our theoretical calculations to diagnosing issues with them and addressing errors in our robot.

Task: Map and test controls

With our first qualifier being a week away, Proteus (our robot) needs to be in drive testing phase. So, we started out by mapping out controls as depicted above.

One stark difference between this control map from previous years is that there a lot more controls than previously since one of our team goal's this season was to reduce human error as much as possible when it pertained to driving and having more expansive controls was reflective of this goal. For instance, last year, when our turret was still in use as in this year, we had two controls for rotating the turret. However, this season, since turret rotation allows us to maximize our capabilities when it comes to continuous targetting, we've set aside 4 controls for turret rotation alone since being able to vary its speed manually is something we've had difficulty with earlier in the season.

Next Steps

As the season changes, we expect our controls to change as well and we will document these changes accordingly as time progresses.

Task: Prepare the intake before the qualifier

Today’s meet consisted of Cooper working on code, Paul burning polycarb, and Trey working on the intake with Paul. We were able to get the ringevator-esque intake working with some level of reliability, at least off the robot. The design is quite ingenious, using the friction of the rings against the floor and a polycarbonate scoop-type thing to integrate the flipping of the rings and the lifting of the rings into one cohesive unit, that saves space, motors, and weight. Paul was in charge of heat-bending the polycarbonate plate, but Paul overheated it and ended up warping the plate. However, this proved to be quite useful, as the warp helped to hold the rings against the ninjaflex elevator belt. Sometimes, rarely, screw-ups are a good thing.

Meanwhile in the robot garage dungeon, Cooper was working on optimization of the code and helped to optimize the odometry, calibrating the robot's autonomous mode to be more accurate based on its surroundings, using both the IMU and potentially an intel RealSense camera in the future. In addition, Cooper worked to enhance the robot’s position holding and automatic targeting systems, helping to ensure that the ring lands in the goal, every time, automatically. Pretty neat stuff.

In the more whimsical department, the robots 12-round chefs-hat extendo-mag turns the robot from an FTC legal precision machine to a motorized fear-inducing machine. This extended mag was used for demonstration, target testing and shooting rings at unsuspecting team members only, as FTC regulations only allow the robots to be in control of 3 rings at a time, not 12 (though that would be kinda cool).

Next Steps

With the ringevator mounted, we plan to get the mag removed by the next meet to create more precision with our launcher system.

Task: Build A Forward Kinematic Model Of The Robot To Account For Turret And Muzzle Offsets, And Counter-Lead The Target To Allow For Launching In Motion

After building the base of a trajectory calculator to allow for continuous targeting and launching, the next step was to address the discrepancies between our robot in code and the real robot, a major one being the offset between the muzzle compared to the center of the robot. Thus far, we had been treating the muzzle exit point as the center of the robot, which in reality isn't the case. The center of the turret is positioned behind the center of the robot to be flush with the back edge, and muzzle is positioned in front of and to the right of the center of the turret. In order to account for these offsets in code, we would have to build, in technical terms, a forward kinematic model of the robot to figure out the final (x, y) position of the muzzle, or the point at which the disk leaves the robot.

To account for the turret's offset we calculated the center of the turret to have the coordinates: \[\displaylines{x_t = x_r - dcos(\theta_r) \\ y_t = y_r - dsin(\theta_r)}\] where \(x_t\) and \(y_t\) represent the x and y coordinates of the turret respectively, \(x_r\) and \(y_r\) represent the x and y coordinates of the robot respectively, \(d\) represents the distance between the center of the robot and the center of the turret, and \(\theta_r\) represents the heading of the robot's base.

We then took \(x_t\) and \(y_t\) and used them to calculate the muzzle exit point using a polar approach: \[\displaylines{x_m = x_t + rcos(\theta_t + \theta_m) \\ y_m = y_t + rsin(\theta_t + \theta_m)}\] where \(x_m\) and \(y_m\) represent the x and y coordinates of the muzzle respectively, \(\theta_t\) represents the heading of the turret, and \(r\) represents the "radius" of the muzzle, and \(\theta_m\) represents the "angle" of the muzzle. In reality, the terms "radius" and "angle" of the muzzle don't make sense since the muzzle is positioned in front of and to the right of the turret, and using a cartesion approach we would have to make two separate adjustments for the x and y for the vertical and horizontal offsets, however converting these offsets into a polar form can help to simplify the process, and is where a "radius" and "angle" are derived from. If the horizontal distance between the muzzle and the turret center is \(o_x\) and the vertical distance between the muzzle and the turret center is \(o_y\) (when the robot is viewed from the top-down), then \(r\) and \(\theta_m\) can be derived like so: \[\displaylines{r = \sqrt{o_x^2 + o_y^2} \\ \theta_m=tan^{-1}\left(\frac{o_y}{o_x}\right)}\] \(r\) and \(\theta_m\) are used in the previous equations for \(y_m\) and \(x_m\) to derive the final position of the muzzle exit point, and completes the "forward kinematic model" of our robot for trajectory calculation purposes. \(x_m\) and \(y_m\) are then substituted for \(x_r\) and \(y_r\) in all trajectory calculations to account for all offsets from the center of the robot. In the first image on this post, the turret can be seen repositioned from the center of the robot with a heading labeled with a red vector, and the muzzle can be seen with a smaller circle containing a neon-green line to the currently selected target.

Our second task was to allow the robot to launch at its target while in motion. The first step of achieving this would be to address how the robot's velocity in the x direction would affect the trajectory of the disk. We would have to counter-lead the target in the x direction to account for side-to-side motion of the robot while launching. This is because when the robot is moving with a velocity \(v_x\) in the x direction while launching, the target will be offset by a factor of \(v_x \cdot t\), where \(t\) represents the time the disk spends in the air. To account for this we can simply subtract \(v_x \cdot t\) from the target's x position in order to counter-lead it.

To account for the robot's velocity in the y direction (\(v_y\)) we can subtract \(v_y\) from the disk's horizontal velocity calculation, which then becomes \(\frac{d}{t} - v_y\). This effectively adds the robot's y velocity onto the y velocity on the disk, which reduces the needed horizontal velocity of the disk, hence why \(v_y\) is subtracted.

With these two additions, we can now, at least theoretically, launch in motion. In practice, we saw that our underdamped PID controller could not keep up with the bearing to the counter-led target. In a perfect world, the turret's heading would equal the bearing the offset target, although due to poorly tuned PID coefficients, this was not the case. With some tuning we hope to correct this and get the turret to somewhat lock on to the offset target while the base is in motion.

Next Steps:

Our next steps would be to continue addressing small errors in between our robot in code and our robot in the real world, perfecting our trajectory calculator to maximize accuracy and precision. From a few tests we determined our successful shooting rate was around 75% from a fixed location, which can be used to conclude that there are mechanical faults at play as well, which could be a non-stationary elbow or unbalanced flywheel. These are all investigations to delve into later in order to perfect our automatic launching.

Task: Prepare the intake before the qualifier

At today's meeting, Paul worked on the ringevator, with the guidance from Mr. V. The intake mechanism required a motor to be installed, which at first glance seems like light work. However, the intake is composed of two separate parts that move independently, connected by a hinge. The motor had to be attached to the static, robot part, however, the power had to be transferred to the belt, which just so happened to be on the dynamic part that swings around like a screen door in a hurricane, so mounting the motor on the swingy bit was out of the question. Paul took a page out of last years book, drawing inspiration from the elbow mechanism of Icarus and with some help from Mr. V, designed a mechanism that allowed the belt and hinge to rotate on the same axis, ensuring constant distance between the motor axis and the axis of rotation for the belt pulley. This allowed the motor to be mounted in a safe spot on the robot, away from the dangers of an FTC field, while simultaneously being able to drive the belt mechanism on the moving part of the robot. Future plans call for replacing the pulley drive bushings with custom fabricated ball bearings, and moving the motor further down the robot to lower the center of gravity.

Next Steps

The ringevator still needs to be mounted on the robot but this was enough progress to hopefully get us to a working intake before the qualifier.

Task: Create a flow chart to analyze all our intake designs so far in this season.

Iron Reign has seen several iterations of our intake over this past build season. With our first qualifier being 2 days away, its finally time to come full circle and identify the different iterations of our intakes coming together. To do this, our team used a flow chart. A morph chart shows the various subsystems of our 2 robots in this system - our robot in 2 days bot Frankendroid and our competition bot TomBot.

Each intake's progression is represented vertically, shwoing stages from the sketch, to the CAD to the final product. For the Ringevator intake design in particular was inspired by a combination of two other intaek designs - the belt drive and caterpillar. The combination of these two designs, as well as a description of each design is also represented on this chart.

Next Steps

Placing all of our designs in one chart like this allows us to see how iterative our design process has been, and how much of an influence each design has had on another. With all of our designs so far placed in the flow chart, our next step is to continue to update the chart after our first qualifier so that we can have a pictorial summary of our entire build season for reference.

Task: Describe the construction and development of the Ringevator intake

This year we have done a lot of work on intakes and launchers. The purpose of this post is to go over the function and overall design and build of the Ringevator intake. It doesn’t go too far in-depth so if you are looking for something more specific I would recommend that you look at specific posts discussing different parts of our design but if not you are in the right place.

Build Breakdown:

The construction of the Ringevator is moderately complex. It consists of a custom belt, two axels, a motor, a pivot, a base, and some elastics. The belt is custom modeled and printed in NinjaFlex. The design is based on the belt seen in one of our previous robots, Kraken, which competed in 2018. It has flaps that do the work of pulling in the rings and holes that are used by sprockets to drive the belt. The holes are the exact size and space apart to be fitted onto the sprockets on the drive axels which are attached to the base. The base is a simple H design that used to be in between the sprockets but now sits so that the sprockets are inside to make mounting easy. The axels are driven by one motor attached by a belt on the base of the robot.

As you can see in the photo above, the belt assembly base and the robot base have a pivot between them. The purpose of this pivot is to make picking the rings much easier. Normally you would have to pick a ring up horizontally and then turn it to a vertical orientation which is what we need but instead, the pivot allows for the belt assembly to walk over rings. This means that when the intake reaches a ring, the movement of the belt causes the mechanism to open and consume the whole ring. Since only one side of the ring is being pulled up by the belt, it is flipped vertically and travels up the rest of the mechanism and out the top. The elastics make sure that the belt keeps in contact with the ring at all times. The only other thing that is apart of the design is a guide ramp on the inside made of heat-bended polycarbonate. You can see a photo of this ramp below along with the intake before it was attached to the robot on a pivot.

Testing:

We tested the Ringevator multiple times throughout its life to make sure that it will work. It gets a good grip on the rings and is able to pull them up most of the time. We still need to iron out a few tensioning issues with the elastics to make it more consistent but other than that it works well based on our tests so far which are few and far between. More testing will come.

Improvements:

The design didn’t start out this well though, we made several improvements since the start. For starters, the whole pivot idea was a mistake, to begin with; however, we discovered while doing preliminary tests that the belt walking over rings was a feature, not a defect. We realized that picking up rings without the pivot would be far more difficult and that was the spark for the design we have now. We also suffered some grip issues with the polycarbonate ramp which wanted to grip the rings too much and hindered the ability of the intake. We fixed this with some friction-reduced tape and now it works well. The design is still in its baby stages so we haven’t found a lot of problems but we will eventually and we are excited to address them.

Next Steps:

We are working right now on dialing in the shooter to make it more consistent and also testing a 1:1 motor to see how it compares to the 1:3 motor in terms of accuracy. We are also being posed with a challenge unlike any other challenge we have faced this season which is taking what we made when we were developing intakes and making a system that can feed into the shooter. This is going to prove a challenge because of the size of the shooter and the fact that it can be rotated or tilted to any angle. The challenge may be large but we are a worthy opponent.

Task: Make the Ringevator legal so we can use it in competition

We’re at the point now where we have a lot of our systems ready to be put on the robot, but we have to face another big challenge, which is making everything legal. Since the robot is a circle, we don’t exactly have any space to put an intake in the sizing cube. We can take advantage of the hypotenuse of the box by putting our equipment in the corners but then we raise the problem of height. This is because the Ringevator was never actually built to be permanently attached to the robot.

We built the Ringevator as a prototype that harnessed the abilities of all of our previous models without their problems. However, with time closing in, it became apparent that the ringevator would have to be on the robot regardless of what we think. In order to do this, we had to shorten the assembly by about 2.5 inches and somehow pull the assembly inside more. With only a few builders being able to join us at any particular time, this proved to be a challenge.

Two things needed to happen to make the robot even close to legal. The first was that the front would have to be chopped off, spitting the front Omni wheel assembly in two. And the second was actually shortening the ringevator which meant shortening the belt. The first part was easily accomplished by modeling two new Omni wheel bases for the front and surgically removing the front of the robot with a hacksaw. This was accomplished in the span of two days. After this was done, Paul also chopped the top of the ringevator off. The last piece was the belt.

The problem with the belt was that I was the only one who knew how to shorten it and I was stuck at home for the next few days. So after Paul was done with the robot surgery, he swung by my house at 3 AM and dropped the belt off in my mailbox. The next morning, I marked off about 5 inches or 5 flaps of the intake, printed a new rig for the welding, cut, and welded the belt into a shorter configuration with my own tools. Then to get the belt back to the robot, we thought about getting a courier to deliver it but instead, I showed up the next day with the new belt and it was assembled onto the robot. After all of that, the robot was still not legal. The reason why it wasn’t legal is because we used bulky REV extrusions as sides since they are easy for prototyping. Since those rails are thick it just barely falls out of the sizing cube. So we had to detach the whole assembly for our next competition.

Next Steps

We would have liked to cut the assembly down more at this point but we couldn’t because we had already pushed the limits of its size. Our next step is to completely redesign the whole intake system. We knew this was going to have to happen at some point but we didn’t think it was going to be this soon. In order to make the intake legal, we have to CNC all of the parts. And I think that’s the kind of challenge Iron Reign is built for.

Task: Review our failure of rushed build leading up to the UTD qualifier

As discussed in the post "Making the Ringevator Legal" there was a lot of rushed build leading up to this qualifier. As a recap of that post, the Ringevator was too wide and too tall to be legal, so we had to cut off the front of the robot, split the omni wheels, shorten the assembly, and shorten the belt. For more information, read that post. So with all of this change leading up to the competition, one would expect that it all worked out.

Alas, it did not. By the end of the raised build, the robot was still not legal by any means. In fact, the ringevator had to be removed so that we could actually run matches with a legal robot. This, however, is not the end. Even though the robot may not be legal, the judges still respected the development we displayed in our journal and portfolio. We demonstrated real development in innovative systems that I suppose resonated with the judges because we were awarded the Inspire award. Ordinarily, any team would see this as a big accomplishment but the builders at IronReign were restless. We failed our goals. The end objective with building a good robot is to score high amounts of points and that’s the one thing we didn’t do.

At the very least we did learn quite a bit from the situation. Firstly, the troubles we had with the ring transfer from intake to outtake demonstrated that the pancake flipper was not a good idea. Such a path for ring transfer would be cool but a challenge too large for the coders. Besides, we already have put so much into the ringevator. Abandoning it now would be reckless. We also discovered that another pivot point at the bottom would be vital to the ring transfer. At the moment this is just a REV core hex motor but something more advanced would be helpful. There is also the added possibility of adding a slide to the bottom of the intake which paired with the current pivots, would make the intake far more versatile and clear of the spin of the turntable, which gets caught. There is still much thinking to be done in this department. Finally, the last thing we learned is that the ringevator would need to be remade in a fully custom, aluminum version to make it fit in the sizing cube. This will be a large feat but if we can do it, we will have points when our next qualifier rolls around.

Next Steps

We’re going to need to do a lot more before our robot scores real points. I admire our progress but we still have a long way to go. We need to step up on driver practice, reevaluate the ringevator, and start thinking about a final version of the robot. What comes immediately next is modeling and redesigning the ringevator to lose any bulk in the system so it can fit on the robot. I hope that those new developments will allow us to run matches next competition.

Task: Plan Out Changes To Codebase and Use New Libraries/Hardware

This season, we plan to utilize the PAA5100JE Near Optical Flow Sensor (left image) and Realsense D435 Depth Camera (right image) to improve our robot's autonomous accuracy and reliability when running alongside other robots.

The optical flow sensor's potentially higher accuracy over traditional odometry deadwheels and immunity to slippage can make autonomous routines more reproducible. However, it is not a device that comes with out of the box FTC support, so a custom java driver will need to be translated from the existing python driver to have it correctly interface with the i2c ports on the REV Control Hub. Additionally, the device uses the SPI protocol for communication, so code will need to be written to convert the SPI calls to i2c, which can then be converted back to SPI via a i2c to SPI bridge chip.

As for the Depth Camera, a pipeline can be created to take its output, detect robots or other objects that the robot may collide with, and preemtively come to a stop during autonomous and possibly tele-op to avoid those collisions. This would save time spent communicating with an alliance partner prior to a match to determine where to place delays in an autonomous program to prevent collisions, since those delays would be performed automatically.

Furthermore, the optical flow sensor outputs movement in both the x and y directions, so only one is required to get xy localization on a holonomic drive. If we wish to also use the sensors for heading information instead of/alongside the IMU, two can be mounted on opposite corners of the robot. But what good is localization for autonomous if not to be used with path following?

We plan to experiment with the roadrunner motion profiling library for FTC robots, using as input the Pose provided by the optical flow sensors. It simplifies many of the common needs for path following, like providing OpModes for odometry tuning, path following for linear and even spline trajectories, as well as asynchronous methods which can easily integrate into our current asynchronous codebase. Since we are dipping our toes back into a mecanum chassis for robot in two days, roadrunner will be ideal to harness the full potential of a holonomic drive.

Next Steps:

The most important first step is to get the optical flow sensor working with the Control Hub, so that we can have an accurate localization system as the backbone for future path following during autonomous. In a separate track, different pipelines can be experimented with to get obstacle detection working using the realsense depth camera.

Task: Build a robot that can be adapted to any challenge

The challenge reveal is going to be quite soon. In the weeks leading up to the challenge reveal we began to wonder if there was anything we could do that would make our transition from preseason to prototyping any better. And obviously, there are many things we could do that would make our work easier when the time comes to see the new challenge. Mainly, we were thinking that since we do a robot in three days when the challenge gets revealed, it would be beneficial to have a robot chassis that could be used in most challenges and be adapted to the specifics of this year’s challenge. A robot like this should be easily maneuverable and have an arm or subsystem capable of interacting with ordinary objects. That’s where the idea for this robot came from.

N-bot is the solution to this problem. The idea for N-bot was that we should have a chassis that can drive over elements and manipulate them within the walls of the robot. In order to do this, we created a robot in the shape of a lower case n that can drive over objects. Ideally, the next step would be to give it an arm that can manipulate anything it can drive over; however, we did not have time to complete this. Instead, what we ended up with was a chassis in the shape of a lowercase n.

For wheels on this robot, we decided that mecanum wheels would be the best choice since we would be able to move in all directions on the field with them and position ourselves accurately over objects. Those four wheels are chained to motors and paired together in wall-shaped blocks that are linked together on top by 4 structural extrusions. The overall shape of the robot appears to be sturdy; however, it is actually quite flimsy. Linking two halves of a robot with only 4 beams on top is not a great idea if you’re looking for a rock-solid design. Instead, our robot tends to flex and shake but that’s ok because those issues are manageable. We sacrificed the structural integrity of our robot for ease of adaptation to challenge specific tasks.

Next Steps:

The next steps for this project are clear: we wait for the challenge to be revealed and then we adapt N-bot to that challenge with any number of additional subsystems. We are planning on only using this robot for our robot in 3 days challenge and nothing else so none of the subsystems we produce will be used at any other point in the year.

Task: Build a robot that can be adapted to any challenge

The new challenge is upon us and with a new challenge comes new robot designs. This year we have found that we are going to need to focus on the chassis of our robot more than ever. This is because the barrier to the warehouse is an important obstacle that we want to be able to climb or get around in order to score. The drawings and notes depicted below are the unfiltered notes that I took shortly after the discussions we had about chassis designs.

Next Steps:

The next steps here are to pick one or two of these designs and run with them. We need to build some prototypes of these fast before the first scrimmage or competition. I think the ones we are most likely to prototype in the coming weeks are the Flipin' tank, the tricycle, and the Flippin' bot. We're excited to see where these designs take us.

Task: Deliver a Presentation Over Developing Vision Pipelines At The Flyset Workshop

This Saturday, we had the oppurtunity to present at the Flyset workshop, an event in which multiple teams could present a topic of their choosing, such as (but not limited to) build, design, and programming. For one of our two presentations, we decided to share our process for rapidly prototyping and testing OpenCV vision pipelines, taking a drag-and-drop visual pipeline in GRIP to a fully-fledged working android project that can be deployed to a control/expansion hub.

To begin the presentation, we introduced the programs and dependencies we use for developing vision pipelines. These include GRIP (a graphical tool to easily visualize and test out different computer vision pipelines), FTC Dashboard (a project dependency that allows for remote debugging with image previews, on-the-fly variable editing, live telemetry, graphing, and a field overlay), and EasyOpenCV (a project dependency that simplifies using OpenCV for FTC and runs vision pipelines in a separate thread for maximum efficiency).

Next, we laid the foundation for the HSV threshold step to come by introducing the audience to the HSV color space and its advantages that make it easier to tune for the purposes of sampling an orange cone or colored team marker. We then transitioned (not shown in slides) to the concept of an HSV threshold, which takes an rgb image and uses hue, saturation, and value ranges to let only certain pixels through the threshold, ultimately producing a binary image.

The final requirement for understanding our color-based detection approach is that of contours in the context of computer vision. We explained the definition of contours (boundaries that enclosed shapes or forms in an image), and how they can be detected from thresholded images.

The final constructed GRIP pipeline is shown above. It follows the steps:

1. gaussian/box blur
2. HSV threshold
3. contour detection

However, multiple contours/color blobs may be detected in the last step shown in the GRIP pipeline, so the largest contour must be selected by area. From this largest contour, moments can be used to find the (x, y) coordinate of the contour's centroid. Moments are defined as the weighted sums of pixel intensities (pixel values when converted to grayscale), weighted by their x and y positions to produce m_1_0 and m_0_1 respectively. These moments can then be divided by m_0_0 to produce the x,y coordinate of the centroid of the largest detected contour, the final desired result.

Finally, the completed vision pipeline was exported to java and modified to be compatible with EasyOpenCV, as well as select the largest contour by area and compute its centroid.

Next Steps:

Possible next steps for other approaches of detecting FFUTSE cones include the shape-based approach and machine learning with tensorflow. The shape-based approach would use an adaptive threshold and contour detection to detect multiple contour, and can rely on the shape of the contour (tapered towards the top like a cone) to detect the location of the FFUTSE cone placed in the image.

In order to construct a tensorflow model to detect FFUTSE cones, training data (images of FFUTSE cones placed in various different orientations, lightings, and backgrounds) will need to be collected and labelled with the (x, y) coordinate of the FFUTSE cone in each image. Then, a CNN (Convolutional Neural Network) can be constructed, trained, and exported as a .tflite file to be used in the FTC ecosystem.

Task: Derive Inverse Kinematics For The Drivetrain

Due to having an unconventential drivetrain consisting of two differental wheels and a third swerve wheel, it is crucial that we derive the inverse wheel kinematics early on. These inverse kinematics would convert a desired linear and angular velocity of the robot to individual wheel velocities and an angle for the back swerve wheel. Not only would these inverse kinematics be used during Tele-Op to control the robot through joystick movements, but it will be useful for getting the robot to travel at a desired forward velocity and turning rate for autonomous path following. Either way, deriving basic inverse kinematics for the drivetrain is a necessity prerequisite for most future programming endeavors.

More concretely, the problem consists of the following:
Given a desired linear velocity \(v\) and turning rate/angular velocity \(\omega\), compute the required wheel velocities \(v_l\), \(v_r\), and \(v_s\), as well as the required swerve wheel angle \(\theta\) to produce the given inputs. We will define \(v_l\) as the velocity of the left wheel, \(v_r\) as the velocity of the right wheel, and \(v_s\) as the velocity of the swerve wheel.

To begin, we can consider the problem from the perspective of the robot turning with a given turning radius \(r\) with tangent velocity \(v\). From the equation \(v = \omega r\), we can conclude that \(r = \frac{v}{\omega}\). Notice that this means when \(\omega = 0\), the radius blows up to infinity. Intuitively, this makes sense, as traveling in a straight line (\(\omega = 0\)) is equivalent to turning with an infinite radius.

The main equation used for inverse wheel kinematics is:

Where \(\vec{v_b}\) is the velocity at a point B, \(\vec{v_a}\) is the velocity vector at a point A, \(\vec{\omega_a}\) is the angular velocity vector at A, and \(\vec{r}\) is the distance vector pointing from A to B. The angular velocity vector will point out from the 2-D plane of the robot in the third, \(\hat{k}\), axis (provable using the right-hand rule).

But why exactly does this equation work? What connection does the cross product have with deriving inverse kinematics? In the following section, the above equation will be proven. See section 1.1 to skip past the proof.

To understand the equation, we start by considering a point A rotating around aother point B with turn radius vector \(\hat{r}\) and tangent velocity \(\vec{v}\).

For an angle \(\theta\) around the x-axis, the position vector \(\vec{s}\) can be defined as the following:

by splitting the radius vector into its components and recombining them.

To arrive at a desired equation for \(\vec{v}\), we will have to differentiate \(\vec{r}\) with respect to time. By the chain rule:

The appropriate equations for \(\frac{d\vec{s}}{d\theta}\) and \(\frac{d\theta}{dt}\) can then be multiplied to produce the desired \(\vec{v}\):

Now that we have an equation for \(\vec{v}\) defined in terms of \(\omega\), \(r\), and \(\theta\), if we can derive the same formula using \(\vec{\omega} \times \vec{r}\), we will have proved that \(\vec{v} = \frac{d\vec{s}}{dt} = \vec{\omega} \times \vec{r}\)

To begin, we will define the following \(\vec{\omega}\) and \(\vec{r}\):

Then, by the definition of a cross product:

Since the same resulting equation, \(\omega r(-\hat{i}sin\theta + \hat{j}cos\theta)\), is produced from evaluating the cross product of \(\vec{\omega}\) and \(\vec{r}\) and by evaluating \(\frac{d\vec{s}}{dt}\), we can conclude that \(\vec{v} = \vec{\omega} \times \vec{r}\)

1.1

Based on the constants defined and geometry defined in the image below:

The equation can be applied to the left wheel to derive its inverse kinematics:

where \(r\) is the turn radius and \(l\) is the width of the robot's front axle. Applied to the right wheel, the equation yields:

Applied to the swerve wheel, the equation yields:

where \(s\) is the length of the chassis (the distance between the front axle and swerve wheel).

The angle of the swerve wheel can then be calculated like so using the geometry of the robot:

Mathematically/intuitively, the equations check out as well. When only rotating (\(v = 0\)), \(r = \frac{v}{\omega} = \frac{0}{\omega} = 0\), so:

In all three cases, \(v = \omega \cdot r\), where \(r\) is the distance from each wheel to the "center of the robot", defined as the midpoint of the front axle. Since rotating without translating will be around a center of rotation equal to the center of the robot, the previous definition for \(r\) can be used.

As for the equation for \(\theta\), the angle of the swerve wheel, it checks out intuitively as well. When only translating (driving straight: \(\omega = 0\)), \(r = \frac{v}{\omega} = \frac{v}{0} = \infty\), so:

As expected, when translating, \(\theta = 0\), as the swerve wheel must point straight for the robot to drive straight. When only rotating (\(v = 0\)), \(r = \frac{v}{\omega} = \frac{0}{\omega} = 0\), so:

As expected, when only translating (driving straight), \(\theta = \frac{\pi}{2}\), or in other words, the swerve wheel is pointed directly forwards to drive the robot directly forwards. When only rotating, \(\theta = 0\), or in other words, the swerve wheel is pointed directly to the right to allow the robot to rotate counterclockwise.

Next Steps:

The next step is to use PID control to maintain target velocities and angles calculated using the derived inverse kinematic equations. Then, these equations can be used in future motion planning/path planning attempts to get the robot to follow a particular desired \(v\) and \( \omega\).

A distance sensor will also need to be used to calculate \(s\), the distance between the front axle and swerve wheel of the robot.

Task: Derive The Maximum Chassis Length On Turns

Having a chassis able to elongate and contract during play poses its advantages and drawbacks. If properly used, the chassis can serve to strategically defend portions of the field. However, if not shortened during turns, the extended length of the robot can lead the swerve wheel to lose traction and start skidding on fast turns. Therefore, it is crucial to derive a model for the maximum chassis length achievable on a turn of angular velocity \(\omega\) before skidding starts to occur.

More concretely, the problem is the following: given an angular velocity \(\omega\) and other physical constants, what is the maximum distance \(s\) achievable between the front axle and swerve wheel before the centripetal force required to keep the robot in circular motion \(F_c\) exceeds the force of friction \(F_f\) between the wheels and the ground?

To start, we can define the force of friction \(F_f\):

where \(\mu\) is the coefficient of friction betewen the wheels and the ground, \(m\) is the mass of the robot, and \(g\) is the acceleration due to gravity.

Then, we can define the centripetal force required \(F_c\):

where \(a_c\) is the required centripetal acceleration, \(\omega\) is the angular velocity of the robot, and \(r_s\) is the distance from the swerve wheel to the center of rotation.

Setting these two equations equal to eachother and solving for \(r\) will yield the final equation:

However, the \(s\) must be related to \(r_s\) to be used in the above equation. This can be done by substituting the expression \(\sqrt{r^2 + s^2}\) for \(r_s\), where \(r\) is the true turn radius, which will compute the distance from the swerve wheel to the instantaneous center of rotation. So,

As seen in the above screenshot of the following desmos calculator, the slower the robot rotates, and the closer \(w\), or in this case \(x\), is to 0, the higher the maximum chassis length \(s\), or in this case \(y\), is. Intuitively, this checks out, since when at a standstill, the robot can be as long as possible with no side effects. When rotating slowly, the robot needs to be slightly shorter to maintain traction, and when rotating fast, the robot needs to be very short to maintain traction, as reflected in the downward slope of the graph.

Next Steps:

The next step is to use PID control with input as the measured chassis length as given by the distance sensor and target being the output of the derived equation for \(s\) to maintain the robot's length to keep traction. Additionally, the coefficient of friction \(\mu\) between the wheels and ground will need to be tuned to the drivers' liking.

Task: Decreasing the Movement of Linear Slides During Expansions

The continuous expansion and contraction of the robot placed a lot of stress on the mounting gear attaching the slides directly to the chassis. With each expansion the slides stretch out, and under their own weight, they would flex downwards. During regionals, the slides were subjected to these forces all day, and by the end our sliding components, “carriages”, were pretty damaged. The internals were unevenly worn and the ball bearings just fell out on the field; If left unattended, the carriages would eventually detach from the slides and the robot would literally break in two.

To fix this, Trey came up with a double-carriage approach, aimed at reinforcing the mounts attached directly to the front of the robot. He machined an aluminum plate on the CNC, and then combined two different carriages to create a single sliding component. This effectively doubled the “strength” of the mounts by shifting the pivot point of the slides further in, and adding more resistance to the gravitational torque acting on the bar. Overall, the slides weren’t as steep and so carriages were much smoother during extensions.

Next Steps

We noticed that the slides did sag a little, however we need some compliance to allow for twisting caused by sharp crane movements and turns.We also noticed that the slide attached to the swerve module did flex so we might need to address that. Testing was limited however so we’d like to get some driver practice in and see how well the upgrades perform on the field.

Task: Evaluating what magnet type works best with the FFUTSE and bucket attraction

Iron Reign has its final event of the season, the UIL championship, in just one month! One driver task we've been needing to complete has been picking up and depositing a Freight Frenzy Universal Team Shipping Element (FFUTSE). To read about the FFUTSE and Iron Reign's open-source design, please refer to our FFUTSE repository. To overcome this part of the game challenge, we have decided to attach magnets on the underside of our bucket-intake and to the top of our cone-shaped FFUTSEs. The idea is that when the bucket roves over a FFUTSE, its magnet will be strong enough to attract the one atop the shipping element. However, the magnetic attraction must not be too strong, otherwise the bucket will not be able to drop off the FFUTSE on the shared shipping hub if the magnet is still affixed to the robot.

In order to determine which kind of magnet could best meet these two criterion, we experimented with niodimium and ceramic magnets. Of the niodium magnets, there are 3 differently-sized ones - a large, medium, and small, with their sizes corresponding to the degree of magnetic attraction from greatest to least respectively.

To reinforce the shipping element's attraction to the bucket, we have also created an array of corresponding magnets inside the bucket rather than simply affixing one magnet, since that way, the vertical thrust of the crane when is lifted upwards will not disrupt the attraction of the FFUTSE to the intake.

It was clear that the ceramic and smallest niodimium magnets were too weak - even with an array of magnets in the bucket, they required too much precision on the driver's part in order to swiftly attract a FFUTSE and part of our idea is to minimize the driver effort and error that can come into play with this FFUTSE pickup process. Between the large and medium-sized niodimium magnets, though the large could attract a magnet faster, it did its job too well since dropping off the FFUTSE was not a task it could accomplish since the attraction of the magnets was too strong

Next Steps

In the end, our decision was influenced by Goldilockian principles - not too large, not too small but just right. The bucket does a reliable job of picking up and transfering FFUTSEs but as of now, this component has not yet been programmed. Once programmed, there is a chance we may have to either use a stronger magnet or find amiddle ground between the largest magnet and medium-sized one in order to minimize driver accuracy while maximizing efficiency.

Task: Fix issues found by Drive Practice in the robot

Iron Reign has seen several dIfferent iterations of our swerve module this past season. In this post we’ve identified the different versions of our modules so we can isolate the failures and successes of each modification from sketch, to a CAD model to the constructed, manufactured iteration.

To accommodate for our expanding chassis design this year, we’ve had to create a hybrid-differential swerve drive which means the combination of two differential wheels and swerve wheels and how they work together to achieve 2 degrees of freedom.

Our first version of the swerve drive had a thrust bearing the same size as the ring gear. Unfortunately, this iteration was too small to cross over the barrier.

The second iteration had a larger compliant wheel to cross over the barrier. Alas, the swerve drive created a high center of gravity for the robot, causing the robot to tip over.

The third version had custom-machined aluminum plates for further weight reduction.The Hex Motor was moved inside and above the wheel hub to reduce the center of gravity. Sadly, the wheel was not malleable enough to pass over the barrier without dropping the freight.

The fourth iteration is a rover-inspired swerve module made of six custom CNC carbon-fiber plates and ten custom 3D printed components. The wheel is made of NinjaFlex and has gothic arch-style to support a large vertical force. The wheel hub is made of nylon and has been holed to reduce weight. The walls of the holes have added infill to increase the strength of the wheel. This version has a lower center of gravity and a lighter wheel module.

Next Steps

We will contact the original designers of the rover-inspired swerve module, an Australian college rover team.

Task: Get more drive practice before the UIL Championship

This weekend, we focused on on-boarding new recruits as well as getting more drive practice to get us ready for the UIL competition next month.

New Recruits Learnt to Create Blog Posts

Bhanaviya taught us how to make blog posts on different topics, and also showed us the most efficient ways to bug the experienced members to get the information we needed.

Drive Practice (we really need it)

Gabriel got in practice going straight and using the extension function to minimize the amount of turning. Different angles of blocks were tested to see how the gripper would pick them up. An average of 3 pieces of freight per round was achieved.

Build Improvements

To help prevent the turret from drifting, we were looking at two options: implementing a tensioner to one of the belts to prevent skipping or adding an IMU to help the turret know where it is. We also added a potentiometer to be able to reliably be able to tell the shoulder position. There was a lot of shaft left, so Trey used a dremel to cut down the shaft so he could add the potentiometer.

Code Changes

There was an issue with an intake. The intake was running at a very high speed so it would spit the freight back out, for lack of a better phrase. A distance sensor was added to slow down the gripper when a shipping element is located nearby. Finally, he worked on fine tuning the crane so the transfer is seamless, and he is currently working on balancing the crane so it doesn’t bump into the shipping hub.

Next Steps

We have to test our robot without outriggers to see if the robot starts to tip over. (NB - We tested it out, it didn’t work. Let’s see what happens at the next meeting.) We also have to fine tune autonomous, so we can have a reliable auton which regularly works. We also have to work on driver optimization using present positions, so it’s easier on our drivers to control. Automating the intake cycle is also on our todo list.

Task: Fix issues found by Drive Practice in the robot

To better prepare for UIL, we have started using Driver Practice to find issues that would’ve impacted the robot performance at the competition. Within the first 15 minutes of driving the robot, the servo that sustains the crane experienced thermal overload and could no longer hold up the axel by which the crane was able to move vertically.

This required the deconstruction of the component to be able to access and replace the Steel Servo that had issue with the weight of the crane. This led to further experimentation with different aspects of the crane, such as the servo horn to test whether the axel would fully insert into the horn and reworking the distance sensor on the bucket so that it would function properly and automatically drop any held element onto the top of the shipping hub, though dropping elements into the shared shipping hub still needs some improvement. Unfortunately, even after changing out the Servo, the weight of the crane would still cause thermal overload, leading us to determine that it was unable to be fully fixed without reworking the crane in its entirety.

Next Steps

Continue with Drive Practice and rigorous testing of the robot attachments to see what needs improvement or complete reworking before UIL

Task-Identify and solve the problems that led to The Reach tipping over mid-match.

Our robot, The Reach, utilizes a hybrid-differential swerve drive along with an extending design in order to effectively cross the barriers and score freight. Although this design is unique and avoids the congested areas of the playing field, it comes with trade-offs and flaws.

At our first qualifier, we noticed one major flaw in the design of The Reach. The robot would often tip over during game play, rendering it unable to move and score points. Observing our matches and looking over our design, we attributed this problem to a couple of key components of our design.

First off, due to limitations on the dimensions of the robot at the beginning of matches, the robot had quite a narrow base for its extended length of around 5 feet. This led to the robot being susceptible to tipping when in motion when combined with a variable center of mass.

Next Steps

Building a unique and innovative robot like The Reach comes with a unique set of challenges and obstacles, and we will keep iterating our swerve module by experimenting with different wheel designs and weight-reduction patterns to reduce odds of tipping.

Task: Work on teamwork with drive practice for the UIL Championship

This weekend, we worked on giving the new recruits a basic understanding of HTML so they could operate the blog when we were no longer here to help them. We also worked on communication in drive practice, because we have two drivers and two controllers.

Gabriel and Georgia got in some drive practice

They got in more practice working together driving, and figuring out how they wanted to split up the responsibilities. We have a robot which works better with two drivers controlling two separate controllers, but this means we have to spend extra time planning out our strategies and deciding how the controls will work for each individual driver.

The new recruits are learning how to use HTML

Bhanaviya and Shawn taught us how to use HTML to upload blog posts to the blog. We wrote our first blog posts a couple weeks ago, and today we learned how to upload them to the blog and possibly run damage control if we accidentally break something in the blog.

Code Changes

Mahesh worked on updating the code for picking up blocks. Now, whenever the robot is trying to pick up a block and drops it midway, instead of going through the whole motion of putting it in the bucket, it goes back down. This will help our robot become more efficient, as it will have more time to pick up blocks when it’s not wasting time.

Making an Innovate Poster

Bhanaviya and Shawn worked on making an Innovate poster which detailed our game strategy and the build for our robot. This is the main award for the UIL Championship.

Next Steps

First things first, we need to fine-tune the autonomous for our robot. We are planning to get more drive practice with an autonomous system so we’ll know how to time things properly. We also want to get in more drive practice in general, so we'll have better control over our robot overall and will be able to control the arm better.

Task: Getting in some serious drive practice at Woodrow

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

Drive Practice at Woodrow

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

Next Steps

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

Task: Replace Crane Servo with a Motor

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

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

Next Steps

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

Gripper Progression

V1

Our first gripper design was for robot in 2 days and with the time crunch came some downsides: little power and poor reach. Our second design intended to fix these downsides.

V2

Our second gripper design was made just before a scrimmage. While it fixed all V1's downsides it was bulky and heavy.

V3

Our third gripper design was used during our first qualifier. While it was significantly lighter than V2 and had much more reach, its gripper power was still too low.

V4

Our fourth gripper design was used for regional and it used a new beater bar on a continuous servo to pull blocks into the intake. The beater bar/spinner was controled by a distance sensor which could detech if a block was in the intake. It was held together using a carbon fiber-nylon sandwich (with aluminum shavings) system. It had 6 CNC carbon fiber plate and had 9 Nylon 3D printed parts.

Task: Solve minor issues with the robot’s design and code. More drive practice in preparation for the UIL Championship next week.

With only one week left until the UIL FTC State Championship in Houston, we doubled down on our efforts to fix a few small problems that remained in The Reach, as well as prepare for the State Tournament. Specifically, we had to finish constructing a new duck spinner that could extend farther out, and fix minor difficulties in the code of the robot that was messing up the positions of the crane during gameplay.

Designing and Constructing a New Duck Spinner

There were a couple of key issues with the old duck spinner that led to the development of an improved version, which Trey designed and constructed. The old duck spinner was too short to reach the duck carousel when the gripper was lowered and in an intake position and the drivetrain for the duck spinner motor was not very good. Trey designed and 3-D printed a new motor mount that allowed the spinner to be directly driven by the motor. To address the length issue, the entire mount was attached to a carbon fiber rod. This new system allows the hot swappable duck spinner to extend further out and work in tandem with the beater. We managed to mount the duck spinner by the end of our meeting.

Remember to use safety glasses kids!

Fixing Minor Build Issues

There were a couple of structural and wiring issues with our robot that needed to be sorted out in order for the robot to function properly. On the bucket, the distance sensor that allowed an automated transfer system and automated drop off was re-wired to ensure that it didn’t unplug during the robot’s motion. This allowed for the proper transfer of freight from the beater to the bucket. Then, the servo for the second gripper beater was properly wired to make sure that the gripper could intake freight into the gripper properly. Finally, the magnets used to score our team shipping element were reattached so that we could lift FFUTSE’s and placed them on the alliance shipping hub.

Code Modifications

We recently added a new shoulder servo for the crane, and we worked today to help integrate it into the code and fine-tune it. We also dealt with an issue with the code that caused the crane to turn only to the right during freight drop-off.

UIL Posters and Documentation

Bhanaviya, Anisha, and Shawn worked on documentation posters for the UIL State Championship to submit for the awards at State. Bhanaviya worked on the engineering and design posters that highlighted how we developed and designed our robot. Shawn completed the innovate poster, which showed how we thought outside the box and created an innovative design. Anisha worked on the connect and motivate posters which displayed how we connected with industry professionals to improve our robot and how we spread robotics and opportunity to our community. Shawn also worked on designing our pit layout for UIL.

Next Steps

More drive practice. Don’t destroy the robot in the one week before State. Try and not have to pull an all-nighter the night before competition. Continual maintenance and upkeep of the robot would be useful to make sure the robot still works in a week. Documentation will also have to be finished and finalized in the coming week in preparation for UIL.

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

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

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.

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

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

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