-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update code in the extern directory #26
Comments
I gave it a shot in https://github.com/robotology/yarp-device-xsensmt/compare/update/2020.0.2 . Unfortunately the API changed a lot, and Xsens switched to recommend a callback-based API that is actually much better that the polling that we used until now, but migrating to that one will probably take a bit more time. For the time being, I tried to migrate from the old API to the new API, but I did a lot of cargo cult changes until it compiled, so it is perfectly possible that is not working fine. |
fyi @prashanthr05 |
@traversaro I was coming here to open the same issue! 😄 Reading through the documents and the code, the API was indeed renovated. And it makes more sense now to have the update to version 2022.0.0. I'll try to draft a working version. |
Can you try to use the branch https://github.com/robotology/yarp-device-xsensmt/compare/update/2020.0.2 and perhaps solve the conflics w.r.t. to the existing master? I think back in time it was compiling fine, but probably in the end we never tested on the real sensor, so it may be worth to start from that. |
By the way it seems that in the meanwhile several new versions of the API have been released, see https://mtidocs.xsens.com/release-notes-change-logs, so it could make sense to use those. Also https://base.xsens.com/s/article/Open-source-XDA-Xsens-Device-API?language=en_US seems relevant, even if I not fully understand the relation between the API that we were using and this XDA Xsens Device API. |
I haven't checked the details of the API were are using, However, I downloaded the latest API they have (version They also include detailed documentation as local See the screenshot of the the files contnents. Here's a screenshot of the overview page of the documentation they provide.. |
Regarding the examples they have, they have 2 sets of examples (concerning the MTi devices in C++): the I compiled the SDK and tested it with the examples. |
The "public" code seems the one that back in time we included in the |
Mmmmm, are you sure? For example, the method By the way, example files |
Sorry, I was not clear. I meant that it is the one corresponding to the code that back in time we imported in |
I started from the branch and fixed some conflicts. There are still some mixed logic between the master and the branch that probably needs to be checked. But focusing on the compilation compilation and running. The devices compiles with no errors, but when trying to run it throws the following errors:
The Demangler shows the symbols are related to I tried adding Branch: https://github.com/HosameldinMohamed/yarp-device-xsensmt/tree/update/2020.0.2 |
Those class is defined in https://github.com/HosameldinMohamed/yarp-device-xsensmt/blob/update/2020.0.2/extern/xspublic/xscommon/threading.cpp, that is included in the static library https://github.com/HosameldinMohamed/yarp-device-xsensmt/blob/update/2020.0.2/extern/CMakeLists.txt#L16 . Can you check if that symbol can be found in the library, by doing something like:
? |
In the running
|
If you want, we can debug this together today. |
With @traversaro we debugged the problem, after handling the dependencies in CMakeLists of xspublic# Globbing should be avoided in general, but this is a library that we use directly as provided by Xsens
file(GLOB xstypes_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xstypes/*.cpp ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xstypes/*.c)
# See EXCLUDE argument in xstypes' Makefile
list(FILTER xstypes_SRCS EXCLUDE REGEX "xstypesdynlib")
add_library(xstypes STATIC ${xstypes_SRCS})
target_include_directories(xstypes PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/xspublic)
target_include_directories(xstypes PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xstypes)
file(GLOB xscommon_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xscommon/*.cpp ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xscommon/*.c)
add_library(xscommon STATIC ${xscommon_SRCS})
target_include_directories(xscommon PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/xspublic)
target_include_directories(xscommon PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xscommon)
target_compile_options(xscommon PRIVATE "SHELL:-include xscommon_config.h" "SHELL:-include xstypes/xsens_compat.h")
target_link_libraries(xscommon PUBLIC xstypes)
file(GLOB xscontroller_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xscontroller/*.cpp ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xscontroller/*.c)
add_library(xscontroller STATIC ${xscontroller_SRCS})
target_include_directories(xscontroller PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/xspublic)
target_include_directories(xscontroller PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xscontroller)
target_compile_options(xscontroller PRIVATE "SHELL:-include xscontrollerconfig.h")
target_compile_definitions(xscontroller PRIVATE -DHAVE_JOURNALLER)
target_link_libraries(xscontroller PUBLIC xstypes xscommon)
find_package (Threads)
add_library(xsens_mt_software_suite INTERFACE)
target_link_libraries(xsens_mt_software_suite INTERFACE xstypes xscommon xscontroller) The error becaume looking for the symbol Solved by adding Journaller* gJournal; In |
I'm testing the software with my Linux PC and the MTi-680G device, the software gets stuck at yarp-device-xsensmt/xsensmt/XsensMT.cpp Line 119 in f03045c
Concerning #26 (comment) The issue seems to be one of the three:
|
With @traversaro we debugged the issue #26 (comment) The debugging consists of:
XsResultValue Scanner::fetchBasicInfo(XsPortInfo& portInfo, uint32_t singleScanTimeout, bool detectRs485) The debugger was showing the other 4 threads running at that point, then it gets stuck.
Library CMakeLists file contents# Globbing should be avoided in general, but this is a library that we use directly as provided by Xsens
file(GLOB xstypes_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xstypes/*.cpp ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xstypes/*.c)
# See EXCLUDE argument in xstypes' Makefile
list(FILTER xstypes_SRCS EXCLUDE REGEX "xstypesdynlib")
add_library(xstypes STATIC ${xstypes_SRCS})
target_include_directories(xstypes PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/xspublic)
target_include_directories(xstypes PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xstypes)
file(GLOB xscommon_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xscommon/*.cpp ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xscommon/*.c)
add_library(xscommon STATIC ${xscommon_SRCS})
target_include_directories(xscommon PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/xspublic)
target_include_directories(xscommon PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xscommon)
target_compile_options(xscommon PRIVATE "SHELL:-include xscommon_config.h" "SHELL:-include xstypes/xsens_compat.h")
target_link_libraries(xscommon PUBLIC xstypes)
file(GLOB xscontroller_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xscontroller/*.cpp ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xscontroller/*.c)
add_library(xscontroller STATIC ${xscontroller_SRCS})
target_include_directories(xscontroller PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/xspublic)
target_include_directories(xscontroller PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/xspublic/xscontroller)
target_compile_options(xscontroller PRIVATE "SHELL:-include xscontrollerconfig.h")
target_compile_definitions(xscontroller PRIVATE -DHAVE_JOURNALLER)
target_link_libraries(xscontroller PUBLIC xstypes xscommon)
find_package (Threads)
add_library(xsens_mt_software_suite INTERFACE)
target_link_libraries(xsens_mt_software_suite INTERFACE xstypes xscommon xscontroller) Then the executable is linked with the compiled libraries ( |
Interestingly, When trying to move the example to this Repo and try to compile it along with the YARP device Linking errors
The files are the same as in #26 (comment) excluding YARP-related lines.
Actually, I saw in the CMakeLists of the ROS driver, they are linking these libraries. And also in this repo with the older versions ( yarp-device-xsensmt/extern/CMakeLists.txt Line 19 in 17eaf3e
And adding linking these libraries actually solves the linking error, and the code runs as expected (not stuck at scanning devices)! I don't completely understand their role yet.. HoweverI'm compiling this repo with a compiler from Conda. While the other case that doesn't throw a linking error and the execution gets stuck, uses the system compiler. That's the difference I could think of, there could be other differences between the two attempts! My Conda compiler:
My System compiler:
NoteI upgraded the Xsens library to the latest version ( |
The functions related to threading (
|
So, just to understand, is the driver working now? Did you solved all the ThreadSanitizers problems? |
I'm compiling the Xsens example with 2 compilers While the system compiler doesn't require linking dl and thread, and even if I link them the problem persists.
No, I encountered this linking issue so I was checking it out.. I left Xsens code as it arrives from the vendor for now.. |
Ok! |
With reference to #26 (comment), I tested it in popOS I tested it in Ubuntu I installed |
The problem appeared to be common with Ubuntu Fix will arrive in a future SDK (v 2023). Suggested workaround to follow: bluespace-ai/bluespace_ai_xsens_ros_mti_driver#17 I tested it in our systems and it removed the error 🎉 |
Great catch! |
Opened PR #38 I updated the configuration and the reading logic based on the example code provided in the MT Software Suite SDK, and the doc files. |
For reference, this fix was done in a43369b . |
Hi @traversaro maybe this issue can be closed? |
Sure! |
The code in the
extern
directory is extracted from the MT Software Suite distributed by Xsens, see https://github.com/robotology/yarp-device-xsensmt/blob/master/extern/CMakeLists.txt#L5 . The last time we updated it was in 2018 with the version 4.8.2 .As we are experiencing now some problems in using this device with
yarp-device-xsensmt
, it is probably worth to try to update it.The text was updated successfully, but these errors were encountered: