FLIR Pi HOWTO

The space has a FLIR infrared camera which is designed to plug into an Android device. Here's how to set up a Raspberry Pi to handle the camera, from scratch.

An operating system would be a good start

Start by fetching the Raspibian image du jour from:

   https://www.raspberrypi.org/downloads/raspbian/

And, I like checksums. So, copy the checksum too. I go to the trouble of putting the sum in an appropriate file. As of this writing (2016.12.06), the checksum is SHA-1. So, create a file named SHA1SUM with the checksum, two spaces, and then the name of the zip file. The SHA1SUM file can have multiple checksums to check. Like so:

   6741a30d674d39246302a791f1b7b2b0c50ef9b7  2016-11-25-raspbian-jessie-lite.zip
   6587483c9b90b11185e2ce99175e27fe75af1f61  2016-11-25-raspbian-jessie.zip

Check the sum with:

   $ sha1sum --check SHA1SUM
   2016-11-25-raspbian-jessie-lite.zip: OK
   2016-11-25-raspbian-jessie.zip: OK

If you see the OK then everything is okay. Duh. If not, your file is corrupt. This could mean an error in transmission or something more sinister...

Mount an SD card somewhere and see where it's mounted and how much free space is on it with:

   $ df -h

In my case, this is an 8GB SD card at /dev/sdb1

The dd program is the standard way to burn an image. I don't like it because to get feedback on the progress of the burn, you have to go through odd somersaults of sending kill SIGs. This is just perverse. Use ddrescue instead. Under Ubuntu (and presumably, Debian) the package name is gddrescue but the command itself drops the initial g.

   $ sudo ddrescue --force -b <blocksize> <source image> <destination device>

Specifically, as of this writing:

   $ sudo ddrescue --force -b 4M 2016-11-25-raspbian-jessie.img /dev/sdb

NOTE: The destination device does not contain a partition number.

(Another alternative to dd is to use dcfldd from the package of the same name, which also, unlike dd, provides a progress report as it burns.)

If you've burned the SD correctly, you should now have two partitions -- a root (/) and a boot (/boot).

Eject the SD safely and pop it into a Pi. Boot the Pi, preferably with an Ethernet cable attached.

