Preparation was key for this project. We selected a camera, chose a software plan of attack, mounted the camera, played some pool to “test”, and created a camera driver. The camera chosen was a basic webcam with a 90 degree field of view and 1080p resolution. This made for a wide enough image to capture the pool table felt and the rails. The chosen software was LabVIEW as DMC has experience using NI’s versatile VAS and VDM software libraries with an integration to our existing custom Java based pool application. Once we wrote the driver we were able to start on algorithm development on FedEx Day.

 
The following software was developed on FedEx Day: Software Architecture/Application, Calibration Algorithms, Ball Location Algorithm, Ball Color and Pattern Algorithm, “Active Shooter” Algorithm. The architecture utilized a Producer/Consumer architecture with a single state machine to collect an image and determine the state of the pool table. Each ball was calibrated by snapping an image of the ball to get a known representation of each balls RGB value and whiteness. Each balls location was detected by HSB differences between a ball and the felt. Based on the calibration images captured for each ball, the RGB best match of each detected ball was matched to the corresponding calibrated ball. The pattern of a ball, striped vs. solid, was determined by white content of each detected ball. More white meant striped and less meant solid; lots of white meant the cue ball. To determine when to analyze the state of the pool table, an algorithm was written to detect whether a player was shooting and therefore blocking the camera’s view of all the balls. 

After a day of programming, we did it! The system correctly identified the location of the balls and what balls were left on the table. However, there were some challenges along the way. Lighting, RGB vs. HSB and the USB standard just to name a few. As always, lighting is very important in vision applications. The issue we ran into was shadowing around each ball. The shadowing ruined the RGB color measurement around the edges of the ball which could lead to incorrect ball color detection. HSB is a valuable domain to work in and was useful in distinguishing between the felt of the table and the color of the balls. As far as the USB standard issue, we used a USB webcam for the proof of concept. Although not a devastating issue, we needed to shorten our USB connection to the camera to be under 5 meters since our initial cable was longer and caused camera connection issues.

There are a lot of fun future applications we can do now that we can detect what balls remain on the table. The next major step will be to integrate it with our existing 3/5-way cutthroat application to automatically update what balls are sunk. If you have any fun ideas let me know by posting them below!
 

The post Pool Vision Application appeared first on DMC, Inc..

In this less than 10 minute video, I'll show you how to:

• Install Android Studio (along with the Java Development Kit)
• Design a simple "Hello World" app
• Test the app on a Virtual Device
• Attach a real device to your computer and test the app there
• Fix common installation problems

Learn more about DMC's custom software and hardware development services.

The post How to Make and Test Your First Android App in Android Studio, FAST! appeared first on DMC, Inc..

Most Android programs (and really most mobile apps), run on the target device and will interact to the outside world over some sort of wireless network: Wi-Fi, Bluetooth, NFC, etc. However, a much less common (but equally as awesome) mode is to interface with external hardware directly using a physical connection. One of the coolest examples of this type of communication in my opinion has been credit card readers that connect to a mobile device using the 1/8” headphone/microphone jack. Another communication interface that is provided with nearly all mobile devices running Android is USB. Google supports a software development kit called the Open Accessory Development Kit (ADK) which is a software stack that defines methods for the Android device to communicate to a generic external device over USB. This allows for custom hardware to be easily interfaced to a device running the Android operating system. One example application of this technology would be for a navigation app to use an external GPS to obtain a more accurate location than the device itself can supply.

At DMC, we recently created a simple “Hello World” Android application to demonstrate using the ADK to connect a Nexus 7 Android tablet to an electronic dial indicator. After a few minor communication issues, we quickly prototyped a working system, and I wanted to share the result with our blog readers.

The goal was to create a simple Android app that would display, in real-time, the current measurement on the electronic indicator. The indicator can send its current measurement interface through a RS-232 serial interface, so the first design challenge was to find a method of translating this information to USB format in a way that is compliant with the ADK protocol. Luckily, Future Technology Devices (FTDI) makes a chip that serves this exact purpose, and they also sell some simple development boards that demonstrate the various supported interfaces (General I/O, Serial, SPI, etc.). For each of the interface modes, they wrote a very basic Android application to demonstrate the functionality and released the source code for public reuse.

