Android Digital Readout Micro FAQ

Monday, January 7, 2013
Since I first posted the screenshot of my Android DRO app I've received a lot of questions and feedback. Additionally, there have been discussions about the project on several forums and groups I read. In this post I will try to provide some answers and explanations as a mini-FAQ.


Why did you decide to use a tablet?

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 have to wait for its own post.

17 comments :

  1. Hi Yuri,

    very impressive project(s), my compliments! I did search for a concept like your Gage/Scale DRO for quite a while. Your solution finally looks like it is working very nicely and even easy to build for non-geeks ;=) - surely thanks to your good documentation.

    Having said that, maybe you can help me: I would like to improve the measuring part of my spinetester (determining arrow shaft deflection). The scale next to proper use is a depth measurer and I am not sure if I am about to pick the right iGage. I do not find and conclusive data sheet either, so I decided to ask you.

    Is this scale usable with your android/arduino DRO:

    http://www.intelligentworkshop.co.uk/igaging-0-4-digital-snapdepth-gage-metric-digital.html

    I read no information regarding a data port and see nothing like it on the picture. And except for the DIGIMAG Linar Scales, no other iGaging model appears to be wireable at first sight. I figured maybe you know a bit more and want to share...

    Thanks for your help,
    Leo

    ReplyDelete
    Replies
    1. Leonard,
      Thank you for the compliments :)
      I don't know much about this particular gage. Coincidentally, I was looking for a similar setup for a different project. I will look into it a bit more and will let you know what I find.
      Please drop me an email to ycroosh at gmail dot com. We might be able to figure something out.
      Thank you
      Yuriy

      Delete
  2. Thank you for your quick reply! Email is sent!

    ReplyDelete
    Replies
    1. No problem at all.
      I looked at the file you sent and required changed to the Android part of are pretty much trivial (I am bit busy the next couple of days, but should be able to get that done by next Monday). The hardware side is a bit trickier. (depending how accurate you want your measurements to be). It's possible to use one of the iGaging scales with a spring, but that will skew your measurements, since there will be a force from the spring acting downward. The device you found would probably the same issue, but presumably to a larger degree (since there is less friction, compared to the iGaging scales).
      I suppose the rig can be calibrated in software, which would get it "pretty close". Another option is to use a range sensor (ultrasonic or IR). That way you won't have any forces acting on the arrow.

      Hope this makes sense.

      Thank you
      Yuriy

      Delete
  3. Man, you are fast :=)!

    Good to hear how you think about this DRO branch. Makes all perfect sense!

    The accuracy demand is comparably low, +- 0,2 mm is okay, +- 0,1 mm would be excellent.

    The spring force is indeed an interesting subject. So far, I did not have one of these iGaging scale I could test (will order one very soon). However, I second your assumption that the force can be compensated. Either by adding some weight elsewhere or in the software. Typical measurements for x range between 10 and 35 mm. I would/will test how much force the scale creates here and see what to do after that. I am pretty sure a compensation is possible. In fact, if the spring force is well measurable, it could be added to the formula depending on the measured distance and thus be re-calculated in back. Now, I hope that makes sense :=).

    US or IR range sensor sound quite interesting but I have absolutely no clue which suitable sensors are available on the market. Can you recommend any?

    Thank you for your effort Yuriy! This all sounds very promising and whenever you find the time to work on it is fine for me!

    Leo

    ReplyDelete
    Replies
    1. Looks like most "hobby" grade proximity sensors won't be accurate enough, so scratch that idea.
      Here is a spring-loaded caliper that might work for your project: http://www.bgmicro.com/digitalcaliperwithdataoutputport.aspx. It appears to have a data output port and enough range to fit your deflection envelope.

      Regards
      Yuriy

      Delete
  4. Hi Yuriy,

    would you mind if I buy those scales and have them shipped to you for testing? The BGMicro Scale and the iGaging Depth Scale as well? That way you could toy around with the scales and test them as you wish. S&H to Germany is more expensive than the scales themselves... If they work, no problem at all, but for testing they would be better in your hands.

    Same goes for these digital calipers:

    http://tinyurl.com/ankqz55

    They have a data port as well (even if there is no mention made of it in the product desrciption) and might be an option if the depth gages fail.

    ReplyDelete
    Replies
    1. Leonard,
      The calipers you posted are available here pretty much everywhere. I think I have 2 or 3 laying around, and I know how to "talk" to them.
      I talked to the iGaging yesterday and the only scales they sell with a data port are the "Remote DRO" ones. BGMicro sound promising, though.


      Regards
      Yuriy

      Delete
  5. Yuriy,

    Thanks for putting together a great project.

    Question related to "Does your DRO work with glass scales/calipers/[insert your favorite encoder here]?"

    I can think of at least two items that would need to be addressed for an 'encoder' based system.

    The first is that many of the 'encoder' based devices are relative rather than absolute.

    That particular issue might be addressed by the controller.

    When it is turned on it assumes a '0' absolute position and then simply calculates and sends to the tablet the position based on the relative signals it receives. That would require the tablet to accept 'worst case' position data and handle it smoothly. Imagine the table cranked to the maximum right position when the encoder is turned on. Then crank it all the way to the left. The synthesized position inside the encoder could be a minus 30 inches. Would the tablet handle this gracefully. I am assuming so but would like to confirm this.

    The other issue that comes to mind is "encoder resolution" and that it may be different for different encoders. It is a moot point with the iGauge scales as they are absolute. The encoder resolution would need to be set based on the particular encoder being used ... as in 5000 per inch for some and 2500 for others. This information would be required by the controller to calculate the synthetic absolute position for each pulse it receives from the scale.

    The first thing that comes to mind is the value being set in the tablet and being sent to the controller when it starts up. Obviously functionality that is not currently implemented ... either as part of the interface or the bi-directional nature of the Bluetooth connection.

    At this point I'll stop and ask for your opinion. Do either of these seem to be show-stoppers?

    Arvid

    ReplyDelete
    Replies
    1. Arvid,
      In practice I'm treating iGaging scales are relative, since they do the same (0 is at the spot the scale was initialized). In my own controller I have two AA batteries connected to the scales power supply so they never loose power.
      On the tablet (in the new version of the app) I added a way to set "absolute" zero for that particular reason: if the scales reset, you can relocate the origin.
      The second concern can be addressed two ways: either write the value to controller's flash memory before transmitting it to the tablet, or have the tablet initialize the controller. Both are feasible. The Android app has the code to send commands, but isn't using it (yet). Wiring to flash isn't a big deal either.
      The app already has a way to calibrate each axis to different clicks per inch (in the settings).

      Hope this helps
      Thank you
      Yuriy

      Delete
  6. Yuriy,

    I have put some code for Arduino and Mitutoyo scales together with your APK. I can format the output of the scale into a long, with no decimal, and receive it on the tablet. I have verified what's going out by monitoring the serial port. The tablet interprets the character string, and gets the decimal in a correct position, but computes offsets that don't match the gage. I am looking through the code on the tablet to understand what is happening. This must be the ticks per inch (I am using the default), but I don't understand why this is needed, since I'm sending the actual position.

    Not sure where to get TPI for these scales, but will look for this. Any suggestions? I could set TPI to 1, and try to back into the number.

    FYI on the Mitutoyo scales, I can't see a way to power these (on/off) remotely, so this may cause me to have to turn them all on individually for a DRO. Others may have suggestions here, but I wanted to let everyone know.

    Jim

    ReplyDelete
    Replies
    1. Jim,
      The easiest way to figure out TPI is to move a scale by exactly one inch and see what the difference in readout is. (or, for more accuracy, by a few inches).
      Please feel free to email me at ycroosh-at-gmail.com if you have more questions.

      Thank you
      Yuriy

      P.S. Would you mind posting your code/schematics? Your project would be very valuable...

      Delete
  7. Hi Yuriy,

    Nice work on the dro:-)

    Sometime ago, i wrote a vb pc app using PICs to read the digital scales (see cnczone - pic dro). Since giving up developing in vb, i was looking to use the pic hardware to interface to a android tablet. You beat me to it :-) and have made a much better job than i would:-)

    I think i can modify my PIC code to out put a suitable string but, since i use one pic per axis with a multiplexed serial out put, I am not sure I can guarantee the order of the axes on the serial o/p.

    Does your app require strict ordering i.e. x followed by y Z etc , or is it happy with any order with,say, repeated axes from faster reading scales?

    Regards, Bill

    ReplyDelete
    Replies
    1. Bill,
      No, it doesn't. As long as each axis readout is well formed the app will work fine.

      Thank you
      Yuriy

      Delete
  8. Юрий проект замечательный, обязательно постараюсь повторить! Вопрос, русский интерфейс планируется?

    ReplyDelete
  9. You have provided the android software, A how to build an arduino with bluetooth module and even the arduino firmware.

    Where is the USB input side of this project? I am looking a way to connect up the 4 slides to the uno r3 with bluetooth module so I can read my slide measurements.

    Can you please point me in the direction of a breadboard circuit that will take care of this?? oh and will i need to modify the firmware?

    ReplyDelete
    Replies
    1. There is no "USB input side". The scales use Mini-USB connector, but they are not actually USB.
      Did you read this post: http://www.yuriystoys.com/2013/07/arduino-dro-build-instructions.html ?

      Delete