ROS / Adlink CM2-BT2 (PC104-SBC) SMBus driver incompatibility

asked 2019-04-10 12:08:29 -0500

hardyn gravatar image

updated 2019-04-10 15:07:25 -0500

gvdhoorn gravatar image

This question is getting super specific, but I would appreciate if anybody has seen something like this with other hardware?

Ubuntu 16.04.6 ROS Kinetic full install Adlink CM2-BT2 (PC104 SBC) Adlink's "SEMA" SM-Bus driver to access on-board-GPIO

I am having the problem where Adlink's GPIO example code is working as expected when running on the SBC without ROS. However, if a node is built using Adlink's shared library upon execution, a core-dump/memory trace occurs. This occurs without any manipulation of GPIO state simply attempting to execute a node build with the Adlink shared object.

The suspect test only contains ros::init() and is liked to the Adlink provided .so file as well as library header files. Simply linking in the .so seems to cause the node to fail. If either ros::init() or the .so are absent, the node will execute.

I am currently talking to one of their sales engineers, but I was curious if anybody has seen anything like this with other SBC's onboard GPIO?

Thanks in advance.

Edit: ldd of (as requested):

/lib64/ (0x00007fdba3cd7000) => /lib/x86_64-linux-gnu/ (0x00007fdba19e5000) => /lib/x86_64-linux-gnu/ (0x00007fdba2ae7000) => /usr/local/SEMA/lib/ (0x00007fdba3110000) => /lib/x86_64-linux-gnu/ (0x00007fdba1daf000) => /usr/local/SEMA/lib/ (0x00007fdba285a000) => /lib/x86_64-linux-gnu/ (0x00007fdba1fc5000) => /lib/x86_64-linux-gnu/ (0x00007fdba15af000) => /lib/x86_64-linux-gnu/ (0x00007fdba17c8000) => /lib/x86_64-linux-gnu/ (0x00007fdba2ceb000) => /usr/local/SEMA/lib/ (0x00007fdba2ef3000) => /usr/local/SEMA/lib/ (0x00007fdba2650000) => /usr/lib/x86_64-linux-gnu/ (0x00007fdba22ce000) =>  (0x00007ffc2dd82000)
edit retag flag offensive close merge delete



The suspect test only contains ros::init() and is liked to the Adlink provided .so file

What other libraries is the Adlink .so linked to (ie: what is the output of ldd /path/to/

And as always with crashes of C++ nodes: build with RelWithDebInfo or plain Debug and run the node in gdb to get a stacktrace and post that here.

gvdhoorn gravatar image gvdhoorn  ( 2019-04-10 12:27:09 -0500 )edit

I will work on getting gbd output shortly

hardyn gravatar image hardyn  ( 2019-04-10 14:09:27 -0500 )edit

Did you get to the bottom of this?

gvdhoorn gravatar image gvdhoorn  ( 2019-05-03 04:48:58 -0500 )edit

I'm currently running into the exact same issue as described. ros::init() throws an std::length_error(), even though I've verified the inputs to the function are correct. hardyn were you ever able to resolve this issue?

btgibbons gravatar image btgibbons  ( 2019-07-08 12:34:00 -0500 )edit

I still suspect a corruption somewhere caused by symbol clashes or something similar.

gvdhoorn gravatar image gvdhoorn  ( 2019-07-08 15:27:55 -0500 )edit

I will have the senior developer that figured it out reply to this thread, as he is the one that solved it. What it seems to be is the SEMA driver contains a version of Boost that conflicts with that used by ROS Kinetic. A symbol clash as @gvdhoorn suggests. It was solved by making an alteration to the roslog? node as the SEMA driver is supplied as binary.

Adlink has been made aware of this problem and the solution we found.

hardyn gravatar image hardyn  ( 2019-07-08 16:50:17 -0500 )edit

Oh that makes sense, I see how that would cause an issue. @hardyn, were you able to ask the senior engineer what their workaround ended up being? I've updated to the latest version of SEMA in hopes that Adlink had fixed things on their side, but still no luck. Thanks for the help.

btgibbons gravatar image btgibbons  ( 2019-07-15 17:19:13 -0500 )edit

@btgibbons Hi, i have also met the problem as yours. The program throws std::length_error at ros::init. Have you already solved it?

8feetaway gravatar image 8feetaway  ( 2020-07-16 23:14:13 -0500 )edit