FLIR Pi HOWTO
From HacDC Wiki
The space has a FLIR One infrared camera which is designed to plug into an Android device. You can watch this review -- among others -- on YouTube.
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.
--Ubuntourist (talk) 05:53, 21 December 2016 (PST)