Endstop and Homing

Support
#1

Hi,

I’ve recently received the Odrive (v3.6) and am having some challenges with the endatops and homing -

Homing:
I’m using hall sensors which work fine (detect the end stop), but when running the homing sequence (so moving to home position following reaching min_endstop) it doesn’t seem to matter what I put as the offset, the motor continues until it hits the end of gantry (so goes past the max_endstop as well).
If i don’t use the homing sequence, and run (i’m using INPUT_MODE_VEL_RAMP mode) it stops fine at both min and max endstops, but have no homing data.

Which leads to…

Endstops:
When the motor hits either endstop, it stops as expected, but won’t take any other commands - i have to reboot.
As noted above i’m using VEL RAMP mode, so am sending input_vel in the opposite direction (away from the endstop), but nothing.

Have been stuck on this for a day, so would really appreciate some pointers! :slight_smile:

M

#2

Hmm… I don’t see anything wrong in the devel branch, and I know @Riewert has been using this. Maybe he can help?

1 Like
#3

Sounds like your offset is either not big enough, or you are using firmware 5.1, which has a bug that was recently fixes.

Can you confirm which version you are running, and that you have your offsets set to none-zero values?

#4

Thanks for getting back to my post.
Looks like I’m running 5.1, so looking at upgrade now.

I’ll update this post to confirm fix or not asap.

Update: Running odrivetool dfu it shows latest as 5.1 - is there a newer version?

#5

You should build the latest version of the devel branch. It is a good idea to do this, as it makes you more familiar with the code, and makes solving any issues you run into a lot easier. There is a guide on how to do this here.

To get you started I’ll build the current version for you. I’ve put them here, they will be available for a week.

On the official website under How to flash a custom firmware is an explanation of how to load custom firmware.

You will probably get a warning from the DFU tool about the firmware version you are uploading. You can ignore that.

#6

Thanks Riewert, I really appreciate the help.
Late here (in Australia) so one to pick up tomorrow!

Thanks again.

#7

Sleep tight.

Btw, here is the issue that was fixed. I think it fits your description.

#8

Hi @Riewert,

The version of firmware you created unfortunately didn’t work - it loads, but the motors no longer initiate. I’ve got the V3.6 56v board.
I created a dev VM, cloned the repo (devel branch) and updated the config file prior to trying a make - with CONFIG_BOARD_VERSION=v3.6-56V
Build fails with unknown board version - looking at the makefile it just checks for ‘v3.’, and the board code it looks like 3.6 is listed, but only voltage listed is 24 or 48.
I try 48V and still get the same error.

Should the build support 3.6 56v?

edit: please ignore me - I had a moment…
Note to self - helps if you rename the config file :wink:

#9

Haha, yeah I was just gonna say that.

Strange. Did you odrv0.erase_configuration() and then reconfigure everything? Between devel and normal releases there are usually quite a number of changes, that cause settings to move around.

I think I tested that build before I put it online for you. But building it yourself is a lot better, so focus on that first.

#10

The build works, but I have the same issue after flash update (no response to initiate), and the same error when flashing, so looks like the build result is the same as the files you created:

Traceback (most recent call last):
File “/usr/local/bin/odrivetool”, line 143, in
odrive.dfu.launch_dfu(args, logger, app_shutdown_token)
File “/usr/local/lib/python3.5/dist-packages/odrive/dfu.py”, line 465, in launch_dfu
update_device(device, firmware, logger, cancellation_token)
File “/usr/local/lib/python3.5/dist-packages/odrive/dfu.py”, line 429, in update_device
odrive.configuration.restore_config(device, None, logger)
File “/usr/local/lib/python3.5/dist-packages/odrive/configuration.py”, line 81, in restore_config
device.save_configuration()
File “/usr/local/lib/python3.5/dist-packages/fibre/remote_object.py”, line 162, in call
self._parent.channel.remote_endpoint_operation(self._trigger_id, None, True, 0)
File “/usr/local/lib/python3.5/dist-packages/fibre/protocol.py”, line 308, in remote_endpoint_operation
raise ChannelBrokenException()
fibre.protocol.ChannelBrokenException

#11

Does the custom firmware load, despite that error?

I think your error is because you are running the normal release of ODrivetool and not the devel ODrivetool.

#12

It loads and responds to commands in the interface (setting or reading values for example), just don’t get any response from the motor.
Flashing back to release version it responds fine.

I wasn’t aware there was a level version of ODriveTool, so will try that tomorrow.

Thanks again for the pointers

#13

Oh, then using the new odrivetool wont change anything. Did you redo your calibrations after the update? You need to confirm that you can get closed loop control working again before you try homing.

#14

Yes, its the motor initiation and calibration that fails - it accepts the ‘odrv0.axis0.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE’ command (no error back), but nothing happens.
I’ve set aside some time this weekend to look at it, so will keep you posted!

#15

Try running the individual calibration steps. That might give you more insight. Motor calibration first i think. Thats the one that beeps.