The first three units I've made used a traditional 7-segment display and some buttons. They worked OK, but I quickly realized that some of the functions I want to [eventually] have in my DRO work much nicer on a device with a fast CPU and a graphical user interface. My first instinct was to use an old laptop or a netbook, but with all the swarf flying around a touch screen was much more desirable than a keyboard/mouse approach. It turned out that a tablet was much less expensive than a PC + touch screen combo, would take much less space and be much more robust (no moving parts, open vents etc.)
Why did you pick Android over iPad or a Windows tablet?
Fort two reasons. First of all, when I stated looking into this, Windows tablet PCs went for close to $1000 and iPad wasn't cheap either. In contrast, a B&N Nook Color sold for $159.99 at my local Staples. While I could justify $200 for a tablet “for the garage”, having a shiny iPad next to my mill would get me killed (if you're married, you will understand). Second, I'm a C#/.NET software engineer during the day. Android uses Java, which is very similar, so I wasn't facing the steep learning curve associated with Apple's Objective C.
Why did you go with Bluetooth instead of a USB connection? Before Android 3.0 tablets didn't have a USB host port. The only way to have a wired connection was to use the Arduino-based ADK board. The selfish reason was that I had several MSP430 Launchpads, Arduinos and a few different Bluetooth-to-Serial adapters. In the long run, though, the wireless approach offered more flexibility. The “encoder” would be platform-independent and could be implemented using any microcontroller. Since I planned to share the project with the community, it made mode sense to go that way.
Does your DRO work with glass scales/calipers/[insert your favorite encoder here]? The application that runs on the tablet will work with any scales. It doesn't care what encoders are used as long as the position it receives is in a particular format. See http://www.yuriystoys.com/2012/09/android-dro-communication-layer.html for more details. If that sounds like a goobleygook, the short version is: as long as the encodes send in something like this: “X1234;Y1234;Z1234;”, you're good to go. The tricky part is that the only encoder I've made so far is for iGaging 21 bit scales, so you can either make it yourself or wait till someone creates one.
Will you post the source code?
Yes, I will (and I did). The source code is posted in a public repo here: https://bitbucket.org/ycroosh/android-dro. I will keep pushing my changes as they are tested. Surprisingly, I get a few emails per day asking this question, even after posting the source code.
Is the project dead?
No. I was insanely busy for the last few months (working 1.5 jobs and helping a charity with a code project), so I didn't have any time to work on it. I'm back to a more normal schedule, so I'll be spending much more time on this project.
There are two more common questions I've been getting: “What features are you planning to add in the future?” and “Why should I use your DRO?”. Those require a bit more than a paragraph, so I will post a more in-depth writeup(s) in a day or two.