[ros-users] A cross-compiling repository

Daniel Stonier d.stonier at gmail.com
Thu Aug 5 05:47:42 UTC 2010


On a side note, does anyone on the list have any experience with T2?

On 5 August 2010 14:44, Daniel Stonier <d.stonier at gmail.com> wrote:

>
>
> 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
>



-- 
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/c47dfb02/attachment-0003.html>


More information about the ros-users mailing list