Strange behavior of SickScanApiClose()

[cblesing]

Hi everyone,

We noticed a strange behavior of the method SickScanApiClose(). Here is a short description. We develop our software with C++ in Ubuntu 22.04. Here everything works as expected. We "open" the scanner (SICK LMS1000) with SickScanApiCreate then we use SickScanApiInitByCli, after that we register the callback with SickScanApiRegisterCartesianPointCloudMsg and thats it. We get the data as expected. If we close our program we first deregister the callback with SickScanApiDeregisterCartesianPointCloudMsg, next we close the api by calling SickScanApiClose, after that we use SickScanApiRelease. With ubuntu 22.04 everything works fine. No errors or issues.

The program that we have implemented is then used on the target machine, which is a Radxa E25. To use the implemented program on that single board computer, we use Buildroot to "build" or linux based on linux-5.10 and include our program as a package during the build process. On the Radxa the startup process runs like in ubuntu 22.04. But if we try to close the scanner in the fashion mentioned above the SickScanApiClose-function blocks. There is no error returned or something.

The famous last words of the scanner thread are: [Info]: sick_scan_common: stopping scanner ... [Info]: sick_scan_common: sending sopas command "<STX><STX><STX><STX><Len=0017>sEN LMDscandata 0x00 CRC:<0x32>" [Info]: sick_scan_common: sending sopas command "<STX><STX><STX><STX><Len=0023>sMN SetAccessMode 0x03 0xf4 0x72 0x47 0x44 CRC:<0xb3>" [Info]: sick_scan_common: sending sopas command "<STX><STX><STX><STX><Len=0015>sMN LMCstopmeas CRC:<0x10>"

Do you have any idea, what is blocking the program execution?

Kind regards, Christian

[rostest]

Thanks for your feedback. Your procedure looks very correct. Do you use the latest sick_scan_xd release 3.2?

[cblesing]

No, we use the Version 3.1.0. Is there any problem with that?

rostest @.***> schrieb am Di., 19. März 2024, 09:06:

Thanks for your feedback. Your procedure looks very correct. Do you use the latest sick_scan_xd release 3.2?

— Reply to this email directly, view it on GitHub https://github.com/SICKAG/sick_scan_xd/issues/297#issuecomment-2006211203, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHTKQ2CLSPWHMGXY2AVSIE3YY7WXJAVCNFSM6AAAAABE3SCCLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBWGIYTCMRQGM . You are receiving this because you authored the thread.Message ID: @.***>

[rostest]

Thanks for your quick reply. The similiar issue https://github.com/SICKAG/sick_scan_xd/issues/256 has been fixed in version 3.2. Please update to the latest release and rebuild.

[cblesing]

Thanks for the reply. We will update the version and I will reply here if it solves the problem.

[cblesing]

We have updated to the mentioned version. But this causes another blocking during the above mentioned starting process. It seams that the SickScanApiRegisterCartesianPointCloudMsg now did not return.

The name of the .so file was not chnaged with version 3.2.0 from libsick_scan_xd_shared_lib.so to something different?

[rostest]

Thanks for following up. Unfortunately, I can not reproduce this error on Raspberry or Desktop-Linux. If SickScanApiRegisterCartesianPointCloudMsg does not return, the error might be related to linkage, dynamic library loading or the Buildroot process. Do you link with "dl" and "pthread"? Can you build and run the example sick_scan_xd_api_test.cpp as described in Complete usage example in C++ on your target?

[cblesing]

Thanks for your reply. Indeed we use dyanamic lib loading. This is because we have to run at least two LMS1xxx within one program. To do so we fork two child processes and each of them loads the sick_scan_xd.so file with DL. But why does this work with your Version 3.1.0 and no more with the newest Version 3.2.0? For us our current implementation is fine. If the sensor processes are returning they are determined with the exit() function. In this case eyery assiciated ressource should be gone if the prozess exits. Do you agree wirh that?

rostest @.***> schrieb am Mi., 20. März 2024, 14:09:

Thanks for following up. Unfortunately, I can not reproduce this error on Raspberry or Desktop-Linux. If SickScanApiRegisterCartesianPointCloudMsg does not return, the error might be related to linkage, dynamic library loading or the Buildroot process. Do you link with "dl" and "pthread"? Can you build and run the example sick_scan_xd_api_test.cpp https://github.com/SICKAG/sick_scan_xd/blob/develop/test/src/sick_scan_xd_api/sick_scan_xd_api_test.cpp as described in Complete usage example in C++ https://github.com/SICKAG/sick_scan_xd/blob/develop/doc/sick_scan_api/sick_scan_api.md#complete-usage-example-in-c on your target?

— Reply to this email directly, view it on GitHub https://github.com/SICKAG/sick_scan_xd/issues/297#issuecomment-2009531190, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHTKQ2BQIOXWCZJ36YPZLFDYZGDA3AVCNFSM6AAAAABE3SCCLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBZGUZTCMJZGA . You are receiving this because you authored the thread.Message ID: @.***>

[rostest]

Thanks for your reply and further information. In my understanding, function SickScanApiClose blocks your application in version 3.1 and SickScanApiRegisterCartesianPointCloudMsg blocks in version 3.2. In both cases it may be the same error.

Note that the sick_scan_xd library is not garanteed to be threadsafe. I am unsure whether a fork is sufficient to create independant processes to serve two lidars ("The entire virtual address space of the parent is replicated in the child, including the states of mutexes, condition variables, and other pthreads objects.", https://github.com/SICKAG/sick_scan_xd/issues/275#issuecomment-1936226885). Replicated mutexes and pthread objects might block, but this is just a guess. If you are using MQTT, independant MQTT clients for each lidar might be an alternative.

Can you determine whether the error occurs when using only one lidar (without fork)? This way we can see whether the error is a problem with a parallel operation.

[cblesing]

Hi, sorry for the late reply. Unfortunately the error occurs if we only use one sensor.

[rostest]

Thanks for your reply and further information. Unfortunately, I can not reproduce this error on a Raspberry (ARM) or on a Desktop-Linux (x64).

I am not familiar with the "buildroot" process. If buildroot does not use cmake and CMakeListst.txt, please make sure that

• the application and sick_scan_xd library use identical calling conventions, and
• compiler and linker settings corresponding to the cmake "SHARED" option are use (e.g. -fPIC for position independant code).

Can you build and run the API example sick_scan_xd_api_test.cpp with cmake on your target?