Why is my odrive 3.2 not doing its initialisation sequence after a power off->on?

Support
1

Hello,

Just freshly did a git pull on one of my 3.2 odrive boards.

I updated the code to reflect my hardware setup, it compiles and flashes just fine. right after the make flash, the odrive does its initialization sequence (beep), and then the motors slighly turns back and forth (about a quarter of a turn i’d say). then the tools/demo.py does work as intended, the motor turns as expected. But if i power off/on the odrive. nothing works: the initialization sequence is not done at all (no beep, no motor turning), and usb communication does not seem to happen. it’s as if the board was dead. However, if i reflash it => it works again until i power off the odrive.

Any idea what could cause this behavior ?

some details below.

  root@MTBD00694:~/ODriveFirmware/Firmware# git show
  commit be53d965fbc7262a4abb9022b227e4115b554e47
  Merge: a26224f bb9d4f5
  Author: Oskar Weigl <oskar.weigl@gmail.com>
  Date:   Fri Feb 23 17:17:42 2018 -0800

using a turnigy aerodrive SK3 6374 149 and a CUI encoder 490-AMT102-V

I followed the readme instructions

  • changed Inc/main.h to set HW_VERSION_MINOR to 2
  • let the usb values as default (i just want to use tools/demo.py for now)
  • i check the CUI dip swiches, they are all on the down position, which according to documentation refers to 2048 (see page 4 on the data sheet), which is the default value used for ENCODER_CPR
  • i counted the POLE_PAIRS, there are indeed 14 magnets, so the default value in the code (7) does work
  • brake_resistance is 0.47f and i use a CGS HSA50 R47 J 1634 that i beleive originates from the odrive shop (or maybe a mouser reference that i found on the forum)
  • for motor_drive, the default value is ok for my motor i believe

What could be wrong ? could it be related to the code or my hardware setup ?

2

i tried reverted the code back to revision a7b11f8c6db30af55302b8b0343bd9b601579208 (Nov 20th 2017). to no avail. i observe a somehow similar behavior

right after reflashing, the system works more or less (the motors vibrates a lot.). i turn off. then when i turn power on (i use a Rhde & Schwarz NGSM power supply configured on 18V / max 8A), then when i click on “enable power” button, the motor moves for a split second, then the power sypply beeeeeps, and no longer provides power. it seems to be the behavior i have when i short the power supply.

I suspect the mechanical linkage between the motor and the CUI encoder is wrong. I used a 3D printed part for this. @bart used a metallic part (an accessory) of the turningy motor that he turned on a lathe to achieve a 6mm diameter, but since i have no lathe, i printed it. it seems either i did not mount properly the part or it had a printing problem because i can see that it is not perfectly turning “straight”.

see video.

i’ll try to mill this part instead of printing it.

3

In your original case, with the be53d965 firmware, is it also “shorting” the power supply, or is it simply not booting?

4

simply not booting I think. will check on monday. do you need a video ?

5

As far as the firmware is concerned, a proper power cycle and re-flashing is identical. My best guess here is that the power supply doesn’t force the output voltage to zero immediately when you turn it off, but it takes some seconds for the ODrive to discharge the output capacitors. Just to be sure, you can try to leave the power supply off for up to 10s before turning it on again. To be really really sure you can verify with a multimeter or oscilloscope on the ODrive 3.3V pin, how long it takes to go down.

6

thanks. will do the 3.3V on oscilloscope.

7

And make sure the LED / light goes off on the board.

8

V3.2 doesn’t have that LED xP

9

this morning i decided to remove all wires, clean up the table of other pending projects (was a big mess). then rewire everything. and bang it seems to be working ??

i suspect that there was some mix up with power from main supply and power from the USB reflashing tool. because i’m pretty sure i was proving power from both sources. but i struggle to find the right info in the documentation.

let’s consider the issue fixed for now. we’ll see

10

Hehe yeah this is why we added a power LED on v3.3 and onwards, makes it easier to see if the logic of the board is powered.