Articles by tag: control

# Accounting For Offsets And Launching In Motion

Accounting For Offsets And Launching In Motion By Mahesh

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

# Control Mapping

Control Mapping By Bhanaviya, Mahesh, and Cooper

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

# Achieving Continuous Targeting and Launching

Achieving Continuous Targeting and Launching By Mahesh and Cooper

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

# Adding Margins Of Error To Desmos

Adding Margins Of Error To Desmos By Mahesh

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

# Fixing Odometry

Fixing Odometry By Cooper and Mahesh

### Task: find and fix old odometry code

This year, more than the 2 previous years, odometry plays a critical role in our solution while vision is on the fritz. This is due to the fact that we plan to do continuous targeting, which requires a way to know the distance and angle to any given target. Our original plan was to use VuForia, but after preliminary testing gave mixed results, we...

# Accounting For Initial Height

Accounting For Initial Height By Mahesh

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

# Ring Launcher 9000 On-Bot Testing

Ring Launcher 9000 On-Bot Testing By Cooper and Jose

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

# Pink v. Cyan Remote Scrimmage Code Post Mortem

Pink v. Cyan Remote Scrimmage Code Post Mortem By Cooper

### Task: review the code changes needed from our latest scrimmage

After looking over the progression of matches of the scrimmage, it is obvious that there needs to be some code changes. I’d like to go over in detail those issues, and how they’d be solved.

First off, the issue prevalent when the robot turns in auton- the PID loops aren’t tuned. The PID constants were from last...

# Pink v. Cyan Remote Scrimmage Post Mortem

Pink v. Cyan Remote Scrimmage Post Mortem By Cooper and Jose

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

# Programming Session 1/31

Programming Session 1/31 By Mahesh and Cooper

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

# Derive And Translate Trajectory Calculations Into Code

Derive And Translate Trajectory Calculations Into Code By Mahesh, Cooper, Shawn, Ben, Bhanaviya, and Jose

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

# Correcting the Trajectory Calculations Equations

Correcting the Trajectory Calculations Equations By Bhanaviya, Ben, and Mahesh

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

# Iterate Trajectory Calculations in Preparation for DPRG Meet

Iterate Trajectory Calculations in Preparation for DPRG Meet By Bhanaviya, Mahesh, and Ben

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

# Code Changes Leading up to the PvC Scrimmage

Code Changes Leading up to the PvC Scrimmage By Cooper

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

# Auto Path Plan

Auto Path Plan By Cooper

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

# Code Planning For The New Season

Code Planning For The New Season By Mahesh

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

# Code Changes The Week Before Regionals

Code Changes The Week Before Regionals By Mahesh and Cooper

### Task: Assess Code Changes During The Week Before Regionals

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

# Wylie East Regional Qualifier Code Post-Mortem

Wylie East Regional Qualifier Code Post-Mortem By Mahesh and Cooper

### Task: Reflect On Code Changes And Choices Made During The Wylie East Regional Qualifier

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

Driving at Regionals By Justin, Aaron, and Jose

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.

...

# The Night Before Regionals - Code

The Night Before Regionals - Code By Cooper and Trey

### Task: Fix our autonomous path the night before regionals.

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

# Control And Vision DPRG Presentation

Control And Vision DPRG Presentation By Mahesh and Cooper

### Task: Present Control And Vision To DPRG And Gather Feedback

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

# OpenCV Grip Pipeline

OpenCV Grip Pipeline By Mahesh

### Task: Develop An OpenCV GRIP Pipeline To Detect Skystones

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

# TomBot Calibration Sequence

TomBot Calibration Sequence By Cooper

### Task: Create a calibration sequence to find a starting position for autonomous

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

# Coding the Snapdragon Gripper

Coding the Snapdragon Gripper By Cooper

### Task: Code the new Snapdragon gripper

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

# Code Changes At STEM Expo

Code Changes At STEM Expo By Mahesh, Cooper, and Abhi

### Task: Use Vuforia To Detect Skystones And Tune Ticks Per Meter

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

# Auto Developments at the STEM Expo

Auto Developments at the STEM Expo By Cooper

### Task: Improve autonomous and tune IMU

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

# Drive Practice 1/6

Drive Practice 1/6 By Justin and Aaron

### Task: Practice driving with new code

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

# Driver Optimization Developments 5/1

Driver Optimization Developments 5/1 By Cooper

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

# Testing Two Drivers

Testing Two Drivers By Justin and Aaron

### Task: Practice driving with two drivers

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

# Control Mapping v2

Control Mapping v2 By Jose

### Task: Map out the new control scheme

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

# Last Coding Session of the Decade

Last Coding Session of the Decade By Cooper