For our demo, we used the FT311D board. Connecting this device to the electronic indicator was simple. RS-232 is a two-wire interface (not counting the ground connection), so we simply sliced open the vendor-supplied cable and connected the two serial pins appropriately to the FT311D headers. The development board has three pairs of pins that are jumpered together to set up the interface mode, so these were set up for RS-232 communication.

Connection between the FT311D board and the Android tablet was very simple. The device serves as a USB host and will recognize any device running a flavor of Android that supports the ADK (this includes 3.1 and above natively, although version 2.3.4 can support the ADK with some additional libraries). One of the cool features of the ADK is the ability for the Android device to associate the attached peripheral to an installed application, and launch it automatically when the peripheral is connected. The FTDI-provided code supported this functionality out of the box, so the RS-232 application launched immediately after powering up the board.

The electronic dial indicator’s serial command set returns the current measurement after a request command is received. Unfortunately, FTDI’s application didn’t work natively with the indicator. I spent some time trying to debug the software by checking the serial lines with a Bus Pirate (which is an immensely useful tool for anyone working with any of the generic flavors of serial communication!), but wasn’t able to pinpoint exactly why the communication wasn’t working properly. Instead, I decided to re-design the application so that it was more centric to the gauge’s command set. That is, on a fixed update interval the application sends a “Get Current Reading” message to the gauge, looks for the response, updates the display, then goes idle.

The display of the dial indicator updates at a rate of approximately 30Hz, and I targeted the Android application to have the same refresh rate to duplicate the physical hardware’s user experience. The revised code worked just as I expected, and we were able to view the current measurement gauge measurement on the Nexus tablet. I also added a button to “Clear” the current measurement, which mimics the physical button on the front of the gauge. You can check out the final result in this video below!

The process of developing a simple “Hello World” application with the Android ADK was surprisingly easy, and yielded some cool results. For anyone interested in tinkering with this interface, I would highly suggest the FT311D development board from Future Technology, as it was very easy to use right out of the box, and is quite reasonably priced. Happy hacking!

The post Android Connectivity using the Android Open Accessory Development Kit appeared first on DMC, Inc..

We’ve had a few upsets along the way, but for the most part, the favorites proved why they earned the high seeds. After a last minute video review overturned what looked initially like a C++ victory in the semi-finals, this inaugural championship is between Microsoft’s C# .Net and review beneficiary, Sun Microsystems’ / Oracle / Open-Source-Independent, Java.

Amazingly, put perhaps not surprisingly, the architectures and syntax of these 2 platforms is remarkably similar. For a complete look at the similarities, there are a number of great sites exposed by a simple Google search. Some of these differences are significant, while some are cosmetic, but diving into all of them is well beyond the scope of a simple blog post.

Now, admittedly, I have done much more work on C# projects than I have with Java, and my Java experience is strictly from what I’ve done working with Android Development and anything I could learn from the Java Unleashed book I bought back in 1997 (you know, when I was in seventh grade and they had to give you a CD-ROM with the SDK and examples, since AOL dialup was still too slow to download anything real from the new-fangled “Internet” thing.)

Jumping from C# into Java, I’ve been perfectly able to make basic Android apps, and all else being equal, I honestly would lean towards Java for the simple reason that it is inherently cross-platform. Like other cross-platform languages, this means that code I write on my Windows computer can be compiled and run on a Mac without worry. This advantage means that we don’t have to build the same application 3 times to run on Windows, Mac, and Linux devices, a huge business case for commercial software companies. The Java VM mechanism used to achieve this is pretty neat too, even if it does mean that we are constantly getting barraged by Java update requests at startup. C# is making progress here with the Mono Project, but there is still a long way to go to get the same foothold that Java has.

So the winner is Java, right? Well, not so fast. C# gets a chance for a rebuttal, and rebut it does. By most accounts, C# is slightly ahead of Java when it comes to features, although both, it seems, have been doing a flip-flop where one adds a useful feature and then the other copies it. The biggest area where I think C# stands out is the integrated usage and implementation of types and classes for each. It might just be because it’s what I’m used to, but the system in C# makes a lot more sense to me than does Java.

