Revision history [back]

The launch file will load the parameters before the nodes are started. I had a similar issue where a System configurator node had to perform a calculation on some data and post that before a second node could use it.

In my case I solved it by simply polling until the parameter had been updated. Like this:

rospy.init_node('my_node_name', anonymous=False) 

# My normal parameter reads

job_file_persistence_time_in_seconds = rospy.get_param('/file_system/job_file_persistence_time_in_seconds')
usb_media_poll_interval = rospy.get_param('/file_system/usb_media_poll_interval')

# My special parameter reads after waiting for the system_configurator node to do its work

system_node_id = 0

while system_node_id == 0: 
    system_node_id = rospy.get_param('/canbus/system_node_id')   # Thread will keep looping here until it is set

# Start the real work

In your case the '0' could be your dummy parameter. You could also include a timeout if required

Happy for criticism/suggestions/drawbacks as to this approach by others

The launch file will load the parameters before the nodes are started. I had a similar issue where a System configurator node had to perform a calculation on some data at startup and post that before a second node could use it.

In my case I solved it by simply polling until the parameter had been updated. Like this:

rospy.init_node('my_node_name', anonymous=False) 

# My normal parameter reads

job_file_persistence_time_in_seconds = rospy.get_param('/file_system/job_file_persistence_time_in_seconds')
usb_media_poll_interval = rospy.get_param('/file_system/usb_media_poll_interval')

# My special parameter reads after waiting for the system_configurator node to do its work

system_node_id = 0

while system_node_id == 0: 
    system_node_id = rospy.get_param('/canbus/system_node_id')   # Thread will keep looping here until it is set

# Start the real work

In your case the '0' could be your dummy parameter. You could also include a timeout if required

Happy for criticism/suggestions/drawbacks as to this approach by others

The launch file will load the parameters before the nodes are started. I had a similar issue where a System configurator node had to perform a calculation on some data at startup and post that before a second node could use it.

In my case I solved it by simply polling until the parameter had been updated. Like this:

rospy.init_node('my_node_name', anonymous=False) 

# My normal parameter reads

job_file_persistence_time_in_seconds = rospy.get_param('/file_system/job_file_persistence_time_in_seconds')
usb_media_poll_interval = rospy.get_param('/file_system/usb_media_poll_interval')

# My special parameter reads after waiting for the system_configurator node to do its work

system_node_id = 0

while system_node_id == 0: 
    system_node_id = rospy.get_param('/canbus/system_node_id')   # Thread will keep looping here until it is set

# Start the real work

In your case the '0' could be your dummy parameter. You could also include a timeout if required

Alternatively you could just not set the dummy parameter in the yaml file and do something like:

while not rospy.has_param('your_parameter'):
    pass

Essentially you are creating a different state space for your node, one with the parameter set, and one without

Happy for criticism/suggestions/drawbacks as to this approach by others

The launch file will load the parameters before the nodes are started. I had a similar issue where a System configurator node had to perform a calculation on some data at startup and post that before a second node could use it.

In my case I solved it by simply polling until the parameter had been updated. Like this:

rospy.init_node('my_node_name', anonymous=False) 

# My normal parameter reads

job_file_persistence_time_in_seconds = rospy.get_param('/file_system/job_file_persistence_time_in_seconds')
reads    

usb_media_poll_interval = rospy.get_param('/file_system/usb_media_poll_interval')

# My special parameter reads after waiting for the system_configurator node to do its work
solution

system_node_id = 0

while system_node_id == 0: 
    system_node_id = rospy.get_param('/canbus/system_node_id')   # Thread will keep looping here until it is set

# Start the real work

In your case the '0' could be your dummy parameter. You could also include a timeout if required

Alternatively you could just not set the dummy parameter in the yaml file and do something like:

while not rospy.has_param('your_parameter'):
    pass

Essentially you are creating a different state space for your node, one with the parameter set, and one without

Happy for criticism/suggestions/drawbacks as to this approach by others

The launch file will load the parameters before the nodes are started. I had a similar issue where a System configurator node had to perform a calculation on some data at startup and post that before a second node could use it.

In my case I solved it by simply polling until the parameter had been updated. Like this:

rospy.init_node('my_node_name', anonymous=False) 

# My normal parameter reads    

usb_media_poll_interval = rospy.get_param('/file_system/usb_media_poll_interval')

# My special parameter solution

system_node_id = 0

while system_node_id == 0: 
    system_node_id = rospy.get_param('/canbus/system_node_id')   # Thread will keep looping here until it is set

# Start the real work

In your case the '0' could be your dummy parameter. You could also include a timeout if required

Alternatively you could just not set the dummy parameter in the yaml file and do something like:

while not rospy.has_param('your_parameter'):
    pass

Essentially you are creating a different state space for your node, one with the parameter set, and one withoutwithout. Therefore instead of a thread blocking while loop as I have used, you could have a simple if branching down to a common ros::spinOnce() and sleep

Happy for criticism/suggestions/drawbacks as to this approach these approaches by others

The launch file will load the parameters before the nodes are started. I had a similar issue where a System configurator node had to perform a calculation on some data at startup and post that before a second node could use it.

In my case I solved it by simply polling until the parameter had been updated. Like this:

rospy.init_node('my_node_name', anonymous=False) 

# My normal parameter reads    

