Ask Your Question
3

ar_track_alvar not 32-bit compatible?

asked 2013-02-07 02:20:54 -0500

Mivia gravatar image

updated 2013-02-14 03:38:08 -0500

I was very happy to discover the ar_track_alvar package, since it will be of great help in a task I am trying to accomplish.

Following the instructions on its official ROS page, I have installed it and use a customized .launch file to macth my setup.

However, almost every time I run the simple test I get an error:

[ INFO] [1360243955.529808050]: Subscribing to info topic
[ INFO] [1360243956.543897374]: Subscribing to image topic
individualMarkersNoKinect: /usr/include/eigen3/Eigen/src/Core/DenseStorage.h:69: Eigen::internal::plain_array<T, Size, MatrixOrArrayOptions, 16>::plain_array() [with T = float, int Size = 4, int MatrixOrArrayOptions = 0]: Assertion `(reinterpret_cast<size_t>(array) & 0xf) == 0 && "this assertion is explained here: " "http://eigen.tuxfamily.org/dox-devel/TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE !!! ****"' failed.

In ~1 of 20 launches it manages to find the marker before the error occurs, and is doing a very fine job of tracking this continuously afterwards. Almost indefinitely without the error occurring.

From a bit of investigation I am leaning towards a conclusion that this may have something to do with the implementation not being compatible with my 32-bit Ubuntu 12.04 fuerte (the 32-bit part is key here). Based on this similar problem: http://answers.ros.org/question/10436/tabletop_segmentation-fails-eigen-error/

Another indicator is that sometimes features in the environment is briefly detected as markers, in the brief moment before the error occurs. The id numbers of these are of course random, but I find it interesting that they are all < 256 in value.

If possible I would prefer to have the package working without any modification, in order to keep it updatable, unmodified etc.

Can anyone confirm if this should work on a 32-bit fuerte? Or any suggestions on how to fix this?

My launch file:

<launch>
  <include file="$(find ar_track_alvar)/launch/pr2_indiv_no_kinect.launch" >
        <arg name="marker_size" default="10.0" />
        <arg name="max_new_marker_error" default="0.8" />
        <arg name="max_track_error" default="0.2" />

        <arg name="cam_image_topic" default="/xtion1/rgb/image_mono" />
        <arg name="cam_info_topic" default="/xtion1/rgb/camera_info" />    

        <arg name="output_frame" default="/xtion1_rgb_optical_frame" />
  </include>
</launch>

I know that I can use the depth_registered for better estimates, but that also gives the error and I wanted to simplify things as much as possible here.

My versions (from dpkg -l) are:

libeigen3-dev 3.0.5-1

ros-fuerte-ar-track-alvar 0.3.0-s1360286484~p

UPDATE:

OK, so I am getting closer to a temporary workaround...

Switched over to using the kinect filtering, and having the node respawn upon crashing, with this launch file:

<launch>
        <arg name="marker_size" default="10" />
        <arg name="max_new_marker_error" default="0.04" />
        <arg name="max_track_error" default="0.1" />

        <arg name="cam_image_topic" default="/xtion1/depth_registered/points" />
        <arg name="cam_info_topic" default="/xtion1/rgb/camera_info" />         
        <arg name="output_frame" default="/xtion1_depth_optical_frame" />

        <node name="xtion1_ar_track_alvar" pkg="ar_track_alvar" type="individualMarkers" respawn="true" output="screen" args="$(arg marker_size) $(arg max_new_marker_error) $(arg max_track_error) $(arg cam_image_topic) $(arg cam_info_topic) $(arg output_frame)" />
</launch>

Furthermore, I have downloaded the source of ar_track_alvar from https://bitbucket.org/sniekum/ar_track_alvar in order to make fixes in the code and compile it myself.

Following advice ... (more)

edit retag flag offensive close merge delete

Comments

I ended up convincing the rest of the developer team that we should all go over to 64-bit. Now it works flawlessly.

Mivia gravatar imageMivia ( 2013-02-20 22:29:35 -0500 )edit

1 Answer

Sort by » oldest newest most voted
4

answered 2013-02-13 23:50:47 -0500

updated 2013-02-14 02:00:36 -0500

This is an error that can appear on 32bit machines when using Eigen. Eigen tries to leverage SIMD instructions/vectorization, but for that to work all data has to be properly aligned in memory. On 32bit machines this isn't guaranteed, so the user has to take care to use macros like EIGEN_MAKE_ALIGNED_OPERATOR_NEW properly. The quick fix "solution" is compiling the software giving that error yourself and setting the EIGEN_DONT_VECTORIZE define. In that case, the speedup due to vectorization is lost however.

From my experience it sometimes can be quite painful to avoid these alignment errors.

edit flag offensive delete link more

Comments

Thank you for your clarification of the issue. I think I will look into the source and try to find the snippets of code causing the problem for this particular package.

Mivia gravatar imageMivia ( 2013-02-14 03:41:30 -0500 )edit

Relatively recently, patches (this, this etc) were made, but they aren't released yet. I opened a release request.

130s gravatar image130s ( 2015-01-23 01:30:49 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

3 followers

Stats

Asked: 2013-02-07 02:20:54 -0500

Seen: 542 times

Last updated: Feb 14 '13