OCCRA
Go to Post PS: Sorry for derailing this thread even further. - Molten [more]
Home
Go Back   Chief Delphi > ChiefDelphi.com Website > Extra Discussion
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 07-17-2018, 06:55 AM
brennonbrimhall brennonbrimhall is offline
Lead Mentor
AKA: Brennon Brimhall
FRC #6844 (Provotypes)
 
Join Date: Jan 2012
Rookie Year: 2012
Location: Provo, UT
Posts: 389
brennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond repute
paper: Modeling Subsystem Reliability

Thread created automatically to discuss a document in CD-Media.

Modeling Subsystem Reliability by brennonbrimhall
Reply With Quote
  #2   Spotlight this post!  
Unread 07-17-2018, 06:57 AM
gerthworm's Avatar
gerthworm gerthworm is offline
Making the 1's and 0's
FRC #1736 (Robot Casserole)
Team Role: Mentor
 
Join Date: Jan 2015
Rookie Year: 2015
Location: Peoria, IL
Posts: 665
gerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond repute
Re: paper: Modeling Subsystem Reliability

Cool stuff, thanks for posting!

Of course, I was particualrly drawn to the conclusions of reliability percentages corresponding to time spent repairing. Understanding this relationship is obviuosly key to establishing design criteria.

Have you started to look at designs and evaluate what constitutes an "83% chance of being repaired within 2.5 minutes"? What sort of design process changes would you suggest to hit these metrics?
Reply With Quote
  #3   Spotlight this post!  
Unread 07-17-2018, 01:15 PM
GeeTwo GeeTwo is offline
In Transition
AKA: Gus Michel II
no team
Team Role: Mentor
 
Join Date: Jan 2014
Rookie Year: 2013
Location: Slidell, LA
Posts: 5,909
GeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond repute
Re: paper: Modeling Subsystem Reliability

Perhaps I'm misreading this, but it seems like your chain is still 5% likely to break every 300 seconds even while you're waiting in the pit or the queue.
__________________

If you can't find time to do it right, how are you going to find time to do it over?
If you don't pass it on, it never happened.
Robots are great, but inspiration is the reason we're here.
Friends don't let friends use master links.
[Quoting brennonbrimhall]: We design a new robot every year, but we can't forget that we also design a new team every year as folks come and go.
Reply With Quote
  #4   Spotlight this post!  
Unread 07-17-2018, 01:38 PM
gerthworm's Avatar
gerthworm gerthworm is offline
Making the 1's and 0's
FRC #1736 (Robot Casserole)
Team Role: Mentor
 
Join Date: Jan 2015
Rookie Year: 2015
Location: Peoria, IL
Posts: 665
gerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond repute
Re: paper: Modeling Subsystem Reliability

Quote:
Originally Posted by GeeTwo View Post
Perhaps I'm misreading this, but it seems like your chain is still 5% likely to break every 300 seconds even while you're waiting in the pit or the queue.
I'd presume there's some assumption of "failure rate applies to robot in motion" and the failure rate of a robot sitting in storage is comparatively negligible?

Not sure though, I didn't dig too hard into all the math implications.
Reply With Quote
  #5   Spotlight this post!  
Unread 07-18-2018, 07:06 AM
brennonbrimhall brennonbrimhall is offline
Lead Mentor
AKA: Brennon Brimhall
FRC #6844 (Provotypes)
 
Join Date: Jan 2012
Rookie Year: 2012
Location: Provo, UT
Posts: 389
brennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond repute
Re: paper: Modeling Subsystem Reliability

In the process of composing a response, I noticed that I made a mistake in the general solution for the steady state. It should have been <a/(a+b), b/(a+b)> and not <b/(a+b), a/(a+b)>. This has been corrected, along with some minor formatting errors. There were about 89 downloads when I swapped the file this morning; sorry for not catching it sooner.

Quote:
Originally Posted by gerthworm View Post
Cool stuff, thanks for posting!

Of course, I was particualrly drawn to the conclusions of reliability percentages corresponding to time spent repairing. Understanding this relationship is obviuosly key to establishing design criteria.
Glad that you enjoyed it; it was fun putting together that paper. I'd also suggest that understanding the relationship between robot uptime/reliabilty as a function of repairability and robustness/durability is key. It's enlightening to run an iteration or two of gradient ascent (or descent, depending on which side you pick to optimize). In general, an extra pound of repairability is not equivalent to an extra pound of durability/robustness.

Quote:
Have you started to look at designs and evaluate what constitutes an "83% chance of being repaired within 2.5 minutes"? What sort of design process changes would you suggest to hit these metrics?
That's a very good question. The short answer is that I haven't looked at designs, and I'm unlikely to do so. That's primarily a function of my background (math/computer science, not manufacturing or mechanical/electrical engineering), and my recognition that many, many variables are involved in those numbers. I don't believe there's a closed form solution that is going to tell me how fast something is to repair or how often it's going to break before I actually build it. And even if I had enough data to do a confidence interval on the robustness or repairability of different designs this year, it's unlikely that the game next year will result in designs for similar mechanisms and subsystems. I'd be more interested in studying things that don't change year to year, like the impact of prototyping, manufacturing techniques, tolerances, and preventative maintenance. Maybe I'm biased though, since that's basically a list of the things that 6844 got wrong this year.

