Re: Team Update #18
 

I don't doubt that there were several instances where MINIBOTs did reach the top, but did not TRIGGER the TOWER. Unfortunately, the rules do not let that count for anything.

How can you claim there was a field malfunction if the exact requirements to TRIGGER the TOWER are not specified? It could just as easily be that the MINIBOT in question does not close the switch for a long enough time to trigger the field system.

I do understand that the system was changed to make it less sensitive to false triggering. But since the whole thing was not specified, I won't say that the field system no longer meets the specs. The ultimate spec is still that you gotta trigger it. Rather than complain about FIRST following their own rules, work on your MINIBOT to make it trigger every time. Ask on the Q&A what exactly is supposed to be required to make it trigger.

Re: Team Update #18
 

How can you claim it was a MINIBOT malfunction, if you don't know what to design your minibot for. If FIRST made us guess on what the maximum peg height would be, I don't think anyone would be happy.

Re: Team Update #18
 

Is there one that says: "Our minibots dimensions make it physically impossible to hit the bolts and we have a really tough to flip switch so that the plate must be pushed up and hit the contacts before it turns off"

If these cases can be organized and then demonstrated week 3 practice day then I will believe there are larger problems at work here.

Re: Team Update #18
 

Ken, what would be considered bouncing off too fast? What is the duration that teams need to contact the disc to ensure that the target is triggered?

Ken's point is a very valid one. Does anyone have any video of Minibots hitting the top target but not triggering the target during week 2? Right now we're just dealing in speculation which isn't leading to anything productive. From what I saw in Pittsburgh, the large majority of minibots were in fact triggering the top target. If this wasn't the case at a regional you were attending, let's try and figure out what the issue was that was causing these false negatives.

If the issue was minibots hitting the bolt heads, that's unfortunate but it can be argued that teams should have been prepared for that based on the published drawings. (I may consider that a flimsy argument, but that's neither here nor there) If the issue is that teams aren't contacting the top target for long enough, I'm more concerned as nowhere in any official specification or guideline have I seen a duration of impact clause.

Re: Team Update #18
 

The reason I'm reading this thread is to gather as much information as possible to ensure our minibot hits the trigger every time.

The only course of action is to work on your minibot to ensure it hits the trigger every time. What I don't agree with is that this course of action was a necessary evil of this game. Had the specifications been laid out ahead of time I would certainly not be complaining one bit if my minibot didn't hit the switch. What bothers me is that there seemed to be some kind of a specification regarding force and now that specification seems less important than the time it takes to trigger the target.

This is a healthy discussion, but I think theres too many unknowns to really take it farther. I think we can agree that the teams responsibility is to trigger the target, what we need is some direction from FIRST on what exactly that entails (your Q&A suggestion is a good one).

-Brando

Re: Team Update #18
 

That's a very good question. I guess the officials didn't understand the rules.

If we'd all had our act together two months ago, we would have asked

:eek:

Re: Team Update #18
 

I do not have a answer for this. So far the only thing I heard of was the speculation of 75ms floating around in this thread. I can see if I can find an answer to this later.

It makes sense to me that if it turns out there are bots that definitely don't hit the bolt and hit the pad hard enough and still don't trigger that duration would be the next most probable cause. I can imagine a pretty violent bounce on some minibots. I would like to believe FMS would still catch those, just based on some of the minibots I saw at Pittsburgh which bounce pretty good that got picked up, however I can not say that bouncing too quick is an impossible cause of a false negative.

I think teams can alleviate the duration problem pretty easily as well by adding some cushioning or something, but I know a real hard number for duration time would help team immensely.

Re: Team Update #18
 

The challenge was to get the minibot to trigger the target as quickly as possible. This is an optimization problem. Many of us used the specifications given as we worked out the optimization.

As they say in Animal House: "You effed up! You trusted us!"

To imply that all teams should have built a slow super-overpowered minibot just to ensure they trigger the target if the FIRST specs were wrong is silly. We (as good engineers) should have worked within the specs given to us.

BTW - I have no idea if there is a problem or not, but I'm surprised by your dismissal of the fears of many by saying "you should have built your minibot to hit harder, not to the spec."

-John

Re: Team Update #18
 

Apparently not many (none?) of us realized the spec was incomplete.

I sure missed it.

Re: Team Update #18
 

I beg to differ... the peg heights are in GE1100-1106 and are referenced on page 3/10 of the 2011 FRC Game Manual, Section 2 - The Arena. Yes they could have been better spelled out. In the "real" engineering world, engineers reference other documents all the time, rather than copy/pasting specs into every document they make because it reduces the risk of forgetting to update documents when a change is made. GE-11036 tells you exactly how to build a sensor plate, yet how many teams actually did it?

Bingo!

I am not sure what you call "it seems to be working" as week 1 they CLEARLY weren't working. There were a ton of false triggers (robots hitting the tower), and then when they implemented a duration, some robots were too fast, so they resorted to manual scoring for week 1. So FIRST fixed them. They did not change the plates, just the electronics/sensors.