### Task: Gripper swivel, extendToTowerHeight, and retractFromTowerHeight. Oh My!

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

# Extend to Tower Height and Retract from Tower

Extend to Tower Height and Retract from Tower By Cooper

### Task: Develop the controller so that it can extend to tower height

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

# Code Developments 12/28

Code Developments 12/28 By Cooper

### Task: Gripper swivel, extendToTowerHeight, and retractFromTowerHeight. Oh My!

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

# Turret IMU Code

Turret IMU Code By Jose and Abhi

### Task: Code some driver enhancements for the turret

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

# Future TomBot Articulations

Future TomBot Articulations By Cooper

### Task: Plan out potential robot articulations to improve game strategy

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.

### 1- Turntable Articulations

In the competition, we realized the extreme convenience that having some articulations for the...

# Post-Qualifier Code Debugging

Post-Qualifier Code Debugging By Cooper

### Task: Debug code after the Allen Qualifier

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

# Last Minute Code Changes

Last Minute Code Changes By Cooper

### Task: Debug some last-minute code to be ready for our first qualifier of the season

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

# Coding TomBot

Coding TomBot By Cooper and Jose

### Task: Use existing code from the code base to program TomBot

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

# Transition from Expansion Hub to Control Hub

Transition from Expansion Hub to Control Hub By Jose and Cooper

### Task: Discuss the transition from using the Expansion Hub to using the Control Hub

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

# Hedrick Scrimmage - Code

Hedrick Scrimmage - Code By Jose and Cooper

### Task: Discuss what went and what needs improvement in our code

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

# Coding Before Scrimmage

Coding Before Scrimmage By Cooper, Karina, Bhanaviya, and Trey

### Task: Finish the temporary auto and work with drivers for teleop

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

# Driving at the Hedrick Scrimmage

Driving at the Hedrick Scrimmage By Karina and Jose

### Task: Figure out what went wrong at the scrimmage

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

# Control Mapping

Control Mapping By Bhanaviya and Cooper

### Task: Map and test controls

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

# Coding 10/19/19 (Putting meat on the skeleton)

Coding 10/19/19 (Putting meat on the skeleton) By Cooper

### Task: work on actually filling out the auto

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

# Auto Path 1

Auto Path 1 By Karina and Jose

### Task: Lay out our robot's path for autonomous

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

# Beginning Auto Stone

Beginning Auto Stone By Cooper and Karina

### Task: Design an intake for the stones based on wheels

Initial Design: Rolling Intake

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

# FrankenDroid - TPM Calibration

FrankenDroid - TPM Calibration By Jose, Cooper, and Bhanaviya

### Task: Calibrate FrankenDriod's Ticks Per Meter in preparation of programming autonomous

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

# Ri2D Code

Ri2D Code By Jose

### Task: Code a Basic TeleOp Code for the Ri2D bot using pre-existing classes and methods

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

# Fixing Mini-Mech

Fixing Mini-Mech By Cooper

### Task: Fix Mini-Mech in time for the Skystone reveal

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

# Auto Paths, Updated

Auto Paths, Updated By Abhi

### Task: Reflect and develop auto paths

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.

...

# Control Hub First Impressions

Control Hub First Impressions By Arjun and Abhi

### Task: Test the REV Control Hub ahead of the REV trial

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

Code updates at UIL By Arjun, Abhi, and Ben O

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

# Center of Gravity calculations

Center of Gravity calculations By Arjun

### Task: Determine equations to find robot Center of Gravity

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

# Reverse Articulations

Reverse Articulations By Abhi

### Task: Summary of Icarus Movements

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.

# Icarus Code Support

Icarus Code Support By Abhi

### Task: Implement dual robot code

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

Balancing Robot Updates By Abhi and Ben

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

# Balancing Robot

Balancing Robot By Abhi and Ben

### Initial Work on Balancing Robot

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

# Localization

Localization By Ben

### Localization

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

# Code Refactor

Code Refactor By Abhi and Arjun

### Task: Code cleanup and season analysis

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 Document By Ethan, Charlotte, Evan, Karina, Janavi, Jose, Ben, Justin, Arjun, Abhi, and Bhanaviya

### Task: Consider what we need to do in the coming months

ROAD TO WORLDS - What we need to do

OVERALL:

• New social media manager (Janavi/Ben) and photographer (Ethan, Paul, and Charlotte)

ENGINEERING JOURNAL: - Charlotte, Ethan, & all freshmen

• Big one - freshmen get to start doing a lot more

...

# Cart Hack

Cart Hack By Arjun

### Task: Tweaking ftc_app to allow us to drive robots without a Driver Station phone

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

# Big Wheel Articulations

