Scoring 2013, I can do better than that!
 

A Frisbee has a a defined weight, so weighing them is one strategy for counting how many in a goal. A strain sensor with +/- 300 grams is a great choice, settlement time may be an issue.

But scoring does seem to be a problem. And since HindSight (tm) is always 100% there may be better ways.

So how would you have scored?

As a VEX and Arduino guy, I would done an pair of Sonar Senors. Mounted on each side of the top opening pointing down and across to cover the opening. Two sensors triggered = score.

But since the Sonar needs a pulse (so there is a read/write cycle), I would go with a short distance IR sensor, then I can get a constant read.

What would have been your plan?

Re: Scoring 2013, I can do better than that!
 

I would stick with weight, but use noise filtering and comparative score tests. Count score at the end of autonomous, then zero the scale.

I have a feeling frisbees are actually mostly the same weights, so I think weighing can be done.

Re: Scoring 2013, I can do better than that!
 

I would have planned for a streamlined human-based solution from the start. Something along the lines of how it was done in 2009, with handheld boxes with tactile buttons for real-time, and manual counting at the end of the match when the goals are emptied.

When was the last time we had an automated solution that reliably handled large quantities of game pieces being scored in parallel? (Answer: it's never.)

Re: Scoring 2013, I can do better than that!
 

Yeah, I was just going to point to 2006 as an example where the automated scoring system caused a ton of problems. It's hard to create a flawless system and this is the type of situation where it needs to be flawless. In 2006, I remember there were tons of issues with the scoring when the goals got clogged by the onslaught of balls and they had to implement a human-based system then.

Re: Scoring 2013, I can do better than that!
 

There were two issues in 2006, one was the goal getting clogged and needing the pokey stick to unjam, and the other was inaccurate sensors, especially in the low goal that tried to detect balls in parallel with a camera. They resorted to guys with counters watching each goal. The sensors had a tendency to miscount and the RTS couldn't be trusted at all.

In 2010 and 2012 they used low numbers of balls and single-file scoring to improve the system, although they still had their issues (including the infamous bounce-back DOGMA penalties in 2010).

2009 was human-counted from the start, but was horribly inaccurate because humans just couldn't estimate it as well as they needed to, or count fast enough for the large loads that got dumped in trailers.

Counting discs as they enter the goal is an issue because a) it's very hard to ensure you don't get a double-count and b) discs that don't stay in the goals aren't counted, and a pass-through sensor can't account for that.

At least this year they can recount the discs after the match...

Re: Scoring 2013, I can do better than that!
 

That's a good point. Pro sports that have automated scoring only have one ball (eg. hockey, basketball, etc.)

Re: Scoring 2013, I can do better than that!
 

I don't even think those sports have auto scoring. It sure take a long time from the score for my TV to update.

Re: Scoring 2013, I can do better than that!
 

I know for a fact hockey and basketball use sensors and cameras to count.

Re: Scoring 2013, I can do better than that!
 

They're not automated, though. If something is unsure to the referees in real-time, they go back and look at the tape. Why FIRST doesn't allow the same thing, who knows...

Re: Scoring 2013, I can do better than that!
 

Similarly to 2011, I think they need to have humans manually putting the score on a touchscreen interface at opposite ends of the field. Yes, there could end up being errors, but I think it'd be a lot better than what we have now...

Re: Scoring 2013, I can do better than that!
 

Hockey does not use an automated system. There is an official sitting behind the goal that turns on a light when he sees the puck go in. And the on ice official will make the call as he sees it.
Basketball scoring also isn't automated, how would a sensor know if it was a 3 or 2 point shot? the ref signals the number of points and a human increments the score.

The only sport that is close to automated, we could say is FIFA. This year they're going to is goal line technology that will alert the official's wrist watch when the ball crosses the line.

I'm not making any excuses for this years FIRST system but hardly any professorial sports are automated.

Re: Scoring 2013, I can do better than that!
 

I'd funnel the frisbees into slots and trip a light beam (and let them drop into bins). Give a couple engineers a day and some materials and they could design a shape that prevents jams.

Re: Scoring 2013, I can do better than that!
 

This is a robotics competition. Of course it should aspire to have autonomous scoring. They can't look at the engineering challenge of autonomous scoring and say "nah, that's too complicated. Let's just count things by hand". Not after what they asked us to do.

Re: Scoring 2013, I can do better than that!
 

If manual counting works better I certainly hope they would.

Re: Scoring 2013, I can do better than that!
 

I started running through multiple ways to count the score in realtime automatically.

Short version, the current version (weight) is the simplest method for both transport and programming. However, as noted, there is a drawback of settle time and if there's a bit of a force applied.

Now, the 2 short-range sensors with both triggered = score is next simplest in execution, at least for transport. However, instead of both triggered = score, I would set it up to that 1 THEN 2 is a score. You can do that--in fact, it's how balls were counted in 2010 and 2012--and it will be pretty accurate. You can also set it to descore if 2 THEN 1 happens, to account for bounce-out (note that a trigger should be both on and off). But you do have to line the whole goal entrance to some extent.

The toughest method to implement would be an inline counter. Not because it's the hardest to program--it's easier than the above solution--but because you have to get incoming frisbees into line, when they're bouncing and sliding around in there. And that takes space and weight that may or may not be available. Slope (to get them to where you want them) can take a lot of material--and then you have to build in something to stop automode scoring at the end of automode, after a semi-reasonable delay to allow for the settling time.