In my mind there is absolutely no way a ref or any spectator can tell for certain that a minibot has put enough pressure on the plate, not hit a bolt and reliably triggered the top. The field crew will be able to test & determine if the tower sensors are working, and if a sensor breaks, I am certain they will fix it.

EXACTLY... I have yet to see a single video that convinces me otherwise. Everyone can do all the math they want, but without factoring in things like when does your robot reverse direction, what is its deceleration,etc, its impossible for me to conclude that the towers aren't working.

And I agree with everyone saying there is too much speculation in here... has anyone actually gone into the Q&A and asked the question? Asked what the sensor is? what the duration is? Your team leader has access to the Q&A forums... USE THEM.

Re: Team Update #18
 

You missed my point entirely. Squirrel was making the point that the 4N number was not in the rules (one of those things with the <Gxxx>), but in the arena drawings. My point was that the arena drawings ARE part of the specs and are just as important as the rules (<Gxxx> again).

Also, even if a team built the sensor plate, it is apparent that that is not enough. You have to know how that switch trigger will be detected. What algorithm is used to reject pole strikes by robots? how long does the switch have to be depressed? etc.

Re: Team Update #18
 

Ask in the Q&A.

Sorry if I misread your original post... I'm a little annoyed that everyone is blaming FIRST for this, when they are clearly trying to make an improvement over week 1, and no one can move that a minibot that should have triggered the pole didn't.

Re: Team Update #18
 

There was a question in the Q&A asking if the bot had to stay up for any period of time.

The response was that it just had to trigger the plate.

As far as padding goes, we tried this in week 1 with 1/2" of "grip-pad" and electrical tape formed into a cushion. This did not improve the reliability of triggering in week 1 at all.

I measured the force our light switch requires to activate. It was 5-6 newtons. 25-50% above the upper limit of the specification (2-4N). The minibot itself struck the top-plate of the practice pole (wood plate) violently enough that the 10' steel pole actually jumped about 1/8". This would make sense if you do the physics of a 1.25 kg object traveling at about 2 m/s (some minibots are even faster than this) being stopped in less than 7mm of travel. It is a pretty violent impact. If the impact absorbed perfectly, I would expect a If you do the math on this, you would expect 7ms impact with a peak force around 30-40N.
Of course, this was week 1. I did hear that week 2 was improved immensely.

Assuming an elastic collision, this could have a dwell under 14ms. If 75ms is required, a flexible member requiring about 4N to flex it, and around 2-3 inches of compression just might work. Shorter if you are slower, longer if you are faster. For you guys going 3 m/s... Good luck. Hope to be joining you soon.

Re: Team Update #18
 

I haven't been to a competition yet, so i don't know, but are they letting you test your mini bot on the field before hand? Just to make sure it works. As far as the bolts go, if i was a ref i would put some chalk or something on the bolt heads. Something that would leave a mark. Or, before the comp the bots get checked to see if they can contact the bolt. Maybe a green mark on bot that can't touch bolt and a red mark if it can. This would end a part of the problem or questions that might arise.

Re: Team Update #18
 

Before I say anything else, let me start with a few caveats:

1. Our team (1519) was at a week zero (pre-ship) scrimmage (Nashua, NH) with the official field, and a week one tournament (NH).
2. At week zero, we had a minibot of around 3.5 pounds and 3-4 seconds.
3. At week one, we had a minibot of around 2.3 pounds and <2 seconds.
4. We did not compete at week two, so I don't have first-hand experience as to whether or not the field changes helped fix the problems.

At week zero, there were lots and lots of "false positives" occurring on the minibot towers from robots bumping into the base of the towers. My understanding is that this was due to very sensitive limit switches combined with an FMS sampling time of 20ms where only one sample was required to report a trigger. However, I don't recall any "false negatives" where a minibot climbed the pole, but didn't result in a successful trigger. Then again, I think there were only a couple minibots being successfully deployed at the scrimmage and these were still > 3 seconds in climb time.

At week one, in order to remedy the problem with false positives, the FMS software was changed (at least at GSR) so that a "trigger" would only occur when 8 consecutive positive samples were detected, with the samples still occuring at a 20ms rate. This FMS change effectively required minibots to hold at least one of the trigger limit switches closed for approximately 150ms. This change eliminated false positives from robots bumping into the base of the towers, and worked fine for slow minibots, but fast minibots were then having trouble hitting the trigger for LONG enough. On Thursday, our minibot was one of the ones which was regularly smashing into the top of the tower (with plenty of Newtons) but which was also not holding the switches closed long enough to result in a "trigger." Team 40 had a similarly quick minibot and was seeing the same problem.

We started adding a mechanical "impact absorber" to the top of our minibot in order to have it remain in contact with the switch plate a little longer, but this had two problems -- it didn't always extend the contact long enough, and sometimes failed to activate our off switch.

In the last match on Friday (a replay of Match 11), we unintentionally found a sure-fire solution to the problem of not contacting the tower for long enough (simply leave the motors on) as shown in the photo below:



