Homepage GitHub

GUI Tool – Next Generation

(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:


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


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


(Theodoros Ntakouris) #39


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:


(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?

(Theodoros Ntakouris) #41
  1. We can use babel to ensure browser compatibility
  2. Some styling errors may occur on edge cases, but I don’t think that’s a problem, really
  3. Electron adds a 80+ MB (if I recall correctly) executable size, that’s really bad: It’s a browser that runs in a desktop environment after all.
  4. We can have a script that automates the installation – pip is not that easy to use really
  5. starting Yukon can fire up the default system browser as well as the python service and what not
  6. Packaging & updating is not really an issue: Updates in general should happen when someone NEEDS new features. If you want this to happen blazingly fast, we can serve the tool from a separate online server (which is always up to date), which communicates with the localhost (or any configured) address.
  7. The desktop environment is not really an issue. We now have service workers, good support for browser local storage and a variety of other APIs we can use on the browser (from file system to gyroscope access).

For sure, we will have a python service ontop of pyuavcan. We have to look into potential auto-generated cli from the endpoints, so this part gets automated (like many CLIs do – ex. Google APIs do this generation thing all the time)

Also: Use swagger for the rest api documentation

(Pavel Kirienko) #42

Here is an example of what degree of functional flexibility the panel framework should be capable of:

VESC is an open source ESC project which supports UAVCAN v0 since recently (based on libcanard). They made their own GUI tool which supports various protocols, including UAVCAN. Ideally, their developers should have been able to take Yukon and write a plugin on top of it as described by Scott instead of building their own UAVCAN GUI (support for other protocols would be outside of the scope of the plugin, of course).

(Pavel Kirienko) #43

Here is another first-class use case which must be supported well:

In the video, a simple script (linked from the description) emits a particular ESC setpoint pattern, and the plotting engine collects and visualizes the data in real time. The data can be exported into CSV, too. Tagging @Zarkopafilis.

(Theodoros Ntakouris) #44

I will keep the plotter thing in mind, till the next feature which would probably be the plotter.

Regarding the panels, I’m unsure of what approach we need to take here. I can, for example, add a their party plugin section, which essentially scans some directory and adds this to the Vue’s router or the navbar. I don’t want to force everybody to use vue, so the second option could be preferable. The API is fully documented, thus, they can use it and even ship their own standalone UI or whatever.

Again, Keep in mind that multiple independent browser windows can exist, each with their separate state and lifecycle.

I will do some research for third party components and possible dynamic dsdl based UI generation.

(Pavel Kirienko) #45

Great. I am moving as fast as I can on my end to come up with a minimal working version of PyUAVCAN.

This should help: https://github.com/UAVCAN/pydsdl

(Theodoros Ntakouris) #46

There is no need to speedrun pyuavcan if that can backfire in the future (in terms of untested code / bac quality). Yukon can progress to a large extent with mock data, I’m even making the python stubs. Also, take in account that we are actively reworking the UI in parallel.

I don’t know if you guys have agreed on a strict deadline for v1.0 though.

Thank you for the resources.

(Scott Dixon) #47

wow. That video is truly terrifying.

(Scott Dixon) #48

I’m very interested in the extensibility of this UI. A primary use case for me is to support manufacturers shipping extensions to the UI with their DSDL definitions (e.g. Zubax can publish Myxa dsdl types and also provides a UI extension that lets you work directly with their ESC).

My original idea was to keep the Yukon UI in a single window for simplicity and because nobody really likes switching between a bunch of windows. I’m wondering if UI extensions are an exception to this rule to take advantage of the process separation between tabs/windows in browsers like Chrome?

(Luc Patiny) #49

Hello. I’m currently working on a javascript only implementation of uavcan protocol and sl-can as a webservice that will allow to monitor the bus from any webbrowser (using websocket).
This is still a very early stage but currently we are able to serialize and parse the data and I guess in once month it will look more finished but here is a small screen snapshot of the current state:

The project is here and have 2 dependencies

(Luc Patiny) #50

I’m working on the UAVCAN scanner that will allow to have a webbrowser that connects to a websocket and interract with the CAN bus.

In order to test I have a packet generator and you may see the result on


There are 3 tabs:

  • global overview with all the nodes that announce them self at least 1/s
  • packet view (you may click on a line for detailed information)
  • data view (you may also click on a line)

The first page is at least mobile friendly the goal being that in can work with RPi and the touch screen.

If you want to contribute just contact. You may also suggest the main information you would like to see on the home screen.

(Pavel Kirienko) #51

This is awesome, thanks @lpatiny. I am wondering if it is possible to join our efforts on Yukon? We are discussing things as we go in this thread, the work is led by @Zarkopafilis: Yukon UI & Rest API