On 5 August 2010 04:28, René Wagner <rene.wagner@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@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

 
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