(Separate photo discussion thread at http://www.chiefdelphi.com/forums/sh...ad.php?t=93430 )

However, our team budget isn't sufficient to afford cooking thermal protection wires and motors in every match, so we needed to come up with a different solution! We ended up increasing the reliability of our off-switch a little, but were still at the edge of triggering / not-triggering the FMS limit switches for long enough. Some matches it would work, and others it would not. I can only presume our contact time was very close to the required threshold.

In Week Two, it's widely known that FIRST made mechanical changes to the trigger assemblies. I'm curious as to whether or not they also changed the needed "contact time". (Maybe to the 75ms described earlier in this thread?) I do think that once a "contact time" is determined by FIRST, it would be helpful to release the information to teams.

That said, I'm still concerned that really fast minibots may not hold the trigger plate up for long enough to result in a positive trigger. It sounds to me that everything worked great at some regionals (Kettering and Pittsburgh have reported that) while other regionals may not have had as much success (San Diego?) This sounds to me that the problem may not yet be completely solved.

I'm curious to see what happens in Week Three regionals and hope that FIRST and teams continue to get this worked out. 1519 doesn't compete again until week Five.

I do know that with ever-faster minibots and deployment systems, anything other than automated scoring (except maybe official video replay) will have a hard time distinguishing between four minibots that all hit the top of the tower with between 9 and 8 seconds remaining in the match! At the Week One Granite State Regional, Finals-2 was determined by the minibot race, (see http://www.chiefdelphi.com/forums/sh...ad.php?t=93314 ) where all 4 minibots hit the top with between 8 and 6 seconds remaining on the clock. Not all of the minibots activated the trigger. The referees manually made the correct on-field call, but there was a fair bit of debate about whether or not they had. Counting on the referees to always be the adjudicators puts them in a really tough spot, so I hope that the automatic triggering system can be made to work reliably without having to pose major additional constraints on teams (such as requiring them to hold the trigger plate up for a long time.)

However, since there presumably is some sort of "contact time" required to have a successful trigger recorded, it is very important (as Brandon mentions) to have teams know what that time is in order to be able to adapt their minibots to satisfy the requirement.

Re: Team Update #18
 

This is the problem exactly. An engineering specification of what constitutes the act of TRIGGERing the tower has not been provided beyond that it takes 2-4 Newtons of force, and unspecified magic happens in the FMS to determine if it is TRIGGERed.

To the best of my knowledge, the manual or arena did not provide any specifcation as to how the tower switches are being sampled, or what they're connected to. I think it's fair enough to say we don't care about the speed of the electrons in the wires, but beyond that, whatever is happening post-switches could make a difference in the design, or in who wins.

For this sort of thing, 20ms is a ridiculously long sample time, and to require 8 consecutive samples at that slow of a rate is just absurd. If that's what it takes to prevent hostbot shakes from triggering it, it needs a redesign. Did FIRST seriously not think teams would build minibots that would bounce off the top in less than 1/10 second?

It was never specified for what duration the force must be applied.

I'd like to see a specification that says something like:

The TOWER is considered TRIGGERed when the switches, connected through _________ to a ________ controller, running code available for download from _____, cause the ____ variable to become true.

Re: Team Update #18
 

In Florida, it appeared the vast majority of races resulted in the towers triggering properly, whether the minibot was slow or fast (and Florida had several sub-1.5 second minibots).

However, I do remember a couple of specific instances where the tower was not triggered for one reason or another (but not the teams involved - all I know is it wasn't us!).

Re: Team Update #18
 

At Lake Superior, one of the FTAA thought of this solution as well. However, it was not implemented because it adds to the weight needed to push the plate up. I believe it was Bill Miller himself who said the FIRST folks thought of your idea, but realized the issue.

For the record, with the exception of issues across the entire field in the second finals match, I did not know of any issues with the towers at Lake Superior with the exception for one team that initially was hitting the bolt heads (they made a tiny modification to fix the issue). That said, the minibots were used by under half of the teams.

Re: Team Update #18
 

By this logic, should the "false positives" from week 0 and thursday/friday in week 1 have counted so long as they occured in the last 10 seconds of a match? Should slamming your minibot into the tower hard enough to trigger the target count as winning the minibot race, even if your minibot never even leaves the hostbot?

Re: Team Update #18
 

Trigger is listed as the plate being pushed.

Re: Team Update #18
 

So........... were does it state HOW the plate must be pushed? To Seans point, stating that it merely needs to be triggered is ignoring the intent of the rule....To determine the WINNER, AND THE SUCCESSIVE PLACES, of the minibot race.

Re: Team Update #18
 

Found the rule G46 the minibot may only be used to climb the pole.

Re: Team Update #18
 

This change would probably have unintended consequences. The bottom plate would likely be more susceptible to jamming. The slightest tilt could bind the threaded bolts in the holes in the upper plate.

Re: Team Update #18
 

In retrospect, I think a better trigger design would have been to have a stationary aluminum lower target plate, insulated from the pipe, and specify that TRIGGERING requires completing a circuit by connecting the pole to the plate with some electrical conducting material in your MINIBOT. Nothing would need to move, you just have to electrically connect the two. This would have the downside of sidestepping the engineering tradeoffs surrounding speed and weight and time to reverse power, making it a simpler (but more well defined) challenge.

John
FRC Team 2530 "Inconceivable"
Mentor, Inspector, Drive coach

Re: Team Update #18
 

358 didn't trigger their pole at WPI despite clearly causing the polycarbonate to deflect. I will try and get our video.

Other than them, few had any problems at WPI

Re: Team Update #18
 

With respect to the act of triggering, here are some cases based on the way the rule is constructed in the manual:

1. Hit the tower base, tripping the switch: false positive
2. Push on the plate, tripping the switch and causing FMS to register it: true positive¹
3. Push on the plate, tripping the switch only momentarily (but long enough to send a signal), and the FMS misses or ignores it: false negative²
4. Push on the plate, tripping the switch and causing FMS to receive the signal, but a bug prevents the FMS from registering it: false negative³
5. Push on the plate with 100 N, bending it visibly, causing the tower to sway, emitting magic smoke, but failing to trip the switch: true negative⁴
6. Minibot reaches the height of the plate, but FMS doesn't register it, so referee grants it: educated guess (could be either true positive of false positive, but the ref didn't have anything to do with that fact)

Some of these are quite perverse. I've left out field faults, but in some of the above situations, they're an additional complication that can perhaps restore some equity, if identified properly. (If replaying the match suits you.) I've also left out GDC intent—because although the high-level intent is clear, they have offered no substantial guidance about the actual sequence of events they had in mind for triggering the tower.

If you think this is crazy, don't blame me. I didn't design the game that way.

¹ Which won't count toward the race if it wasn't the minibot doing the pressing!
² The rules have no provision for a minimum duration. If the switch is tripped, an ideal system would not wait.
³ It's basically impossible to identify this false negative if the FMS doesn't throw an error code or something.
⁴ The force isn't part of the determination of triggering. And since sending the FMS a signal is an integral part of the act of triggering, if the sensor doesn't work right, you didn't trigger it. Doesn't that suck?

Re: Team Update #18
 

You missed the point.

Besides this states nothing about HOW the PLATE gets pushed only about what may climb the pole. There are many forces that can 'PUSH' the plate without actually climbing the pole or even contacting the plate at all.

In case you have not figured out my point, I will clarify: To differentiate between TRIGGERING first and WINNING the race is lawyering the rules as the obvious intent is to determine who is first, second, third and fourth and assign a point value to represent each place.

If we lose a match because the other alliance scored more points than us. I can accept that and applaud the victors.

If we lose a match because our alliance partner goes into the opposing alliances scoring zone contacting a robot incurring a red card. I can accept that and commend the refs for making the correct call.

But if we lose a match because the field did not operate as intended or described in the user manual as interpreted by the TEAMS, FIRSTs customers, using a minibot that was built to operate under said parameters....This I cannot accept and will not accept and will result in a student standing in the little ? box at the end of the match every time it happens.

If TRIGGERING requires some amount of debounce time to register, or something greater than 4 Newtons, or Coke turning into Pepsi, this should be CLEARLY published in one of the many user manuals put out by FIRST.

Re: Team Update #18
 

Only the minibot is allowed to trigger the plate and be awraded points and the minibot is only allowed to climb the pole so only the minibot is allowed to climb the pole to trigger the plate and scores points according to the race's results. Is this not the intent of the rule and the wording of it? Why can a flawed field not be accepted as possibly existing? Week one after all usually has delays from fixing some electronic errors. I, myself, got frustrated in week 1 trying to fix why the robot sat still for 2 qualification matches when the drive-team reports they have communication, we already tested in the pits, and it was working earlier.

Humans only have so much insight before forgetting something. The GDC might have thought saying 4N of force acting on the trigger plate was enough but apparently it did not happen so. I cannot say anything on what they should have or should not done.

Re: Team Update #18
 

Using the nominal dimensions on the field drawings for the pole OD, the threaded bolts, and the hole diameters and location in the polycarbonate plate, plus the apparent location of the sensors, it appears that if the plate is lifted off-center so that it pivots on the bolts it will reach an interference condition with the bolt threads and the pole before it travels 1/4" at the switch. FWIW.

Re: Team Update #18
 

Simple solution: Use camera backup, officaly fed into the field system, and read post match by a scoring personel. You could set cameras up on top of the alliance station walls, or pretty much anywhere as long as they have a clear field of view.

Re: Team Update #18
 

At week 1, with one sample, "force of 2-4N" was a complete rule.

If an X sampling time requirement is added to a trigger event and not reflected in a rule update: then FIRST is not being completely open and honest.

Some teams will end up with more access to more information than other teams.
I didn't know sampling was added. All that was officially reported was it was being fixed to prevent false triggers from robot collisions.

Some teams found out some of the sampling changes- was any of the that information given outside the Q&A?
(I could not find any discussion of sampling on FIRST Q&A)

Re: Team Update #18
 

[EDIT] Originally referenced a post later removed by author later, so I wont quote that, but I still think a post about attitude is generally relevant, so I will leave the rest even though it is now somewhat out of context.

I understand the frustration of losing a match because of something that you think is out of your control. Back when I was driving in HS, I felt the same way. As a volunteer, I can tell you it gets pretty old pretty fast to have teams getting in your face and giving you an attitude about these types of issues. I know it sucks to lose matches, but please remember the greater purpose we are here for and how negative attitudes affect that.

So even if you can prove that something unfair happened, please lets all keep a calm and professional composure and remember our true greater purpose here. Let's debate issues, but in a civil and professional manner. I am not saying that this conversation has turned into this, but what type of example is being set for the students if after a match the minibot doesn't trigger and you start complaining about FIRST and the field staff to your students.

Re: Team Update #18
 

NO IT DOES NOT. From looking at the way that these are designed at the Kettering District, there are 3 trigger switches, they are connected in series!

Graphical Representation:

___________ (Power in)
.................|
................[ ] (Sensor 1)
.................|
................[ ] (Sensor 2)
.................|
................[ ] (Sensor 3)
.................|
__________| (Reading out)

This means that all three switches must activate in order to trigger the tower. What I noticed with most of the fast minibots is that they actually hit the plate so hard that it wouldn't go up horizontally, thus not triggering all three sensors. We did have one minibot that I loved that was the slowest one there (wish I knew what team it was), BUT because it took more time to make it to the top it triggered the tower every time. Just for reference it came down as soon as it hit, just it did both in a slower manner than say 33's or 51's which were super fast.

Also another note for the fast minibots. When you go up so fast that you hit the plat and skew it from horizontal you actually bind it against the threads of the bolts holding it together. This means the plate won't move past a certain point, which just may be before the trigger point.

Re: Team Update #18
 

They look like they are in series, but I believe they act in parallel. Check out attachment. I helped make the tower mods and this is how I remember it working.

If any of the contacts are closed, the whole switch is closed.

Please correct if wrong.

Re: Team Update #18
 

Two things here:

1. The GDC has said in the Q&A that only one switch needed to be triggered. If they were wired in series they must have been wired normally closed.

2. This is somewhat irrelevant as the microswitches were replaced in the Week 2 retrofit kit for the towers.

Re: Team Update #18
 

So...impacts within 2" of the pole (which is where every one of the "fast" minibots that occasionally didn't trigger hit) are less likely to lift the plate in an exaggerated off-centered manner right? This suggests an off-centered lift isn't the culprit in those cases in my mind.

Re: Team Update #18
 

It would be great if the trigger design itself provided whatever dwell was necessary for the system sample rate to detect, was not sensitive to bumping the tower, did not matter where it was contacted, did not have any bolts or obstructions that kept it from working every time, and required only the specified force with no other mystery requirements.

Such as:

Re: Team Update #18
 

I don't follow your logic.

Re: Team Update #18
 

I am well aware of the greater purpose here....are you? It's to inspire. It is not inspiring to work as part of a team, to inspire others to strive for excellence and success only to have that under minded by a poorly documented field condition that changes the outcome. As far as unprofessional and uncalm at what point did you think my post was any of those things?

You may want to consider these points before you appoint yourself mediator in a battle that has not even happened yet.

Then what are you saying?

I'll tell you what, when and if it happens to your team you can pretend it did not affect the outcome and then later face the disappointing faces your student members who worked so hard on solving a problem only to have the question change after answering it correctly. Oh if first can't find 4 dudes with a button I know three that would be happy to help with this problem.

Re: Team Update #18
 

The simple answer is: at no point. :P

I wasn't referencing your post. It was a different one where the author deleted after reconsidering its GPness. Without that post for context, I think mine seems overdramatic.

The intention of the post was not really meant to chastise a single individual or set of individuals, but to remove some of the tension in the air, which seemed to be coming up after the now deleted post. So if it came off that way, I apologize, like I said, wasn't the intent.

Re: Team Update #18
 

Given the amount of play/spacing between the floating plate and the bolts as well as the pole itself as you referenced, wouldn't a push on one side far out at the perimeter cause more of a "tilting" effect than a push near the center of the plate?

Re: Team Update #18
 

I for one am on the bandwagon of wanting a final official specification from FIRST. I want to know exactly the force I'm expected to exert, for exactly how long, and exactly how clean the signal needs to be. I want to know what kind of sample rates, sensor wiring, and hysteresis is in place here. FIRST owes us that.

Before anyone jumps on me for blaming FIRST, I want to make it clear that I'm not mad at them. They gave us a very vague specification, we designed to it, we did our best, and it appears we have fallen short.

FIRST also designed to it, they designed a system to react to that vague specification, it seems they also have fallen short. They're now taking steps, within reasonable bounds, to correct that. I agree it's not wonderful, and it is unfortunate that teams in prior events are not going to benefit from this system, but I think we can all agree we'd rather improve it, then have everyone suffer in the name of fairness, especially on a playing field that will never be entirely level anyway.

Also, I agree with the people here that are concerned the system still isn't reliable, my inner engineers hunch is telling me it's not going to work as well as they want, and I don't agree with their approach of "We fixed it, trust us, and deal with it.".

But wait! I hold the teams responsible as well! We were given a vague specification, and everyone made their own interpretation of it, and many of us were wrong, and this is our mistake. Questions should have been asked weeks ago, more research done by teams, we all dropped the ball. I'm not saying people should assume failure, or injustice, but just one team asking FIRST for more information could have made a world of difference.

As I said before, I'm glad FIRST is stepping up and trying to fix their foul-up, now it's our turn to return that professionalism, ask questions and see what we have to work with, and do our best to meet the most accurate specification we can wrangle out of them.

Matt

Re: Team Update #18
 

I know this has been suggested already, but I think the right place to pose questions is directly to the Q&A:

http://forums.usfirst.org/forumdisplay.php?f=1465

You need to have the team leader account to post there, but I am sure that FIRST will be more than receptive to answer all the questions posed here. If people do get an answer to some of the common questions, can they please post them here as well?

The main questions that seem to need answering is:

How long must the contacts be connected for FMS to trigger / what other technical constraints of the triggering system should be kept in mind by the teams?

I do not have an account for this, otherwise I would pose the question myself. I do think teams have full right to ask these questions though.

Re: Team Update #18
 

Thank you Eric, and Ether for your analysis. I was starting to doubt my eyes and memory. I remember when the refs tested the plate with a stick at Kettering, the first couple of pushes bound the plate.

As one of the teams with the light, fast, tiny minibots, here's hoping the new solution works.

Re: Team Update #18
 

All else being equal it would seem reasonable to suppose that. But there are other dynamic factors at play whose effect on jamming due to tilting is difficult to quantify.

Re: Team Update #18
 

Questions were asked. Here's one:http://forums.usfirst.org/showthread.php?t=16174

The answers were vague. We didn't drop the ball. We built a pole, with lexan plates, three limit switches & timer. Worked 100% with our minibot during development.

At NY, our minibot triggered the pole most of the time, pole didn't trigger once, but it was counted. I can only hope they are all counted at our next competition in DC.

If a time specification has been introduced, that has changed the specs and the game. We expected and designed to "Only one limit switch needs to be actuated" as per the Q&A Jan 16th.

Re: Team Update #18
 

I have submitted the following question to the FIRST Forum Q&A:

"With any electro-mechanical contact closure that is sensed by a programmable control system, there is both a force component required to perform the closure, and a time/dwell component for the control system to register the closure. The Competition Manual provided the force component necessary to activate the minibot trigger contacts, but did not provide the time/dwell required for this contact to register with the FMS. What is the minimum length of time that the specified force (2N-4N) must be applied to the trigger plate in order to be recorded/registered by the FMS?"

Re: Team Update #18
 

Just for fun (for those who are so inclined):

A 3 pound minibot is traveling up a pole at 7 feet per second.

It is depowered and a downward force of 4 Newtons (plus gravity) is immediately applied to it.

1) Assuming no friction, how far will the robot continue to rise until it reverses direction?

2) Instead of 4 Newtons, how much (constant) force would need to be applied to limit the rise to 1/4" ?


