Team Update #18

[JesseK]

Originally Posted by Ether

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.

The basic cause-effect of this, as an example, is that even if the minibot moves the plate 1", causing the sensor to be in contact for 3/4" of that movement, the contact time of the sensor is much less than the 100ms I listed. So we need either a higher sampling rate to allow finer granularity in the false-positive algorithm, or we need a dampening mechanism that's implemented by the "GDC" or by teams.

====

As far as I can tell, interrupt-driven signals have just as much probability for false-positives as sampling does in this setup. The interrupt would have to be held high/low for a certain amount of time to ensure it's a valid trigger, which still requires some sort of 'time' specification for teams to ensure they don't lose contact with the sensor too quickly.

[JesseK]

Originally Posted by Mike Copioli

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.

How do you safely account for paradox? The refs would need to be up on a ladder (or something similar) to ensure they hit the button at the actual impact time and not a microsecond later. In swimming the judges are able to stand over the lanes to get the best view (from what I've seen).

The issue with sending out a time spec isn't efficiency, but rather accuracy. If it's wrong in 1 case at 1 regional, causing a tower to not be triggered and a match to be lost, was it worth it to argue over what the actual number is to begin with?

I'm not defending FIRST so much as I'm trying to be pragmatic about this from a project engineering perspective.

[Chris is me]

Originally Posted by JesseK

How do you safely account for paradox? The refs would need to be up on a ladder (or something similar) to ensure they hit the button at the actual impact time and not a microsecond later.

All of the refs are standing from more or less the same spot on the floor relative to their respective towers.

[Mark McLeod]

I think pole-sitting refs would add greatly to the amusement factor, as well as, giving them a kick in the pants to push their button.

[c-parent]

Originally Posted by Mark McLeod

I think pole-sitting refs would add greatly to the amusement factor, as well as, giving them a kick in the pants to push their button.

I think you may be on to something for next years game...I'm seeing dunk tanks maybe?

[boomergeek]

I think we have one ref concentrating on every tower anyway looking for penalties and disablement.
I think we can trust ref's to press an "enablement" button as soon as the minibot crosses the starting line, then use the sensors on the plate integrated over 40 milliseconds to record the time I.e., the tower plate is inactive until after the ref decides the minibot crossed the start line fairly.

Whatever the triggering mechanism: it NEEDS to be published and the sooner the better. If not, then some teams will end up getting an advantage over others because of the multiple hats of developers, testers and facilitators.

[wireties]

Originally Posted by Chris is me

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

I don't want to seem too flippant but YES - because that is how the real world works. It is not fair and/or uniform. Go thru a career as an engineer who assumes the provided specs are always perfect and you will lose a lot of money and be frustrated. You'll probably quit and end up a sales-person!! ;o)

[JaneYoung]

Originally Posted by Al Skierkiewicz

I am thinking that temperature in Texas is spiking today.

We continue to monitor the impact of Copioli-isms in Texas, shoring up weaknesses in mounting pressures and potential collisions caused by strong wind. In other words, we are doing the best we can with what we have to work with. Temps are still spiking in some areas but we're continually adapting in preparation for the next generation.

Jane

[Ether]

AFAIK, we do not have official drawings or specs (of the sensor) from FIRST so I cannot say this definitively... but if the drawing that was posted earlier in this thread by colt527 is a reasonable representation of the hardware then the minibot moves the plate 1/4" and then closes the "switch" (which appears to be 2 metal pieces coming into contact) which acts as a hard-stop. High speeds of impact into this hard stop could arguably mean less contact time, not more.

The damping mechanism was suggested earlier in this thread by Squirrel (minibot) and jspatz1 (tower).

Everyone agrees that requiring multiple consecutive positive samples lowers the incidents of false positives.

The comment about interrupts was simply a clarification, for the benefit of students who may be reading, to an unqualified statement made about sampling. It may or may not be part of an eventual solution. Another clarification: an interrupt does not have to be "held". The ISR can spawn a high-sampling-rate temporary thread to run an algorithm to test for false negatives. Then it's just* a matter of adjusting the software.



