# Yukon Take Three **URL:** \ **Category:** Yukon\ **Created:** [March 2, 2021, 2:47am UTC](https://forum.opencyphal.org/t/yukon-take-three/1139 "2021-03-02T02:47:17Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [March 2, 2021, 2:47am UTC](https://forum.opencyphal.org/t/yukon-take-three/1139/1 "2021-03-02T02:47:17Z")
A few months back I said that I am _slowly working on a Yukon-related proposal_. A [recent post](https://github.com/UAVCAN/yukon/issues/14#issuecomment-785655158) by @bbworld1 on GitHub made me realize that I better make my šŸŒ work slightly more visible to enable collaboration. Here we go: > At this very moment, there is virtually nothing you could run and poke at (aside from a [silly demo script that doesnā€™t do much interesting](https://github.com/pavel-kirienko/yukon/blob/8269112d5e11d8b49c194bda20a9b908d0ca58ce/test.orc.yaml)), but I am šŸ¢ working on putting all the core blocks in place to make that possible. Once the groundwork around the DCS and the basic networking is finished, it should be easy to distribute the remaining tasks around a larger group of people. For now, I would like people to validate the design proposal and submit architectural criticism. There are no specifics to argue about yet, but they do not appear to be required for a high-level discussion. If the general direction is considered sensible, I would like to tag the current master and merge my work on top of that to continue cowboy-style development upstream. I will continue to focus on the core business logic and the nitty-gritty networking details. While I am focused on that, I would really appreciate help on the following fronts: - The DSDL definitions of Yukon take 10 minutes to compile. This is despite the fact that some of the [messages](https://github.com/pavel-kirienko/yukon/blob/8269112d5e11d8b49c194bda20a9b908d0ca58ce/yukon/dsdl_src/public_unregulated_data_types/org_uavcan_yukon/presentation/PortTypeMap.0.1.uavcan#L7) are [intentionally](https://github.com/pavel-kirienko/yukon/blob/8269112d5e11d8b49c194bda20a9b908d0ca58ce/yukon/dsdl_src/public_unregulated_data_types/org_uavcan_yukon/io/transfer/Payload.1.0.uavcan#L1) truncated to speed up compilation. The reason is this old combinatorial explosion problem in PyDSDL, which I expect to be fixable by replacing the current brute force algorithm (exponential complexity) with something closer to linear: > > > The following benign-looking definition is parsed very quickly (some millisecondā€¦s), but any attempt to determine its bit length set (e.g., using \`@assert \_offset\_ \<...\>\` or to generate code) takes a very, very long time (possibly hours): > > \`\`\`python > uavcan.register.Value.0.1\[\<=10\] b > \`\`\` > > The referenced type \`uavcan.register.Value.0.1\` has a very complex layout (thousands of bit length options), so some delay is expected. However, a delay of more than several seconds is highly undesirable, and anything over ~20 seconds is unacceptable. What makes things worse is that most of the computation is performed in the native context, so the user can't interrupt it with SIGINT/CTRL+C. > > The bit length set computation logic should be reviewed some day, it should be very optimizable. > > The problem does not affect any of the standard definitions. - Build a simple discardable demo based on Dear ImGui (better) or Electron (slightly less interesting) that subscribes to a UAVCAN subject with GUI messages and renders them on screen. When the user clicks an interactive GUI element, the demo should send a UAVCAN service request to the node that published the element. You can use the [new PyUAVCAN tutorial](https://pyuavcan--154.org.readthedocs.build/en/154/pages/demo.html) to bootstrap the UAVCAN side of the demo. The GUI UAVCAN types, as I imagine them, should be built roughly like this: Am I making sense here? Would anybody like to join this effort? Maybe this time we will drive it to some conclusion. FYI @scottdixon @linjieqiang @bbworld1 @dmitry.ramensky ---
**Author:** ![bbworld1](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/bbworld1/32/786_2.png) [@bbworld1](https://forum.opencyphal.org/u/bbworld1)\ **Post date:** [March 2, 2021, 8:06am UTC](https://forum.opencyphal.org/t/yukon-take-three/1139/2 "2021-03-02T08:06:45Z")
Iā€™d be interested in trying out building the demo for the GUI; it seems like a cool project, and the usage of UAVCAN to render UI elements is a very interesting possibility that I havenā€™t really considered before. While I havenā€™t had much experience with Dear ImGui itself, Iā€™ve used somewhat similar frameworks and the API seems intuitive. I will need to brush up a bit on PyUAVCAN; Iā€™m still a little bit of a beginner to using UAVCAN in general, so you might have to bear with a couple of my idiotic questions (apologies ahead of time). Speaking of questions, one major question I had was about the usage of Dear ImGui in this project, combined with a UAVCAN implementation. The library is written in C++; the two open source UAVCAN implementations listed on [uavcan.org](http://uavcan.org) are libcanard (C11, intended for embedded environments) and pyuavcan (libuavcan, the C++ library implementation, seems to still be in progress) - with pyuavcan being recommended for HMI applications such as this. Is it fine to write using libcanard? Should we use [Python bindings for ImGui](https://github.com/swistakm/pyimgui)? ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [March 2, 2021, 9:37am UTC](https://forum.opencyphal.org/t/yukon-take-three/1139/3 "2021-03-02T09:37:23Z")
> [@bbworld1](#): > > s it fine to write using libcanard? Should we use [Python bindings for ImGui](https://github.com/swistakm/pyimgui)? We should use Python. Libcanard has two problems here: 1. it supports only UAVCAN/CAN, whereas for Yukon it makes sense to rely on a more capable transport like UAVCAN/UDP. 2. Life is short, use Python. Perhaps we should sit down and draft up basic requirements for the UAVCAN UI interface? Semi-related, you may want to consider joining our weekly call tomorrow if you prefer to discuss something in real-time: > [@Weekly dev call](https://forum.opencyphal.org/t/weekly-dev-call/173): > > A periodic conference call among the maintainers and developers of OpenCyphal is to take place every Friday at 17:00 UTC at [https://meet.jit.si/OpenCyphal](https://meet.jit.si/OpenCyphal). Wednesday, April 22, 2020 5:00 PM TZ (UTC) Please post your feedback and suggestions here. ---
**Author:** ![bbworld1](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/bbworld1/32/786_2.png) [@bbworld1](https://forum.opencyphal.org/u/bbworld1)\ **Post date:** [March 3, 2021, 9:05am UTC](https://forum.opencyphal.org/t/yukon-take-three/1139/4 "2021-03-03T09:05:29Z")
Thanks for the response; weā€™ll use Python for the GUI then. > [@pavel.kirienko](#): > > 1. Life is short, use Python. Definitely true šŸ™‚ > [@pavel.kirienko](#): > > Perhaps we should sit down and draft up basic requirements for the UAVCAN UI interface? Absolutely. Iā€™d like to ask a few (minor) questions about this at the conference call; after that we might want to start discussing a list of requirements on this forum thread or another thread. As for the conference call itself, thatā€™s at 9AM for me; my classes start at 9:45. However, this shouldnā€™t be a major issue in terms of scheduling - as long as everything that needs to be discussed regarding the UI interface takes place in the first 45 minutes of the call it should be fine. If not, I will just have to drop off the call at 9:45. ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [March 3, 2021, 4:08pm UTC](https://forum.opencyphal.org/t/yukon-take-three/1139/5 "2021-03-03T16:08:11Z")
Iā€™ll just voice my opinion that this rather exasperating project would be best built as a vscode extension such that we avoid spending time re-solving all the problems of GUI toolkit, cross-platform support, packaging, installation, updating, distribution, windowing system integration, configuration, customization, etc, etc, etc. We also allow Yukon features to integrate with the IDE features of vscode such that we can relate debug of code on a ĀµC (see Cortex-Debug extension, for example) with observation of a bus. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [March 3, 2021, 4:36pm UTC](https://forum.opencyphal.org/t/yukon-take-three/1139/6 "2021-03-03T16:36:19Z")
> [@scottdixon](#): > > Iā€™ll just voice my opinion that this rather exasperating project would be best built as a vscode extension such that we avoid spending time re-solving all the problems of GUI toolkit, cross-platform support, packaging, installation, updating, distribution, windowing system integration, configuration, customization, etc, etc, etc. I wouldnā€™t support this because while VSCode does help with GUI and distribution, it is hardly helpful with the underwater part of the iceberg. If the Dear ImGui experiment is a success, we would end up with a pure Python application that can be initially [distributed like Yakut](https://github.com/UAVCAN/yakut#installing), which is: `pip install yukon`. Itā€™s not the most user-friendly solution for an average Windows user but many developers already have Python installed so it should be acceptable for an early stage. Even if we did go the VSCode way, we would still need the backend, so the rest of the story holds. ---
**Author:** ![bbworld1](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/bbworld1/32/786_2.png) [@bbworld1](https://forum.opencyphal.org/u/bbworld1)\ **Post date:** [March 10, 2021, 5:55am UTC](https://forum.opencyphal.org/t/yukon-take-three/1139/7 "2021-03-10T05:55:01Z")
Hey, sorry for the lack of recent updates. Itā€™s been a little busy on my side but I got a chance to sit down and finish the basics of the demo today: ![image](https://forum.opencyphal.org/uploads/default/original/1X/3948838f49d06cbf98ff8fb132f0579661ea67be.png) The Imgui-based UI is capable of rendering a window UI description with buttons and text right now. Other primitive UI elements can be added very easily. Itā€™s more or less implemented the way Pavel suggested; the Button and Text elements each have a uuid and a text attribute, which is unionā€™d into an Element, which is stored in an array inside a UIDescription, published on subject id 420. When a new description is published the UI is automatically updated. The node will be removed from the UI automatically when its heartbeat is lost, although this behavior is easily modifiable. ![image](https://forum.opencyphal.org/uploads/default/original/1X/8c1d0a4cf874b08eb704fb663fa275c9fb473b27.png) UI event callback sending seems to work flawlessly (at least from my admittedly non-rigorous testing). We can use this to update the UI description on events, allowing us to build very robust and dynamic node UIs. After writing a basic UI based on this distributed concept, it seems worthwhile to continue with this idea; the extensibility of the design allows for a lot of exciting possibilities. Code is here: [bbworld / yukon-gui-experiments Ā· GitLab](https://gitlab.com/bbworld1/yukon-gui-experiments)