rtabmap: add recipe

[TSC21]

Any plans to add a recipe to rtabmap_ros? How hard would it be, giving some dependencies as gtsam, g20 or libsuitesparse for example?

[Minipada]

I didn't see those dependencies in the CMakeLists. For libsuitesparse, I am working in a private layer to use Cartographer using it and all dependencies. You'd have to compile ATLAS/Lapack/BLAS on a similar machine to ensure performance and import them in your custom recipe

[TSC21]

I didn't see those dependencies in the CMakeLists.

Are on README as optional.

For libsuitesparse, I am working in a private layer to use Cartographer using it and all dependencies. You'd have to compile ATLAS/Lapack/BLAS on a similar machine to ensure performance and import them in your custom recipe.

For now I don't have that similar machine available. Isn't there another option?

[Minipada]

Would you have a machine with the same architectures and number of cores? I think it should be ok. You cannot cross compile, as precised here for ATLAS

[TSC21]

So can you describe the best way of doing this? So basically I can't add the ATLAS pkg to a .bb file cause it can't cross-compile, right? So the idea is that I have to manually copy it to the machine I created the image to after booting into it?

[Minipada]

What I'm doing is putting ATLAS, LAPACK BLAS in the sysroot in the Yocto workflow normally, here is the recipe

SUMMARY = "ATLAS library precompiled on target. Cannot be cross compiled because of its nature"
AUTHOR = "R. Clint Whaley & Jack Dongarra & Antoine Petitet"

SRC_URI = "\
    file://libatlas.a \
    file://libcblas.a \
    file://libf77blas.a \
    file://libf77refblas.a \
    file://liblapack.a \
    file://libptcblas.a \
    file://libptf77blas.a \
    file://libptlapack.a \
    file://libsatlas.so \
    file://libtatlas.so \
    file://libatlas.so \
    file://libcblas.so \
    file://atlas.zip \
    file://LICENSE \
"

LICENSE = "BSD"
LIC_FILES_CHKSUM = "file://${WORKDIR}/LICENSE;md5=700a1fc17f4797d4f2d34970c8ee694b"

RDEPENDS_libatlas-dev += "libgfortran"
RDEPENDS_libatlas-staticdev += "libgfortran"

COMPATIBLE_MACHINE = "<Your-machine-name>"

INSANE_SKIP_libatlas-dev = "ldflags"
INSANE_SKIP_libatlas-dbg = "libdir"
INSANE_SKIP_libatlas-dev += " dev-elf"

PACKAGES = " \
    libatlas \
    libatlas-dev \
    libatlas-staticdev \
    libatlas-dbg \
"
FILES_libatlas-dev = " \
    ${libdir}/*.so \
    ${prefix}/local/atlas/lib/*.so \
    ${prefix}/local/atlas/include/* \
"
FILES_libatlas-staticdev = " \
    ${libdir}/*.a \
    ${prefix}/local/atlas/lib/*.a \
"
FILES_libatlas-dbg = " \
    ${libdir}/.debug/* \
    ${prefix}/local/atlas/lib/.debug/* \
"
do_configure(){
    :
}

do_compile(){
    :
}

