Our school along with others in our district recently in received I-pads for the every student, personally I prefer laptops but now we have a common device which our whole team is using and there are some opportunities with this. We were wondering how to develop apps for scouting and team management. Any help is greatly appreciated and we’ll gladly share anything we develop if we get that far!
It depends on your programming background. There are a couple ways to do this. Probably the easiest way is to do an HTML 5 application. This is the way we do it.
Programming for the iPad usually requires an Apple Developer license. Well there are a couple ways around this. You can tell your app to cache locally when saved as a bookmark. This is a pain in the butt (we did that the first year and it worked well enough but it was a pain).
The other way to avoid getting a developer’s license is to use a program like Telerik’s App Builder. App Builder has a starter license that is free for projects like this and run your code through their free companion app.
You can also program the apps directly in Objective C if you have the knowledge but you will need a developer’s license to program for your iPad. (Our team switched to Android because of these issues)
I would just get an Apple developers lisence. It only costs $99. This will allow you to program with Swift, which is much easier than objective c and html 5 in my opinion. Once you have an apple developers lisence you can even make apps for other teams to use(outreach).
Don’t hesitate to try out other scouting apps created by other teams. It definitely saves you the hassle of creating a new one not that I am discouraging you from doing so. Try out FRC scout, created by team 1730, which is available on the appstore. There seems to be a iBook manual for FRC scout as well. Also Aerial scout, created by team 525, which is also on the appstore. Links included below.
https://itunes.apple.com/us/app/frc-scout/id824608264?mt=8
https://itunes.apple.com/us/book/frc-scout-manual/id846169922?mt=11
http://525swartdogs.org/?page_id=707
http://525swartdogs.org/?page_id=997
When searching for the swartdogs app on the appstore turn this option on when searching for it “Iphone only”. IPhone applications work on Ipads as well. The app can only be found when searching in the Iphone apps area(I searched and downloaded it myself on my family’s device). I noticed this since I had a bit of trouble finding it on the appstore.
Hope this helps.
My one recommendation for trying to develop/test any electronic scouting system is that as you develop/test the electronic version, make sure there is also a paper version you can fall back on. You don’t want to suddenly hit a roadblock because all of the sudden at the event you can’t connect your iPads to the aggregate system.
Set yourselves a hard deadline (a week before you leave for your first event is probably the latest you could make this), that if that scouting system is not complete (though you can always make iterations later) and thoroughly tested, you can fall back on your paper system.
I strongly second this app. Our team used it all of last year and really avoided us a lot of stress, seeing as we took cycles of scouting and not matter how many different iPads we used (although we tried to stick to 6) we could easily transfer all the data onto one within ~15 minutes. That itself is kind of a downside,︎ so I’d encourage setting up a Master iPad for the pit and transferring the data at lunch and at the end of every day so you’re not running around before alliance selections trying to get all the data on the Master.
Telerik is also a really good platform for designing apps, although it only lasts 30 days.
Also I noticed that you guys(4536) are only signed up for 10,000 lakes. 10k is a week 6 regional, and since you guys wont be attending any of the duluth regionals you guys can test your application out in many ways before 10k. To give a stress test to your scouting application before 10k you guys can turn on a regional webcast(weeks 1-5). Gather all your scouts and view/practice scout the regional at the same time. This way you can get a feel for the game, scouts can be more familiarized with scouting, and you will also give a good stress test to your application. This way you can ensure that your system can handle the stress.
Also as artK mentioned always have a backup scouting system ready. You never know when you might encounter issues at a regional. Better safe than sorry.
Adding on to that, I’d be fine stress-testing a scouting application using webcasts, or possibly even up at Northern Lighs (although that is Week 1).
This should help: http://www.chiefdelphi.com/media/papers/3037
I am a programmer, our team created a mobile website that was used for scouting last year. If you have experience with HTML5, CSS, and Javascript, I would highly recommend those over Objective-C and Swift. Making any application on an iOS device, except for a mobile website, requires an apple developer license, which requires a Mac. Even if you write your apps in HTML5, it still requires that you upload your application to Apple via a Mac.
We use Phonegap to build our HTML apps, and I would recommend you to do so as well, because compared to some alternatives, Phonegap is free, Open Source, and there is a wealth of tutorials for it online.
The problem with using iPads and HTML is how you communicate with the web server. iPads don’t connect to ethernet and setting up a WiFi hotspot is forbidden by the FIRST rules. 3G-LTE iPads can communicate over the cell system but connection speed can vary greatly depending on venue. At championships Verizon and AT&T become so slow as to be unusable for typical web access. Besides, getting all those dataplans and 3G enabled iPads can get expensive.
We’ve switched to Android to give us more programing options. We’ll be using custom Bluetooth communication to a local server this year.
If you utilize Telerik’s platform you can compile your html5 app and use it without a developer’s license (they have a companion app that will run your code).
What we have done the last 2 years is to save the data to a local webSql database on the ipad (or Android, or WIndows, etc). We then sync this data up after the event at the hotel. We don’t have live data (at least compiled between the devices) but we have really good data the next day.
We have also during lunch periods have some people run out to the parking lot, fire up the hotspot and sync up the data with the server.
My team investigated Bluetooth but we could never find a good way to make it work. Would you be able to post some of the basic ideas of your setup? I’m curious about how you went about this.
I’ll have our software person doing the work respond if there’s more to say but the idea is the tablets running a custom Android program periodically (maybe once every few minutes when they have something to share) try to connect to the sever in the stands via Bluetooth. That server may be a Raspberry Pi or maybe a laptop. If they succeed, they send up all the data they’ve collected. If not they wait a random amount of time and try again. Only one Bluetooth device can be linked at a time so they just keep trying until they connect.
This is still a work in progress so we’ll see how it goes.
Hey, I’m the guy that is behind 1540’s aforementioned scouting app. (This post is probably a bit excessive, and probably mostly under your level of proficiency, but I felt like typing it out.)
Let me just preface this with some background. For us trying bluetooth was the natural choice for this season. Last season we used a system with android tablets wired directly to a raspberry pi that would service requests. While this idea was great in theory, in practice it meant a lot of messy wires and not quite functioning ethernet ports. Additionally, this system also tied all the tablets functionality to the server, which meant server crashes were disastrous. We might of tried to continue in this vein, even with these drawbacks, but we lost all the team members who knew enough javascript to maintain the system.
With this in mind I knew that I wanted our rewrite to be two things, server independent, and maintainable.
Immediately I realized maintainability meant Java. Our school has a strong computer science curriculum that does Java second year, and our robot code is also written in Java. Java is also more maintainable, in my opinion, than Python, which is the only other language our team has consistent proficiency in.
Secondly, reliability meant wireless. Since I’m not a web guy, this meant a native app, helpfully also in Java. Wireless was actually a tricky issue. Since we couldn’t communicate over wi-fi that left bluetooth as the only other high level choice. Unfortunately, despite being in the same language, bluetooth communications between an Android Java app and a computer running a Java app are hard to establish. I just used the built ins for the tablets, but for computer I didn’t. Why, one might ask? Because there is no built-in Java bluetooth functionality! Helpfully, or debatably not, Sun published a spec of what they think it should look like, JSR-82. I downloaded Bluecove, an open source implementation, and wrote my server code based on that. Bluecove was really fiddly, requiring 32 bit Java 6 to work properly, but is pretty reliable once it was correctly configured. The biggest problem after setting this strait was a random crash I was getting ever so often, I mention this for sheer absurdity points, the first message transmitted by the tablet never goes through. (I never actually fixed this, it’s just handled by my other failed message code.) In actual fact, once you fix up networking code, it’s pretty reliable.
Once networking works, the server and client apps seem fairly self evident, presuming you know what you want to collect 
Can you just use a Bluetooth PAN profile for this, then implement everything using TCP/IP? I have little experience with Bluetooth, but I figure once you have a PAN set up, any of the server/client type programs should work no problem.
I just tried this out with a simple http server on a laptop and connected to my Galaxy S5 and it seemed to work just fine. I’ve read that the protocol is limit to 8 devices and 3Mbps, but that should be more than enough for simple scouting data.
Bluetooth PAN is the way that were working towards right now. One of our biggest challenges is that we won’t have a common device to build an app for since we are relying on student/mentor provided tablets. So our solution will be server/client based. The server will be a raspberry Pi running a basic LAMP setup and then having the clients access using there native web browser.
I have the bluetooth PAN working pretty good on the Pi. Next step is to start developing the code and database.
I’m also working on a scouting app using bluetooth. Here’s a good blog post explaining how to connect an android device to a computer, using JR-82 and bluetooth. I haven’t tried it yet, but it looks like it will work alright.
The network design I’m planning on implementing would be completely decentralized, able to sync data across devices in the pit without internet access automatically, and completely network fault tolerant, not being tied to a laptop in the stands.
To address OP’s question though, I don’t think 2-3 months is quite enough time to learn how to do mobile app development. Last year, I implemented a system that relied on manually copying data to and from a central laptop over a USB cord with windows explorer. It was pretty ghetto, but it worked pretty well. You can see the source for the desktop version here, and the android version can be downloaded here. Let me know if you want me to put the source for that up. This is what I managed to make in about 3 months on my own with experience with Java. I’m not saying that to brag at all though, I’m not very happy with how the app turned out, and alot of the code inside is absolutely horrible because I was very rushed with mid competition bug-fixes.
All that being said, I thought it was a great experience, and I learned a lot by doing it, and you should definitely give it a shot, whatever method you choose. Just make sure you have a good backup solution like paper or another app, like I did, for if your app isn’t ready in time. You can always take what you’ve made and polish it up in the off season for next year.
Though it is debatable, I am under the impression that Bluetooth is prohibited at competitions.
T4 prohibits WI-FI, but not Bluetooth.