Not all published params can be set with a call to set_parameter

[bk-mtg]

All parameters are treated the same here:
https://github.com/PepperlFuchs/ROS_driver/blob/477d72066f8cfc6ecb960fc388c2a8f0e9f6a3ec/pf_driver/include/pf_driver/pf/r2000/pfsdp_2000.hpp#L85
But several of them (packet_type, start_angle, max_num_points_scan, skip_scans) can only be set during the call to request_handle_tcp or request_handle_udp, rather than with a call to set_parameter.

[hsd-dev]

You are right. Thanks for pointing out.

[hsd-dev]

#29 should solve it.

[bk-mtg]

I guess it's kindof a matter of what "solving" this means. I think to really do it properly, you have to stop the existing data stream from the R2000/R2300 and start a new one, but that's quite a bit of work and may raise other issues. May be that it's not worth that much effort to allow dynamic reconfigure, since most of the properties that can only be set that way probably aren't going to be changed while running. (BTW, left comments on the other PR using my other github account; sorry about that.)

[hsd-dev]

This is the statement in the R2000 protocol document:

It is recommended (but not required) to stop sensor data output while using set_scanoutput_config. In case scan data out-
put is active, the point in time when modified configuration settings are applied to the running data stream is non-deterministic.
After the new settings are applied, scan data output is suspended until the start of an new scan (skipping scan data pack-
ets in-between). If the client application depends on a deterministic switching behavior, it should stop scan data transmis-
sion first using stop_scanoutput, change settings using set_scanoutput_config and finally restart the data stream with
start_scanoutput.

I will take of this in the later PRs because as you said, it might raise other issues. Leaving the issue open for now.