Skip to content

Conversation

@askuric
Copy link
Member

@askuric askuric commented Dec 23, 2025

So this is a PR that does two things:

  1. Does a big refactor of the FOCMotor code with the aim to simplify the BLDC, Stepper and HybridStepper motor codes
  2. Implements a more flexible autotuning from the Current PI Autotuning #426

Refactor

  • All the common functionalities moved to the FOCMotor class
    • Sensor alignement
    • Current sese alignment
    • Motion control
    • Torque control
    • Calibration ...
  • Only the truly different parts left in the BLDCMotor, StepperMotor, ...
    • Setting the phase voltages
    • init,enable,disable

Autotuning

  • Baiscally the code is more or less the same as in Current PI Autotuning #426
  • But it is more flexible and allows to be called from the Commander - ex MFC100 for the bandwith of 100Hz
  • It can be also called in the setup. - ex motor.tuneCurrentController(100)
  • It will either use the motor parameters
    • from the constructor or
    • if the current sense is available and no params are provided it will calll motor.characteriseMotor

@askuric askuric mentioned this pull request Jan 7, 2026
@runger1101001
Copy link
Member

This seems like a good refactoring to me...

One thing to maybe talk about is to make the PID and LPF classes exchangeable instead of hard-coded, and then instead of combining fixed and variable sample times into one class, to make separate classes and therefore also open the possibility to have alternative implementations.

@askuric
Copy link
Member Author

askuric commented Jan 9, 2026

I like the idea. Do you have an idea on how to do it though?
linkLPF mothod or something like that?

@runger1101001
Copy link
Member

runger1101001 commented Jan 12, 2026

I like the idea. Do you have an idea on how to do it though?
linkLPF mothod or something like that?

Good question what the best way to do it is.

At the moment the LPF and PIDs are fields of FOCMotor. They can't be changed because they are direct members of the class, and also because their methods are not virtual and can't be overloaded.

One way would be to use the same paradigm as for Driver and CurrentSense. Change them to be pointer types, and make their functions virtual for overloading.

Another way, probably with better runtime performance would be to use templates. In general I was wondering if introducing templates in some places would not be a better approach altogether, but this would be a bigger refactoring...

template<typename LPF, typename PID> FOCMotorT {
...
    PID PID_current_q{DEF_PID_CURR_P,DEF_PID_CURR_I,DEF_PID_CURR_D,DEF_PID_CURR_RAMP, DEF_POWER_SUPPLY};//!< parameter determining the q current PID config
    PID PID_current_d{DEF_PID_CURR_P,DEF_PID_CURR_I,DEF_PID_CURR_D,DEF_PID_CURR_RAMP, DEF_POWER_SUPPLY};//!< parameter determining the d current PID config
    LPF LPF_current_q{DEF_CURR_FILTER_Tf};//!<  parameter determining the current Low pass filter configuration 
    LPF LPF_current_d{DEF_CURR_FILTER_Tf};//!<  parameter determining the current Low pass filter configuration 
    PID PID_velocity{DEF_PID_VEL_P,DEF_PID_VEL_I,DEF_PID_VEL_D,DEF_PID_VEL_RAMP,DEF_PID_VEL_LIMIT};//!< parameter determining the velocity PID configuration
    PID P_angle{DEF_P_ANGLE_P,0,0,0,DEF_VEL_LIM};	//!< parameter determining the position PID configuration 
    LPF LPF_velocity{DEF_VEL_FILTER_Tf};//!<  parameter determining the velocity Low pass filter configuration 
    LPF LPF_angle{0.0};//!<  parameter determining the angle low pass filter configuration 
...
};

typedef FOCMotorT<LowPassFiler,PIDController> FOCMotor;  // standard version instantiated

then users could make their own, by writing a MyPIDController class fitting the PID template:

typedef FOCMotorT<LowPassFiler, MyPIDController> MyFOCMotor;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants