combined ROS/machinekit installations: Debian packaging strategy unclear

Issue by mhaberler Sun Jan 10 18:45:46 2016 Originally opened as https://github.com/machinekit/machinekit/issues/857

we want to integrate with ROS (see #689) with the primary goal of machinekit becoming a configurable realtime appliance for ROS.

This suggests either:

a single-host combined installation of both the ROS driving layers and machinekit (typically running Ubuntu)
or a separate host with a bare-bones ROS install plus machinekit which would talk to a driving ROS instance remotely (which would typically be an embedded system, and Debian as our preferred distro)

Re (1) - while we currently do not build Ubuntu packages, a machinekit build from source works fine and is a reasonable workaround for now; and even building Ubuntu packages seems viable relatively cheap.

For (2) - which could become quite popular - switching to Ubuntu as target platform is not a realistic option - as it would hugely increase build and support load.

Assuming we build turnkey images for key platforms (like BB, and eventually select Xylinx+Altera SoC boards), we need a ROS package stream for Debian (currently indigo), to the extent the ROS layer can tap into a remote ROS instance.

ROS is currently not available in Debian, so the question of packaging for select embedded target platforms is open.

This issue addresses packaging issues only; actual ROS/machinekit interworking is dealt with in #689.

Comment by unseenlaser Sun Jan 10 18:53:51 2016

they do state that it builds on Debian , so should we attempt our own live cd with that purpose ? http://wiki.ros.org/Debian/Installation/Source

On 10 January 2016 at 18:45, Michael Haberler notifications@github.com wrote:

we want to integrate with ROS (see #689 https://github.com/machinekit/machinekit/issues/689) with the primary goal of machinekit becoming a configurable realtime appliance for ROS.

This suggests either:

a single-host combined installation of both the ROS driving layers and machinekit (typically running Ubuntu)

or a separate host with a bare-bones ROS install plus machinekit which would talk to a driving ROS instance remotely (which would typically be an embedded system, and Debian as our preferred distro)

Re (1) - while we currently do not build Ubuntu packages, a machinekit build from source works fine and is a reasonable workaround for now; and even building Ubuntu packages seems viable relatively cheap.

For (2) - which could become quite popular - switching to Ubuntu as target platform is not a realistic option - as it would hugely increase build and support load.

Assuming we build turnkey images for key platforms (like BB, and eventually select Xylinx+Altera SoC boards), we need a ROS package stream for Debian (currently indigo), to the extent the ROS layer can tap into a remote ROS instance.

ROS is currently not available in Debian, so the question of packaging for select embedded target platforms is open.

This issue addresses packaging issues only; actual ROS/machinekit interworking is dealt with in #689 https://github.com/machinekit/machinekit/issues/689.

— Reply to this email directly or view it on GitHub https://github.com/machinekit/machinekit/issues/857.

The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This mail and any attachments have been scanned for viruses prior to leaving the RcTechnix network. RcTechnix will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on.

RcTechnix reserves the right to monitor and record e-mail messages being sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring effective operation.

Comment by mhaberler Sun Jan 10 19:04:38 2016

It turns out that there is a Debian Science ROS effort underway which aims at getting ROS into debian.

Jochen Sprickerhof and Leopold Palomo-Avellaneda are driving this effort and it seems we could make use of their package stream - I got in touch with them and this is the exchange:

Von: Leopold Palomo-Avellaneda leo@alaxarxa.net Betreff: Aw: ROS/debian packages Datum: 8. Jänner 2016 um 18:48:56 MEZ An: Michael Haberler mah@mah.priv.at Kopie: Jochen Sprickerhof jochen@sprickerhof.de, Bas de Bruijn bdebruijn@luminize.nl, Charles Steinkuehler charles@steinkuehler.net

Hi Michael, Jochen, Bas and Charles :-D

El Divendres, 8 de gener de 2016, a les 11:50:56, Michael Haberler va escriure:

Hello Jochen, Leopold

(I put in Charles who is the original creator of our debian SD image for the BB)

Am 08.01.2016 um 11:08 schrieb Jochen Sprickerhof jochen@sprickerhof.de:

Hi Michael,

I've put Leopold Palomo-Avellaneda into Cc, as he is part of the effort. Hope it's ok to answer in English.

@Leo: Michael is part of machinekit.io and they are using Debian jessie on i386+amd64 and armhf and are looking into integrating ROS and asking for the current status.

Regarding jessie:

Leo provides a binary repo for i386+amd64 already, maybe we can add armhf there as well. I think in the long run we should switch this to [1], once we have everything in unstable. Would that help you?

that would in fact be very much help us.

Ok, I'm trying to build jessie-robotics for armhf. Give me some days. Now, that I begin to have for i386 to have another arch should no be difficult.

An armhf debian package stream we can rely on would enable us to produce combined ROS/machinekit turnkey images for a series of platforms, and that would be a huge boost.

A bit of background:

machinekit is multi-platform/multiarch and we focus on debian (also as a consequence of debian becoming the prime distro for embedded platforms AFAICT) - supporting ubuntu machinekit packages/builds from source is in principle possible but we would like to confine this to the desktops if at all - one reason for this is - we do provide a Beaglebone SD image with debian/xenomai/Machinekit turn-key, but multi-distro image variants are beyond our support capacity - newer platforms are coming up like the Xylinx and Altera Soc/FPGA platforms where such turnkey images would make sense and are in the works, but going dual-route is unsustainable

Great. I'm trying to maintain xenomai too. It seems that the debian maintainer is not longer active.

As a target scenario for combined ROS/machinekit RT configurations, this is likely to be confined to intelligent playout devices (like arms or robots with an embedded linux controller) - meaning a full desktop install is not needed and that is not what we are focusing on in embedded space anyway

we do have experimental manual installs on a BB/debian+ubuntu/indigo+machinekit from source working which get us over the initial hurdles, but building from source is problematic once we get to turnkey images; it turned out ROS-comm plus the occasional package added/compiled from source later is just fine for this purpose. Right now this is to enable experimentation; later we might let loose less experienced users and the guru factor needs to come down until then.

In summary: even if incomplete right now a debian armhf ROS stream would be an incredible enabler for us!

ok, we could help on this. Also, the Linaro guys maybe can help.

Note that ROS/machinekit integration is in an early stage, and we are not blocked by any debian package issue from doing our homework - meaning: We are looking for a perspective onto a reasonable armhf debian ROS stream in a few months from now which we can rely on, and integrate with.

So there is no need to jump any hoops right now and we are at leisure to work out any kinks.

In terms of package priorities we would need to do more soul-searching (and frankly learn more about ROS first); that said: we're working closely with the ROS-industrial folks, and everything controlling trajectories/moving motors/doing IO and "being generally close to RT" looks most fruitful to us

RT is the difficult ...

I am happy to work with you - like trying things out, report issues and be a generally good netizen; I think this applies to the other folks on the machinekit side as well - there is significant interest in this combination and everybody sees the upside of packaged distros as we have been through the pain before.

Since this is significant news for us I would like to repost this exchange in our tracker (https://github.com/machinekit/machinekit/issues/689) to keep the other folks in the loop - I hope this OK with you?

No problem. It's ok for me too.

the future looks so bright we'll need dark sunglasses ;)

:-)

Maybe we should begin to think to package ros-industrial ...

Leopold

PS have you think for control Orocos?

best regards

Michael Haberler

Regarding the current state:

You can find it on [2]. We have packaged almost all of ros-desktop-full and a lot of it passed the review by the ftp-masters already and is in unstable.

In general it's already usable (at least I use it on a daily basis and Leo is using it in his lab), but it could be still a little rough around the edges (bug reports welcome). Also, ROS contains much more packages and I don't think we are able to integrate all of them into Debian any time soon. But I've an initial version of a script to automatically port the Ubuntu package to Debian. Obviously they won't be as clean as the once we provide, but it's working. If you have a need for specific packages, we could prioritize them as well.

So in essence, would be great if you would use our packages, and if you find problems, we should be able to fix them in time.

Cheers Jochen

[1] http://backports.debian.org [2] https://wiki.debian.org/DebianScience/Robotics/ROS/Packages

Michael Haberler mah@mah.priv.at [2016-01-08 01:31]: Hallo Jochen,

ich bin in machinekit.io involviert, wo wir uns u.a. mit der Integration mit ROS beschäftigen (https://github.com/machinekit/machinekit/issues/689)

Unsere Platform ist debian jessie, und da einiges auf embedded läuft, hier neben i386+amd64 auch armhf; deswegen sind wir sehr an Eurem Projekt interessiert

Wie ist der Status der Sache? Was würdest Du uns empfehlen zu tun?

vielen Dank im voraus

Michael Haberler

Comment by mhaberler Sun Jan 10 19:07:50 2016

@unseenlaser - building from source is always possible, but this is not the only problem - without a package stream this means any subsequent package to be installed needs to be rebuilt, and the process of creating a turnkey SD image becomes very convoluted

that is why I am looking for a debian package stream, in particular jessie armhf

Working with Jochen and Leopold would help us a lot

Comment by rojkov Thu Jan 12 15:56:44 2017

without a package stream this means any subsequent package to be installed needs to be rebuilt, and the process of creating a turnkey SD image becomes very convoluted

I wonder if Yocto could be considered an option then? There's meta-ros layer for Yocto maintained by BMW. machinekit could be built on top of that.

Comment by luminize Thu Jan 12 19:41:10 2017

On 12 Jan 2017, at 16:56, Dmitry Rozhkov notifications@github.com wrote:

without a package stream this means any subsequent package to be installed needs to be rebuilt, and the process of creating a turnkey SD image becomes very convoluted

I wonder if Yocto could be considered an option then? There's meta-ros layer for Yocto maintained by BMW. machinekit could be built on top of that.

Building machinekit means having a debian system, Unless you intend to get all prerequisites for building MK in shape on the system of your choice. Building on debian is easiest by far.

But there are also a lot of setups which do not run on Yocto, like a PC with Mesa hardware. So I think a solution which works for all setups is easiest in the long run.

Comment by dkhughes Thu Jan 12 20:59:28 2017

Yocto does run with x86 hardware - Intel even maintains a branch that they use for boards like the Minnowboard. That being said, I came from that environment and moved to Debian with the Xilinx arm work @mhaberler and I did. Wow! How much easier it is to work with a real package manager... at least for me.

Does ROS really not offer debian packages? I thought some were available even if they aren't the most cutting edge.

Comment by luminize Thu Jan 12 21:42:16 2017

On 12 Jan 2017, at 21:59, dkhughes notifications@github.com wrote:

Does ROS really not offer debian packages? I thought some were available even if they aren't the most cutting edge.

There's an effort going on for packages on debian. https://wiki.debian.org/DebianScience/Robotics/ROS These are ROS jade packages. In my case I would need the indigo packages since I use ros-industrial. Clicking the link "continuous integration for jessie" leads here. Looks like it's a bit old. An alternative seems to be from beagleboard https://beagleboard.org/blue Not sure cause I haven't tried that out.

Although it's a bit of work, in a few hours (faster if you do it regularly) one can build from source on Debian.

For trying out (without ros-industrial) Ros Jade, especially on an affordable board like BBB with cramps i'd use the packages from the Debian science team.

Comment by rojkov Fri Jan 13 09:57:32 2017

Building machinekit means having a debian system, Unless you intend to get all prerequisites for building MK in shape on the system of your choice. Building on debian is easiest by far.

I could try to do Yocto packaging for machinekit if there is no strong opposition to Yocto.

But there are also a lot of setups which do not run on Yocto, like a PC with Mesa hardware. So I think a solution which works for all setups is easiest in the long run.

Yocto is just a build system for cross-compilation plus a set of "source package streams" called meta-layers. If you want to build a prototype SD-image quickly (on a powerful Intel workstation) and use it on the target device Yocto is the way. Building a binary package stream (deb, rpm, ipk) is possible as well.

@dkhughes What makes Yocto difficult to use for you?

Comment by dkhughes Fri Jan 13 23:07:09 2017

@rojkov I had a lot of issues with Qt packages being stale. Most of my work was with the AM335x processors, like the beaglebone, and it seemed like every time I wanted to do anything useful I had to roll a custom recipe layer and work through all of the cross compilation issues myself. Qt5 was young at the time, and the default cross compilers (gcc-4.9ish) had issues compiling their source. Not to mention tons of problems with buggy cross compilation (Qemu crashes, etc.) which basically forced me to compile natively on an arm device.

Now, I prefer debian devices. Sure, my SD footprint is a little larger (deploying at about 1.2GB), but I can run Jessie on just about anything ARM or x86/x64. One init system to understand and maintain scripts. I still hit enough issues with QEMU, etc. that I build all of my ARM SD card images, and machinekit for that matter, natively on build slaves (two odroids with USB 3.0 SSDs). Given those slaves I can build a complete image, including RIP building machinekit, and deploy to an img file in less than 20 minutes - so I haven't seen any compile / iteration time penalties in the switch.

I checked out those packages linked by @luminize, that does look promising.

Comment by rojkov Mon Jan 16 14:10:36 2017

@dkhughes Thank you for the info! Qt5 was problematic indeed.

Unlike PRoot-based cross-compilation Yocto enforces everything to be cross-compiled even if the target device is x86. Or if a component hasn't been developed with possible cross-compilation in mind. Especially this might be a problem if the component needs to run a part of itself at build-time, e.g. OpenCL first builds a special LLVM-based compiler then runs it natively in order to build actual blobs loadable onto GPU. So for components of this type Yocto builds packages twice. But it allows to eliminate the need for QEMU completely. I'm new to Yocto, but I don't see how QEMU could be a reason for crushes here.

In its current state Yocto doesn't scale well (no distributed builds still, not really reproducible builds) and has other shortcomings when used in development of big products (e.g. when only a part of the team can access some components' source code). I worked in the Maemo project on Nokia N9 and Yocto would be a no-go there definitely (Scratchbox was used at that time, nowadays it would be PRoot most probably). But for small teams (<10 I guess) it should be OK given there are maintained recipes for the components used on lower layers (meta-qt5 particularly).

machinekit / machinekit-hal

combined ROS/machinekit installations: Debian packaging strategy unclear #138