param set uri doesn't work for Player component about rosbag2 HOT 7 OPEN

Happy to check for sure.
@KenYN thank you in the meantime for the testing you are doing on this, it is unvaluable :)

from rosbag2.

There seems to be the possibility to add a callback.
https://roboticsbackend.com/ros2-rclcpp-parameter-callback/

Yes there are callbacks, though I will point out that the advice in that particular link is incorrect.

In particular, you should never make state changes based on the "on_set_parameters_callback". The purpose of that callback is to validate that the parameters are valid, not to make state changes. This is important because there can be an arbitrary chain of parameter validation callbacks, so if you were to make state changes, and a callback further down the line rejected the set, your state would be out of sync with what the parameter database shows.

As of Iron, we have a callback specifically for this purpose called post_set_parameters_callback that should be used instead. See http://docs.ros.org/en/rolling/Concepts/Basic/About-Parameters.html#parameter-callbacks for some more information, and https://github.com/ros2/demos/blob/a29e65623e8ace15b8253ab33f19f3d8165c3cfe/demo_nodes_cpp/src/parameters/set_parameters_callback.cpp for an example.

from rosbag2.

@roncapat Any ideas why ros2 param set /bag_player uri "/path/to/file2" doesn't work as expected?

from rosbag2.

Well, my first thought is that we are not handling any parameter update IMHO. Parameters are just parse one time at the beginning and stop.

Example:

storage_options.uri = node.declare_parameter<std::string>("uri", "");

after this line, storage_options.uri is not bound to any rclcpp::ParameterValue. It is a simple std::string. And nothing is done currently to support updated on the fly.

I will think a bit about how this could be done.

from rosbag2.

I believe that a big shift of paradigm would be needed here to implement this.
Currently, we have player_options and storage_options structures being a collection of parameter values, not rclcpp::ParameterValues. To do what you are asking, we should either inject in the already quite intricate architecture the concept of rclcpp::ParameterValue, down to classes like Reader or Writer. To avoid so, another option would be to inject instead explicit "setters" wherever needed to flow down any change of parameter (Assuming we can get notified by something that a parameter has changed).

This is just a preliminary analysis of course, feel free to add your point of view :)

An example:
Reader has no way to change opened file. You need to close a Reader and open it again. And this can only happen for example when Player is stopped. Multiply this by a huge number of potentially run-time modifyable params and you get a big headache. I agree with you however that this would become more user-firendly instead of unloading/loading again a Player component.

from rosbag2.

@KenYN @roncapat I think we will close this issue as unsupported by design.

@roncapat BTW as regards

(Assuming we can get notified by something that a parameter has changed).

Do you have ideas on how we can potentially get notified when the parameter got changed?

from rosbag2.

There seems to be the possibility to add a callback.
https://roboticsbackend.com/ros2-rclcpp-parameter-callback/

from rosbag2.