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 ...
I ended up convincing the rest of the developer team that we should all go over to 64-bit. Now it works flawlessly.