Electronic Scouting System, Team 1678

Citrus Circuits presents a whitepaper of their 2013 scouting system,

In a nutshell, the system uses multiple Android tablets used for uploading data, stores data on a central server, and features a native iPhone app for viewing this data in realtime, to be used for strategizing both alliance selections and qualification matches.

Using this system, we managed to win the Central Valley Regional from the position of seed 6, and advanced to Einstein!

We designed the system to be extremely reusable for future years, and look forward to improving and employing it this coming year.

Attached is a brief overview of the system, with enough details to hopefully inspire other teams to create a scouting system of their own.

We welcome any comments and feedback that you may have.

Scouting Whitepaper.pdf (3.14 MB)


Scouting Whitepaper.pdf (3.14 MB)

I like the system. WildStang is working on a similar idea for this season.

Team 11 had a somewhat similar setup, but went direct from Android device to webserver over a protocol we wrote called LipSync.

Would be any chance of you guys open-sourcing any of the backbone? I’m curious to see how you guys stored data on the tablets and Pi in the event of transmit failure.

Thanks for the reply!
One question I have for you: how did you actually get your internet connection?
That was one of our biggest difficulties, because we want our system to be 100% legal…

Would be any chance of you guys open-sourcing any of the backbone? I’m curious to see how you guys stored data on the tablets and Pi in the event of transmit failure.

As of now we are not planning on open-sourcing it, but its certainly possible. It would be at least a few weeks, as right now we are busy preparing for the Powerhouse Pwnage offseason competition.

As to how we stored data on the tablets / Pi in event of transmit failure…
Well, we didn’t implement an awesome, clean looking protocol like you did.
As we had just assembled our Pi solution before Championships, it was fairly crude.
In an event of failing to upload to server, the tablet just saves that match’s data to disk, and a scout can upload failed uploads later, probably using Wifi during lunch. The Pi implements no sort of data storage, but the tablet does wait on a reply from the Pi via USB to assume of successful transmission.

The whole USB / Pi part of the system is what is most subject to change right now… we will almost certainly make big changes to it this season.

Why did you guys use internet? With our team we just set up a local database and had all info transferred from the tablets via Bluetooth.

I like it! Team 20 has been cooking up something similar, but it follows more of a distributed paradigm. I’m excited to see 111’s too!

Did your coaches really like the real-time information? Was it really necessary to do that in real-time, or do you think that it you could achieve similar results with updates every 30 minutes or so?

I love this on so many different levels. Im interested in seeing the code for this and trying this out for myself.

Our initial iteration of the system only stored data on disk on tablets, and then we uploaded later, which certainly worked.

However, we wanted internet access in the stands so we could upload the scouting data directly after each match, rather than have to do batch uploads, say during lunchtime. This let us deliver accurate scouting data to our coaches / driveteam to strategize for qualification matches also.

Realtime data did significantly improve strategizing in qualification matches. Updates every 30 minutes or so probably would have been frequent enough for the data to be useful for qualification matches, but, how do you effectively do a batch upload (legally) every 30 minutes?

If you have 6 tablets, and you need to upload via Wifi, then you need to walk out of the stands, activate someone’s hotspot, connect all the tablets to the hotspot, and finally upload, then go back to the stands. For a not quite legal solution, you would still have to activate a hotspot and connect tablets. This process could easily cause you to miss scouting a match… rather than deal with that, we chose the more difficult problem of suppling constant internet access.

That was our logic, and it worked well in St. Louis, but I think we can use the realtime data a lot more effectively this coming year.

After determining that all of our scouts already owned Android smartphones, we made the call to trust 3G/4G cell networks for the most part and use wifi where available.

Previously we’ve looked into using Bluetooth connections to a laptop hooked into a 3G/4G modem, but decided against that this year since it never became a pressing issue.

In theory we could also run any device as a server (over Bluetooth or NFC if were really hardcore and the devices supported it) for non-internet-connected devices, then have it sync data to our webserver.

That is certainly one of the simplest solutions, I’m glad it worked well for you!
We didn’t have quite that concentration of smartphones on our team, and wanted to keep the system more general, so it would work for future years, and thus not rely on student phones. But, I guess as they become more and more common, its not unreasonable to.

Our team coach call the real time updates the “b— s— detector” during pre match discussions. It was incredibly valuable. Also we were able to focus our strategic scouting with the real time data. We saw a huge difference between the regionals where we had little or no real time updates and Worlds where we had fairly consistent real time updating. (It wasn’t faultless as Donald notes in the paper, but they have a solution.)

One other very important point: I’m the adult mentor who “supervised” this task–but the reality is that all I did was help identify the information to be gathered, the calculations using the collected data and the summary outputs. ALL of the technical software and hardware matters were handled entirely, 100% by student team members. I was simply amazed at their technical prowess of designing, building, debugging and rebuilding the system. To me this is the epitome of the FIRST experience.

I would just like to chime in here as a Team 11 programming mentor.

Will and his fellow students wrote and designed virtually all of the work he’s presenting here.

So far as I know no other mentor or myself produced any of this code.
We just stuck our heads in if requested.

I think this is a fantastic demonstration of what Will, the MORT team and FIRST can achieve as well.
Will stands on the works of Patrick and Nick and Abhi and all those that came before all the way back to 1997.
Everyone making their own unique contribution and paving the way for the next.
I would also like to thank Mount Olive High School and their teachers for giving them the knowledge to safely set their imaginations free.

I think 1997 was perhaps the only year software written mostly by me was central to a FIRST robot.
No I wasn’t a high school student at the time…however someone had to bootstrap the process to get here.

Now I can go play building other parts of the robot with MORT cause Will and Terry have it covered.

Here’s the whitepaper for this year’s version of 1678’s scouting system. We used Bluetooth connections very successfully.

We heard the same feedback from our drive coach. Apparently he used the data we’d collected to prove teams wrong multiple times in regards to the position they should play. Quite amusing.

While I hate to call teams out, there are some instances where you have to, and having the data to back yourself up is life-saving. We used similar updates in paper form that we actually gave to our alliance partners in some situations. The Papers gave statistics about all 6 robots from each alliance.

When it came down to “I want to Score” or “Oh Yeah! We can definetly Truss to our Human Player!” or “Our Auto is 100% Hot goal”…telling someone no is easier when you have the scouting data on hand.