Variable scan frequence

[Karsten1987]

According to SICK's developer guide we have to trigger 2 functions to fully configure the laser.
The LMS1xx::setScanCfg LMS1.xx#L287 function alone does not sufficiently set the output range parameters. Hence the extension in this PR.

[hanshammel1337]

Any reason why this PR is not merged yet?
May be the code is not up to date, but the functionality to switch between 0.25°/25Hz and 0.5°/50Hz is very useful.

[efernandez]

FYI @servos @mikepurvis

[mikepurvis]

Can someone explain a bit more about what this is doing? It looks like we're adding a new function which isn't actually called from anywhere. Can this behaviour be exposed through a parameter to the supplied node?

[hanshammel1337]

For the pull request you are right; the function is never called.
As I see the driver just gets the current config for angle resolution and frequency from the stored data on the LMS100 hardware. Normally set via SICK Software Sopas ET (Windows Software). As mentioned in the linked SICK pdf there is the possibility to set angle resolution and frequency via telegram sMN mLMPsetscancfg.

• I think the main intention by OP for this pull request was to avoid the hardcoded frequency here: LMS1xx_node.cpp#L69
• and 2nd: Adding the possibility to set resolution and frequency in the code of the ROS node. So changing between 0.25° and 0.5° (and 25 Hz / 50Hz) does not require Windows SICK Software.

[efernandez]

Set

[efernandez]

I agree with not forcing a frequency and allowing to configure it from this driver.

However, the configure method should be tested and exercised somewhere. IMHO it's buggy. See my comments.

BTW, I don't know why this branch has conflicts... I guess it must be rebase on top of the main branch.

[efernandez]

@Karsten1987 , do you have time and the resources to fix and test this?

[efernandez]

FYI @asaini89

[Karsten1987]

Sorry for reacting late on this.

In fact I have a launch file plus small executable providing a ROS configuration node. I will add it soon.
Further, i may close this PR and re-open it with my master branch, since I have a couple of more commits on top of this one.

• fixing CMakeLists.txt 36d0554
• adding IP config ee19a3c
• activating filters 17670c4

Have a look here https://github.com/Karsten1987/LMS1xx/commits/master

@hanshammel1337 Your thinking is absolutely correct. I think it's necessary to provide functions like this to configure your lasers according to your application. BTW, most of the functions are applicable also for the TiM series.

@efernandez I am not having access to a laser until Monday and will test the functions again according to your comments. I basically played monkey-see-monkey-do with the already existing functions. As for the merge conflicts, my guess would be white-spacing since the original code is using real tabs and I spaces.

[Entropy512]

Karsten - have you had success with 25Hz 0.25 degree scan configurations on an LMS100?

For whatever reason, if I disable the scan frequency check, enable 0.25 degree scan resolution in SOPAS, then start the node - it starts and connects successfully but then crashes the moment anything subscribes to the /scan topic.

25 Hz/0.5 degree works fine

[Karsten1987]

Given that I don't have access to any LMS anymore, please treat my answer here with caution.

you may want to verify that your cfg-structs which you get from the driver actually correspond to the settings in SOPA. As far as I recall, I only tested 50Hz/0.5 deg and 25Hz/0.25deg. I am not sure if a mix is supported.
I've run already into strange configurations where the first 540 points were set as range and the remaining 540 as intensity values. You may want to double check that.

[Entropy512]

Thanks for the info. I actually did figure out the issue about an hour after I posted, but in general you seem to be right.

What I'm seeing is that in some cases, the LMS100 outright lies. Specifically, if I set 25Hz/0.25deg, the scan config returns the correct resolution value, but the scan output range query reports 0.5deg resolution when in fact the data is at 0.25deg resolution. As a result, the ROS node assumes half as many points as are actually being delivered, which leads to the crash. I changed LMS1xx_node.cpp to ignore the angular resolution information from getScanOutputRange() and only use the resolution from getScanConfig() and that seems to be working.

Interestingly - at least on my LMS100, SOPAS does not allow you to configure the output data resolution - the only resolution config is the scan config. (May be a sign that I need to update firmware in the unit and/or sort out network access for the machine I'm running SOPAS on so I can use a DDS other than the one downloaded from the unit itself.)