Radu Bogdan Rusu wrote: > Cedric, > > Thanks for sharing your experiences with ROS on gumstix! There's a lot of valuable information here, and in order for it > to "live on", would you mind setting up a wiki page? I know there's other people out there working on the same thing, so > if we could centralize this information, that would be great! :) Thank you in advance. > > Cheers, > Radu. > Hi Radu, I'd be happy to create/update the wiki page (I've actually preformatted the email to make it easy to integrate as wiki page). Can anybody contribute to the pages, or do I need a specific account? Thanks for your positive feedback. > Cedric Pradalier wrote: > >> Hi all, >> >> I have been spending some effort on making ROS compiling for the gumstix >> and I'd like to share the experience: >> >> First of all, I have tried the approach listed on the wiki, and they are >> not my favourite but they provide a good basis. >> >> The first thing I have done is installing ubuntu on the gumstix (a guide >> for that can be found on >> http://johnwoconnor.blogspot.com/2009/04/installing-ubuntu-on-gumstix-overo.html) >> This simplifies a lot the process of getting all the 3rd party libraries >> compiled (in particular boost, xmlrpc++, log4cxx, apr can then just be >> obtained using an apt-get call). >> >> Once you have installed ubuntu on the gumstix, you could in theory >> install all the -dev packages and gcc/g++ and compile everything >> natively. Needless to say that it might be a little bit long given the >> performances of the gumstix. However, this is a working solution. >> >> The second solution is to run a gumstix image using qemu and in >> particular qemu-system-arm (package qemu-kvm-extras in ubuntu 9.10). To >> this end, you first need to setup a disk image, mount it, copy the file >> system created using the link above. >> #> qemu-img create overo-ros.img 2G >> #> mkdir overo-ros >> #> mount -o loop overo-ros.img overo-ros >> #> cd overo-ros >> #> sudo tar -zxvf /path/to/armel-rootfs-YYYYMMDDhhmm.tgz >> >> At this point the file system can be umounted and launched with qemu >> (get the kernel by following the instruction at >> http://people.canonical.com/~ogra/arm/qemu/README) >> >> #> umount overo-ros >> #> sudo qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.28-versatile >> -hda overo-ros.img -m 256M -append "root=/dev/sda" -net nic -net user >> >> I have not tried booting the image while it is still mounted. I suspect >> it does not work so well. >> >> Once qemu has started the image, one can easily apt-get arm packages and >> update the image to get all the -dev packages. It is also possible to >> install gcc and compile all ros in the virtual gumstix. However, this >> takes forever, even longer than on the real system. >> >> However, getting qemu running is not a loss of time. Once all the -dev >> packets have been installed, the ubuntu image can be used to >> cross-compile. To this end, I first quit qemu, and remount overo-ros. >> >> The following will assume you have a a cross compiler installed, for >> instance through buildroot or open-embedded (check the gumstix wiki). We >> can then use the -sysroot option of gcc to compile using the overo-ros >> directory as the root of the filesystem (where /usr/include and /usr/lib >> are looked for). However, at the time of this writing libtool is not >> able to pass a -sysroot option to gcc, so I write a set of scripts for >> gcc, g++ and cpp, respectively called gcc-sysroot, g++-sysroot, and >> cpp-sysroot. The scripts are as follows: >> >> #!/bin/bash >> if test -n "$ARM_SYSROOT" >> then >> SYSROOT=--sysroot=$ARM_SYSROOT >> fi >> exec ${0/-sysroot/} $SYSROOT $* >> >> The same script can be used for all the executable as it find which >> binary to call based on how it was called. >> >> Once the scripts are defined, I have a special gumstix compilation >> environment: >> export GUMSTIXTOP=$HOME/overo-oe/ >> export OVEROROOT=$HOME/overobuntu/overo-ros >> export >> PKG_CONFIG_PATH=$OVEROROOT/usr/local/lib/pkgconfig:$OVEROROOT/usr/lib/pkgconfig >> >> export ARM_SYSROOT=$OVEROROOT >> export CROSSBIN=$GUMSTIXTOP/tmp/cross/armv7a/arm-angstrom-linux-gnueabi/bin >> export PATH=$CROSSBIN:$PATH >> export AR=$CROSSBIN/ar >> export CPP=$CROSSBIN/cpp-sysroot >> export CXX=$CROSSBIN/g++-sysroot >> export CC=$CROSSBIN/gcc-sysroot >> >> >> Once this is sourced in the current shell, you can call rosmake >> normally, and everything should be able to compile. Obviously, rosdep >> install does not work (you have to restart the qemu thing and call >> apt-get from there, or at least that the easy solution I found). I have >> all the laser and image processing stack working in particular, even >> libdc1394 with the usb drivers for the pointgrey cameras. >> >> Please note that you need to recall "cmake ." in all the directories. >> This can be done for instance with a script such as: (not fully tested) >> >> roscd >> find . -name "CMakeCache.txt" | while read line >> do >> cd ${line/build\/CMakeCache.txt/} >> cmake . >> cd - >> done >> >> Beware that a couple of binary must be compiled native and crossed >> (rospack, rosstack and rosmsg). To this end, compile them first native, >> save them (for instance renaming it rospack.intel), then compile them >> crossed, save the crossed compilation for later installation (for >> instance renaming it rospack.arm), then make a link to the correct >> executable for the current architecture, and mark these directory >> ROS_NOBUILD (touch ROS_NOBUILD). This also applies to libraries such as >> librospack.so and librosstack.so. I hope the WillowGarage team finds a >> way to decouple these libraries for cross-compilation. >> >> It might also be necessary to delete all the .la files installed with >> the -dev package in ubuntu on the arm image. These files refers libtool >> to some libraries in /usr/include and /usr/lib, without using the >> -sysroot option. gcc/g++ sees the risk and does not accept to compile >> then. This is a problem in particular for libjpeg (compressed image >> transport). >> >> Using all the above, I have ros working on both the gumstix overo and >> verdex. On the overo, using wifi G, the gumstix can downstream telemetry >> data and video data from an helicopter, using either raw images or >> jpeg-compressed images (not much framerate gain). >> >> On the verdex, I need to change the timeout in rospy/client.py (TBC) to >> 20seconds as it is the time the systems needs to get roscore up and >> running (The disk access performance are extremely bad on this older >> board). If someone wants to run ROS on a verdex, please contact me, and >> I'll check exactly what I had to change to make it happen. Not that the >> file system mentioned above works for a verdex. >> >> Check on http://support.skybotix.com/downloads.php for a full filesystem >> for the gumstix overo, with ros pre-compiled (Skybotix is a company >> selling micro-helicopter with an embedded gumstix, but the file system >> should be a good starting point for any gumstix application) >> >> I hope all this information helps... >> >> > > -- Dr. Cedric Pradalier http://www.asl.ethz.ch/people/cedricp