usb_media_poll_interval = rospy.get_param('/file_system/usb_media_poll_interval')

# My special parameter solution

system_node_id = 0

while system_node_id == 0: 
    system_node_id = rospy.get_param('/canbus/system_node_id')   # Thread will keep looping here until it is set

# Start the real work

In your case the '0' could be your dummy parameter. You could also include a timeout if required

Alternatively you could just not set the dummy parameter in the yaml file and do something like:

while not rospy.has_param('your_parameter'):
    pass

Essentially you are creating a different state space for your node, one with the parameter set, and one without. Therefore instead of a thread blocking while loop as I have used, you could have a simple ifif rospy.has_param('your_parameter'): branching down to a common ros::spinOnce() and sleepsleep() if you wanted the node doing other things while waiting for the parameter

Happy for criticism/suggestions/drawbacks as to these approaches by others

The launch file will load the parameters before the nodes are started. I had a similar issue where a System configurator node had to perform a calculation on some data at startup and post that before a second node could use it.

In my case I solved it by simply polling until the parameter had been updated. Like this:

rospy.init_node('my_node_name', anonymous=False) 

# My normal parameter reads    

usb_media_poll_interval = rospy.get_param('/file_system/usb_media_poll_interval')

# My special parameter solution

system_node_id = 0

while system_node_id == 0: 
    system_node_id = rospy.get_param('/canbus/system_node_id')   # Thread will keep looping here until it is set

# Start the real work

In your case the '0' could be your dummy parameter. You could also include a timeout if required

Alternatively you could just not set the dummy parameter in the yaml file and do something like:

while not rospy.has_param('your_parameter'):
    pass

Essentially you are creating a different state space for your node, one with the parameter set, and one without. Therefore instead of a thread blocking while loop as I have used, you could have a simple if rospy.has_param('your_parameter'): branching down to a common ros::spinOnce() and sleep() if you wanted the node doing other things while waiting for the parameter

Another approach which is trivially implemented is to delay the launch of the node requiring the parameter using the launch_prefix tag. This of course has the disadvantage of being less deterministic but effective.

<node name="yr_node" pkg="yr_pkg" type="yr_type" launch-prefix="bash -c 'sleep $(arg node_start_delay); $0 $@' " />

Happy for criticism/suggestions/drawbacks as to these approaches by others

The launch file will load the parameters before the nodes are started. I had a similar issue where a System configurator node had to perform a calculation on some data at startup and post that before a second node could use it.

In my case I solved it by simply polling until the parameter had been updated. Like this:

rospy.init_node('my_node_name', anonymous=False) 

# My normal parameter reads    

usb_media_poll_interval = rospy.get_param('/file_system/usb_media_poll_interval')

# My special parameter solution

system_node_id = 0

while system_node_id == 0: 
    system_node_id = rospy.get_param('/canbus/system_node_id')   # Thread will keep looping here until it is set

# Start the real work

In your case the '0' could be your dummy parameter. You could also include a timeout if required

Alternatively you could just not set the dummy parameter in the yaml file and do something like:

while not rospy.has_param('your_parameter'):
    pass

Essentially you are creating a different state space for your node, one with the parameter set, and one without. Therefore instead of a thread blocking while loop as I have used, you could have a simple if rospy.has_param('your_parameter'): branching down to a common ros::spinOnce() and sleep() if you wanted the node doing other things while waiting for the parameter

Another approach which is trivially implemented is to delay the launch of the node requiring the parameter using the launch_prefix tag. This of course has the disadvantage of being less deterministic but effective.

<node name="yr_node" pkg="yr_pkg" type="yr_type" launch-prefix="bash -c 'sleep $(arg node_start_delay); $0 $@' " />

I first saw this last suggested posted by kushlik and discussed here

Happy for criticism/suggestions/drawbacks as to these approaches by others

The launch file will load the parameters before the nodes are started. I had a similar issue where a System configurator node had to perform a calculation on some data at startup and post that before a second node could use it.

In my case I solved it by simply polling until the parameter had been updated. Like this:

rospy.init_node('my_node_name', anonymous=False) 

# My normal parameter reads    

usb_media_poll_interval = rospy.get_param('/file_system/usb_media_poll_interval')

# My special parameter solution

system_node_id = 0

while system_node_id == 0: 
    system_node_id = rospy.get_param('/canbus/system_node_id')   # Thread will keep looping here until it is set

# Start the real work

In your case the '0' could be your dummy parameter. You could also include a timeout if required

Alternatively you could just not set the dummy parameter in the yaml file and do something like:

while not rospy.has_param('your_parameter'):
    pass

Essentially you are creating a different state space for your node, one with the parameter set, and one without. Therefore instead of a thread blocking while loop as I have used, you could have a simple if rospy.has_param('your_parameter'): branching down to a common ros::spinOnce() and sleep() if you wanted the node doing other things while waiting for the parameter

Another approach which is trivially implemented is to delay the launch of the node requiring the parameter using the launch_prefix tag. This of course has the disadvantage of being less deterministic but effective.

<node name="yr_node" pkg="yr_pkg" type="yr_type" launch-prefix="bash -c 'sleep $(arg node_start_delay); $0 $@' " />

I first saw this last suggested delay mechanism posted by kushlik and discussed here

Happy for criticism/suggestions/drawbacks as to these approaches by others