For example, Java lacks static classes, doesn’t have a tool like LINQ, won’t allow named and optional method inputs, can’t pass inputs as references, doesn’t integrate arrays and collections, and has only watered down support for Generics. Project file management also seems better in C#, with conditional compilation flags and a level of abstraction between assemblies and files and between files and classes. Now, I know that each of these are subjective features, and you can probably even argue that some features are intentionally left out of Java, but I personally have become accustomed to the C# programming style and think that it makes sense.

The bottom line is that both C# and Java are excellent, high level languages, with many similarities and a few individual strong points. I think that environment has a strong impact on which you prefer, but for me, being in a strongly Microsoft-centric workplace, C# is my go to language. Therefore, strongly weighing my own opinion of my own opinion, in a wild game, with a controversial play, at the very last second, on a strongly contested Hail Mary, C# wins in what will safely go down as an Instant Classic.

Semi Final Flashback

Relive the Excitement

The post Programming Madness National Championship appeared first on DMC, Inc..

Now that we have reached the semi-finals, a lot has already been said about our remaining contenders: C#, Python, Java, and C++.  All of these languages are strong, object-oriented platforms, capable of creating a wide array of applications. That being said, in true DMC / Medieval Times fashion, I still insist on a battle to the death.

I am going to name our first matchup the Battle of the Dan’s. On one side, we have Dan Freve’s first true love, C# .Net, and on the other side, we have DMC alumnus Dan Aukes’ flavor of the week, Python.  Both of these languages have a lot going for them, but one key area that we can differentiate is in the developer experience. Whether you love Microsoft or hate them, you can’t really argue that Visual Studio 2010 makes for quick, efficient programming in C#. Honestly, I get startled when writing code if I ever have to type more than 3 letters of each variable, property, or method that I want. This level of Intellisense, combined with strong typing and live error checking really help developers get into “the zone” when coding.

On the flip side, Python suffers from the fragmentation and division that so often plagues open platforms. On the Python wiki, there are well over a dozen different IDEs listed, and, although I am sure I could research or employ trial and error to find the best one, this is something I wish were done for me. Now I am sure that several of the Python IDE’s are great, and I am encouraged to see features like code completion, but the ones I’ve worked with (admittedly a small sample) have forced me to manually look up method names, only check errors at compile time, and generally force you to write code like you are in a simple text editor. I’m sure a lot of this has to do with Python as a scripting language, but for application development, I’ll take our first finalist, C#, any day of the week.

Switching over to the National League championship, we run into 2 bastions of application development, C++ and Java.  Both of these languages have been major drivers in programming during my lifetime. C++ has been the language of choice on anything from Windows, Office, and even Google Chrome to the majority of video games across most platforms, and has even been used in many beefier microcontrollers.

What C++ has done for applications, Java, by many regards, has done for the web. Having been explicitly targeted at the internet from birth, Java has been the backbone of countless internet games, applications, and services/tools. When you throw in Android’s reliance on Java as well, it becomes pretty obvious that it is a force to be reckoned with. As Java has become more “open-source“, it is being used frequently on lightweight, embedded, Linux-based smart devices around our homes and workplaces. In fact, many Java tools, like Spring, Hibernate, and Tomcat, have become wildly popular solutions aiding rapid development, by solving common developer problems and have set the standard for cross-platform architectures. Given Java’s wide usage and numerous applications, Java wins as expected and moves to the final against C#.

View the Previous Round

On to the Finals!

The post Programming Madness – Conference Finals appeared first on DMC, Inc..

The tail end of round 2 graces us with the matchups between Java and LaVIEW and Objective C and C++. As we have seen before, Java is a widely used, extremely flexible, and free programming platform. Despite ongoing disputes between Google and Oracle, Java is an integral part of the Android platform, which has only made Java more of a rockstar. The many high level functions that Java automatically performs “under the hood” allow developers to focus on writing great applications, rather than get lost in memory allocation issues or tied up in painful debugging or code maintenance. Java has been embraced by open source communities (again, free!) meaning that there are numerous reusable libraries you can drop in when needed. On the flip side, LabVIEW is a language that is closely managed by its owner, National Instruments. In ways this can be a very good thing, since it avoids fragmentation that can occur when too many cooks are in the kitchen. However, it has also meant that popular new features may be slow to surface. LabVIEW is also the only Dataflow based programming language on our list, meaning that it takes a different mindset than do the traditional C-like languages. This definitely has its uses, but it also can lead to silly mistakes and is prone to race conditions, and it just isn’t what programmers are generally used to. As such, for the purposes of this competition, despite being a Certified LabVIEW Architect myself, I think that I will have to give Java the edge. If the competition had more to do with hardware and data measurements, though, it would definitely be another story.