do_install(){
    install -d ${D}/usr
    install -d ${D}${libdir}
    install -m 0644 ${WORKDIR}/libatlas.a       ${D}${libdir}/libatlas.a
    install -m 0644 ${WORKDIR}/libatlas.so      ${D}${libdir}/libatlas.so
    install -m 0644 ${WORKDIR}/libcblas.a       ${D}${libdir}/libcblas.a
    install -m 0644 ${WORKDIR}/libf77blas.a     ${D}${libdir}/libf77blas.a
    install -m 0644 ${WORKDIR}/libf77refblas.a  ${D}${libdir}/libf77refblas.a
    install -m 0644 ${WORKDIR}/liblapack.a      ${D}${libdir}/liblapack.a
    install -m 0644 ${WORKDIR}/libptcblas.a     ${D}${libdir}/libptcblas.a
    install -m 0644 ${WORKDIR}/libptf77blas.a   ${D}${libdir}/libptf77blas.a
    install -m 0644 ${WORKDIR}/libptlapack.a    ${D}${libdir}/libptlapack.a
    install -m 0644 ${WORKDIR}/libsatlas.so     ${D}${libdir}/libsatlas.so
    install -m 0644 ${WORKDIR}/libtatlas.so     ${D}${libdir}/libtatlas.so
    install -m 0644 ${WORKDIR}/libatlas.so      ${D}${libdir}/libatlas.so
    install -m 0644 ${WORKDIR}/libcblas.so      ${D}${libdir}/libcblas.so

    install -d ${D}/usr/local
    install -d ${D}/usr/local/atlas
    cp -r ${WORKDIR}/atlas/* ${D}/usr/local/atlas
}

And then you put ATLAS as a dependency of rtab_map. I have put the COMPATIBLE_MACHINE flag since the files are associated for one machine

[TSC21]

That's awesome! Are you planning to PR this to the repo soon, together with cartographer_ros? And what about libsuitesparse?

[Minipada]

Thanks :). I have everything done for cartographer and libsuitesparse and I actually plan multiple PR for this, I didn't take the time yet but I created an issue here.

[TSC21]

@Minipada that's great! Please when you have time please issue the PR. It will help the community a lot. Adding libatlas and libsuitesparce to recipes-extended and cartographer_ros to recipe_ros can be a good approach. After that, I'll be pushing the rtabmap_ros recipe based on the addictions you are doing and consider adding g2o and gtsam to it as optional dependencies.

[TSC21]

COMPATIBLE_MACHINE = "<Your-machine-name>"

Is there a away of automatize this during bitbake without hard-coding it?

[Minipada]

I thought of the approach. I think for example, libatlas recipe should provide libraries for each architecture depending on the file name. For example, for a raspberrypi3, the file would be libatlas-raspberrypi3.a. Then the recipe, depending on the machine would know which files to provide. Nevertheless, not every machine are compatible because not every machine files have been generated. Thus, a new user who would want to use the recipe with a new machine would be blocked because it is not listed in COMPATIBLE_MACHINE. For now, my recipe doesn't have this modularity, but I plan to prepare it, because I use raspberrypi3 and raspberrypi3-64 since a week.

[TSC21]

Thus, a new user who would want to use the recipe with a new machine would be blocked because it is not listed in COMPATIBLE_MACHINE.

Maybe we can address this by each community member with a different architecture push new files to the repo. For example you may have architectures that I don't have, and I some that you don't, so if we share, we will both have access to those same files. I think that's one of the purposes of open-source. If everyone collaborates, everybody will be happy. So I think for a first approach you can add files for a certain list of compatible machines. Then, more users can do the same based o you implementation. Maybe you can add a document no the README explaining how can we collaborate on extending the libatlas/libsuitesparse/other libs to more machines (I think that libsuitesparce is cross-compilable though). What do you think?

[Minipada]

Yeah I think exactly the same way, you're completely right. I want to put limitations simply to warn users of the current ... limitations. IT has to grow :)

[TSC21]

Yeah I think exactly the same way, you're completely right. I want to put limitations simply to warn users of the current ... limitations. IT has to grow :)

Exactly! Will be waiting for your PR then. Let me know if you need assistance.

Also, I'm seeking for interest on upgrading meta-ros to Kinetic, but I don't know the current state or if it is possible. In any case, we can discuss that in https://github.com/bmwcarit/meta-ros/issues/485. Thanks

[bulwahn]

I started looking into writing the recipe for rtabmap and published my incomplete work in a personal branch at https://github.com/bulwahn/meta-ros/tree/rtabmap.

Currently, compiling rtabmap fails with:

| [ 17%] Built target res_tool
| make -f corelib/src/CMakeFiles/rtabmap_core.dir/build.make corelib/src/CMakeFiles/rtabmap_core.dir/depend
| make[2]: Entering directory `/home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/build'
| [ 18%] [Creating resources]
| cd /home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/build/corelib/src && /home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/rtabmap-0.11.8/bin/rtabmap-res_tool -n rtabmap -p /home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/build/corelib/src /home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/rtabmap-0.11.8/corelib/src/resources/DatabaseSchema.sql
| /home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/rtabmap-0.11.8/bin/rtabmap-res_tool: /usr/lib32/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/rtabmap-0.11.8/bin/rtabmap-res_tool)
| /home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/rtabmap-0.11.8/bin/rtabmap-res_tool: /usr/lib32/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/rtabmap-0.11.8/bin/librtabmap_utilite.so.0.11)
| /home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/rtabmap-0.11.8/bin/rtabmap-res_tool: /usr/lib32/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/rtabmap-0.11.8/bin/librtabmap_utilite.so.0.11)
| /home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/rtabmap-0.11.8/bin/rtabmap-res_tool: /usr/lib32/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/rtabmap-0.11.8/bin/librtabmap_utilite.so.0.11)
| make[2]: *** [corelib/src/DatabaseSchema_sql.h] Error 1
| make[2]: Leaving directory `/home/lukas/work/repositories/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/rtabmap/0.11.8-r0/build'
| make[1]: *** [corelib/src/CMakeFiles/rtabmap_core.dir/all] Error 2
| make[1]: *** Waiting for unfinished jobs....

As far as understand it on the first scan, rtabmap first compiles its own tool, rtabmap-res_tool, and then immediately wants to use it in the compilation. This fails of course with cross-compilation. So, we need to split first to compile rtabmap-res_tool as native package and then use that when compiling rtabmap. That is not completely trivial and needs some more digging in the build script.

[Minipada]

I contacted oe-core to propose them the recipe and they told me they won't accept it because binaries need to be provided and they advised me to publish a custom layer for this. I am currently checking internally with my company to know if they want to disclose it. I'll come back as soon as I have more information

[TSC21]

started looking into writing the recipe for rtabmap and published my incomplete work in a personal branch at https://github.com/bulwahn/meta-ros/tree/rtabmap.

Cool but shouldn't we focus on the ROS API implementation of it: https://github.com/introlab/rtabmap_ros

That is not completely trivial and needs some more digging in the build script.

Maybe we can take a look on it together?

I am currently checking internally with my company to know if they want to disclose it. I'll come back as soon as I have more information

Just hopping it goes forward. Let me know if you need help regarding this.

[bulwahn]

@TSC21 The rtabmap_ros package essentially depends on rtabmap. All other dependencies of rtabmap_ros are already in meta-ros except for rtabmap_ros and rviz. I hope that we still make the rviz dependency optional, as some embedded devices probably do not want to include a full-fledged visualization. So to actually write and test the rtabmap_ros, we need to start getting the rtabmap package cross-compiling. My current state of investigation is on my personal branch, just create your own personal fork on github and pull the current commit, check if the reported issue above occurs in your setup and start improving and creating commits on top. Once we are done, we can create a condensed commit for review and contribution to the main repository.

[pavannandyala]

What I'm doing is putting ATLAS, LAPACK BLAS in the sysroot in the Yocto workflow normally, here is the recipe

SUMMARY = "ATLAS library precompiled on target. Cannot be cross compiled because of its nature"
AUTHOR = "R. Clint Whaley & Jack Dongarra & Antoine Petitet"

SRC_URI = "\
    file://libatlas.a \
    file://libcblas.a \
    file://libf77blas.a \
    file://libf77refblas.a \
    file://liblapack.a \
    file://libptcblas.a \
    file://libptf77blas.a \
    file://libptlapack.a \
    file://libsatlas.so \
    file://libtatlas.so \
    file://libatlas.so \
    file://libcblas.so \
    file://atlas.zip \
    file://LICENSE \
"

LICENSE = "BSD"
LIC_FILES_CHKSUM = "file://${WORKDIR}/LICENSE;md5=700a1fc17f4797d4f2d34970c8ee694b"

RDEPENDS_libatlas-dev += "libgfortran"
RDEPENDS_libatlas-staticdev += "libgfortran"

COMPATIBLE_MACHINE = "<Your-machine-name>"

INSANE_SKIP_libatlas-dev = "ldflags"
INSANE_SKIP_libatlas-dbg = "libdir"
INSANE_SKIP_libatlas-dev += " dev-elf"

PACKAGES = " \
    libatlas \
    libatlas-dev \
    libatlas-staticdev \
    libatlas-dbg \
"
FILES_libatlas-dev = " \
    ${libdir}/*.so \
    ${prefix}/local/atlas/lib/*.so \
    ${prefix}/local/atlas/include/* \
"
FILES_libatlas-staticdev = " \
    ${libdir}/*.a \
    ${prefix}/local/atlas/lib/*.a \
"
FILES_libatlas-dbg = " \
    ${libdir}/.debug/* \
    ${prefix}/local/atlas/lib/.debug/* \
"
do_configure(){
    :
}

do_compile(){
    :
}

do_install(){
    install -d ${D}/usr
    install -d ${D}${libdir}
    install -m 0644 ${WORKDIR}/libatlas.a       ${D}${libdir}/libatlas.a
    install -m 0644 ${WORKDIR}/libatlas.so      ${D}${libdir}/libatlas.so
    install -m 0644 ${WORKDIR}/libcblas.a       ${D}${libdir}/libcblas.a
    install -m 0644 ${WORKDIR}/libf77blas.a     ${D}${libdir}/libf77blas.a
    install -m 0644 ${WORKDIR}/libf77refblas.a  ${D}${libdir}/libf77refblas.a
    install -m 0644 ${WORKDIR}/liblapack.a      ${D}${libdir}/liblapack.a
    install -m 0644 ${WORKDIR}/libptcblas.a     ${D}${libdir}/libptcblas.a
    install -m 0644 ${WORKDIR}/libptf77blas.a   ${D}${libdir}/libptf77blas.a
    install -m 0644 ${WORKDIR}/libptlapack.a    ${D}${libdir}/libptlapack.a
    install -m 0644 ${WORKDIR}/libsatlas.so     ${D}${libdir}/libsatlas.so
    install -m 0644 ${WORKDIR}/libtatlas.so     ${D}${libdir}/libtatlas.so
    install -m 0644 ${WORKDIR}/libatlas.so      ${D}${libdir}/libatlas.so
    install -m 0644 ${WORKDIR}/libcblas.so      ${D}${libdir}/libcblas.so

    install -d ${D}/usr/local
    install -d ${D}/usr/local/atlas
    cp -r ${WORKDIR}/atlas/* ${D}/usr/local/atlas
}

And then you put ATLAS as a dependency of rtab_map. I have put the COMPATIBLE_MACHINE flag since the files are associated for one machine Hi

is there any recipe available any where for ATLAS library i need libatlas-base package to be part of my rpi3 yocot build please help

[pavannandyala]

can any one please point me to atlas libraries or pre-compiled libraries for rpi 32 bit version or yocto recipe

[Steven-Cai]

@pavannandyala Hi, I want to involve libatlas-base-dev into RPI3 yocto build. Do you have succeed to integrate it? Thank you!

[herb-kuta-lge]

@TSC21 < Can this issue be closed?

[TSC21]

I suppose it can. Was there any work on bringing this in?

[herb-kuta-lge]

There now is a recipe generated under meta-ros1-melodic for rtabmap-ros: https://github.com/ros/meta-ros/blob/thud-draft/meta-ros1-melodic/generated-recipes/rtabmap-ros/rtabmap-ros_0.19.3-1.bb. However, it requires rtabmap which does not yet build because of missing platform package dependencies. We are working towards getting as many packages as possible to build, so eventually, it probably will.