Extend the SpeedLoad options

[upb-lea]

Extend the SpeedLoad options

[GitPascalP]

Is the speed, when given by the ConstantSpeedLoad, a kind of reference/ target value, which should be achieved by the controlled current?
Should therefore the speed have a similar behavior as the ReferenceGenerators?

[max-schenke]

Is the speed, when given by the ConstantSpeedLoad, a kind of reference/ target value, which should be achieved by the controlled current?

The ConstantSpeedLoad is meant for a scenario where the speed is dictated by external means. This could e.g. be the case in a power plant, where speed is determined by control of combustion processes or turbines, and the control of the electric motor / generator focuses more (or entirely) on the electrical behavior.

So, in this scenario speed is an external signal. However, it is not the same as a reference!
This scenario implies that the speed as given by the ConstantSpeedLoad is "physically present" from the very beginning. This means that the speed state of the motor has been fixed and can not be changed.

Should therefore the speed have a similar behavior as the ReferenceGenerators?

Of course it is possible that our external "speed source" has changing speed. To simulate this case, it would be quite useful to apply the funnction generators we already have. However, this should then be implemented in a different class or after renaming the class.
(It would be very confusing to apply the "ConstantSpeedLoad" and still get a non-constant speed.) You could e.g. solve this by renaming the class to something like "ExternalSpeedLoad" and allow to parameterize this class to either output constant speed or changing speed.

[GitPascalP]

Added new class ExternalSpeedLoad in mechanical_loads.py. You can define a external Speedprofile for the load by handing a functionobject to the class. The functionobject can be for example a numpy function or a self defined lambda function.
Additional properties to the speedprofile (like amplitude, ...)can be given to the class as additional paramters ( **kwargs).

Eventually additional testscripts have to be added soon.

[praneeth-b]

internal review done. comments fixed by @GitPascalP .
Moving task to 'done'

[GitPascalP]

I checked the accuracy of the target and system value for the speed profile. I don't know if the frequencies I tried are similar to a real use case, but I think it reveals the most important things.

My target is the speed_profile(t + tau) calculated directly. The Systemvalue comes from the step() - Funktion. The Error between the signals goes up for higher frequencies and is a little bit dependent on the initial value (the system needs a moment to get to the actual profile). For a sine, the errors look similar.

[GitPascalP]

one additional remark:
i pushed a new branch (issue_#9_and_30), where connected my issues, as it was possible. So maybe only the one branch should be checked, when both issues are in the done column.

[max-schenke]

Omega is normalized within this plot, I suppose?
I think one could interprete it better if it was not.
How about negative speed?

[GitPascalP]

Yes it is normalized on the plot. Now unnormalized and with negative speed.

[max-schenke]

Thank you for these diagrams. As it does not look as accurate as I would have wished, I took a look at the code and I think I found a minor bug (in class ExternalSpeedLoad):

If I am not mistaken it should be
return "...(1 / self._tau)..."
instead of
return "...(self.j_total / self._tau)..."

Could you please try this?

---

Eventually additional testscripts have to be added soon.

Maybe this should also be added to the next sprint phase if it has not been covered yet.

[GitPascalP]

I think the result should look like this, or did I miss something?

The result looks quite idealized:

I think it is a matter of interpretation if the system follows the profile directly or the load follows the profile with inertia.

[max-schenke]

Has this diagram now been produced after my correction idea has been implemented?
Looks way better. The speed seems to follow the desired profile more precisely.

Here is my short derivation to the problem:
Speed_Profile_Torque_Estimation.pdf

The mechanical_ode is supposed to return omega_dot, which has unit 1/s^2. With j_total put into the equation the units do not fit.

[GitPascalP]

The Diagram is from after your correction. I think there was a wrong thought on my side. The mechanical_ode function should give the differential of the state back (omega dot) and not T. For some reasons I forgot this last step

[max-schenke]

Please execute another round of testcases like for these diagrams.
This time, plot the speed error (omega_target-omega_system).

Please include tests for all available solvers:
https://upb-lea.github.io/gym-electric-motor/parts/physical_systems/ode_solvers/ode_solver.html?highlight=solvers

[GitPascalP]

Here are the error plots.
For every plot, I used a new environment, initialized with a different solver.
(the second plot zoomed in the peak from timestep [600, 800]

[wallscheid]

I believe the results are already looking promissing, but I would like to really check a little bit deeper:

• For which of the above speed profiles are these error plots, 16 Hz? And could please provide an estimate of the domega/dt during the linear transients during these speed profiles.
• Considering an extreme scenario that an electric motor is stopped from max. speed to zero speed within a gear box due to the clutch usage, I would expect angular mech. speed gradients of up to 15000 1/s^2. If the above baseline simulations' gradients are much less dynamic, could you please adjust your simulation according to my extreme case scenario and report errors on this basis.

[GitPascalP]

the plots before are plotted with max 12 Hz. With 16 Hz no big difference occurred (with signals like triangle). For the extreme Motorstop, I used a normal sawtooth signal and used the mechanical ode output (or the direct calculation of the state difference divided by tau). Gradient and error plot are following. The error is ,for the scipy solvers, higher and the gradient gets big as you proposed.

[wallscheid]

I believe the accuarcy is sufficient - of course the error is large whenver there is really a jump within the speed profile, but that has to be accepted due to the used implementation way. Error is also not increasing over time, that's good.

However, please add a specific in-line comment and/or doc string information to the class pointing out that the the usage of the simple Euler discretization is only an approximation and that small differences between the inserted and the actual speed profile may occur.

From my side the core functionality of the code increment is achieved and the auxillary stuff (unit tests, docu,...) can be quickly finalized before a pull request is executed.

[max-schenke]

Done