Note: The purpose of this exercise is to show that the force exerted on such a minibot by the plate assembly (and thus the force exerted by the minibot on the plate assembly) far exceeds 4 Newtons.

Re: Team Update #18
 

It looks like we're making progress on figuring this out.

Re: Team Update #18
 

1. 0.586 ft.

2. 474 N

Re: Team Update #18
 

Yup.

Re: Team Update #18
 

WooHooo! I've still got it!

Re: Team Update #18
 

to trip it, you have to be traveling ~.39 meters per second or ~1.28 fps for a 1 kilogram minibot using EBE assuming no friction, the minibot is not back driving, there is no rotational inertia, and pretty much everything else.

pretty much if you're not going that fast you are not winning anyways (~15 sec with more rounding and constant acceleration)

Re: Team Update #18
 

I doubt you would ever successfully trigger the switch with those numbers.

Please explain your reasoning and show your calculation.

Re: Team Update #18
 

I'm not so sure it's that simple Ether. Such a simple model isn't explaining what's being seen on the field. Additionally, why a 1/4" stop? Why not 3/4", which may be just as valid a distance that prevents the sensors from triggering (I'm assuming the plates are ~1" apart, which may be wrong since I still haven't examined the field drawings).

Additionally, how does your model take into account any mechanical (dis)advantage that plate exerts due to binding on the bolts opposite the minibot's impact point?

