Improvements derived from semestral work

Dobrý den,

zkusil jsem posbírat a uklidit skripty, které jsem v semestrálce použil.

JV

software/students/README.md

+# Active suspension simulation & control
+
+This set of scripts and models attempts to create a more faithful simulation
+than what the stock Quanser Simulink schema provides. It also contains some
+controllers that can be used for demonstration purposes.
+
+## How to use this
+
+1. Run the `design_controllers.m` script.
+2. Open the `simulator.slx` Simulink model. This model does not depend on
+   QUARC and can hopefully be opened in any Matlab version R2024a and newer.
+3. Select the controller to use through the manual switches in the bottom
+   left of the schema.
+4. Run the model.
+
+You can also run the provided demonstration controllers on the physical device
+in the lab. To do so, just open the `lab_device.slx` model instead of the
+`simulator.slx` one. To start up the physical model, follow the instructions
+in the top-level README of this repository.
+
+## Used controllers
+
+The demo contains three controllers:
+
+ - A LQR controller. This controller attempts to minimize a linear-quadratic
+   criterion. The weights are chosen such that the relative motion of the
+   upper and lower masses is penalized the most. Out of the three controllers,
+   this one behaves the best when deployed on the real device in the lab.
+ - A H-infinity controller. This controller uses the signal-based approach
+   to design a controller that minimizes the acceleration of the upper mass
+   and also some other metrics. This controller behaves slightly worse --
+   it is a bit too aggressive when trying to damp the upper mass oscillations,
+   leading to oscillations of the lower mass. However, it does work when
+   compared to the open-loop response.
+ - A lag controller. This controller was designed through the `sisotool` to
+   damp the system based on the accelerometer signal from the model.
+   It works fairly well. However, it has some overshoot and the return
+   from the over-shot position is kinda slow.
+
+## State space formats
+
+Two state space formats are used here:
+ - "internal"/"physical" states. This state space is what one would derive
+   through bond graphs or other means. The states are:
+   - `zs` = position of the upper mass wrt. its idle position.
+   - `dzs` = speed of the upper mass.
+   - `zus` = position of the lower mass wrt. its idle position.
+   - `dzus` = speed of the lower mass.
+   This state space is fairly intuitive and corresponds to what one would
+   see in the lab (road steps up -> both masses step up; the same holds for
+   the graphs).
+ - "observed"/"Quanser" states. This state space is slightly different and
+   contains these states:
+   - `zs-zus` = distance of the upper and lower masses wrt. its idle value.
+   - `dzs` = speed of the upper mass.
+   - `zus-zr` = distance of lowre mass and the road platform wrt. its idle value.
+   - `dzus` = speed of the lower mass.
+
+The "Quanser" state space might be more useful for controller design. Its advantage
+is that when the physical model reaches steady state, all states here should
+be zero. This is advantageous for LQR design: the task can then be
+formulated as a regulation task and not a tracking task.
+
+These state spaces *cannot* be converted one to another using a state-space
+similarity transformation. The issue is that the model with "observed" states
+cannot take road height `zr` as an input directly: inputs cannot directly set
+state values (e.g. `zus-zr`). Instead, it must have `dzr`, the derivative of road
+height, as an input; this input is then integrated via the `zus-zr` state.
+The "physical" state-space does not have this limitation, as `zr` only controls
+how the lower mass will accelerate (i.e. it feeds into the `dzus` state through
+a spring factor).
+
+## Matlab files
+
+ - `design_controllers.m` prepares the three controllers described above.
+   It also automatically runs the `load_simulator_constants.m` script
+ - `load_simulator_constants.m` contains the model physical constants for
+   `simulator.slx`.
+ - `simulator.slx` is a Simulink model for simulating the active suspension
+   when not in the lab.
+ - `lab_device.slx` is a Simulink model for running the controllers in the
+   lab. It is derived from the `software/quanser_updated/q_as_lqr.slx` model.
+ - `quanser_order2_filter.m` is a helper script for designing a low-pass filter.
+ - `get_suspension_linear_model.m` is a script that generates a linearized
+   Control System Toolbox state-space model of the active suspension. There
+   are various formats of the model available; see the documentation and
+   code inside.
+
+## Generic notes
+
+- The model constants were determined using scripts in the `/data/students` directory.
+- The H-infinity controller could be improved by using frequency-dependent weights.
+  Currently the weights are just static gains.
+- There are various places where friction can be modelled:
+  - Viscous friction parallel to springs (equivalent to a shock absorber in cars).
+  - Viscous friction in the bearings between masses and the base.
+  - Static friction in the bearings between the masses and the base.
+- The Quanser lab model only assumes the first type of friction.
+  This seemed unrealistic to me -- there is no shock absorber mounted on the
+  physical model in the lab. The Simulink model here uses only the last two
+  types of friction - I assume the bearings are where most of the losses are happening.
+- The way static friction is implemented in the simulation model is not ideal.
+  Currently, it is effectively just a signum function in negative feedback.
+  This breaks Simulink's step-size control. To work around this, a fixed-step
+  ODE4 solver is used with a 1 kHz sample rate. This might be improved
+  by implementing https://www.mathworks.com/help/simulink/slref/friction-model-with-hard-stops.html
+  here or choosing a different approach.