On a side note, does anyone on the list have any experience with T2? On 5 August 2010 14:44, Daniel Stonier wrote: > > > On 5 August 2010 04: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 >> >> -- >> ------------------------------------------------------------ >> 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 > > > - 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