Big Wheel Articulations By Abhi

### Task: Summary of all Big Wheel movements

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

# Control Mapping

Control Mapping By Bhanaviya, Abhi, Ben, and Karina

### Task: Map and test controls

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

# Autonomous Non-Blocking State Machines

Autonomous Non-Blocking State Machines By Arjun

### Task: Design a state machine class to make autonomous easier

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

# Competition Day Code

Competition Day Code By Abhi and Arjun

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

Code Updates By Abhi and Arjun

### Task: Detail last-minute code changes to autonomous

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

# Minor Code Change

Minor Code Change By Karina

### Task: Save Bigwheel from self destruction

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

# Vision Summary

Vision Summary By Arjun and Abhi

### Task: Reflect on our vision development

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

# Issues with Driving

Issues with Driving By Karina

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

# Auto Paths

Auto Paths By Abhi

### Task: Map and code auto for depot side start

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

# Debug OpenCV Errors

Debug OpenCV Errors By Arjun

### Task: Use black magic to fix errors in our code

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

# OpenCV Support

OpenCV Support By Arjun

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

# Refactoring Vision Code

Refactoring Vision Code By Arjun

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

# DPRG Vision Presentation

DPRG Vision Presentation By Arjun and Abhi

### Task: Present to the Dallas Personal Robotics Group about computer vision

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

# Code Post-Mortem after Conrad Qualifier

Code Post-Mortem after Conrad Qualifier By Arjun and Abhi

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

# RIP CNN

RIP CNN By Abhi

### Task: Farewell Iron Reign's CNN

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

# Pose BigWheel

Pose BigWheel By Abhi

### Task: New Pose for Big Wheel robot

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

# Rewriting CNN

Rewriting CNN By Arjun and Abhi

### Task: Begin rewriting the Convolutional Neural Network using Java and DL4J

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

# Developing a CNN

Developing a CNN By Arjun and Abhi

### Task: Begin developing a Convolutional Neural Network using TensorFlow and Python

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

# Upgrading to FTC SDK version 4.0

Upgrading to FTC SDK version 4.0 By Arjun

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

# Labelling Minerals - CNN

Labelling Minerals - CNN By Arjun and Abhi

### Task: Label training images to train a Neural Network

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 Read More

# CNN Training Program

CNN Training Program By Arjun and Abhi

### Task: Designing a program to label training data for our Convolutional Neural Network

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

# Autonomous Path Planning

Autonomous Path Planning By Abhi

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

# CNN Training

CNN Training By Arjun and Abhi

### Task: Capture training data for a Convolutional Neural Network

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

# Vision Discussion

Vision Discussion By Arjun and Abhi

### Task: Consider potential vision approaches for sampling

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.

...

# Rover Ruckus Brainstorming & Initial Thoughts

Rover Ruckus Brainstorming & Initial Thoughts By Ethan, Charlotte, Kenna, Evan, Abhi, Arjun, Karina, and Justin

### Task: Come up with ideas for the 2018-19 season

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.

#### Building

• A One-way Intake System

• This suggestion uses a...

# Replay Autonomous

Replay Autonomous By Arjun

### Task: Design a program to record and replay a driver run

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

# Position Tracking

Position Tracking By Abhi

### Task: Design a way to track the robot's location

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

# Swerve Drive Prototype

Swerve Drive Prototype By Abhi and Christian

### Task: Build a Swerve Drive base

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

# Swerve Drive Experiment

Swerve Drive Experiment By Abhi

### Task: Consider a Swerve Drive base

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

# Autonomous Updates, Multiglyph Part 2

Autonomous Updates, Multiglyph Part 2 By Abhi, Karina, and Tycho

### Task: Develop multiglyph for far Stone

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

### Task: Score extra autonomous glyphs

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

# Importance of Documentation

Importance of Documentation By Abhi and Tycho

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

# Controller Mapping

Controller Mapping By Janavi

### Task: Map the controller layout

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

# Kraken LED Modes

Kraken LED Modes By Tycho and Janavi

### Task: Attach and Code LEDs

We added LED's to Kraken's base. After that, we coded the lights to change color depending on which mode we are in. Though a small addition, it helps take stress off of our drivers. By glancing at the robot, they can immediately tell what mode we're in and can adjust accordingly. It also keeps us from making an crucial mistakes like activating our autonomous for blue...

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.

### Autonomous Objective:

1. Knock off opponent's Jewel, place glyphs in correct location based on...

# Robot Drive Team

Robot Drive Team By Charlotte, Tycho, Karina, and Evan

### Task: Build a solid drive team.

