Hi there. We’re looking at implementing ROS from the ground up to replace the charging, control, and motion capabilities of our robotic camera. While I have a few years of experience supporting creating BSPs and recipes for yocto, I have yet to play with ROS. I wanted to gauge the current functionality of ROS in yocto/OE. Seems like for meta-ros the Igloo release is fully in master, there are experimental branches to support Kenetic, and then there is another parallel effort using superflore to automatically generate a ROS distribution for use in OE.
We’re hoping to get up an running for our commercial product and shipping within a month. While we have tools and automation in place for yocto, are we better off reinventing our tools and automation for Ubuntu instead of sticking with yocto giving our timeline.
Happy to help test or get these working under yocto, just curious which branch or release I should focus on first.
You say you have no experience with ROS and you want to use it for a commercial product that ships in under four weeks? That is a rather impressive goal.
If you are pressed for time you’d be best to take the road well traveled, the one where the potholes are mostly smoothed over and where there are others who you can ask for help. ROS on Ubuntu on PC hardware is the easy path.
With a very tight schedule I think “risk reduction” is the way to think.
Using Yocto is risk reduction to me. We already have plenty of tools that leverage yocto and openembedded. Going to Ubuntu involves reinventing the wheel from a package selection, base os, monitoring, and automation standpoint. Not to mention the package size, loss of package control, tight integration, and overinflated size of the base OS that we lose just by using it. Should be only a few weeks at most to integrate ROS layer in OE, whereas redoing everything in ubuntu, puts this out to months for implementation.
Anyway, anybody have any thoughts of maturity and functionality of the openembedded layers available? Or do we reinvent or wheels in place for Ubuntu as Chris has suggested.
We’re looking at implementing ROS from the ground up […] I have yet to play with ROS, […] We’re hoping to get up an running for our commercial product and shipping within a month.
Irrespective of the build/deployment infrastructure that you end up going with, that seems like a short time.
As meta-ros maintainer for five years by now (time flies like an arrow), I obviously have a strong bias for meta-ros. So, I probably cannot give you an unbiased advice on using OpenEmbedded or Ubuntu. Furthermore, I have not maintained an Ubuntu ROS system for five years.
I assume you are well aware of the strong and weak points of OpenEmbedded and The Yocto Project. So, I will just point out the current status of meta-ros:
We offer recipes for about 200 ROS packages (all basic packages are covered). If that is enough for you, you might quickly get your full product ready. If you need OpenBLAS or OpenNI2, you will face some challenges. Some users are working on that for some time as it seems (visible on the github forks), but they did not provide pull requests yet.
The indigo branch is maintained and kept in sync with the ROS distribution release updates.
The kinetic branch is experimental (well, just a few packages maintained in indigo don’t run yet on kinetic, but I did not move that to 100% completion yet) and it is not kept in sync with the release updates at the moment, again due to limited time for maintenance and as there isn’t any user asking loud enough for proper maintenance and support of kinetic.
The lunar branch is an experimental branch from @allenh1; I do not know its current state, but I think it is probably also close to 100% completion of all 200 packages cross-compiling, but not completely there yet.
We have a CI system running that checks each pull request against the current master of openembedded-core and meta-openembedded, but we currently do not check on regular basis on a public system if the latest commit always works with the latest master commit of its dependent layers. We also try to keep changes backwards-compatible, but we do not test and maintain specific branches for Yocto releases. All other testing is really just other users (and me) test-building the recipes on a regular basis. If you want to improve the situation concerning CI testing, @rojkov and I can provide all information of our testing infrastructure.
SDK support is still not merged yet, but some users have experience with it; but I could not find time to test it. If that is important to you, let me know and we can move this topic forward together in the main-line repository.
I know that @vmajoral and his company explored the use of meta-ros a few years ago in 2013/2014, and he decided to build their embedded systems with Ubuntu. He might provide you reasons why he ultimately decided for Ubuntu.
Also, here is an interesting comparison from @trainman419 at ROSCon 2014 (again, from the developer around ROS ARM Ubuntu, so possibly biased in the other way):
I hope that helps.
Which ROS packages do you need? What features do you need? Which qualities do you expect?
Help is certainly appreciated; I have a long list of topics, but probably it is best to know what would be important to you and move those things forward collaboratively.
if you already have experience in yocto, stick with it. It is the only way to make a product with ros. Especially, because it is much more easy to get a realtime kernel, which you will need at some point, if you aim to place your product in the automation industry (and you don’t want it to suck).
I am working with meta-ros (kinetic) and I find it quite useful!
Thanks for the votes of support. I would agree with using HorstLocal, and appreciate the feedback and support bulwahn in providing an updated layer to utilize kenetic. I have imported in the latest experimental branch, and things work well thanks to the large community effort around it. Now to clean up the disk space to get it all to compile.
