Hi Ceci, I was hoping that Victor Mayoral would have answered your question, as he is our Beaglebone and Angstrom expert. Being maintainer, I usually work with the development versions of openembedded-core and meta-openembedded, and not with the Angstrom distribution. Unfortunately, I also do not have a Beaglebone at my hands.
Can you provide more information, which steps you do and which error message was shown exactly? Then, I can try to replay it on a qemuarm image and see if the problem occurs in the qemuarm image as well. Lukas Am Donnerstag, 30. Januar 2014 10:36:54 UTC+1 schrieb Ceci: > > Hi! > > I am also trying to work with ROS on the Beaglebone using Angstrom. > I have followed all the steps on the ROS tutorial, and ROS is running on > the Beaglebone. > I also built Angstrom on my laptop (which has Ubuntu installed on it), and > I can compile bitbake recipes. I have tried with the beginner-tutorials and > the bb-dc-motors. This works ok. > The problem appears when I try to install the packages (.ipk) on the > Beaglebone. The error message that I get is "Packages for > beginner-tutorials found, but incompatible with the architectures > configured". > Any ideas on what is going on? > > Thanks a lot. > > Ceci > > Am Dienstag, 21. Januar 2014 08:40:15 UTC+1 schrieb Lukas Bulwahn: >> >> Dear Brice, >> >> One of the assumptions for the use of a cross-compiling tool chain is >> that you want to develop (i.e., write code), compile and build on a >> larger non-embedded computer (e.g., your own PC or laptop) and then at >> some stage, package and release it, and update the embedded target >> system. The reasons for cross-compiling are diverse. For example, it is >> impossible to compile the software on the embedded target system because >> the target system does not have enough memory or is so slow that >> compiling takes many hours. It is also common that your team works on >> various pieces of the software on their local machines, as you do not >> provide the embedded target system for every developer, and instead the >> whole team shares one target system for testing. >> >> Following this motivation, developing, compiling and building own >> packages directly on the board is not a primary use case for a >> cross-compiling tool chain. Hence, we do not support it, and doing it on >> your own is difficult or seems even impossible. >> >> Instead, I will try to describe a possible way for development and >> deployment with the OpenEmbedded distributions (the distro-less >> OpenEmbedded-Core, Angstrom, Poky): >> >> Your setup: >> >> - You set up your development environment for your own ROS packages that >> allows you to package the sources, i.e., you have a git repository >> and/or can simply release archive files with increasing version numbers. >> >> - You create your own small OpenEmbedded layer and add the recipes for >> your own ROS packages. >> >> - You set up your build infrastructure, e.g. Angstrom or >> OpenEmbedded-Core + meta-ros, to cross-compile the Linux and ROS sources >> for your embedded machine. >> >> - You set up your base target system with a software update manager, >> e.g., the smart software updater, to fetch updates from your build >> infrastructure. >> >> Now, you can have the following work-flow: >> >> 1. Develop, compile and test your ROS packages on your local machine >> (not matter which architecture). >> >> 2. You release your ROS packages, e.g., by committing a changeset to the >> git repository or tagging a new version. >> >> 3. Cross-compile your ROS packages on your build machine and it is >> automatically added to the software repository >> >> 4. You update the software on your target system using the software >> updater to download the new version and its dependencies. >> >> 5. You test the software on your target system. >> >> There are different documents from the Yocto Project, Angstrom and >> meta-ros to help with the various steps. Maybe, others on this mailing >> list can suggest which chapters of which manuals are best to understand >> how to setup the development environment and step through the sketched >> workflow. >> >> Lukas >> >
