ni.com is currently experiencing slowness.
Support teams are actively working on the resolution.
ni.com is currently experiencing slowness.
Support teams are actively working on the resolution.
06-30-2016 05:35 AM
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
06-30-2016 10:05 AM
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
06-30-2016 10:55 AM
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
06-30-2016 02:35 PM
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)
06-30-2016 02:39 PM
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
07-01-2016 10:57 AM
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).