Motor - Magic Pie 2 (48 Volts, 56 magnets, 1500 kw)
Power Source - MeanWell RSP-3000-48
I compiled and flashed ODrive with the following settings different from the standard ones:
#define HW_VERSION_HIGH_VOLTAGE true
#define ENCODER_CPR (5000 * 4)
#define POLE_PAIRS 28
.motor_type = MOTOR_TYPE_GIMBAL,
Installed connections in this picture
Flashing the board was successfull. Here is the picture from Visual Studio Code
I used UART to communicate with ODrive via Arduino.
Yesterday аfter the first start with the ‘b’ command I got vbus_voltage = ~ 48.57
Today vbus_voltage = 0 always
I tried to connect only Arduino and power supply with disconnected motor, resistor and encoder, but still 0 volts
Motor does not rotate and it did not rotate in any of the tests.
The Mosfets heat up very much, especially the one with the edge - a few seconds after it can not be touched.
I think yesterday at the first test I noticed it too late and maybe Odrive overheated and burnt.
In any case, I ask you to help me figure it out, because after the order of the new board everything will be repeated.
I made a demonstration video.
Motor slightly torn after switching on and that’s all.
I did various combinations of connecting wires coming from the motor, but the situation did not change (although I have not tried all combinations)
Maybe the reason is in which combination of wires are connected from the motor?
After I set
.motor_type = MOTOR_TYPE_HIGH_CURRENT and mosfets are no longer overheating,
but the motor also does not move and vbus_voltage = 0
What do I need to check or measure to find out the reason?
I had some issues with my Odrive and I know that to debug is not easy.
I think it is normal if the Odrive detect an error, its possible to read errors over USB.
The order of connection is not a problem.
Did you try to execute the test move ‘s’ after that or an other “power” command ?
I suggest you should first know if a component is burnt, so disconnect all on your board except the DC bus. If you can, try to power with a low tension (5v) and look if a component begin warm. If it is the case you have to change the component.
You can try to use the M1 port but before you have to understand the cause.
Others points :
You don’t need to connect the 5v of the programer look here, maybe it can causes issues.
Did you make a change in the code to take in account the ratio between the motor and the encoder ?
Yes, i made change in the code to take in account the ratio.
Ratio is ~1:10 and for encoder 600 p/r i set ENCODER_CPR (5000 * 4)
After i set .motor_type = MOTOR_TYPE_HIGH_CURRENT no more overheating but still doesn’t work
I tried to detect an error, but i can’t set drivers for ODrive
It says ‘Unknown USB-device (device descriptor request failed)’
So i can’t set ODrive driver to libusb-win32 on Windows 10
I tried to connect USB+STLink and USB+main DC (48 volts)
What else may I check?
Hi @Mirage_2142, sorry that getting ODrive to work has been confusing. I think the main issue is that we have not been clear enough in the documentation.
First of all, please don’t use
MOTOR_TYPE_GIMBAL, it is only for gimbal motors, and can very easily fry your motor or the ODrive if you use it on a lower resistance motor, such as the one you have.
I would recommend that you set
#define USB_PROTOCOL_NATIVE and then try to get it working on the python scripts first, before trying on the Arduino: a lot of the configuration and debug features are not available on the legacy (ascii) protocol.
You must set
#define USB_PROTOCOL_NATIVE then you can try USB connection again.
You must use a gear ratio that makes the effective CPR an exact integer, then you must use that exact number.
Flashed the board
but still the same - ‘Unknown USB-device’
I connect STLink and USB port to USB 2.0 ports because connecting to USB 3.0 doesn’t work
I think it’s probably better for me to wait for the new ODrive and try it without connecting the motor to avoid the possibility of burn.
It’s strange but flashing the firmware works with no errors all the time
Sorry I made a mistake above (I edited to fix it), I mean you must set
Ok yes it seems it still doesn’t work.
Did you try “list all devices”?
I noticed that the results from VSC with some errors
I try to find the file limits.h but there is not in folder odrive-master
Is it normal?
Yes that’s normal, it is because we haven’t found a good solution for the vscode compiler include paths. You can update them to match your installation if you wish. Though this should have no effect on the compilation, only VSCode intellisense.
I understand correctly that I first need to apply power to STLink and then connect USB port?
You don’t need to power the ST link externally, it derives power from your computer’s USB port.
I ordered another Odrive.
I successfully flashed it with this settings in commands.h
After i connect it to Sony VAIO notebook with Windows 7 pro to USB 2.0 ports
(STLink and USB cable)
Then run zadig-2.3.exe and select menu Options/List All Devices
After this i got Unknown Device
What am I doing wrong?
Maybe i need install some other driver to make zadig see Odrive?
Which firmware revision are you based on: can you give a commit hash or fw-v0.x.x release number? Thanks.
I start sending command only via Arduino and UART_PROTOCOL_LEGACY
and check N5065 - it works
But Magic Pie doesn’t rotate - it slightly moves on start Odrive and that’s all. Odrive does not heat anymore.
N5065 still works fine
I set POLE_PAIRS to 28 because MAGIC PIE has 56 magnets.
I measure resistance between motor wires
For N5065 i got 0.3-0.4 Ohm
For Magic Pie 0,6-0.7 Ohm
I downloaded last Odrive sources from GITHUB and Zadig identified Odrive !
So i solved the problem with ‘Unknown device’ in Zadig
I run python tools:
demo.py - works but motor doesn’t rotate
drv_status.py - works with no error from motor
explore_odrive.py doesn’t work
There are errors
On VMWare works good (flashing Odrive and python tools).
So I moved all the sources and components to VMWare, which is very convenient now to move to other computers
What do I need to do now to understand what settings to change in Firmware?
Ok great that you managed to get everything working!
import readline issue is already fixed in the
devel branch and will be released in a week or so. Then I guess working on Windows will also be OK.
Now that you have
explore_odrive.py working in VMWare, can you do
my_odrive.motor0.error, and see if there is any error?
I used GITHUB master branch and explore_odrive.py doesn’t work from this branch (even on VMWare)
I download dev branch from GITHUB
Install ipython and run explore_odrive.py from folder ODrive-devel
Then i got this message
I rechecked n5065 with the same encoder
and for n5065 out: 0
and motor rotate (i mean n5065)
Ok great that you can get the error messages out.
Error 23 is
ERROR_DC_BUS_BROWNOUT (you can check the error enum in low_level.h).
There are 2 reasons that you can get brownout error:
- You have set the wrong board version. To set in:
- Current devel: set the
- Current master: set
#define HW_VERSION_HIGH_VOLTAGE true in main.h
- you are drawing too much power from your power supply and your bus voltage is dipping below 8V.
What power supply are you using? What is your calibration_current and current_lim?
Then why N5065 is work?
I use MeanWell RSP-3000-48 (48 volts)
Arduino b command response 47.6v
.calibration_current = 10.0f,
.current_lim = 10.0f,
I compile and flash sources from master branch of Github
I only run explore_odrive.py from dev branch
Should i flash firmware from dev branch also?
#define HW_VERSION_HIGH_VOLTAGE true
I don’t understand why n5065 is work…
Do you have an oscilloscope and can measure the bus voltage and see if it dips a lot when the ODrive stops?
One reason that the big motor can cause dc bus brownout is because it has larger resistance, but I don’t think it makes sense to be able to trip it when the calibration_current is 10A… So I’m not exactly sure what’s going on.
Can you check if there is a short between any two phases on the big motor?
I rechecked - there is no short.
(For N5065 i got 0.3-0.4 Ohm)
There are some settings in low_level.c
Which of them can i change ?
may be if i will change them randomly then i can find the reason
if i change calibration current to 35 A (or more) - may it help?