Do you have some way of reproducing the behavior that you see? e.g. if
you record to a bag file and play back, do you still get the same
result? If so, I can debug more easily.

FYI: I'm out no week, so no rush

 - Ken


On Fri, May 14, 2010 at 10:30 AM, Stefan Kohlbrecher
<stefan.kohlbrecher@googlemail.com> wrote:
> Hi Ken,
>
> thanks for the quick explanation and code. Unfortunately the artifacts
> persist despite the proposed changes. I'm not sure if they got a
> little better, as that's hard to say without some longer, systematic
> testing.
>
> regards,
> Stefan
>
> 2010/5/10 Ken Conley <kwc@willowgarage.com>:
>> Looking at the code, my hunch is performance-related jitter inside of
>> rxplot. If you have timestamped data, this isn't an issue, but if you don't
>> have timestamped data, the best rxplot can do is look at the clock when it
>> receives the data. Looking at the code, rxplot is taking the timestamp later
>> than it should (and inside of a lock). If this lock is causing the jitter,
>> it should be easy to test by changing _ros_cb() in
>> rxtools/src/rxtools/rosplot.py to:
>>
>>     def _ros_cb(self, msg):
>>         t = rospy.get_time()
>>         try:
>>             self.lock.acquire()
>>             try:
>>                 self.buff_y.append(self._get_data(msg))
>>                 # #944: use message header time if present
>>                 if msg.__class__._has_header:
>>                     self.buff_x.append(msg.header.stamp.to_sec() -
>> self.start_time)
>>                 else:
>>                     self.buff_x.append(t -
>> self.start_time)
>>                 #self.axes[index].plot(datax, buff_y)
>>             except AttributeError, e:
>>                 self.error = RosPlotException("Invalid topic spec [%s]:
>> %s"%(self.name, str(e)))
>>         finally:
>>             self.lock.release()
>>
>> It's possible that this change won't be enough to eliminate the jitter, but
>> I'm interested if it is. If this change works, we can patch ROS
>> appropriately. I'll note that for non-timestamped data, jitter is always
>> possible as the receipt latency can cause these artifacts.
>>
>>  - Ken
>>
>> On Mon, May 10, 2010 at 5:25 AM, Ruben Smits <ruben.smits@mech.kuleuven.be>
>> wrote:
>>>
>>> On Monday 10 May 2010 14:15:14 Stefan Kohlbrecher wrote:
>>> > Hi everyone,
>>> >
>>> > I am currently trying out the Orocos-ROS integration. In the process
>>> > of doing so, I added a WritePort to my testing TaskContext that
>>> > oscillates a floating point variable between values 0.0f and 1.0f. The
>>> > task context runs at a update rate of 200 Hz. When I plot the values
>>> > with rxplot, I get a large amount of artifacts, as can be see the
>>> > attached file 'rxplot_jitter.png'. When pausing rxplot for a while and
>>> > resuming, the data plotted for the paused period looks correct as
>>> > expected (see ' rxplot_pause.png'). Is this normal behavior and can it
>>> > be improved somehow?
>>>
>>> I suspect this is a rxplot issue ..., but I don't know the internals of
>>> rxplot.
>>>
>>> If you look at the values using rostopic echo, do you see the same
>>> artifacts?
>>>
>>> Ruben
>>> _______________________________________________
>>> 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
>>
>>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>