Noob question here… I’m interested in implementing @Wetmelon’s fork with endstops and limit switches. What is the best way to go about this?
Obviously I’ll have to upload the new firmware to the board, but then is it simply a matter of downloading the new repository and just running Odrivetool from the new folder?
What if I have previously installed via apt-get install on Ubuntu? should I uninstall first?
Thanks
Go through the firmware developer documentation here https://docs.odriverobotics.com/developer-guide
@Wetmelon Hi Thanks for the response. I’ve looked through the documentation… but I’m still unclear about what if I have previously installed the ODrive software via apt-get install on Ubuntu? should I uninstall first?
?
or do I just download the new devel branch from github and run tools/setup.py?
sorry I’m sure this is totally obvious to you but I’m still getting up to speed.
thank you
The installed version of ODrivetool doesn’t affect anything. Just clone the repo and follow the docs for building on Linux
@Wetmelon or anyone!
I downloaded the repository:
git clone https://github.com/Wetmelon/ODrive.git
I had issues with the linux build. specifically with running
sudo apt-get install gcc-arm-embedded
dpkg: error processing archive /var/cache/apt/archives/gcc-arm-embedded_7-2018q2-1~xenial1_amd64.deb (–unpack):
trying to overwrite ‘/usr/bin/arm-none-eabi-gcc-ar’, which is also in package gcc-arm-none-eabi 15:4.9.3+svn231177-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/gcc-arm-embedded_7-2018q2-1~xenial1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
to fix I had to run:
sudo apt remove gdb-arm-none-eabi
sudo apt remove binutils-arm-none-eabi
sudo apt uninstall gcc-arm-none-eabi
then the “make” command would work but odrivetool dfu would not:
thomas@localhost:~/ODrive/tools$ ./odrivetool dfu
ODrive control utility v0.4.0.dev
You need intelhex for this (sudo pip install IntelHex)
so I installed, uninstalled and re-installed intelHex but I keep getting the same error. I tired pip3 and sudo -H but same problem.
ok i think I got the linux dfu tool to work…?
after finally getting intelhex to install for python3:
sudo pip uninstall intelhex
download IntelHex from source:
uncompress archive and cd into intelhex directory
sudo python3 setup.py install
then I realize I was using the dfu tool wrong, because the custom firmware flashing instructions are buried under one of those drop down things in the docs.
the proper command is:
cd ~/ODrive/tools/
sudo ./odrivetool dfu path/to/firmware/file.hex
which in my case after running the “make” command to flash the firmware one must run:
sudo ./odrivetool dfu /home/thomas/ODrive/Firmware/build/ODriveFirmware.hex
but there was still an error thrown at the end, but I can connect to the drive… so assuming the firmware went through?
thomas@localhost:~/ODrive/tools$ sudo ./odrivetool dfu ~/ODrive/Firmware/build/ODriveFirmware.hex
[sudo] password for thomas:
ODrive control utility v0.4.0.dev
Waiting for ODrive…
Found ODrive 206A3396304B (v3.6-24V) with firmware [unknown version] in DFU modeYou are about to flash firmware [unknown version] which is the same version as the firmware on the device ([unknown version]).
Do you want to flash this firmware anyway? [y/N] y
The configuration cannot be backed up because the device is already in DFU mode. The configuration may be lost after updating. Do you want to continue anyway? [Y/n] y
Erasing… done
Flashing… done
Verifying… done
Waiting for the device to reappear…
Traceback (most recent call last):
File “./odrivetool”, line 142, in
File “/home/thomas/ODrive/tools/odrive/dfu.py”, line 454, in launch_dfu
update_device(device, firmware, logger, cancellation_token)
File “/home/thomas/ODrive/tools/odrive/dfu.py”, line 417, in update_device
if do_backup_config:
UnboundLocalError: local variable ‘do_backup_config’ referenced before assignment
Exception ignored in: <bound method Device.del of <DEVICE ID 0483:df11 on Bus 003 Address 018>>
Traceback (most recent call last):
File “/usr/lib/python3/dist-packages/usb/core.py”, line 1029, in del
self._ctx.dispose(self)
File “/usr/lib/python3/dist-packages/usb/core.py”, line 225, in dispose
self.release_all_interfaces(device)
File “/usr/lib/python3/dist-packages/usb/core.py”, line 222, in release_all_interfaces
self.managed_release_interface(device, i)
File “/usr/lib/python3/dist-packages/usb/core.py”, line 159, in managed_release_interface
self.backend.release_interface(self.handle, i)
File “/usr/lib/python3/dist-packages/usb/backend/libusb1.py”, line 751, in release_interface
_check(self.lib.libusb_release_interface(dev_handle.handle, intf))
File “/usr/lib/python3/dist-packages/usb/backend/libusb1.py”, line 552, in _check
raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 19] No such device (it may have been disconnected)
thomas@localhost:~/ODrive/tools$ ./odrivetool
ODrive control utility v0.4.0.dev
UPDATE:
ok YES it did flash the firmware, but NO it is the wrong branch!
I hadn’t downloaded the development tree properly! It’s github’s fault. When you click on the “clone or download” button on this page: https://github.com/Wetmelon/ODrive/tree/Endstops
and if you get the link to clone “https://github.com/Wetmelon/ODrive.git” it is not the right branch.
but if you download the ZIP file it is correct from this page it is correct.
arrg so frustrating. @Wetmelon FYI
When you clone you get the whole repo. Default branch is master, so you have to checkout the Endstops branch:
git clone https://github.com/Wetmelon/ODrive.git
git checkout Endstops
@Wetmelon Does the RazorsEdge include the homing/endstops features or do I have to choose the endstops branch specifically?
It includes the endstops feature branch
@Wetmelon I just downloaded the zip file of the endstops branch and compiled that. seems to be working! I’m a bit of a noob when it comes to github and software dev. I’m more of a builder who knows enough abut code to get myself into some deep rabbit holes. now just need to integrate it with everything.
Are there ascii commands for homing and/or for resetting (after tripping the limit switch)? I didn’t have time on this project to integrate the native python protocol… so just using ascii commands for now. I ship in a couple weeks, but the project dosn’t go live 'till April, so I might have time to explore that option…
No, sorry, you have to use the native protocol or the CAN protocol (RazorsEdge only)
I found a workaround by using a python script to do the homing, which I can call from within the program I am using to control the motors (Touchdesigner) with ASCII protocol.