Optris PI Camera Driver

[JE_Green]

Hello Everyone,

(1) I'm attempting to get an Optris PI USB thermal imaging camera (http://www.optris.co.uk/infrared-cameras) running on an sb-rio 9637. I aim to do real time control of a process using thermal images.

(2) The camera has a driver and subscription server type arrangement where programs written (in C, LV or whatever) subscribe to the server and recieve data from the camera. It is not possible to connect directly to the camera using standard USB techniques despite the fact that the camera plugs into a USB port. The driver/server arrangement is unavoidable. The driver is available for armel (http://www.optris.com/optris-pi-linux-library) but it is for debain based systems dpkg. Source code appears not to be available but I will ask the manufacturer and see how I get on if necessary.

(3) Opkg will install .deb packages but dpkg has script helper programmes that allow the package writer to perform administative tasks (for example dpkg-maintscript-helper). Opkg doesn't know what to do with the scripts and neither do I. There are also a mile of dependency problems to wade through although I believe I have solved a number of them by manually downloading the armel packages from debian repos and installing using opkg.

(4) There is a wrapper for the driver provided by NIT (http://wiki.ros.org/optris_drivers) but I've not got that far yet. Source code available so not expecting too many problems there.

(5) Yet another problem is the optris driver (2) requires the uvcvideo kernel module loaded on ARM platforms. I've not even looked at this yet.

I have managed to install eveything and got the camera working fully in debian jessie on a 64 bit intel I7. Not running in Labview but getting LV to talk to NIT's wrapper should be trivial by comparison. There are lots of examples.

So my questions:

A) In your collective opinion which of the following seems most likely to provide a result:

- Attempt to persue a solution to the pakaging problem outlined above (3) and continue trying to get the compiled dpkg code to go. Based on picking apart whatever the package writer has implimented with dpkg-maintscript-helper and implimenting those tasks by hand in a shell.

- Attempt to get the source for the driver (2) and compile on NI Linux.

- Attempt to get the source for the driver (2) and cross-compile (I'm assuming the driver is written in C/C++ but I've no idea).

- Something radical (e.g. pull NI Linux source addin dkpg as a competing package manager alongside opgk compile and hope).

B) Any thoughts on tackling the kernel module in (5).

Many thanks,

James

[BradM]

First things first, welcome!

What version of the NI software are you using, as this impacts how to proceed somewhat.

I think you're going to have a difficult time getting the source to take the approaches that require that. If you could, for many components that use configuration and compilation systems (like cmake, which this library seems to do), it is easier to compile on the target for one-off builds since the writer of the original component likely expected that users would be compiling for the system the build is happening on.

That said, if I were in your position, I would likely use the .deb and use opkg to install the dependencies that it calls for. Opkg's (originally Ipkg) design came from a stripped-down Apt/Dpkg, and it can install .deb files (including handling most maintainer scripts), but you hit on an important point: this is installing a package on a system other than the one that it was intended for, and therefore has a higher risk of going south.

