Week 5

Starting Phase 2 …. Hello everyone, hope this blog finds you well.

Last week I could get my 2nd Pull Request merged in. Alongside I also gave a brief introduction about phase 2. In this phase I’ll be making some improvements in the codebase like adding more useful methods to the TransferFunction and TransferFunctionMatrix classes and enhancing the design to improve user-friendliness.

Aim :

My purpose this week was to investigate the control/lti.py file and find potential areas of improvement. Once I completed an entire sluething I wanted to raise issues, so that we can discuss upon them as a community. Eventually I’ll be fixing those issues in the upcoming week as this week I patiently await to get clarity on the expected results.

These are the issues I have opened up. Kindly comment on them if you are interested in the project !

1. Refactoring Control Plots: Replace Numerical methods with Algebraic methods as much as possible
2. How should division of Transfer Functions be handled
3. How should subs() be handled for Transfer Functions
4. Restrict Inputs to only valid Transfer Functions

Work : Let us go through the Issues in brief.

1. Refactoring Control Plots:
   This issue addresses this comment. Right now all plots in the control module use numerical methods from Numpy. We need to replace the current methods with algebraic methods from SymPy under GSOC 1.4 work.

2. Division of Transfer Functions:
   The / operator does not work for transfer functions as of now.

   Relevant control algebra packages handle it as follows:

   MATLAB

   >> tf1 = tf([1],[1 1])
   >> tf2 = tf([2],[1 1])
   >> tf = tf1/tf2
      
   tf =
       
      s + 1
     -------
     2 s + 2
   

   Python-control

   >>> tf1 = control.TransferFunction([1],[1,1])
   >>> tf2 = control.TransferFunction([2],[1,1])
   >>> print(tf1/tf2)
      
    s + 1
   -------
   2 s + 2
   

3. Substitution of Transfer Functions:
   Right now, .subs() does not work with TransferFunction and TransferFunction Matrix class.

   Some control packages support the direct substitution:

   MATLAB

   >> t = tf([1 3],[1 1 1 1])
   >> value = evalfr(t, 2);
   >> value
       0.3333
   

   Python-control

   >>> tf = control.TransferFunction([1,3], [1,1,1,1])
   >>> substituted_tf = control.evalfr(tf, 2)               # Same name, a coincidence :)
   >>> substituted_tf
   (0.3333333333333333+0j)
   

4. Check validity of Transfer Functions:
   Right now the TransferFunction class allows any expression to be input as a transfer function.

   I think we could do it like MATLAB (only allow time delay when a delay argument is given) -

   >> G = tf([1],[1 10],'InputDelay',2.1)
      
   G =
                     1
     exp(-2.1*s) * ------
                   s + 10
   

   Otherwise catch if not polynomial with something like this -

   +        if (num.is_polynomial(var) is not True or den.is_polynomial(var) is not True):
   +            raise TypeError("Numerator and Denominator of TransferFunction must be a polynomial")
   

Future Work : In this upcoming week I would be opening up pull requests to address the issues I have opened this week. It is crutial to discuss ideas on these issues, so that I have clarity on my future Pull Requests. A challenge which still exists is the completion of the GSOC 1.2 Pull Request regarding the Root Locus plot.