Segmentation Fault

[agnostic-apollo]

Hi, I am building a SLAM robot using RatSLAM and was thinking about integrating stereo viso2 odometry into it but I am getting segmentation faults at the function divconqrecurse(mesh*, behavior*, float**, int, int, otri*, otri*) (), the gdb backtrace shows a dozen divconqrecurse function calls. Can you check this out?

Log file:
log.txt

My setup is Raspberry Pi Compute Module 3 running Ubuntu 16.04, ROS kinetic with stereo v1.3 Cameras each taking 640x480 images at 10fps using raspicam lib. The images are sent to my laptop running Ubuntu 16.04, ROS Kinetic over a LAN Wi-Fi connection.
The bgr8 images are first encoded to jpeg before transfer to reduce transfer time.

The Pi publishes

sensor_msgs/CompressedImage at
/agnostobot/left/image/compressed
/agnostobot/right/image/compressed

and

sensor_msgs/CameraInfo at
/agnostobot/left/camera_info
/agnostobot/right/camera_info

The images are then converted back to raw using image_transport
and published at

/rectify/left/image_raw
/rectify/right/image_raw

camera_info messages are remapped to

/rectify/left/camera_info
/rectify/right/camera_info

stereo_image_proc is used to rectify the images. Then ExactTime policy is used to synchronize rectified images and camera_info messages and republish them for viso2_ros stereo_odometer. This was done since camera_info messages were delivered to viso2 earlier than image messages which were still being rectified.

images are published at

/stereo/left/image_rect
/stereo/right/image_rect

and camera_info at

/stereo/left/camera_info
stereo/right/camera_info

the left camera image and camera_info message header frame_id are set at

/agnostobot_left_camera

and the right camera image and camera_info message header frame_id are set at

/agnostobot_right_camera

static_transform_publisher with args="0.1075 0.0865 0.0215 0 0 0 /base_link /agnostobot_left_camera 100" is used to provide transform from /base_link -> /agnostobot_left_camera

static_transform_publisher with args="0.1075 -0.0865 0.0215 0 0 0 /base_link /agnostobot_right_camera 100" is used to provide transform from /base_link -> /agnostobot_right_camera

im also using chrony server on the laptop which is used by the pi for syncing time since that was being a problem too with "future transform" errors.

possible issues but could be unrelated

1. my tf coordinate frames are not optical frame, my x is forward, y is left and z is up which is not what viso2 want but im new to tf and not sure how to merge both logics.

2. another issue is that im encoding and decoding before rectification, that shouldn't be an issue, right?

3. my robot is not built yet, I was just moving my raspberry pi case mounted with cameras around the room, i expect to get false or no odometry data but not for the lib to crash

4. whats this about, the parameter isn't mentioned in the docs
   'stereo' has not been remapped! Example command-line usage:
   $ rosrun viso2_ros stereo_odometer stereo:=narrow_stereo image:=image_rect

If you need any more info, let me know. Also let me know if I'm making any mistakes here. Waiting for your response.
Thanks

Links:

pi camera image publisher
launch file
message synchonizer

[klintan]

I had a very similar issue for mono_odometer , and the problems is in the sobel/convolution phase for feature extraction. The logic is fairly complex, but 640x480 images will not work because the sliding window which works on the memory address is trying to access a memory location "outside" the image. (This is also just my interpretation of the code could be incorrect)

Using the test dataset image size 1344x391 worked.

[agnostic-apollo]

Thanks for the response. At the time I submitted the issue, I had a deadline and did not have enough time to look into a complex code to fix it. And I'm currently working on some other projects but do plan on working on the robot again when I can find the time. I'll check out your suggestion then and report back.
Thanks again.

[P3TE]

Hey there!
I've uncounted a similar issue (If not the same one).
I've written up a work-around that will stop lib-viso from crashing, but honestly haven't looked too far into what the root cause of this issue is.
In any case, I believe I've identified the issue so a proper fix should be easier to implement now!