Hello!
We are in the early stages of developing a GUI for ODrive. We want to know what types of features you want out of a graphical ODrive tool. Right now, everything is on the table. Native desktop application, web app, server-client to connect to an ODrive on a different computer - you name it.
What do you want out of the ODrive GUI?
Exporting all settings to a JSON file and re-importing them later. Either for backup purposes or troubleshooting (send me your settings) or maybe some settings can only be changed that way (like advanced settings)
Hi
These are just the things i was thinking about right away, may leave another message later.
Good luck with it
Cheers
Carelsbergh Stijn
If you used something like Flutter it could be built for Linux and Windows, with the option to add Android and Web-app later if desired. There are other proprietary build options available also, like some apple stuff. But all that on the same codebase without building your app multiple times.
Can I ask if there’s a specific reason as to why JSON, as opposed to, say, XML or even binary? Just curious if I’m missing something.
JSON makes smaller files for the same amount of data, and its structure is more defined (no attributes or comments, only elements and data) which prevents bad practices from encroaching the data structure down the road. It’s also platform-independent like XML but it’s better suited for data and settings.
JSON is a better data exchange format. XML is a better document exchange format.
Ah, makes sense. I never looked at it from a size perspective.
To me, the lack of attributes especially but also lack of code comments is what mostly makes it better.
The smaller size is an additional bonus in my opinion.
It really enforces best practices by its very nature.
I’m assuming JSON over binary because you want to be able to open the settings file, outside of the application, for modification?
That’s one reason, yes.
Fair enough. I was just curious.
I don’t think a web app would be particularly useful (?). Server/client maybe, for those who don’t have the luxury of ssh -X
I would love some system identification & controller tuning tools. Nyquist/Bode plots? I/O mapping, etc. The ability to plot any signal in the ODrive on a graph at reasonably high sample rates. (although plotting high sample rates will probably need signal recorder functionality in the firmware)
I think it should stick to Python implementation, using either PyQT or tkinter. There should be a minimal amount of duplication between the GUI and odrivetool - i.e. the UI elements should make use of the commands in the background.
For Windows/Mac deployment, a Pipfile might be useful? (so the only thing you need to install is Python)
For the real Windows noobs, the installer could download and install Python automatically if it’s not installed.
It should also incorporate a basic terminal with odrivetool functionality. There are some well-known brands of industrial servo controller that have a very rich GUI, but also have a fully featured command line interface which is always available in the bottom left corner.
I’m not sure about the -X switch, but, you can ssh in windows; you just have to use powershell and not cmd. Powersell is much better anyway, and it’s the closest you’ll get to linux next to installing an ubuntu instance. Speaking of, that could potentially be utilized.
My only problem with python is it’s problem with threading. From my understanding, it can’t, really. If we’re looking at getting data as fast as possible with an ever updating UI, multi-threading may need to be in the conversation. Otherwise, I agree completely.
Agreed… Although there’s not a huge amopunt of CPU heavy processing to be done, is there? Apart from running on one CPU, python threads work fine for handling things like blocking I/O.
You could always have two separate processes attached with a socket. You could even add a remote socket command to odrivetool and then connect to it with a program written Python or a completely different language.
-X allows you to run an X11 (ie graphical) application on the remote computer using your local X server (ie your display). It works only of you have an X server. It’s useful for example for me running my CAN GUI on my raspberry pi which doesn’t have a display - I can have it use my local display with ssh -X.
There are X server implementations for Windows such as Cygwin/X, but this would be too complicated for the average user. I was having a poke at Windows again. 
I have no idea what powershell does, but I expect there is no microsoft X server for Windows.
I was thinking more about interrupts or Windows doing how it does with process prioritization. Meaning, instead of commands stacking, the process could essentially be expedited. I get lost in whole big O computation though, so, that might not even be viable.
That sounds pretty awesome! But why not VNC? I haven’t used it yet, so I don’t really know how it works, but from my understanding, it is basically what you described with server X. On another note, I really need to get a raspberry pi 
Oh man. A gross over-statement would be that it is a shell, for Windows. It runs on the .NET Framework, but, there’s also Powershell Core that runs on .NET Core, which can be run on linux. If you’re familiar with .NET and an administrator, it’s a god-send compared to CMD. I’ll take writing a powershell script or module over a batch file any day. Check it out, if anything, it may cause you to like Windows just a bit more than you do now. Oh, they also incorporated (most, if not all) usual shell commands like mkdir, rmdir, ls, etc. by alias, or you can use the long hand New-Item, Remove-Item, Get-ChildItem, respectively. Pretty simple to use and easy to learn. The trick is, like learning how to use the man pages, you have to learn how to use Get-Help.
I think I get what you mean, you want to improve the communication speed of the ODrive by processing multiple commands at once. This would still be possible with normal Python threads.
Sadly though, there is only one USB bus to the ODrive, so commands can’t be stacked with threads. However there are some plans (I think) to allow more than one command per USB message, which does speed it up a lot.
Because VNC sends a whole desktop. ssh -X just sends a single application at a time, without needing a screen, an X server or even a graphics card on the remote machine. In fact on Linux, the entire desktop is rendered over a network socket. All programs, like Chromium/etc have to connect to that socket in order to draw a window on the screen. ssh -X simply redirects that network socket to the local host of the SSH client.
I think i’ll stick with BASH on Konsole. 
In Windows, I’m normally using minTTY or WSL anyway.
If you wanted to be reeeeeally technical, there’s the option of a DB9 port and the 8 GPIO pins 
But that’s probably more a finding a problem for a solution lol.
Ooooh, ok. That makes sense. Interesting.
Fair enough. I like to try and know as much as I can about both. I like being able to get on either computer and be comfortable to do advanced task. That way it doesn’t matter what a client is running, I can at least figure out what’s going on. I’ve found a lot of time the client doesn’t know what they have and getting there and going, ‘ah, yea, I’m a Windows admin/developer’ when they would have a linux box going made me feel so unprofessional
The ability to:
I would love to see mainly the same as Riewert and the following if possible: -