Hi all,
New to this. I bought my first ODrive, but i am not new to robotics.
I am using python IDE to communicate to the ODrive using the USB port (Which is COM29 for reference).
When i want to connect to the board i write:
drive = odrive.find_any()
This take a long time everytime i run the program (as most of you know). I know in the documents it says to write:
drive.odrive.find_any(“serial:/dev/ttyUSB0”)
I am using a windows machine so i tried:
drive = odrive.find_any(“serial:COM29”)
But i get nothing.
So how do i tell it to look for a specific serial port to cut connecting time.
Thanks in advance
Jamil
Hi Jamil
In my experience that annoying lag you seem to be experiencing is not related to the lib having to search/enumerate every possible com port until odrive is found. Instead it is an annoying feature of the default/bundled python USB lib that enumerate over USB the entire firmware attribute/function tree instead of using a local cache. That causes a systematic loss of 10sec each time you run your python script (of that you connect/disconnect the USB cable while using odrivetool). Some user offered a fork to implement precisely this feature (sorry I’ll search for the right post another time).
If you want to do anythin more than a one time configuration, I would really suggest you to simply avoid the USB interface entirely.
Thank you.
Your suggesting i use a TTL to USB interface to connect to the board using GPIO instead of the onboard USB?
If so i got to figure out how to do this.
I’m not so sure i’m the best person to ask advice to regarding what’s the best interface for odrive.
I think it also depends a lot on what you want to do with it how stable/reliable you need the thing to be compared to the level of stress/load/performance you expect.
I would suggest to maybe wait for some other users’ feedback.
What I do know is that I tried streaming position commands through USB with the python lib and I observed hard to reproduce unexpected behavior. (Usb communication issue / AttributeError: 'RemoteObject' object has no attribute 'axis0')
I’m pushing my luck with UART interface (gpio) with an arduino rx/tx pins. I manage to reproduce the normal behavior I had before using python/USB/PC. But only time will tell us if I got rid of instabilities for real. And maybe a lot of this is due to my own ignorance too.
Bottom line is I don’t know if using a PC and USB/ttl will work better than python lib / USB / PC. But you will get rid of the annoying 10sec + you will know how to address a specific com port like any other Serial port related project.
Hello Jamil84,
you can instead try odrive.find_any(serial_number="366333693031")
the serial number is given when its connected with odrivetool as such:
Connected to ODrive 366333693031 as odrv0
This won’t get rid of the 5~10s delay though. If reducing this delay is important, you can try this script by user @marcelrobitaille. I’ve tried it and takes less than 1 sec on my machine.
As for the interface method, many people have successfully used native USB interface, however I have personally had some issues due to motor switching noise. I think uart based approach is more robust in noisier setup (using RS485 converters). I am using ODrive uart with baudrate of 921600 in one project with great success. There is also CAN interface available in a feature branch if you have multiple ODrive boards.
silly question: what is the odrivetool command you used for configuring this?
Beware, the delay caused when connecting to odrivetool is because the configuration of the odrive is being sent over. This takes about 10s per ODrive on my system. The actually detection of the odrive happens almost instantaneously.
The easiest way to remove these 10s, is to cache the configuration from the first connection and assume it hasn’t changed since the odrive was previously connected. This feature is currently not implemented, and as far as I am aware there are no plans to implement it.
alexisdal, you need to change the huart4.Init.BaudRate in usart.c and recompile
thanks. I noticed initial comment from Jelsdon that mentions the
Firmware/Board/v3/Src/usart.c
Line:
huart4.Init.BaudRate = 115200;
However, changing the firmware is something I would rather avoid for now. I guess it’s another encouragement to try out CAN bus 