Objective C and C++ is a much less differentiated matchup. Both languages were created or popularized in the 80’s as beefed up alternatives to C, specifically adding classes and object oriented design. However, they go about achieving this goal in entirely different ways. C++ uses what is called “Simula” style, meaning that methods called on classes are all resolved at compile time. Objective C instead uses a messaging paradigm that is derived from its predecessor, Smalltalk. In this design pattern callers just blast messages out to classes who then resolve what to do on their side. This reminds me a lot of UDP versus TCP where the sender just broadcasts something and the receiver does what it wants, but there isn’t really any handshake between the two, so if the method doesn’t exist on the receiving side, the call just quietly dissolves into the ether. To me, this sounds prone to difficult debugging, and I am a huge proponent of strongly typed enforcement. Without diving more deeply into Objective C, I am going to call it here and send Objective C home, and C++ on to the semi-finals.

Well, that’s it for today, but we are getting closer and closer to crowning a champion. Honestly, I have to say that I would be happy to code all day in any of the languages we have left, but, in true DMC competitive fashion, one must be crowned the best!

See the Other Quarter Final Games

Check out the Conference Finals

The post Programming Madness – Last of the Quarter Finals appeared first on DMC, Inc..

Our opening game this blog pits the world renowned Java (the language, not the beverage) against the quirky underdog, Assembly Code. As with our previous 1 v. 8 matchup, there is little doubt in my mind as to who will probably move on, but for the sake of fairness, let’s weigh some strengths and weaknesses. Java, as you may or may not know, started off as a platform for the oft-failed idea of 90’s web TV. Despite the embarrassing origin, Java’s founding principles hit the right notes of object oriented, multithreaded, platform independent code. Throw in Java’s prevalent role in the world’s most popular mobile OS, and Java is sitting pretty. Assembly language, the language of the first few weeks of Microcontrollers 101, has none of Java’s bells or whistles. Even when programming low level embedded and microcontroller devices, it’s likely that any remotely complicated program will be written in C or C++. Despite an impressive historical resume, and the ability to expose what your processor is actually doing, assembly obviously has little to no place in the modern programming language conversation. Java, book your ticket to New Orleans, you’re going to the Elite Eight.

Going in order down the bracket, we next get to LabVIEW and VB .Net. LabVIEW’s bread and butter, without a doubt, is the stellar NI hardware to which LabVIEW is inextricably tied. As such, LabVIEW is probably ‘the best’ tool for creating applications to acquire and analyze measurement data. However, the issue comes with asking it to do the same sorts of things that applications developed in ‘enterprise’ languages do. Just like you wouldn’t typically ask a PLC to play multimedia, LabVIEW isn’t great if you need inheritance, abstraction, or an extensively customized look and feel. In contrast, I often ask myself why VB .Net exists at all. I completely understand the need for readable code, but when lined up next to C#, VB just feels ridiculously verbose. I realize why VB .Net evolved, but, despite a short list of features found in VB and not in C#, I have a hard time justifying ever choosing the former over the latter. That being said, let’s just get out of this matchup and let LabVIEW roll.

In one of our more exotic matchups, Objective C tries to defend Leon’s honor in a battle against PHP. Objective C is one of those languages that started off simple but ended up becoming one of the big dogs by getting in with the right crowd, in this case becoming the basis for Apple’s Mac OS and iOS. Objective C and the overall dev package known as Cocoa have the benefit of Apple’s unified, streamlined approach to technology, which often leads to a robust programming experience. 

Objective C also supports well-loved features such as reflection and garbage collection (although this is a recent addition), and it plays very nicely with standard C code, promoting reuse of existing tools. However, missing features like namespaces and the ability to overload methods show Objective C’s age. 

In contrast to Objective C, PHP is another example of a niche language, existing primarily as a web scripting tool. PHP’s differentiator is in being a server side tool, allowing dynamic content generation closer to the many data sources, such as MySQL databases. This matchup is a tough one for me to judge, but in all, I think that Objective C is a broader brush with which to paint, giving it the go ahead to round 2.

