Connecting multiple Bluetooth devices for scouting

[cavalier]

Also, one thing to watch out for with Bluetooth is the connected device limit. From what I've read, connecting 6 devices to one device may not function reliably.

[Connerd]

T4:

Teams may not set up their own 802.11a/b/g/n/ac (2.4GHz or 5GHz) wireless communication (e.g. access points or ad-hoc networks) in the venue.

Not sure how this works with all of the previously mentioned threads on stuff like this.
I should probably ask the question, but does Bluetooth use these, and thereby, is Bluetooth illegal?

[Chris_Ely]

Originally Posted by Connerd

T4:

Not sure how this works with all of the previously mentioned threads on stuff like this.
I should probably ask the question, but does Bluetooth use these, and thereby, is Bluetooth illegal?

This has been discussed in other threads. A quick summery:
Bluetooth follows the 802.15.1 protocol, so would be legal under the rule you quoted. However, some people have said that they were forced to turn their Bluetooth off anyway.

[yash101]

Originally Posted by luckof13

This has been discussed in other threads. A quick summery:
Bluetooth follows the 802.15.1 protocol, so would be legal under the rule you quoted. However, some people have said that they were forced to turn their Bluetooth off anyway.

Just bring ye ol' trusty notepad in case of an emergency!

[hardcopi]

What we do is use a local database and then sync them up later. We can usually get the data pretty quickly, to get around the network rule we will sometimes have someone run out into the parking lot with a hotspot and the tablets and sync it up outside of the no wifi area.

On another note, why 6 tablets this year? We used 6 last year, but this year we are pretty sure we can do it with 2. Except for the autonomous it should be pretty straight forward shouldn't it? (I want to make sure I am not missing something, our first data collection meeting is probably Saturday).

[notmattlythgoe]

For the past few years we've used a collector program that we wrote running on a laptop that searches drives for a specific file, then we plug each of the devices in through USB and the program automatically collects the data for us.

[Dale]

Thanks for everyone's responses. In previous years we've used 3G connected iPad 1s but those connections have severe problems at some venues and especially and Championships where AT&T 3G was completely saturated. Typically we write these programs as web applications so Javascript and Node.

Our software team working on this doesn't have experience writing native Android applications. It's likely too late to learn this cycle. This year we'd like to continue running our competitive analysis system in a browser being served up by a web server, a local one this year.

notmattlythgoe makes an interesting point about using USB and polling for special files on each tablet from a "server". If we can't come up with a cleaner solution that would be a good fallback. Hopefully we can get our Ethernet adapters to work on 4.3.

I was hoping there was some Bluetooth magic that would allow these tablets to connect to a local network over that pipe. If anyone knows of such a thing, let us know!

[Dale]

Oh, and to answer hardcopi (why not just use two tablets), we're looking for the best data we can get on each robot. We'll be tracking things like the number of attempted passes, number of completed passes, number of shots attempted and number successful, subjective data, etc. You might get away with it with two scouts but those would be busy scouts!

[notmattlythgoe]

Originally Posted by Dale

notmattlythgoe makes an interesting point about using USB and polling for special files on each tablet from a "server". If we can't come up with a cleaner solution that would be a good fallback. Hopefully we can get our Ethernet adapters to work on 4.3.

If you'd like I can post our compilation software for your use. It's not the greatest out there and could definitely use some work but it does what it needs to.

[RoboScout]

Hello fellow scouters,

FIRST Team 1073 made the switch to a tablet system in 2012, using up to six Andrdoid tablets to capture the scouting data for pit and match scouting. We have had the tablets sync to a central laptop over bluetooth, where the scouting data is processed and stored in a database. From there, all sorts of reports can be retrieved, including a weighted scoring list of teams that represent our "pick-list". The central laptop provides a web server to serve the reports over HTTP.

The bluetooth sync works great. We generally sync each tablet one at a time to avoid any contention, and have experienced no issues to date with that method. We also use a 3G tablet to upload the collected data to another copy of the central application that is running up in the Amazon Web Services cloud. We did this so that any team member with a smartphone or internet access can view the scouting data in real time from anywhere.

If anyone wants some additional information on how our system works, send me a private message and I'll be happy to provide as much detail as you need. All of our code is available from GitHub, and that may save you some time should you want to get a head start. In fact, our Android tablet application itself is generated from a spreadsheet that defines the attributes that a team wants to collect/measure. We can easily generate a custom application for you with your scouting "sheet" to give you a taste of what the system can do.

KenSt (aka RoboScout)
Mentor - FIRST Team 1073

[Dale]

RoboScout,
Interesting that you connect one tablet at a time. Is that an automated process back on the laptop or is that manual?

It sounds like your front-end is a spreadsheet that your save periodically and retrieve to the central laptop. Do I have that right?

[RoboScout]

No, sorry to confuse you, the front end is an Android application.

In order to minimize the new development year over year, and to allow the students without a software background to build the application, we wrote a code generator to build the Android application. The code generator takes a spreadsheet file as input, and generates the Java application source files from which the application is built. The code generator supports radio buttons, checkboxes, text fields, a custom scoring matrix for the UI.

Why I mentioned the spreadsheet in my post was that you indicated that your team doesn't have much experience with Android development. Perhaps, we could spin a version of the app for you.

And, yes, there is a 'sync' button on the UI that allows a scouter to sync the collected files on demand. We chose that model early on so that we could make sure that each transfer completed successfully. Now, that we have two seasons under our belt with the application, we may shift over to an auto-sync, but simple and reliable is good, too.

[notmattlythgoe]

Originally Posted by RoboScout

No, sorry to confuse you, the front end is an Android application.

In order to minimize the new development year over year, and to allow the students without a software background to build the application, we wrote a code generator to build the Android application. The code generator takes a spreadsheet file as input, and generates the Java application source files from which the application is built. The code generator supports radio buttons, checkboxes, text fields, a custom scoring matrix for the UI.

Why I mentioned the spreadsheet in my post was that you indicated that your team doesn't have much experience with Android development. Perhaps, we could spin a version of the app for you.

And, yes, there is a 'sync' button on the UI that allows a scouter to sync the collected files on demand. We chose that model early on so that we could make sure that each transfer completed successfully. Now, that we have two seasons under our belt with the application, we may shift over to an auto-sync, but simple and reliable is good, too.

I had this same idea for generating the Android UI but we have not had a chance to implement it yet. Now with Tableau as a data analysis source the android app is the only part of our software chain that needs rewritten each year. I'd love to get it to the point that the most we'd have to do is add an implementation for a new type of UI widget if the needs arises.

[Dale]

RoboScout,
Pretty fancy stuff!

I see the development of the scouting application as another important project for the the team to develop, just like building the robot. It's a project full of constraints, pitfalls and opportunities. If we get in a bind, though, we might take you up on your generous offer.

notmattlythgoe,
Thanks for your offer as well. We'll see how far we get on the Ethernet and Bluetooth. If neither pan out, given our skill set, your software might be very handy.

[hardcopi]

Acutally I guess we are using 4 scouts. Just two tablets though. Two data collectors and two spotters who will be an extra set of eyes.

I agree though to our team data is every bit of important (well almost) as the robot itself. A great robot can have a few bad match ups depending on your partners. The data can be used to help show what your bot can really do.

I am thinking right now of doing it almost like we did last year just for simplicity sake.

I am curious though what stats everyone is taking. That is kinda the basics of our meeting on Saturday. Getting the data is pretty straight forward, but getting the right data isn't so easy.

I know our data last year by St. Louis was good enough to be able to predict the last day of Archimedes within 2-5 points for each bot. The only ones we missed were due to mechanical malfunctions.