Use nmap to find the IP address of the Pi. The following pings all of the machines on the local network. (THANKS, Tom!)

   $ nmap 192.168.26.2-255 -sn

   Starting Nmap 7.12 ( https://nmap.org ) at 2016-12-05 21:42 EST
   Nmap scan report for 192.168.26.6
   Host is up (0.0033s latency).
   Nmap scan report for 192.168.26.97
   Host is up (0.038s latency).
   Nmap scan report for 192.168.26.100
   Host is up (0.00023s latency).
   Nmap scan report for 192.168.26.116
   Host is up (0.0015s latency).
   Nmap scan report for 192.168.26.156
   Host is up (0.0055s latency).
   Nmap scan report for 192.168.26.176
   Host is up (0.035s latency).
   Nmap done: 254 IP addresses (6 hosts up) scanned in 2.36 seconds

Configure the Pi and enable SSH. I changed the host name to flirpi and the default user (pi) password to Infra-Red. There is a GUI to do that, or in a terminal you can use raspi-config.

Images are always out of date. So, fetch the latest and greatest packages for your Pi. And, while you're at it, get Avahi which makes working remotely sooo much simpler.

   $ sudo apt update
   $ sudo apt full-upgrade
   $ sudo apt install avahi-utils

Get all your SSH key ducks in a row to ease communicating with the wee beastie. In addition to adding the appropriate public keys to the appropriate ~/.ssh/authorized_keys file on the appropriate machines you want to talk to each other (and ensuring the permissions on said file are 600), adding a stanza to .ssh/config like:

   # HacDC's FLIR Infrared Camera Pi
   #
   Host flirpi.local
     User pi
     ForwardX11 yes
   Host flirpi
     Hostname flirpi.local
     User pi
     ForwardX11 yes

will let you easily ssh into the Pi without worrying about DNS services or remembering the IP numeric address du boot. (Installing the avahi-utils package is what allows us to use the .local to find the Pi. The above just lets us set up an even shorter alias to that, and to automatically specify the user to connect as -- not to mention the whole forwarding of X11 stuff, which lets us run graphics software on the Pi even if we don't have graphics capabilities on the Pi.)

For additional suggestions see both the following:

   http://www.penguintutor.com/linux/raspberrypi-headless
   http://www.penguintutor.com/linux/tightvnc

Okay. That was all very special. Now, time to get to why we're here.

Adding FLIR to the mix

We're already at 56% used of the 8GB... Everything up until this point has been a good way to set up any Pi. But now, it's time to add the special sauce to make it talk to the FLIR.

We need git to fetch the Video for Linux loopback source, since the Debian package seems hopelessly borked. To compile that, we need kernel header files. And finally, we need libusb-dev for a header file needed to compile the FLIR source code.

   $ sudo apt install git
   $ sudo apt install raspberrypi-kernel-headers
   $ sudo apt-get install libusb-1.0-0-dev

   $ mkdir -p ~/github/FLIR
   $ cd ~/github/FLIR

Compile and install the Video for Linux loopback driver module:

   $ git clone https://github.com/umlaeute/v4l2loopback
   $ cd v4l2loopback
   $ make
   $ sudo make install

Moment of truth: Compile flir.

   $ cd ~/github/FLIR/

Search the blog at http://www.eevblog.com/forum/thermal-imaging/question-about-flir-one-for-android/msg832208/#msg832208 for the source code link (flir8g-mint.c). It's a bit hidden near the bottom of the thread. Drop it in the recently created ~/github/FLIR/.

Determine, for certain, where the libusb.h file was installe in order to reference it in the FLIR compilation command.

   $ find / -name libusb.h 2>/dev/zero
   /usr/include/libusb-1.0/libusb.h

   $ gcc '-I/usr/include/libusb-1.0' -o flir flir8g-mint.c -lusb-1.0 -lm

Make sure that both the FLIR's power AND data lines are connected to the Pi, and type:

   $ sudo modprobe v4l2loopback video_nr=1,2
   $ sudo ./flir

The console should, after a second or two, start spitting out all sorts of camera data in an ongoing stream.

To see the camera data as video, install mplayer on the Pi and run it with some special parameters:

   $ sudo apt install mplayer
   $ mplayer tv:// -tv driver=v4l2:device=/dev/video1

Finally, since it's easier than figuring out the RIGHT way to do it, add a couple of lines to /etc/rc.local to automatically load the recently compiled and installed Video for Linux loopback module upon reboots:

   # Last modified by Ubuntourist <[email protected]> 2016.12.06 (kjc)

   # 2016.12.06 KJC - Load Video for Linux loopback driver module
   modprobe v4l2loopback video_nr=1,2

Also, a ~/.bash_aliases file with:

   # Written by Ubuntourist <[email protected]> 2016.12.06
   alias heatwatch='mplayer tv:// -tv driver=v4l2:device=/dev/video1'

added will let you type "heatwatch" instead of remembering all the parameters for the mplayer command. (Remember to start flir first.)

All told, 59% of the SD card's root partition (4.0 GB out of 7.1 GB) is being occupied at the moment.

Sample results

The stream can be captured to a file named capt.mpeg via the command:

   $ mplayer tv:// -tv driver=v4l2:input=1:device=/dev/video1:width=640:height=480 -vf pp=lb -vo yuv4mpeg:file=capt.mpeg

The tool "record my desktop" glitched a bit, but you should see something like this High Resolution Video. However, if you don't set up X11 forwarding, (either by adding a stanza to your .ssh/config as shown above, or by specifying a -X explicitly in the ssh command) then mplayer will do its best to accommodate, and produces this lovely Low Resolution ASCII Art Video.