Homepage GitHub

GUI Tool – Next Generation

(Scott Dixon) #1

I wanted to start a thread about the next generation of the GUI tool. As some might be aware the current version is encumbered by a GPL license in the Python binding for the QT GUI toolkit. Because one of the core features of UAVCAN is that “the specification and high quality reference implementations are open and free to use” we must find an alternative.

The current thinking (agreed upon at the recent Stockholm conference) is that we should start over using pyuavcan as the basis for the GUI but presenting this GUI as a JavaScript UI served from a local python process (e.g. Like Jupyter notebooks are served when run locally).

There are two important points to discuss in this thread:

1. What GUI toolkit should we use?

  • Angular?
  • React?
  • Ember?
  • ???

2. Is anyone in the community interested in taking on development of this GUI?

The current maintainers lack the time and expertise to take on a Javascript GUI while developing v1.

SI namespace design
Yukon design megathread
(Pavel Kirienko) #2

Here comes my personal wish list. Note that I intend to start working on an async-based rewrite of PyUAVCAN once the spec draft is finished.

Multi-node concurrent configuration tool

Many nodes, such as motor controllers, often require identical configuration to be shared across multiple devices. Shared configuration parameters are a subset of all parameters available on nodes; for example, uavcan.node_id will have to be unique, whereas motor_resistance are likely to be the same for all controllers.

Some parameters may have to be distributed across heterogeneous node sets, such as CAN bus bit rate.

The GUI tool should allow the user to batch-reconfigure an arbitrary set of nodes on the bus. Probably this should be arranged like some sort of table, where columns are nodes, and rows are configuration parameters:

Parameter name 12 42 123
param_a 1 2 <N/A>
param_b 12.34 -2.45 100500
param_c <N/A> 1, 2 2, 89

Parameter import/export

It should be possible to load/store configuration parameters to/from a node (or multiple nodes, as above) from/to file on disk.

Computational graph display with statistics

Quote from PR:

uavcan.node.GetPorts, uavcan.node.GetPortInfo, uavcan.node.GetPortStatistics - these data types provide a simple yet very powerful API that allows one to reconstruct the computational graph, collect the main communication metrics (input/output/errors) in real time, and verify that all nodes use compatible data types for communication with each other. Eventually, when the new GUI tool is around, it will be able to build things like this, showing the traffic intensity and transport errors in real time:

Bus monitor with logging

The existing bus monitor seems to have most of the required functionality. What is missing is the ability to log data (raw CAN frames with timestamps) to a file. For the file format, I suggest we use Popcop frame format, like HDLC – it is very simple, offers a transparent channel, and uses a strong CRC32C algorithm.

Logging to a file from the browser might be impossible though, so this functionality may need to be implemented on the server and controlled remotely from the browser with the ability to download the log file when completed.

Log file analysis

I haven’t given much thought to this idea yet, this is a highly complex feature which probably shouldn’t be implemented in the first edition of the tool. What follows is a highly disorganized collection of random ideas.

Ideally I would like to be able to load a frame dump file (which contains only timestamped CAN frames; or, well, not necessarily CAN, but we don’t support other protocols yet) recorded either by the tool itself or by a third-party hardware (which is why it is important to agree on a particular format beforehand), and let the tool perform an in-depth analysis of the state of the bus at any given moment in time, with a convenient overview of important events that were happening on the bus for the duration of the log file.

For example, suppose we have an hour long data dump from a black box flight recorder (which is stupid and all it does is just storing CAN frames on a flash disk with local monotonic timestamps). Having opened the recorded file, we should be able to see a brief event overview on a timeline, where important events are marked, such as: a new node appeared, a diagnostic message emitted, and so on, correlated with a bus load plot (so that we can see bus load abnormalities easily) and the system time (recovered from time sync messages correlated with the monotonic timestamps from the log file). There should be some kind of a cursor, which the user can slide across the timeline. Having positioned the cursor at a particular location, the user would get a sample of the current state of the bus at this exact moment of time: which nodes are online, what are their statuses, and so on. It should be possible to replay segments of the timeline to plot values and study the data exchanged over the bus during that segment. It should be possible to export parsed data from a particular subject to a CSV, or search for a particular data pattern on the bus (e.g. find the first occurence where abs(climb_rate) > 10). The tool should be able to automatically attempt to parse the entire data set and highlight sections where data could not be parsed, possibly indicating connectivity problems. Ideally it should be possible to correlate multiple dump files in the same analysis session, to support recordings from redundant transports. My wish list is very long but I perceive I should stop here.

At one point in the past I spent a lot of time working with the ROS logging system, you can find some info here for inspiration: http://wiki.ros.org/rqt_bag


Supremely important for debugging. Nothing to add here, the feature is self-explanatory. I am generally okay with the plotter we have in the current GUI tool, except that its configuration interface is a bit clumsy and not so user-friendly, perhaps it could be improved.

Publishing tool

In the current GUI tool there is a “ESC panel”, which works, but it’s created for a very specific, narrow use case. I think it should be possible to create a generic alternative which would allow the user to publish arbitrary messages or invoke arbitrary services by providing a dynamically-constructed GUI based on the DSDL definition of the data type in use. That would be great to have, doesn’t seem very hard to implement.

Other features available in the current GUI tool

This includes the log viewer, dynamic node ID allocator, and the file server (the last two are implemented in PyUAVCAN). The file server is required for firmware updates.