The actual dependecies are not so massive, and should be able to be satisfied (depending on the version of the base OS image that you're using) completely from opkg and the NI package feeds.

ar p libirimager-1.1.7-armel.deb control.tar.gz | tar xOzvf - ./control | grep Depends

./control

Depends: libudev-dev (>= 1.0), gcc (>= 4.6), build-essential (>= 1.14.18), cmake (>= 2.6)

The difficulty here is that many package management systems tend to give slightly different names to the same (or compatible) packages. In this case, "build-essential" become "packagegroup-core-buildessential" (for 2014 onward), "libudev-dev" becomes "udev-dev" (at least for 2015, didn't check other releases), etc.

Regarding the kernel side of things, there are some threads in this forum that have the overall guidelines, and there are per-release instructions at NI's Linux RT github portal: https://github.com/ni/nilrt

[JE_Green]

Hi Brad,

Many thanks for your reply. I was secretly hoping you'd be the person to pick this up. Sorry I neglected a key piece of information.

MAX is quoting the OS as: NI Linux Real-Time ARMv7-A 3.14.40-rt37-ni-3.0.0f2

MAX lists the software set as:

NI CompactRIO 15.0 - August 2015 (I can put the full listing if you want it).

and uname -a at the shell provides:

Linux NI-sbRIO-9637-030b4226 3.14.40-rt37-ni-3.0.0f2 #1 SMP PREEMPT RT Thu Jun 1                                  1 17:43:52 CDT 2015 armv7l GNU/Linux

I'm glad your order of preference is more or less the same as that I outlined. I'll continue with the .deb approach and keep this spot posted with how I get on.

Thanks for the pointers on the kernel.

Cheers,

James

[BradM]

JE_Green wrote:

...

Thanks for the pointers on the kernel.

Cheers,

James

If you planned on attending NI Week 2016, I plan on having a session on working with the kernel (NIWeek Kernel and Kernel Module Building session)

[JE_Green]

Hi Brad,

I would really like to, but the budget will not stretch to a trip to the US unless it's really impossible to continue without it.

In the past (2012 for exmple) the NI Week talks were videoed and available via ftp. Is that the intention with this talk as well?

James

[BradM]

I'll double-check. This session won't likely be a traditional session as most customers won't really need this level of detail, it will be closer to a hands-on session.

However, I do have good news! I somehow had just overlooked the module that you were asking about, and the uvcvideo module should be available in the 2015 compactRIO image (some NI software uses that to support the Vision toolkit through USB webcameras).

[JE_Green]

Excelent on the kernel module! It's not looking nearly as impossible as when I started. Not actually got it going yet but I'll keep trying.

Thanks,

James

[JE_Green]

Hi All,

I've got all the dependencies installed (as far as I know), and have extracted and re-built the optris driver package using dpkg on debian such that it now seeks the correct dependencies on NI Linux. I only changed the control file and I used fakeroot throughout to avoid changing the file ownership.

When installing this new package with OPKG using

opkg install libirimager-1.1.7-armel-NI.deb --verbosity=4

I've got some rather long output which is at: http://james-green.staff.shef.ac.uk/libimagerInstallOutputFail.txt

It doesn't appear to fail but after running the install, when quearying opkg for the files or status of the package it reports that the package is not installed. Sure enough if I go looking for the files that form part of the package they are nowhere to be seen.

I've had a look at the output from a successfull install (of cmake) and I can't see any obvious differences between its output and the output in the file linked above. That said, I know almost nothing about package management beyond what I've picked up doing this so I can't really say what I'm looking at.

Any pointers greatly appreciated!

James

[BradM]

Can you post the .deb file that you've created to check the contents, dependencies, etc. etc.?

Also, for the record, you're atttempting something very tough if you're fairly unfamiliar with package managers. I don't know whether to applaud your gumption or comisserate with you over your pain

[JE_Green]

Hi Brad,

I like a chalenge! If we were not already invested in the use of this particular camera in several of our experimental setups I would have bought an NI Vision system and be in the pub by now but we want to use one embeded architecture (NI) and one camera (Optris).

Since all Oprtis cameras use the same embedded system & driver (as far as I know), if I can get this going it should mean that all Optris cameras can work on any NI platform that runs NI Linux. I think it's worth having a good go.

I've actually gone round the package now and just extracted it on debian, passed it to the rio by scp, moved the files into their respective directories (/etc/... & /usr/...) then run the post install script line by line (there's only one line) at an ssh prompt.

I can detect the camera (I can have it report its serial number at a command line using an Optris supplied binary) which means the armel compiled binaries supplied by Optris can run on the cortex processor on the sbRIO, hurrah!. I can't read any data from the camera yet but I'm not loosing faith.

Of course I'd like to be able to have a pacakage based install as, if I want to uninstall for some reason, I have to go round hoovering up files manually and that's not the sort of thing that makes sysadmins happy. The .deb package I've re-worked probably rather inexpertly is at:

http://james-green.staff.shef.ac.uk/libirimager-1.1.7-armel-NI.deb

Since I've got the listing of dependencies and have installed them using OPKG from the command line, I can't guarantee that the package manager will pick up the dependency packages properly if you need it to. Best install them youself in my view. With regard to the control file I have changed some of the required version numbers to >=1.0 in cases where the numbering is very different between debian and NI Linux, I'm fairly sure this is safe as I've checked manually that the versions I'm running on the RIO are equal or newer than the ones requested by the unmolested version of the package.

I've also changed the architecture in the control file to "all". This is patently not correct as the binaries are built for armel. They were probably using crosstoochains (https://wiki.debian.org/CrossToolchains) but that's just my guess. Changing the architecture in the control file means that I don't need to add a line "arch armel (300)" or similar to: /etc/opkg/arch.conf on my RIO...

Do let me know if you need any more info, thanks for your continued support!

James