During my naive days as a university student the only time I graphed data was when some professor required a graph in the lab report. Back in those days I always just looked at the numbers to see what what was happening. It wasn’t until I worked on much more complex real world problems that I admitted graphing the data can help. It’s ironic that as I’ve become a better engineer I’ve realized how important it is to take advantage of every crutch I can fine. These days I graph just about every kind of data I see. Want to know when all the office birthdays are? Let me graph that out for you…
Graphing data lets my mind understand what is happening much faster/better the raw numbers. I know there are some less experienced programmers/engineers that need to learn this. The holy grail for software is real time graphing of the data your application is using. So often people add this sort of feature in at the end, but I think there are benefits to doing it first since it reduces debugging time. At my job we have a whole team dedicated to real time graphing of the data processed by our 3D graphics processors. I am always extra friendly to the people on this team because I fully realize how much easier they make my job. In short I’m a graphing fan boy so it should be no surprise that I wrote some graphing software for my hobby projects. I did this as the first step in a much larger autonomous flying vehicle project that I’m working on.
Since my ultimate goal is a flying vehicle I knew I’d need an inertia measurement unit (IMU). I wanted something with accelerometers to measure acceleration and gyroscopes to measure rotation. After some research I found the ADXL330 is a good accelerometer and the IDG300 is a good gyroscope. I use this Sparkfun 5 degrees of freedom (DOF) device that has both of these chips integrated onto a single small board. These chips measure acceleration along all three axises (x,y,z) and the gryroscopes measures pitch and roll. This means I am missing yaw, but I decided I can add an electronic compass in the future to get this data. I have an Arduino so that is the microcontroller I used.
With all the hardware figured out I already knew that taking this many inputs into a project and expecting it to do what I want was not going to happen on my first try. So to make the debugging less frustrating I decided to graph out all these signals. I will probably add some derived data to these graphs in the future as I get further on this project, but I think it makes sense to share this simple version of the generic graphing software before things get overly complicated.
I used the open source Arduino SDK to compile the code for my microcontroller. Here is the code I wrote for the Arduino. This code reads the sensors and then writes this data onto the serial bus. This software lets you figure out the frequency you want to refresh this data and then will sample the sensors as many times as it can while hitting this refresh frequency. Multisampling helps reduce sensor noise. The reason I didn’t want to send every sensor value over the serial bus is because that it too much data. For my uses I limited the refresh frequency to 100 times per second.
The graphing was done with the open source Processing language. I had never used Processing before, but I found it very easy to use and in a few hundred lines of code got some pretty nice graphing functionality. In a nutshell Processing is a java based language with a bunch of drawing and IO helper functions. Here is the graphing code I wrote for Processing. Besides graphing the data in real time, this software also supports logging all the data to a file and applying a smoothing filter to the data. I wrote this code pretty cleanly so it should be easy to add and remove more data to the graphs.
Here’s a movie of me shaking the sensors in a few different directions and you can see the graphs react accordingly. I’ll let you derive your own conclusions, but it looks like I have a good deal of work ahead of me.