Homepage GitHub

GUI Tool – Next Generation


(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

https://loradb.org/build/

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