You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
IMO, robot_frames should initially publish each transformation once right when starting up, with a time stamp that's long in the past but non-zero (e.g., 1). If we connect the output of robot_frames to transformer, this would cause transformer to register all the required streams with its internal stream aligner. That way, if robot_frames doesn't get some joint states on its input port (e.g., because the component that provides the joint states is not running yet), transformer would properly drop the data samples during that period.
Currently, transformer fires its callback, but inside the callback, the registered transformations fail.
BTW, even with this fix, stuff is getting ugly fast, because we have to be very careful with the order of initialization. Here is a small example for a task (urdf_filter) that uses a transformer internally and receives data from robot_frames::Task:
# first configure robot_frames, so that the output ports are createdrobot_frames.configureurdf_filter.configure# next, connect the portsrobot_frames.each_output_portdo |port|
ifport.type == urdf_filter.input_tf.typeport.connect_tourdf_filter.input_tf,type: :buffer,size: 10000endend# we have to start this first, so that urdf_filter processes# the messages generated by robot_frames, right?urdf_filter.start# this will publish the initial set of messagesrobot_frames.start
If we switch any of these steps around, things will stop working, correct?
If we switch any of these steps around, things will stop working, correct?
Correct. The problem here is that the way we use the RTT dataflow assumes that it is used to transmit dynamic data.
One way to mitigate this is to turn keepLastWrittenValue on the robot_frames output port (this has to be done in C++, not supported by orogen AFAIK). You can then use the init: true flag in the connection policy when connecting the ports, which ensures that the last written value is used to initialize the connection. I am however not sure that it works on clear() (i.e. when a task starts)
IMO, robot_frames should initially publish each transformation once right when starting up, with a time stamp that's long in the past but non-zero (e.g., 1). If we connect the output of robot_frames to transformer, this would cause transformer to register all the required streams with its internal stream aligner. That way, if robot_frames doesn't get some joint states on its input port (e.g., because the component that provides the joint states is not running yet), transformer would properly drop the data samples during that period.
Currently, transformer fires its callback, but inside the callback, the registered transformations fail.
See rock-core/drivers-transformer#11.
BTW: Is it legal to write stuff to ports inside the
startHook
? If not, we need to find a way to trigger theupdateHook
once after startup.The text was updated successfully, but these errors were encountered: