Quantcast

A cross-compiling repository

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

A cross-compiling repository

Daniel Stonier

Greetings all,

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.

It seems that we're now having a few groups actively working at various stages cross-compiling with the RoS and rather than going it solo all the time, it would be good if we could pool resources. As I've mentioned before on the mailing list, I've been working at building an environment for cross-compiling that automates and simplifies the process and have tested it on the guinea pigs (err lads) at work who have little and often no experience with cross compiling. They seem to be taking to it well, so I'd like to go a step further and see if we can help the RoS scale down as well as its been scaling up.

What I'd like to propose as goals for the project.

  • Simplify the cross compiling environment for the ros with tools, packages, documentation and contact points.
  • Be responsible for testing, maintaining and providing patches upstream to ros that enable embedded ros'.
  • Be a collective group that is willing to work together/share problems common to cross-compiling and more particularly cross-compiling in general.
  • Provide guides/tools that enable building of simple root filesystems running the ros.
  • Provide guides/tools for development on common targets (including emulations).
  • Endeavour to keep a watch (and provide fixes) on ros/ros stacks so that as much as possible correctly cross compiles.

What I envisage us needing at least to get kick started:
  •  An official ros package repository with tools and build scripts dedicated to cross-compiling accompanied by good documentation for the ros websites
    • A library of cmake modules representing different toolchains*
    • A library of cmake modules representing different platforms*
    • Python scripts of many sorts...*
    • Packages which provide cmake build scripts for ros dependencies, e.g. boost, apr, apr-log*
    • Cross compiling test packages such as msg_latency, rpc_latency*
    • Maintains patches for the ros which automatically apply on selection of a toolchain (until the patches get merged upstream)*
    • Tools for building simple embedded ros root filesystems (or instructions).
  • A dev area (e.g. redmine with issue tracker, wiki and forum) where cross compiling issues can be tracked and discussed.
  • An irc room for live interaction.

Some of these tools* we're already using at Yujin and are bundled in the ecl (link below). However I think its both simpler and better if I unbundle them and commit them to a project with a single focus. To give some idea of their usage currently in the ecl and at Yujin:

To kick start I'm thinking of opening a google code project to simplify and transfer the ecl build components and a redmine project at snorriheim for a dev area. My schedule is a bit tight until september when I'll have about two weeks free time to really work on it, but I'd like to canvas here first for some opinions or advice and see if there are other interested parties that would like to participate or also provide some input.

Any thoughts/suggestions?

Regards,
Dr Daniel Stonier,
Yujin Robot.

PS I'm not sure I'd call myself an embedded expert yet - still very much learning and thanks to Yujin, doing it very fast and very hands on (aka dancing in the frying pan!). However as a group, I think we can do better than we're currently managing in the cross compiling arena and I also think the ros has alot of potential for assisting in embedded development as systems get more and more complex.

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

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A cross-compiling repository

Jack O'Quin
On Wed, Aug 4, 2010 at 9:11 AM, Daniel Stonier <[hidden email]> wrote:

