Okay, that's reasonable. Having investigated further, it looks like latching
is per-source rather than per-feed, so my "rollcall" message is actually
completely unnecessary--- each unit can simply latch its announcement
message, and then the controller will receive them all when it comes online.
Thanks again,
Mike
On 1 June 2010 20:52, Ken Conley <
kwc@willowgarage.com> wrote:
> Hi Mike,
>
> Think of topics like connecting to a live video feed -- whenever you
> connect, you receive the most recent feed. The examples you give
> demonstrate the latency/race condition of subscribers attempting to
> get that first message from the publisher. A publisher can have
> arbitrarily many subscribers, and not all of those subscribers are
> guaranteed to connect, so this is the intended behavior.
>
> There are several remedies that ROS supports:
>
> 1) latch=True: the last message you published is saved and is
> delivered to any new subscriber
> 2) subscriber callbacks (see rospy_tutorials/004_listener_subscribe_notify)
>
> Hope this helps,
> Ken
>
>
>
>
> On Tue, Jun 1, 2010 at 5:39 PM, Mike Purvis
> <mpurvis@clearpathrobotics.com> wrote:
> > Hey everyone,
> > I'm experiencing a curious issue with regards to a node which sends a
> > message on startup. The following works:
> > pub = rospy.Publisher("/clearpath/announce", Announce, latch=False)
> > rospy.init_node('controller')
> > pub.publish(action="rollcall")
> > However, if I initialize the node first before setting up the publisher,
> the
> > message send silently fails. No error, but the message never arrives, and
> > rostopic shows no activity:
> > rospy.init_node('controller')
> > pub = rospy.Publisher("/clearpath/announce", Announce, latch=False)
> > pub.publish(action="rollcall")
> > But, when I insert some delays, it works again!
> > rospy.init_node('controller')
> > rospy.sleep(0.5)
> > pub = rospy.Publisher("/clearpath/announce", Announce, latch=False)
> > rospy.sleep(0.5)
> > pub.publish(action="rollcall")
> > I assume that there's some initialization going on in a background
> thread;
> > is this a known/documented behavious? Is there some better way to handle
> it
> > than just these delays?
> > Thanks,
> > Mike Purvis
> > _______________________________________________
> > ros-users mailing list
> > ros-users@code.ros.org
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> >
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
(text/plain)