FlexGrade: Mobile Timber Grading
Back in January I was starting my final semester in college, and one of the classes I had to take was a senior capstone design course. What that means is people or organizations can come to the different engineering colleges and solicit free work out of us seniors! There were a few different projects that required software in one form or another, and so us soon to be Computer Science grads got called in to work on them. The project I got assigned to was a mobile timber grading mechanism, and I was a little bit underwhelmed when I heard about it. We're going to be bending logs? Ooh boy, how will I stand the excitement? Well, it turns out working on that project was one of the best times I've had writing software to date, even if I had a hard time getting into it to begin with...
So, why did this project turn out to be so much fun? Let me count the ways:
I couldn't have asked for a better group of mechanical engineers to work on this project with. Each of them knew their stuff (which was good, because I had no idea what to do with any of the hardware!) and they got their part of the project done fast enough for us CS people to start poking around and getting the devices working with our software. I've worked with groups before and a lot of the time progress is hampered by any number of things... someone has a key piece of knowledge you need to proceed and isn't getting back to you, someone is slacking and their lack of deliverable slows down the entire team, and on and on. That wasn't the case here, which was good because we needed all the time we could get with the machine to get it up and running!
So, before this project I hadn't really ventured in to the scary world of hardware (except for the odd Arduino project). I was comfy in my software bubble, thank you very much! Being forced to work with the hardware devices to coax information out of them (through a digital/analog converter, but still!) turned out to be a major headache, but that just meant that getting them working felt all the sweeter. And once we had all the devices working together, the rest of the software just fell in to place. We were constantly tweaking the software to accommodate the shortcomings of the hardware, but that was fun in its own right. Our ultrasonic transducer (to measure distance) has a ton of random noise coming across? Time to pull more data points. Our hydraulics are missing their target weights by 100+ pounds when we tell them to stop? Turns out we need to keep the "slow" relay on when we're stopping them (now we only miss by 20 pounds or so, which is a trivial amount considering how much force we put on the logs).
On the software side of things, we were working in C# .NET, which I've spent a lot of time writing in the past few years. We get the GUI for free with the the tools built in to Visual Studio! We used a National Instruments DAQ to acquire data from the hardware devices and to control the hydraulics, so we get their libraries to use! And software is easy, right? So what could go wrong?
Turns out, the NI library is a pain in the ass to use, and in no small way. It took a few weeks to get our devices reading in data reliably from the DAQ, and then we had more issues crop up when controlling the hydraulics. The code we wrote was a mix of threaded and non-threaded calls to the DAQ libraries, depending on what was happening in the system at the time. We needed to keep our GUI updated and allow the user to stop the hydraulic ram at any time, thus the threading. Well, the DAQ didn't like that, and would intermittently stop responding to our requests to change the relays controlling the hydraulics (for example, when trying to stop them midway through an experiment). Since we didn't want to kill or maim anyone with this device, we spent a long time testing and finally found out that the DAQ didn't like mixing threaded and non-threaded calls to their functions (even though they didn't overlap or anything... we weren't stepping on any toes here! The code was thread safe on our end!) The end result is some hackish code (in my opinion, at least) that calls some one line functions (that take less than 1/100th of a second to run) in their own threads just to get around the issue NI had with mixing the calls. The worst part of all that is the code that was causing the error was deep in the NI library, so even when I wrapped the calls in a try/catch the exceptions still were thrown and not handled. *sigh* There was a lesson in there somewhere, but I'll leave it up to you to say what it was...
The last thing that I loved about this project was the final product. When it all finally came together, it worked well and it was reliable. The testing that we did in a lab setting had our (relatively) inexpensive, portable system outperforming an expensive, giant machine that was supposed to be the end all be all of grading materials like this. So, that's a success! And not only does it work well, but apparently there's a pretty decent need for something like this to take into the field. As it stands now, there are specialists that grade timber visually based on a number of things (number of knots, knot size, etc) and they have to be very conservative. Now, with the help of our trailer, a log can be loaded, graded, and unloaded in 30 seconds. And it's accurate to within 5%, which is more than you can say for the visual grading system. It's speculated that at least half of the logs graded visually will be underestimated, which equates to a lot of lost profit when that's spread across a whole forest's worth of trees!
Anyway, I'm chalking FlexGrade up as a success, and it was a fun success at that! The project site is archived at the University of Idaho's Engineering department, you can take a look at it for yourself at http://seniordesign.engr.uidaho.edu/2010-2011/flexgrade. And maybe you'll be seeing some of our handiwork in a forest near you soon? I guess we'll just have to wait and see...