install problems with rospkg and rosdep

[bobteeter]

Tully - I have cloned copies of wstool, rospkg and rosdep down to my Raspberry pi box.  I was able to build and install wstool without a problem.  I then tried to build/install rospkg and rosdep.  They built without a problem but when it went to install them they failed because  "/usr/local/lib/python2.7/dist-packages/easy-install.pth" was already installed by wstool and would not install.
I also had to do "sudo apt-get install checkinstall" to get them to work as the make utility bitched that checkinstall was not present.  Any direction on how to proceed.

Bob Teeter

[bobteeter]

OK - Paul - I have been able to work around the problem of installing from source for rospkg, rosdep and wstool. First I removed the wstool that I had installed on the box.  Then I built and installed rospkg without a problem.  I then tried to build and install rosdep and it failed because the install tries to overwrite the easy-install.pth file and checkinstall does not allow that.  So looking at the Makefile I just issued the command "python setup.py install" in the rosdep build directory and that worked fine. So I did that again with wstool and it also failed and then with the second method installed.  SOOOO - since the 3 packages do build on a Raspberry PI/Raspbian system without fail is it possible to get a repository constructed such that they can be installed with apt-get?

Bob Teeter

[Paul Mathieu]

Bringing working deb repositories - especially for RPi at the moment - is my primary focus as of right now. I'll dig into it and come back at you with any update. Eventually, one should be able to just 'apt-get install' ROS and get everything working as if they were on a Ubuntu PC.

-paul

On Mon, Jan 21, 2013 at 2:40 PM, bobteeter <bobt...@gmail.com> wrote:

OK - Paul - I have been able to work around the problem of installing from source for rospkg, rosdep and wstool. First I removed the wstool that I had installed on the box.  Then I built and installed rospkg without a problem.  I then tried to build and install rosdep and it failed because the install tries to overwrite the easy-install.pth file and checkinstall does not allow that.  So looking at the Makefile I just issued the command "python setup.py install" in the rosdep build directory and that worked fine. So I did that again with wstool and it also failed and then with the second method installed.  SOOOO - since the 3 packages do build on a Raspberry PI/Raspbian system without fail is it possible to get a repository constructed such that they can be installed with apt-get?

Bob Teeter

--
 
 

[Tully Foote]

If you want to generated debs you should use stdeb.  As you've noticed checkinstall doesn't work for more than 1 python installed package at a time.  The deb_dist target should generate them for you if you have stdeb installed.  

Tully

--
 
 

--
Tully Foote
tfo...@willowgarage.com
(650) 475-2827

[bobteeter]

Ok here is what I did to get the system to build .deb files for rospkg, rosdep and wstool.

sudo apt-get install python-stdeb fakeroot python-all

cd /usr/src

git clone http://github.com/ros/rospkg.git

cd rospkg
vi stdeb.cfg
(add wheezy to the end of the Suite: <>   line}
save the file

python setup.py --command-packages=stdeb.command bdist_deb

This will built the source and binary files.   And create a .deb file in the deb_dist directory

The only packages that need the stdeb.cfg change are rospkg and wstool.  rosdep already has the entry for wheezy in it.

Now MR.PAUL how are you at catching the 8 ball.  Sorry just had to have some fun.

I don't know what it takes to setup a repository but I hope that this is a start for the files we desperately need available to make the build simpler.

Bob Teeter

[bobteeter]

Another update:  It seems that we are also missing 2 other utilities and they need to have the same thing done to them.

vsctools
rosinstall

They also complain about the bzr package.  Which made me do a sudo apt-get -f install.   That appears to have cleaned up a lot of broken dependencies.

Then I could run the .deb creation command and install the .deb file with the 
dpkg -i <name>.deb file created in the deb_dist directory.

That's it for tonight and on to tomorrow.

Bob Teeter

[Tully Foote]

Bob, 

It would be great if you could file these changes as feature request or even better pull requests on the affected packages.  That will help get them updated as quickly as possible. 

Tully

--
 
 

[bobteeter]

I have put pull request in for rospkg, wstool, rosinstall, vcstools.  It seems that rosdep aready has wheezy in the Suite: line for building the package with stdeb.

Now we only need a place to put these changes.

Bob Teeter

[bobteeter]

Paul / Mike - where should we document the packages that need to be supplied so that the Source Code version of Groovy can be built.  There seem to still be libraries missing from Raspbian build that are needed by ROS as defined by the latest version of rosdep.  Case in point is libtbb-dev.  According to google that library exists and is in fact is part of the Debian tree for Wheezy.  Should we just post here or is there a better location?

Bob Teeter

[bobteeter]

Also in the document "Installing on Raspberry PI/Raspbian from source".   We have to compile a couple of items because they are not in the Raspbian binary tree.  The tbb library is one of those items and the next is collada-dom with the last being swig-wx.  All of which build on the Rpi/Raspbian system but are not available from the install tree.  I don't know if these items belong in the Raspbian or ROS trees but they have to be supplied for ROS to build and we need that before we can create the install tree of binaries so that our install document is as simple as the document "Unbuntu install of ROS Groovy".  It is my understanding from this ongoing conversation that this is the target we are all working towards.  I am not trying to be pushy here but I am looking at a project that will probably use around 25-30 Rpi systems in its operation.  Some of the units will be doing detail project construction operations and others will be doing control functions with 10" touch screen on the systems.  The Google group project is is "CubeSpawn manufacturing project" and has lots of places that different levels of ROS will be necessary. So I do have a personal interest in getting this to work.  Some of the people in the project have started using the "Fuerte" release and I started on the new system to get it operational so that the group can progress with the newer code base when it is available.  I thank Paul, Mike, William and Tulley for all the help with this effort.  It is still fun cranking a Rpi system around the post and making it scream all the way down the hill.  I am in Minnesota and that is what happens when you ski downhill and all you see are Redwoods (the tree). You can end up with one big headache and you might even get to the bottom.

