Nintendo DS Scouting System

Finally!

I don’t believe that any teams have yet created (or, for that matter, announced the production of) a Nintendo DS scouting system. Well, for the last 2-3 months (on and off), I’ve been working my rear-end off researching the DS homebrew scene. The concept has several pros and cons, but it is a new idea to throw out there for teams. Way way back earlier this year out team bought the tools necessary to run homebrew. Unfortunately, I got caught up in the FRC excitement and completely forgot about our plans, until recently. So, without further ado…

THE HISTORY
Earlier this year, our team (1726) was talking to Dr. Karen Suhm, a mentor from 842 and owner of !nventivity](http://www.nventivity.com/). She created an incredible scouting system for 842 this last year and it worked wonders at the regionals and championships. Anyway, somehow, someone got the idea of using a Nintendo DS as a scouting platform; it was very efficient with a touch screen and buttons, so my dad suggested I look farther into the subject. We bought the tools to run homebrew and I started experimenting, first loading other’s programs onto the cartridge and then creating my own. Before I knew it, we had a scouting system ready to go!

THE PRESENT
Here’s the catch: the required tools are

  • 6 Nintendo DSs (quite easy to obtain, from what I’ve seen at FIRST competitions. Every team member of every team seems to have one, so this is probably no problem)
  • 6 SD-to-GBA adapters (We use the SuperCard, available at RealHotStuff(yes, it’s safe for work!))
  • several superkeys (a version of a NoPass)
  • 6 SD cards (32mb cards are easily obtained on ebay, but MAKE SURE THEY’RE SD CARDS, NOT MMC CARDS OR ANYTHING ELSE(can be micro with sd adapter))
  • all of the software (I’ve added the GNU General Public License to the software, for reasons to be later discussed)

As you can see, there is a lot of stuff needed to get a full system to work. Here’s a picture of everything we currently have (image is missing 5 DSs):
http://img507.imageshack.us/my.php?image=ds1lt1.jpg

However, the cost of this system is actually quite cheap: under $300 if you buy everything from the right places! A great investment, in my opinion…

Here is an attachment of the software needed to run and sort the data:
DSScouting.zip (116 KB)
Basically, all you have to do is place DSSCOUTv0.3.sc.nds and INFO1.txt on the root directory of the SD card. Then place the SD card in the adapter, plug it into your DS, and scout! When you’re done (this is a problem that I will shortly fix) make sure the SD card is in the E drive and run the macro on the spreadsheet. A simple data spreadsheet will be created with every team sorted. Keep in mind that this is all based on 842’s system. If multiple DSs are being used, the data must be copied to 1 file (that means only the DATA, not the column titles) before running it through the macro.

That’s basically how it functions right now. When you’re scouting, you should get a screen like this:
DS2.jpg
Follow the program, filling in information, until you come to the save screen. Fill in that information and then hit save. At that point, the program is writing to INFO1.txt, so don’t cut power! It will then return to the main screen so you can scout again.

THE FUTURE
Fortunately, this is FIRST, and I’ve decided to release everything to the FIRST community. It is licensed under the GNU GPL, which pretty much means you can edit the code and change the project all you want! In fact, I beg everyone who has any interest in this field to join in an fix my code! It was made by, and I quote myself here, a “complete and utter n00b.” The code is probably very inefficient and I want this project to become something that FIRST teams can actually use! All I ask is that any team that edits the program, changes it, or completely redoes it (which might be the best choice…) graciously donates their code to the FIRST community.

Anyway, since I’m releasing it, you may want to know just how to make programs. Here’s what I did:

  1. Download and install DevKitARM (I don’t think that’s the version I downloaded, but it will most likely work…)
  2. Download and Install the latest release of PAlib
  3. If you intend to create graphics, you might want to ensure you have the microsoft’s .NET runtime environment installed…
  4. An emulator might be nice until you can buy some stuff
  5. Start programming!

One thing you may want to look into is reading a LOT OF MATERIAL on programming the DS. There is enough stuff out there you get you started, and looking up random files in the libraries is especially useful. Here’s a wiki site on the PA library (which also includes information on installing everything on LINUX!

Also, don’t let me forget to upload the program and all of it’s source code an files:

DSscoutingv.3.zip (639 KB)

Well, that’s about it! I was planning on debuting this system at Battle at the Border, but unfortunately southern California is on fire (I hope everyone is safe!). So I’ve decided to release it anyway.

I plan on creating a small website solely for this system in the near future, so keep checking for that!

Comments, questions, and suggestions of any kind are welcome!

Thanks!
Kevin Forbes, FRC 1726

DSScouting.zip (116 KB)
DS2.jpg
DSscoutingv.3.zip (639 KB)


DSScouting.zip (116 KB)
DS2.jpg
DSscoutingv.3.zip (639 KB)

I’ve been working on DS/GBA homebrew programming for about 2 years now and I can also say that I’ve always thought of different ways these handhelds can be used for applications within FIRST. This is an amazing idea and I can’t wait to see what it evolves into!

Do all of the nintendo DS talk to each other so everyone has a updated scouting sheet. That would be cool!

Hmm… looks very interesting. Was thinking of using PDA’s or something, but this is much better. Going to propose this to my team once the time comes around again.

As of now, you have to remove all 6 SD cards, take the .txt files off, put the data in one large .txt file, and then run the excel macro. It’s a tedious process, and I believe that creating a wifi section of the program that enables the scouters to place all of the data on one central DS would be more efficient.

Also, I forgot to mention that there are tons of programs out there for the DS that are quite useful. Moonshell, for one, is an OS of sorts; you can view pictures and text files, watch videos, and even play mp3 files. Also, one idea that briefly crossed my mind is the use of an FTP program, so that if the scouters are near a wifi hotspot, they could simply upload the files to some place on the internet, and another team member could download and print the results.

Also, for teams who are going to try this, there are DS Slot Homebrew cartridges now that use Micro SD for storage (D4 and M3 DS Simply)

I use an M3 DS Simply.

That sounds like it would be an awesome idea once some of the details get worked out. That and some sort of automation where it’d be updated from one DS.

[offtopic=“1”]I like what one of the teams at Buckeye did last year, which was setup a simple, open, ad-hoc WiFi network with a SuperG router. Basic server/software setup where you could easily view it from a PDA or even a PSP. I’m working on a bit of a better version. [/offtopic]

This is awesome. If you wanted you could even have it grab info on match schedules from a Sundial server, if someone is running one at the regional.

how about a team set up a network for wireless internet and have real time stats on all the teams at the competition. and it could be like wikipeadia where any team can change other teams stuff… and that would be a good scouting tool all you need is the internet and make it so each team has a profile …

of any one has any ideas hit me up i think all talk to a few people on this and see what i could do …

That’s exactly what I’m working on right now, alex. Maybe we should start a seperate thread to discuss this. Because I’ve no clue what I’m doing outside of setting up the server with Apache/MySQL/PHP. Got a custom box I purchased at a garage sale and threw on Windows Server 2003. Still configuring software and such, but once I get the basics setup, I’m pretty clueless as to what to do next. It’ll be all self-contained with no need for internet since that would mean either subscribing to Wireless Broadband or asking CSU to run a line, neither of which I’d like to do. A firewall would be called for too. Anyway, I need some assistance with coding the app. Preferably PHP, since I’m most comfortable with it.

Box Stats (Parts May Be Upgraded Before Competition, Just Got A New Job):

Windows Server 2003
Processor - AMD 366 MHz
RAM - 512 MB
Hard Drive - 6 GB
Network - Realtek 10/100 | Kingston 10/100/1000 | Dlink WBR1310 (b/g)
Optical - Generic CD-RW | Sony DVD-RW

I’m currently exploring the wonderful world of C++. It is without a doubt one of the (if not the) most flexible and useful programming language I’ve come across. (I just found out about the vector class)
The idea is to make a very easily editable version of the program so that it can be changed from year to year and team to team without having to reprogram the entire system (ie I’m thinking about making a library).

Anyway, I really like the idea of having a central “Hub” set up as a wifi center so that teams can connect and view other team’s stats. There are just no bounds with DSs!

Also, I’ve set up a simple blog sort of a thing at project1726.org/ds3.

If you are going to have a code ready by Week 3, send it to me and I’ll test it out at Buckeye Regional. I’m taking up some programming at community college this spring, so I won’t know enough in time. I was using something simple (the team last year updated a normal table) so we could have anything there, but I’ll take an actual program if it’s available.

Without looking through the code, I do have some questions. These are by no means critisisms; most customers in industry who want to implement a product have similar questions:

Why 6 DS’s? Is that # scalable?
How hard is it to create a read-only scouting client, for say, the drivers who are already busy?

Possibly the hardest thing to do if you take this real-time and wireless is to ensure that teams who don’t want to share data have the option to not share it. This is mainly due to the fact that some teams find particular pieces of information pertinent to their team whereas the rest of the information is simply noise to them. Any thoughts on how you’d do this?

Also, does the DS platform have a Java environment for it? I’m simply more comfortable with Java, even though it’s slightly more overhead.

On a side note, my camera uses a 1GB SD memory card. Can a Nintendo DS read that large of a card?

this sounds awesome. since one of our mentors saw this thead we r thinking bout doing this too.

@Jesse: Good point about it being six. I never stopped to look at that part of it. I’m hoping it is scalable, though. And with the teams not wanting to share certain info, maybe they can make some sort of logon for the teams or just ask them whether or not they want it in there.

By 6 DSs I’m implying that there would be one-on-one scouting for each robot on the field; 6 DSs for 6 robots.

Could you elaborate? From what I understand, you want a simple side program that organizes the data on the DS so that the driver’s can easily check up on their allies/opponents?

As of now I have no idea of how the wireless data sharing would work. Other people seem interested in this idea, so I’ll let them work on that for now.

Could you elaborate? (sorry, just don’t quite get what you’re asking…)

yes, my dad has one that large and it works just fine.

Could you elaborate? From what I understand, you want a simple side program that organizes the data on the DS so that the driver’s can easily check up on their allies/opponents?

Yes. I guess one would just have to take a look at the format of a realtime output file and figure out how to parse it to give the drivers realtime information.

Could you elaborate? (sorry, just don’t quite get what you’re asking…)

Can I program anything I want to do (like the above question for the drivers) in Java instead of C on the Nintendo DS? Since I do non-stop Java development at work on a 4+million line system, I’m more familiar with it. The interface from the Data Input © side to the Java side would be the output text file.

hmmmm…I just thought of something…how about having only 3 scouts scout 3 of the robots, taping each match, and have the scouts play back the last match immediately and scout the other 3 robots. Since we have a video camera.

(Kevin and I did some testing of the DS scouting system by watching the videos of the Arizona regional matches, which the Cobra Commanders FRC498 so kindly sent us)

I don’t quite know the state of Java on the DS, but I did find this page, where someone essentially created a very basic java platform. So as of now, I am not aware of a complete Java compiler for the DS. C/C++ are the only languages I’m aware of that you can use to program the DS, mostly because the libraries developers use are programmed in C.

I dunno…Theoretically, it could be done, but I’m not sure the match turnaround will be slow enough. You’d add to scouting stress levels. Also, there is the I/O error (e.g. filming only one robot all match) to consider. It would have to be a fixed camera that could see the whole field with decent resolution and a screen large enough for three scouts to see simultaneously. I’d do it as follows: six scouts + 1 camera. At convenient breaks, each scout reviews the video if needed. (Sort of like instant replay–but instant re-scout.) Also, when talking strategy, the video may be helpful to interpret comments made by scouts. And, the video camera can fill in for scouts who have to take breaks if you can’t get a replacement.