>
> Greetings all,
>
> 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.
> It seems that we're now having a few groups actively working at various
> stages cross-compiling with the RoS and rather than going it solo all the
> time, it would be good if we could pool resources. As I've mentioned before
> on the mailing list, I've been working at building an environment for
> cross-compiling that automates and simplifies the process and have tested it
> on the guinea pigs (err lads) at work who have little and often no
> experience with cross compiling. They seem to be taking to it well, so I'd
> like to go a step further and see if we can help the RoS scale down as well
> as its been scaling up.
> What I'd like to propose as goals for the project.
>
> Simplify the cross compiling environment for the ros with tools, packages,
> documentation and contact points.
> Be responsible for testing, maintaining and providing patches upstream to
> ros that enable embedded ros'.
> Be a collective group that is willing to work together/share problems common
> to cross-compiling and more particularly cross-compiling in general.
> Provide guides/tools that enable building of simple root filesystems running
> the ros.
> Provide guides/tools for development on common targets (including
> emulations).
> Endeavour to keep a watch (and provide fixes) on ros/ros stacks so that as
> much as possible correctly cross compiles.
>
> What I envisage us needing at least to get kick started:
>
>  An official ros package repository with tools and build scripts dedicated
> to cross-compiling accompanied by good documentation for the ros websites
>
> A library of cmake modules representing different toolchains*
> A library of cmake modules representing different platforms*
> Python scripts of many sorts...*
> Packages which provide cmake build scripts for ros dependencies, e.g. boost,
> apr, apr-log*
> Cross compiling test packages such as msg_latency, rpc_latency*
> Maintains patches for the ros which automatically apply on selection of a
> toolchain (until the patches get merged upstream)*
> Tools for building simple embedded ros root filesystems (or instructions).
>
> A dev area (e.g. redmine with issue tracker, wiki and forum) where cross
> compiling issues can be tracked and discussed.
> An irc room for live interaction.
>
> Some of these tools* we're already using at Yujin and are bundled in the ecl
> (link below). However I think its both simpler and better if I unbundle them
> and commit them to a project with a single focus. To give some idea of their
> usage currently in the ecl and at Yujin:
>
> Partial cross guide :
> http://snorriheim.dnsdojo.com/redmine/wiki/ecl/Partial_cross_compile
> Full cross guide :
> http://snorriheim.dnsdojo.com/redmine/wiki/ecl/Full_cross_compile
> Build tools :
> http://snorriheim.dnsdojo.com/redmine/wiki/ecl/Ecl_ros_python_tools
> CMake toolchains/platforms :
> http://snorriheim.dnsdojo.com/redmine/embedded/ecl/ecl_build/html/index.html
> Ros deps : http://snorriheim.dnsdojo.com/redmine/wiki/ecl/Ecl_cross
> Embedded opencv (no gui and utilises rosconfig.cmake) :
> http://snorriheim.dnsdojo.com/redmine/embedded/ecl/ecl_opencv/html/index.html
>
> To kick start I'm thinking of opening a google code project to simplify and
> transfer the ecl build components and a redmine project at snorriheim for a
> dev area. My schedule is a bit tight until september when I'll have about
> two weeks free time to really work on it, but I'd like to canvas here first
> for some opinions or advice and see if there are other interested parties
> that would like to participate or also provide some input.
>
> Any thoughts/suggestions?

Sounds like a good idea to me.
--
 joq
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A cross-compiling repository

Koen Buys
It sounds like a good idea, in our lab we're using ROS on OMAP 3530
(Beagleboard and Igep) and should be
compatible with the popular gumstix.

On 4 August 2010 16:47, Jack O'Quin <[hidden email]> wrote:

> On Wed, Aug 4, 2010 at 9:11 AM, Daniel Stonier <[hidden email]> wrote:
>>
>> Greetings all,
>>
>> 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.
>> It seems that we're now having a few groups actively working at various
>> stages cross-compiling with the RoS and rather than going it solo all the
>> time, it would be good if we could pool resources. As I've mentioned before
>> on the mailing list, I've been working at building an environment for
>> cross-compiling that automates and simplifies the process and have tested it
>> on the guinea pigs (err lads) at work who have little and often no
>> experience with cross compiling. They seem to be taking to it well, so I'd
>> like to go a step further and see if we can help the RoS scale down as well
>> as its been scaling up.
>> What I'd like to propose as goals for the project.
>>
>> Simplify the cross compiling environment for the ros with tools, packages,
>> documentation and contact points.
>> Be responsible for testing, maintaining and providing patches upstream to
>> ros that enable embedded ros'.
>> Be a collective group that is willing to work together/share problems common
>> to cross-compiling and more particularly cross-compiling in general.
>> Provide guides/tools that enable building of simple root filesystems running
>> the ros.
>> Provide guides/tools for development on common targets (including
>> emulations).
>> Endeavour to keep a watch (and provide fixes) on ros/ros stacks so that as
>> much as possible correctly cross compiles.
>>
>> What I envisage us needing at least to get kick started:
>>
>>  An official ros package repository with tools and build scripts dedicated
>> to cross-compiling accompanied by good documentation for the ros websites
>>
>> A library of cmake modules representing different toolchains*
>> A library of cmake modules representing different platforms*
>> Python scripts of many sorts...*
>> Packages which provide cmake build scripts for ros dependencies, e.g. boost,
>> apr, apr-log*
>> Cross compiling test packages such as msg_latency, rpc_latency*
>> Maintains patches for the ros which automatically apply on selection of a
>> toolchain (until the patches get merged upstream)*
>> Tools for building simple embedded ros root filesystems (or instructions).
>>
>> A dev area (e.g. redmine with issue tracker, wiki and forum) where cross
>> compiling issues can be tracked and discussed.
>> An irc room for live interaction.
>>
>> Some of these tools* we're already using at Yujin and are bundled in the ecl
>> (link below). However I think its both simpler and better if I unbundle them
>> and commit them to a project with a single focus. To give some idea of their
>> usage currently in the ecl and at Yujin:
>>
>> Partial cross guide :
>> http://snorriheim.dnsdojo.com/redmine/wiki/ecl/Partial_cross_compile
>> Full cross guide :
>> http://snorriheim.dnsdojo.com/redmine/wiki/ecl/Full_cross_compile
>> Build tools :
>> http://snorriheim.dnsdojo.com/redmine/wiki/ecl/Ecl_ros_python_tools
>> CMake toolchains/platforms :
>> http://snorriheim.dnsdojo.com/redmine/embedded/ecl/ecl_build/html/index.html
>> Ros deps : http://snorriheim.dnsdojo.com/redmine/wiki/ecl/Ecl_cross
>> Embedded opencv (no gui and utilises rosconfig.cmake) :
>> http://snorriheim.dnsdojo.com/redmine/embedded/ecl/ecl_opencv/html/index.html
>>
>> To kick start I'm thinking of opening a google code project to simplify and
>> transfer the ecl build components and a redmine project at snorriheim for a
>> dev area. My schedule is a bit tight until september when I'll have about
>> two weeks free time to really work on it, but I'd like to canvas here first
>> for some opinions or advice and see if there are other interested parties
>> that would like to participate or also provide some input.
>>
>> Any thoughts/suggestions?
>
> Sounds like a good idea to me.
> --
>  joq
> _______________________________________________
> ros-users mailing list
> [hidden email]
> https://code.ros.org/mailman/listinfo/ros-users
>
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A cross-compiling repository

