How should I fix this? Should I actually be selecting startup_sensorless_control?
Also, since this hasn’t been working (I’ve tried using startup_sensorless_control then followed the documentation to no avail) I also considered using the sensors. These have a 6 pin output, and I was wondering if the odd one out - since the documentation only mentions 5 pin sensors - would just not be connected?. I believe the last one is for temperature, though I’m not sure. The wire colors are: Black-Yellow-Green-Blue-White-Red
I think you need to update the firmware. enable_sensorless_mode was a relatively recent addition. That would also explain the unknown error code.
I’d also advise to re-create your config from scratch (call odrv0.erase_configuration() after the upgrade) - you can always take a backup first i.e. odrivetool backup-config my-config.json but there have been some bugs migrating config from old firmware versions, and it’s easier to set it up from defaults.
I’ve recreated my config numerous times now (didn’t know you could migrate a config whoops) and for some reason I don’t have the authorization to update the firmware for some reason. I’ve tried adding sudo to the firmware updating command, as well as flipping the switch on the board to DFU, power cycling, and trying again to no avail. I have also tried using the other phase ports(?) on the ODrive (m1 instead of m0).
Will do. I’ve run the command but I’m waiting for it to finish now. It’s been stuck like this for a little while now (just like in some of the previous instances of me trying to update the firmware):
Still stuck on this for ungodly amounts of time so I cancelled it. However this time around I also flipped the DFU switch after waiting a while – no change there.
It doesn’t seem like I’m the only one that has had this issue. In addition to some of the other posts on here (iirc not all of them had been resolved, or at least there was not update to the threads), someone else I know is also have the exact same issues. Is this not a one-off case?
Ok, so it’s not setting DFU mode correctly, which is odd.
Can you check “sudo dmesg -w” and plug in the ODrive in DFU mode and verify that it connects as “STMicroelectronics STM32 DFU Bootloader” or similar?
It should do the same when calling odrv0.enter_dfu_mode() (which is the function that the odrivetool dfu script calls)
fyi, Flipping the DFU switch while the ODrive is powered will do nothing. You need to flip it and then power-cycle the ODrive for it to boot into DFU mode.
So on the documentation here, there are instructions to update the firmware with a different DFU utility:
sudo apt install dfu-util
The documentation also notes that other’s have had issues using the Python DFU tool.
After running this and going through the firmware update process again:
odrivetool dfu
The ODrive was FINALLY able to update the firmware – no ST-Link needed.
**Note: I did put the ODrive tool in DFU mode by flipping the physical switch on the board itself while it had power, then unplugged it from the computer, took away power, plugged it back in, then plugged the ODrive back into the computer before doing the aforementioned steps to update the firmware.
Following the calibration then then unsensored setup processes, the motor moves now.