Again Thank You all for your help.

Bob Teeter 

[Austin Hendrix]

I'm having a similar problem with the build farm I'm running for Ubuntu armel; arm builds of libtbb and collada-dom aren't available.

It looks like libtbb is missing because it doesn't compile on armel; when I pull down the source debs and try to compile, I get the following compile error:
../../include/tbb/tbb_machine.h:128:2: error: #error Minimal requirements for tbb_machine.h not satisfied; platform is not supported.
../../include/tbb/tbb_machine.h:140:55: error: ‘__TBB_full_memory_fence’ was not declared in this scope

Poking around on google a bit, it looks like TBB is doing some processor-specific things with memory barriers, and it doesn't appear to support ARM. Have you had any luck building it?

I can't seem to find the sources for collada-dom-dev; the binary packages are in the ROS tree, but the source debs aren't there. Tully, do you know where we can find these?

It looks like ROS is packaging its own version of swig-wx internally, as ros-groovy-swig-wx. It's building just fine for ARM on my build farm.

-Austin

--
 
 

[mptho...@gmail.com]

Bob, posting missing packages in Raspbian to get Groovy built here in this list would be fine.

I'll try to find time tomorrow evening and examine these specific packages in the Raspbian repository and see what I can find about them. 

When a package doesn't appear in Raspbian that is supported in Debian armhf in general it is because either a dependency is not present (which then needs to be investigated -- a recursive operation) or because the package autobuild encountered an error.  In most cases, we can work through whatever the issue might be by tweaking the package build scripts or sometimes resorting to manual builds.  In a minority of instances, the packages truly do have armv7 dependencies that prevent them from being ported to armv6 without the help of the package developers.  Typically these are bytecode compilers/interpreters in Javascript/webkit that emit armv7 specific opcodes or debug and profiling tools with modules having specific support for armv7 systems, but don't offer support for armv6 systems.

In other instances, packages are supported in Debian Wheezy on certain platforms (notably i386 and adm64), but aren't supported on armhf and/or armel.  These issues are generally the toughest to resolve because there is almost certainly a very good reason the packages isn't supported (or is very broken) on armhf or armel.  A port of Mono for armhf is one such example.  You can generally find a very long discussion list in the Debian forums as to why certain packages aren't supported in armhf.

Looking at the libtbb-dev here: http://packages.debian.org/wheezy/libtbb-dev

Unfortunately it seems that libtbb-dev falls into this later category.  This packages simply isn't for armhf in Debian Wheezy, nor Debian Sid where the latest versions of packages are kept.  Therefore this package certainly won't be available for Raspbian on the Raspberry Pi.  Perhaps there is an ARM version of this package for Ubuntu that can be brought over, but I'm not hopeful.

In this instance, one would have look at the ROS dependency for libtbb-dev and see if it is somehow optional -- for instance, the ROS package will compile without this package, but perhaps run less efficiently.

All other packages that don't have a version in Raspbian will need to be examined in a similar manner. 

Hopefully this all makes sense.

Mike

[bobteeter]

Mike - I have done the following research on the tbb package.  First it does build on the Raspbian OS as listed in out source install instructions.  Second I have examined the main.cpp source code and Intel was smart enough to test and set defs for intel platforms so that it is only used with intel hardware.
So I guess that building it and installing it will do no harm at this time.  I don't know how to identify where the libtbb_dev is being required because it is not listed in any package.xml file in ROS.   So it appears that this library is required because of another library that is loaded.  I don't know how or where to find this relationship so that it can be tested for or modified on a per arch type of thing. But it is a show stopper from getting groovy to build/install on Raspbian and ROS natively without any modification.

Maybe Paul and others can identify this choke point and we can work out a solution for this problem.

The 3 programs do build on Raspbian.   Collada-dom and swig-wx do install from the makefile for the package.  the libtbb package builds but does not have an install definition in the makefile.  So we just copy the *.so files into /lib where they are found.  The libtbb-dev definition is for the 3 libraries and all the *.h files to be install on the target machine.

At this point I am looking for some direction for what we are doing.

Bob Teeter

[Paul Mathieu]

Hi Bob,

Thanks for looking into that. I will give a look to the dependency tree and how it resolves to libtbb_dev being needed. 

Also, Austin, you are compiling for Ubuntu armel, could it be that libtbb needs at least armhf?

Paul

--
 
 

[bobteeter]

 I have done a grep of the ROS source tree and there is one entry from opencv2 from the cmake directory in OpenCVDetectTBB.cmake that looks for libtbb.dylib.  Other than that the does not appear to be a string for libtbb anywhere else.

Bob Teeter

[mptho...@gmail.com]

I attempted a standard Debian package build for the tbb source package in the hopes it would simply work and create the necessary binary packages for armhf.  Unfortunately not.

The output of the build is here: http://pastebin.com/LDyAZbda

I don't quite understand the error message, but I hope others can point to a fix.  Perhaps a simple configuration change in the package make file will get a clean compile.  Or, perhaps a newer version of this package than what is included with Debian Wheezy is needed to support the Arm architecture. 

I'll continue to look at what's required to get the Debian/Raspbian binary packages built for tbb.  I thought I saw mentioned above that a standard build of this library does indeed seem to work on Arm systems.  Is this correct?  If so, there must be some easy tweak to make the Debian package building tools build it.

Mike

[mptho...@gmail.com]

Just to add a little more information, here is support that someone added for the tbb package for armhf for the armv7-A.  I don't know if these patches will work as is for armv6 or if additional changes are needed.

https://groups.google.com/forum/?fromgroups=#!topic/linux.debian.bugs.dist/gvhccDtWa8Y
https://wiki.linaro.org/OfficeofCTO/ThreadingBuildingBlocks

I'll see if I can build package with these patches and see what results.

Mike

[Paul Mathieu]

Mike,

