Build maplab on ARMv7-A (32bit) about maplab HOT 17 CLOSED

@Alabate Thanks a lot for your efforts to port maplab to ARM based devices and for sharing your diff. Regarding your remarks: I agree, ANDROID is not a good flag name for this purpose, but having a global cmake flag which is set based on the processor architecture sounds like a good idea. Potentially, we can also replace the script from aslam_cv_common with a combination of FindARM.cmake and FindSSE.cmake and then set the -mssse3 or -mfpu=neon flags based on this. I think we can put this script just in aslam_cv_common and then copy it to the two other repos that also use it. As I'm currently also building maplab on an Odroid, I will try to put something together and tag you, ok?

from maplab.

We released an experimental pre-release branch which adds build compatibility for armv7 and armv8 processors (along with some other changes).

You can test it by checking out the branch pre-release-january in both the maplab and the maplab_dependencies repo:

git pull
git checkout pre-release-january
git submodule init
git submodule update --recursive

After this, clean the catkin workspace and rebuild it:

catkin clean
catkin build maplab

We are happy to hear if this works for you.

from maplab.

Good news! With that change the entire package builds successfully.

from maplab.

Hi, thanks a lot for your question.

To be honest, the amount of work is difficult to predict, but I think it's worth a try. It's also hard to say what will be the impact on performance as you're lacking SSE optimization that Eigen broadly uses (and Eigen matrices are present all over the project).

1. This Id problem in maplab_common is rather easy to fix, you just need to hack in a routine to generate a unique id on a 32-bit machine. As you can see, id is composed of two 64-bit values so you just need to properly initialize them (make sure the id space is 128bit not 64bit to avoid Id clashes).

2. -mssse3 flag is just to enable Eigen optimizations using SSE3. You can probably kick out this flag for now and see what happens, I don't think we strictly depend on SSE, it was just to promote the optimization by the compiler.

Another issue you may encounter are Eigen alignment issues (we might be missing proper alignment in some places), which show up much more often on 32-bit machines. On the other hand, they are resulting from x86 SSE optimizations, not sure if Eigen has some ARM-specific code (NEON?) that might cause them.

from maplab.

Ok, so I managed to build and start a bag. I'm giving you the diff of my workspace, to let anyone do the same. But those are really dirty modifications, sometimes even useless or just dumb (like in descriptor-projection where I tried to add 3 times the same thing in the CMakeLists.txt because it wouldn't work). We have to find clean ways to fix the same problems.

https://gist.github.com/Alabate/c1017c4f0a6c3b9e5e6db75ddbcddf0b

from maplab.

As you can see, most of modifications are removing the -mssse3 to add -mfpu=neon instead. How could we do this in a clean way ?

• I see on some part of the project that there is an ANDROID flag in cmake that enable neon. We could use this flag in every part of the project. In this case a simple parameter in the catkin worskpace would enable the arm build. However, I don't think ANDROID is a good name for a such flag, because android is not the only arm system and android can be installed on x86.
• In aslam_cv2/aslam_cv_common/cmake/export_flags.cmake there is also the IS_ARM_ARCHITECTURE flag which is generated by the following script. This could also be a good solution, the name of the flag is definitely better. But in this case, we have to put this script somewhere and include it in every CMakeFile.txt. We could put it in every repo that need it, or in another simple repo which would be a dependency.

set(IS_ARM_ARCHITECTURE FALSE)
execute_process(COMMAND uname -m COMMAND tr -d '\n' OUTPUT_VARIABLE ARCHITECTURE)
if (ARCHITECTURE MATCHES "^(arm)")
  set(IS_ARM_ARCHITECTURE TRUE)
endif()

What do you think ?

from maplab.

Actually a think this script might do the job.

from maplab.

Guys, thanks for the amazing project. As @Alabate I was trying to make it work on the Nvidia TX1.
Like you point out, the extensive use of -mssse3 is the biggest concern. Regarding the dependencies, I manage to compile:

doxygen_catkin -> ok
catkin_simple -> ok
gflags -> ok
glogs -> ok (use lates version from git, remove the patch in the make,
have libunwind-dev libunwind8-dev pre installed)
Voxblox -> ok
Opencv3_catkin -> ok

the rest still trying out, especially aslam pkg (-mssse3) and brisk. Brisk released a v2, and it should implement NEON. Still need to try it.

Keep you update and thanks for the work!

from maplab.

Could this be a simple fix - JakobEngel/dso#59 ?

from maplab.

@bidbest Have you managed to build brisk on the TX1? When I remove the -msse3 option I get error:
fatal error: emmintrin.h: No such file or directory
I found this SSE2NEON.h, maybe this could help?

from maplab.

@hoangthien94 Diden't try it yet. I'm currently working on x86 processors, will try again on arm in the future. If I remember correctly emmintrin.h file is considered only when flagh sse3 is present. You can try to test Brisk v2, that should support NEON., and hope it will not conflict with the rest of maplab.

from maplab.

@hoangthien94 We are working on porting maplab to ARM. Regarding ethz-asl/brisk repo, you can alreay checkout the feature/port-to-arm branch there which should do the job.

from maplab.

Hi @fabianbl, I have tried the feature/port-to-arm branch ,but it still failed when building brisk with following errors:

c++: error: unrecognized command line option ‘-mfpu=neon’

My device is Nvidia Jetson TX2 which's architecture is aarch64.

$ uname -a
Linux CAR01-CU03 4.4.38 #1 SMP PREEMPT Tue Oct 10 15:24:32 CST 2017 aarch64 aarch64 aarch64 GNU/Linux

from maplab.

Hi @megamindhe . Thank you a lot for your report. Unfortunately, we weren't able yet to test this on an armv8 architecture (but will do so soon). Apparently, for these processors, no specifications for using advanced SIMD are necessary (see here). For now, you can simply comment out all occurrences of -mfpu=neon (e.g. here in ethz-asl/ethzasl_brisk).

from maplab.

I tried building on a Jetson tx2, ubuntu 16.04, ROS kinetic, with the experimental pre-release branch.
The initial try failed with an "internal compiler error" while building rovio. Looking at the logfile, the error occurred right after:

[ 94%] Built target feature_tracker_node

On the second try, it succeeded with rovio but failed while building vi_map (46/91), with this error:

Errors << vi_map:cmake /home/nvidia/maplab_ws/logs/vi_map/build.cmake.000.log
CMake Error at /home/nvidia/maplab_ws/devel/share/catkin_simple/cmake/catkin_simple-extras.cmake:38 (find_package):
By not providing "Findbenchmark_catkin.cmake" in CMAKE_MODULE_PATH this
project has asked CMake to find a package configuration file provided by
"benchmark_catkin", but CMake did not find one.

Could not find a package configuration file provided by "benchmark_catkin"
with any of the following names:

benchmark_catkinConfig.cmake
benchmark_catkin-config.cmake

from maplab.

@dan9thsense Thank you for your report. I think what you can do is:

cd ~/maplab_ws/src/maplab_dependencies
git submodule init
git submodule update

This will initialize and checkout benchmark_catkin which was not there in the master branch. Forgot to mention this, I now added it to the description above.

from maplab.

@fabianbl I added your instructions to the PR description as well, thx.

from maplab.