Go to Post You need a good BAD (*BAD = Ball Acquisition Device) - DonRotolo [more]
Home
Go Back   Chief Delphi > Competition > Rules/Strategy
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
View Poll Results: How many times are necessary to determine consistency?
Defenses: 1-3 1 1.35%
Defenses: 4-6 14 18.92%
Defenses: 7-10 18 24.32%
Defenses: 11-20 18 24.32%
Defenses: All 27 36.49%
Climbing: 1-3 4 5.41%
Climbing: 4-8 27 36.49%
Climbing: All 33 44.59%
Multiple Choice Poll. Voters: 74. You may not vote on this poll

Closed Thread
 
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 27-01-2016, 03:05
Knufire Knufire is online now
Rose-Hulman Institute of Technology
no team
Team Role: College Student
 
Join Date: Sep 2009
Rookie Year: 2010
Location: Terre Haute, IN
Posts: 740
Knufire has a reputation beyond reputeKnufire has a reputation beyond reputeKnufire has a reputation beyond reputeKnufire has a reputation beyond reputeKnufire has a reputation beyond reputeKnufire has a reputation beyond reputeKnufire has a reputation beyond reputeKnufire has a reputation beyond reputeKnufire has a reputation beyond reputeKnufire has a reputation beyond reputeKnufire has a reputation beyond repute
Re: How many times is enough to prove consistency?

Remember, quantitative data is ALWAYS better than qualitiative. You have a goal in mind (measuring the consistency of robots crossing defenses). How can you measure this with a hard, factual number?

If you have a bunch of qualitative ratings that scouters can choose from, the robot will be at the mercy of the scouter's opinion. Different scouters on your team might have different standards as to what a "good" vs "struggle" crossing is.

I also don't see that many "unsuccessful" crossings happen. An unsuccessful crossing can only happen two ways; you either fail to get over the obstacle and back up, or you get stuck. If you're stuck, you're done for the match unless a partner comes and helps you out, and that probably only counts as one (albeit massive) failure. If you have to back up and try again, you'll probably get the same result (re. definition of insanity) unless you try to Duke of Hazzard it over.

My initial thought was to record not whether the robot crossed or not, but the time it took the robot to cross. Having the average time to cross each obstacle for every team at a tournament would be an extremely valuable piece of data. Downside is that this is probably only practical to record with some sort of electronic scouting system. For this method, I'd also define crossing per the manual definition of a CROSS for clarity.
__________________
Team 469: 2010 - 2013
Team 5188: 2014 - 2016
NAR (VEX U): 2014 - Present
  #2   Spotlight this post!  
Unread 27-01-2016, 10:22
Jcarbon Jcarbon is offline
Registered User
FRC #3322 (Eagle Imperium)
Team Role: Leadership
 
Join Date: Jan 2016
Rookie Year: 2014
Location: Ann Arbor, Mi
Posts: 63
Jcarbon has a spectacular aura aboutJcarbon has a spectacular aura about
Re: How many times is enough to prove consistency?

We generally scout both quantitatively and qualitatively. This year, I think we'll count total crossings and also have experienced scouts judge speed, consistency, and ease of crossing. Then, we can combine the information to make decisions - did they cross a lot but do it hesitantly? Did they do only a few crossings but do each one smoothly and quickly? Of course, whatever system we use will probably change once we see what matches and robots actually look like.
  #3   Spotlight this post!  
Unread 27-01-2016, 14:19
gblake's Avatar
gblake gblake is offline
6th Gear Developer; Mentor
AKA: Blake Ross
no team (6th Gear)
Team Role: Mentor
 
Join Date: May 2006
Rookie Year: 2006
Location: Virginia
Posts: 1,935
gblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond reputegblake has a reputation beyond repute
Re: How many times is enough to prove consistency?

If a team+robot accomplishes something every time they attempt that thing between Wednesday and Sunday, I would say that they were consistently able to accomplish it.

On a slightly more serious note, one big aspect of achieving consistency when doing anything is controlling the independent variables that affect doing that thing.

If you call the thing-to-be-done a process, that process will consume (or be affected by) inputs that are fed into it purposefully (such as battery charge remaining, driver commands, etc.) and by inputs that come from the environment around it (temperature, other robots, debris, friction, etc).

If you want to think about whether other teams' FRC robots can accomplish some process consistently, your thinking needs to include thinking about all the inputs that affect the process, and about how many of those inputs the other team-plus-robot are able to control (how many are possible to control, and how many do they control); and think a little about which of those inputs are the most important.

If the team-plus-robot that you are assessing is doing well at controlling the important variables that can be controlled, then they are likely to perform consistently (predictably) during matches. They (and their allies) will be able to *predict* outcomes as well as can be reasonably expected.

And, I think that being able to make accurate *predictions* is the real topic being discussed here.

With that in mind, seeing another team-plus-robot accomplish some process once could easily convince me that I can rely on their predictions of how well they will perform that process in the future; so long as that one observation was complemented with me knowing that they are controlling the important independent variables that affect the process.

I hope this helps.
__________________
Blake Ross, For emailing me, in the verizon.net domain, I am blake
VRC Team Mentor, FTC volunteer, 5th Gear Developer, Husband, Father, Triangle Fraternity Alumnus (ky 76), U Ky BSEE, Tau Beta Pi, Eta Kappa Nu, Kentucky Colonel
Words/phrases I avoid: basis, mitigate, leveraging, transitioning, impact (instead of affect/effect), facilitate, programmatic, problematic, issue (instead of problem), latency (instead of delay), dependency (instead of prerequisite), connectivity, usage & utilize (instead of use), downed, functionality, functional, power on, descore, alumni (instead of alumnus/alumna), the enterprise, methodology, nomenclature, form factor (instead of size or shape), competency, modality, provided(with), provision(ing), irregardless/irrespective, signage, colorized, pulsating, ideate

Last edited by gblake : 27-01-2016 at 14:29.
Closed Thread


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 06:17.

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


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