* "just software". I hate that phrase. Don't you?

[JesseK]

Originally Posted by Ether

The damping mechanism was suggested earlier in this thread by Squirrel (minibot) and jspatz1 (tower).

Yea, I was close to squirrel's idea with a slightly different idea that was totally ignored. Jspatz's damping idea looked like an entire rework that introduced as many questions as it had answers. But that's neither here nor there at this point. The math and the arguments solidify that a simple damping mechanism is probably the simplest way forward from both a technical and a holistic program perspective. Personally, at this point, I'd much rather implement the damping mechanism myself rather than expect the numbers FIRST puts out are perfect and without tolerance. We still need test time on Thursday though. I don't exactly have a "springy finger" or "squishy surgical tubing" down to a mathematical science yet.

[Tom Ore]

I'm thinking the root cause of the problem is more related to the rate of evolution of minibot designs. With the full-size competition robots, even when teams see robots with really amazing features, they are just too complicated to copy in the time available. The design time of one iteration of a minibot is fairly short and teams which so choose can keep iterating as long as they want. My guess would be that the GDC envisioned 4 or 5 second minibot times and the triggering system on the tower would have been fine. Early in the build season, talk of 3 second minibots surfaced. Then 1625 posted their video and the times fell to 2 seconds and now times near 1 second have been demonstrated. Put 2000 teams on a problem and allow them to iterate over and over again and give them a big payoff or iterating over and over and the result is that by St. Louis any team that wants an awesomely fast minibot will have one and maybe they all will exceed what the GDC envisioned.

[AdamHeard]

Originally Posted by Tom Ore

I'm thinking the root cause of the problem is more related to the rate of evolution of minibot designs. With the full-size competition robots, even when teams see robots with really amazing features, they are just too complicated to copy in the time available. The design time of one iteration of a minibot is fairly short and teams which so choose can keep iterating as long as they want. My guess would be that the GDC envisioned 4 or 5 second minibot times and the triggering system on the tower would have been fine. Early in the build season, talk of 3 second minibots surfaced. Then 1625 posted their video and the times fell to 2 seconds and now times near 1 second have been demonstrated. Put 2000 teams on a problem and allow them to iterate over and over again and give them a big payoff or iterating over and over and the result is that by St. Louis any team that wants an awesomely fast minibot will have one and maybe they all will exceed what the GDC envisioned.

Within a few hours of the update clarifying we had to use FTC motors, we had already calculated (with darn simple math), that sub 1 second minibots were possible. This should not have been overlooked, that's as if they made a field border that could only handle impacts of robots going 7 ft/s, because they assumed none would go faster.

[Ether]

Originally Posted by AdamHeard

Within a few hours of the update clarifying we had to use FTC motors, we had already calculated (with darn simple math), that sub 1 second minibots were possible.

Would you be willing to post this math, for the benefit of students on teams who do not have mentors/teachers who know how to do motor calculations.

[Tom Ore]

Originally Posted by AdamHeard

Within a few hours of the update clarifying we had to use FTC motors, we had already calculated (with darn simple math), that sub 1 second minibots were possible. This should not have been overlooked, that's as if they made a field border that could only handle impacts of robots going 7 ft/s, because they assumed none would go faster.

I hear what you are saying and it seems reasonable, but if the GDC anticipated 1 second minibots it seems like they should have built some and tested them on their triggers. Most team minibots were probably "tinkered" into existence rather than engineered into existence. Is it possible that the GDC did likewise?

[Ether]

Originally Posted by Ether

Would you be willing to post this math, for the benefit of students on teams who do not have mentors/teachers who know how to do motor calculations.

16.8 watts max power output w/o gearhead

= 12.4 ft-lb/sec

x2 motors = 24.8 ft-lb/sec max power output

2.3 lb estimated robot weight

(24.8 ft-lb/sec) / (2.3 lb) = 10.8 ft/sec (neglecting friction)