Skip to content
This repository has been archived by the owner on Mar 7, 2022. It is now read-only.

Plotter time axis issue #18

Open
olliw42 opened this issue Aug 12, 2017 · 7 comments
Open

Plotter time axis issue #18

olliw42 opened this issue Aug 12, 2017 · 7 comments

Comments

@olliw42
Copy link

olliw42 commented Aug 12, 2017

Hey Pavel,

I think there is a bug in the plotting of data using Plotter. It seems as if the resolution on the time axis is not sufficient to resolve data which comes at higher rates.
Pl see the attached screen shots.
Fig1: Here the rate of the storm32.Status is set to 20 (ca 20 ms per message). As evident from the bus monitor every ca 20ms a message is received, and checking shows that each has a new data item. the plot looks as expected.
Fig2: Here the rate of the storm32.Status is set to 3 (ca 3 ms per message). As evident from the bus monitor every ca 3ms a message is received, and checking shows that each has a NEW data item. So, from the bus monitor everything seems perfect. However, the plot has these strange "steps/spikes". My first guess would be that for plotting a too low resolution for the time axis data is used.
The issue seems to start for rates below about 10-15 (clearly present at 10).

cheers, Olli

uavcanguitool-plotter-issue-02
uavcanguitool-plotter-issue-01

@pavel-kirienko
Copy link
Member

Thanks, Olli. The problem is not caused by the plotter. As you can see in the bus monitor window on the second screenshot, there are multiple frames that share the same timestamp down to microsecond. This is likely caused by the low resolution of the monotonic clock on Windows.

You could try to get around that by providing hardware time stamps from your CAN adapter. In this case, the SLCAN driver from Pyuavcan would automatically detect that the time stamps are provided, and it would start using them instead of relying on the low-resolution OS clocks. However, I'm not really sure whether the time base conversion algorithm (the one that converts the time stamps from the adapter time base into the time base of the operating system) is going to work well on Windows, since it still relies on the precision of the local monotonic clock, although to a lesser degree than the naive timestamping approach.

If you think that answers your question, please close the ticket.

@olliw42
Copy link
Author

olliw42 commented Aug 12, 2017

no, there are always only exactly 2 consecutive frames with identical timestamp, and these two belong to one and the same message (coincidentally the storm32.Status message has exactly 16 bytes), so, each new message arrives with a new timestamp

(in the monitor, Fig2, you see the 3rd line clicked, which marks the beginning of a new message)

@pavel-kirienko
Copy link
Member

I see now.

I think the problem could also be caused by the insufficient precision of float64 for high-resolution time stamps. The time stamps are provided in the Unix time base, so the values are quite large, and therefore the absolute resolution is low. This is how we convert them into the process-relative time base in the plotter process: https://github.com/UAVCAN/gui_tool/blob/4b8e69632796f9c652716257403f65327dcfb2f8/uavcan_gui_tool/widgets/plotter/window.py#L142

Perhaps we should use microsecond integers for timestamping like we do in Libuavcan (or Libcanard) since they provide a fixed high resolution independent of the magnitude.

If you have an hour, perhaps you could modify the timestamping logic in Pyuavcan and see if it resolves the problem?

@olliw42
Copy link
Author

olliw42 commented Aug 12, 2017

I'm not sure I understand what you're saying
the usage of "timestamping" and "timestamping logic" confuses me, I don't see any need to change anything with the time stamping, or anything in pyuavcan, it looks OK to me
to me it's only the conversion to the data which the Plotter uses which is imperfect

I once tried to run the Uavcan GUI Tool from the native py files, but it failed, for whatever reasons, which I did not investigate. So, I apologize, except of bringing this to your attention I'm not very useful here. :)

@olliw42
Copy link
Author

olliw42 commented Aug 14, 2017

hey Pavel

I thought I could give it another try, to run UavcanGUITool from python. The problem I had/have is this:

I went to the install folder, C:\Program Files (x86)\UAVCAN\UAVCAN GUI Tool. I was somehow expecting to see a uavcan_gui_tool.py, or any other .py which would look like the main script. The only thing I could find is the main.py in the uavcan_gui_tool subfolder, but then I start it I get

from . version import __version__
SystemError: Parent module not loaded, cannot perform relative import

I searched the web a bit, and this is obviously because of the ".", and that I should not run main.py directly.
But what to run else? I honestly have no idea.

@pavel-kirienko
Copy link
Member

@olliw42
Copy link
Author

olliw42 commented Aug 14, 2017

ok, thx
"tried" it, which means I copied this file into \UAVCAN\UAVCAN GUI Tool (from the line "from uavcan_gui_tool.main import main" I concluded that's the correct place), and changed it's extension to .py, since otherwise it would have conflicted with the subfolder of same name, and ran it. But I again do get an error. This time something with a expat.py file in my Python install folder, and an Import Error: DLL load failed (I do have a working PyQT, WinPython-64bit-3.4.3.5).
Obviously I would need instructions for dummies and I have no clue what I'm doing. So, I again give up with that, it's beyond my paycheck.

Thx for your willingness to help. :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants