I am mainly a mechanical engineer, not a software engineer. However, for my application, I need to preprocess the encoder measurement (low-pass filter and corrections) before it goes to the PID controller.
Is this possible? and how can I approach such modification?
Hmm. May be possible, but from a control point of view the very last thing you should want is to is apply low-pass filtering (or any filtering, especially where that causes a lag) to the feedback.
What makes you think that you need such filtering?
You are right, lag will be introduced with the addition of a low-pass filter. I still did not research how to avoid the lag yet.
As for why I need to filter it, the encoder I am using is noisy and the application requires precise motion. Other things I need for preprocessing is correction for slippage and other disturbances.
ODrive does filtering on the board in a smarter way than basic low-pass but you’ll need to handle the slippage before it gets passed to the ODrive, and with minimal phase lag.
Can you share more details about your application? It sounds like you are focused on the mechanical controls and you have an encoder with noise and slippage that you want to correct before it gets used for position/velocity control. ODrive also needs the encoder for motor commutation - if your encoder slips, this is a no-go. It also sounds like you might not have the encoder mounted directly to the motor - is this the case?
My application basically is developing an accurate wheeled mobile robot. I want to account for certain disturbances before feeding the encoder values to the controller, such as the slippage of the wheels. Also, I might develop a probabilistic filter (such as Kalman filter) for simple accuracy improvement.
In short, I have the dynamic model of my system and I already have a simple nonlinear control based on the dynamic model I developed. And I still did not decide whether I implement my controller in ODrive directly or the main controller that communicates with ODrive (Arduino or RPi).
@Forenkazan - applying the correction to the feedback path is the wrong approach (in my professional opinion. )
Corrections for wheel slippage should be applied to the command input, NOT the feedback.
As @PJohnson pointed out, the feedback is used for commutation of the motor, so you cannot apply any “correction” that would cause misalignment of the stator’s electromagnetic field with respect to the rotor’s permanent magnets. The drive’s commutation algorithm needs to ensure they are always aligned, or the motor simply will not work.
When you said slippage, we thought you were talking about slippage of the encoder on the motor shaft, not wheel slippage.
As I say: apply any corrections you like to the command signal, but don’t touch the feedback, please.
To put it into system modelling terms: The ODrive is a motor controller, NOT a robot controller. You feed it a command signal for the motor.
If in fact, the motor is not the thing you really want to control (i.e. you want to control something connected to the motor, like the end-effector position of a robot arm, or the position and orientation of a rover) then you need to model that separately from the motor. You need to think about what movement you need from the motor itself in order to get the desired effect from your robot.
So if (for example) you have a gearbox with a gear ratio, stiffness and backlash, then you need to invert that function before you command the motor. (yes, I know backlash is not invertible - do your best! )
Similarly if you have slippage, and let’s say you have some vision system to track your movement, then you can command extra velocity from the wheels, or even some anti-slippage velocity profile, to correct for it.