[ros-users] Ros on Gumstix: another way of doing it...

Wed May 5 23:44:18 UTC 2010

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