Team Update #18

[Rick TYler]

Originally Posted by Paul Copioli

... or Karthik.

Is that an Imperial Karthik or a new metric Karthik? Either way, I like the idea of saying, "Our robot imparts a force of 1.2 Karthiks on the playing surface."

Or, "most FRC robots are about 1.2 Karthiks, but FTC robots are usually .25 Karthiks, and VRC robots about .15 Karthiks." I think this could catch on.

[Matt Krass]

Originally Posted by Rick TYler

Is that an Imperial Karthik or a new metric Karthik?

Now I'm imagining some bizarre Star Wars-esque theme song when Karthik walks around. Sort of an Imperial Karthik March...

[Paul Copioli]

Originally Posted by Matt Krass

Now I'm imagining some bizarre Star Wars-esque theme song when Karthik walks around. Sort of an Imperial Karthik March...

So is it wrong that I just started humming the imperial march score?

I guess I just found the entrance music for Karthik at Waterloo! I wonder how long it will take before someone shuts down the webcast at Waterloo?

[Matt Krass]

Originally Posted by Paul Copioli

So is it wrong that I just started humming the imperial march score?

I guess I just found the entrance music for Karthik at Waterloo! I wonder how long it will take before someone shuts down the webcast at Waterloo?

I imagined it sounding like the Imperial March, with a mix of power drills, and the FMS sound effects...

Is this what happens if you stay in FIRST too long?

Matt

[Mike Copioli]

Originally Posted by JesseK

yet the whiners haven't proposed a solution..

What makes you think they haven't. If they did, what makes you think FIRST will listen?

Originally Posted by JesseK

The fact of the matter is, Physics beat the crap out of FIRST's system during Week 0 and Week 1 by exposing a severe flaw. Why are we complaining that FIRST had to adapt to it? Why should they put out a specific spec in the form of a rule that teams WILL simply complain about regardless? .

Because it is their job and responsibility. A 'spec' is not a rule, it is the specifics of how something should work, hence the name 'spec.' A rule or ruling is what update 18 is and I do not consider "Oh well trigger it or else it does not count" as adapting to it.

Originally Posted by JesseK

Honestly, the only concession FIRST can make at this point is to give us dedicated MINIBOT time on Thursday.

A spec would be easier and much more efficient since teams have unlimited access to the minibot.

[JesseK]

Originally Posted by jspatz1

I wouldn't say I'm a whiner, but I did propose a solution: http://www.chiefdelphi.com/forums/sh...57#post1040957

Think the design of the solution through, including its problems and how to solve them. Then analyze if the new problems present risks in implementation, and determine if the solution really solves the overarching problem or if it simply introduces different problems from the current implementation. You've presented an entirely new configuration -- if you can lay out more than just a picture, then you've presented a solution rather than an idea.

======================

As for the force required, I don't think it's relevant in retrospect; I do concede that it's improbable for the minibot to stop before it hits the sensor. I do still believe the friction greatly effects the deceleration rate of the minibot, which then effects the sensor contact time while the minibot decelerates moving up the pole after cutoff. (I don't know why I keep arguing irrelevant points). So below I'll present the case where there is no external force, as you've recommended and as I can't properly characterize. We can assume that the times will be less during deceleration if there is friction. Thus, deceleration comes from ~17N (plate + bot weight) of force on a 3lb minibot.

If the sensor contact points have a length L, and the minibot weight 3 lbs, and the bound off of the top plate provides no acceleration downward, then the data follows (times in milliseconds):

 L (in)    upward   downward   total
====================================
0.25         27.0     36.0      63.0
0.375        33.1     44.1      77.2
0.5          38.2     50.9      89.2
0.625        42.8     56.9      99.7
0.75         46.8     62.4      109.2
0.875        50.6     67.3      117.9
1.0          54.0     72.0      126.1
====================================

If we figure out what can make these times less, we may be on our way to finding the real problem:
1.) A gap between contact points -- this is necessary to prevent vibratory false positives. The gap means that the sensor makes contact for less time than the minibot is in contact with the tower.
2.) A bounce of the minibot off of the top plate that increases downward acceleration would decrease the time.
3.) Friction that increases deceleration moving up. In retrospect, perhaps the bounce has more of an effect that could make this negligible anyways?
4.) What others are there?

So if we try to solve any of these inherent problems, without introducing any new problems by regression, then (1) isn't really solvable except by sampling rate adjustments to ensure the most accurate initial contact time, (2) means we need a damping mechanism, and (3) just might be negligible. Cory wants the limit switches with increased sampling rates, but isn't that the setup that induced the false positives? Or did the false positives come as a result from FIRST not using the limit switches for some reason? It's important to note that even the limit switches have a contact length, L, and that the sampling rate of the switch could still mean a false negative given the data above. If a custom circuit was created to sample the sensors, then adjustments may not be possible (unless it's a simple resistor replacement, which could still introduce errors during replacement).

