Homepage GitHub

GUI Tool – Next Generation


(Pavel Kirienko) #21

I just removed my vote for Excavator. The story behind it is that there was one parked on the campus a few days ago.

Both Yukon and Excavator are leading, but I think we can all agree that Yukon is just better, so let’s go with that.


(Scott Dixon) #22

https://github.com/UAVCAN/Yukon is up. I’ll fork and start pull requests that include design documents.


(Scott Dixon) #23

Proposed Logo (It’s Christmas. I have time to draw and stuff. Stop laughing at me)

image


(Pavel Kirienko) #24

Proposed Logo

I see a dog. What’s my diagnosis?



Random ideas galore. What if we turned the computational graph widget into an interactive graphical programming utility?

Suppose we introduced a convention (recommendation) that all ports with non-fixed ID can be configured via a configuration parameter (register) named in a particular way, e.g., uavcan.subj.motor_angvel – this example shows us a configuration parameter which sets the subject ID of a data link that carries the angular velocity of a certain motor; the part uavcan.subj. is dictated by the convention, and the suffix motor_angvel is defined by the user/vendor, it could be anything. The range of the parameter should be [0, 65536] (Natural32); the value 65536 is needed to represent an unconfigured subject ID.

Suppose we have a bus that contains seven nodes. The nodes have just been connected and powered on for the first time, the bus is non-functional yet. The graph widget shows us this:

Boring. The user picks up their computer mouse, clicks on the connection point labeled servo_angle_roll, and draws the mouse over to the first servo’s connection point labeled angle. The user lets go of the computer mouse, thereby having created a new subject. But wait, this new subject does not have a fixed subject ID, yet we need one.

A pop-up dialog saves the day: subject_id_of_new_link

Having specified the subject ID (let’s say 12), the user clicks OKAY. Yukon takes notice and issues two requests of type uavcan.register.Access to both of the involved nodes – the autopilot and the servo:

  • The request to the autopilot assigns the value 12 to the register uavcan.subj.servo_angle_roll.
  • The request to the servo assigns the value 12 to the register uavcan.subj.angle.

Done, the link is now created (although it may not be active yet, depending on whether the nodes require a restart for the parameter change to take effect).

If the user wanted to add yet another connection point to the same subject, the dialog box exercise wouldn’t have be repeated, because Yukon will be able to deduce that we’re connecting a new item to an already existing subject with a known subject ID.

Suppose that, having repeated the procedure a dozen of times, the user ended up with a satisfactory configuration:

The diagram is known to be incomplete and a bit misleading, because there always exist subjects with fixed port IDs that do not require a configuration. They are not shown in this demo. In the real widget they should probably appear as unchanging static links that can’t be disconnected or moved (they are static, after all).

Should the user desire to get rid of an unwanted connection, they would just disconnect an appropriate link, and Yukon will issue a request uavcan.register.Access with the value set to 65536.

It is assumed here that Yukon does not have any prior knowledge of the properties of the involved nodes; the information is deduced at runtime by evaluating the available registers; specifically, by matching all available register names against uavcan.subj.*.

An overly attentive reader would point out that we never once asked ourselves: “is it type safe?” Indeed, such blatant disregard of type safety is borderline illegal.

Unfortunately, the type introspection tools we have at our disposal (namely uavcan.node.port.GetInfo) operate at a level of abstraction that is too low to be useful in this setting. The core problem here is that the type information is attached to a port ID rather than a particular function available in the node. The important implications are:

  • Type introspection data is dependent on the port ID settings.
  • Type introspection can’t be performed until a port ID is assigned. Which in turn means that the correctness of a new subject link can’t be verified until the link is established.