Last but not least this week, we have C++ and Fortran, two languages that have polarizing supporters. I have always viewed C++ as one of those familiar, comfortable languages, not straying far from good ole’ C, but providing the flexibility of object oriented classes, exception handling, and the like. C++’s biggest negative could be that it is sort of a middle child, stuck between older low-level languages and the flexible, dynamic languages of the present day. 

This means that it becomes easy to write inefficient code, but it also gives you the freedom to create really effective code without the overhead of higher level languages. This is likely the reason that so many drivers and OS’s (including Windows) are written in C++. Fortran, like LabVIEW or Matlab, might best be described as an academic language. 

To some extent, we are all indebted to Fortran for popularizing the idea of a compiler that optimizes programs into machine code from high-level, human-readable syntax. Because it is so well optimized and geared for number crunching, Fortran can be a great tool for the type of intensive calculations often encountered by engineering and science researchers (which is probably why so many in academia still swear by it). Unless you’re working on your Ph.D. though, the shortcomings of Fortran probably mean there is a better language to do what you want, but at least we don’t have to write its name in screaming caps anymore. Begging the forgiveness of anyone over the age of 35, I’m sending Fortran home and C++ on to the next round.

As much as I hate having all the higher seeds move on, that’s the way it works out sometimes. Stay tuned for round 2!

Return to Round 1, Part 1

Continue to Round 2

The post March Programming Madness: Round 1 – Part 2 appeared first on DMC, Inc..

Our first matchup features the highly favored C# .Net taking on lowly, old-timey conference winner Punch Cards. Obviously, even if we weren’t a Microsoft Gold Partner and I wasn’t such a huge proponent of C#, this still wouldn’t be much of a contest. However, there is some really fascinating history of the punch card system and how its impact can still be felt in programming today. Punch cards, in addition to setting the 80 column width limit on older terminal interfaces that you might still see today, also served as the launch pad for tech-giant IBM (originally International Business Machines.) For our purposes, however, without even getting into the mud-slinging of hanging or pregnant chads, we’ll go ahead and move C# as our first team into round 2.

Our second matchup, good ole’ plain C vs. VBA presents a somewhat more even pairing. For me, I can’t help but feel some affinity towards VBA, as was the medium for some of my earliest professional programming. After dabbling with some QBasic (ah the blue-grey IDE!) and HTML at a young age, as most young boys do, discovering VBA inside of Excel and Access really let me wow fellow engineers in my first few internships. When you evaluate VBA in the context of what it’s expected to do, it serves its purpose really, really well. However, this round it is up against C, whose versatility, in stark contrast to VBA, is practically unmatched. C can be thought of as the grandfather of languages like C# or C++, it can be compiled for almost any platform from microcontrollers to popular operating systems, and it is still one of the most widely used languages around. Ironically, both these languages have similar shortcomings, such as lack of object-oriented capabilities and manual memory management, meaning that C, with its huge advantage of portability, joins C# in round 2.

Matchup 3, Ruby on Rails and Matlab features 2 of the lesser known competitors coming into this tournament. Ruby on Rails is one of the newer kids on the block, having developed over only the last decade or so. Based on the Ruby language, which is widely used itself, Ruby on Rails is a language specifically geared towards web development. Its core principle of DRY (Don’t Repeat Yourself) coding is something every programmer should follow and the MVC architecture inherent to RoR is one of several great ways to structure a program. All that being said, however, RoR suffers from some early growing pains between versions and compatibility and probably has some maturing to do. Matlab, on the other hand, has been around for what feels like forever, and most of us probably used it at one time or another to crunch numbers in school. If you have major numeric processing to do, LabVIEW is probably the way to go, but since graduating, I can’t say that I’ve seen Matlab pop up more than once or twice. Matlab just seems to be more of a research tool than an application development platform. From weak typing to limited GUI tools, the typical expectations of programmers just aren’t met, and accordingly, companies aren’t willing to invest in Matlab development licenses. Honestly, I’m not blown away by either of the two competitors here, but I think we’ll move Ruby on Rails through if for no other reasons than having the right idea in their mission statement.

