I’m flashing custom firmware to an odrive (v3.5 48v) over a USB cable from linux (attached raspberry pi zero). This works great, the only issue is that when I finish I’d like to exit DFU mode using the command line. I could use the dip switch, but I don’t have easy access to the odrive board, so a software solution makes the workflow way easier. Also power cycling the board will exit DFU mode, but I’ve got a bunch of other odrives attached to the same power source so it is disruptive to the development workflow to have to power cycle after each firmware for each odrive. I can get the boards into DFU mode via the odrivetool and the enter_dfu_mode() function, but obviously the boards won’t show up in the odrivetool once they are in dfu mode so no way to get out of it. I tried the detach flag for the dfu-util (-e) but it didn’t do the trick :
sudo dfu-util -a 0 -s 0x08000000 -e
OUTPUT :
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Opening DFU capable USB device…
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface…
Setting Alternate Setting #0 …
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
dfu-util: can’t detach
On windows the DfuSeDemo gui has a button for this, but I’m not sure how to do it in linux. Anyone have any ideas?
Hmm. Pretty sure this should happen automatically. It does for me, at least, using the standard python3 Tools/odrivetool dfu Firmware/build/OdriveFirmware.hex
The DIP switch is only checked on boot afaik. You should never “normally” need to use it. Leave it in RUN mode.
Check the source of odrivetool - you may see what it is doing in there.
Thanks towen, that’s way better as it not only enters and exits DFU mode automatically it also saves the config file so you don’t have to repopulate all of the values. I guess I was confused by the documentation and thought that you could only use that for getting the latest release from odrive (not custom firmware) so I was using :
sudo dfu-util -a 0 -s 0x08000000 -D ODriveFirmWare.bin
This also works but leaves the odrive in DFU mode and doesn’t save the config.
I’m adding the ability to use an odrive as a servo over CAN without startup calibration. I’m using an output shaft potentiometer and a pre-offset calibrated absolute motor encoder AS5047 (via SPI). Using a 2 point potentiometer to output shaft angle calibration (stored via config params) I can compute the absolute output shaft angle in degrees. Of course this could be done with just the AS5047 if there wasn’t any reduction, but I’m using a 2 stage belt reducer for a 16:1 reduction. I’ve seen some comments about people doing similar things on some of the other branches, but the code for this isn’t that complex and I also wanted to add some custom CAN messages to control the odrive in degree mode.
Nice I like it! So you’re using an absolute encoder for the motor, and a the pot to find out which “turn” of the gearbox the motor is on? I did exactly that for an industrial manipulator. It was for radioactive environments so a multi-turn encoder was out of the question - we used “resolvers” which are a type of rotary transformer used as an absolute encoder. but that only worked within one turn. My idea was to use a pot at the gearbox output.
I think you can do with without the pots if you set your cpr & pole_pair ratio correctly, then multiply pos_abs by the ratio (so that the absolute reading is on [0, cpr)
The output shaft pot is only used once on startup to compute the motor shaft encoder to output shaft offset. This gives the absolute position of the output shaft without any calibration or homing necessary on startup (and no assumptions like the output shaft wasn’t moved while the odrive was powered down). Unless I’m missing something (highly possible ) I don’t see how what you’re describing can replicate this. If that’s the case please elaborate as I’d love to ditch the potentiometer!
