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
record and playback commands sent by the GUI and status of properties. For easier debugging.
highlight recent changes to the configuration
show timestamp at which displayed data was retrieved
set which variables are sent to the PC, and at which rate
some kind of integrated command window, so you can send commands from the GUI in python if necessary
save and load GUI settings, so you can reopen the same GUI state (graphs). Not necessarily the data displayed, but at least the same variables/axis/graphs displayed.
an actual log of the bits/bytes/hex sent out and received. Helps debugging if it isn’t connecting properly, or when testing custom firmware.
loading configuration from the board, and not hardcoded into the UI. You were probably planning on doing this anyway.
definitely native desktop.
ability to send commands over ST-LINK in addition to USB? (I fried the USB port on the ODrive, but the board functions nicely otherwise)
Server-Client could be cool, but then it would be nice to have a very clear e-stop/UI button.
Add buttons that run custom scripts. So users can automate tasks for their use-case.
I think the app needs to make use of the existing failsafe “watchdog” command which informs the ODrive that it will be sending commands at least once every 100ms and if it doesn’t, then stop. That way the software can have a fairly reliable BRB (Big Red Button) in the top left corner of the screen, which the user can click on or hit ESC on their keyboard if their robot is “vibrating itself to death”.
Not sure about working via ST-Link - sounds like scope creep to me.
CAN on the other hand…
Scripting is definitely good, but not sure what a GUI would provide that python/odrivetool doesn’t already?
As for the app framework:
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.
Garrett:
I got your email a few days ago and tried to reply yesterday. It bounced, not too surprising when I looked at the return address.
What is the good way to communicate with you, Towen and the group?
I have a start on a gui interface for odrivetool. It’s taking more time than I thought to remember how to make pyqt work. I have been out of it for 3+ years though, so not too surprising. I should have a start that will work for a the initial tasks in another day or three. Nothing that is even sort of ready for anyone but fellow devs. How do I share it with you?
The email I tried to send –
From: James Hurlburt hurlburtjl@gmail.com
To: Claude Garrett via ODrive Community noreply@discourse.odriverobotics.com
Cc:
Bcc:
Date: Sat, 18 Jul 2020 12:52:16 -0700
Subject: Re: [ODrive Community] Calling all UI/UX experts
Sorry for not getting back to you sooner. Things got busy.
I will see if I can knock something together today and tomorrow.
Just a start of a front end for odrivetool.
How do I contact Towen?
What is the process of getting github permission to upload the work I do?
Might I suggest linuxcnc on a pi4.
I have one running headless beside me and can connect to it with vnc from linix. I’m sure there are ways to do the same from windows or mac.
Hi! Any updates (progress) on your plans for making an ODrive GUI?
Have you seen this ODrive UI (see below)? It seems pretty cool and functional already? Maybe you could partner with its creator (tinker_inc) or use its code?
But that’s probably more a finding a problem for a solution lol.