Thus I suspect the greatest contributing factor to the problem (as of Week 2) is the bounce off the top plate (stated before I'm sure).

IMO, the simplest 'fix' that would solve the problems is a simple dampening mechanism that attaches to a current configuration. If you're the GDC, is it easier to get teams to add a simple dampening mechanism to their minibots, for you to add your own (think logistics here...), or both? If the GDC has to add a rubber bumper, they have to give a new Force spec to teams. If the onus is on teams to add their own dampening mechanism, then the teams can customize it to their minibots. So Cory, I think you should be grateful the GDC isn't trying to perform a fix that could simply introduce more problems.

Thus, the GDC should give the teams some extra test time with the minibots in the real system with the Week 2 fixes.

[JesseK]

Originally Posted by Mike Copioli

What makes you think they haven't. If they did, what makes you think FIRST will listen?

Because the "solutions" in this thread haven't been well thought-out solutions so much as they've been ideas that would introduce the same magnitude of risk as the current implementation did 2 weeks ago. The GDC would be vilified further if they implemented a "new" design that had the same issues as the current/old (Week 1) design.

Because it is their job and responsibility. A 'spec' is not a rule, it is the specifics of how something should work, hence the name 'spec.' A rule or ruling is what update 18 is and I do not consider "Oh well trigger it or else it does not count" as adapting to it.

The Update simply enforces the rule as it was before referees made their decisions to manually score it. The spec and the update have nothing to do with each other in that regard. The Update simply points out a spec that was available before (though this is more opinion in regards to what the intention of putting that note in an official rule update is).

A spec would be easier and much more efficient since teams have unlimited access to the minibot.

Yet the argument that has been made very clear (and most accurately) is that the specs provided by FIRST haven't been 100% complete or accurate thus far.

I do agree that it's an insane amount of information in too many different places that make things confusing, but I'm more inclined to think that (right now, moving forward) more test time would be less time consuming and less frustrating that expecting teams to believe a new specification at this point.

[Al Skierkiewicz]

Originally Posted by Paul Copioli

So is it wrong that I just started humming the imperial march score?

I guess I just found the entrance music for Karthik at Waterloo! I wonder how long it will take before someone shuts down the webcast at Waterloo?

I am thinking that temperature in Texas is spiking today.

[Ether]

Originally Posted by Matt Krass

Logically a computer system can only sense a condition that exists for a finite period of time related to the sampling rate.

You're forgetting about interrupts. If the switch is connected to an IO port which can be configured to generate an interrupt then there is no sample rate involved.

[wireties]

Originally Posted by Ether

You're forgetting about interrupts. If the switch is connected to an IO port which can be configured to generate an interrupt then there is no sample rate involved.

And it certainly possible (though I guess not used here) to latch rising or falling edges of a signal so they are preserved till the computer gets a chance to poll them or run the ISR that reads them.

[wireties]

Originally Posted by Cory

I don't feel the specification was unclear. There is a force given in the rules. The original tower used limit switches.

Logically one would think that a setup using limit switches would be momentary-ie not having to be triggered for some finite time period.

We should have foreseen that there was not enough real world testing done to show how robots hitting the towers would affect the response of the triggers?

In the future I guess when we see things like this you're saying we should assume FIRST will not be able to implement them properly and as such we should ask way more questions than necessary to ensure that everything works right?

I was drawing an analogy to a classic real-world engineering quandary (so students and young mentors can learn something from this problem), not stating that FIRST was doing anything wrong, intentional or not.

It is not uncommon to get requirement/s or a proposal from a real-world customer that is vague or contradictory or impossible. In such cases it is prudent to ask for more detail before starting a design/build process. In the real world, it costs $$$ to pursue vague requirements, a risky course of action!!

[Ether]

Originally Posted by JesseK

it's improbable for the minibot to stop before it hits the sensor.

I wouldn't take that possibility entirely off the table, in view of some of the testimony given in this thread. It's at least possible that on some occasions where the minibot visibly whacked the plate but failed to trigger, the cause was a tilted/jammed plate which prevented switch contact.

We can assume that the (contact) times will be less during deceleration if there is friction.

It's not at all obvious that this assumption is valid. It is arguable that a faster-moving object with no friction hitting a switch may ricochet off faster and have less contact time than a slower-moving object with friction.

(if) the bound off of the top plate provides no acceleration downward

When the minibot drives the bottom plate into the switch, there will be rebound acceleration of the minibot. This acceleration is very large and cannot be ignored. The only time there would be no rebound acceleration would be if the speed had become near zero by the time the minibot hit the switch.

[wireties]

Originally Posted by Cory

In the future I guess when we see things like this you're saying we should assume FIRST will not be able to implement them properly and as such we should ask way more questions than necessary to ensure that everything works right?

Surely there is some middle ground. And asking more questions than is necessary is preferable to asking too few questions, don't you think?

HTH

[Chris is me]

Originally Posted by wireties

Surely there is some middle ground. And asking more questions than is necessary is preferable to asking too few questions, don't you think?

HTH

So we're supposed to assume FIRST's specs are a little incomplete instead of complete or completely wrong? Why?

[Mike Copioli]

Originally Posted by JesseK

Because the "solutions" in this thread haven't been well thought-out solutions so much as they've been ideas that would introduce the same magnitude of risk as the current implementation did 2 weeks ago. The GDC would be vilified further if they implemented a "new" design that had the same issues as the current/old (Week 1) design.

That's because the spec is incomplete. Debounce time is a necessary component for solving this problem. Without it you can apply 100 newtons or Karthiks or grains or whatever unit you like until you turn blue, if you do not apply that force for at least the time needed to debounce the switch it does not matter.


.

Originally Posted by JesseK

The Update simply points out a spec that was available before (though this is more opinion in regards to what the intention of putting that note in an official rule update is).

Yes, an incomplete spec.

Originally Posted by JesseK

I do agree that it's an insane amount of information in too many different places that make things confusing, but I'm more inclined to think that (right now, moving forward) more test time would be less time consuming and less frustrating that expecting teams to believe a new specification at this point.

Ok, if you think that clarifying a spec is more difficult then every team in FIRST using trial and error to find what works then FIRST is less efficient than I thought.

So fine I have a simple solution.... Use the sensor plates as primary feed back and four dudes with a button as secondary. This is how it is done in swimming events, including the Olympics.