Thank you for your kind reply, but could you tell me how to remove control utility version 0.5.2 and install back control utility version 0.5.1? There is no such problem with version 0.5.1. Thank you.
pip install 'odrive==0.5.1.post0'
Hi all, I just updated the Odrive control utility to 0.5.2 as well as the firmware, and I noticed that the Iq setpoint was saturated at 3.3333334922790527.
I am using a 4S lipo battery to drive a motor similar to T-motor U10plus.
I set up the ODrive motor controller in torque control mode
The motor configuration and controller configuration are listed below:
I_bus_hard_max: inf (float)
I_bus_hard_min: -inf (float)
I_leak_max: 0.10000000149011612 (float)
R_wL_FF_enable: False (bool)
acim_autoflux_attack_gain: 10.0 (float)
acim_autoflux_decay_gain: 1.0 (float)
acim_autoflux_enable: False (bool)
acim_autoflux_min_Id: 10.0 (float)
acim_gain_min_flux: 10.0 (float)
bEMF_FF_enable: False (bool)
calibration_current: 10.0 (float)
current_control_bandwidth: 1000.0 (float)
current_lim: 60.0 (float)
current_lim_margin: 8.0 (float)
dc_calib_tau: 0.20000000298023224 (float)
inverter_temp_limit_lower: 100.0 (float)
inverter_temp_limit_upper: 120.0 (float)
motor_type: 0 (uint8)
phase_inductance: 2.2307487597572617e-05 (float)
phase_resistance: 0.0595686137676239 (float)
pole_pairs: 20 (int32)
pre_calibrated: False (bool)
requested_current_range: 90.0 (float)
resistance_calib_max_voltage: 2.0 (float)
torque_constant: 1.0 (float)
torque_lim: inf (float)
anticogging:
anticogging_enabled: True (bool)
calib_anticogging: False (bool)
calib_pos_threshold: 1.0 (float)
calib_vel_threshold: 1.0 (float)
cogging_ratio: 1.0 (float)
index: 0 (uint32)
pre_calibrated: False (bool)
axis_to_mirror: 255 (uint8)
circular_setpoint_range: 1.0 (float)
circular_setpoints: False (bool)
control_mode: 1 (uint8)
electrical_power_bandwidth: 20.0 (float)
enable_current_mode_vel_limit: True (bool)
enable_gain_scheduling: False (bool)
enable_overspeed_error: True (bool)
enable_vel_limit: True (bool)
gain_scheduling_width: 10.0 (float)
homing_speed: 0.25 (float)
inertia: 0.0 (float)
input_filter_bandwidth: 2.0 (float)
input_mode: 1 (uint8)
load_encoder_axis: 0 (uint8)
mechanical_power_bandwidth: 20.0 (float)
mirror_ratio: 1.0 (float)
pos_gain: 20.0 (float)
spinout_electrical_power_threshold: 10.0 (float)
spinout_mechanical_power_threshold: -10.0 (float)
steps_per_circular_range: 1024 (int32)
torque_mirror_ratio: 0.0 (float)
torque_ramp_rate: 0.009999999776482582 (float)
vel_gain: 0.1666666716337204 (float)
vel_integrator_gain: 0.3333333432674408 (float)
vel_limit: 20.0 (float)
vel_limit_tolerance: 1.2000000476837158 (float)
vel_ramp_rate: 1.0 (float)
and here is the input torque as well as Iq setpoint during operation
In [33]: odrv0.axis0.motor.current_control.Iq_setpoint
Out[33]: 3.3333334922790527
In [34]: odrv0.axis0.controller.input_torque
Out[34]: -9.652692794799805
Maybe this issue has existed before when I was using 0.4.12, but I was wondering if there is any other parameters that I should set to increase the current.
Best.
Sounds like an encoder problem, i.e. the commutation is wrong.
What encoder are you using? Can you check that is working properly? (try using odrivetool liveplotter and turn the motor by hand)
Hey,
We’re experiencing issues when initiating closed loop control from the startup sequence. Whenever we try to actuate the error UNKNOWN_PHASE_ESTIMATE is given. If we manually set the axes to closed loop control we don’t experience this error.
I’m honestly not sure whether this issue has arisen from the firmware changes as we haven’t used this feature with earlier firmware version. Though I’d expect it to be a known issue if it had occurred in earlier firmware versions.
Cheers
1 Like
Try disabling the speed limit in torque mode (controller.config.enable_current_mode_vel_limit)
I’ve created a github issue for this, please put any info you have in there. startup_closed_loop causes UNKNOWN_PHASE_ERROR · Issue #582 · odriverobotics/ODrive · GitHub
Was there any change related to pre-calibration data for the encoders?
Namely, requesting state AXIS_STATE_ENCODER_INDEX_SEARCH doesn’t actuate the motor as it did in 0.5.1. However, one can request AXIS_STATE_CLOSED_LOOP_CONTROL immediately afterwards and the drive actually goes into closed loop control - then, if the motor is disturbed in any way, MOTOR_ERROR_SYSTEM_LEVEL and ODRIVE_ERROR_DC_BUS_OVER_REGEN_CURRENT are generated…
We are also experiencing issues activating step/dir input mode
- disabled UART on pins 1,2,
- switched the pins to mode 0 (GPIO),
- enabled step_dir in axis config
- checked for correct step and direction gpio mapping in axis config
Is there anything else to check/do?
We upgraded the FW to 0.5.2 due to LPF on motor thermistors (we had an issue that in one moment odrive with 0.5.1 went into a weird state, where the stationary and unloaded motor got so hot it burned the skin on touch…).
ps: anti-cogging calibration is not operational, either… odrv0.axis0.controller.start_anticogging_calibration() sets the calib_anticogging: True, but there is absolutely no motion after initial ‘jerk’ to the starting position
Hi,
I ran a firmware update using multi-platform instructions posted on the odriverobotics site. I was running into many issue and am now trying to go back to the 0.5.1 firmware version.
I downloaded the folder from github and it is sitting in my downloads and I am not quite sure where to move the folder from there. I was wondering if anyone knew what file location it should be placed in?
Hey guys, I am using a motor with hall sensors built in and I am having getting position control working. I can get velocity control working when I am in incremental encoder mode, but when I change to hall encoder mode, I can’t get position control working.
One thing I am confused about is what’s the difference between hall encoder mode and incremental? The screenshot below says I need to put it in incremental mode, but I think I want to get it working in Hall mode.
Another thing, the screenshot below says to configure GPIO pins 9,10,11 to digital, but in Odrive now, I get an error like AttributeError: Attribute gpio9_mode not found when trying to perform the commands below.
.config.gpio9_mode = GPIO_MODE_DIGITAL
.config.gpio10_mode = GPIO_MODE_DIGITAL
.config.gpio11_mode = GPIO_MODE_DIGITAL
Thanks for all the help!
@MatevzB what command sequence did you use for setup?
I tried this and it works as expected:
odrv0.erase_configuration()
odrv0.axis0.encoder.config.use_index = True
odrv0.axis0.requested_state = AXIS_STATE_MOTOR_CALIBRATION
# [wait for beep]
odrv0.axis0.requested_state = AXIS_STATE_ENCODER_INDEX_SEARCH
# [wait for motor to stop]
odrv0.axis0.encoder.index_found # returns True
odrv0.axis0.requested_state = AXIS_STATE_ENCODER_OFFSET_CALIBRATION
# [wait for motor to stop]
odrv0.axis0.encoder.config.pre_calibrated = True
odrv0.axis0.motor.config.pre_calibrated = True
odrv0.save_configuration()
# [wait for reboot]
odrv0.axis0.encoder.index_found # returns False
odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL
odrv0.axis0.current_state # returns 1 (idle)
odrv0.axis0.requested_state = AXIS_STATE_ENCODER_INDEX_SEARCH
odrv0.axis0.encoder.index_found # returns True
odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL
odrv0.axis0.current_state # returns 8 (closed loop control)
As for the anticogging and step/dir issues, I have to look into that.
@vvanamala you can point odrivetool to the path where your downloaded hex file is: odrivetool dfu /path/to/firmware.hex.
@ap23 can you post the output of odrv0.config? Does it contain an item called gpio9_mode?
@Samuel We ended up figuring this out, it turns out we didn’t need to set those GPIO pins to digital. However, now we got position control to work but are having a little trouble with tuning our system.
In the tuning instructions below, it says to increase position gain until it overshoots. Does this mean the. motor has to already be spinning during tuning? Do we need to give it an input position before tuning? What exactly does overshoot mean in this context? Thanks a lot! Also, I’m having an issue where sometimes i need to give the motor a small tap before it goes to the commanded position. Is there any way to fix this?
@Samuel On previous versions, one could go directly to AXIS_STATE_ENCODER_INDEX_SEARCH after the reboot with a precalibrated motor. Was this intentionally changed?
It looks like the encoder setpoint does not zero when endstop is pressed.
Settings:
odrv0.config.gpio7_mode = 0
odrv0.axis1.min_endstop.config.gpio_num = 7
odrv0.axis1.min_endstop.config.is_active_high = True
odrv0.axis1.min_endstop.config.debounce_ms = 200
odrv0.axis1.min_endstop.config.enabled = True
odrv0.axis1.min_endstop.config.offset = -3
odrv0.axis1.controller.config.homing_speed = -2
I saw some people working with the Devel branch, this seems like a lot of work to get into.
Is it possible to get a regular firmware download with this updated?
@ap23 yes the ODrive needs to be at a stage where you can command it a position setpoint and the motor will go there. For tuning the simplest way is to send manual position setpoints to send the motor back and forth between two positions. Overshoot means that the motor spins further than the commanded position and then turns back before finally coming to a halt. The tap might be required because the motor can’t overcome static friction and cogging torque. You can try to increase the current limit a bit to fix this.
@MatevzB You can still do that. In my log I only ran additional commands to verify that the ODrive rejects closed loop control as expected after startup.
@Samuel thanks a lot! One more thing, I think I tuned my motor properly as it accurately goes to inputted position with no overshoots and vibrations. This is with a vel_gain of 0.30, pos_gain of 28, and a vel_integrator_gain of 0. When I use the formula for vel_integrator_gain, i get 150, and then this makes my system vibrate.
- What should I do about this for vel_integrator_gain? Change my bandwidth? If so, to what?
Also, is there a reason why the motor isn’t, say, “fighting back” a lot when I hold it as it is spinning in velocity mode? How can I make it do this in both modes? EDIT: We just measured current and it looks like the system isn’t really increasing current after I hold it down (when vel_integrator_gain is 0). When I make vel_integrator_gain 150, it somewhat increases current upon holding the motor, but not that much. Also, when I put it in position mode with these values, it just vibrates rapidly, unless vel_integrator_gain is shifted to 0.
- current_lim: 85
- requested_current_range: 100
- velgain, posgain: 0.30 and 28
- bandwidth: 1000
- current_control_bandwidth: 2000
- How else could I make it so current increases to maintain motor velocity upon some stress to the motors?
Additionally, when I do get a current limit violation, and even sometimes when I don’t, I notice that the current_lim state is drops to 11 automatically. Any reason why?
Lastly, I’m using a 190 kv motor, but when I do 8.27/190 for my torque constant, the low value causes the motor to spin extremely fast with any input and thus cause a current_lim violation. Any thoughts about this?
Thanks a lot for your help too, appreciate it
@Samuel I tried to redirect the path as you suggested although I keep running into an issue that I had before that I’m not sure how to fix. When launching the odrive tool, the prompt states:
C:\Users\vaish>odrivetool dfu /path/to/firmware.hex
ODrive control utility v0.5.2.post0
Waiting for ODrive...
←[91;1m13:02:26.766500700 [USB] Could not open USB device: -5←[0m
←[91;1m13:02:27.795895800 [USB] Could not open USB device: -5←[0m
←[91;1m13:02:28.825201000 [USB] Could not open USB device: -5←[0m
It should be 0.5 * vel_gain * the desired system response bandwidth of the velocity control, not the current controller. Try something between 1.5 and 15, not 150.
8.27 / 190 is correct. It spins very fast with any what input? input_pos?
So I tried to update and updating the odrivetool seems to be no problem (the picture was taken with the odrivetool downgraded again) but after running the DFU tool “successfully” the firmware number on the odrive doesn’t change to 0.5.2
I would’t be so bothered about it if I weren’t getting errors left, right and centre (fet-transistor error, unbalanced phases, other motor errors and some system-level errors)
Does anyone know what I am doing wrong?
1 Like