Calling all UI/UX experts

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?

1 Like

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.


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:

  • Easy to learn, just a handful of HTML tags is necessary to create nicely structured documents.
  • Every text editor can be used to create content. Programming editors add nice features like syntax highlighting and autocompletion.
  • With a little foresight and avoiding “cool” features, pages render perfectly on every device – without change/modification/adaption.
  • Users with disabilities can scale pages up and down if they have sight problems.
  • No libraries like JQuery & Co required. They add an unnecessary (IMHO) layer of complexity with respect to content delivery, and add to the learning curve. Pure JavaScript is easier to read and understand (at least for me…).
  • Sound and media files can easily embedded into the pages (e. g. for advanced help, demos, etc.)
  • Creating collapsible tree structures with very few lines of JavaScript is simple.
  • CSS is engaged to “style” the content. There is the opportunity for “skins” – if that is ever required…
  • No need for a web server to create content: Most browsers can render HTML files directly from the file system (using the file:// protocol). However, for talking to hardware a web server may be necessary. Fortunately, there are a lot of light-weight options available. And if the web server is integrated into ODrive (which I strongly vote for), there is no need for a web server on the developer’s machine. There are web server examples for Arduino/ESP32 with very few lines of code.
  • Graphic libraries for rendering graphical content are available: Wikiipedia.

Oh, another point:

  • I’d like to join this project…!

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:

  • Integrated GCode interpreter (GRBL?). Removes the requirement for a real-time control host.
  • More axes (one can never have enough, sooner or later…)
  • No power drivers on the controller board. That should be separate, external units, for reasons of scalability. Of course, that means a set of different PCBs. I have KiCad…

How can I help?

Best regards


Serv{u|o}s to you, too! :slight_smile:

Clearly you’ve never used Python :wink:
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” :slight_smile:

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!


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.



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

  • Connect Feature. Possibly a modular connect function that would be able to handle multiple odrives
  • Calibration Feature. Used for setting up calibration modes
  • Run Modes.
  • Logs
  • Plots
  • Encoder Settings
  • General Settings
  • Main Display (Start, stop, position to, acceleration, etc)

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


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.

:arrow_up: so much this.

1 Like

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.

1 Like

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.


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
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.


Eclipse without Eclipse? I love it :joy:
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)

1 Like

…and Oracle

Who wants to use something that means you might get sued years later.

With all due respect, f that

1 Like

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


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.