Help !!!
After upgraded my Odrive v3.5 48V to 0.4.11, some error appeared，which shows
"AttributeError: ‘RemoteObject’ object has no attribute ‘ramp_up_time’ "
Hi @Neil_FV ,
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?
Thanks.
Hi,
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?
Thanks for reply!
Looking forward to your next upgrade
python is your command and odrive_UI.py is a file that python will run.
So command should look like (at least on linux)
python3 odrivetool_UI.py
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.
What do you think?
1 Like
Hey,
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.
Nice project.
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")
I never bothered with TLS.
I still did not get closer on properly testing my machine and replacing stepper to odrive.
But maybe this week I can make a small script. Do you still need it? It’s been a while…
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.
TIA
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
1 Like
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?
For a remote, headless RPI setup you will need node.js to run JavaScript instead of the browser. The current node.js odrivetool is CLI just like the python version but adding a web server to access the webUI is pretty straight forward. I’ll wire up something and update the repositories with an example.
Any progress on switching back to odrive? I would love to see the UI get improved 
I just want to say, this project is awesome. Great work on what you have done.
Hi!
Odrivetool UI looks amazing! Thanks! It doen’t seem to work for Odrivetool v 0.5?
Is anything planned to migrating it to v0.5?
Cheers!
Dan
1 Like
Hi,
Thanks for a good feedback. But since Odrive started to work on their official GUI I don’t think there is a point on trying to improve this one.
I haven’t tried official one yet, but I think setting up webserver and accessing it via browser is better than trying to setup python environments etc. and I am sure soon they will have a decent version of it.
My use case was not configuration anymore. I worked on the project with a marine robot so we needed to control it remotely so we had a raspberry pi on the robot as a server and access point with MQTT broker and node-red. I a made this mqtt to odrivetool proxy.
These is not a lot of documentation. But it’s basically when we run the script we put our odrive serial number and rate at which we want to receive data. so if we know how mqtt works it just pushes data to a certain topic and desired rate and we publish commands to other topics.
We did this so we don’t have to do programming for commands we just used node-red flows to do all the logic and communicate with odrive. So if mqtt proxy is of interest I rather elaborate on this one. Maybe should create a separate thread for it. But for GUI official stuff should surpass of what I have made (which is good news).