Off-The-Shelf Hacker: Customize Your Gauges with Processing Code

Last week we discussed reading multiple sensors with an Arduino Pro Mini and then sending the data to the Raspberry Pi for display on multiple analog gauges.

This week we’ll look at pulling the data into the Pi and developing the multi-gauge setup with the Processing programming language. We’ll talk about how to break up the serial line input text into corresponding values to drive two onscreen gauges. I’ll also show you a way to make the movable gauge pointers without a lot of code.

Much like using the Arduino IDE, on the Pi to program the Pro Mini, you can use the Processing IDE, right on the Pi to take care of the code for the gauges. Pairing an Arduino and a Raspberry Pi (with a monitor and keyboard/mousepad) unleashes a potent portable development/usage environment. The Arduino and Processing code for this article were both developed with that setup.

Examining the Code

To review, the Arduino Pro Mini reads the ultrasonic range finder and coverts the distance into a text string. The Arduino code also simulates a variable value for a light level photocell. Both values are sent from the Arduino to the Pi over the serial line as a simple stream of text.

Since I’m not tweaking the Arduino code, at this point, I just powered the Pro Mini on and developed the Processing code inputting the data from the wired serial line. No need to use the FTDI cable for this job.

You’ll probably still want to run the stty command line before starting the Processing IDE, just to make sure you can read the serial data stream.

Remember that ttyAMA0 is the standard wired serial port name for the Raspberry Pi.

Here’s a screenshot of some sample serial data from the Pro Mini.

Notice that the data stream is just two values separated by a comma and an invisible line feed at the end. The first value is the data from the ultrasonic rangefinder and the other is the “simulated” data from a light level sensing photocell. You could add any number of values to the data stream.

Now that we know what the input looks like, let’s see how the Processing code works.

Much of the code was covered in a previous article. I’ve added quite a few comments to help readers understand how the existing and new functionality works.

Breaking up the input file is new. Scroll down to the “String[] pieces” line. This function takes an input line and breaks it up into character values, separated by the comma. The values are assigned to an array. We have only two input values in the text stream from the serial line, so we have two elements, [0] and [1] in the array. Additional sensor input values would increment the array accordingly. Those array elements are used to drive the code that cranks the pointers around the gauge face. Note in Processing, we can blatantly convert a character value to a float value using the float() function.

In a nutshell, adding new gauges basically means duplicating the angle#f and the segment functions then tweaking the appropriate setup initializations. You also have to account for additional input values in the input text stream.

Let’s move on to building those good-looking, low-effort gauge pointers.

Replacing Pointer Code with a Graphic

Much like ditching the notion of using manual code to ‘build’ a gauge with a dial face graphic, we can also streamline swinging the pointer around, with a picture too.

Here’s an old code snippet showing how to construct a pointer with line segments and code.

That’s a lot of work to edit the values back and forth, hit “Run” (in the Processing IDE) then adjust the numbers to get a nice looking pointer.

Instead, look at the segment part of the new code. Here you’ll just see a reference to an image. The image variable connects to a .png or .gif file of the gauge pointer. For the large gauge, I took a picture with my Galaxy 8+ super-phone, of a DIY clock minute hand, pulled it into the GIMP and scaled the output file (png or gif) to 200×150 pixels. The dial face file, “/home/pi/gauge10-b.png” is scaled to 300×300 pixels.

The small gauge uses a dial face file called “/home/pi/gauge10-c.png” and is scaled to 150×150 pixels. This explains the half size in comparison to the larger left-hand gauge. A picture of a Phillips head screwdriver was made the same way, although scaled down to 100×75 pixels. Dial placement was handled earlier in the code with the g1x, g1y, g2x and g2y variables.

It seems a little tedious to do it this way but isn’t that bad once you get the hang of it. You can design any kind of dial face or gauge pointer at any scale and place it anywhere on your gauge dashboard, with this technique. If you don’t like the steampunk theme, pick something else, take some pics and you’re in business. It sure beats trying to build some lame “code” pointer and then spend hours modding it to look half-way right.

What do you think?

Large gauge with the clock pointer, a small gauge with screwdriver pointer

What’s Next?

I think this will wrap up the gauges for a while. I’m using the steampunk conference badge for a tech talk at OSCON in July, so probably need to halt tweaking and get everything stable. The hardware should work when we step up to the podium. I need to work on the startup and shutdown scripts, get everything looking consistent and do adequate testing.

Look for a different Off-The-Shelf Hacker topic next week.

Rob "drtorq" Reilly is an independent consultant, writer, and speaker specializing in Linux/OSS, physical computing, hardware hacking, the tech media, and the DIY/Maker movement. He provides a variety of engineering, business and special project services to individual clients and companies....

Read more from drtorq