René Wagner
In reply to this post by Daniel Stonier
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
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A cross-compiling repository

Cedric Skybotix
Hello,

just my 2 cents here, but I've worked with OE and with a stripped down
arm ubuntu (or debian for that matter), and I really enjoyed much more
the packet system of ubuntu. I really love to just be able to apt-get
install minicom or gdb, or a specific library.

For that, I vote for whatever cross-compiling that results in a nice
package management system.

Cheers

On 08/04/10 21:28, René Wagner 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
>
>    


--
Dr. Cedric Pradalier
http://www.asl.ethz.ch/people/cedricp

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A cross-compiling repository

Daniel Stonier
In reply to this post by René Wagner


On 5 August 2010 04:28, René Wagner <[hidden email]> 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
[hidden email]
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

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A cross-compiling repository

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

On 5 August 2010 14:44, Daniel Stonier <[hidden email]> wrote:


On 5 August 2010 04:28, René Wagner <[hidden email]> 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
[hidden email]
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

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A cross-compiling repository

Daniel Stonier
In reply to this post by Cedric Skybotix


On 5 August 2010 07:22, Cedric Pradalier <[hidden email]> wrote:
Hello,

just my 2 cents here, but I've worked with OE and with a stripped down
arm ubuntu (or debian for that matter), and I really enjoyed much more
the packet system of ubuntu. I really love to just be able to apt-get
install minicom or gdb, or a specific library.

For that, I vote for whatever cross-compiling that results in a nice
package management system.

Cheers

 
Us also, for our intel atoms - I was using a hand made system and then a crossdev built system, but did some testing and for control stuff at least, the stripped down ubuntu was just as fast. It's only if you put too many debs inbetween the baseline and your control programs that you start noticing a non-optimised slowdown. But if you compile/optimise the important things inbetween, it's still fast and the debs give you easy access to all the tools (which don't need to be optimised) you need. 

You only get in trouble when the distro doesn't have a repo for your core - I think ubuntu only supports certain flavours of arm cores for instance.

 
On 08/04/10 21:28, René Wagner 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
>
>


--
Dr. Cedric Pradalier
http://www.asl.ethz.ch/people/cedricp

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users



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

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A cross-compiling repository

tfoote
In reply to this post by Daniel Stonier
With respect to being able to extend rosdep, that is definitely a possibility.  Right now it is abstracted based on the detected OS however it can be overridden by using environment variables to set the OS.  If you define your own OS there is an abstracted interface which rosdep uses, through which the arguments from rosdep.yaml are passed.  From which you create a script to run.  Right now everything is assumed to be a bash script, but there are thoughts of extending it to python for better cross platform support.  

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



--
Tully Foote
Systems Engineer
Willow Garage, Inc.
[hidden email]
(650) 475-2827

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Loading...