Re: Durability in FRC
 

Fair enough; but they're rules to which I hold fast, because I work with teams that are quite limited re: machining capability, student experience, and resources. Mind you, never breaking the "keep it simple" rule is not, as I mentioned, equivalent to restricting yourself to trivial challenges. Rather, it's much more a guideline for execution and for specifics of the design.

Yes, you've got to jump at some point; but I try as hard as I can to always err on the side of caution. In my experience, it is absolutely no fun to be over-ambitious and have a mechanism which does not function. I've experienced it many times, as a student and as a mentor, and it's one of the things I strive to avoid.

That said, we ourselves at 4464 have a fairly ambitious drive project we've been working on during the offseason, and we'll hopefully be implementing it in the coming build season (pending success of the current design iteration), so don't take this as if I'm saying that you should never be ambitious; you should simply be very wary of ambition at the cost of reliability.

If you have a very capable team with lots of experience, you can push the boundaries. This is certainly true, and I'd have done better to qualify my advice to reflect such. That said, human psychology being what it is, it is exceedingly easy to abandon proper caution and overextend, and the results from doing so are neither fun nor satisfying. It is a constant struggle to keep your ambitions in line with what is actually feasible, and in my experience (both in FRC and elsewhere) failing to do so is probably the single most common mode of design failure. I'd much rather be overly-strict in my adherence to KISS than be not strict enough, based on my experience with the outcomes of both.

Re: Durability in FRC
 

Long post on Estimating Duty Cycles and Fatigue.