Re: Team Update #18
 

I hope this all gets resolved in a way that satisfies everyone. BUT this is a good life lesson for aspiring engineers. We have to respond to technical specifications all the time that are vague (where our potential customer knows much less about the problem/solution domain than we do). On some level, it is our responsibility to request clarification BEFORE designing/building a solution.

And BTW Linux == Embedded, my company has put it on several satellites and on some tiny tiny platforms. Linux does soft real-time quite well these days and is closing in on hard real-time performance.

HTH

Re: Team Update #18
 

I think the point is that that is a lot of force. If it really requires 2-4 newtons to trigger the plate, 474 newtons should definitely trigger the plate. It obviously does not always do this, so there are other issues at play like you said.

474 newtons is the equivalent force of an FLLer (~100 pounds) standing on the plate.

Re: Team Update #18
 

... or Karthik.

Sorry, I couldn't resist.

Re: Team Update #18
 

It was never intended to model or explain what's being seen on the field. Please re-read the disclaimer at the bottom of my original post. All it shows it that minibots which DO successfully trigger the tower are exerting way more than 4 Newtons.

AFAIK, we have no official drawing or specification of the switch mechanism, but colt527 provided a sketch as an attachment to this post which shows 1/4" travel required to trip the switch.


It doesn't, and wasn't intended to.

