search

OpenCyphal-Garage / yukon-old

An open suite of tools for observing, debugging, and interacting with a UAVCAN v1 bus.
http://uavcan.org
MIT License
31 stars 10 forks source link

Adding diagram of top-level functions for this version of Yukon #1

Closed thirtytwobits closed 5 years ago

pavel-kirienko commented 5 years ago

I recall that we've agreed to say "plug-and-play" instead of "dynamic node ID", perhaps the diagram should be updated?

Linjieqiang commented 5 years ago

Happy to see this project start ! Yukon now !

pavel-kirienko commented 5 years ago

Suppose that we've implemented a replay feature, where the user picks a CAN dump file (e.g., recorded by a flight recorder or by the tool itself) and replays a segment of it for an in-depth analysis. It is natural to expect other widgets to behave as if the tool was connected to an actual bus, except that the bus is read-only. Do such widgets still fall under the category "Requires Connection to a Bus"?

Consider the Computational Graph canvas (can we call it Klondike?). I see how it could be useful for a postmortem analysis; limiting the widget to the online mode only seems unnecessarily restrictive. To work in the post-mortem mode, the tool should be able to deduce the necessary information through observation of the pre-recorded exchanges, recognizing that a new exchange to obtain the missing information (e.g., node.GetInfo, node.port.GetStatistics) can't be initiated. Same applies to the Bus Monitor, Subscriber, and Plotter.

The Interactive Console could probably be useful on its own even if the tool is not connected to a bus and a log file is not loaded; e.g., for poking around DSDL definitions.

I am not saying that we definitely need these advanced analysis features in the first version, but the architecture should probably foresee their integration later?

thirtytwobits commented 5 years ago

I recall that we've agreed to say "plug-and-play" instead of "dynamic node ID", perhaps the diagram should be updated?

I'll fix this. Sorry

thirtytwobits commented 5 years ago

Suppose that we've implemented a replay feature, where the user picks a CAN dump file (e.g., recorded by a flight recorder or by the tool itself) and replays a segment of it for an in-depth analysis. It is natural to expect other widgets to behave as if the tool was connected to an actual bus, except that the bus is read-only. Do such widgets still fall under the category "Requires Connection to a Bus"?

Consider the Computational Graph canvas (can we call it Klondike?). I see how it could be useful for a postmortem analysis; limiting the widget to the online mode only seems unnecessarily restrictive. To work in the post-mortem mode, the tool should be able to deduce the necessary information through observation of the pre-recorded exchanges, recognizing that a new exchange to obtain the missing information (e.g., node.GetInfo, node.port.GetStatistics) can't be initiated. Same applies to the Bus Monitor, Subscriber, and Plotter.

The Interactive Console could probably be useful on its own even if the tool is not connected to a bus and a log file is not loaded; e.g., for poking around DSDL definitions.

I am not saying that we definitely need these advanced analysis features in the first version, but the architecture should probably foresee their integration later?

Yep. I'll be less specific in this diagram. See update.

pavel-kirienko commented 5 years ago

Cool. I suggest to be even less specific and instead of "CAN interface" say "Transport interface".

pavel-kirienko commented 5 years ago

Wireframes are cool, but how about replacing "CAN" with "Transport" though?

thirtytwobits commented 5 years ago

Wireframes are cool, but how about replacing "CAN" with "Transport" though?

This is not a wireframe; it's just a functional block diagram (a very simple one) to help flush out the high-level taxonomy. That means that what we call things is important for this PR and I'll work to be more bus agnostic in my names. New diagram on the way.

pavel-kirienko commented 5 years ago

I think the last diagram made a wrong turn. There is no reason to make high-level functions per-interface specific; perhaps my recent post about alternative transports can clarify what I am proposing. The previous version of the diagram was good except that it said "CAN" instead of "Transport".