# Revision history [back]

### ar_track_alvar not 32-bit compatible?

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... ### ar_track_alvar not 32-bit compatible? 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... here.

My versions (from dpkg -l) are:

libeigen3-dev 3.0.5-1

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

### ar_track_alvar not 32-bit compatible?

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 from this post: http://www.pcl-users.org/Can-t-avoid-Eigen-alignment-problems-td2531193.html I have made the following changes:

in file kinect_filtering.h line 72

- PlaneFitResult () : inliers(boost::make_shared<ARCloud>()) {}
+ PlaneFitResult () : inliers(boost::shared_ptr<ARCloud>(new ARCloud())) {}


in file kinect_filtering.cpp line 62

- pcl::PointIndices::Ptr inliers=boost::make_shared<pcl::PointIndices>();
+ pcl::PointIndices::Ptr inliers=boost::shared_ptr<pcl::PointIndices>(new pcl::PointIndices());
`

The package still crashes, but far less frequent. Success rate now like 1/5 launches. With the option to respawn on crashes, this makes it possible to continue testing and set this issue aside momentarily.