I looked a little into the tbb code and it seems that it might be a "feature" on their side.

if you look into include/tbb/tbb_machine.h:493 you will notice that the routine is only defined if __TBB_USE_GENERIC_DWORD_LOAD_STORE is defined, which is only the case for macos and the xbox360 (apparently), and now if you look at the line 525, you will see that the call to __TBB_machine_load8 depends on __TBB_WORDSIZE and __TBB_64BIT_ATOMICS, the latter being 1 in our case.

Actually, I wonder why this compiles on any platform at all...

--
 
 

[mptho...@gmail.com]

I attempted the patches, but they use an assembler statement that is apparently only supported on armv7 and above:

 Error: selected processor does not support ARM mode `dmb ish'

Mike

[mptho...@gmail.com]

It appears that tbb packages will be tough to get on armv6.  Any luck tracking down the whether this package is truly required by any of the ROS packages, or is it just an indirect dependency that can be patched up?

Mike

[Paul Mathieu]

Haven't had time to really look into the dependencies.

And for what it's worth, you could try to comment out the call to __TBB_armv7_inner_shareable_barrier(); in include/tbb/machine/linux_armv7.h

As far as my understanding of it goes, it is here to prevent race conditions on certain ARMv7 processors. I do not know whether it is needed or not on ARMv6, and if it is, what would be the equivalent.

If you can get it to compile with this line commented out, we'll investigate the matter to be sure to make it right.

Paul

--
 
 

[Paul Mathieu]

Hi Mike,

I'm trying to track down the dependencies to TBB. TBB should only be used to parallelize computation over several cores, which we do not need with the RPi anyway, so I will try to get rid of it.

Unfortunately, I haven't got a usable build process running on RPi at the moment (that will be fixed soon), so I will rely on your feedback as to how things go without TBB for the time being.

It seems that flann also uses tbb, but from what I have seen, this should be easily fixable.

I will update this thread as soon as I have more on this.

Paul

[mptho...@gmail.com]

I commented out the line and got much further in the build of the package before it terminated with the following lines:

g++ -c -MMD -DDO_ITT_NOTIFY -O2 -DUSE_PTHREAD -Wa,-mimplicit-it=thumb  -Wall -Wshadow -Wcast-qual -Woverloaded-virtual -Wnon-virtual-dtor -Wextra    -I../../src -I../../src/rml/include -I../../include -I. ../../src/test/test_atomic.cpp
/tmp/ccRZiGjd.s: Assembler messages:
/tmp/ccRZiGjd.s:1454: Error: selected processor does not support ARM mode `ldrexd r0,r1,[r8]'
/tmp/ccRZiGjd.s:1457: Error: selected processor does not support ARM mode `strexdeq r3,r6,r7,[r8]'
/tmp/ccRZiGjd.s:1470: Error: selected processor does not support ARM mode `ldrexd r6,r7,[r8]'
/tmp/ccRZiGjd.s:1473: Error: selected processor does not support ARM mode `strexdeq r3,sl,fp,[r8]'

Unfortunately, it looks like the inline assembly in the patches is specifying thumb instructions.  On armhf for armv6, we tell the compiler/assembler to not use thumb instructions as they don't support the floating point registers on the armv6 architecture -- something that was fixed in the armv7 version of the thumb instructions.  The flag ",-mimplicit-it=thumb" is suspicious as well.

Examining the patches, it only looks to be about 12 lines of ARM assembly code so perhaps someone knowledgeable of ARM instructions can rewrite the inline assembly code to be compatible with armv6.

Mike

[Paul Mathieu]

Thank you Mike!

On the priority list, I think 'getting rid of the dependency to TBB in ROS' will be first. Should that be too complex, then we will see about patching libtbb, which will probably be needed some day anyway.

And you are right, I had the same impression when reading the code, it should not be too difficult to clone the existing ARMv7-specific code and adapt it to ARMv6

Paul

--
 
 

[Austin Hendrix]

I found that the later version of TBB built without errors on my Pandaboard, and is reported to build on the RPi as well, so I think the appropriate course of action is to package the latest version as a .deb and leave the things that depend on it alone.

In particular, keeping TBB will be useful for those of us with multicore arm boards.

-Austin

On Thu, Jan 24, 2013 at 10:05 AM, <mptho...@gmail.com> wrote:

--
 
 

[mptho...@gmail.com]

I can take a look into doing this.  Is anyone able to confirm that the later versions of TBB did build on the Raspberry Pi?  If so, what versions?  4.1 update 1? 

Mike

[Austin Hendrix]

The raspbian instructions here: http://www.ros.org/wiki/groovy/Installation/Raspbian/Source indicate that the latest version http://threadingbuildingblocks.org/sites/default/files/software_releases/source/tbb41_20121112oss_src.tgz builds and installs cleanly on the Raspberry Pi

You could also give the stable version a try; if it seems ok it may be a better choice for packaging due to being more, well, stable.

-Austin

[bobteeter]

I have built the 2012112 version of the code repeatably with out a problem.  The makefile does not have an install function call in it.  So after the build completes we just copy the *.so files to /lib.  It works not fancy but it works.  It takes about 5 minutes to build on a Rpi Beta 512 with the cpu set on high.  At this point it appears that the 3 programs tdd, collada-dom and swig-wx need to be packaged some how so that they can be loaded with a apt-get command line to satisfy  the build requirements from the new version of rosdep with a -r option.  If these are resolved then the only other things are those that don't build right now in groovy anyway. (ie desktop-full items)

[mptho...@gmail.com]

I think I have a solution for tbb and I was able to build a test set of Debian armv6 armhf packages for Raspbian from the tbb41_20121112oss_src.tgz source file.  My package building foo is a bit rusty, but I'm going to work on creating proper set of Raspbian packages for tbb and hopefully have a set of packages that others can be test within the next 24 hours or so.  Because of the architecture differences between armv6 and armv7, I'm not sure how well this package will work on a real Debian armv7 armhf systems, particularly multi-core systems.

I looked at collada-dom and there do appear to be Ubuntu packages for this on the i386 and amd64 architectures.  However, it doesn't seem this package would have any architecture limitations that should give trouble for armhf/armel systems.  What I'll do is attempt to modify the Ubuntu packages to create equivalent Debian packages of collada-dom for Raspbian.  The source for the packages are:

https://launchpad.net/~barthelemy/+archive/collada/+packages

Is there a better source for these?

swig-wx is more of a mystery for me.  It looks to be a custom package maintained specifically for ROS.  Since there appears to be debian directory to create packages for Ubuntu, I presume these can be easily modified to create Debian versions of the packages.  I'll see what I can do with this one as well.

Mike

[Kai Franke]

Sorry for checking in so late, I got to all three packages to compile on the RasPi without any major problems. Please check the wiki for instructions. For collada-dom, I downloaded the latest version from sourceforge
Kai

[mptho...@gmail.com]

The broader issues are more about getting these packages into a Debian/Raspbian binary package that can be installed using apt-get just as it is done for Ubuntu on the i386/amd64 platform to satisfy install dependencies.  The wiki has great information that I've already used, but creating binary packages that makes it trivial for others to install with apt-get is unfortunately non-trivial (at least to me).

Mike

[bobteeter]

Paul - is it possible to get the repository started with the ros* and catkin* tools for at least the Raspberry Pi release as these build and run correctly.  These are the python tools and do build correctly with the standard stdeb tools.  All we have to make sure of is that "wheezy" is listed in the Suite: line in the stdeb.cfg file.  I put in pull requests for each of the tools and I don't know if that work has been completed on all the tools.  But as an initial start on the distribution tree it would be nice.

Bob Teeter

[Paul Mathieu]

Bob,

If you have already packaged those we can probably set up a repository with them for those who want to start building the rest on an RPi.

What I am trying to do on my side is getting the debbuild process working on a regular PC build farm, with qemu to the rescue. I do not have enough RPis nor the courage to set up a native build farm (at least for the time being).

Paul

On Fri, Jan 25, 2013 at 1:23 PM, bobteeter <bobt...@gmail.com> wrote:

Paul - is it possible to get the repository started with the ros* and catkin* tools for at least the Raspberry Pi release as these build and run correctly.  These are the python tools and do build correctly with the standard stdeb tools.  All we have to make sure of is that "wheezy" is listed in the Suite: line in the stdeb.cfg file.  I put in pull requests for each of the tools and I don't know if that work has been completed on all the tools.  But as an initial start on the distribution tree it would be nice.

Bob Teeter

--
 
 

[mptho...@gmail.com]

I've built Raspbian binary packages for tbb, collada-dom and swig-wx that will install with "dpkg -i" and "apt-get" once placed in a repository.  I'll post them in a bit on-line where others can get download them to try out.

I had to guess at the swig-wx package based on what I found in the Git tree for the Ubuntu packages.  However, I'm not certain I got it right.  The package installs the following files at the the indicated paths:

/opt/ros/groovy/share/swig/1.3.29/ruby/cmalloc.i
/opt/ros/groovy/share/swig/1.3.29/ruby/rubytracking.swg
/opt/ros/groovy/share/swig/1.3.29/ruby/std_except.i
/opt/ros/groovy/share/swig/1.3.29/ruby/rubyuserdir.swg
/opt/ros/groovy/share/swig/1.3.29/ruby/rubytypemaps.swg
/opt/ros/groovy/share/swig/1.3.29/ruby/rubykw.swg
/opt/ros/groovy/share/swig/1.3.29/ruby/rubyfragments.swg
/opt/ros/groovy/bin/swig
/usr/share/doc/swig-wx/changelog.gz

Does this look right?  It looks to suspiciously have too few files as if the package didn't build properly.

I guess it is a ROS specific package.  Shouldn't it just be built as part of the rest of ROS?

Mike

[mptho...@gmail.com]

I've created Raspbian binary .deb packages (along with the source code) for tbb, collada-dom and swig-wx.  As I mentioned in another posting, I'm not certain of the correctness of the swig-wx package, but hopefully I can fix up any problems quickly.

The .deb files can be found in the folders for each package at the following URL:

http://mpthompson.raspbian.org/ros_stuff/raspbian/

wget can be used to get the relevant .deb files and they should be able to be installed on any Raspberry Pi running Raspbian with the "dpkg -i" command.

If these packages work as intended, I'll set up a temporary repository where they can be downloaded and installed more easily using "apt-get".  Over the longer term we'll need to find a home for these packages -- either in the Raspbian package repository, ROS package repository or somewhere else.

Mike

On Thursday, January 24, 2013 6:53:03 PM UTC-8, bobteeter wrote:

[Kai Franke]

I did not try it out yet, but I searched for all files on my raspi with the swg ending. I have a lot more :)
I installed it by cloning the repository from here

Kai

[Robert Teeter]

Mike - the install instructions for groovy list the location and commands to build the 3 pieces of software.

Paul - where can I put the *.deb files for the python modules that we need. I was able to follow Tully's pointers to where to
get started with building them.  They built the first time once I did all the steps correctly.  He said to build them with stdeb and
all I had to do was add "wheezy" to the Suite: line in the stdeb.cfg file and run the command.  Just like kicking a pebble over a cliff
and you get a real pile of rocks at the bottom.  Its really just that easy.

Bob Teeter

[mptho...@gmail.com]

Bob, I was under the impression that for tbb and collada-dom, that it was desirable to create native Raspbian binary .deb packages that could be installed with "dpkg -i" or "apt-get install" once placed into a repository.  These would these would then satisfy dependencies when installing the ROS packages and avoid the need to build these packages from source as described on the wiki.  Are these packages not needed? 

Mike

[Robert Teeter]

No - you are correct - these are to be standard .deb files and should be in the Raspbian tree.  The files built according to the instructions are used in that form.  They are just in the instructions because they don't exist in the raspbian tree. And we needed them to allow the software to build.  I was trying to supply the location of the instructions of what and where it was that we had done.

Bob Teeter

[bobteeter]

Mike - do you have a URL for the packages you are building for ROS yet.
What I am looking for are the additions for the /etc/apt/sources.list.d/ros   file.  To resolve for the packages that need to be added to
Raspbian for the ROS installs.

I think that if we keep the 3 needed .deb packages separate for a while it might make thing easier all around.

Bob Teeter

[mptho...@gmail.com]

Bob, the .deb files can be found in the folders for each package at the following URL:

http://mpthompson.raspbian.org/ros_stuff/raspbian/

These are not yet inserted into a repository so you'll have to download the .debs using wget or a browser and manually install them using "dpkg -i package_name.deb".  I would like to have someone try them out to make sure they work as intended before adding them to a repository.  If it makes sense, I can likely add the tbb and collada-dom package directly to the Raspbian repository to keep things simple.  The swig-wx package (which I'm not sure is built correctly) would likely not be put into the Raspbian repository as it is not created in a manner consistent with Debian standards (ie. it puts stuff under the /opt directory).

I'm not sure what you mean by keeping these packages separate for now.  Do you mean creating a repository just for these Raspbian packages?  If so, I can do that pretty quickly if desired and it may make the most sense for the time being.

Hopefully these packages will work for you.  If not, let me know and I'll see what I can do.

Mike

[Robert Teeter]

Mike - I personally think that keeping them separate for now would be a good thing as they of unknown quantity until we can get them tested with installs and operational usage.  If you could make up a separate repository and post the url for adding to our test boxes.  I think that would be best for now.

Bob Teeter

--

You received this message because you are subscribed to the Google Groups "ros-sig-arm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-arm...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Kai Franke]

I think creating a repository for those packages is a good idea. I would also like to see packages like opencv2 or pcl to be added as soon as someone built a deb package for it. I am giving PCL a new try right now (36% percent already!!)

Kai

[mptho...@gmail.com]

OK, that sounds fine.  I'll have this done sometime on Monday and post back the repository URL then.

BTW, I'm very new to ROS and am just going through the beginner tutorials now.  I have groovy installed on Ubuntu so I can at least start looking at the package layout to better understand how it all fits together.  I'm excited to see the efforts to bring ROS to the Raspberry Pi. 

Mike

[Kai Franke]

I am just trying to use the RasPi tutorial for the gumstix and found yaml-cpp to be missing. I might have forgotten to note that on the wiki page. Can anyone confirm that? If yes, we should add it to the list

Kai

On Monday, January 21, 2013 2:18:38 PM UTC-8, bobteeter wrote:

Tully - I have cloned copies of wstool, rospkg and rosdep down to my Raspberry pi box.  I was able to build and install wstool without a problem.  I then tried to build/install rospkg and rosdep.  They built without a problem but when it went to install them they failed because  "/usr/local/lib/python2.7/dist-packages/easy-install.pth" was already installed by wstool and would not install.
I also had to do "sudo apt-get install checkinstall" to get them to work as the make utility bitched that checkinstall was not present.  Any direction on how to proceed.

Bob Teeter

[mptho...@gmail.com]

Bob, I've created a very small repository with the missing collada-dom and tbb binary packages from Raspbian that seem to be needed to be needed to satisfy build/install dependencies for ROS on the Raspberry Pi.

To pick up these extra packages add the following to /etc/apt/sources.list:

deb http://ros.raspbian.org/repo/ros/ wheezy main

Install the binary packages with:

sudo apt-get install libcolladadom-dev
sudo apt-get install libtbb-dev

I don't think I've created the proper version of swig-wx yet.  I want to research this further by comparing it with the equivalent Ubuntu package and hopefully I'll be able to add it later today.  It would help if someone could point me to a URL of the specific swig-wx package that is installed for Ubuntu 12.10 as it doesn't seem to be part of a standard Ubuntu repository.  I'm assuming it off on some other private repository.

Mike

[Robert Teeter]

Mike - I found the source for swig-wx at github

http://github.com/ros/swig-wx.git

So it appears that this is a version of swig  that has been customized to work with ROS.  I believe that it probably belongs in the

ROS tree and not in the OS tree.

Bob Teeter

--
You received this message because you are subscribed to the Google Groups "ros-sig-arm" group.

To unsubscribe from this group, send email to ros-sig-arm...@googlegroups.com.

[Mike Thompson]

Kai,

I can look into building and adding Raspbian binary versions of the OpenCV and PCL packages. 

I notice that the binaries for OpenCV 2.3.2 seem to already be part of Raspbian:

http://archive.raspbian.org/raspbian/pool/main/o/opencv/

Is a newer version of OpenCV desirable?  I guess that would be 2.4.3 or a slightly older version that that is unstable.

Mike

--
You received this message because you are subscribed to the Google Groups "ros-sig-arm" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-arm...@googlegroups.com.

[Austin Hendrix]

Correct; this is a version of swig-wx that is packaged with ROS, and built as a standard ROS deb; you should not be trying to provide separate debs for it out side of ROS.

I'm not sure why the source install doesn't pull in sources for it; that probably a bug in the rosinstall generator.

-Austin

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-arm...@googlegroups.com.

[Kai Franke]

Mike,

I did not see know that OpenCV was already compiled for the RasPi, that is good news. I am not familiar with the OpenCV changelog, so I cannot tell you if it makes sense to build the latest version but the newer the better I guess. I installed 2.4.3 and used it without any problems. The more important library would be PCL. I set up a cross-compiler, because the native PCL compilation is already running for more than 30 hours now (71%). Unfortunately I did not get the cross-compilation to work yet :(

Kai

[mptho...@gmail.com]

Kai,

There should be a version of the PCL library already installed in Raspbian.  Try the following:

apt-get install libpcl1-dev

That should be version 1.6 which I believe is the current version.  Let me know if there are any problem with it.

Mike

[mptho...@gmail.com]

Sorry, wrong information about PCL.  That's the Portable Coroutine Library, not the Point Cloud Library.  I'm working on a package build of the correct PCL library.  It depends on the OpenNi library, a large library which I don't believe is in Raspbian either.  Hopefully I'll have something within the next 24 hours for you.

Mike

[Austin Hendrix]

Watch out; there are currently two ways to build debs for PCL: within ROS and without ROS. I don't know all of the specifics, but I do know that the proper way to build PCL for use with ROS is to build the ros_pcl package, which should be (yet another) package that you get when setting up a Jenkins build farm.

-Austin

To unsubscribe from this group, send email to ros-sig-arm...@googlegroups.com.

[Kai Franke]

as far as I know pcl_ros (part of the perception_pcl package) depends on pcl. Here is the package.xml
https://github.com/ros-perception/perception_pcl/blob/master/pcl_ros/package.xml
So it should be ok to build PCL as a standalone library. This is valid for groovy, I do not know about fuerte.
OpenNI is also a standalone library which would be nice to have to use kinect data. It should be installed before PCL, otherwise PCL will only build a few libraries not related to it

Thanks a lot for your effort Mike

Kai

[mptho...@gmail.com]

Unfortunately, the Openni-dev binary package is proving to be a tough nut to crack as it basically assumes it is being built for an x86 system.  Looks like some effort was made to get it to build for Arm, but it looks incomplete and certainly wasn't supported for a debian package build.  I'll have to look at this tomorrow.

Is it worth build PCL without Openni?

Mike

[Kai Franke]

I installed openni on the raspi and wrote the steps down in the wiki. Just search for openni. Building PCL without OpenNi does not make that much sense because it will most likely be used to process Kinect data.

Kai

[Mike Thompson]

I was able to get a build of Openni binary packages for Raspbian and installed on the repository:

http://ros.raspbian.org/repo/ros/pool/main/o/openni/

Unfortunately, this is not the opennidev package needed to build PCL (at least according to the dependencies for the PCL package).  It seems that opennidev is a very old package (well from 2011) and doesn't support Arm for package builds.  This will have to be added if we want a set of binary packages for Raspbian.  I really don't know the difference between the openni package and the opennidev package.  Is openni just a newer version?

Mike

[mptho...@gmail.com]

I now have the Raspbian binary packages in the repository for openni-sensor-primesense as well as openni.  Not yet for opennidev which I'm hoping isn't needed.

http://ros.raspbian.org/repo/ros/pool/main/o/openni-sensor-primesense/

I currently have no way of testing these builds, but hopefully someone can try them out and they prove to be useful.

To pick up these extra packages in Raspbian add the following to /etc/apt/sources.list:

deb http://ros.raspbian.org/repo/ros/ wheezy main

I would still like to find out if the .debs built from the openni and openni-sensor-primesense source packages provide what's needed to build PCL.  In Ubuntu the PCL packages depend upon opennidev which seems to be an old OpenNi version.

Mike

[Kai Franke]

As far as I know, openni-dev is outdated, so we will not need that. Please also see Tully's post
He says, that the openni depends on libopenni-dev and libopenni-sensor-primesense-dev
You can see all dependencies here

Thanks for you efforts

Kai

[mptho...@gmail.com]

Kai, thanks for the confirmation.  That's exactly the change I made to get the current package build of PCL going.  I'll post back soon as I have packages in the repository to check out.  Hopefully later this afternoon.  I'm running into some minor Arm issues with the PCL package that are easy to fix, but the force me to restart the package build each time from the beginning I fix something up. :-(

Mike

[HCW]

Am Dienstag, 29. Januar 2013 19:06:18 UTC+1 schrieb mptho...@gmail.com:

Kai, thanks for the confirmation.  That's exactly the change I made to get the current package build of PCL going.  I'll post back soon as I have packages in the repository to check out.  Hopefully later this afternoon.  I'm running into some minor Arm issues with the PCL package that are easy to fix, but the force me to restart the package build each time from the beginning I fix something up. :-(

Hi. I also started compiling PCL 1.6.0 from source. I had to setup swap of 600MB + 512MB Ram to get things compiling (currently at 19%).

I had many messages about "Warning: swp{b} use is deprecated for this architecture", so i fixed boost headers as described in https://svn.boost.org/trac/boost/ticket/7140 and https://svn.boost.org/trac/boost/ticket/7141 .

Unfortunately this is without openNi, so either i restart the compile once more ( ... 8-<) or wait for your packages .... 8-> .
I did not had success with the Ubuntu OpenNi packages, so i tried the Openni2 packages on Ubuntu.

They worked there so i tried the github sources of OpenNi2 on the pi, there they worked also (with some patching).

And then found that PCL does not yet seem to support OpenNi2 (http://www.pcl-developers.org/OpenNI2-td5707600.html).

Regards

Hauke

[mptho...@gmail.com]

My package build is about 80% done and should be done in a few hours.  This is building on a iMX53 QSB system with 1GB of memory and attached SATA drives in a Raspbian change root.  Hopefully the rest of the package build goes smoothly and I'll have them posted to the repository soon.

I noticed swp{b} warnings, but we typically ignore those for armv6 builds as we didn't know the fix.  Fortunately, they didn't seem to harm anything.  I'll apply the patches you linked to if I need to rebuild the packages again to correct the warning.

Mike

[Kai Franke]

Sounds great, I got the trunk version (1.7) to compile, unfortunately it does not work with pcl_ros. So I downloaded 1.6, applied the proposed patches for the swp{b} warnings and added some compiler flags. At the beginning I proposed in the wiki to just remove the native flag, but I assume it would be best to add the flags -march=armv6 -mfloat-abi=hard -mfpu=vfp for some optimization instead. Do you build with any of those flags Mike? I assume my compilation to take about 24h

Kai

[mptho...@gmail.com]

Kai, those are the exact -m flags I compile with.  These packages really shouldn't be specifying such flags, but I guess they have their reasons.

Mike

[mptho...@gmail.com]

OK, I now have a set of Raspbian binary .deb packages for PCL 1.6 with dependencies on libopenni-dev rather than the obsolete openni-dev.  The compile seems to have gone relatively smoothly, but someone will have to verify the package does include the libraries that correctly link to the OpenNi libraries.

The packages are in the repository I created at:

http://ros.raspbian.org/repo/ros

The package directory is here:

http://ros.raspbian.org/repo/ros/pool/main/p/pcl-1.6/

It's a set of big packages so it will take a bit of time to download and install on a Raspberry Pi.  However, it should beat building the package from source which will beat up a Pi.

BTW, the build took about 10 hours on one of the build servers we used for Raspbian.  A big package indeed, but I've seen a lot worse.  For this package I didn't see where I need to specify the -march=armv6 -mfloat-abi=hard -mfpu=vfp flags.  These are automatically selected by the Raspbian gcc/g++ compiler so they shouldn't be needed.  I suspect the native option is available for getting higher level optimizations out of a regular armv7 compiler, but it's not needed for Raspbian.

Mike

[blackstag]

very cool thanks for doing that.

[Kai Franke]

Thanks a lot, I will try it out right now. I tried installing libpcl-1.6-all-dev and it gives me that.

The following packages have unmet dependencies:
 libpcl-1.6-all-dev : Depends: libpcl-apps-1.6-dev but it is not going to be installed
                      Depends: libpcl-features-1.6-dev but it is not going to be installed
                      Depends: libpcl-filters-1.6-dev but it is not going to be installed
                      Depends: libpcl-io-1.6-dev but it is not going to be installed
                      Depends: libpcl-kdtree-1.6-dev but it is not going to be installed
                      Depends: libpcl-keypoints-1.6-dev but it is not going to be installed
                      Depends: libpcl-registration-1.6-dev but it is not going to be installed
                      Depends: libpcl-sample-consensus-1.6-dev but it is not going to be installed
                      Depends: libpcl-search-1.6-dev but it is not going to be installed
                      Depends: libpcl-segmentation-1.6-dev but it is not going to be installed
                      Depends: libpcl-surface-1.6-dev but it is not going to be installed
                      Depends: libpcl-tracking-1.6-dev but it is not going to be installed
                      Depends: libpcl-visualization-1.6-dev but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Is there a way you can fix it to install it automatically? I will install them by hand and see how it goes

Kai

 

[Kai Franke]

I cannot get it to install :(
E: Package 'ps-engine' has no installation candidate
E: Package 'libflann1.7-dev' has no installation candidate

those are the packages I found to be missing up to this point

[mptho...@gmail.com]

Darn.  Looks like a made a mistake in the dependency lists.  I'll take a look and start a new build for tonight with the corrections.  Sorry about that.

Mike

[HCW]

Hi I tested the Openni packages on my Rpi with an Xtion.

Unfortunately i get a load of nealry 100% and a FPS of 15. With the OpenNI2 i had a load of 15% and a FPS of 30.
Kind Regards

Hauke

[mptho...@gmail.com]

I fixed the dependencies for building the source package, but forgot to change the dependencies for the binary packages.  I'm rebuilding the packages and will post them sometime tomorrow.  I'll also make sure I can load the packages on my Pi first.

Mike

[mptho...@gmail.com]

Hmmm, I guess some major performance improvements have been made in OpenNI2.  Does anyone know if a Debian package has been created for OpenNI2 that I can adapt to Raspbian?

Mike

[blackstag]

Which stream were you getting that performance out of.

[HCW]

Am Mittwoch, 30. Januar 2013 13:43:26 UTC+1 schrieb Black Stag:

Which stream were you getting that performance out of.

The NiSimpleRead sample only requests depth streams in both versions. This is what i tried.

Regards

Hauke

[Kai Franke]

30fps with 15% CPU is hard to believe, 15fps would be an amazing performance. As far as I know SimpleRead only outputs the middle pixel, so maybe they implemented a better method to retrieve single pixels. Did you try to stream the depth image at all?
Kai

[mptho...@gmail.com]

I got another build, but I found another dependency issue that had to be fixed.  Ugh.  Another 10 hour build cycle.  I should have working PCL packages late tonight.

Mike

[HCW]

Am Mittwoch, 30. Januar 2013 17:26:39 UTC+1 schrieb Kai Franke:

30fps with 15% CPU is hard to believe, 15fps would be an amazing performance. As far as I know SimpleRead only outputs the middle pixel, so maybe they implemented a better method to retrieve single pixels. Did you try to stream the depth image at all?
Kai

I also tried MWClosestPointApp, which runs at 24fps with load of 15% also. This sample scans the whole depth image and finds the closest point.

If you want to transfer the data to SD card or via network, you might get slower performance of course.

Try yourself, if you dont believe... 8.->

Regards

Hauke

[HCW]

Am Mittwoch, 30. Januar 2013 17:26:39 UTC+1 schrieb Kai Franke:

30fps with 15% CPU is hard to believe, 15fps would be an amazing performance. As far as I know SimpleRead only outputs the middle pixel, so maybe they implemented a better method to retrieve single pixels. Did you try to stream the depth image at all?
Kai

Hi Kai.

In order to let you easier check out the stuff, here is my git repo with my changes:

https://github.com/hcw70/OpenNI2 branch raspberrypi-fixes.

Just to clarify a few things (as far as i know):
- They changed the SW architecture between OpenNi and OpenNI2 in a major way that now the skeleton tracking sits above the OpenNi2, and not within the OpenNi layer).

- Skeleton tracking et al is part of the (closed source) Nite framework which i did not ran here.

- Without skeleton tracking, the task is more or less reading an image stream (depth / color) from an USB device (like done with a webcam).

- Depht calculation is done completely within the Xtion / Kinect device.

- Within the examples i tried there is not much post-processing of the data (except maybe some calculations to mm distances).

- "Displaying" the image stream cost alot CPU power also. Thats why some People report "1-2FPS with NiViewer". Especially on the Pi XServer which does not have HW-OpenGL support. Maybe someone writes an OpenGL-ES viewer for OpenNi...

So 15% for reading the data stream is not much, but could also be lower as the minimum CPU usage on the Rpi to get to the depht stream of an XTion i think.

Any post processing will add to the 15%, so the data amount must be reduced prior to further calculations.

Kind regards

Hauke

[Kai Franke]

Hauke,

thanks for the clarification, I found that just transmitting raw images through ethernet would raise the CPU usage to 100% on the RasPi using image_transport. I would really like to know why OpenNi2 is so much faster than OpenNi. Is there any way you can find out? I will try out your OpenNi2 fixes later, right now I am still compiling PCL 1.6 with Openni support ;)

Kai

[mptho...@gmail.com]

OK, I'm pretty sure I have a Raspbian build PCL binary packages that don't have dependency issues.  They can be found here:

http://ros.raspbian.org/repo/ros/pool/main/p/pcl-1.6/

These packages were built against the newer libopenni-dev package rather than the older openni-dev and ps-engine packages which look like they'll port to Arm very well.

The URL to add to your /etc/apt/sources.list file so these files can be installed with apt-get is the following:

deb http://ros.raspbian.org/repo/ros wheezy main

Good luck.  If there are any problems with the package let me know and I'll see what I can do.  After building the package three times I'm getting pretty good at building.  Sigh...

Any other packages that ROS is dependent upon, but aren't yet in the Raspbian?

Mike

[Kai Franke]

I did not get to try out your PCL package but I found another package which would be great to have as a binary.
https://github.com/flexible-collision-library/fcl.git

This package will be needed by the moveit! package which will replace arm-navigation as soon as it is released :)
I will try to build it from source and report any difficulties

Kai

[mptho...@gmail.com]

Kai,

Do you know if someone else has created a Debian/Ubuntu package of FCL?  A google search didn't seem to turn any up for me.

Mike

[Kai Franke]

Mike,

there is a debian package for it in the ros repository called ros-groovy-fcl
I just installed it from source which worked fine. The only dependency is libccd which also compiled just fine. There will be a few more packages to build for moveit, I will write everything down in the last section of the wiki

Kai

[mptho...@gmail.com]

Kai,

Given what Tully and Paul said at the HomeBrew Robotics Club meeting last night concerning Willow's efforts to create ROS binary packages for the Raspbian, I'm not too inclined to create packages which overlap with the ros-groovy packages.  It seems like it's a pretty high priority and efforts outside of Willow would probably be duplicating work that will happen anyway.  I would presume the package ros-groovy-fcl would be part of the porting effort to the Raspberry Pi.

I would suggest we wait a few weeks to see what progress Paul makes.  For now, I would like to concentrate on packages that are a known dependency for ROS, but aren't part of Raspbian similar to the other packages I already created.  If you think FCL does meet this criteria, let me know.  Perhaps I'm mistaken that its a part of ROS that will be in Willows porting efforts.

BTW, I did find a bunch of packages which probably would be useful to have on Raspbian.  FCL is part of them.  These are part of the Golem project at Georgia Tech.  Unfortunately, these packages don't include the debian control source used to generate the packages, otherwise it would be very easy to port them to Raspbian.  I'll send an email and see if I can find some information on them.

Mike

[Kai Franke]

Mike,

I think fcl qualifies for your build farm :)
According to the ROS wiki FCL will no longer be a ROS package starting with groovy.

Kai

[mptho...@gmail.com]

I see.  I'll see what I can do.  I haven't been able to find standalone .deb files for FCL that I can adapt for Raspbian.  I'll likely have to create by own .deb control files to build the package and that will take a bit of time.

Mike

[Kai Franke]

Mike,

Could you build the latest OpenCV version for Rasbian as well? I just tried to compile ROS from scratch using your package. It fails because ROS tries to access an enum with values that only exist in later versions

Kai

[Mike Thompson]

OK, I'll see what I can do and report back.

Mike

[mptho...@gmail.com]

OK, I kicked off a build of the OpenCV 2.4.3 binary packages for Raspbian.  It's 70 Mb of compressed sources so this thing is very likely going to take quite a while to build.  I'll let you know how it goes.  Fortunately it already seems to know how to build armhf packages so I didn't have to fiddle with the package control files, but hopefully it doesn't monkey around armv7 specific code for the armhf build.

Mike

On Monday, February 4, 2013 7:51:47 PM UTC-8, Kai Franke wrote:

Mike,

[mptho...@gmail.com]

Kai,

Raspbian binary packages for OpenCV 2.4.3 are now part of the repository.  They can be found here:

http://ros.raspbian.org/repo/ros/pool/main/o/opencv/

Hopefully these will help in your efforts to build ROS from scratch for the Raspberry Pi.

Mike

[mptho...@gmail.com]

Kai,

I now have binary packages for fcl and ccd in my Raspbian repository.  Hopefully these are the correct versions needed for ROS.

Add the following to the /etc/apt/sources.list:

deb http://ros.raspbian.org/repo/ros/ wheezy main

sudo apt-get update
sudo apt-get install libfcl

Just for reference, these packages were built using the following information:

https://github.com/golems/dart/wiki/Faq
http://dart.golems.org/index.php?f=downloads/brew/

Mike

On Friday, February 1, 2013 10:59:41 AM UTC-8, Kai Franke wrote:

Mike,