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 ™ 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?

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.

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

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.

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…

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

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

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

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…

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…

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.

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.

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.

If manual counting works better I certainly hope they would.

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.

One of the most important engineering principles you can learn is that sometimes, the flashiest, highest-tech solution is not always the best one.

remember discs can go into goals then bounce out

How would you guys prevent the chains from tripping the sensors? Because of the chains “dancing” afterwards, you would need to put them both far to the front or back… the back doesn’t work because some low-velocity frisbees never make it back that far. You could put them both close to the very front, but then you wouldn’t have much spread available.

Also, I’ve seen several points at which multiple frisbees converged to enter the goal at almost exactly the same spot and almost exactly the same time. A laser or ultrasonic sensor would have a very difficult time discerning this.

Also extreme wide-angle shots… you would possibly see a frisbee tripping multiple beams at once.

I think weight, despite its current issues, is still the best way to count frisbees.

I think weighing after auto and then zeroing the scales for tele. Then after the match while emptying the goals they double check the scores with lexan tubes that stack the discs to count them. Weight is the only way I can think of for doing real time scoring but they need some way to double check it with the inaccuracies shown during the week 1 regionals.

One of my early mentors gave me wise words – when designing a system to compile & analyze information, your first design choice should always include consideration of a stack of 3x5 file cards. :smiley: After 30+ years is IT, I’ve yet to find a reason to disagree with him.