As far as a design process goes, I'd start by making sure you're being strategic and thoughtful. Ask yourself and your students what the failure modes are. Idenfity the "mission impact" of the failure - "if this breaks, what does that do in a match? If this breaks, what does that do to our chances of being picked?" Estimate how frequently you'll encounter the failure mode. Estimate how quick to repair the failure mode will be. Multiply both estimates by a safety/fudge factor. Come up with a preventative maintainence plan, and practice repairs. Consider if your repairs will have any impact on software. Build and bag spare assemblies when possible.

I also suggest that subsystem designers pick a "favorite" failure mode. For example, wheels slipping on a drivetrain might be considered a failure, as it results in a loss of propulsion - but it also means that you're not tripping your main breaker. Pick a failure mode, optimize the other failure modes into statistical improbabilities, and then optimize that failure mode for repairability.

Quote:
Originally Posted by GeeTwo View Post
Perhaps I'm misreading this, but it seems like your chain is still 5% likely to break every 300 seconds even while you're waiting in the pit or the queue.
Quote:
Originally Posted by gerthworm View Post
I'd presume there's some assumption of "failure rate applies to robot in motion" and the failure rate of a robot sitting in storage is comparatively negligible?
You're almost right - I can see how that could be confusing, based on how I phrased things in the paper. If I update the paper again, I might change this.

On average, there's a 5% chance that it will break in a 2.5 minute window. That average accounts for time spent in matches, time on the practice field, time tuning auto, and the rest. Not going to lie - it's a pretty sad drivetrain.
__________________
Code and FRC, my personal blog.

Team 20, 2012-2014: 4 blue banners, 5 medals, and 9 team awards.
Missionary, Church of Jesus Christ of Latter-day Saints, 2014-2016: Colorado Denver South Mission.
Brigham Young University, 2016-present: Computer Science.
Team 6844, 2018-present: 2018 Utah RAS, 2018 Newton/Carver RHS.
Reply With Quote
  #6   Spotlight this post!  
Unread 07-18-2018, 11:38 AM
Mechvet's Avatar
Mechvet Mechvet is offline
Electromechanicadchining Mentor
AKA: Craig Hickman
FRC #0114
Team Role: Mentor
 
Join Date: Jan 2016
Rookie Year: 2004
Location: Yay Area
Posts: 228
Mechvet is a splendid one to beholdMechvet is a splendid one to beholdMechvet is a splendid one to beholdMechvet is a splendid one to beholdMechvet is a splendid one to beholdMechvet is a splendid one to beholdMechvet is a splendid one to behold
Re: paper: Modeling Subsystem Reliability

How does the math change if your drivetrain requires time for debug, and failure analysis?

Breaks and damage aren't always obvious.
Reply With Quote
  #7   Spotlight this post!  
Unread 07-19-2018, 08:41 AM
brennonbrimhall brennonbrimhall is offline
Lead Mentor
AKA: Brennon Brimhall
FRC #6844 (Provotypes)
 
Join Date: Jan 2012
Rookie Year: 2012
Location: Provo, UT
Posts: 389
brennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond reputebrennonbrimhall has a reputation beyond repute
Re: paper: Modeling Subsystem Reliability

Quote:
Originally Posted by Mechvet View Post
How does the math change if your drivetrain requires time for debug, and failure analysis?
Analytically, it changes significantly. See spoiler for details.

Spoiler for the mathematical details:
I assume that you're saying that you'd always fix after debugging, so we'd end up with a matrix like this (do me a favor and imagine square brackets around this):

Code:
w	0	1-f
1-w	d	0
0	1-d	f
Then, the steady state probability for being in the working state (mouthful, I know - but I don't know how to phrase that any better) is:

Code:
x = 1 / (1 + (1 - w) / (1 - f) + (1 - w) / (1 - d))
If you focus on the transitions between states, then you get a form that is, in my opinion, a bit nicer:

Code:
a = 1 - w
b = 1 - d
c = 1 - f

x = 1 / (a / a + a / b + a / c)

If you want, I can go through derivation, but it would need to be typeset in LaTeX. It would be pretty unreadable here.


Interestingly, this hardly impacts the example I used.

If you put in that debugging takes, on average, 5 minutes and that fixing it takes, on average, 25 minutes (notice that when summed together, this is the same average of 30 minutes), we have a .625 for the three-state/debug model and .624 for the two-state model. This may be a mathematical coincidence rather than anything really meaningful, however.

If you want to play with different scenarios, here's a Google Sheet that will try to numerically solve a three-state Markov chain.
__________________
Code and FRC, my personal blog.

Team 20, 2012-2014: 4 blue banners, 5 medals, and 9 team awards.
Missionary, Church of Jesus Christ of Latter-day Saints, 2014-2016: Colorado Denver South Mission.
Brigham Young University, 2016-present: Computer Science.
Team 6844, 2018-present: 2018 Utah RAS, 2018 Newton/Carver RHS.

Last edited by brennonbrimhall : 07-19-2018 at 08:43 AM.
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 09:43 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi