odrv0.vbus_voltage > ~14.3
odrv0.axis0.motor.config.calibration_current=5
odrv0.axis0.motor.config.pole_pairs=21
odrv0.axis0.motor.config.motor_type=MOTOR_TYPE_HIGH_CURRENT
odrv0.axis0.encoder.config.cpr=8192
odrv0.save_configuration()
odrv0.reboot()
odrv0.axis0.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE (completes left right motion)
Things start to go bad here:
odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL (state change error)
Reboot:
odrv0.axis0.requested_state = AXIS_STATE_ENCODER_OFFSET_CALIBRATION
dump_errors(odrv0): https://discourse.odriverobotics.com/t/motor-failed-current-unstable/3194
Reboot:
odrv0.axis0.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE (completes left right motion)
dump_errors(odrv0): (all good)
odrv0.axis0.encoder.config.use_index=True
odrv0.axis0.requested_state = AXIS_STATE_ENCODER_INDEX_SEARCH
dump_errors(odrv0): https://discourse.odriverobotics.com/t/motor-failed-current-unstable/3194
Reboot:
odrv0.axis0.motor.config.calibration_current=10
odrv0.axis0.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE (completes left right motion)
dump_errors(odrv0): (all good)
odrv0.save_configuration()
odrv0.reboot()
Never reconnected again
DFU link:
Shows up under Zadig as STLink32 bootloader:
odrivetool -v dfu
ODrive control utility v0.4.11
Waiting for ODrive...
STLink flash:
openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init -c "reset halt" -c "flash write_image erase C:\Users\matt\Downloads\ODriveFirmware_v3.6-56V.elf" -c "reset run" -c exit
xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:28)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J17S4 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.263872
Error: init mode failed (unable to connect to the target)
I tried rebooting the computer, tried every usb port, tried multiple usb cables.
In DFU mode the bootloader will connect to usb, but it cannot flash the chip, and run mode will not connect to usb, and STLink will not connect to target.
Update:
I hooked everything up again and it seems the Odrive board can only connect to USB while the STLink is attached. When i attach both the Odrive usb, and the STLink, the odrive usb interface appear in zadig. If i unplug the STLink, the odrive usb interfaces disappear and I can no longer communicate with the board via odrivetool.
It seems as though the board is being powered through STLink?
The good news, with STLink connected, i’m able to connect to the board and I was able to finish calibration by increasing my current_tol. The motor is correctly working in closed loop position control.
However, I cannot use the Odrive unless the STLink is connected? Any ideas?
It seems like we had the same problem. It was not possible to connect or flash the ODrive-Boards via USB until we disconnected them from the main power supply and powered the Boards via STLink instead.
You may have a noisy power supply or a ground loop in that case. Please check with an oscilloscope if you have one. You can also upgrade to a shorter or higher quality USB cable
For a while we could use our board without any problem. But after some time the board showed strange behavior. Sometimes it did not react to new input values at all, sometimes the motors started vibrating. We tried flashing the firmware (0.5.1) again. Now the connectivity issues are back again.
Thank you for your ideas, Wetmelon! We checked the power supply, changed the USB cable and don’t think that we have a ground loop. At the moment it is possible to flash the board in DFU mode but it doesn’t reappear back in RUN mode. Any other suggestions?
It’s ODrive v3.6 56V. And there is another board connected in the same way without any problems.
If the ST-Link is still connected, the board may be held in RESET?
If you have access to a Linux computer e.g. Raspberry Pi, check the output of dmesg -w when you plug the USB in.
If you’re on Windows (God help you) you might need to use some tool (Zadig?) to change USB driver from DFU to libusb-win32.
Thanks towen!
At the moment we are only using the 5V and GND of the STLink.
dmesg -w gives the following output:
[ 400.482657] usb 1-2: new full-speed USB device number 8 using xhci_hcd
[ 400.624800] usb 1-2: New USB device found, idVendor=1209, idProduct=0d32, bcdDevice= 3.00
[ 400.624809] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 400.624814] usb 1-2: Product: ODrive 3.6 CDC Interface
[ 400.624818] usb 1-2: Manufacturer: ODrive Robotics
[ 400.624821] usb 1-2: SerialNumber: 3351314C3536
starting odrivetool in verbose mode gives:
ConfigurationValue 1
InterfaceNumber 0,0
EndpointAddress 130
InterfaceNumber 1,0
EndpointAddress 1
EndpointAddress 129
InterfaceNumber 2,0
EndpointAddress 3
EndpointAddress 131
Kernel Driver was not attached
EndpointAddress for writing 3
EndpointAddress for reading 131
Connecting to device on USB device bus 1 device 9
But even after minutes of waiting nothing happens.
@qwert what version of ODrivetool is this? It’s probable that you have an old version e.g. installed by pip. Maybe it has a bug or is incompatible with the newer firmware?
Can you try uninstalling your odrivetool from however you installed it, and instead run python3 tools/odrivetool
from the Git repository?
You can also try sudo python3 tools/odrivetool udev-setup etc.
Thank you so much for your effort, towen! It seems to finally work now.
After disconnecting the CAN bus cables the board somehow appeared in odrivetool.