I am looking to use much smaller motors than the N5065 (or similar). I have gotten somewhat familiar with the oDrive using those but when I try smaller motors it doesn’t seem to work. It won’t even complete what would look to be a normal startup sequence.
The two motors I am trying right now are:
Any ideas? I am guessing it is a setting in the firmware.
Thanks!
P.S. I have a GARTT ML3510 on order since it is on the “approved” list but even that is a bit large for my application.
Yes I think I know what is going on: by default the ODrive can only measure phase resistance up to 100 milli-ohm. To verify, you can use the expore_odrive.py to query the motor error code: motor0.error. You can check the error codes, they are zero-indexed from this enum. Specifically, I suspect that you will be getting error number 3, which is ERROR_PHASE_RESISTANCE_OUT_OF_RANGE.
No worries though, we can indeed change some parameters to make it work, though the steps are different for your two motors.
This has a resistance just a touch over what can be measured by default, and also it has a fairly low current rating. You can change .calibration_current to 5A, and it should give you the ability to measure twice the resistance, while also not stepping over the current rating of your motor during calibration.
Also, since your motor has such a small current range, compared to the 100 or so A that the ODrive is designed for, you may want to increase the current amplifier gains to sense the smaller range. You can do this by setting the gains to 80 V/V in low_level.c:
local_regs->Ctrl_Reg_2.GAIN = DRV8301_ShuntAmpGain_80VpV
So gimbal motors have such high resistance, they need to be run in a different way. You can do this by setting .motor_type to MOTOR_TYPE_GIMBAL. See the instructions here.
Thanks!!
Still trying to get these things worked out, working on the gimbal motor right now. When I plug in the odrive the motor turns but keeps turning and turning…
the only thing I changed in the code is :
// .gate_driver_regs Init by DRV8301_setup
//.motor_type = MOTOR_TYPE_HIGH_CURRENT,
.motor_type = MOTOR_TYPE_GIMBAL,
Maybe there is something else I need to change as well? It does the same thing if the encoder is plugged in or not…
Hmmm that’s odd. The only reason it would do that I can think of is if you have .encoder.use_index = true and your encoder doesn’t have an index pulse, or the index pulse is not working.
Is that the case?
I changed it to .encoder.use_index = false and it seems to work fine the encoder I was using does not have an index pulse. Thanks for the help!
Great! Just for my information, do you know if it was you who changed the setting to true in the first place, or did that come in from some pull from the git server that you did? If so do you remember what branch you were pulling from?
I never changed that, I think I just did a “git pull” from terminal, not sure what that would pull from. If there is something I can do to help you with this let me know, sorry I am not very knowledgeable about all of this.
I just looked, and I’m sorry, it was no mystery, I had accidentally put in the setting to true in the main master code. It’s set to false by default now.
cool! no worries, once you said it that made perfect sense as to how to the motor was acting thanks for being on top of things!
hi @Brandon_Lima, @madcowswe, I was able to connect to my ODrive 3.5 board via Windows machine. I am having a similar issue driving the Turnigy 2822 SK3. Does the calibration startup sequence change at all?
@Brandon_Lima: do you think you could share the configuration parameters that you used to successfully drive this motor?
Hi @alan that was a while ago but if I remember right I had to really play with the calibration current setting, try everything from 1-10.
I think I was never able to get the 2822 to work but I was able to get the larger 2832 (I think), although I suspected that the motor I had was bad.
Hope this helps, I just moved so all my robotics stuff is not in order otherwise I would just put it back together and let you know for sure!