Axis 1 Stopping at 25V

Hi there,

I’m using the ODrive to power two hoverboard motors. As power supply i have to 12V batteries that provide between about 11.5 to 12.5V. Now, when I start the programm, the motors spin for about half a second, then axis 1 stops and is not turning anymore until the ODrive is rebooted. However, when connected to only one battery, both axes work just fine.
Now my question is, how much overvoltage the ODrive can endure? I own the 24V Version and the odrv0.vbus_voltage command gives a bus voltage of 24.8V. Is it possible that this is too much?

I will try to put a step-down voltage regulator between Power-Source and ODrive to see, wether this works at 23-24V. To see if this slight voltage overdose is the cause of the error.

Thanks in advance for your help.

What error are you getting?

dump_errors(odrv0)

I tried regulating the voltage to somewhat between 22.5-23.9V. The motors then worked most of the time but the controller shut down, when the wheels hit obstacles or when the cart tried to break. Now I wanted to read the errors but my raspberry pi won’t recognize the ODrive anymore. I tried a few different things and decided to start over with a fresh raspbian.
Now with the odrivetool installed and did everything from the Getting Started page, but ended up in the same situation as https://discourse.odriverobotics.com/t/odrive-doesnt-show-up-in-odrivetool/808 - lsusb is not showing any signs of the odrive, same thing on my windows pc. Additionally the odrivetool generates the same errors as https://discourse.odriverobotics.com/t/solved-issue-connecting-odrive-to-rpi-over-usb/2798. Unfortunatelly none of advice there could resolve my issue.

My windows does recognize the ODrive in DFU mode, but I am not so familiar with the flashing process so I did nothing with that. The green light is also shining on the ODrive. But somehow I can’t establish a connection.

I know this is a slight change of problem, yet I hope you can help me solve it.

Thank you for your help

Okay, I forced DFU mode and reflashed the firmware. Now the ODrive is showing in lsusb. Now, I only have the runtimewarnings with the odrivetool.

I was able to solve the connectivity issues and am back at the problem that I opened the thread for.

When I connect the ODrive to any voltage between 20-24.7V, the wheels spin for a while. If I generate any breaking torgue, it occurs in about 90% of the cases that either one axis - namely axis 0 - or both axes stop and are not reacting to the ODrive anymore.
When reading the errors there are two different cases:
Axis 0 stopping: the error is the encoder error ERROR_ILLEGAL_HALL_STATE
Both axes stopping: both axes have the ERROR_DC_BUS_OVER_VOLTAGE error.
The power supply are two batteries and I do not have the auxilliary break resistance connected.
For the Hall state error, I have checked whether there are any loose connections with the hall sensors, but that does not seem to be the case. Additionally, when I connect the ODrive to only one battery and run it on 12V, everything works fine. The motors are designed as 36V motors.
I don’t know what more info is needed, but I’m happy to provide.

I also found madcowswe’s post:


Here he suggests to solder on some capacitors. Could that be the issue, since it seems to work with 12V just fine? I’m am rather wary soldering on costly electronics. I am using the ODrive 3.6

Thanks for the support.

Yep, add caps to solve that ILLEGAL_HALL_STATE error.

Thank you for your help.

We still face the DC_BUS_OVER_VOLTAGE error. We are experiencing it everytime we generate a breaking torgue. Depending on the supply voltage the error occurs sooner or later. When operating with 24V slight breaks or small obstacles cause the motors to stop. When using 18V only stopping both motors at the same time causes the over voltage. Using 12V both motors work fine but don’t provide the required power.

We have the ODrive attached to two 12V batteries wired in series. Between these two batteries on a 12V lane we connected a RaspberryPi. Our next step is to try and use the provided resistance to burn off any currents the motors generate when breaking. However that would disable any recuperation. Does it make a difference whether the recuperation is enabled or if we connected the batterys to the AUX output of the ODrive? The idea would be that any generated voltage would maybe not cause errors on the ODrive then.
Second idea is to switch motors. We currently use hoverboard wheels designed for 36V. I am not firm enough with motors but I could imagine that they behave differently while breaking from 24V oder 12V motors. Do you think that could make a difference?

Thank you for your time in reading this and the support you provided.

Additionally another question: If we succeed in our project and get it ready for the market we would need larger numbers of ODrive boards. Is there any way to know when the capacitor bug would be fixed, since it appears to exist since version 3.3?

You weren’t doing that already? No wonder it was happening.

If you use https://github.com/Wetmelon/ODrive/tree/RazorsEdge, you can set the regeneration current limit with odrv.config.max_regen_current while also using the braking resistor.

I’m not sure about the capacitors, you’d have to ask @madcowswe

p.s. it’s spelled braking, not breaking :wink:

Up to this point we were not.

I was following the guidelines which state:

If you don’t have a brake resistor, the ODrive will pump excess power back into the power supply during deceleration to achieve the desired deceleration torque. If your power supply doesn’t eat that power (which it won’t if it’s not a battery), the bus voltage will inevitebly rise.

So I thought we’d be fine using just the batteries. I suppose that means our batteries cannot eat enough power to achieve the deceleration torgue? If we use the brake resistor, does that mean all excess power is burnt off over the resistor or do we still recover some of the energy and only the remaining energy is lost?

As I understand, when using your branch of the ODrive Software we can achieve the partial regeneration and excess power burning. However, I would like to stick to the master branch as long as possible.

Thank you very much for your support.