Re: Team Update #18
 

Precisely. I couldn't have said it better myself. In fact, I didn't :-)

Re: Team Update #18
 

The teams, of course, pay FIRST to compete. In that sense the teams are customers. But FIRST is largely a set of volunteers, at least the staff at the regional events. If we think of this game as a simulated engineering exercise, FIRST is actually the customer (having provided a specification).

Our team, like most, did not query the "customer" about a vague requirement. This is totally "our bad" though one hopes FIRST does not intentionally put out vague specs. Our first heavy-ish 4 second minibot triggered the sensors every time in week 1 at The Alamo but our evolving optimized minibot design is now gonna be a little stronger and stay in contact with the plate a little longer than originally designed.

Re: Team Update #18
 

I think Cory's point is that FIRST shouldn't be let "off the hook" every time they do something at the expense of teams just because it's a volunteer organization. We do still pay to compete, after all.

Re: Team Update #18
 

Sorry to be pedantic, but...

You're basically saying that it's OK to imply an assumption for the calculation and then ignore the assumption for the conclusions of overall system characterization. You did this with your Mecanum analysis a few months ago as well.

Which would probably be a great broad stroke to paint, yet the whiners haven't proposed a solution. 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? The referees already made concessions to manually score the towers even though it wasn't in the rules.

