Hello everyone,
I have been trying to setup my odrive using the getting started documentation and have been running into some issues right off the bat. I can follow the odrive documentation up until
odrv0.axis0.controller.input_pos = 1
where then I get the error
AttributeError: Attribute input_pos not found
I have the most recent firmware and have the most current odrivetool version. I’m really at a loss here.
Hi pete. How certain are you that you have the latest firmware?
I say this because a major firmware change (about a year ago) added input_pos to replace pos_setpoint.
You can hit Tab to see the available commands/objects/attributes in odrivetool, as you would with ipython.
Hello towen,
I am pretty certain, board was purchased about a month or two ago (just getting to setting it up). I have tried the previous commands as well to double check my sanity. Here is a printout
vbus_voltage = 24.293188095092773 (float)
serial_number = 206E39A04D4D (int)
hw_version_major = 3 (int)
hw_version_minor = 6 (int)
hw_version_variant = 56 (int)
fw_version_major = 0 (int)
fw_version_minor = 4 (int)
fw_version_revision = 12 (int)
Realized you were correct in the firmware being incorrect. I went ahead and updated. Still having problems however. Now the initial command for input_pos still doesnt work and when doing the full calibration the motor turns alternating directions constantly and never stops, locking the odrivetool in the process
I went through block by block and have come to the conclusion the error is occuring actually at the command
odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL
Then the motor will just turn back and fourth a few rotations at a time in an endless loop
Aah, that makes a lot more sense! 
You need to adjust the control gains for the position controller. See the tuning guide.
I still don’t understand why odrivetool would lock up though. Possibly a USB comms issue due to noise, which might go away when the controller is tuned corrrectly.
I think the odrivetool is locking due to the motor being in an endless cycle of back and fourth, so perhaps the tool is thinking the command hasn’t yet been successfully executed?
No. Setting the state to closed_loop_control is not a blocking function. Actually you’re just making a request to the state machine, and it has responded by changing state.
Most likely, what’s happening is that the position controller is trying to achieve a position but keeps overshooting. If it’s a very slow oscillation, then perhaps vel_integrator_gain is too high.
Try reducing the gains and see if the oscillation changes.
Thank you for all your help, seems to be working okay now!