What can we do about this? Raising the level of abstraction of the existing introspection API doesn’t seem like a decent idea because all options that come to mind so far seem extremely complex and implementers may be hesitant to support them. Another solution is to go the way of other protocols and introduce the optional concept of electronic datasheets, where the type information will be explicitly stated. The third solution is to further extend the register naming conventions by adding a new name pattern: uavcan.type.*, where the asterisk stands for the port name – e.g., uavcan.type.servo_angle_roll – the value contained in the register will be the name of the data type together with the major version number, like uavcan.si.angle.Scalar.1.

Ultimately we may want to go both ways: introduce electronic datasheets at some point in the future, and also enrich introspection by specifying the register naming conventions (uavcan.subj.*, uavcan.type.*). The electronic datasheets are likely to be preferred in high-reliability settings where any extra logic that is not directly related to the end application implemented on the node is undesirable; the way of introspection is likely to be more useful for highly sophisticated setups involving many complex COTS nodes from different vendors (robotics, autonomous driving, etc.). This is is unlikely to appear in the spec before UAVCAN v1.1, but nobody is stopping us from implementing this logic in Yukon as a vendor-specific extension which is to be specified later.


High level node descriptor
(Scott Dixon) #25

Oh geez @pavel.kirienko, I’m getting flashbacks to directshow.


(Lin Jieqiang) #26

(Pavel Kirienko) #27

Oh wow. May I ask you to share a few words about that undertaking? I see that it is based on UAVCAN v0, which makes sense considering that I am yet to publish my rewrite of pyuavcan which is UAVCAN v1.0-compatible. Do you have migration to UAVCAN v1.0 on your short-term roadmap?


(Theodoros Ntakouris) #28

I have much more experience on frontend/backend/web stuff than C++ / I’m able to help much much more with this one!

I think that the best thing at this point in time (for web, at least) would be

  1. React
  2. Vue

(with that priority).
uavcan-web is extra nice; Having such a separation layer is a must for a portable UI. Edit: Api endpoint versioning could go in par with potential breaking changes in the spec.

In the end, it would not be hard to make some UI with any technology. The only thing that makes me wonder about implementation & technology details is

‘‘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.’’

Perhaps we can provide minumum-boilerplate starting project templates so anyone can use this.

PS. Some 2 extra name recommendations: uavcan shark / uavcan cat (inspired from wireshark / netcat)


(Scott Dixon) #29

This is great to hear! Us bit twiddlers have been looking for help from UI wranglers for awhile now. @Linjieqiang would you be willing to work with @Zarkopafilis to start Yukon as a Vue/Flask project?

I’d like to avoid React because Facebook and messed with the licensing in the past (I’m not sure if they changed it back to plain-vanilla MIT or if they still have the “we haz all your patenz” clause in it but I’d like to avoid it).


(Theodoros Ntakouris) #30

I’m cool with that. We can start by working out some endpoints and data contracts, then UI and backend can go sort of in parallel if we split the work up.

I’m away at Germany due to a family trip. I’ll be back at 21/Feb and after finishing the TxQueue PR (a very small fix and it should be ready), we can start iterating the agile way, without having a strict wireframe spec.

I guess we can start with some mockups too?


(Scott Dixon) #31

