Please help support our team! $25 buys a motor, $50 buys a new battery, $150 adds controllers and sensors, $500 pays tournament fees, $750 upgrades our drivetrain

Iron Reign

Welcome to Iron Reign at Dallas ISD's Science and Engineering Magnet

Articles by section: engineering

Balancing and PID

20 Aug 2017
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.

+ public void BalanceArgos(double Kp, double Ki, double Kd, double pwr, double currentAngle, double targetAngle)
+{
+ //sanity check - exit balance mode if we are out of recovery range
+
+
+
+ if (isBalanceMode()){ //only balance in the right mode
+
+ setHeadTilt(nod);
+
+ //servo steering should be locked straight ahead
+ servoSteerFront.setPosition(.5);
+ servoSteerBack.setPosition(0.5);
+
+ //double pwr = clampMotor((roll-staticBalance)*-.05);
+
+ balancePID.setOutputRange(-.5,.5);
+ balancePID.setPID(Kp, Ki, Kd);
+ balancePID.setSetpoint(staticBalance);
+ balancePID.enable();
+ balancePID.setInput(currentAngle);
+ double correction = balancePID.performPID();
+
+ logger.UpdateLog(Long.toString(System.nanoTime()) + ","
+ + Double.toString(balancePID.getDeltaTime()) + ","
+ + Double.toString(currentAngle) + ","
+ + Double.toString(balancePID.getError()) + ","
+ + Double.toString(balancePID.getTotalError()) + ","
+ + Double.toString(balancePID.getDeltaError()) + ","
+ + Double.toString(balancePID.getPwrP()) + ","
+ + Double.toString(balancePID.getPwrI()) + ","
+ + Double.toString(balancePID.getPwrD()) + ","
+ + Double.toString(correction));
+
+ timeStamp=System.nanoTime();
+ motorFront.setPower(correction);
+

Reflections

REV Robot Reveal

24 Aug 2017
REV Robot Reveal By Tycho, Austin, Charlotte, Omar, Evan, and Janavi

Argos V2 - a REV Robot Reveal

This video was pulled from Argos visits to: The NSTA STEM Expo in Kissimmee FL, in the path of eclipse totality in Tennessee, and in North Texas at The Dallas Makerspace, The Southwest Center Mall, Southside on Lamar and the Frontiers of Flight Museum. We hope you find it interesting:

PID Calibration and Testing

27 Aug 2017
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 PIDTune(PIDController pid, boolean pidIncrease, boolean pidDecrease, boolean magnitudeIncrease, boolean magnitudeDecrease, boolean shouldStateIncrement){
+ if(shouldStateIncrement){ pidTunerState = stateIncrement(pidTunerState, 0, 2, true); }
+ if(magnitudeIncrease){ pidTunerMagnitude *= 10; }
+ if(magnitudeDecrease){ pidTunerMagnitude /= 10; }
+
+ double dir;
+
+ if(pidIncrease) dir = 1;
+ else if (pidDecrease) dir = -1;
+ else if (pidDecrease) dir = -1;
+ else dir = 0;
+
+ switch(pidTunerState){
+ case 0:
+ pid.setPID(pid.getP() + pidTunerMagnitude*dir, pid.getI(), pid.getD());
+ break;
+ case 1:
+ pid.setPID(pid.getP(), pid.getI() + pidTunerMagnitude*dir, pid.getD());
+ break;
+ case 2:
+ pid.setPID(pid.getP(), pid.getI(), pid.getD() + pidTunerMagnitude*dir);
+ break;
+
+ }
+ }
+ + public double getPidTunerMagnitude() {return pidTunerMagnitude;}
+
+ public int getPidTunerState() {return pidTunerState;}
+
+ public int stateIncrement(int val, int minVal, int maxVal, boolean increase){
+ if(increase){
+ if(val == maxVal){
+ return minVal;
+ }
+ val++;
+ return val;
+ }
+ else{
+ if(val == minVal){
+ return maxVal;
+ }
+ val--;
+ return val;
+ }
+ }
+

Meeting Log

09 Sep 2017
Meeting Log September 09, 2017 By Ethan, Evan, Abhi, Tycho, Austin, Karina, and Kenna

Meeting Log September 09, 2017

Today was the first meeting of the Relic Recovery season. Our main focus today was strategy, then organization and getting the robot ready for this year's challenges

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • Write blog post for Kickoff
  • Fix dates for indexPrintable
  • Blog post catchup
  • Strategy review

Software

  • Glyph recognition OpenCV
  • Aspiring programmer's code review

Build / Modelling

  • Teardown old robot
  • Design Competition - glyph grabber

Service / Outreach

  • Kickoff

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
EthanKickoff post2:002
EthanFix dates4:002
EvanDesign Competition2:004
AustinTeardown robot2:002
AustinDesign Competion4:002
TychoCode review2:004
KennaBlog review2:004
KarinaStrategy review2:004
AbhiStrategy review2:004
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001
PeopleTask2:001

Intake System Competition

09 Sep 2017
Intake System Competition By Evan and Austin

Task: Compare build designs for the cryptobox intake system

The block scoring system is going to be an integral part of the competition this year, and it will have to built sturdy. It’ll have to be reliable for us to have any shot of winning any matches. So we got to brainstorming. Me and Austin spent a while at the whiteboard, drawing up various mechanisms and ways to pick up blocks. I became set behind the idea of a block delivering system similar to those modern vending machines that have two degree of freedom movement. I began to design the contraption so that a conveyor belt could be placed on an up and down linear slide to position the blocks just right to make the different symbols. Austin came up with the idea to use our tank treads from Gebb, our competition robot from two years ago, to push the blocks up a ramp and deposit them into the cryptoboxes. Neither of us could convince the other about what was to be done, so we both split off to work on our own models. Next week we will keep working on this build off of the century.

Meeting Log

16 Sep 2017
Meeting Log September 16, 2017 By Ethan, Evan, Karina, Tycho, Austin, Charlotte, and Kenna

Meeting Log September 16, 2017

Today we had a major outreach event at Conrad HS in DISD which served around 450 people. We also planned on continuing our building competition, working on strategy, the blog, and the robot teardown.

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • Conrad post
  • About page - new members
  • Strategy

Software

  • Code review

Build / Modelling

  • Complete robot teardown
  • Finish design competition
  • Install REV hubs

Service / Outreach

  • Conrad HS volunteering

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
EthanConrad post2:002
EthanAbout page4:002
EvanDesign competition2:004
AustinRobot teardown2:001
AustinREV hubs3:001
AustinDesign competition4:002
KarinaAbout page2:002
KarinaStrategy4:002
TychoCode review2:004
CharlotteConrad post2:004

Further Design of the Intake

16 Sep 2017
Further Design of the Intake By Evan and Austin

Task: Design the grabbing systems further

The sun came out and it was back to the field. We got started right away, both of us building our designs. Since the cryptoboxes were wider than the 18 inch sizing cube, I started by designing a fold out for the conveyor belt. This was entirely proof of concept, purely to see if it was at all aplicable in the game this year. I spent an hour or two gathering parts and put together an extending conveyor belt. This device would swing down, like the arrow suggests, allowing for more space to move the blocks back in forth, giving us accuracy in rune completion. This will be later attached to linear slides, allowing for an up and down motion.

Intake Systems

17 Sep 2017
Intake Systems By Austin

Task: Work on designs for the intake system

Over the past couple of days we’ve experimented with a horizontally mounted track system that we had hoped would serve to move blocks through the entire length of the robot and into the crypto box. Immediately we noticed a few issues, the primary one being that the tread was static in terms of mounting and therefore wasn’t accepting of blocks when feed at an odd angle. To correct our feeding issue, we widened the gap between the tracks and added rubber bands in hopes of maintaining traction and adding to on demand orientation ability.

Initial tests of our second prototype went fairly well, however the design suffered from some severe drawbacks; the first was its weight and size which would limit robot mobility and take up much needed space for other components, the second issue was that keeping the treads tensioned perfectly for long periods of time was nearly impossible and they would often sag leading to loss of grip, and finally the system was still fairly unpredictable especially during intake (blocks were flung occasionally). These finding lead me to believe we may scrap the idea in consideration of time.

Aside from our track intake we’ve also been working on a griper and slide system that shows promise.

Meeting Log

23 Sep 2017
Meeting Log September 23, 2017 By Charlotte, Kenna, Tycho, Austin, and Evan

Meeting Log September 23, 2017

We started the day by volunteering at LV Stockard MS, another DISD event. During our practice, we planned to work on robot design, blog updates, and code testing.

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • About page updates
  • Stockard blog post

Software

  • Controller mapping

Build / Modelling

  • Cryptobox grabber - competition judging
  • Install chosen grabber
  • Reposition robot hubs

Service / Outreach

  • Stockard MS DISD

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
CharlotteStockard post2:002
CharlotteCompetition judging4:002
KennaAbout page2:002
KennaCompetition judging4:002
TychoController mapping2:004
AustinCompetition judging2:002
AustinInstall grabber4:002
EvanCompetition judging2:002
EvanMove hubs4:002

Narrowing Down the Designs

23 Sep 2017
Narrowing Down the Designs By Evan and Austin

Task: Redesign our grabber systems

In an attempt to get a working lift system before the coaches meeting we will be presenting at, a linear slide has been attached to the robot, along with a pair of grabbing arms. They work surprisingly well and aren’t as complicated as my idea. Plus the importance of speed has really taken hold on me this year. We need to be as fast as possible but my contraption is slow compared to the grabber arm. I think i'll be scrapping my idea for this grabber arm bandwagon everyone seems to be hopping on. While the grabber arm allows for quick pick ups and easy placement, my idea was only bulky and unnecessary because of our use of mecanum wheels which eliminate any need for a system to go side to side. Since the grabber was rudimentary, I’ll be making improvements and new iterations. We toyed with some materials earlier on in the season, and I’ll probably be implementing that into it.

Slide Designs

24 Sep 2017
Slide Designs By Austin

Task: Figure out slide mechanism

After determining that the treaded channel was much to buggy to perfect with the time we had, we shifted attention to other scoring systems like grabbers, however before finding the right grabber we decided we needed to get the track for it completed first. We’ve had experience in the past with all sorts of rails from tetrix kits that convert their standard channels into lifts, to the newer REV sliding rail kits which we also toyed around with in initial prototyping shenanigans.

One of our key concerns was also wear and tear, we knew that long periods of use over multiple competitions would deteriorate the plastic components of either rail sets, and other rails that used full metal parts would simply be bulky and rough to fit in snugly with our robot. After a bit more research we settled on standard steel drawer slides from home depot, mainly because they were streamline and all around sturdy. The slides also provided us with easy mounting points for our future claw and attachments.

We understood that whatever option we picked for slides would have to be easily repairable or replaceable during competition, should something go wrong. Since the drawer slide were easy to come by and needed little modification we could easily make duplicates to act as stand by and demonstration parts during competition.

These positives came to form more than enough of a reason to continue prototyping our grabber that would eventually be attached once completed to the lift, which was now mounted to the robot and used a system of spools and pullies to extended above the minimum height for scoring in the top row.

Building Competition 2017

25 Sep 2017
Building Competition 2017 By Evan and Austin

Task: Find the best robot design

The games have begun and it’s time to build. So that’s what Austin and I did. A war had been declared. Legions of the indentured collided on the battlefield. Millions were slaughtered during this new age armageddon. Austin had his army. I had mine. Two different ideas to do the same task: lift glyphs into their correct positions. A simple job but one that caused a rift in Iron Reign, an incurable rift between the forces of light and darkness. But then I decided to stop because his design had more speed than mine and speed is more necessary this year. My idea had been a lift that could move the glyphs back and forth but I realized that it would be a little too slow for the competition. My solution would have had a side to side conveyor belt that moved glyphs back and forth to arrange them in the correct order, and then push them into the slots. This movement would have been separate from the four mecanum wheels that we are using in the chasis. His idea was simpler than mine, a conveyor belt that ran through the middle of the robot to bring the glyphs to the keybox, where they could be slotted in with the side to side movement provided by the mecanum wheels. So, like an outnumbered Supreme Court judge, I decided to join the winner so I could have a say in the early design. Once he got a prototype ofhis contraption working, it was able to pick up blocks effectively but it still needs improvement. It has issues with blocks at an angle, and it has trouble slotting the blocks into the keybox, but it's a nice step toward a working block system. We are currently planning to use the mecanum wheel base we used last year but this could change anytime. We left practice with a direction and that's better than nothing.

Meeting Log

30 Sep 2017
Meeting Log September 30, 2017 By Ethan, Evan, Tycho, Austin, Kenna, Karina, Austin, and Abhi

Meeting Log September 30, 2017

Today was based around prepping for our meeting with DISD adminmistrators, getting our robots in working order, and organizing parts for the season.

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • Fix stats page
  • Strategy

Software

  • Program lift
  • Program grabber

Build / Modelling

  • Fix lift string system
  • Add lift supports

Service / Outreach

  • DISD prep

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
EthanFix stats page2:002
EthanDISD Prep4:002
EvanLift supports2:004
AustinLift string2:004
TychoProgram lift2:002
TychoProgram grabber4:002
KennaLift supports2:004
KarinaStrategy2:004
AbhiStrategy2:004

Testing Materials

30 Sep 2017
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 our intake. Our drivers have to align the robot with the block so precisely to be able to stack it that it eats a majority of our game time. However, there are some advantages, such as light weight and adjustability, to this gripper that we would like to carry over into the second version.

    We tested out a few different materials:
  • Silicone Baking Mats - The mats were a very neutral option because they didn't have any huge advantages or disadvantages (other than not adhering well). These could have been used, however, there were other better options.
  • Shelf Liner - It was far too slippery. Also, when thinking about actually making the grippers, there was no good way to put it on the grippers. Using this materials would have been too much work with little gain.
  • Baking Pan Lining (picked) - It was made out of durable rubber but was still very malleable which is a big advantage. We need the grippers to compress and 'grip' the block without causing any damage.
  • Rubber Bands on Wheels - This material was closest to our original version and, unexpectedly, carried over one of the problems. It still requires very specific orientations to pick up blocks, which would defeat the purpose of this entire task.

Designing the Grabber Further

30 Sep 2017
Designing the Grabber Further By Evan

Task: Design the grabber design and make future plans

The grabber has been evolving. A column made of a turkey baster and a wooden dowel attached to servo has come into fruition. The first drawings and designs are coming along, and some 3D printed parts have been thought up to allow the square dowel to become a hexagon. An adapter of sorts. The grabber and lift have been outfitted with a back board to stop blocks from getting caught underneath the backing bar. The back board is just some 1/16th inch wood cut to fit. The new turkey baster columns are in the first stages, so more info on them will come as more is discovered and progress has been made. The sketches will explain these designs better.

Designing the Grabber

01 Oct 2017
Designing the Grabber By 5

Task: Work on the grabbers more

With our single degree of freedom lift fastened to the robot we focused on the appendage that would grip to within an inch of its life any glyph we fed it. We initially toyed with simple tetrix channels to form a make shift rail that would hold axels for pivoting points, however we found tetrix to be a bit too cumbersome and decided to use rev rail instead. Using two tetrix U-brackets we built a makeshift grabber that used rubber bands and a servo to secure blocks without letting them slip through its grasp. To add extra grip to the long L-beams that formed the pincers of the claw, we added even more rubber bands, and moved on to testing.

Initial tests were very positive, the high strength servo coupled with a few rubber bands maintained enough of a grip on one or two blocks with ease, and because the entire system was mounted to a rev rail we could easily slide and size the pincers to the right distance. Feeling confident in our work we attached the grabber to the lift and attempted drive practice, which ended relatively quickly due to a surprising number of jams between the lift and glyphs.

The key issue we now faced was that as the lift returned to its home state blocks were getting stuck beneath the retracting claw causing jams. To fix this relatively simple problem we added a back plate to the claw that kept blocks from slipping to far into the robot, this was easily fashioned out of a bit of thin wood board we had lying around from the decks of other robots. The overall performance of our glyph wrangling device was astounding, so long as whoever was operating the robot was a well-trained driver.

Oh No! Dying glyphs

02 Oct 2017
Oh No! Dying glyphs By Abhi

Problem:

We were tearing up our glyphs like this because our wheels had no guard for their screws:

Reflections

Since we noticed this very early in the season, we have a lot of time to fix it. That being said, we hope to make a model soon to resolve the issue.

V2 Hexifier and Parts

07 Oct 2017
V2 Hexifier and Parts By Tycho and Abhi

Task: Creating the Parts for V2

Today we continued our work on the second grippers. We need the baking pan liner to adhere to the large square dowel we chose to be the base for our grippers. In order to do this, we had to design and print a hexifier, as seen below, which makes the dowel's square shape into a hexagon. We also designed and printed square pieces to go on the top and bottom of the gripper to keep it in place.

Reflections

The new grippers are probably going to be much heavier than our previous ones. Not only because of the difference in material, but in sheer size. We may not be able to retain the lightness in V2 that we had hoped to.
We used PTC Creo for all of these parts. Abhi has some video tutorials on using Creo that can be found here and here. Soon we will start assembling our V2 grippers.

Meeting Log

07 Oct 2017
Meeting Log October 07, 2017 By Ethan, Evan, Austin, Tycho, and Charlotte

Meeting Log October 07, 2017

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • DISD post
  • Fix old post formatting
  • Stockard MS

Software

  • Begin autonomous

Build / Modelling

  • Fix robot - was dropped
  • REV hub relign 2
  • Realign square base

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
EthanDISD post2:002
EthanFix formatting4:002
EvanFix robot2:002
EvanRealign4:002
AustinFix robot2:002
AustinREV realign4:002
TychoAutonomous2:004
CharlotteStockard post2:002
CharlotteJournal review4:002

Chassis Upgrades

08 Oct 2017
Chassis Upgrades By Austin

Task: Upgrade our chassis

Because our robot at this point has merely become a collage of prototypes that we compete with, there are often subtle improvements that need to be made. Starting with the wheelbase, Abhi has written a blog about the shields we printed to protect the glyphs from the gnashing bolts of our mechanum wheels, and we also tensioned all our set screws and motor mounts to make sure that our base was preforming in terms of the speed and strength we needed. As we add components to the robot things often are shifted around as well, after tuning up the drive train we focused on realigning our REV expansion hubs and their wiring so that nothing would be in the way of critical lift or drivetrain components.

Because our robot at this point has merely become a collage of prototypes that we compete with, there are often subtle improvements that need to be made. Starting with the wheelbase, Abhi has written a blog about the shields we printed to protect the glyphs from the gnashing bolts of our mechanum wheels, and we also tensioned all our set screws and motor mounts to make sure that our base was preforming in terms of the speed and strength we needed. As we add components to the robot things often are shifted around as well, after tuning up the drive train we focused on realigning our REV expansion hubs and their wiring so that nothing would be in the way of critical lift or drivetrain components.

Any jettisoning bolts that have been catching components while moving, and any sharp edges have all been ground down to ensure that any motion is smooth and that there are minimal catching hazards during operation. Because of the earlier mentioned prototype state our robot was in, many of the key components laid outside of the 18 inch cubic limits and so these components we brought in and neatly fastened to the internals of the robot bearing in mind ease of access for future updates to components. This entire push for cleanliness was the result of upcoming scrimmages and practice matches that we would be participating in.

Meeting Log

14 Oct 2017
Meeting Log October 14, 2017 By Ethan, Kenna, Abhi, Austin, Janavi, Evan, Charlotte, and Tycho

Meeting Log October 14, 2017

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • Learn to blog
  • UTA post
  • Teach how to blog
  • Strategy post

Software

  • IMU testing
  • Autonomous

Build / Modelling

  • Install wheel mounts
  • Test string for lift

Service / Outreach

  • UTA volunteering

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
EthanTeach how to blog2:002
EthanFix formatting of posts4:002
KennaLearn to post2:002
KennaUTA post4:002
AbhiStrategy post2:004
AustinWheel mounts2:004
EvanString test2:004
CharlotteLearn to blog2:004
TychoIMU2:002
TychoAutonomous4:002

Grabber Code

16 Oct 2017
Grabber Code By Tycho

Task: Create a seperate class for the grabbers on the robot

Today, I created a new PickAndPlace class to isolate the code that controls the current gripper and lift system. I also added new methods to send the lift to max, min and stacking heights with manual override. It now prevents over extension or over unwinding by setting max and minumum heights. Pushes lift all theway down by hand before starting.

+package org.firstinspires.ftc.teamcode;
+
+import com.qualcomm.robotcore.hardware.DcMotor;
+import com.qualcomm.robotcore.hardware.Servo;
+
+/**
+ * Created by tycho on 10/15/2017.
+ */
+
+public class PickAndPlace {
+
+ DcMotor motorLift = null;
+ Servo servoGrip = null;
+
+ private int liftMax = 4000;
+ private int liftStack = 2500; //stacking height
+ private int liftMin = 50;
+ private int liftPlanck = 450; //smallest distance to increment lift by when using runToPosition
+
+ boolean gripOpen = false;
+ int gripOpenPos = 900;
+ int gripClosedPos = 2110;
+
+ public PickAndPlace(DcMotor motorLift, Servo servoGrip){
+ this.motorLift = motorLift;
+ this.servoGrip = servoGrip;
+ }
+
+ public void ToggleGrip (){
+ if (gripOpen) {
+ gripOpen = false;
+ servoGrip.setPosition(ServoNormalize(gripClosedPos));
+ }
+ else {
+ gripOpen = true;
+ servoGrip.setPosition(ServoNormalize(gripOpenPos));
+ }
+ }
+
+
+ public void stopLift(){
+ motorLift.setPower(0);
+ }
+
+ public void raiseLift(){
+ if(motorLift.getCurrentPosition() < liftMax) motorLift.setPower(.5);
+ else motorLift.setPower(0);
+ }
+ public void lowerLift(){
+ if(motorLift.getCurrentPosition() > liftMin) motorLift.setPower(-.5);
+ else motorLift.setPower(0);
+ }
+
+ public void raiseLift2(){
+ if (motorLift.getCurrentPosition() < liftMax && motorLift.getTargetPosition() < liftMax) {
+ motorLift.setTargetPosition((int) Math.min(motorLift.getCurrentPosition() + liftPlanck, liftMax));
+ motorLift.setMode(DcMotor.RunMode.RUN_TO_POSITION);
+ motorLift.setPower(1);
+ }
+ }
+ public void lowerLift2() {
+ if (motorLift.getCurrentPosition() > liftMin && motorLift.getTargetPosition() > liftMin) {
+ motorLift.setTargetPosition((int) Math.max(motorLift.getCurrentPosition() - liftPlanck, liftMin));
+ motorLift.setMode(DcMotor.RunMode.RUN_TO_POSITION);
+ motorLift.setPower(.8);
+ }
+ }
+ public void goLiftMax() {
+
+ motorLift.setTargetPosition(liftMax);
+ motorLift.setMode(DcMotor.RunMode.RUN_TO_POSITION);
+ motorLift.setPower(1);
+
+ }
+
+ public void goLiftMin() {
+
+ motorLift.setTargetPosition(liftMin);
+ motorLift.setMode(DcMotor.RunMode.RUN_TO_POSITION);
+ motorLift.setPower(1);
+
+ }
+
+ public void goLiftStack() {
+
+ motorLift.setTargetPosition(liftStack);
+ motorLift.setMode(DcMotor.RunMode.RUN_TO_POSITION);
+ motorLift.setPower(1);
+
+ }
+
+ public int getMotorLiftPosition(){
+ return motorLift.getCurrentPosition();
+ }
+
+ public static double ServoNormalize(int pulse){
+ double normalized = (double)pulse;
+ return (normalized - 750.0) / 1500.0; //convert mr servo controller pulse width to double on _0 - 1 scale
+ }
+
+}

Fixing the glyph breaking

21 Oct 2017
Fixing the glyph breaking By Abhi

Problem: Stop Destroying Glyphs

Since damaging field elements is a huge no-no, we needed to fix this, we decided to create a 3-D part to protect the glyphs from our wheels

Model:

During my first attempt, I had just self taught Creo hours prior to construction. As a result, I was not very profecient nor efficient in my design. Nevertheless, I recognized that there were some basic shapes I could use for construction like a semicircle for the bottom half and two rectangles on the top part. I decided to use measurements that were estimated from a singular mechanum wheel. This culminated in my design below.

Result:

Meeting Log

21 Oct 2017
Meeting Log October 21, 2017 By Ethan, Tycho, Evan, Abhi, Charlotte, and Karina

Meeting Log October 21, 2017

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • Travis blog post
  • Work on presentation

Software

  • Work on openCV integration
  • Test out RoboRealm

Build / Modelling

  • Robot drive practice
  • Learn PTC
  • Jewel thief mockup

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
EthanWork on presentation2:004
TychoTravis blog post2:001
TychoOpenCV3:002
TychoRobotRealm4:002
CharlottePTC2:004
AbhiPTC2:004
KarinaDrive practice2:004
EvanJewel thief mockup2:004

Machine Vision Goals – Part 1

22 Oct 2017
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 it gives us a chance to regularly get the glyph crypto bonus. From looking at the code, it seems to be a single line different from the Vuforia tracking code we’ve already got. It’s probably a good idea to signal the completed decode by flashing our lights or something like that. That will make it more obvious to judges and competitors.

Jewel Identification – most teams seem to be using the REV color sensor on the arm their jewel displacement arm. We’ll probably start out doing that too, but I’d also like to use machine vision to identify the correct jewel. Just because we can. Just looking at the arrangement, we should be able to get both the jewels and the Vuforia target in the same frame at the beginning of autonomous.

Alignment – it is not legal to extend a part of the robot outside of the 18” dimensions during match setup. So we can’t put the jewel arm out to make sure it is between the jewels. But there is nothing preventing us from using the camera to assist with alignment. We can even draw on the screen where the jewels should appear, like inside the orange box below. This will also help with Jewel ID – we won’t have to hunt for the relevant pixels – we can just compare the average hue of the two regions around the wiffle balls.

Autonomous Deposition – this is the most ambitious use for machine vision. The dividers on the crypto boxes should make pretty clear color blob regions. If we can find the center points between these regions, we should be able to code and automatically centering glyph depositing behavior.

Autonomous glyph collection – ok this is actually harder. Teams seem to spend most of their time retrieving glyphs. Most of that time seems to be spent getting the robot and the glyphs square with each other. Our drivers have a lot of trouble with this even though we have a very maneuverable mecanum drive. What if we could create a behavior that would automatically align the robot to a target glyph on approach? With our PID routines we should be able to do this pretty efficiently. The trouble is we need to figure out the glyph orientation by analyzing frames on approach. And it probably means shape analysis – something we’ve never done before. If we get to this, it won’t be until pretty late in the season. Maybe we’ll come up with a better mechanical approach to aligning glyphs with our bot and this won’t be needed.

Tools for Experimenting

Machine vision folks tend to think about image analysis as a pipeline that strings together different image processing algorithms in order to understand something about the source image or video feed. These algorithms are often things like convolution filters that isolate different parts of the image. You have to decide which stages to put into a pipeline depending on what that pipeline is meant to detect or decide. To make it easier to experiment, it’s good to use tools that let you create these pipelines and play around with them before you try to hard-code it into your robot.

I've been using a tool called ImagePlay. http://imageplay.io/ It's open source and based on OpenCV. I used it to create a pipeline that has some potential to help navigation in this year's challenge. Since ImagePlay is open source, once you have a pipeline, you can figure out the calls to it makes to opencv to construct the stages. It's based on the C++ implementation of OpenCV so we’ll have to translate that to java for Android. It has a very nice pipeline editor that supports branching. The downside is that this tool is buggy and doesn't have anywhere near the number of filters and algorithms that RoboRealm supports.

RoboRealm is what we wanted to use. We’ve been pretty closely connected with the Dallas Personal Robotics Group (DPRG) for years and Carl Ott is a member who has taught a couple of sessions on using RoboRealm to solve the club’s expert line following course. Based on his recommendation we contacted the RoboRealm folks and they gave use a 5 user commercial license. I think that’s valued at $2,500. They seemed happy to support FTC teams.

RoboRealm is much easier to experiment with and they have great documentation so now have an improved pipeline. It's going to take more work to figure out how to implement that pipeline in OpenCV because it’s not always clear what a particular stage in RoboRealm does at a low level. But this improved pipeline isn’t all that different from the ImagePlay version.

Candidate Pipeline

So here is a picture of a red cryptobox sitting against a wall with a bunch of junk in the background. This image ended up upside down, but that doesn’t matter for just experimenting. I wanted a challenging image, because I want to know early if we need to have a clean background for the cryptoboxes. If so, we might need to ask the FTA if we can put an opaque background behind the cryptoboxes:

Stage 1 – Color Filter – this selects only the reddest pixels

Stage 2 – GreyScale – Don’t need the color information anymore, this reduces the data size

Stage 3 – Flood Fill – This simplifies a region by flooding it with the average color of nearby pixels. This is the same thing when you use the posterize effect in photoshop. This also tends to remove some of the background noise.

Stage 4 – Auto Threshold – Turns the image into a B/W image with no grey values based on a thresholding algorithm that only the RoboRealm folks know.

Stage 5 – Blob Size – A blob is a set of connected pixels with a similar value. Here we are limiting the output to the 4 largest blobs, because normally there are 4 dividers visible. In this case there is an error. The small blob on the far right is classified as a divider even though it is just some other red thing in the background, because the leftmost column was mostly cut out of the frame and wasn’t lit very well. It ended up being erased by this pipeline.

Stages 6 & 7 – Moment Statistics – Moments are calculations that can help to classify parts of images. We’ve used Hu Moments since our first work with machine vision on our robot named Argos. They can calculate the center of a blob (center of gravity), its eccentricity, and its area. Here the center of gravity is the little red square at the center of each blob. Now we can calculate the midpoint between each blob to find the center of a column and use that as a navigation target if we can do all this in real-time. We may have to reduce image resolution to speed things up.

Wheel Protector Correction

24 Oct 2017
Wheel Protector Correction By Abhi

Problem: Wheel Guard Innacuracy

Refering back to the design of the wheel guard, we decided it was time to actually mount it on the robot. At first, it seemed like the part was perfect for the robot since it fit just snug with the screws on the wheel. However, upon mounting, we discovered the following:

Turns out that the part is acutely shorter than the real height of wheel relative to the horizontal axis superimposed upon the vertical plane. As a result, a second and better trial for modeling needed to be conducted. For this run, I chose to measure the dimensions directly from the robot rather than a spare wheel.

Correction:

As seen above, the corrected version of the part looks and works much better. Though there is a slight margin of error in the success of the part due to the dynamic nature of the density of the field tiles , the part should be reliable for the most part

Working on Autonomous

29 Oct 2017
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.

+ public void autonomous2 (){
+
+ switch(autoState){
+ case 0: //moves the robot forward .5 meters
+ if (robot.driveStrafe(false, .60, .35)) {
+
+ robot.resetMotors(true);
+ autoState++;
+ }
+ break;
+ case 1: //scan jewels and decide which one to hit
+ if (robot.driveForward(false, .25, .35)) {
+ autoTimer = futureTime(1f);
+ robot.resetMotors(true);
+ autoState++;
+ }
+
+ break;
+ case 2: //short move to knock off jewel
+
+ robot.glyphSystem.ToggleGrip();
+ autoTimer = futureTime(1f);
+
+ robot.resetMotors(true);
+ autoState++;
+ break;
+ case 3: //back off of the balance stone
+ if (robot.driveForward(true, .10, .35)) {
+ autoTimer = futureTime(3f);
+ robot.resetMotors(true);
+ autoState++;
+ }
+ break;
+ case 4: //re-orient the robot
+ autoState++;
+ break;
+ case 5: //drive to proper crypto box column based on vuforia target
+ autoState++;
+ break;
+ case 6: // turn towards crypto box
+ autoState++;
+ break;
+ case 7: //drive to crypto box
+ autoState++;
+ break;
+ case 8: //deposit glyph
+ autoState++;
+ break;
+ case 9: //back away from crypto box
+ autoState++;
+ break;
+ }
+ }
+

Meeting Log

03 Nov 2017
Meeting Log November 03, 2017 By Ethan, Evan, Tycho. Austin, Charlotte, Karina, Janavi, Kenna, and Abhi

Meeting Log November 03, 2017

Today is one of the last full meetings until our tournament, so we need to get everything ready for judging. This post also includes the objectives for the next week.

Today's Meet Objectives

Organization / Documentation / Competition Prep

  • Review Journal
  • 3 posts from each member
  • DISD Scrimmage post
  • Field build post
  • Strategy\Business plan
  • Print notebook
  • Finish presentation
  • Presention practice

Software

  • Autonomous
  • Drive practice

Build / Modelling

  • Respool string
  • Robot tuneup

Today's Work Log

Team MembersTaskStart TimeDuration
AllPlanning Meeting2:10pm.25
Ethan3 posts2:002
EthanFinish presentation4:002
EvanTuneup2:004
TychoAutonomous2:002
TychoDrive practice4:002
EvanDrive practice2:004
AustinDrive practice2:004
AustinTuneup2:004
JanaviWork on presentation2:004
KennaPrint notebook2:004

How to make a part in PTC Creo Parametric

04 Nov 2017
How to make a part in PTC Creo Parametric By Abhi

Problem: How to Make a Part in Creo Parametric

PTC Creo Parametric is one of the best software to 3-D model tools that we can print out. I will detail how to create a part in Creo for both our team and any other teams who need help creating a piece. For this demo, Creo Parametric Academic Edition was used along with a pre designed model of the part.

To begin the model, create a new part. Make sure you are making the part in the right dimensions since the 3-D printer needs special requirements. For the 3-D printer that Iron Reign has, we chose to make all of our dimensions in millimeters. You can change this configuration by going into File>Prepare>Model Properties >Units.

Once your program is set to go, go under Model and press Sketch. This will create the base diagram which we will raise to make our part. Once the sketch menu appears, you will have to choose a plane on which we will draw. For this sketch, we will draw from the top plane since we want to raise it from the bottom. To do so, press on the top plane and press sketch. If the view is still in an isometric format, you can change the view by pressing the button indicated in the video.

Once the sketch is set up, we need to draw two concentric circles with the right dimensions. To find the dimensions, I refer often to the premade part. Once I have made the system, I set up centerlines vertically to be able to draw better. Next, I cut off the top two parts of the circle since we will put rectangles on them.

Next, select a line chain to draw two sets of rectangles with the bottom edge fused with the half circle. At the end, you should have a U shaped part. Now, we can draw another centerline along where we want the screw holes. After doing so, we can use the circle tool to make two holes in the rectangles.

We now need to extrude this part to the right size. After pressing the extrude took, we can change the size on the arrow. After doing so, we need to place two high radius thin circles on either sides. These are placed as weight pads so that when the part prints, it doesn't curve on the printing bed.

At this point, we can do some optional things to make our part..well lets say prettier. We can use the round tool so the edges look nicer and the screws are easier to place inside. After doing so, we can use the render tool to color all the edges. At the end, you will have a complete part to print

End result:

I hope you learned from this tutorial and are able to apply this to any future parts you make!

Designing the Jewel Thief

07 Nov 2017
Designing the Jewel Thief By Evan

Task: Design a part to remove the jewel

The jewel thief, the mechanism for knocking off one of the jewels, was going to be one of the tougher parts of our bot to integrate, based on the chassis we began with. But, with a little engineering and some long thought, I came up with a few ways to implement it. I began with a side mount, and it was alright for the angle, but we switched our autonomous plan to begin pointing forward, presenting me with a new problem. The part I had used before would simply not work. I tried a modified version of the pusher I'd made, but it didn't fully suffice. It was impractical and would require more than a little wire extention for the servo. I finally decided that a frontwards approach should be taken from the side. Instead of a single middle forward facing prong, a two bar prong sticking from either side, meeting in the middle, and providing a platform for a potential relic placer. While not completely finished, I intend to have it done by the first qualifier, fully functional. It should allow us to knock the jewel off during autonomous effectively and efficiently, although that’s all to be seen.

Reflections

While not completely finished, I intend to have it done by the first qualifier, fully functional. It should allow us to knock the jewel off during autonomous effectively and efficiently, although that’s all to be seen. We also should make a fully functional version and test it with autonomous.

Relic Recovery Strategy Part 1

07 Nov 2017
Relic Recovery Strategy Part 1 By Austin

Task: Determine building strategy for Relic Recovery

Any well-versed team understands that, depending on the competition for the year, a robot will either be modified to compete or be built from the ground up. In any case, however, a robot often starts at its chassis, and teams have multiple companies that provide solutions to the common robot chassis’ needs and specifications. To name a few: AndyMark® has its standard kits that include all the parts and electronics needed to build a very basic frame that includes a few mounting points for the rest of the robot’s components, Tetrix has its standard kit that provides all the parts for an entire robot if used properly (however, we’ve discovered drawbacks to be mentioned later), and even REV has thrown its hat in the ring with new motor and battery types to add to the highly adjustable REV rail chassis kits. For rookie teams there is no lack of options for starting your robot chassis. However, as a team gains experience they find the flaws that come with each kit and move towards creating robots that harness equal amounts of parts from all companies. Here’s what we’ve learned about each company:

AndyMark: overall, AndyMark is a great supplier for all the standard parts you’ll need, however we wouldn’t recommend buying their overall chassis kits because they can be on the pricier side and come with few replacement parts and too many unnecessary parts. Most of our gears, wheels, pulleys, motors, and batteries come from AndyMark in batches of parts that we keep on hand to prototype with or replace failing parts. This keeps us from paying for parts we don’t need and having what we do need on hand. The overall quality of their parts is high, but they do decay quicker with use, especially when running the robot at multiple competitions without proper repair time.

Tetrix: Tetrix is highly standardized in all dimensions, making the connections between parts easy to grasp for basic builders who haven’t developed a mental 3D idea of what they’re working towards. Tetrix kits don’t include electronics. However, their brackets, channels, and joints are very useful for making connections between various components of your robot, so keep plenty on hand for quick fixes and prototyping. Our biggest concern with tetrix are their designated nuts; we find that they often are shaken completely off respective bolts, which can lead to mechanical failure and penalties. To combat the issue of robots quite literally shaking themselves apart, we recommend using nyloc nuts. They have a small amount of nylon in them that grips the threads of bolts making them almost immovable without a pair of pliers.

Rev: Iron reign loves our Rev rails. The ability to have a mounting point at any incident on a bar is amazing, and often allows us to pull off the crazy designs we create. Rev has created a system that is beyond flexible, meaning that the limits of your designs have expanded. For those who want a chassis that is easily maneuverable, Rev rail is extremely light as well. While Rev is expanding into providing parts like AndyMark, we find that they are still in development but we eagerly await upgrades.

Overall, Iron Reign wanted a robot chassis that was stable, maneuverable, and modular to our needs, so this is our compromise that we’ve applied to all aspects of our robot;

- AndyMark FRC Standard Omni-Wheels: we chose these because of their dependability and maneuverability. They provide standard motion as well as strafing for fine-tuning movements in front of cryptoboxes. While we had to print custom mounts, and modify tetrix channels for the necessary axels, the wheels pared nicely with the rest of our components once mounted.
- Rev Rail: our entire upper chassis is made from interconnected Rev Rails that serve as a smooth, easily adjustable, and light support for the massive omni wheels that rest below it. The rails provide plenty of room for future expansion, and can take quite a beating (we learned this the hard way by dropping our robot off a table).
- Tetrix Channels and Brackets: these are the middle men, the parts we change to fit those awkward angles and fittings, such as the axels for our wheels. Overall never a bad idea to have extras on hand.
- Hardware: we always use standard hardware sizes, but we make sure that the corresponding components are snug fitting and streamlined to minimize unnecessary snags and sharp edges.

While these are the typical components that make an Iron Reign base, we have seen other teams get extremely creative with raw material, although this usually requires heavy machinery such as laser cutters and lathes. Overall, we are a team that uses what companies provide and modify it to fit our needs (which has worked well for the past years of competition.) For smaller start up teams we recommend a similar approach of learning each system and its advantages over the course of multiple years, and finding what you feel works best for your needs.

Adding Code Fixes to the Robot

10 Nov 2017
Adding Code Fixes to the Robot By Tycho

Task: Add code updates

These commits add said functionality:

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

Jewel Arm


+package org.firstinspires.ftc.teamcode;
+
+import com.qualcomm.robotcore.hardware.NormalizedColorSensor;
+import com.qualcomm.robotcore.hardware.Servo;
+
+/**
+ * Created by 2938061 on 11/10/2017.
+ */
+
+public class JewelArm {
+
+ private Servo servoJewel;
+ private NormalizedColorSensor colorJewel;
+ private int jewelUpPos;
+ private int jewelDownPos;
+
+ public JewelArm(Servo servoJewel, NormalizedColorSensor colorJewel, int jewelUpPos, int jewelDownPos){
+ this.servoJewel = servoJewel;
+ this.colorJewel = colorJewel;
+ this.jewelUpPos = jewelUpPos;
+ this.jewelDownPos = jewelDownPos;
+ }
+
+ public void liftArm(){
+ servoJewel.setPosition(ServoNormalize(jewelUpPos));
+ }
+ public void lowerArm(){
+ servoJewel.setPosition(ServoNormalize(jewelDownPos));
+ }
+
+ public static double ServoNormalize(int pulse){
+ double normalized = (double)pulse;
+ return (normalized - 750.0) / 1500.0; //convert mr servo controller pulse width to double on _0 - 1 scale
+ }
+
+}

Autonomous

public void autonomous(){
switch(autoState){
case 0: //scan vuforia target and deploy jewel arm
robot.jewel.lowerArm();
autoTimer = futureTime(1.5f);
if(autoTimer < System.nanoTime()) {
relicCase = getRelicCodex();
jewelMatches = robot.doesJewelMatch(isBlue);
autoState++;
}
break;
case 1: //small turn to knock off jewel
if ((isBlue && jewelMatches)||(!isBlue && !jewelMatches)){
if(robot.RotateIMU(10, .5)){
robot.resetMotors(true);
}
}
else{
if(robot.RotateIMU(350, .5)){
robot.resetMotors(true);
}
}
break;
case 2: //lift jewel arm
robot.jewel.liftArm();
autoTimer = futureTime(1.5f);
if(autoTimer < System.nanoTime()) {
jewelMatches = robot.doesJewelMatch(isBlue);
autoState++;
}
case 3: //turn parallel to the wall
if(isBlue){
if(robot.RotateIMU(270, 2.0)){
robot.resetMotors(true);
autoState++;
}
}
else{
if(robot.RotateIMU(90, 2.0)){
robot.resetMotors(true);
autoState++;
}
}
autoState++;
break;
case 4: //drive off the balance stone
if(robot.driveForward(true, .3, .5)) {
robot.resetMotors(true);
autoState++;
}
break;
case 5: //re-orient robot
if(isBlue){
if(robot.RotateIMU(270, 1.0)){
robot.resetMotors(true);
autoState++;
}
}
else{
if(robot.RotateIMU(90, 1.0)){
robot.resetMotors(true);
autoState++;
}
}
break;
case 6: //drive to proper crypto box column based on vuforia target
switch (relicCase) {
case 0:
if(robot.driveForward(true, .5, .35)) {
robot.resetMotors(true);
autoState++;
}
break;
case 1:
if(robot.driveForward(true, .75, .35)) {
robot.resetMotors(true);
autoState++;
}
autoState++;
break;
case 2:
if(robot.driveForward(true, 1.0, .35)) {
robot.resetMotors(true);
autoState++;
}
autoState++;
break;
}
break;
case 7: //turn to crypto box
if(isBlue){
if(robot.RotateIMU(315, 1.5)){
robot.resetMotors(true);
autoState++;
}
}
else{
if(robot.RotateIMU(45, 1.5)){
robot.resetMotors(true);
autoState++;
}
}
break;
case 8: //deposit glyph
if(robot.driveForward(true, 1.0, .50)) {
robot.resetMotors(true);
robot.glyphSystem.ReleaseGrip();
autoState++;
}
break;
case 9: //back away from crypto box
if(robot.driveForward(false, .5, .50)){
robot.resetMotors(true);
autoState++;
}
break;
default:
robot.resetMotors(true);
autoState = 0;
active = false;
state = 0;
break;
}
}
public void autonomous2 (){

switch(autoState){
case 0: //scan vuforia target and deploy jewel arm
robot.jewel.lowerArm();
autoTimer = futureTime(1.5f);
if(autoTimer < System.nanoTime()) {
relicCase = getRelicCodex();
jewelMatches = robot.doesJewelMatch(isBlue);
autoState++;
}
break;
case 1: //small turn to knock off jewel
if ((isBlue && jewelMatches)||(!isBlue && !jewelMatches)){
if(robot.RotateIMU(10, .5)){
robot.resetMotors(true);
}
}
else{
if(robot.RotateIMU(350, .5)){
robot.resetMotors(true);
}
}
break;
case 2: //lift jewel arm
robot.jewel.liftArm();
autoTimer = futureTime(1.5f);
if(autoTimer < System.nanoTime()) {
jewelMatches = robot.doesJewelMatch(isBlue);
autoState++;
}
case 3: //turn parallel to the wall
if(isBlue){
if(robot.RotateIMU(270, 2.0)){
robot.resetMotors(true);
autoState++;
}
}
else{
if(robot.RotateIMU(90, 2.0)){
robot.resetMotors(true);
autoState++;
}
}
autoState++;
break;
case 4: //drive off the balance stone
if(robot.driveForward(true, .3, .5)) {
robot.resetMotors(true);
autoState++;
}
break;
case 5: //re-orient robot
if(isBlue){
if(robot.RotateIMU(270, 1.0)){
robot.resetMotors(true);
autoState++;
}
}
else{
if(robot.RotateIMU(90, 1.0)){
robot.resetMotors(true);
autoState++;
}
}
break;
case 6: //drive to proper crypto box column based on vuforia target
switch (relicCase) {
case 0:
if(robot.driveStrafe(true, .00, .35)) {
robot.resetMotors(true);
autoState++;
}
break;
case 1:
if(robot.driveStrafe(true, .25, .35)) {
robot.resetMotors(true);
autoState++;
}
autoState++;
break;
case 2:
if(robot.driveStrafe(true, .50, .35)) {
robot.resetMotors(true);
autoState++;
}
autoState++;
break;
}
break;
case 7: //turn to crypto box
if(isBlue){
if(robot.RotateIMU(215, 1.5)){
robot.resetMotors(true);
autoState++;
}
}
else{
if(robot.RotateIMU(135, 1.5)){
robot.resetMotors(true);
autoState++;
}
}
break;
case 8: //deposit glyph
if(robot.driveForward(true, 1.0, .50)) {
robot.resetMotors(true);
robot.glyphSystem.ReleaseGrip();
autoState++;
}
break;
case 9: //back away from crypto box
if(robot.driveForward(false, .5, .50)){
robot.resetMotors(true);
autoState++;
}
break;
default:
robot.resetMotors(true);
autoState = 0;
active = false;
state = 0;
break;
}
}

Greenhill FTC Qualifier

11 Nov 2017
Greenhill FTC Qualifier By Ethan, Evan, Tycho, Charlotte, Austin, Abhi, Tycho, Karina, and Kenna

Task: Compete at our first FTC qualifier

So, we were absolute failures. There's no way to get around that. We got 14th place out of 14, and our presentation flopped. But, its not the end of the world, even if it may feel like it. We have another qualifier in Oklahome in one week, and we need to analyze what we did wrong so that we can improve for the next round.

We had many failures in the robot game. Our first, main failure was lack of practice. We only really dedicated ourselves to driving practice two weeks before, and we had trouble aligning the blocks throughout the day. In prior years, we had started drive practice from over a month out, so this was a major failure on our part. A second failure that wasn't our fault was that we had connection issues between the phones, and weren't able to drive in two rounds. But, because of our collective failures, we managed not to win a single game. However, we ended up with the second heighest rank points in the whole tournament (380).

Our presentation was a failure too. We hadn't practiced our presentation enough, and it seemed a bit janky at points. In addition, our engineering journal was a bit rushed, as we'd printed the night before and had some issues printing. We also didn't turn the control award in. However, one highlight of the judging is that we were able to answer questions quickly and effectively, and the judges seemed to like that. We did end up winning the Connect Award.

Reflections

This tournament was one of Iron Reign's worst. However, we must learn from that so we don't repeat our mistakes. The silver lining of this tournament is that we can't really preform any worse :).

Driving struggles

13 Nov 2017
Driving struggles By Abhi

Task: Drive the Robot

Today I tried to drive the robot on the practice field for the first time since the qualifier last Saturday. However, I couldn't get in very much quality drive practice because the robot kept breaking down. I 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 plank of the grabber arm mounted on the vertical axis, the structure only had one bar for support for the lift. As a result, since the construction of our robot, the rev rail of the mount had been worn out constantly up to the point where it broke. Also because of the singular rod mounting, the lift system rotated on the vertical planar axis creating a need for drivers, such as myself, to rotate into the cryptobox every time we needed to mount. This was not a good way for the robot to function and had frustrated me.

Another issue I had was that the lift system string was caught often in all the wiring of the robot. Due to the friction created between this string and all the wiring, including the jewel system, it breaks the string and also creates a safety issue. As a result, we need to fix either the wiring of the robot or the lift system altogether.

Reflections

We hope to make improvements over this week before the Oklahoma qualifier. Hopefully, we will have a more proficient robot making it easier on our drivers.

Gripper Part 2

13 Nov 2017
Gripper Part 2 By Evan

Update:

The task today was simple. I replicated Tycho's work with the first gripper so we can begin connecting them. The biggest problem was finding all the parts to make it. I am hoping we can connect and mount them in the next couple days so it will be ready for the qualifier in Oklahoma.

Code Fixes and Readability

13 Nov 2017
Code Fixes and Readability By Tycho

Task: Make the code more readable

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.

Control Award

15 Nov 2017
Control Award By Janavi

Task:

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 my 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 in Zone, place glyph in cryptobox (25 pts)

Autonomous B has the ability to be delayed for a certain amount of time, allowing for better coordination with alliance mates. If our partner team is more reliable, we can give them freedom to move, but still add points to our team score.

Sensors Used

  1. Phone Camera - Allows the robot to determine where to place glyphs using Vuforia, taking advantage of the wide range of data provided from the pattern detection, as well as using Open Computer Vision (OpenCV) to analyze the pattern of the image.
  2. Color Sensor - Robot selects correct jewel using the passive mode of the sensor. This feedback allows us determine whether the robot needs to move forwards or backwards so that it knocks off the opposing teams jewel
  3. Inertial Measurement Unit (IMU) - 3 Gyroscopes and Accelerometers return the robot’s heading for station keeping and straight-line driving in autonomous, while letting us orient ourselves to specific headings for proper navigation, crypt placing, and balancing
  4. Motor Encoders - Using returned motor odometry, we track how many rotations the wheels have made and convert that into meters travelled. We use this in combination with feedback from the IMU to calculate our location on the field relative to where we started.

Key Algorithms:

  1. Integrate motor odometry, the IMU gyroscope, and accelerometer with using trigonometry so the robot knows its location at all times
  2. Use Proportional/Integral/Derivative (PID) combined with IMU readouts to maintain heading. The robot corrects any differences between actual and desired heading at a power level appropriate for the difference and amount of error built up. This allows us to navigate the field accurately during autonomous.
  3. We use Vuforia to track and maintain distance from the patterns on the wall based on the robot controller phone's camera. It combines 2 machine vision libraries, trig and PID motion control.
  4. All code is non-blocking to allow multiple operations to happen at the same time. We extensively use state machines to prevent conflicts over priorities in low-level behaviors

Driver Controlled Enhancements:

  1. If the lift has been raised, movement by the jewel arm is blocked to avoid a collision
  2. The robot has a slow mode, which allows our drivers to accurately maneuver and pick up glyphs easily and accurately.
  3. The robot also has a turbo mode. This speed is activated when the bumper is pressed, allowing the driver to quickly maneuver the field.
Autonomous Field

Intake Grippers Pt2

15 Nov 2017
Intake Grippers Pt2 By Evan

Task: Attach the new intake grippers

The basters are here and in full swing. I spent a late night putting together the two intake columns. They were attached to a backing by Austin and Kenna while I was away, allowing me to finish it by attaching the final servo and tieing it to the two columns. Since the new intake needed new code, Tycho whipped up some code to allow us to have control. Upon doing this he realized we needed two controllers, one for movement and controlling the lift, and a second purely to work the two columns as they spun. This allowed the operator to operate the whole robot just a little easier. The new columns are set on a majority REV base, allowing for more choices in design that normal tetrix doesn’t provide. The new grabber has already been placed on the robot and seems to be working smoothly, only time will tell if it is a long term solution.

Oklahoma Qualifier Recap

18 Nov 2017
Oklahoma Qualifier Recap By Ethan, Evan, Austin, Janavi, Charlotte, Kenna, Tycho, Karina, and Abhi
Task: Compete at the Oklahoma Qualifier

Once done, our postmortem post will be here.

On Nov. 17, we went to the Oklahoma Mustang HS qualifier. Our strategy for this tournament was to attempt to qualify in multiple regions so that we have more chances to get to the South Super Regionals. For this tournament, the DISD STEM Dept. funded the tournament fees for us to attend, as well as housing for our team. We drove down there on our RV, and also fixed it up so that we could convert it into tournament mode.

For out-of-area tournaments, we have to prepare ahead of time so that we can get everything we need, since we can't really go back to get parts we forgot. So, this time, we created a packing list in order to ensure that we have everything on the RV before we leave. The complete list is below.

Tent / Pits

  • Shield
  • Main robot Cart
  • Small carts (x2)
  • Banner stand
  • Main banners (x3)
  • Aquila
  • Inspire
  • Inspire mount
  • Monitor
  • Extension cord(s)
  • Power Strip(s)

Field Elements

  • Cryptobox
  • Foam blocks
  • Jewels
  • Jewel base
  • Vuforia pattern on stick

Tools

  • Staticide
  • Shamwow
  • Threadlock
  • Red (x3), Blue (x3), Green (x3) hex keys
  • Flat heads: Large (x2), Small (x2)
  • Phillips heads: Large (x2), Small (x2)
  • Modular screwdrivers + bits (Cyan wrenches)
  • Rubber bands / Hair Ties?
  • String for pulley system
  • Container store chest of drawers
  • Chain Box
  • Tape Box
  • Glue + putty Box
  • Large pliers
  • Needlenose pliers
  • Regular Pliers
  • Power pole Box + stuff with that
  • Xacto knifes
  • Regular knifes
  • Zip ties
  • Axles
  • Drills
  • Yellow Drill (x2)
  • Drill batteries + chargers
  • Electric screwdrivers + bits
  • Plugin drill
  • Wire strippers
  • Measuring tape
  • Dremel
  • Reciprocating Dremel
  • Circular Dremel
  • Sawblade
  • Evil sandpaper
  • Battery
  • Charger
  • Hack saw
  • Hammer
  • Mallet
  • Bolt cutters
  • Lighter
  • Core power distribution Box

Parts

  • Standard nuts + bolts
  • Extrusion nuts + hex bolts
  • Prototyping wire
  • Tetrix pieces
  • U pieces
  • Plates
  • Phone cases - ZTE + SG5
  • Extrusions (Cap lift size)
  • Extrusion brackets

Electronics

  • Phones
  • All cables that we can get our hands on
  • Phone cables(new and old)
  • Coding cables        
  • OTG cables
  • Printer
  • Computers
  • Battery Box - phone
  • Joysticks
  • 9-volt batteries
  • All wrenches
  • Spare Core Power Distribution Module Box
  • M-M cable
  • M-F cable

Organization (Boxes)

  • Judging Box
  • Damaged foam block
  • Example of abs 3-D printing
  • Drawer Slide                      
  • All grabber prototypes
  • Turkey baster ones
  • Conveyer belt one
  • Current one on robot
  • Tape Box
  • Foam tape
  • Gaff tape
  • Duct tape
  • Duct tape
  • Double sided
  • More + ........
  • Glue + Putty Box
  • Battery Box
  • Batteries
  • Phone cables
  • Phone + Charging Box
  • Joystick Box
  • Powerpole Box
  • Tri-Crimp
  • Powerpoles
  • Wire stripper
  • Wire clipper
  • Needle nose
  • Container store chest of drawers
  • Chain Box
  • Spare Core Power Distribution Module Box

Before leaving, we had already encountered problems. Our RV's generator refused to turn on, which meant that we couldn't get AC, chargers, or any electrical components on board to work. So, we had to do a last-minute oil change. As well, we had trouble finding several important tool parts, such as our box of drill bits and other things. Running about an hour late, we finally left for Oklahoma. The drive took the usual 4 hours, stopping to get Schlotzky's™, and we arrived at midnight. After we were all assigned to our rooms and all, we did another runthrough of our presentation, then went to bed

We woke up by 7am the next day, and slogged our way out of bed to the Mariott™ Contentental™ Breakast™. Over breakfast, we discussed our strategies and rules for the tournaments. Some of the major points are these:

  • Unless your work requires it, stay off the RV and in the pit
  • If possible, try to talk to as many teams as possible, hand out flyers
  • When you see judges roaming the tournament, try to flag them down to talk
  • Try to get as many people as possible to see the RV
  • Do scouting ASAP

Flyer

Inspection


We didn't manage our time well for inspection. We hadn't really prepared our robot back in Dallas, nor on the way, so we had to attach the side panels and the buttons right as we arrived. As well, we had to make sure the bot fit within the sizing cube. Overall, our preparation for this section of the tournament was 4/10.

Judging/Presentation


This was our largest improvement from last tournament. This was probably the best presentation we've put on yet. As well, our engineering journal was indexed a little bit better than last time. The judges also seemed receptive to our presentation and asked in-depth questions on our robot, which was very enjoyable and signalled that we would be considered for future awards. As well, we managed to get every judge in the tournament on the RV, every single referee, and about half the teams total. So, we did well on that front. As well, our strategy of trying to talk to every judge worked well, as we were able to cover a variety of subjects, ranging from our design process, to business, to our outreach, to women in STEM.

Robot Game

Our time-management overall here was not great. We'd rush to the practice field to try and fix parts, then get immediately called back to the round. I think we almost got disqualified 3 or 4 times because of this. However, this was our most successfull tournament in the robot game ever, since this was our first time getting 1st alliance captain.
Game 1
Game 1 was one of the two games we lost this tournament. We lost by 20 points, and we managed to both knock the opposing team's jewel off, as well as not balance in the end-game. This match highlighted the problems with our autonomous' reliablility.
Game 2
In game 2, we still had autonomous problems, but won a close game due to our stacking.
Game 3
Game 3 was our best game, as we didn't experience any connection issues and got almost 200 points.
Game 4
In game 4, our robot shut down throughout the game, but despite that, we ekeed out a close victory.
Game 5
We won game 5 by about 30 points, as we stacked 2 columns, got a jewel, and balanced our bot.
At this point, we became an alliance captain and chose team 3732 Technical Difficulties to be our partner. We had connection problems throughout the next games that hampered our ability to score.
Semi-Finals 1
We won 80-100, despite connection issues.
Semi-Finals 2
We improved a little and got about 120 points as we fixed a servo between matches.
Final 1
We lost this game due to connection issues.
Final 2
This was our closest game, as we won by 2 points, since we were able to stack blocks *slightly* faster.
Final 3
We won this game by 20+ points as the opposing team failed to balance one bot.

Ceremony

The first award we won was the First Alliance Captain award, a first for our team, so we were overjoyed about that. Then, we also won 1st place Control Award, another first for our team. This was especially suprising, as our autonomous failed quite a bit throughout the tournament. Finally, we won 2nd place Inspire Award. While this is still a great accomplishment, we'd like to work on this a bit more and get 1st place next tournament in January.

Grabber Arms v3

25 Nov 2017
Grabber Arms v3 By Abhi and Karina

Task:Develop a More Efficient System

At the Oklahoma qualifier, we say numerous teams with similar systems to that of ours. However, because we had the mobilized gripper arms to stack with auto alignment, we were able to collect glyphs easier. However, after observing other teams in action, we realized our current gripper method had the issue of not being ready by the time we got back to the cryptobox. This is because we had to turn around everytime we needed to pick up glyphs and we also needed to pick up glyphs. This leads to longer time to fill the cryptobox, something that is not good if we plan on doing the relic later in the season. As a result, we decided to upgrade our arms to a new level: a chain based intake system.

The idea behind this system is that the grabber arms would be on a mobilized chain system, kind of like a conveyor belt. One of the reasons this is much faster than our old system is that we don't need to turn our robot around as we approach the cryptobox. We can drive forward, pick up glyphs, and as we drive backwards, we can use a toggled button on our gamepad to move the grabber arms to the back of the robot upright. As a result, by the time we get back to the cryptobox, we have the glyphs ready to place.

Another benefit of this new system is that we don't need to stack glyphs. When we drive forward to pick up glyphs, we can tilt the grabber arms forward so that even if the pre stacked glyphs look far apart, they can still be in-took with the tilted system. Also, this system can be used for intaking the relic in the future. If the chain system is placed on an elevated level on our robot, the grabber arms will be taller than the field walls. Because of this, if we pick up the relic when it is on the ground, we can place it easily.

This picture represents our current progress. We hope to complete this system soon so we can test it on the robot.

Oklahoma 2017 Post-Mortem

27 Nov 2017
Oklahoma 2017 Post-Mortem By Ethan, Evan, Tycho, Austin, Janavi, Kenna, Abhi, Charlotte, and Karina

Task: Recap what went right and wrong in Oklahoma

Even though we did very well in the Oklahoma qualifier, we still encountered several problems, that if not addressed, could sink our chances of getting to Super-Regionals. So, we had a team discussion on what to do differently in the next tournament, and what to keep constant.

Problems

Time management
Our time management was Not Good. First, we had trouble coordinating with different parts of the team, which lead to disorganization. As an example, we nearly missed judging because we had to go to inspection, then we nearly got DQ'd from several matcvhes because we kept going back to the practice field instead of queuing. So we need to clearly schedule when to go to practice field and when to not, as well as coordinate the judging, inspection, and other important events.
Refering to coach
We didn't realize that the judges were judges in the pit and one of our members refered to our coach for help, which probably hurt our chances.
Preparedness
First, on the robot side, we hadn't prepped for inspection the night before, so we had to be in a rush the day of to get ready. As well, we still hadn't made a coherent model of our robot in Creo by OK, which hurt our judging chances. And, we didn't emphasize the design process enough.
Presentation
For some reason, our robot kept glitching out *only* during the presentation, which hurt us. As well, even though our presentation was better than last time, we still had a lot of pauses that could've been remedied easily with more practice.
Robot Stability
While our robot worked pretty well during the first 5 rounds, once we hit the final rounds, our robot started shutting down and being hard to operate. We still don't know the reason, but we're currently diagnosing now.

To-do

  • Static-proof robot
  • Fix wiring
  • Organize journal for award
  • 3D Model
  • Expand engineering section
  • Build 2nd field
  • Shock mount robot

Contact Us

E-Mail: ironreignrobotics@gmail.com Website: In the address bar