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!
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.
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
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.
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
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.
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.
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!
