We are in the early stages of making a graphical ODrive tool. We would like to hear from the resident UI/UX people about their experience with different frameworks/toolsets/languages etc.
With the requirements that the tool is multi-platform, connects to an ODrive over USB, supports graphical configuration, plots real-time data - what are your recommendations? What are the development ergonomics like for your language and framework of choice?
I would look into the Flutter framework.
Well, first thing to consider is the conflict of multi-platform and real-time. Real-time in the Windows world roughly translates to, ācheck on it as you can while itās activeā lol. But, on a serious note, there are a lot of ways to go about it. .NET Core and Python are the only two that I know of that are still supported to do a multi-platform app. Serial communication is pretty straight forward in each (Iāve attached a simple YouTube link for a video I did with C#, Arduino, and a relay board, here (keep in mind this video was from early 2018 when I had only been coding for about a year with no work experience)).
As for the development practices, with C# it really depends on what youāre developing. A console app would typically use the standard OOP (Object Oriented Programming) with a TDD (Test Driven Design) approach. This also carries over well into Python. With GUIās, however, The MVC (Model-View-Controller) or MVVM (Model-View-ViewModel) conventions are mostly used. These still follow OOP principles, but, are a bit more complex to explain in a forum thread.
As mentioned in other threads, PyQT.
It follows the MVC convention and is easy to program in Python.
Flutter looks awfully Googly. Are we looking to develop an app across desktop, web and mobile? (and suffering lowest-common-denominator issues therein)
If not, then Iād suggest itās a bit of a sledgehammer for the proverbial nut.
Serv{u|o}s!
Over the course of time, after using and writing all sorts of software in Pascal, C, C++, C+, Assembler, Visual Basic, ā¦, I switched to pure HTML + CSS + JavaScript for nearly everything. I would recommend it for the following reasons:
Oh, another point:
Of course, thereās a very selfish reason: Right now Iām choosing the drives for my least-cost CNC tube based router. Steppers & GRBL were my first choice ā until I saw BLDCs in actionā¦
What I would like to see in this project:
How can I help?
Best regards
Ulrich
Serv{u|o}s to you, too! 
Clearly youāve never used Python 
seriously though, where hardware is involved, JavaScript tends to fall down. But a websocket API from the python odrivetool code (or directly via CDC Ethernet as you suggest) could solve that.
Not on Mobile they canāt. Thanks, Google!
Interesting. I have rarely seen a rich javascript app work well in the absence of a webserver. (I have seen one, i wrote it. but it was a pain to get it to run locally)
I like the idea of a webserver embedded on the ODrive though. Potentially, it could make the USB comms more efficient, using CDC Ethernet instead of CDC ACM. But it would be tricky to get all the web assets into the limited flash space. The current STM32F405 chip only has 1MB flash (of which 1/4 is used up by the firmware). Memory could also be an issue. Unless they upgraded the chip. (ESP32 cheats, because it has about 8MB of proprietary encrypted/obfuscated ROM, containing a black-box network stack, proprietary operating system and God-knows what else - you never get access to the ābare metalā chip - or if you do, it becomes useless)
You also have the issue of network configuration on the userās end. I donāt like devices that use embedded DHCP servers to try to reconfigure my network settingsā¦
Whatās a tube-based router?
Think very carefully about this: How would you define the interface between the two boards?
Would the gate driver be on the āpowerā board? What if you needed to change gate drivers later on?
What if you wanted to change to 1200V IGBTs so you needed a completely different type of gate drive? SiC? GaN? They could need completely different switching schemes.
No, personally I think the microcontroller is in the right place, at the business end.
What Iād actually do, is make a āco-ordinatorā board which interfaces to all of the ODrives via CAN bus. This board could have a high-end microcontroller with an embedded web server, GRBL interpreter and whatever else you like in it, and handles multi-axis co-ordinated moves by sending CAN messages to the drives. CAN-FD would be even better.
How did you knowā¦? (but I used the Python console of Freecad. And Iām reading a Python book to leverage Python in Freecad. I have some experience with Perl and PHP, also interpreted languages. What intrigued me instantly with JS was the fact that the interpreter and debugging tools are built into browsers (not sure about Lynx), so no installation required. Speed is OK, but certainly not suitable for number crunching.
Works well for me on Windows Mobile and Android 7 Phone Edge. Changed the font scaling factor in the accessibility settings. But there are web designers who āmanagedā to find ways to make their pages ignore thatā¦
This is what I meant:
Bassmati on Freecad
The entire page content, including images and videos, can be authored and viewd offline. Only when it comes to some āactiveā content (XMLHTTPRequest to retrieve content modules such as the table of contents), a small web server is required because the file:// protocol is considered insecure in most modern browsers. I use NodeJS for that purpose. Works well for me.
I never tried a web server behind a USB cable, but TCP/IP over Ethernet certainly works.
Right. Some sort of mass storage is required, for example an SD card slot or an external serial EEPROM. Clearly not suitable for an axis driver module, but makes sense on the front end (motion planner e. g.). This implies a more modular design or an all-in-one solution.
Agreed. I suggest giving it a static IP address during initial configuration via USB or RS232. At least that should work.
My interpretation of the MPCNC (Mostly Printed CNC) project. Mine could be called āMostly Bolted CNCā
Apologize for my sloppyness. What I meant is an (ODrive) MCU for a single or few axes, with power drivers (MOSFETS, bipolars, whatever) on on end, focusing on the low level stuff and keeping the high frequency control lines short and shielded, and the front end MCU (PDC(?), motion planner, GRBL interpreter, whatever) on the other. Some sort of interface like a bus in between. Somethink like ODrive torn into two separate (and thus more scalable and flexible) parts.
Thatās what I meant! Would be nice to find a widely accepted and easy-to-use standard for that purpose. But I think Iām drifting off-topic way too much. Thereās an Grbl thread here, perhaps I can revive that.
Have a nice day, and thanks for your kind response!
Ulrich
I would also like to throw out some ideas for potential future proofing as well as add-ons or plugins.
I would hate for a language to be chosen specifically with open source libraries that potentially could have an end of life scenario or lack of updates that would bottle-neck future development of a UI.
In a lot of the development I have done so far, I have been using OpenCV. I know that their are wrappers for many languages, but if the UI tool was built with C++, Python, or Javascript (All languages the developers directly support), that would be ideal.
Personally, I agree with BassMati. Most of my fun projects were initially done with Visual Basic/C++/Python, but now most of my projects are Javascript/Typescript driven. Setting up an opensource Angular App would be a great developing platform that could meet all of the requirements for āRealtimeā data transfer as well as cross platform as it runs in a browser.
Also, most of the UI/Serial/Graphing libraries that I use (Material, d3, etc) are driven by huge companies so the libraries stay up to date.
My setup is usually a MEAN (MongoDB (mongoose), Express, Angular, and NodeJS. This would probably be overkill as I donāt think you would need a backend.
I would also think that having it setup locally on the user machine vs actually being hosted (ie, inventables xcarve software) would work just as well.
VSCode is the IDE of choice.
I can answer most questions if anyone has any.
wayneStock
In order to choose an architecture/language/tools, we should first think about what to achieve with a GUI. Otherwise we could have built a pink tank for buying rolls for the sunday breakfast from the bakery around the next cornerā¦
Some extremely basic functionality I would like to see from the UI.
Debugger is a must. Having a printout/echo function of all commands/responses/errors would make not only testing easier, but also helping from this forum easier
Since the website kind of does this already, and I am not always a fan of this, but a setup wizard would be pretty nice to lessen the burden of anyone not familiar with the current odrive python commands. The setup wizard could build upon mode type, encoder type, motor type, number of odrives, etc. Settings could be changed later, but would be a good start.
The main UI layout could obviously look like anything, but I am a fan of tab views for each of the major features of a program with major elements never being hidden (ie. odrive connections, status, etc.)
The following I think are good features to have on different tabs
The creator of the vesc does something similar. Now I am not a big fan of the vesc, but the interface and amount of options available to setup a motor with the program is pretty nice. The developer used Qt, Qt Quick (QML) and C++ for almost the entire thing.
Again, these are just my two cents, feelings wonāt be hurt if they are all shit ha
wayneStock
I appreciate everyoneās comments!
One of the key goals for the ODrive GUI is ease of use. It should be possible to connect a motor and encoder to an ODrive, connect the ODrive to a computer, and get everything running with a minimum number of clicks/instructions/package installations. Judging by the projects here and elsewhere that use ODrives, the community is skewed towards the technical side. However, a user shouldnāt have to know python/motor theory/whatever to get their system up and running. Sometimes the destination is more important than the journey! Obviously the GUI will support power-users, too, but there is a target for ease of use.
The GUI could be written in just about any language and toolkit, but itās a safe bet that anyone with a computer will have a functioning internet browser. Web apps, local or hosted, are also easy to package and distribute these days and generally donāt have hard dependencies on runtimes (besides a browser).
With that in mind, the web-tech route looks pretty good. I donāt think the GUI will become a huge software project, but Python can quickly get out of hand without real diligence during development. The web framework route has the benefit of similar expressiveness and good component-based structure. C# and C++ have the drawbacks of being more verbose and requiring either a toolkit (Qt/Wx/Gtk) or runtime (.NET) to be distributed. At this stage I would prefer to avoid those types of dependencies. Another benefit of a client-server approach is that the frontend could interface with a server anywhere on a local network. One use case for this is a robot using a RPi or Jetson to communicate with multiple ODrives. Not a hard requirement right now, but the flexibility is nice.
With respect to the scope: the plan for ODrive hardware is to be a motor driver and not a full featured motion controller. I think the GUI should also have a similar scope. Enough user inputs to test out a configuration and log/plot data (testing a mechanism, robot joint, etc), but not a g-code interpreter or machine controller. Those are useful for systems, but there are existing tools and products to handle those tasks.
The interface for VESC is also the most user-unfriendly thing I have ever used.
I think we should strive for it to be as opposite of that as possible.
so much this.
Perhaps, but as it currently stands ODrive is an extremely good teaching tool for both of those things. I wouldnāt want that to be lost if it moves to a graphical tool that hand-holds users too much.
I guess when I said that, I really meant the setup wizard and the amount of options you can change with it. I agree that the usability is not the greatest.
I couldnāt agree more. I do agree that anyone should be able to load this up and get a motor running in no time; however, a good mix of beginner and advanced features built in as standard options would accomplish more for the community as whole.
wayneStock
@PJohnson
If youāre considering a web app, my recommendation would be to build the app around the Theia IDE framework, which is an open source, extensible browser IDE framework based on VS Code (see theia-ide.org).
The app you develop based on Theia obviously wonāt be an IDE, just a series of widgets (e.g. setup, tuning, I/O monitor, parameter setting, plotting etc.) that take advantage of the flexible window layout and stock widgets offered by the framework.
The Theia framework is highly modular with well-defined interfaces which streamlines development - i.e. separate widgets/components can be developed separately with ease. I think this modularity will save the ODrive team a lot of time, not only during initial development, but also when maintaining and adding new features to the app.
Theia is a very active project run by the Eclipse Foundation, with a large community, and so naturally support is quite good.
Theia also supports building to Electron if thatās of any interest to the ODrive team.
A really cool additional benefit of this is that the user would be able to install the app on their Linux-based robot controller (an RPi for example, which would presumably be mounted on their robot), and then access the app from their laptopās browser over WiFi, which I think is a bit cleaner than having to remote into the Pi.
Sorry for the late comment - I hope itās not too late to consider this as an option.
Cheers,
David
Eclipse without Eclipse? I love it 
Because the worst thing about eclipse is Eclipse. And Java.
I think there could still be a (very lightweight) version served directly from the ODrive though (obviously with a link to the full app, Theia-based or otherwise)
ā¦and Oracle
Who wants to use something that means you might get sued years later.
With all due respect, f that
I have worked extensively in python and pyqt. It wouldnāt be a large job to make a gui that would do all that odrivetool does and would be extensible.
I have been out of the loop for a couple of years, but while I was working, python/pyqt was cross platform for linux, windows and mac.
I would vote that the goal should be to duplicate with minor enhancements the capabilities of odrivetool with live_plotter built into it.
No small concern would be to limit the goals for the first iteration and keep the feature set as small as possible to start.
I worked for 20+ years at a window manufacturing plant, and the two of the major things I learned was to make sure that the code was readable and understandable when I came back to it in a few months or years, and that something that worked pretty good real soon was much better than trying for perfect in a few weeks or months. Also to keep changes small and release often. If it could be done, to break upgrades into small pieces. Fix or add this item. Turn it over to the working crew. Monitor and fix as needed. Then start on the next small bit. (Usually quite a bit of overlap between monitoring and fixing the previous change and working on the next change)
I work in linux and have windows 10 available. If python/pyqt would suit the gang I am willing to put some serious effort into the project.
Jim Hurlburt
Bend, OR
hurlburtjl@gmail.com
2:1 - Iāll start learning pyqt in that case. My Discord ID is FoX#0166 if you and/or Towen would like to link up anytime. Not to isolate anyone else, by all means, feel free; Iām just directing that to the other python (or C#) devs in particular.