One of the leading problems Iron Reign faces is our ability to allot time to effective driving practice. Driving practice is essential for our success in the robot game, but it is sometimes difficult to find time to practice due to other team members working on various robot improvements. We have created two different drive teams, a main team and a backup team, so that despite...

# Control Award

Control Award By Janavi

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.

### Autonomous Objective:

1. Knock off opponent's Jewel, place glyphs In correct location based on image, park in safe zone (85 pts)
2. Park...

# Drive Practice

Drive Practice By Karina, Charlotte, and Abhi

### Task: Become experts at driving the robot and scoring glyphs

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

Code Fixes and Readability By Tycho

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

# Driving Struggles

Driving Struggles By Abhi

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

# Adding Code Fixes to the Robot

Adding Code Fixes to the Robot By Tycho

• Pre-game logic - joystick control
• Fix PID settings
• Autonomous resets motor
• Jewel Arm functionality
• Autonomous changes
• Tests servos

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.

...

# Working on Autonomous

Working on Autonomous By Tycho

### Task: Create a temporary autonomous for the bot

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

# Machine Vision Goals – Part 1

Machine Vision Goals – Part 1 By Tycho

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

# Testing Materials

Testing Materials By Austin, Evan, and and Tycho

### Task: Test Materials for V2 Gripper

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

# PID Calibration and Testing

PID Calibration and Testing By Tycho

### Task: Allow user to change PID coefficients from the controller

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.

public void Read More


# Balancing and PID

Balancing and PID By Tycho

### Task: Test and improve the PID system and balance code

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.





# OpenCV

OpenCV By Ethan and Tycho

### Task: Implement OpenCV in autonomous

Last year, we had some experience with OpenCV to press the beacons, and this year we decided to do the same. We use OpenCV to find the color we are looking for on the beacon in conjunction with Vuforia. First, it detects the search pattern in the view with vuforia, then isolates that area and finds the side of the beacon with the correct color. Our code is...

# Vuforia

Vuforia By Janavi and Tycho

### Task: Use Vuforia to enhance autonomous

We use Vuforia and Open CV vision to autonomously drive our robot to the beacon and then click the button corresponding to our team's colour. We started this by getting the robot the recognize the image below the beacon and keep it within its line of vision. Vuforia is used by the phone's camera to inspect it's surroundings, and to locate target images. When images are located, Vuforia...

# Robot Drive Team

Robot Drive Team By Charlotte, Tycho, Karina, and Evan

### Task: Build a solid drive team.

One of the leading problems Iron Reign faces is our ability to allot time to effective driving practice. Driving practice is essential for our success in the robot game, but it is sometimes difficult to find time to practice due to other team members working on various robot improvements. We have created two different drive teams, a main team and a backup...

# Mapping Out Autonomous

Mapping Out Autonomous By Janavi, Tycho, Omar, Evan, and Darshan

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

# Fixing Faulty Encoder

Fixing Faulty Encoder By Tycho and Jayesh

### Task: Fix a faulty encoder on our robot

This shows a test of our encoder issues. It might have been a month ago that we noticed a strange behavior in our autonomous code when the robot was moving forward at low speed. It would curve to the right when we were telling it to go straight. We probably would have noticed the problem...

# Mecanum Driving

Mecanum Driving By Tycho

### Task: Code driving under mecanum wheels

Today, I wrote the whole code for controlling our mecanum wheels. It is entirely fron scratch, and works perfectly right off the bat. This code allows us to strafe, move backwards and forwards, and rotate, in one method.

### Reflections

We still have a lot of coding to do, as we're currently working on a particle-launching system. As well, we need to consider autonomous soon.

...

# Programming our New Robot

Programming our New Robot By Tycho, Lin, Ethan, and Jayesh

### Task: Program our new mecanum wheel driving platform

Now that our new robot has been built with a mecanum wheel platform, we can start write our drive code and figure out how to make our robot preform three basic motions: forwards and backwards, side-to-side and to rotate. We decided that, in order to get the best understanding of our robot,...

# Hoverboards and PID

Hoverboards and PID By Lin, Omar, Darshan, Tycho, and Max

### Task: Continue with the Hoverboard and tweak PID

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.

### Reflections

We experimented with balancing the robot more evenly on the hoverboard to keep it on a straight path...

# The Double-Wide Experiment

The Double-Wide Experiment By Jayesh, Max, Dylan, and Evan

### Task: Strengthen our tape-measure climber against folding and sideways forces

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

# Functions of our controller

Functions of our controller By Alisa, Ethan, Trace

### Task: Listing out the functions of our game controller

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

# Control Scheme

Control Scheme By Darshan, Lin, Tycho, Max, Jayesh, and Omar

#### Task: Test Autonomous and debugging

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.

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