In 2007, in order to have the giant ramps (2 ramps of 18 square feet each), weight was a very precious commodity. While the students do most of the fabrication and a lot of the design, the engineers often do the calcs. The arm and tower on that robot were constructed out of very thin aluminum (0.049" wall). At that time, we estimated the weights and torques expected to see on the arm. We figured that the arm would raise and lift at most 9 tubes per match. We were going to 3 regionals and planning on the world championship. Assuming 10 qualifying matches and 9 elim matches means that the robot was expected to play about 60 matches. With the lifting/lowering at 9/match, this would be just over 500 cycles. Assuming tuning and practice matches double the cycle count, you have about 1,000 cycles. This is not a lot of cycles in terms of fatigue strength. You can see it on a sample SN curve for aluminum here: http://en.wikipedia.org/wiki/Fatigue_(material)
Note that the 1,000 cycle point is at about 2/3 the 1 cycle failure point from a stress perspective.
The 1,000 cycles would correlate again to about 120 matches or about 4 hours of assumed operation.
We built a practice robot that year, and after about 10 hours of actual run-time during practice, the robot self-destructed. This occurred right before the championship. It was scary. *
The competition robot performed well that year, short of a joint failure right before elims at Detroit (the hand portion kept striking the ground hard and broke at Detroit, but we had a spare and fixed it in short order). The competition robot did end up failing later that year. It was after Worlds, after IRI, after Kettering Kick-off, and about 4 ours into playing at the YES expo. In other words, after a couple hours of test and tuning, approximately 100 mathces (2 more hours), and 4 hours of playing at YES... or around 10 hours.
If you compare on the SN curve, the 10 hours of operation we saw with both bots was about 2,500 cycles. Had we used 0.065 wall tubing, the stresses would have been reduced to about 75% those experienced (using thin wall assumptions). As the associated point on the SN curve linked above was 175MPa, 0.065 wall would have seen 131MPa. This stress would equate to around 40,000 cycles or 160 hours of operation. Another 25% reduction would have gotten out to 1,600 hours.
So the question then becomes, how sure are you of your assumptions, and how important is weight. Well, in 2007, for the components I am talking about, we had 16 feet of 1.5" x 0.049 wall tubing. This was about 1.34 lbs lighter than going up to 065 wall. As the robot was continuously at 119.9 lbs that year... It was a reasonable bet, but JZ asked that we never push it that close again (at least intentionally).
Something to keep in mind, the same robot that would see 2,500 arm cycles would see about 1.35 Million revolutions from a CIM motor in the drivetrain (assumes 10 hours of operation at 50% speed = 10*60*2250=1.35M revs).

*The calculations were based off of annealed 6061 alloy even though 6061 T6 was the base. The reason for this was because the welding done on the 6061 would cause localized annealing at critical stress locations.

Re: Durability in FRC
 

For those wondering (like I was) "isn't this assumption too conservative-- won't the HAZ naturally age back to some fraction of its full strength in a matter of days if stored at room temperature?", apparently the answer is no (pdf link):
Learned something new today! Quota met-- now I don't have to do homework :)

Re: Durability in FRC
 

Yep... You also get a tiny bit of thinning in the material section just outside of where the weld occurs. That is often why you will see failures just past the edge of the weld on thin section material.

Re: Durability in FRC
 

WOW! I never thought about how many matches teams would have to play in. That # is absolutely astonishing!

If there's one thing I learned from Aren Hill and the rest of our mentors during my one year on Team Neutrino, it's that you want to modularize EVERYTHING on your robot. By having modules, you give yourself a leading advantage over other teams. I was talking with some FTC teams at our state fair and encouraging them to modularize everything they could. If something were to happen to say the climbing mechanism, you could detach it from your robot and it wouldn't impact your robot.

Re: Durability in FRC
 

One of the things that the district systems has taught my team is to make cycle times faster for in between matches. Bumpers and the battery have to be very quickly changed when you are being called to get in the queue while coming off the field which happens usually once a district for us if not more. Also having the lexan siding for the robot velcroed on makes diagnosing issues on the field so much easier.

Re: Durability in FRC
 

This is a great item that I don't think has been brought up before. It is a good practice for repairability as well as adaptability.
For instance, I heard 111 made swerve modules that were easy to swap for replaceability/spares. Break a wheel, replace the module (faster/more reliable). While it costs more, it keeps those items from casting the team a championship.
Modules are also easier to replace. In 2005, the FRC 33 bot had no fewer than 4 end-efectors throughout that season (which was really tricky due to fix-it windows versus current withholding allowance), This was only possible because there was an easy and documented attachment point for the end effector.
While you don't have to have a complete CAD design of your robot, it is essnetially to have good documentation of major interfaces. In industry these are often referred to as ICDs or Interface Control Documents. ICDs can either cover the inputs/outputs/attachemnts of a module (think hand ICD & arm or forearm ICD) or the documents can cover the interface (think wrist joint ICD).

Re: Durability in FRC
 

In all of this great thread on durability (or reliability), I didn't see mention of a key item - SOFTWARE. Think about it. Any comments?

Re: Durability in FRC
 

Re: Durability in FRC
 

Software is generally not going to weaken and/or break merely by being used. If it works as designed at the beginning of a competition, it's likely to still be working as designed by the end.

Programming bugs have their own agenda for expressing themselves, but they're not likely to cause issues in quite the same way worn bearings or overheated motors can.

Re: Durability in FRC
 

In the context of a thread like this, software would be in terms of error handling due to failed sensors or components. A common item would be how to mitigate a faulty encoder or having a manual override in case a potentiometer goes out on an arm controlled by state programming. Good question but probably not the right thread. How about starting a software validation thread?

Re: Durability in FRC
 

Intriguing conversation...

Software can compensate for physical durability/reliability constraints. This approach is often used in building systems that demands 99.99+ availability.

In the context of FRC robots? Here are a couple of thoughts on better handling problems with wear-and-tear.

What if we:

- use redundant sensors for critical elements (e.g. encoders for the shooter's speed this year) and reject abnormal readings automatically?

- over-sample the image data from camera so that noise can be "averaged" out for better target tracking?

- put simple checks into the amount of energy we send to the actuators (e.g. unusual range, spiky patterns) to prevent damage/reduce mechanical stress on parts?

- use a proximity sensor and accelerometer to slowdown before the robot slam into something HARD. (this must be overridable though)

In fact, I can imagine some of these design patterns can be coded into reusable libraries to make it easy to adopt.

Additional thoughts?



It takes a little bit of work, but the overall systems' durability can be improved.

Re: Durability in FRC
 

The design of a car involves hundreds of engineers over many months and tens/hundreds of millions of dollars. I get customers who ask similar questions about miniaturization. "This computer is less powerful than my phone which cost me almost nothing, why is is $12,000". Answer: Give me a couple hundred million for NRE and I can match the price point and size of your phone.

There are many great recommendations in this thread. Durability comes both from good design practices (using robust serviceable mechanisms - bearings instead of bushings etc) and good quality practices (pull test all electrical connections, tie the wiring harness down so that no terminal connection is stressed, unit test software and so on). I wish 1296 had the problem of getting a robot through 100 matches! But we do design them to be used for demos for years after each season.

Re: Durability in FRC
 

To help introduce the newbies on team 20 to design, I made a powerpoint about designing for reliability. It covers basics- nothing too in-depth, but it goes over how we built our robot last year in terms of reliability, and the mistakes we made when we were preparing for IRI.
I would love to hear suggestions, but remember, this is for the freshman, I'm not trying to give them all of ChiefDelphi's knowledge about building robots. Baby steps. :D

I'm likely to add a few more pictures of the parts of the robot I'm talking about in the future.
Attachment 15307

Re: Durability in FRC
 

I've tried to stress durability to my team over the past two years, not because of more matches in the FIRST season, but because by the time Cowtown Throwdown rolls around, our robots are barely functioning. Not only that, but then some of our robots have to be able to work longer than that, since we use them as demonstration robots.

Our oldest one still working, Trigger (Breakaway), is turning 4 in February, and other than motor replacements and small rebuilds to make it easier to maintain, it has had no problems.

On the other hand, we have Epona (Rebound Rumble), which turns 2 in February, has consistently broken down and almost everything on it has been replaced and it still doesn't always work right.

Even worse was Pegasus (Ultimate Ascent), which has been scrapped after having many problems at the end of the FRC season, the least of which was that the frame was lower than the wheels.

I'm sure you can guess which one we demonstrate the most out of these robots (I'll give you a hint, it's Trigger).

All of these reasons are going into the design of our robot for Cowtown Throwdown, Buckbeak, so that we can keep it as a demonstration robot for the future.