I prepared functions that generate windows. Functions get a button and properties gets a label, unless the parent of item is config then it gets appropriate spinbox or radiobutton accordingly if it’s a float or a bool etc.
There are still a bunch of exceptions needed like buttons to control machine states or that like firmware version is a single label instead of split between minor, major. etc
Tonight I am planning of making settings window, so when generating config items it would use values from settings.
Also, since retrieved values from the remote object are in a dictionary, they are not sorted so every single time the layout is random. Have to include some functions to reorganize the view.
Hello,
a small update.
I have setup settings window for various preferences, including slider settings etc. But since the app was all dynamic just managing how to store and transfer data between all the settings, and sliders and current values and finding object paths to write settings to the board, I had to rewrite some code so it took me a while.
Another thing was that it was generating sliders for all integers and all floats and obviously for motor modes or directions etc. we don’t need sliders so it I had to figure out where is the best way to filter out these conditions. So it’s taking me a while. But there is progress.
And now I am going for two week holiday, I was really hoping to have it functional before this time. But oh well I wasn’t allowed to bring odrive board with me.
Anyways, I am just noting that I have not forgotten about this project, there is work in progress and few delays.
Thanks!
One excellent point of comparison is vesc_tool for configuring VESC board.
I encourage you in particular to review its excellent motor confg wizard: a must have!
I can donate one odrive 3.2 for you to have fun during holidays if you’re willing to give such a wizard a try
(mmmm if it’s your wife/husband who forbid it, it may not be a good idea )
Thank you this is great, I found one bug. It doesn’t allow me to set a negative speed for encoder index search speed, which is usually used in case you want to search for index in the opposite direction.
Thanks, previously spin boxes were set to have minimum value of 0.
Negative values were added. Let me know if all works out I am still away, can’t test it out.
Thanks
I am also using Windows 10 and use Anaconda Prompt IDE.
Even I followed the steps using @Isaac_Ben’s advice. But I am currently facing a problem in running the tool i.e. step 5.
Can you please guide me?
Sorry for kinda abandoning this work for now, but I myself stuck on building a machine and decided to use stepper motors to start and odrive will come as an upgrade. Therefore this UI tool is also postponed.
So, as far for changes between firmware versions the easiest would be just to yourself manually comment out the fields that don’t exist anymore. Because they are manually written down and if any naming changes there gonna be errors.
In a future version that I had started to prototype, I made so it scans for all possible options and configs and then depending on specifications it creates the config fields.
@P_V Since I am not using windows it would be hard to help for me. Since I am not aware of how python is on those environments. If the errors you are getting is because of libraries well then it’s probably windows specific so I can’t really help. If the error is about some variables from the program then you can post the results and maybe we can see what’s the problem.
@tinker_inc For opening the odrive tool, in the anaconda prompt, I write:
odrivetool
(base) C:\Users\PK>odrivetool
ODrive control utility v0.4.9
Please connect your ODrive.
You can also type help() or quit().
In [1]:
When I write odrivetool_UI.py, this is the result:
(base) C:\Users\PK>odrivetool_UI.py
‘odrivetool_UI.py’ is not recognized as an internal or external command,
operable program or batch file.
I am not so good at python as I am a plc and motion controller guy. From what i recognise, the method of calling the tool is wrong. Could you please advise?
Hi,
This UI is a great project. I now look into expanding it into something that could be accessed remotely. My scenario is that robot I build (and intend to monitor) is away from the python screen. I have mounted an RPI on it with odrivetool and can access it remotely over ssh but that is hard to do any monitoring.
IMHO the way to go could be a demon querying the ODrivie for key parameters (curent, velocity, position, errors) and a small web server on the RPI serving that data in realtime as large readout numbers or gauges or maybe even last 60 seconds plots.
This way I could have it launched it on the phone to real time view parameters.
One thing to note is that some people having issues with USB for long time periods. So, not sure how robust this solution would be.
But if you want only simple monitoring without any controls, then it’s a fairly simple problem. Like you said yourself simple program to query data and then parse it somewhere else. There are so many dashboard servers available. But then this wouldn’t be a PyQt app. Just a webserver.
Is your RPI controlling Odrive? Because I believe only one application can access serial port at the time. So, if one app is controlling odrive I am not sure if you can have another parallel process accessing USB too.
Sorry for late response, but I am interested too in similar solutions. As I want to do monitoring for maintenance purposes. Currently I use smoothieboard for controlling step dir.
The full control of my machine is over RC input (search GardenBot on this forum) and RPI just sits there so I can read the errors over SSH. no control over USB at all. So it can be devoted to dashboard UI. I looked at code and it is a bit to much for my python coding skils to modify that
Another way I was thinking is to make a small deamon on RPI that would just read basic stats and errors and beam them with MQTT in to the network.
Then I can pickup and archive them with any system.
I have full setup of Openhab with Habpanel dashboards that
can do that. And the bonus would be that I have full archival stat to review afterward.
So, that sounds good. Basically, the app would start one thread to query for odrive and once it found one it would parse the object to the main thread that beams data via mqtt. odrive object is like a dictionary so the easiest would be just to send a json string via mqtt.
couple things to note. Since there you can’t define callbacks (or at least I am not aware of it) with odrivetool, we have to define at what period we want to query messages.
And then what kind of stuff you want to send. Like shall we filter messages to send it only if values has changed from the previous one etc.
It really depends on where you want to filter your stuff. Maybe selecting and sending all axis or odrive data and then on server side you just pick which values you want to store or display on a dashboard.
As I am using ELK stack for my logging of servers. Where putting json formatted data to elastic search would be a simple way and then I filter values I want to pick from it.
I haven’t played with odrive enough to understand which values are worth logging, besides the obvious (errors).
Let me know what you think. Maybe I could write up a small script for it. Do you care if your MQTT has tls?
This exactly would be the flow of the deamon script.
Wait for connection and then a loop for MQTT packet production.
For sure you need to select in the script the parameters that need to be sent.
For me Bus voltage, motor current, velocity is critical . For other uses position as well.
And of course errors when they occur.
To have nice dashboard like dials on receiver I would say that you need 2Hz display.
And I think that getting the data from OD within 500ms is doable even on RPI.
I have experience in sending mqtt messages from the python script with the paho mqtt library.
It is a two liner.
import paho.mqtt.publish as publish
publish.single("ODrive/velocity", value , hostname="ip_of_the_mqttbroker")
Yep, my machine still needs a lot of trouble shooting, if you can get me a simple connection and collections script I can write the mqtt transmiter and reciever part.
I have a javascript port of the odrivetool running in the browser and connecting to the odrive over webusb. Using Pub/Sub with socket.io I can monitor and control state from anywhere. webUI
ok, that is super interesting. But how do I get that working with only remote RPI connected to the OD. Do I need to have Web server running on the RPI serving you JS port?
I wasn’t allowed to bring odrive board with me.
)
