A few months back I said that I am slowly working on a Yukon-related proposal. A recent post 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), 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 are intentionally 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:
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 to bootstrap the UAVCAN side of the demo. The GUI UAVCAN types, as I imagine them, should be built roughly like this:
A top-level message that contains a unique ID of the element (say, a uint64 hash) and the element itself.
The “element itself” is a union of several options:
@union org_uavcan_yukon.ui.Button.1.0 button org_uavcan_yukon.ui.Spinbox.1.0 spinbox org_uavcan_yukon.ui.Textbox.1.0 textbox org_uavcan_yukon.ui.Texture.1.0 texture # etc...
When the user clicks on an interactive element (like a button) or enters text, the event is reported back to the publisher via a service call along with the unique ID of the affected element and some payload (like entered text). A stateless immediate-mode framework like Dear ImGui is probably a better fit for this task because you can just periodically scan the most recently received GUI objects and render them in a single pass, then start anew on the next iteration.
Am I making sense here? Would anybody like to join this effort? Maybe this time we will drive it to some conclusion.