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 delay mechanism posted by kushlik and discussed here
Happy for criticism/suggestions/drawbacks as to these approaches by others
Can you edit your question to include that section of the launch file?