Re: Team Update #18
 

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.

Re: Team Update #18
 

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

Re: Team Update #18
 

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?

Re: Team Update #18
 

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

Re: Team Update #18
 

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

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.


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

Re: Team Update #18
 

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):

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.

Re: Team Update #18
 

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.

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

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.

Re: Team Update #18
 

I am thinking that temperature in Texas is spiking today.

Re: Team Update #18
 

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.

Re: Team Update #18
 

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.

Re: Team Update #18
 

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!!

Re: Team Update #18
 

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.

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.

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.

Re: Team Update #18
 

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

Re: Team Update #18
 

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

Re: Team Update #18
 

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.


.Yes, an incomplete spec.


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.