Missing derived values in field data

[robertwil]

Hi,

when I try to get the safety and warning fields in the MICS3 via void SickSafetyscanners::requestFieldDataInColaSession( std::vector<sick::datastructure::FieldData>& fields) in SickSafetyscanners.cpp the derived values, which are accessed in field_data.setStartAngleDegrees(config_data.getDerivedStartAngle()); field_data.setAngularBeamResolutionDegrees(config_data.getDerivedAngularBeamResolution()); are zero and/or uninitialized. Therefore I have no angle information, when I try to access the FieldData structure later.

The derived values (using getDerivedValuesPtr()) are, from my understanding, correct in the UDP-Callback.

If i change config_data.getDerivedStartAngle() to config_data.getStartAngle() and the EndAngle respectively, I can visualize my fields.

Is there any special initialization that has to be done to get the derived values ?

Best regards Robert

[puck-fzi]

Hi Robert,

could you elaborate a bit more on this issue. What have you tried, how are you using the driver? I just tried the latest commit and got the following for the configured sensor when calling the getFields service:

start_angle: -1.57079637051
angular_resolution: 4.24441310543e-07

Which appear as reasonable values to me. So as follow up how exactly are you starting the driver? Since you reference the request function, are you using ROS at all? And the values used for the start angle and current configuration originate from the currentMeasurementConfiguration.

[robertwil]

Hi,

I'm usually using ROS but I'm, as you have correctly guessed, trying to build a application for Windows to visualize scans without a Linux-ROS machine. This already works quite well thanks to your nice modularity in the code.

I tried to use the ROS service and it works fine with one laserscanner (the older CBAZ55ZA1) and times out with the CBAZ90ZA1.

The CBAZ55ZA1 also returns with getDerivedAngularBeamResolution a value of 2.21729279e-05 (is this reasonable ? I don't quite get in which unit it is as it seems quite a low value for everything).

I didn't find any differences in the safety designer, which could lead to such a result. So maybe the sensor has a defect ? It also fails to reconnect and needs a hard power off after a first connection.

Apart from this: Do you know, whether the safety fields are stored in a more complex geometry instead of a distance value for every angle ? Or does the safety designer read all the 2201 points (or 715 depending on the scanner) and calculates that these points form a circle (example) ? Can I access the name of the field set ? I only found its index.

Thank you very much.

Best regards Robert

[puck-fzi]

Hi Robert,

then first let me point you towards: https://github.com/SICKAG/sick_safetyscanners_base Which is basically a standalone version of this driver. With a little bit added functionality. Still missing the fix of the device name from the other issue. But giving a further synchronous and asynchronous interface.

And for the angular beam resolution, you are correct, it appears a little bit small. I will have to check that again, The unit should be radians. The sensor should give degrees and the driver converts this into radians. Since i am on holiday the next two weeks, this will happen afterwards. If you want to have a look into it, the cola protocoll can be found here https://cdn.sick.com/media/docs/1/01/701/Technical_information_microScan3_outdoorScan3_en_IM0083701.PDF This is missing the direct access for the field data though. I don't know where these information are publicly available.

And for the fields, the accessible data can be found at https://github.com/SICKAG/sick_safetyscanners/blob/master/include/sick_safetyscanners/datastructure/FieldSets.h and https://github.com/SICKAG/sick_safetyscanners/blob/master/include/sick_safetyscanners/datastructure/FieldData.h. There are names of the fields and field sets in there.

As for the safety designer itself, you would need to contact Sick directly, since i have no knowledge about the underlying software.

But as for visualizing the fields and their status, the field data service and the output paths topic should give you all the information you need for the safety fields. So best have a look into the there published information.

[robertwil]

Hi, thank you for the information. I'm able to receive the field and field set data (while getDerivedAngularBeamResolution still does not work for one scanner). One thing I came across was that:

In ParseProjectName.cpp in function ParseProjectName::readProjectName it reads 16 bits, which leads to a dereferencing problem (like #49).

In ParseFieldSetsData.cpp in serveral functions I had to replace the multiplication factor of 112 by 104 which seemed to be more reasonable (in debugging as I don't have a detailled data sheet). Otherwise another dereferencing error occurred leading to a allocation of several GB of memory ;) I hope you can confirm this.

[puck-fzi]

Hi, i will have a look into this. Thanks for reporting. I will keep you updated on the findings

[puck-fzi]

The parsing of the project name should have been fixed in the latest commit d39aaae as well.

[puck-fzi]

In ParseFieldSetsData.cpp in serveral functions I had to replace the multiplication factor of 112 by 104 which seemed to be more reasonable (in debugging as I don't have a detailled data sheet). Otherwise another dereferencing error occurred leading to a allocation of several GB of memory ;) I hope you can confirm this.

By looking through the datasheet this appears to be right. thanks for spotting. I will fix this

[puck-fzi]

The offset should be fixed in commit 47fc608

Does this solve your current problems? If not please reopen.