For our scouting app this year, we have decided to try counting only the number of cycles completed rather than trying to count every piece of fuel that is scored or missed by a team. Using TBA data for total goals scored per alliance, pit scouting data for maximum capacity for high/low fuel per cycle, and number of cycles per match from pit scouting, I have devised an algorithm that will estimate the number of fuel scored by a given team.
Basically, the algorithm estimates the maximum amount of fuel shot by the robot by multiplying cycles scored by maximum fuel capacity. Using those numbers and any previous accuracy data, it will estimate the percentage of total goals scored contributed by the team, which is then used to find goals scored, and by extension, accuracy. The formula is designed to become increasingly more accurate as the competition goes on and more accuracy data is accumulated.
This is my first time coming up with such an algorithm, so I would appreciate any feedback or input on how I could improve this formula to make it more accurate. I am planning to test this and other algorithms during our week 1 scouting party, and may post the results and conclusions we get afterwards. If anyone else would like to contribute their early-season data to help improve the calculations, that would also be greatly appreciated.
I just dug around your spreadsheet for a few minutes. Perhaps I missed something (and I apologize if I did) but how do you account for a robot shooting half of its hopper capacity? Even it teams consistently make an attempt to shoot a full hopper they will (probably) try to empty their hopper at the end of the match, which may not be full. you will need to include an ‘approximate robot fullness’ datapoint for each cycle, to be tallied along with that cycle’s approx accuracy.
You can always attempt a least squares approach for extrapolating fuel points scored by a team, (this is a difficult challenge to separate high and low scored fuel this year due to First not providing high and low fuel scores separately).
Good luck in these last few days of build,
Skye Leake
When I first created this spreadsheet I was assuming that robots would always get a full load before shooting it off because it was more efficient that way most of the time. I see your point about unloading whatever’s in the hopper at the end of the match though. However, the reason I didn’t want to add an approximate robot fullness datapoint was because the ball storage for many robots is not always easily visible from the stands, and it adds another area for human error to affect rankings. It is something I will consider adding to our app though, to see how much of an effect error in estimating robot fullness has on the estimations during week 1 competitions.
I am not familiar with regression analysis, since I’m new to this kind of analysis. Are there any resources for specifically applying regression lines to FRC statistics you can point me towards?
I am also fairly certain that TBA provides high and low boiler goals in separate numbers.
This is one of the reasons that we are counting groups of 5 balls as our ball scoring ‘unit’. Low fuel a little more tricky as they will probably have up to ~30balls per second dumped into the boiler. (I am still trying to get a handle on the best way to deal with low boiler dumps)
I would suggest any of the several whitepapers on OPR calculation as a starting point. There seems to be a new one on Chrif Delphi every year.
When I checked the FIRST API all i saw was a ‘getFuelPoints()’ method… so Im not sure of the high and low bouler distinction.
If I run across more info (and when im not using Chief on my phone) ill send you a PM.
From what I’ve seen of the robot teasers so far, counting balls manually, even in groups of 5, looks fairly challenging for the scouter. Add to that the poor visibility from the stands and that our scouts are relatively inexperienced, and I don’t think we can get very accurate data points.
I’m thinking of adding some way to differentiate between full cycles and non-full cycles; we’ll see how that works out week 0/1.
According to FIRST Events API - v2.0 · Apiary the API has a teleopFuelLow and a teleopFuelHigh field. Unless we are talking about different APIs then there should be a distinction between high and low goals.
I’m still looking into regression analysis for fuel scored; while it will probably not be as accurate without actual match/pit scouting data, it will be useful for precompetition analysis.
Our plan is to count cycles and accuracy to calculate the number of fuel scored. We are asking our Scouters to give each team an accuracy score from 0-5 for both high and low. We then take an average of the accuracy scores to get the best value.
To differentiate between full cycles and non-full cycles, we are making the Scouters add 0.5 cycles every time they see a non-full cycle. Although 0.5 isn’t as accurate as we would like, 0.5 is an easy number for the Scouters to work with.
During Pit Scouting, one of the questions we will be asking is fuel capacity. Using the three factors we will be able to find the average number of fuel scored per match.
I think scouting fuel scored is an incredibly tough task. However the benefit is that if you are off by about 10 balls, you are only off by 3 scores. We have been talking about trying to implement a clicker, but I am skeptical that it will work.
I was a student back in 2009, when scouting # of balls scored was similarly difficult, but probably not this difficult. My opinion is that if you are scouting a bot you should pay attention to how many balls they intake before they try to score, and estimate how many of those went in. Over the course of a match you won’t be off by more than 20 even with the rapid fire bots in my opinion.
