Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finish implementation of control synthesis for regularized discrete systems with uncertainty #43

Open
pgagarinov opened this issue Dec 1, 2015 · 3 comments
Assignees

Comments

@pgagarinov
Copy link
Member

Deadline: end of the semester

Existing implementation of control synthesis for discrete systems in issue_73_alim_komarov is implemented for the systems without uncertainty
and covered with tests that can be run via elltool.control.test.run_disc_tests. All tests basically check that a point that is within a solvability
domain is driven to a terminal set. A number of different systems is tested, each specified via a separate pair of xml file that stores a system configuration.
All system configurations are stored in products+elltool+control+test+conf\confrepo_templates and products+elltool+control+test+sysdef+conf\confrepo_templates where a system parameters are stored in the second folder while other parameters like a set of good directions, time interval etc are stored in the first folder. Configurations from the first folder reference configurations from the second folder via
systemDefinitionConfName parameter of configuration. The tests can be run either for all configurations or for a subset of configurations (see a help header for elltool.control.test.run_disc_tests for examples).

Not all implemented tests pass, particularly

a) Tests for configurations
demo3thirdTest
uosc8
ltisys
x2dtest

doesn't pass because of error "undefined function or variable AtDefCMat". This problem needs to be investigated and fixed.

b) Configuration demo3fourthTest doesn't pass because of error "timeVec is expected to contain integer values".

This problem also needs to be investigated and fixed.

c) Tests for configuration osc8 doesn't pass because of mismatch of matrix dimensions, this also needs to be fixed.

d) Some other tests doesn't pass because a system trajectory doesn't end up exactly in the terminal set.

There are two reasons for these problems:

  1. Programmatic errors in the implementation of control synthesis for systems without uncertainty
  2. Not implemented control synthesis for regularized systems with uncertainty. Some of the configurations include both uncertainty and regularization enabled. The regularization parameters are
    specified in regularizationProps section of configuration:
        <regularizationProps type="struct" >
            <isEnabled type="boolean" >0</isEnabled>
           <isJustCheck type="boolean" >0</isJustCheck>
                <regTol type="double" >1e-05</regTol>
        </regularizationProps>

where isEnabled=true and isJustCheck means that reachability tube is dynamically regularized with epsilon=regTol in formula 36 from
https://drive.google.com/open?id=0B5OqL4IVOIC8NTZCZmpBVTU3ODA

All this means that control constraint is no longer E(p(t),P(t)) but E(p(t),P(t)+M(t)) where M(t) is stored in MArray field of ellipsoidal tube returned
by getEllTubeRel method of elltool.reach.ReachDiscrete class.

For additional information about control synthesis for discrete systems under uncertainty please refer to
https://drive.google.com/open?id=0B5OqL4IVOIC8VzdaQzR3LVZ0ZDg

Here is what you need to do step by step

  1. Read https://drive.google.com/open?id=0B5OqL4IVOIC8VzdaQzR3LVZ0ZDg
  2. In parallel with 1) - study
    a) existing implementation of control synthesis for discrete systems in package elltool.control.
    b) tests for control synthesis launched via elltool.control.test.run_disc_tests. You need to understand how tests work and how to run tests for a specific system.
  3. Compare tests for discrete systems (elltool.control.test.run_disc_tests) and continuous systems (elltool.control.test.run_cont_tests). You will see that 4th column in
    confCMat for continous systems is not empty and empty for discrete systems. This column contains a list of external points that are not expected to be driven by control
    synthesis into a terminal set. The thing is that these points are not defined in the tests for discrete systems and you need to add such points for each configuration. External (outer) points are the points that are located outside of solvability domain and are expected to stay outside of solvability domain for all times. Since exact reachability domain
    is not known we can use a simple rule to generate points that are guaranteed to be outer: we just take a good direction l(t) at time t, for a point of contact between ellipsoidal
    approximation E(t) and exact X(t) along l(t) i.e. a maximizer x^{}(t) such that (l(t),x^{}(t)) rho(l(t)|E(t)) and then use x^{_}(t)+eps_l(t) as an outer point where eps is small.
    You should generate at least 3 points for each cofiguration for different l_i=l(t_s) where s usually equals t_0 (depends on configuration). At the end of this step there should
    be at least 3 outer points defined for each configuration in elltool.control.test.run_disc_tests.
  4. fix problems a,b,c,d listed above for those configurations (systems) that contain no uncertainty. After this step all tests for systems without uncertainty should pass.
  5. Study https://drive.google.com/open?id=0B5OqL4IVOIC8NTZCZmpBVTU3ODA paying a special attention to a regularization schema and the way M(t) is used in ellipsoidal approximation schema. Then modify control synthesis for discrete systems in elltool.control by using E(p(t),P(t)+M(t)) as a control constraint instead of just E(p(t),P(t)) where M(t) is stored in MArray field of ellipsoidal tube returned by getEllTubeRel method of elltool.reach.ReachDiscrete class. After this modification make sure that tests for systems with uncertainty pass.
@ruslan-malsagov
Copy link

Peter, good evening.

Could you please tell me if I'd better work out this issue in the branch issue_73_alim_komarov or I should create my own new branch?

Regards,
Ruslan

@pgagarinov
Copy link
Member Author

You should branch from issue_73_alim_komarov and create your own branch. Please be in touch with Dmitry and rebase periodically against his branch in case he fixes something important for you. Also, rebasing against his changes will protect you from merging conflicts when you both try to merge into master.

@ruslan-malsagov
Copy link

Thanks a lot for your response, got it.

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

No branches or pull requests

2 participants