Odrive has AXIS_ERROR_MIN_ENDSTOP_PRESSED error after homing


I have my new odrive setup with a limit switch at the end of one axis. After homing axis0 remains in an error state (AXIS_ERROR_MIN_ENDSTOP_PRESSED). Using odrivetool, I can clear the error, then can jog the axis around normally. However, when I write a python script which follows the same process, I’m unable to move the axis. If I then launch odrivetool and do dump_errors, I see that it’s still in the same error state. But now I can’t clear it (even from odrivetool), and only a reboot will get things going again.

Here’s my python script.

import odrive
from odrive.enums import *
import time
import math

PULLEY_PCD = 19.1*0.001     # m
AXIS_RANGE = 0.8            # m
HOMING_TIMEOUT = 20         # s

print("finding an odrive...")
od = odrive.find_any()
# Clear any errors (both axes)
axis = od.axis0

# mo = axis0.motor

# Ask axis to home

axis.controller.config.homing_speed = 0.7
axis.requested_state = AXIS_STATE_HOMING

t_start = time.time()
while axis.current_state != AXIS_STATE_IDLE and ((time.time() - t_start) <= HOMING_TIMEOUT):
if (time.time() - t_start > HOMING_TIMEOUT):
    print("...timed out")
    axis.requested_state = AXIS_STATE_IDLE
# Clear the homing active error
# Put odrive in closed loop mode
axis.controller.config.input_mode = AXIS_STATE_CLOSED_LOOP_CONTROL
axis.controller.config.input_mode = INPUT_MODE_TRAP_TRAJ
# Prompt user for target location, do some validation then command move axis
    print("Enter axis target (m):")
    target_m = float(input())
    if(target_m > AXIS_RANGE):
        target_m = AXIS_RANGE
    elif(target_m < 0):
        target_m = 0
    target_turns = target_m / (PULLEY_PCD*math.pi)
    print("target: " + str(target_m) + "m, " +  str(target_turns) + " turns")
    # od.axis0.clear_errors()

    axis.controller.input_pos = target_turns
    while axis.current_state != AXIS_STATE_IDLE:
    print("Movement complete")

Any help is appreciated!



Ok, I did just notice a mistake in my original program - I believe I should be doing

axis.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL
axis.controller.config.input_mode = INPUT_MODE_TRAP_TRAJ

If I push the axis off the limit switch, then trying jogging the axis (from within my python program) it now works as expected. But I still have the issue with the error, which is to say it won’t move while it’s on the limit switch, and clearing the error from within my python program using


doesn’t seem to be helping

Well it shouldn’t be throwing an error anyway. What version of the firmware are you running?

How do I check my firmware version? It’s a brand new 3.6 board which I received last week.


Ok, figured it out - I have 0.5.1. I’ll try upgrading tomorrow.

Hmm, does it says 0.5.1 and “unreleased”? We actually made a mistake when we released 0.5.2 and it’s stuck showing 0.5.1 lol

odrv0.fw_version_unreleased = 0

Does that mean that I do have 0.5.1?

I’ve now upgraded to 0.5.2.

During that process some settings seemed to get lost, so I’ve dismantled my system (i.e. no load on the motor) and have re run the calibration process, then saved the configuration. All seems well, but when I do odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL, I get motor error MOTOR_ERROR_UNKNOWN_PHASE_ESTIMATE. odrv0.axis0.motor.is_calibrated is showing as True, and the encoder seems to be working fine. I’m using a D6374 I bought from the store.

Any suggestions?


I seem to have resolved this by erasing the entire configuration and starting from scratch. I’ll report back later on whether the firmware upgrade has solved my AXIS_ERROR_MIN_ENDSTOP_PRESSED error problem.

1 Like

I can confirm my limit switch errors have gone away with the firmware update.


Hi, I just uploaded 0.5.2 firmware on Odrive 3.6-56V and configured min_endstop and axis homing at startup.
I’m getting the same error (AXIS_ERROR_MIN_ENDSTOP_PRESSED) when homing on startup.
I don’t understand why since I followed the docs page on homing to set it up.

Hi Powerbling, there was a problem / bug in 0.5.2. We just released 0.5.3 today which fixes it, so I recommend upgrading :slight_smile:

Hi Wetmelon, problem persists after firmware upgrade.

1 Like

hello, I have the same issue, even after the firmware upgrade, @Wetmelon could you help us to fix this issue?

Understood. I’ll have to set up a homing system here to debug.