In the video, they used the NUCLEO IHM07M1 motor driver shield for the STM32 board, but I want to use the ODrive instead because I require higher current for my eBike hub motor.
What would be the best interface/protocol to use for controlling the ODrive with the STM32 board?
I realized from thread that I can’t directly use my own PWM signals to control the ODrive.
My goal is to model the Driver-Motor system in Simulink to tune the FOC algorithm for my application. I’m working on a chainless eBike project where I’ll later add another ODrive and a generator for the pedal shaft. This will require extensive tuning to mimic the responsiveness of a traditional chain-driven system.
Right now, the ODrive feels like a “black box” to me. Does anyone have suggestions or experience with modeling the ODrive in Simulink to simulate and optimize the system?
Hi! Very cool application, and sorry for the delay in my response. Yes, you cannot control the individual PWM timing of the ODrive phases. However, it seems from your need this shouldn’t be necessary.
To clarify – the starting building block of any brushless servo system is the FOC control. With a proper encoder and configuration, the ODrive will handle any and all of the low-level details, allowing you to directly command torque, which the ODrive will fulfill. That is to say, the ODrive will handle this section of the system block diagram:
I’m going to assume that you’ll want to implement the position/velocity controller externally, so I’ll be mostly focusing on torque control.
The ODrive’s torque control is generally much much faster than the motor’s mechanical response (given inertia), so you unless the motor is operating near maximum speed (where there will be torque falloff – see here for more: ODrive Motors — ODrive Documentation 0.6.10 documentation), you can assume that the ODrive will apply any input torque setpoint given within a few milliseconds (except for the case of a very high inductance motor, or if you’re hitting current limits).
Specifically, the transfer function between input torque and applied torque is a first-order critically damped response at a -3dB frequency of current_control_bandwidth (1000 by default).
Additionally, you can query the ODrive’s estimated torque applied to the motor via the torque_estimate property.
Since the ODrive will auto-tune the current control (i.e. torque) gains, the only gains you’d ever need to tune are the velocity and position controller gains (if using the ODrive in either velocity or position control – this is unnecessary in torque control).
Do either (1) or (2) but with a first-order low pass filter with a cutoff frequency of 1/current_control_bandwidth (so this would be 1/1000 by default) between the (if (2), current limited and torque limited) input torque setpoint, and output torque to the motor.