Since we chose to build on the swerve platform that we developed over the summer, we needed to make some additions to the code for the swerve platform. The swerve module is built up of two separate rotating parts, a platform, or as we like to call it, a frame, and we have the swerve module itself. While coding the swerve module in the summer, we decided to ignore the rotation of the...
This year’s challenge led Iron Reign down a complex process of developing an efficient means of scoring, which involved the interaction between the intake and outtake. Currently, we are in the process of implementing Forward and Inverse Kinematics to find and alter the orientation of our outtake, known as PixeLeviosa.
...
Today, Iron Reign had its third league meet. It was more successful than our last league meet, with more success with both the drone launcher and our autonomous code. Overall, we went 5-1 and ended up ranked 3rd due to our relatively high tie-breaker points. We ended up perfectly tying with the 2nd place team when it...
A huge focus this season has been navigation; each scoring sequence spans the whole field: from the wing or stacks to the backdrop, and it’s crucial to make this happen as fast as possible to ensure high-scoring games. To do this, the robot needs deep knowledge of all of the components that make...
With the rigging and the backdrops being introduced as huge obstacles to pathing this year, it’s absolutely crucial that the robot knows exactly where it is on the field. Because we have a Mecanum drivetrain, the included motor encoders slip too much for the fine-tuned pathing that we’d like to do. This year, we use...
Today, Iron Reign has its second league meet. It was, in general, a helpful experience and a great chance to compete with local teams. Overall, we went 3-3 and ended up ranked 9th due to our high tie-breaker points. Even though our record was slightly worse compared to the first meet, our robot performance was significantly worse,...
Today was our first league meet, which means all our wins, losses, overall points and points gained in autonomous would count towards league tournament rankings. This was a good opportunity to see how we'd hold up against other robotics teams who all had the same amount of time to prepare for this season's...
Earlier today, we had our first scrimmage at Woodrow Wilson! This was our first proper opportunity to interact with other teams and their robots this season and we got a chance to troubleshoot any design issues with our robot. We entered this scrimmage with our beater bar system in the vague shape...
During our PowerPlay season, we used FTC Dashboard extensively. However, because of some suboptimal code and some limitations of the platform, we were unable to use it to its full potential, especially in regard to the Field View component. We contributed to the repository with some quality-of-life changes that impact the hundreds of FTC teams that use...
This weekend, we participated in the FlySet workshop, graciously hosted by team 8565, TechnicBots. We gave two presentations: one on our summer project, R2V2, and one on changes we made to FTC Dashboard.
Aarav...
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
It’s important to keep in mind that our mobile learning lab is based on a Class...
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...
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...
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...
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...
Trey redesigned the gripper stopper on the underarm to limit the degrees of movement so that the underarm gripper will not get stuck. The original design of the gripper stopper did not fully stop the gripper because it did not limit the gripper's movement as much as we wanted it to.
The tensioning belt on the...
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...
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...
With the Regional competition coming up quite soon, we needed to get to work finishing up the build for TauBotV2, optimizing the code with new inverse kinematics for the double-jointed UnderArm, finishing up some subsystem blog posts, and practicing and preparing our presentation.
With a heavily below-par performance than the Tournament...
Inverse kinematics is the process of finding the joint variables needed for a kinematic chain to reach a specified endpoint. In the context of TauBot2, inverse kinematics, or IK is used in the crane and the UnderArm. In this blog post, we'll be focused on the implementation of IK in the UnderArm.
The goal of...
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...
Today, Iron Reign and our two sister teams competed in the D&U League Tournament at Woodrow Wilson High School, the culmination of the previous three qualifiers. Overall, we did pretty well, winning both Inspire 1 and Think 2, which means we will be directly advancing to the Regional competition in about a month. There...
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...
Today, Iron Reign and our two sister teams participated in the 3rd League Meet for the U League at UME Preparatory for qualification going into the Tournament next week. Overall, we did solid, going 4-2 at the meet; however, we lost significant tiebreaker points in autonomous points due...
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...
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...
Intrinsic Hazards and Safeties
Primary Safety
Backup Safety
Site Safety
Operational Safety
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...
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...
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...
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...
To better prepare for “robot in three days” (ri3d for short), we decided to get ahead a bit and resuscitate the code base. After making sure everything was up to date, we set off on cleaning it up. Going through it, we simplified the movement pipeline, got rid of unused variables, and generally worked on formatting. After which came the big part of the day; getting rid...
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...
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...
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...
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...
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...
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....
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...
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...
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...
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...
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...
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....
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...
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...
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...
Numerous code changes were made during the week before regionals, the most signicant of which were attempted two days before regionals, a costly mistake during competition. Firstly, three different paths were layed out for respective position of the skystone (South, middle, and North), which involved rotating to face the block, driving to the block, extending enough distance to capture the block, and driving towards the foundation afterwards.
Next, we...
Despite putting in lots of effort in order to pull off a working autonomous before regionals, small and subtle issues that surfaced only during testing at the competition as well as various other small bugs with our autonomous routine prevented us from performing well on the field. Trying to write a full autonomous in the last week before competition was a huge mistake, and if more time...
Driving at regionals was unfortunately a learning opportunity for our drivers. In our first few matches, for some reason we couldn't get our robot moving; we faced code crashes, cables being pulled, and incorrect calibration during the transition from autonomous to tele-op. These issues combined with our weak autonomous (sorry coders), led to a very unimpressive robot performance for our first few matches.
... 
Twas the night before regionals, and all through the house, every creature was stirring, especially the raccoons, and boy are they loud.
Anyways, it’s just me and Trey pulling an all nighter tonight, such that he can work on build and I can work on auto. Right now the auto is in a pretty decent...
This saturday, we had the privilege to present our team's Control and Vision algorithms this year to the Dallas Personal Robotics Group. During this event, we described the layout of our robot's control scheme, as well as our OpenCV vision pipeline, in order to gather suggestions for improvement. This opportunity allowed us to improve our pipeline based on the...
With this year's game awarding 20 points to teams than can successfully locate Skystones during autonomous, a fast and reliable OpenCV Pipeline is necessary to succeed in robot game. Our other two choices, using Vuforia and Tensorflow, were ruled out due to high lighting requirements and slow performance, respectively.
With many different morphological operations existing in OpenCV and no clear way to visualize them using a control...
Today we worked on the calibration sequence. This has been a problem for awhile now, as the robot has so many degrees of freedom, and not a single flat edge to square off of (other than the guillotine, but that isn’t necessarily orthogonal to anything), it is rather difficult to come up with some way to ensure precision on startup, and this...
Last night we installed the new Snapdragon gripper, which means we needed to re-work the gripper code. We started out by getting the positions the servo would go to using a servo tester. Then we decided whether to make it an articulation, which originally we did. This articulation would set the servo to pull up the gripper front and then return to its relaxed position. After doing...
This Saturday, we had the privilege of being a vendor at the Annual DISD STEM Expo. While this event served as a good way for us to showcase TomBot at our booth, it also gave us the much-needed chance to experiment with vision. With this year's game rewarding 24 points for locating skystones and placing them onto the...
During the STEM Expo, while also helping volunteer, we worked on auto. There were a series of cascading events that were planned and completed. The first of which was to calculate the TPM of the base. There was, however, a problem before we did that. Our robot has a slight drift when trying to drive straight, which could be solved by driving based off of the...
Today we worked on driving the robot with new presets. Over the weekend, our coders worked on new presets to speed up our cycling time. The first preset the drivers learned was the cardinal directions, which allows the base driver, but potentially both drivers to quickly rotate the turntable 90 degrees. This made switching from intakeing to stacking directions very fast. To further speed up...
Today we worked on driver optimizations, since Justin was here. We changed around the controls for the arm to be more like the drivetrain and the D-pad on controller 1, with the left stick by controlling the elbow, the x controlling the turret, and y on the right stick to control the extension of the arm. This was cited to be more natural to the drivers than the previous setup. Then...
Today we started testing out our new two controller setup. The goal is to have one driver control just the base, and have the other driver control the arm and turret. With the early stage of the 2 driver code, we were able to practice maneuvering around the field and placing blocks. unfortunately the code wasn't completely sorted, so the turret controller lacked many features that...
As we progressively make our robot more autonomous when it comes to repeated tasks, it's time to map these driver enhancements. Since we have so many degrees of freedom with TomBot we will experiment with using two controllers, where one is the main controller for operating the robots and the second handles simpler tasks such as setting the tower height and toggling...
Today is the second to last day of 2019, and therefore the same of the decade. Thus, I want to spend it at robotics. Today I worked solely on vision testing and attempt of implementation. However they ended up being fruitless, but let me not get ahead of myself. To start the day, I tried looking at the example vuforia code that was provided. After...
Since we have decided to move onto using 2 controllers, we can have more room for optimizations and shortcuts/ articulations. One such articulation is the extendToTowerHeight articulation . It takes a value for the current tower height and when a button is pushed, it extends to just over that height, so a block can be placed. This happened in...
Today was a long day, clocking in 10 hrs continuously. In those ten hours, I was able to make tremendous progress. Overall, we have 4 main areas of work done.
The first one gets it’s own blog post, which is the extendToTowerHeight, which encompasses fixing the 2nd controller, calculating the TPM of the arm, and calculating the TPD for the elbow.
The second focus...
With the return of the king(Abhi - an alumni of our team) we were able to make some code changes, mainly dealing with the turret and its IMU since that is our current weak point. At first we experimented with field-centric controls but then realized that for ease of driving the robot, turret-centric control are necessary. After a few lines of...
Getting back from the tournament, we were able to immediately start to think about what was the big problems and possible improvements to the articulations of the robot. Overall, we ended up coming up with several ideas, both for fixing things and for efficiency.
In the competition, we realized the extreme convenience that having some articulations for the...
After the qualifier, along with articulation plans, we had a long list of bugs in the code that needed to be sorted out. Most of them were a direct effect of not being able to test the code until the night before the qualifier. In hindsight, there were some issues which needed to be debugged in the turntable and turret.
The first one that...
This article may seem a bit rushed, but that's because it is - for good reason. Tonight is the night before the qualifier and it’s roughly 2 in the morning. Tonight we got a lot done, but a lot didn’t get done. We can explain.
We finally have a robot in a build state that we could use...
To code TomBot, we decided to use the codebase from Frankendroid, as its the one we were most comfortable with. This will change after the qualifier, as we recognize that the robot is more like last year's robot, Icarus. This will, in the long run, help us as we will be able to...
Over the past month we have used the control hub our robot in 24 hours, FrankenDriod. This was a great way to test its viability before implementing in onto our competition robot. We have already used the control hub at the REV test event where we were given a sample control...
Taking part in the annual Hedrick Scrimmage, we got to test our Robot In 24 Hours, FrankenDroid. Specifically, since both coders on the team are new to the sub-team, we wanted to see the code capabilities we could offer. For this event we had two autonomous paths: the first one simply walks underneath the skybridge for some easy 5...
Tonight, the night before the scrimmage, We worked on making the depositing of the stone and parking of the robot more reliable. Or as reliable as possible, as we are planning to use FrankenDroid, which is somewhat in need of repair, which I also did with the help of Trey, Bhanaviya and Karina. This had a few changes come with it, as while we solved the problems of when we started the auto,...
We didn't do too well in teleop driving at the Hedrick Scrimmage, with our max stone deposit being 2 stones. There are several things to blame.
In usual Iron Reign fashion, we didn't start practicing driving until a day or two before. Since we were not familiar with the controls, we could no perform a maximum...
With the Hedrick Middle School scrimmage being a day away, the robot needs to be in drive testing phase. So, we started out by mapping out controls as depicted above.
Upon testing the controls, we realized that when the robot attempted to move, it was unable to do so without strafing. To fix this issue, we decided...
As seen in the last post, the skeleton of the auto was done. Tonight My goal was to fill it out-- make it do the things it needs to at the points based on the skeleton. This Would have been a bit more automated had we put a distance sensor on the robot, as...
To kick off our autonomous programming, Iron Reign created our first version autonomous path plan. We begin, like all robots, in the the loading stone, its back to the field wall and with our intake arm upwards. We approach the line-up of stones and deploy the arm to its intake state over the last stone. At the same time,...
We've been trying to get our start on autonomous today. We are still using FrankenDroid (our R12D mecanum drive test bot) because our competition bot is taking longer than we wanted. We just started coding, so we are just trying to learn how to use the statemachine class that...
Today we worked on the calibration of FrankenDriod's TPM. This is used to accurately and precisely move during autonomous by having a conversion factor between a given distance and the unit ticks, which is used in the code. This was done by commanding FrankenDroid to move forward 2000 ticks. Of course this wasn't a meter, but the distance...
As the Ri2D bot nears completion, the need for TeleOp code becomes apparent to actually make it move. Since this robot is based of from MiniMech, a previous chassis design for Rover Rockus, the code was simply inserted into its existing class. To allow its subsystems to move and hold their position when they are not, methods for...
In two weeks, Iron Reign is planning on building a robot in 2 days, based on the 2019-2020 Skystone Reveal Video. We've never really built a robot in that short span of a time, so we realized that preparing a suitable chassis ahead of time will make the challenge a lot easier as it gives us time to focus on specific subsystems and code....
It has been a very long time since we have reconsidered our auto paths. Between my last post and now, we have made numerous changes to both the hardware and the articulations. As a result, we should rethink the paths we used and optimize them for scoring. After testing multiple paths and observing other teams, I identified 3 auto paths we will try to perfect for championships.
...
Iron Reign was recently selected to attend a REV Control Hub trial along with select other teams in the region. We wanted to do this so that we could get a good look at the control system that FTC would likely be switching to in the near future, as well as get another chance to test our robot...
It's competition time again, and with that means updating our code. We have made quite a few changes to our robot in the past few weeks, and so we needed to update our code to reflect those changes.
Unfortunately, because the robot build was completed very late, we did not have much time to code. That meant...
Because our robot tends to tip over often, we decided to start working on a dynamic anti-tip algorithm. In order to do so, we needed to be able to find the center of gravity of the robot. We did this by modeling the robot as 5 separate components, finding the center of gravity of each, and then using that to...
In post E-116, I showed all the big wheel articulations. As we shifted our robot to Icarus, we decided to change to a new set of articulations as they would work better to maintain the center of gravity of our robot. Once again, we made 5 major deployment modes. Each articulation is necessary to maintain the robot's center of gravity as its mode of operation shifts. 
With the birth of Icarus came a new job for the programmers: supporting both Bigwheel and Icarus. We needed the code to work both ways because new logic could be developed on bigwheel while the builders completed Icarus.
This was done by simply creating an Enum for the robot type and feeding it into PoseBigWheel initialization. This value was fed into all the subsystems so...
Today we managed to get our robot to balance for 30 seconds after spending about an hour tuning the PID gains. We made significant progress, but there is a flaw in our algorithm that needs to be addressed. At the moment, we have a fixed pitch that we want the robot to balance at but due to the weight distribution of the robot, forcing it to balance at some fixed setpoint will not work well and...
Since our robot has two wheels and a long arm, we decided to take on an interesting problem: balancing our robot on two wheels as do modern hoverboards and Segways. Though the problem had already been solved by others, we tried our own approach.
We first tried a PID control loop approach as we had traditionally been accustomed to that model for our autonomous and such. However, this served as a large challenge as lag in loop times...
A feature that is essential to many advanced autonomous sequences is the ability to know the robots absolute location (x position, y position, heading). For our localization, we determine the robots position relative to the fields coordinate frame. To track our position, we use encoders (to determine displacement) and a gyro (to determine heading).
Our robots translational velocity can be determined by seeing how our encoder counts change over time. Heading velocity is simply how our angle changes in time. Thus, our actual velocity...
At this point in the season, we have time to clean up our code before development for code. This is important to do now so that the code remains understandable as we make many changes for worlds.
There aren't any new features that were added during these commits. In total, there were 12 files changed, 149 additions, and 253 deletions.
Here...
ROAD TO WORLDS - What we need to do
OVERALL:
ENGINEERING JOURNAL: - Charlotte, Ethan, & all freshmen
...
As you already know, Iron Reign has a mechanized cart called Cartbot that we bring to competitions. We used the FTC control system to build it, so we could gain experience. However, this has one issue: we can only use one pair of Robot Controller and Driver Station phones at a competition, because of WiFi interference problems.
To avoid this pitfall, we...
In our motion, our robot shifts multiple major subsystems (the elbow and Superman) that make it difficult to keep the robot from tipping. Therefore, through driver practice, we determined the 5 major deployment modes that would make it easier for the driver to transition from mode to mode. Each articulation is necessary to maintain the robot's center of gravity as its mode of...
With regionals being a week away, the robot needs to be in drive testing phase. So, we started out by mapping out controls as depicted above.
Upon testing the controls, we realized that when the robot went into Superman-mode, it collapsed due to the lopsided structure of the base since the presets were not as accurate as they could be. The...
In the past our autonomous routines were tedious and difficult to change. Adding one step to the beginning of an autonomous would require changing the indexes of every single step afterwards, which could take a long time depending on the size of the routine. In addition, simple typos could go undetected, and cause lots of problems. Finally, there was so much repetitive code, making our...
The picture above is a representation of our work today. After making sure all the manual drive controls were working, Karina found the positions she preferred for intake, deposit, and latch. Taking these encoder values from telemetry, we created new methods for the robot to run to those positions. As a result, the robot was very functional. We could latch onto the lander in 10 seconds (a much faster endgame than...
While at the Wylie quaiifier, we had to make many changes because our robot broke the night before.
First thing that happened was that the belt code was added. Previously, we had relied on gravity and the polycarb locks we had on the slides but we quickly realized that the slides needed to articulate in order to preserve Superman. As a result, we added the belts into our...
It is almost time for competition and with that comes a super duper autonomous. For the past couple of weeks and today, we focused on making our depot side work consistently. Because our robot wasn't fully built, we couldn't do auto-delatching. Today, we integrated our vision pipelines into the auto and tested all the paths with vision. They seemed to work at home base but the field we...
The other day, when running through Bigwheel's controls, we came across an error in the code. The motors on the elbow did not have min and max values for its range of motion, causing the gears to grind in non-optimal conditions. Needless to say, Iron Reign has gone through a few gears already. Adding stops in the code was simple enough:
Testing the code...
One of our priorities this season was our autonomous, as a perfect autonomous could score us a considerable amount of points. A large portion of these points come from sampling, so that was one of our main focuses within autonomous. Throughout the season, we developed a few different approaches to sampling.
Early on in the season, we began experimenting with using a Convolutional Neural Network to detect...
Regionals is coming up, and there are some driving issues that need to be addressed. Going back to November, one notable issue we had at the Conrad qualifier was the lack of friction between Bigwheel's wheels and the field tiles. There was not enough weight resting on the wheels, which made it hard to move suddenly.
Since then many changes have been made to Bigwheel in terms of the...
Today, we implemented our first autonomous path. Since we we still didn't have a complete vision software, we made these manually so we can integrate vision without issues. Here are videos of all of the paths. For the sake of debugging the bot stops after turning towards the crater but in reality it will drive and park in the far crater. These paths will help us score highly...
We implemented OpenCV support in our code, but we hadn’t tested it until now. Upon testing, we realized it didn't work.
The first problem we found was that Vuforia wasn’t reading in our frames. The queue which holds Vuforia frames was always empty. After making lots of small changes, we realized that this was due to not initializing our Vuforia correctly. After fixing this,...
We recently refactored our vision code to allow us to easily swap out vision implementations. We had already implemented TensorFlow, but we hadn't implemented code for using OpenCV instead of TensorFlow. Using the GRIP pipeline we designed earlier, we wrote a class called OpenCVIntegration, which implements VisionProvider. This new class allows us to use OpenCV instead of TensorFlow for our vision implementation. Our code for OpenCVIntegration is shown below....
Iron Reign has been working on multiple vision pipelines, including TensorFlow, OpenCV, and a home-grown Convolutional Neural Network. Until now, all our code assumed that we only used TensorFlow, and we wanted to be able to switch out vision implementations quickly. As such, we decided to abstract away the actual vision pipeline used, which allows us to be able to choose between vision implementations at runtime.
We did this by...
We presented to the DPRG about our computer vision, touching on subjects including OpenCV, Vuforia, TensorFlow, and training our own Convolutional Neural Network. Everyone we presented to was very interested in our work, and they asked us many questions. We also received quite a few suggestions on ways we could improve the performance of our vision solutions. The presentation can be seen below....
Iron Reign has been working hard on our robot, but despite that, we did not perform well owing to our autonomous performance.
Our autonomous plan was fairly simple: perform sampling, deploy the team marker, then drive to the crater to park. We planned to use the built-in TensorFlow object detection for our sampling, and thus assumed that our autonomous would be fairly easy.
On Thursday, I worked on writing a...
FTC released new code to support Tensorflow and automatically detect minerals with the model they trained. Unfortunately, all of our CNN work was undercut by this update. The silver lining is that we have done enough research into how CNN's work and it will allow us to understand the mind of the FTC app better. In addition, we may retrain this model if we feel it doesn't work well. But now, it...
Historically, Iron Reign has used a class called "Pose" to control all the hardware mapping of our robot instead of putting it directly into our opmodes. This has created cleaner code and smoother integration with our crazy functions. However, we used the same Pose for the past two years since both had an almost identical drive base. Since there wasn't a viable differential drive Pose in...
While we were using Python and TensorFlow to train our convolutional neural network, we decided to attempt writing this in Java, as the code for our robot is entirely in Java, and before we can use our neural network, it must be written in Java.
We also decided to try using DL4J, a competing library to TensorFlow, to write our neural network,...
Now that we have gathered and labeled our training data, we began writing our Convolutional Neural Network. Since Abhi had used Python and TensorFlow to write a neural network in the past during his visit to MIT over the summer, we decided to do the same now.
After running our model, however, we noticed that it was not very accurate. Though...
FTC recently released version 4.0 of their SDK, with initial support for external cameras, better PIDF motor control, improved wireless connectivity, new sensors, and other general improvements. Our code was based on last year's SDK version 3.7, so we needed to merge the new SDK with our repository.
The merge was slightly difficult, as there were some issues with...
Now that we have software to make labeling the training data easier, we have to actually use it to label the training images. Abhi and I split up our training data into two halves, and we each labeled one half. Then, when we had completed the labeling, we recombined the images. The images we labeled are publicly available at In order to use the captured training data, we need to label it by identifying the location of the gold mineral in it. We also need to normalize it by resizing the training images to a constant size, (320x240 pixels). While we could do this by hand, it would be a pain to do so. We would...
With the high point potential available in this year's autonomous it is essential to create autonomous paths right now. This year's auto is more complicated due to potential collisions with alliance partners in addition to an unknown period of time spend delatching from the lander. To address both these concerns, I developed 4 autonomous paths we will investigate with to use during competition. When making auto...
In order to train a Convolutional Neural Network, we need a whole bunch of training images. So we got out into the field, and took 125 photos of the sampling setup in different positions and angles. Our next step is to label the gold minerals in all of these photos, so that we can train a Convolutional Neural Network to label the...
Part of this year’s game requires us to be able to detect the location of minerals on the field. The main use for this is in sampling. During autonomous, we need to move only the gold mineral, without touching the silver minerals in order to earn points for sampling. There are a few ways we could be able to detect the location of the gold mineral. ...
So, today was the first meeting in the Rover Ruckus season! On top of that, we had our first round of new recruits (20!). So, it was an extremely hectic session, but we came up with a lot of new ideas. One of the difficulties in writing an autonomous program is the long development cycle. We have to unplug the robot controller, plug it into a computer, make a few changes to the code, recompile and download the code, and then retest our program. All this must be done over and over again, until the...
During Relic Recovery season, we had many problems with our autonomous due to slippage in the mecanum wheels and our need to align to the balancing stone, both of which created high error in our encoder feedback. To address this recurring issue, we searched for an alternative way to identify our position on the field. Upon researching online and discussing with other teams, we discovered an...
Over the past week, I worked with Christian and another member of Imperial to prototype a drive train. Due to the limited resources. we decided to use Tetrix parts since we had an abundance of those. We decided to make the swerve such that a servo would turn a swerve module and the motors would be attached directly to the wheels. Immediately we noticed it was...
Last season, we saw many robots that utilized a swerve drive rather than the mecanum drive for omnidirectional movement. To further expand Iron Reign's repertoire of drive bases, I wanted to further investigate this chassis. Swerve was considered as an alternative to swerve because of its increased speed in addition to the maneuverability of the drive base to allow for quick scoring due to its use of traction wheels at...
We had a functional autonomous for the balacing stone close to the audience. However, chances are that our alliance partner would want that same stone since they could get more glyphs during autonomous. This meant that we needed a multiglyph autonomous for the far balancing stone. We went on an adventure to make this happen. We programmed the robot to drive...
At super regionals, we saw all the good teams having multi glyph autonomi. In fact, Viperbots Hydra, the winning alliance captain, had a 3 glyph autonomous. I believed Iron Reign could get some of this 100 point autonomous action so I sat down to create a 2 glyph autonomous. We now have 3 autonomi, one of which is multiglyph. I made a new methods called autonomous3(). For...
As explained in a previous post, we were having many issues with git commits and fixing our errors in it. After a lot of the merging conflicts, we had to fix all the commits without exactly knowing what was being changed in the code. Part of the reason this was so hard was our lack of good naming conventions. Though we always try to make a title and good...
At this point, we are training the next generation of the drivers on our team, and since we have so many buttons with so many different functions it can often become difficult for the new drivers to determine which button does what, so Karina and I created a map of the controller. By doing this, we not only assist others in determining what button they need to press to do...
We In the past few months we've made a lot of improvements and updates to our robot and code. For example, we changed our gripper system again; it now includes an internal which makes it easier to despite out collected glyphs into the cryptobox. So we have decided to update our control award submission to reflect these changes. One of the leading problems Iron Reign faces is our ability to allot time to effective driving practice. Driving practice is essential for our success in the robot game, but it is sometimes difficult to find time to practice due to other team members working on various robot improvements. We have created two different drive teams, a main team and a backup team, so that despite...
Last Saturday, after our qualifier, we had a team meeting where we created a list of what we needed to do before our second qualifier this Saturday. One of the tasks was to create the control award which we were unfortunately unable to complete in time for our last competition. Iron Reign’s robot drivers Abhi, Charlotte, and I, have been working hard to decrease our team’s glyph-scoring time. The past few meets, we have spent many hours practicing maneuvering on the field and around blocks, something that is crucial if we want to go far this competition season. When we first started driving the robot, we took approximately 4 minutes to complete a single...
So, we can't include all the code changes we made today, but all of it involved cleaning up our code, removing extra functions we didn't use, refactoring, adding comments, and making it more readable for the tournament. We had almost 80k deletions and 80k additions. This marks a turning point in the readablity of our code so that less experienced team members can read it....
Today we tried to drive the robot on the practice field for the first time since the qualifier last Saturday. However, we couldn't get in very much quality drive practice because the robot kept breaking down. We decided to dig a bit deeper and found some issues. As seen above, the first thing that was wrong was that the lift was tilted. Due to the cantilever orientation of the...
These commits add said functionality: These commits allow better QoL for our drivers, allow our robot to function more smoothly both in autonomous and during TeleOp, allows us to score the jewels, and lets us test servos. We attempted to create an autonomous for our first scrimmage. It aimed to make the robot to drive forward and drive into the safe zone. However, we forgot to align the robot and it failed at the scrimmage. Instead of talking about the code like usual, the code's main functions are well documented so that any person can understand its functions without a prior knowledge of...
We’ve been using machine vision for a couple of years now and have a plan to use it in Relic Rescue for a number of things. I mostly haven’t gotten to it because college application deadlines have a higher priority for me this year. But since we already have experience with color blob tracking in OpenCV and Vuforia tracking, I hope this won’t be too difficult. We have 5 different things we want to try: VuMark decode – this is obvious since...
Though our current gripper is working sufficiently, there are some issues we would like to improve in our second version. The mounting system is unstable and easily comes out of alignment because the rev rail keeps bending. Another issue we've encountered is the cervo pulling the grippers so that they begin to cave inwards, releasing any blocks being held at the bottom. By far the biggest problem is...
To allow each user to create their own settings, we're designing a way to allow the user to tune PID to their own liking from the controller. This also enables debugging for our robot. We're currently testing code to give Argos a balancing system so that we can demo it. This is also a test for the PID in the new REV robotics expansion hubs, which we plan on switching to for this season if reliable. Example code is below. Last year, we had some experience with OpenCV to press the beacons, and this year we decided to do the same. We use OpenCV to find the color we are looking for on the beacon in conjunction with Vuforia. First, it detects the search pattern in the view with vuforia, then isolates that area and finds the side of the beacon with the correct color. Our code is...
We use Vuforia and Open CV vision to autonomously drive our robot to the beacon and then click the button corresponding to our team's colour. We started this by getting the robot the recognize the image below the beacon and keep it within its line of vision. Vuforia is used by the phone's camera to inspect it's surroundings, and to locate target images. When images are located, Vuforia...
One of the leading problems Iron Reign faces is our ability to allot time to effective driving practice. Driving practice is essential for our success in the robot game, but it is sometimes difficult to find time to practice due to other team members working on various robot improvements. We have created two different drive teams, a main team and a backup...
To tell the robot how far to move forward we had to calculate our motors RPM. We did this by telling the robot move to 10 rotations forward and calculating how far it travelled. After he RPM we created a model field upon which we designed a set path for the robot during autonomous. One path for red and then one for blue....
This shows a test of our encoder issues. It might have been a month ago that we noticed a strange behavior in our autonomous code when the robot was moving forward at low speed. It would curve to the right when we were telling it to go straight. We probably would have noticed the problem...
Today, I wrote the whole code for controlling our mecanum wheels. It is entirely fron scratch, and works perfectly right off the bat. This code allows us to strafe, move backwards and forwards, and rotate, in one method. We still have a lot of coding to do, as we're currently working on a particle-launching system. As well, we need to consider autonomous soon. Now that our new robot has been built with a mecanum wheel platform, we can start write our drive code and figure out how to make our robot preform three basic motions: forwards and backwards, side-to-side and to rotate. We decided that, in order to get the best understanding of our robot,...
After the long weekend last week, today was a reasonably relaxed practice. We decided that we could work on anything, as long we stayed focused. The two main foci were the -Robot on a Hoverboard- and fine tuning our PID for autonomous. We experimented with balancing the robot more evenly on the hoverboard to keep it on a straight path...
Our tape measure is constantly under stress, which usually isn't a big problem if the driver is positioned with a straight 90 degree angle, but when twisted can result in cracks. While our tape-measure design worked decently at our competition last week, with multiple mid zone scores and one high zone score, we are going to need more consistency to be a valuable ally in our matches. At...
In order to find a button for our argos mode drive, we made a rough draft of our game controller listing the functions of each button. For example, the 'X' button is for the churo climb, the 'A' button is for our beater to stop, etc. We had about 5 unused buttons so in the end, we decided on using the top left button for argos mode drive. Now that...
Today we were refining our ramp autonomous by debugging the gyro code. We found that our "goYonder" and "goBackward" method were affecting each other which was making our robot work incorrectly and just going crazy. Referencing the earlier article explaining robot functions needing to be assigned buttons, we had a meeting to get the control scheme actually implemented into the controllers. The picture above displays the majority of the control scheme. Some values were changed such as the ski lift values. CNN Training Program
Read More
Task: Designing a program to label training data for our Convolutional Neural Network
Autonomous Path Planning
Read More
Task: Map Autonomous paths
CNN Training
Read More
Task: Capture training data for a Convolutional Neural Network
Vision Discussion
Read More
Task: Consider potential vision approaches for sampling
Rover Ruckus Brainstorming & Initial Thoughts
Read More
Task: Come up with ideas for the 2018-19 season
Building
This suggestion uses a...
Replay Autonomous
Read More
Task: Design a program to record and replay a driver run
Position Tracking
Read More
Task: Design a way to track the robot's location
Swerve Drive Prototype
Read More
Task: Build a Swerve Drive base
Swerve Drive Experiment
Read More
Task: Consider a Swerve Drive base
Autonomous Updates, Multiglyph Part 2
Read More
Task: Develop multiglyph for far Stone
Autonomous Updates, Multi-glyph
Read More
Task: Score extra autonomous glyphs
Importance of Documentation
Read More
Task: Explain commits
Controller Mapping
Read More
Task: Map the controller layout
Kraken LED Modes
Read More
Task: Attach and Code LEDs
Control Award Updates
Read More
Task:
Autonomous Objective:
Robot Drive Team
Read More
Task: Build a solid drive team.
Control Award
Read More
Task:
Autonomous Objective:
Drive Practice
Read More
Task: Become experts at driving the robot and scoring glyphs
Code Fixes and Readability
Read More
Task: Make the code more readable
Driving Struggles
Read More
Task: Drive the Robot
Adding Code Fixes to the Robot
Read More
Task: Add code updates
Jewel Arm
...
Working on Autonomous
Read More
Task: Create a temporary autonomous for the bot
Machine Vision Goals – Part 1
Read More
Testing Materials
Read More
Task: Test Materials for V2 Gripper
PID Calibration and Testing
Task: Allow user to change PID coefficients from the controller
public void Read More
Balancing and PID
Task: Test and improve the PID system and balance code
OpenCV
Read More
Task: Implement OpenCV in autonomous
Vuforia
Read More
Task: Use Vuforia to enhance autonomous
Robot Drive Team
Read More
Task: Build a solid drive team.
Mapping Out Autonomous
Read More
Task: Mapping Out Autonomous
Fixing Faulty Encoder
Read More
Task: Fix a faulty encoder on our robot
Mecanum Driving
Read More
Task: Code driving under mecanum wheels
Reflections
Programming our New Robot
Read More
Task: Program our new mecanum wheel driving platform
Hoverboards and PID
Read More
Task: Continue with the Hoverboard and tweak PID
Reflections
The Double-Wide Experiment
Read More
Task: Strengthen our tape-measure climber against folding and sideways forces
Functions of our controller
Read More
Task: Listing out the functions of our game controller
Control Scheme
Read More
Task: Test Autonomous and debugging
Reflections:
Our approach to fixing our autonomous has yielded some promising results. When we started practice the autonomous code only worked every other time, failing when we compiled for the first time per connect and...
Control Scheme
Read More
Task: Assign control scheme to actual competition controller
Reflections:
With our control scheme now advancing to the testable stage, we now have the ability to alter values and fpcus on the controls of possible future attachments...