Honestly, the only concession FIRST can make at this point is to give us dedicated MINIBOT time on Thursday. 4 teams at a time can have their MINIBOTs climb, uninhibited, yet with the real field's triggering/scoring system. If it's dedicated minibot time, then every team should be able to test their ascent and triggering 4-5 times in an hour or two.

Re: Team Update #18
 

This is a good lesson for the students and for mentors that do not typically address similar challenges at work. Think more like an engineer that owns the company or an engineer helping to form a response to a proposal. Taking a risk (being able to satisfy) a vague requirement from a customer is NOT a good idea. You very well might not get paid and it does not matter if one is correct or not. In this case, the customer (FIRST) supplied a vague spec but did provide a compliance test.

If the specs are not written clearly, it is ALSO our responsibility to request clarification or we risk NOT getting paid (or tripping the sensor).

Re: Team Update #18
 

Proximity sensors and light sensors are two common proposed solutions.

Personally, I don't see what's wrong with a photo finish here. Yes, "instant replay" is a dirty word, but it would clearly be the best.

Re: Team Update #18
 

Could you be a bit more specific? What "implied assumption" are you referring to?

The only assumptions used in the calculation were to ignore friction (which was explicit, not implied) and to ignore additional stored kinetic energy (rotational). These tend to cancel each other out. Over very short distances (such as 1/4"), the stored rotational KE easily overcomes friction, so it's actually a conservative assumption. You can demonstrate this for yourself, if you like: with the wheels raised, power your minibot with 12V and then remove the power. Observe how much the wheels turn after the power is removed.

If you have questions about the mecanum analysis I would be glad to discuss those, but not in this thread.

Re: Team Update #18
 

1.) Proximity sensors may work, yet are subject to calibration and vibration for a single data point. If you're using the difference of two data points, you still have to either increase sampling rate or # of sample to prevent false positives. Thus, changing to proximity sensors could pose the same issues/risks of the current system, which means there's no reason to change to proximity sensors.

2.) Light sensors are subject to noise and calibration. These may work better than proximity sensors since the noise is most likely easy to isolate, yet the tolerances in spacing would have to be tight to ensure even the slightest movement of the plate triggers the sensor. The designers simply may not have the time to implement something so quickly across all of the regional events for this week or even next week. This one seems the most feasible to me from a technical perspective though.

3.) Any instant replay sets a dangerous precedent. There will always be those who make assumptions based upon what's happened before, regardless of what's stated in the manual and regardless of what's talked about at driver meetings. I think FIRST just doesn't want to go there unless there's more thought put into it. That desire is reasonable in the longer term just to simply avoid stress during competition. Yet assuming a photo finish for 1 specific aspect of every game could probably also open up the types of activities we'd perform in future games. So I'm with you on this one ... subject to that caveat.

Re: Team Update #18
 

Alright, I did say implied and you were explicit about the friction. Yet it was still ignored in the conclusion without any explanation in the original posts. Ok, so there's the explanation, which I still don't think allows for a valid conclusion based upon the calculation. Your latest statement makes the implied assumption that the unloaded motors act identical to the real system during impact. Impact forces induce shock into the gearing which momentarily increases the friction in the gearing/bushings with a positive correlation to the amount of force applied to the plate. Impact forces induce friction in the bolts on the triggering mechanism, which may be bind on the plate if the impact causes a torque moement. Thus it may take 474 newtons at a specific instance in time to slow a minibot down without taking friction into account -- yet until we characterize the friction in the system we're making a dangerous* conclusion that "more than enough force is applied to moving the plate".