Our fourth and final matchup of the day, Ladder vs. Python is an intriguing matchup, because the 2 platforms are such polar opposites. Ladder’s low-level, no-nonsense programming is specifically targeted for robust, real-time systems needing reliable control. Ladder logic and PLC’s have a fairly intuitive programming structure (it’s just like an electrical schematic!) but obviously can be restrictive at times. Ladder logic is another case of a language being great at what it’s meant for. It probably won’t be winning any software architecture contests, but it makes modern life possible, from automated factories and building technology to amusement parks and public transit. On the flip side, Python was created to be one of the most flexible languages around and has a pretty impressive standard library. Coming from .Net, I wish that Python has static type checking, as having type checking in the compiler just makes me feel warm and fuzzy, but at least it is enforced at runtime. I also worry that, as an open source package, Python suffers from fragmentation, especially when it comes to getting started, choosing an IDE, compiling, and developing GUI’s. The choices can be overwhelming for a newcomer. Still, running the risk of global infrastructure spiraling out of control, I’m giving the nod to Python (in honor of Dan Aukes) for the first upset of the year.

Stay tuned for the second half of round 1 soon!

Return to Part 2 – The Snubs

Continue to Round 1, Part 2

The post March Programming Madness – Let the Nerdament Begin appeared first on DMC, Inc..

At DMC, we pride ourselves in being fluent in many, many software languages from LabVIEW and .Net to PLC’s and microcontrollers. A team of engineers came up with a list of the world’s best programming languages and seeded them from 1 to 16. If these potential matchups don’t make your heart race you might want to see a doctor, because you are probably a robot.

Over the month of March I will be weighting input from our engineers and readers to (arbitrarily) decide who moves on and who goes home. Obviously this is a completely subjective exercise, but I am hoping that it exposes the strengths of the contending languages and that we all gain exposure to new architectures and programming approaches.

Continue on to Part 2 – The Snubs

Now without further ado, I submit the initial rankings:

1. C# .Net
2. Java
3. C++
4. C
5. LabVIEW
6. Ruby On Rails
7. Objective C
8. Ladder
9. Python
10. PHP
11. Matlab
12. VB .Net
13. VBA
14. Fortran
15. Assembly
16. Punch Cards

Feel free to submit your 2 cents if you feel like your favorite was left off the list or if you are abhorred by any of the ranks. Otherwise, check out the bracket and get ready for a crazy, action packed March of software reviews and architecture discussions!

Continue on to Part 2 – The Snubs

The post March Programming Madness – The Bracket appeared first on DMC, Inc..

The only entryway to the data that was available with no additional hardware was the Modbus RTU network already in place, that fed data from the PLC (master) to some intelligent analog gauges (slaves) in the field. If I tapped into that, and sent the signal through a cheap Modbus RTU to TCP/IP converter (the only hardware addition necessary), I knew I could just plug into the customer’s existing Ethernet network, and have all the data I needed available from any Modbus TCP/IP server also plugged into the network.

That was the easy part. The hard part was finding a way to display that data in a meaningful way on a PC. After a bit of research I found two options. Two libraries, one for Visual Studio .NET offered by Win-TECH, and one for Java (called jamod), that could set up both client and server Modbus TCP/IP connections from a PC. The core differences were that the .NET library was supplied by a private company and cost thousands of dollars, whereas jamod was open source, had an active online community, and was free to distribute under a modified BSD license. Even after weighing the risks of leaning on an open source solution (lack of support), the jamod solution seemed a little more enticing.

After surprisingly little tinkering around, I had it up and running. The library simply extends the regular Java TCP/IP Connections class, and offers many of the same connectivity functions, along with all of the standard Modbus communication functions. It really opens up the possibilities for custom remote monitoring software. My customer can now log into their machine, check the status of (or modify) all of its parameters, and log the data to a local CSV file, all from any computer that can run the Java Runtime Environment. Even neater, the JRE is available on many mobile platforms, giving anyone with the right smart phone the ability to peek into the machine data.

Jamod truly opens some exciting doors. This open source library, combined with Modbus (the most widely used protocol in the manufacturing world), makes it easier than ever to create customized remote monitoring and control applications with extremely low hardware and software costs.

Learn more about DMC’s software and web development services.

The post Remote Machine Monitoring–Connecting to a Modbus Network with Java and Jamod appeared first on DMC, Inc..