Yukon design megathread
Yukon design megathread
Yukon design megathread
(Scott Dixon) #3

I’d like to add:

Panel Framework

An API and mechanism for easily and dynamically adding custom UI panels to the gui. This allows system developers and vendors to provide highly specific controls for a given system/component.

It would also be interesting to define a way to associate a set of DSDL with a panel in a packaging format that would allow a vendor of, for example, a particular ESC to deliver the types and UI for their product using pypi or npm or something similar.

(Lin Jieqiang) #4

So when shall we start this project? Looking forward to it.

(Pavel Kirienko) #5

The first step is to finish the specification: https://github.com/UAVCAN/specification/issues/42

Then we should update PyUAVCAN to make it compatible with the new spec (actually it will be a full rewrite): https://github.com/UAVCAN/pyuavcan

When the above are done, we will be able to start working on the new GUI. Meanwhile we could use help with libcanard (which also requires update to UAVCAN v1.0).

(Scott Dixon) #6

I think we can start on wireframes for the UI @pavel.kirienko?

(Pavel Kirienko) #7

You are right. I’m probably a bit too hung up on finishing the spec and the reference implementations; nothing is stopping us from starting with the GUI part and working out the general architecture. Who wants to spearhead this?

(Scott Dixon) #8

This is where I betray the fact that I have, in-fact, built a few user interfaces in my career. As such I have some experience working with information architects and UI designers and can pretend I learned something about those disciplines and volunteer do the wireframes. That said, If there are real creative types out there they should speak up now before I decide to make every user action require 10 mouse clicks and a scroll wheel.

(Scott Dixon) #9

First things first: repos. Do we create a new repo for the new “gui tool” (and come up with a better name) or do we just start a v1 branch in the current repo?

I’d like to start a new repo just named “tools” that has a GUI as one of the tools. This leaves space for command-line tools to be developed as well and kept in this repository.

We might also want to refer to the GUI using something less generic then “gooey tool”. What about calling it the “UAVCAN control station” or “UAVCAN control suite”. Let’s make a “my name is best” list like we did for naming Subjects:

  1. UAVCAN control station (UCS)
  2. UAVCAN control suite (UCS)
  3. UAVCAN Diagnostics and Control (UDC)
  4. Visual UAVCAN (VUC)
  5. UAVCAN connect (UConn)
  6. UAVCAN 360 (this is a joke, somehow I went all Microsoft for the last three of these)
  7. The Best Damned User Interface Ever Built Using Python to Serve Javascript (BDUIEBUPSJ)
  8. Cannery
  9. CAN Opener
  10. CAN NT
  11. (sorry, this is fun)

(Pavel Kirienko) #10

I decide to make every user action require 10 mouse clicks and a scroll wheel

Computer mouse was invented for a reason, right?

I’d like to start a new repo just named “tools” that has a GUI as one of the tools. This leaves space for command-line tools to be developed as well and kept in this repository.

Eh, I would rather see a dedicated repo for the gooey tool, it seems important enough for that. How many command-line tools can there be anyway, and are we sure they should be versioned together with the gooey tool?

We might also want to refer to the GUI using something less generic then “gooey tool”.

I am ashamed of myself that I couldn’t come up with a better name. We must fix this.

  1. You said “UAVCAN Diagnostics and Control (UDC)”; surely you meant UAVCAN Command and Conquer (UCNC)?
  2. Excavator.
  3. In the spirit of “bus master” there could be a Bus Vassal.
  4. Lord of the Bus (one tool to rule them all, one tool to find them, etc).
  5. Cool Bus.

(Alexander Sysoev) #11

How about voyeur? After all, this tool is often used to EXPLORE what is there on the bus

(Alexander Sysoev) #12

Though LOTB seems bizarre enough. I like it

(Scott Dixon) #13

Okay. Agreed. Once we have a name I’ll start a new repo and start opening issues like “pick a UI widget framework” and “pick a python web framework”.

synonyms: peeping Tom, pervert, watcher; informal perv

…uh, no :slight_smile:

(Pavel Kirienko) #14

@kjetilkjeka please join us here.

@scottdixon do you think LOTB is legally safe?

Another (lame) option is “U-can”.

(Scott Dixon) #15

I can’t comment on any copyrights other then to say satire seems generally well-protected in western law. That said, I’m not a big fan of LOTB since it requires people to get the joke to understand the name.

Here are the names that I think are reasonable albeit boring (didn’t someone suggest Canny-McCanface yet?)

(not in any order)

  • Excavator
  • U-can
  • UAVCAN control station (UCS)
  • UAVCAN control suite (UCS)
  • UAVCAN Diagnostics and Control (UDC)
  • UAVCAN connect (UConn)
  • Cannery

(Scott Dixon) #16
  • Excavator
  • U-can
  • UAVCAN control suite (UCS)
  • UAVCAN Diagnostics and Control (UDC)
  • UAVCAN connect (Uconn)
  • Cannery
  • None of these names

0 voters

(Pavel Kirienko) #17

UAVCAN connect (UConn)

How about Yukon

(Pavel Kirienko) #18

I also like “None of these names”, very clever, although a bit awkward to use.

(Scott Dixon) #19

Second Round Vote

  • Yukon
  • Excavator
  • UAVCAN connect (Uconn)
  • Cannery

0 voters

(Scott Dixon) #20

Ugh. Excavator? I was really hoping for Yukon. Okay: why Excavator? What’s the story behind that name?