@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
@Samuel
As I wrote initially, changing the requested_state into AXIS_STATE_ENCODER_INDEX_SEARCH directly after reboot doesnât actuate the motor and just finishes immediately. Setting the state to closed loop afterwards, actually does actuate the motor, but it is not stable (ODrive has no idea on where the rotor isâŚ).
1 Like
Hi everyone, after being unable to drive my motor in sensorless mode i decided to upgrade the firmware of the board. it failed and now not even the USB is recognised by windows⌠close to brick modeâŚ
can i please have some ideas?
@Diego_Colonnello Change the DFU on the DIP switch to 1 and reboot the card. You can then proceed either with the latest version odroid tool to load the firmware or use the STM32CubeProgrammer to load the hex directly.
I fixed mine this way.
I tried this exact sequence today with the 56V ODrive 3.6. Nothing happens when encoder is instructed for index search.
Normal calibration does work, but it is not possible to do full calibrations when the motors are mounted in the final position.
As noted, we really need the temperature sensors on the motor and the driver since one of the ODrives failed in such a way that both the motor and the driver almost got toasted. Since the noise is not filtered in the previous firmware, the temperature limits just get hit even during motor calibration of the other motor channelâŚ
Can we expect any fix for the latest firmware since our project is standing stillâŚ
@Wetmelon I got it to work, thanks! But now I have another issue. The âf motorâ UART command for ASCII which is supposed to send position data to the computer isnât working. When I run the command, I get back non-sense characters. Iâm extremely confused on what to do or how to debug this. Any thoughts? Thanks!
1 Like
Double check that you have a good ground, and make sure youâre reading Floats instead of ints or characters.
When you request AXIS_STATE_ENCODER_INDEX_SEARCH and immediately afterwards check odrv0.axis0.current_state, whatâs the value (it should be 6)? After checking this, wait for current_state to change to 1. After that, whatâs the output of dump_errors(odrv0)?
It state does indeed change from 1 to 6 when commanding AXIS_STATE_ENCODER_INDEX_SEARCH, but there is no power to the motor and the state changes back to 1 immediately.
Whatâs the output of dump_errors(odrv0) after that? And whatâs the value of <axis>.encoder.index_found?
It sounds like the ODrive mistakenly recognizes an index pulse immediately after arming the motor.
What encoder are you using? What GPIO are you using for the index? Please also try with disconnecting the index pin entirely.
It could also help to post a copy of your configuration (odrivetool backup-config) and/or a complete list of commands you ran (starting with an erased config).
I tried this with slight modifications (see commends for explanation) and it works as expected. After hitting the endstop (I used a jumper cable to manually put GPIO7 to 3.3V) the motor moves back a bit (3 turns in this case) to what has now become the zero position.
Here are my commands:
odrv0.erase_configuration()
odrv0.config.gpio7_mode = GPIO_MODE_DIGITAL_PULL_DOWN # pulldown recommended since your endstop is active high
odrv0.axis0.min_endstop.config.gpio_num = 7 # I don't have axis1 hooked up
odrv0.axis0.min_endstop.config.is_active_high = True
odrv0.axis0.min_endstop.config.debounce_ms = 200
odrv0.axis0.min_endstop.config.enabled = True
odrv0.axis0.min_endstop.config.offset = -3
odrv0.axis0.controller.config.homing_speed = -2
odrv0.axis0.controller.config.vel_limit = 5 # must be higher than abs(homing_speed)
odrv0.config.enable_brake_resistor = True
odrv0.save_configuration()
odrv0.axis0.requested_state = AXIS_STATE_MOTOR_CALIBRATION
odrv0.axis0.requested_state = AXIS_STATE_ENCODER_OFFSET_CALIBRATION
odrv0.axis0.requested_state = AXIS_STATE_HOMING
dump_error(odrv0) shows no errors and odrv0.axis.is_homed is True after this. Please check if this is the case for you too.
I did run into a different bug tough whereby the homing procedure mistakenly completes successfully if an error happens during homing (like overspeed). In this case the ODrive thinks itâs homed but the position registration will be off.
1 Like
Hi there guys, Iâve successfully upgraded my v3.6 56V board to v0.5.2, but am repeatedly getting ODRIVE_ERROR_DC_BUS_OVER_REGEN_CURRENT errors. Iâve attempted increasing the dc_max_negative_current to -50mA, but am concerned to go higher given that this is 5x the default value.
For reference, I am powering 2x T-Motor U13 (85KV) and using a 1.2kW (60V, 50A) power supply, with a 10 Ohm brake resistor. Iâve set my current limit at 40A and current limit margin at 10A.
Any ideas?
This is way too high. Youâll go over your max braking current very quickly (60V / 10 = 6A bus current, or ~360W). But make sure you have odrv0.config.enable_brake_resistor = True. Otherwise, set dc_max_negative_current to a more negative value (we used to not have this and nobody said their power supply exploded, so itâs probably safe to set it pretty high, but YMMV)
Sorry, It looked like it didnât reset the value.
After homing it had a controller.pos_input of 17 something, but as soon as I set another pos_input it moved to the correct position.