[ros-users] A cross-compiling repository

Thu Aug 5 05:44:44 UTC 2010

On 5 August 2010 04:28, René Wagner <rene.wagner at dfki.de> wrote:

> Hi Daniel,
>
> I guess I should start by saying that as a former OpenEmbedded (OE)
> developer I may be somewhat biased but I thought I'd chime in with a few
> thoughts anyway.
>
> On Wed, 2010-08-04 at 23:11 +0900, Daniel Stonier wrote:
> > This is targeted at anyone who is either working with a fully
> > cross-compiled ros or simply using it as a convenient build
> > environment to do embedded programming with toolchains.
>
> The risk I see with this approach is that you will inevitably end up
> replicating a lot of work that has gone into existing cross-compilation
> environments. One of the things that I believe make ROS beautiful is
> that, despite its name, it's not an operating system. It sits on top of
> any (more or less) supported operating system providing additional
> services where necessary and leveraging existing facilities where
> possible.
>
> As far as the build environment is concerned, the interface between ROS
> and the OS is the part of rosdep that translates dependencies into
> native package names and calls the OS-provided package management system
> to install those. I think it would be ideal if the cross-compilation use
> case could be covered by similar means. This is particularly important
> since the complexity of a cross-compilation environment tends to grow
> exponentially with the number of targets supported.
>
> [I'll focus on OE now simply because it's easiest for me to judge the
> feasibility of this approach with OE.]
>
> The way I think this could work with OE is, roughly, as follows:
>
> 1. Set up OE and ROS for the desired target in a well-defined matter,
>   i.e. such that paths follow a certain, predictable, pattern. This
>   could be scripted or even GUI-driven and is required such that OE can
>   be invoked from ROS tools (and possibly vice-versa).
> 2. Export relevant variables (paths, compilers flags, etc.) from OE as a
>   cmake toolchain description file and instruct ROS to use that.
> 3. Rely on rosdep to call bitbake (the OE build tool) to build
>   system-dependencies (the toolchain and any packages already present
>   in OE such as boost/apr/etc.) and install them in the cross
>   environment. Otherwise use rosmake as usual.
> 4. To build ROS packages (.deb, .ipk, .opk, etc.) for the target,
>   rosmake (or some other tool) would generate a package description
>   file (.bb) for OE, mainly consisting of the exported dependencies, a
>   call to rosmake and information on where to find
>   executables/libraries built by rosmake, and again invoke bitbake.
> 5. Root filesystem or image creation would be left to OE. The only thing
>   OE needs to know is a list of the packages built in 4.
>
> Obviously, there are still some details to be worked out but the overall
> approach should keep the amount of cross-compilation specific code in
> ROS to a minimum and instantly allow people to run ROS on any
> OE-supported target (With vendors like Gumstix officially supporting OE
> there are quite a few of these nowadays).
>
> Cheers,
>
> Rene
>
> --
> ------------------------------------------------------------
> Dipl.-Inf. René Wagner                     Junior Researcher
> DFKI Bremen                           Enrique-Schmidt-Str. 5
> Safe and Secure Cognitive Systems             D-28359 Bremen
>
> Phone: (+49) 421-218-64224       Fax: (+49) 421-218-98-64224
> Web: http://www.informatik.uni-bremen.de/agebv/en/ReneWagner
> --- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> Deutsches Forschungszentrum für Künstliche Intelligenz  GmbH
> Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern
>
> Geschäftsführung:
>   Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
>                                          Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats:
>                                Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern                          HRB 2313
> ------------------------------------------------------------
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>

My thoughts long term are actually really similar. From my experience, there
are usually four attack vectors to setting up a platform

   - Generate their os's entirely (using oe, t2, crossdev or by hand)
   - A supplier provides a board support package, i.e. toolchain + kernel +
   filesystem
   - Build by hand
   - If you're lucky enough to have a compatible board, use a stripped down
   distro like cedric

Short term and for those who use a board support package (which means we're
usually dealing with a very light embedded system), a few ros packages that
are effectively cmake build scripts is an easy way to get people to bridge
the gap from bsp to ros-enabled bsp.

There are also other packages which can benefit from being compiled from
source within the ros environment rather than as a generic distro package by
utilising your ros optimisations (specific cflag settings) which aren't
typically enabled in distro packages. This can be quite important for
various control libraries. Opencv is an obvious candidate with vectorisation
flags (sse or altivec).

Long term, along the same lines as you've mentioned, I'd really like to
connect ros(dep) to leverage one of the system builders. I've got no
inclination (or time!) to replicate all the work currently done by others.
Recycle/reuse... Until now, I've used crossdev, which I think's fantastic
and alot simpler than OE for building a simple control platform, but it's
constrained to gentoo. I don't have much chance teaching my korean
colleagues gentoo and any generic solution we look for needs to be more
general. I'm going to have to do a bit of learning though, or grab some folk
who already know such a system well.

-- 
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin Robot: http://www.yujinrobot.com/
Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100805/80efaa62/attachment-0003.html>