cklb / pymoskito Goto Github PK

Add a button to load pmr files.
If a file is loaded, delete all regime-files in dockarea "Regimes", create a new one with the settings of the loaded file and fill the dockarea "Properties" and "Data" with the corresponding datasets.
All functionalities stay active.

see attached file ...

Currently the only way the get rid of a plot dock is to double click its title-bar and close the resulting floating window.

When clicking on search page at the bottom of the docs, one is referred to an empty page.

The usage an work with the toolbox should be explained within a little tutorial.
It should start with the modelling of a simple system an its implementation, enriched with some formulas and code snippets from the related parts of the toolbox.
The next step would be an introduction to the GUI by simulating the freshly created system.
Furthermore, a simple control law can be derived and implemented to show the most basic components of the modular simulation loop.

Other sections would then focus on the simulation system in whole or parts like trajectory generation or observer design.
The result of the tutorial should be a complete example system that should also be added to the examples sub-package.

The introduction should have a lesson-like structure with little hints about the requirements to understand them.

Things that should be explained:

• What is the difference between the Solver and the Model?
• Why do the Model outputs do have a name and the Solver and Trajectory outputs only have numbers like .1, .2 etc.
• Why do strings in the property list do have to be entered with surrounding " "?
• How does the control loop look like?
• What does the ModelMixer do and what are its possibly settings?
• What are Post- and MetaProcessors and what do they do?

Check calculation of metrics in this class and refactor it to use the methods provided by the base class.

At the moment at lest the BallBeam example uses his own colors, the behavior should be consistent accross the examples.

This controller shows how a system can be linearized at a certain steady state.

If the results from the most current simulation do not provide results for a certain plot, not only clear it but also delete the tab widget.

These classes should use XYMetaproxessor as base class.

At the moment, all derived classes of SimulationModule lack a reference to their respective base classes. It should be added.

Since the handling of the visualization is not very intuitive, it could be a good idea to prevent the user from interacting with it.
every visualizer should have an option to enable or disable rotation.

When there is a syntax or runtime error in the simulation thread, the thread gets aborted (SIG_ABRT) and returns exit code 143.
This makes it very hard to find out what exactly went wrong. When running the python interpreter in gdb, the complete backtrace of the underlying exception can be seen. This information should also be available in the log of the main application to make the debugging process easier.
A possible solution would be to catch all exceptions in the simulation thread, exit graceully and forward them to the gui thread.

Either let the user select a custom width or get a reasonable setting from LaTeX.

At the moment, the return type specification caries heavily between the different modules.

Since vtk is a problematic dependancy on some systems, the vtk import could be made optional so that the application won't fail if it isn't present. The 3d result display would be disabled in this case.

If the given controller input string is not allowed, the program crashes.
Instead of Assertions, a ModleException or something similar should be thrown be a initializing SimulationModule and caught by the SimulationInterface

list of postprocessors on the left side is empty, if you lanch the postprocessor in two_pendulum_on_a_cart or ballbeam

The docs should be extended by a short derivation of the system dynamics, a sketch, references and some sentences about the problems that make it interesting for control theory.

Since the postprocessing has to now something about what is being done, the simulation interface is the wrong place to handle this task.

They have to be adapted to the new internal results structure and should make more use of base class methods for metric calculations.

Refactor SmoothTransition to provide transitions for a vector instead of a scalar entry. Create a new class for that.

The docs should be extended by a short derivation of the system dynamics, a sketch, references and some sentences about the problems that make it interesting for control theory.

Come up with a way to mimic a user interaction with the GUI and test some behaviors with it.
If possible, also build a test to randomly press all available buttons.

Since the car system is able to maneuver a set of serially attached carts backwards it would be nice to add the actual controller and show its performance.
Furthermore, the example's name and regime names should be updated

Todos:

• Rename parameters of CarModel._calc_output()

The following steps results in a crash of PyMoskito.

1. Simulate a random System
2. Save the result file with the shortcut "Ctrl+S"

When installing pymoskito from a checkout per setuptools the ressources directory is omited. This results in an error when starting the GUI.

Docs are completely missing and should contain a reference to the used scipy solvers.

For now a control and an observer error are calculated based on hard coded defaults. There should be a way to select what is being calculated

The delete shortcut always removes an entry from the regime list, even if the regime list has no focus.
This results in a quite non-intuitive behavior.

Since a lot has happened between the last minor release and the one to come, the changelog has to be updated.

The docs are still missing a well written introduction about what this toolbox is about, what it is able to do and most important: what not.

At the moment there is always a regime file called default, that should be renamed to default_regimes or something more meaningful.

Finish at least one meaningful metaprocessor for this example.

These generators used to create a big set of regimes used for the evaluation of e.g. parameter uncertanties.

Long term goal is to replace them with a regime creation wizard (#17)

Calculate the jacobians for all example systems to display their usage and add a test for the corresponding method.

If a Module offers tune-able settings like gains or physical parameters, it should make sure that these values cannot cause FloatingPointErrors like division by zero etc.

A more sophisticated check of the data type should be done on another level.

Furthermore, the pictures should be updated.

This error-prone method should be removed as it has been the source of a great amount of discontent in the development.

There are several sub-steps to approach this issue:

• Move this task somewhere else #19
• Provide ways to influence its behavior #20

Finish the test trunks after solving the problem #

The current property view that shows the simulation settings for each module does not scale very nicely.
It should be replaced by the one provided by pyqtgraph.

The current name does exactly say that this system describes a tandem pendulum on a moving cart.

The docs should be extended by a short derivation of the system dynamics and some sentences about the problems that make it interesting for control theory.

This wizard window would have the same functionalities as the old interactive regime generator scripts from the ballbeam example without the need to build a new script for every new usecase.

Instead of directly assembling the yaml code, the regime should be generated as python dictionary and then exported to yaml.

These modules are missing examples at the moment. The example models should be simple (PT1, PT2) and located in the resources module. That way they can also be used in the tests.

The docs should be extended by a short derivation of the system dynamics and some sentences about the problems that make it interesting for control theory.

To make the tests self-contained a way to generate a test data-set from within the test framework has to be found.