Starting position after homing on 2 parallel axis

Support
1

Hello everyone!

I am currently trying to implement a gantry, and I am facing some issues with the homing process.

For some quick context, it works as shown in this simplified diagram:

ODrive_Tink_Gantry
ODrive_Tink_Gantry3730×1195 393 KB

I have 2 D5065 motors (from ODrive shop) controlled by a single ODrive (v3.6 56V, last devel firmware), powered by a 24V power supply (for now).
Instructions come as step/dir from an Arduino Mega, running a modified GRBL. It is only used to control M0. M1 is then mirrored form M0 encoder with an offset.
For each axis, a 8192 CPR encoder is used (AMT102-V, from ODrive shop again), directly on motor shaft.
At each end of both rails, there are min and max endstops.

Everything is wired as shown :

ODrive_Tink_Wiring
ODrive_Tink_Wiring2137×969 92 KB

What I am trying to achieve is for my gantry to be at a set position “0” after calibration and homing. It could be summed up as this sequence:

  1. M0 and M1 calibration.
  2. Reaching for min endstops.
  3. Modify offset value used to control M1 from M0 encoder.
  4. Move to specified position (that should be min_endstop.offset ?).
  5. Move as instructed from setp/dir input.

What my current sequence looks like:

  1. M0 and M1 calibration.
  2. Reaching for min endstops.
  3. Return to power-up position.
  4. Move as instructed from setp/dir input.

Endstops, are checked and working.
Here are my ODrive parameters:

In [1]: odrv0.axis0.min_endstop
Out[1]:
config:
debounce_ms: 50 (uint32)
enabled: True (bool)
gpio_num: 1 (uint16)
is_active_high: True (bool)
offset: 0.0 (float)
endstop_state: False (bool)

In [2]: odrv0.axis0.max_endstop
Out[2]:
config:
debounce_ms: 50 (uint32)
enabled: True (bool)
gpio_num: 2 (uint16)
is_active_high: True (bool)
offset: 0.0 (float)
endstop_state: False (bool)

In [3]: odrv0.axis1.min_endstop
Out[3]:
config:
debounce_ms: 50 (uint32)
enabled: True (bool)
gpio_num: 3 (uint16)
is_active_high: True (bool)
offset: 0.0 (float)
endstop_state: False (bool)

In [4]: odrv0.axis1.max_endstop
Out[4]:
config:
debounce_ms: 50 (uint32)
enabled: True (bool)
gpio_num: 4 (uint16)
is_active_high: True (bool)
offset: 0.0 (float)
endstop_state: False (bool)

Thanks in advances for any help or feedbacks!

Tink

2

Plug your endstops into grbl and home that way, then send set_linear_position(0) when they’re in the spot you want to call home.

3

Hi!

Thank you for this solution!

Unfortunately, I can only control my ODrive with the setp/dir form the GRBL.
That is why I thought of using the homing procedure with a defined offset.
Do I use the wrong endstop parameters or maybe I understood wrong what it is supposed to do?

Thanks again for your response.

Tink

4

Move the gantry by hand to the location you want to call “0”. Measure the distance from the endstop to the gantry (the part that will touch the encoder). The encoder.config.offset will be the negative of this value, in turns. (say -1.25 for 1.25 turns). When you ask the drive to home with AXIS_STATE_HOMING, it will automatically handle this offset.

You can’t home the axis by running into the endstop while in CLOSED_LOOP.

5

Hi!

Sorry for the delay. I had to solve new electrical issues before I could try your solution.
Sadly, it still doesn’t fully work. The AXIS_STATE_HOMING gives proper reaction when asked after a normal start (config.startup_homing = False).
However, when homed during the startup process (config.startup_homing = True, just after motor and encoder calibration), it makes erratic moves:

For each axis:

  1. powering the ODrive
  2. motor calibration
  3. index search
  4. moves toward min endstop
  5. touches the min endstop
  6. moves back slowly by the number of turn defined by the encoder.config.offset (and I don’t get why, but it works for me with positive values)

And that is where I encounter issues, different from my original post

  1. jumps a random distance in a random direction
  2. goes into closed loop control

Thanks again for your help!

6

After a few weeks of getting back to fresh firmware and parameters, I think I understand better what is going wrong.
It appears that, for a “standard” control method, the homing sequence works obviously well, during startup as well as any given time AXIS_STATE_HOMING is requested.
However, when coupled with step/dir control, homing at startup doesn’t properly work, and gives the sequence I originally described:

Any idea of where it might come from?

7

What pins do you have the endstops on? Might be conflicting with the endstops. See

8

I tried switching and it gave me the same result.
For context, current GPIO are:
1:axis0.min_endstop
2:axis0.max_endstop
3:axis1.min_endstop
4:axis1.max_endstop
5:NC
6:NC
7:Dir
8:Step

9

The problem comes with :

odrv0.axis0.controller.config.circular_setpoints = True

I tried to increase cricular_setpoint_range to 50 as my motor is not supposed to do more than 44 turns for a full axis travel, without success.

10

For context, here are the 2 graphs for both circular_setpoints = False and True.
I tried my best to start from the same arbitrary point near the middle of my axis.

  1. circular_setpoints = False

Here, ​once AXIS_STATE_HOMING is requested, it moves as it is supposed to:

  • Goes to reach for min_endstop
  • “endstop_state = True”, stops
  • Goes back as defined by offset
  • Done!

setpoints False
setpoints False4184×2243 362 KB

  1. circular_setpoints = True

This time, HOMING makes it go back before the starting position:

  • Goes to reach for min_endstop
  • “endstop_state = True”, stops
  • Goes back what to what looks like X0 + offset
  • Done, but not correctly!

setpoints True
setpoints True4184×2243 418 KB

11

What offset do you have set? I imagine the way that the homing works will cause it to fail if offset >= 0.5 * circular_setpoint_range

12

Not working either.

I kept circular_setpoint_range at 1 and tried many different min_endstop.config.offset :

  • -2.5
  • -1
  • -0.4
  • 0
  • 0.4
  • 1
  • 2.5