This is great to hear! I have one PR pending in Yukon (Paging @pavel.kirienko -> https://github.com/UAVCAN/Yukon/pull/1) that lays out some very initial guidelines. Mostly I want to build a very modern GUI that avoids windows, dialogs, drop-down menus, and other dated interactions that nobody really likes. We should take our design cues from the web and IDEs that aren’t Eclipse (e.g. vscode and Atom both have a lot of nice interactions we could emulate).

I really don’t have time to contribute much to this effort other than help review and consult since my time for open-source work is dedicated to libuavcan these days but I’ll do what I can to get this started. It’s really very important to the ongoing success of uavcan.

We should also write down the final technology decisions in the Yukon readme. We did not consider an Electron based front-end if you have experience with that at all? Barring that I think Flask/Vu.js might be a good start for the front-end. What’s most important is to get a good interface layer between the core python toolset and any GUI we want to put on top of it.


(Pavel Kirienko) #32

Sorry, I hadn’t realized that it’s been waiting for my review. I normally ignore push notifications (maybe that’s because I push a lot), so in the future don’t hesitate to nudge me relentlessly if you need me to look at something. Sorry.

Crap. I love all that stuff. Can we at least keep a tiny command line hidden in there somewhere? :keyboard:


I should probably inform the public here that my pyuavcan rewrite is fully asynchronous and requires Python 3.6+ at the moment.


(Theodoros Ntakouris) #33

+1 for the command line. It needs to be decided whether it would be based on the interface layer (REST or whatever), or on newest pyuavcan.


(Scott Dixon) #34

We should have two “command-lines” actually. First: anything that you can do through the GUI you should be able to do through a command-line-only python script (i.e. we shall have feature parity between the GUI and either pyuavcan or an automation layer on top of pyuavcan). Second: we should have a “one-box” widget like vscode has via CMD+P that allows navigation using the keyboard.

Which re-raises the question: should this be an Electron application or even a VSCode extension?


(Pavel Kirienko) #35

My humble opinion is that things like Electron and VSCode come and go, whereas standalone web apps seem more dependable in the long term.


(Scott Dixon) #36

Fair enough but I think the two are a bit different. Electron is an application framework that is simply more full-featured and higher-level then our proposed flask/vu.js framework. VSCode is something that can fall out of favor which would affect us.

So “Which re-raises the question: should this be an Electron application?”


(Lin Jieqiang) #37

@scottdixon I also think Electron maybe is a better choose for us.


(Scott Dixon) #38

Yeah. I think we could build something like this:

image

Where we could also allow UI remoting by skipping the spawning of the local process and connecting to an existing python service:

image

This also suggests a nice separation of work:

  1. Front-end - We can have one person concentrate on just the nodejs front-end without needing to touch python.
  2. automation/service layer - We can have a person that concentrates on the python service API and command-line automation components.
  3. pyuavcan - the automation./service layer is built on pyuavcan so this is another interface layer we can separate concerns at.

We might even benefit from moving the automation service into its own project giving us:

Yukon - Javascript GUI
[automation project] - RESTful-HTTP and commandline automation on top of pyuavcan.
Pyuavcan - Python implementation of UAVCAN

Thoughts?


(Theodoros Ntakouris) #39

Exactly.

Although I would not suggest creating an electron app, just to launch the python service; a very small python layer that also serves the frontend at a standard browser, while also starting the daemon is sufficient.

Wireframes first, feature & usability discussion and then, we can start establishing some contracts for the rest api endpoints.


(Scott Dixon) #40

So I think we agree on this:

image

(If you don’t know UML, the circle on the end of a stick, or “lollipop” means “interface”)

But let’s take a moment to compare Electron versus simply serving the UI from the automation layer:

With Electron we get a framework that provides desktop GUI integration, packaging, updates (either automatic or push notification of availability) and a known, stable browser environment. The simplest user story for getting started is:

  1. Make sure you have Python3 installed.
  2. Download Yukon
  3. Open Yukon

If we don’t use Electron we still get packaging via PyPI but we no longer have a stable browser environment nor desktop integration. This adds a few steps:

  1. Make sure you have Python3 and pip installed.
  2. Make sure you have [insert browser requirements here]
  3. pip install Yukon
  4. start Yukon.
  5. Open your browser to localhost:[yukon port]

The latter isn’t the end of the world given that, if you know how to use pip you probably can handle this level of complexity. That said, we should consider the difficulty of diagnosing UI errors when you don’t control the browser. For the latter configuration we’ll have a class of bugs where the user reports “when I do x, y goes wrong” for which we’ll respond “we can’t reproduce this. What browser and operating system are you using? Do you have any weird extensions installed? How old is this browser? What other tabs do you have open?” (etc).

Thoughts on this @Zarkopafilis?