*dangerous because the process of coming to the conclusions would then be acceptable to use elsewhere.

I can't characterize the friction with numbers or equations, which I will concede. Interestingly, that's the very specific reason we [industry] do shock testing for our real world complex systems. The equations simply don't match the results of the real implementation.

Re: Team Update #18
 

I'm counting the days down until Waterloo. Get your popcorn ready.

Re: Team Update #18
 

I think the calculation allows a valid conclusion. Even if the gearbox were to completely lock up, the only effect it would have for purposes of this calculation would be the resulting friction between the (locked) wheels and the pole. Compared to 474 Newtons, such friction can reasonably be ignored for purposes of the conclusion, which is simply that a 3lb minibot traveling at 7fps which is decelerated to zero speed in 1/4" is exerting much more than 4 Newtons on the plate.

Re: Team Update #18
 

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?

Re: Team Update #18
 

...I've been chastised for championing this point for years.

So the refs, judges, and staff at the events are VOLUNTEERS. According to the people who don't see it my way, they should be forgiven any and all shortcomings, because they're VOLUNTEERS. Everyone claims that a cornerstone of the FIRST program is the tenet of GRACIOUS PROFESSIONALISM. To me, doing your job poorly, or worse, outright incorrectly (as in 2008 SVR Finals Match 2), is UNPROFESSIONAL. Not only that, but each and every team has mentors. All of whom are, themselves, VOLUNTEERS. The mentors are expected to know and follow the rules, because if they don't, and their teams robot doesn't comply with the rules, they don't get to play.

This isn't even what this argument is about, though. FIRST HQ is NOT run by volunteers. Many of the staff at FIRST HQ take a salary, paid for by our entry fees, and the sponsorships provided by industry. They are being paid to provide the teams with a product, a competition.

While I might be able to be convinced to forgive the shortcomings of a ref based on the "volunteer" argument, I will never be able to be convinced to forgive FIRST HQ for shamelessly doing things at the expense of their customers, the teams.

Re: Team Update #18
 

Does a standard scale, such as the ones used to inspect the robots at competition, give us the weight or mass of the robot? In other words, is the number we see equal to mass*[accel due to gravity] or equal to only mass?

Using a direct weight-equals-mass calculation, I get 0.586 feet stopping distance and 488N for stopping @ 1/4".

Dividing by the acceleration of gravity, I get a stopping distance of 0.060 feet (~3/4") and ~50N to stopping @ 1/4".

Re: Team Update #18
 

The scale measures force.

If you measure something on Earth, then you can use that force to calculate the mass, as follows: kilograms = pounds * 0.4535924

If you use the same scale on the Moon, you will get a force reading about 1/6 of what you got on Earth, even though the mass is the same.

Re: Team Update #18
 

In imperial units, a scale measuring pounds gives the weight of an object, not the mass. The imperial unit of mass is slugs, which is equivelent to approx. 32 lb-mass. When doing Newtonian calculations in imperial units, you must use the units slugs, lb-force, feet, and seconds. This yields the results you mentioned first, .586 ft and ~480 N (107 lbs).

Re: Team Update #18
 

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

Re: Team Update #18
 

I am paid a coaching stipend, so technically I am not a volunteer.

(I was asked to itemize it out this year because we're doing budget negotiations and it looks like the admins are trying to cut compensation for extracurricular advisors, so I did the math and discovered that when it comes down to brass tacks I get paid about $0.07/hour if we keep it to only one summer project, but still...)

Re: Team Update #18
 

@pfreivald: ok, so maybe not ALL the mentors on FRC teams are 100% volunteers, but my point is still valid since you're in the overwhelming minority.

Re: Team Update #18
 

I EARN that seven cents an hour, dag-nabbit!

(I hope you realize I was just playing with you.)

Re: Team Update #18
 

For those 7 cents I expected more from you!

Just kidding. :)


The biggest problem I see with a 'photo finish' is something still needs to trip the camera. Taking constant video of the poles at a frame rate of 29.97fps may work, but close minibots will still be very close there, it may be hard to determine accurately. I'm not saying it isn't possible, but it's certainly something to think about.

Logically a computer system can only sense a condition that exists for a finite period of time related to the sampling rate. Since no specification was given regarding how long the force must be sustained, nor the sampling configuration of the system, it was an incomplete specification. Also, the force specification given appeared to be a rough estimate of the minimum required, not a clear definition of what we had to attain. I believe, as other posters have stated, you're hung up on that number.

Real engineering specifications are pretty explicit, I'm working on a project here at work that has an entire page explaining that the power LED must turn on when I apply power to the system. It even states how fast the LED must turn on when power is applied. The 'spec' we got from FIRST, if you can even call it that, was most definitely incomplete, and yes we should have foreseen complications from a lack of real world test data. I stand by my original argument, both the teams and FIRST are responsible for this.

Matt

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.

Re: Team Update #18
 

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.

Re: Team Update #18
 

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.

Re: Team Update #18
 

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

Re: Team Update #18
 

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

Re: Team Update #18
 

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