Dear All,
Lately, an idea of a widely needed library in the field of systems and control was initiated. I am student at Eindhoven University of Technology of Systems & Control master's track and this is a part of my graduation project. I would like to get you familiar with the idea my professors and I had, so in case you are interested in the topic, you can comment and contribute. Additionally, this was also discussed with the group from KU Leuven working on OROCOS, especially BFL library.
The starting idea is to make a stand alone library in C++, which consists of digital filters as components (basically discrete transfer function of standard control components like leadlag, PID, low-pass, etc). The component oriented programming, similar to OROCOS, is chosen. Each component should have initialize, update and finalize functionality. Configuration should also be enabled. Soon, I will have an example, which I will post here.
The next step is to make a kind of composition, that would enable (control) block diagrams (Simulink-like). This includes structure of tree or DAG type, which would be able to execute coordination of the components, i.e. configure them, define connections and communication and take care of sequence of updates of each one of them (and would make an overview and visualization of running components feasible). A simple FSM machine is possible here. If this is done properly, combination of this kind of component compositions should be possible as well (subsystems feature).
On the other side, this is just a part and all the requirements of such a library are not firmly set yet, so any suggestions in that context would be appreciated too.
To sum up, having any questions or suggestions, please don't hesitate to reply to this post.
Kind regards, Boris
Systems & Control Library
On Wed, 25 May 2011, b [dot] mrkajic [..] ... wrote:
> Lately, an idea of a widely needed library in the field of systems and
> control was initiated. I am student at Eindhoven University of Technology
> of Systems & Control master's track and this is a part of my graduation
> project. I would like to get you familiar with the idea my professors and
> I had, so in case you are interested in the topic, you can comment and
> contribute. Additionally, this was also discussed with the group from KU
> Leuven working on OROCOS, especially BFL library.
Thanks for the initiative! Let me add my (lot more then) "two cents" on
this topic.
Within the BRICS and Rosetta project consortiums, there are also a couple
of people that want to start/use a similar "SCL" (Systems and Control
Library). (And Klas Nilsson of Lund (and Rosetta) has some very sharp ideas
about the topic; hopefully he is able to share them with us, non-Java
earthlings, too...:-) So, I am forwarding this message to the relevant
BRICS and Rosetta mailinglists (since I am not sure they are on this Orocos
list). I do suggest that further discussions take place on "Orocos dev"
(which I think is a more appropriate place then "Orocos users": after all,
there is not really something to use already :-)). So, I am also forwarding
to orocos-dev.
> The starting idea is to make a stand alone library in C++, which consists
> of digital filters as components (basically discrete transfer function of
> standard control components like leadlag, PID, low-pass, etc). The
> component oriented programming, similar to OROCOS, is chosen. Each
> component should have initialize, update and finalize functionality.
The motivation for this is that it reflects the fact that the component in
which SCL functionality can be deployed alwasy(?) have corresponding "life
cycle states".
> Configuration should also be enabled. Soon, I will have an example, which
> I will post here.
Good :-)
> The next step is to make a kind of composition, that would enable
> (control) block diagrams (Simulink-like). This includes structure of tree
> or DAG type, which would be able to execute coordination of the
> components, i.e. configure them, define connections and communication and
> take care of sequence of updates of each one of them (and would make an
> overview and visualization of running components feasible). A simple FSM
> machine is possible here. If this is done properly, combination of this
> kind of component compositions should be possible as well (subsystems
> feature).
Let me try to explain my ideas on the suggestions in the paragraph above,
structured according to the relevant "5C" aspects:
- Connection: control block diagrams are _graphs_ in general (and not trees
nor DAGs), so we must come up with a data structure that represents this.
(More about that below).
Control diagrams typically also have a hierarchical decomposition in that
one control block can consists of a complete control block diagram in
itself. Hence, the concept of "composite" control block must be
introduced as a "first class citizen".
(Orocos itself misses this "composite" component concept, at least in a
formal way; many (good) developers already use the concept implicitly.)
- Computation: control block diagrams have one generic behaviour, i.e., one
computes the whole diagram every "sample time". However, one has to come
up with an _explicit_ "partial ordering" in which to run the functions in
each of the blocks in the diagram (= calling the "update hook" of that
block. A Directed Acyclic Graph (DAG)
<http://en.wikipedia.org/wiki/Directed_acyclic_graph>
(or even better, a (poly)tree
<http://en.wikipedia.org/wiki/Polytree>)
are appropriate data structures to encode such a partial ordering. So, we
have to come up with an appropriate data structure for that.
(More about that below.)
- Configuration: each individual control block component must be
appropriately initialized (and "finalized", especially when its output is
being used to drive a motor!), and this configuration takes place in the
"finalize" state of the Coordination state machine of the whole control
diagram (see below). Each "composite" control block's "initialize" (and
"finalize", and "update") function should know what to do with the
corresponding initialization/finalization/updating of the control diagram
that it encapsulates; in principle, this should be rather straightforward
because the DAG datastructures can be nested hierarchically (I think...)
In addition, there can be runtime configuration of
some of the "gains" in some of the blocks, which would be done in the
"update" state of the composite control block, but via the configuration
interfaces of the individual control blocks.
- Coordination: for the SCL _library_ there should be _no_ state machine
functionality, since that is the responsibility of the _component_ in
which the functionality is being computed. Of course, it would be nice if
we could provide the SCL functionality in an Orocos/RTT compatible
component; and that one will have a Coordination state machine. There are
plenty of examples for this in the KDL and BFL libraries; also there, the
separation between the functionality and the "component deployment" has
been nicely achieved. But the 'executable graph' idea was not yet there
when these libraries were conceived, so the both have their own, partial,
implicit, implementation of that idea. Food for refactoring :-)
- Communication: each individual control block will be designed in a
"component based way", that is, the "update" function reads the input
"Ports" (including configuration, possibly), does its computations, and
then writes the "output" Ports. This design allows usage in the following
relevant use cases:
- fully "collocated" deployment, that is, everything takes place in one
single thread, without any "communication middleware", so:
- each Connection is just a shared variable;
- each Port access is a read/write to that variable
- the Coordination of the computational scheduling is done via the
Directed Acyclic Graph data stucture.
- "multi-threaded" deployment, that is, some component run in one thread,
others in another thread, but still in the same address space. Then
nothing changes in the _functions_, but the RTT component framework comes
into play, and more in particular, its "lock-free data ports", and a
Coordinator for the whole system to take care of the coordination of the
initializations and finalizations.
- "multi-process" deployment: similar as multithreaded, but now with the
RTT mqueues.
- "multi-platform" deployment: again similar, but now a non-Orocos-native
Communication middleware has to be used.
About the graph, tree, DAG, polytree data structures: these are much more
generally useful than the SCL context, so we should make a separate library
for them. I have a Master student working on this, and we call it
"executable graphs", for the time being. Roughly said, he has made a fully
"5C comptabile" design for graph structures, including the computational
scheduling of a graph (using a graph in itself).
> On the other side, this is just a part and all the requirements of such a
> library are not firmly set yet, so any suggestions in that context would
> be appreciated too.
>
> To sum up, having any questions or suggestions, please don't hesitate to
> reply to this post.
I am considering doing exactly that :-)
Thanks for taking the initiative. I was hoping for someone to do this since
"Day one" of Orocos, which is ten years ago, this September :-)
> Kind regards,
> Boris
Herman
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
Systems & Control Library
> - the headers of your files should contain licensing information, and
> references to inspiration, litterature, prior art, people that have
> provided useful inputs,...
> It would also be nice to mention your institute, to give it the credit it
> deserves from providing your education :-)
I will do that, only first I need to check with my professors what is the standard we use at our institution and the header template we have.
> - "/// Definition of needed constants
> #define filter_order 1
> #define PI 3.14159265358979"
> The latter is already available in math.h, as M_PI, isn't it?
> The former is a configuration parameter, whose setting/getting should be
> accessible via a configuration interface.
I have altered the latter one, but for the first constant, I have only made it a const var, but kept it non-configurable, since if this could be changed, the (lead/lag) filter I have designed would change (it is supposed to be 1st order filter). All would have to change if it is made, e.g. 2nd order filter.
>- "switch (method){
> case EulerBackward: "
> Maybe it is more appropriate to make a virtual class ("abstract
> interface"), with one single sub-class for each particular choice of
> integrator?
> That would make things much simpler to aggregate, and much clearer from a
> name giving point of view. You could take inspiration from how it is done
> in KDL, where different forward and inverse kinematics solvers are
> provided, as implementations of the same abstract interface.
I will reconsider this, but for now, I will leave it as a configuration parameter. I can imagine that it is not intended to be changed on the fly, but again,if I think of a simulink-like control diagram, maybe one would like to change just in block configuration discretization method and not need to change the whole block for that purpose.
> the doxygen documentation does not display as an HTML file in my Firefox
> browser; I just get to see the HTML "source code".
I can open it from my hard drive with no problems, could be svn link that makes it open as source always or similar. Anyways, one can always generate it himself, so I guess this is not a huge issue.
> - your "Polynomials" library uses operator overloading; are you sure that
> will never lead to online memory allocation? That kills realtime
> behaviour, so not acceptable as an Orocos sub-library :-)
If I understood the problem correctly, I changed the code. Or does operator overloading by definition leads to memory allocation?
The rest of things, I have tried to make as it was suggested. Again, I share the link, so you can take a look at the code. The same link holds (https://amigo.wtb.tue.nl/svn/amigo/code/tue-ros-pkg/dev/SCL/)
Regards,
Boris
Systems & Control Library
On Thu May 26 2011, Herman.Bruyninckx at mech.kuleuven.be wrote:
> Let me add my (lot more then) "two cents" on this topic.
Thank you for the comprehensive explanation, it truly makes the idea about SCL a lot more clear.
Furthermore, I want to share with you an example of a part of SCL. My focus is on creating a digital filter part and the following is a fraction of it. Namely, a DLeadLag filter class represents one of the standardly used filters (among others like low-pass, PID, etc.) and it should be representative segment of the SCL.
Link to it:
https://amigo.wtb.tue.nl/svn/amigo/code/tue-ros-pkg/dev/SCL/DFILTERS/
I would appreciate any comments or suggestions, primarily regarding the structure and wrt the 5Cs aspects.
Regards,
Boris
Systems & Control Library
On Wed, 1 Jun 2011, Mrkajic, B. wrote:
> On Thu May 26 2011, Herman.Bruyninckx at mech.kuleuven.be wrote:
>> Let me add my (lot more then) "two cents" on this topic.
>
> Thank you for the comprehensive explanation, it truly makes the idea about SCL a lot more clear.
>
>
> Furthermore, I want to share with you an example of a part of SCL. My focus is on creating a digital filter part and the following is a fraction of it. Namely, a DLeadLag filter class represents one of the standardly used filters (among others like low-pass, PID, etc.) and it should be representative segment of the SCL.
>
> Link to it:
>
> https://amigo.wtb.tue.nl/svn/amigo/code/tue-ros-pkg/dev/SCL/DFILTERS/
Thanks for the efforts!
> I would appreciate any comments or suggestions, primarily regarding the
> structure and wrt the 5Cs aspects.
- the headers of your files should contain licensing information, and
references to inspiration, litterature, prior art, people that have
provided useful inputs,...
It would also be nice to mention your institute, to give it the credit it
deserves from providing your education :-)
- "The DLeadLag class represents a digital leadlag filter and it is
a part of Systems & Control Library (section Digitial Filters)."
This is not very useful information, since this much is already clear from the
name of the file and the context of the library.
What is missing is an explanation of the filter's behaviour; described
explicitly, or by refering to accessible documentation, such as e.g.
<http://en.wikipedia.org/wiki/Lead%E2%80%93lag_compensator>
or
<http://en.wikibooks.org/wiki/Control_Systems/Controllers_and_Compensators>
- "#include "../Polynomial/Polynomial.hpp"
It would be nice if you could briefly document for what reasons exactly
this dependency exist. In other words, what data structures and/or
functionality do you need from that library?
- "/// Definition of needed constants
#define filter_order 1
#define PI 3.14159265358979"
The latter is already available in math.h, as M_PI, isn't it?
The former is a configuration parameter, whose setting/getting should be
accessible via a configuration interface.
- "enum DiscretizationMethod {
EulerBackward = 1,
EulerForward = 2,
Tustin = 3,
TustinPrewarp = 4,
ZOH = 5,
ZeroPoleMatch = 6
};"
These choices, their influence, and their motivation should be part of
the above-mentioned documentation. And the choices should be part of a
configuration interface. Most probably integrated with a state machine
for the functionality, since switching from one integration rule to another
should not happen on the fly, I guess...
And using enums is not so readable; for example, it leads to code like
the following:
'if (method == 4){'
and that's asking for (human) errors...
- "if (zero_freq == 0 || pole_freq == 0 || Ts == 0)"
Since these variables are doubles, they will almost never be exactly
zero. Wouldn't it make sense to have a (configurable!) "epsilon" dead
zone around zero?
- "switch (method){
case EulerBackward: "
Maybe it is more appropriate to make a virtual class ("abstract
interface"), with one single sub-class for each particular choice of
integrator?
That would make things much simpler to aggregate, and much clearer from a
name giving point of view. You could take inspiration from how it is done
in KDL, where different forward and inverse kinematics solvers are
provided, as implementations of the same abstract interface.
- I read function names like "c2d" that are too cryptic and confusing.
Don't be afraid to type some more characters while trying to be
unambiguous and complete in name giving of functions :-)
And the implementation of the c2d function requires more extensive
documentation that the non-existing variant that you have now :-)
- the "normalize" function can currently do a "divide by zero"...
- "// Normalization
normalize(aD, bD);"
The comments are not really saying more than the function name :-)
It _would_ make sense to comment more, e.g., by documentation why and how
the normalization is needed or is being done. But that documentation should
be given with the implementation of the "normalize" function.
Anyway, "normalize" is a too generic name; please choose a much more
concrete name, that unambiguously represent the kind of normalization that
is being performed. Again, don't be afraid to use longer names: the
software is going to be used in large-scale robot and other control
systems, in which many other "normalizations" will appear.
Same remarks for "save", ...
A minimum "moniker"
<http://en.wikipedia.org/wiki/Moniker>
to use could be "SCL_...".
- do your "initialize()", "update()" and "finalize()" functions have the
same meaning as their counterparts in Orocos/RTT's coordination state
machine? If so, that could be mentioned explicitly. (Although I think
that you do not depend on that RTT meaning, do you? Which is fine!)
- the doxygen documentation does not display as an HTML file in my Firefox
browser; I just get to see the HTML "source code".
- your "Polynomials" library uses operator overloading; are you sure that
will never lead to online memory allocation? That kills realtime
behaviour, so not acceptable as an Orocos sub-library :-)
>
> Regards,
> Boris
Herman
Systems & Control Library
On 02/06/11 20:38, Herman Bruyninckx wrote:
> - "/// Definition of needed constants
> #define filter_order 1
> #define PI 3.14159265358979"
> The latter is already available in math.h, as M_PI, isn't it?
> The former is a configuration parameter, whose setting/getting should be
> accessible via a configuration interface.
For type safety, #define should not be used. Use consts. e.g.:
const unsigned int filter_order 1
const double PI 3.14159265358979
(Although in this specific case, as Herman says, M_PI is already
available and the other value may be better as a configurable parameter
- you should avoid, where possible, assuming your users' needs too
specifically.)
http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.7
> - "enum DiscretizationMethod {
> EulerBackward = 1,
> EulerForward = 2,
> Tustin = 3,
> TustinPrewarp = 4,
> ZOH = 5,
> ZeroPoleMatch = 6
> };"
> These choices, their influence, and their motivation should be part of
> the above-mentioned documentation. And the choices should be part of a
> configuration interface. Most probably integrated with a state machine
> for the functionality, since switching from one integration rule to another
> should not happen on the fly, I guess...
> And using enums is not so readable; for example, it leads to code like
> the following:
> 'if (method == 4){'
> and that's asking for (human) errors...
As I understand it, using an enum is the preferred choice, because they
give type safety (at least in C++). You cannot simply interchange them
with an integer.
http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.19
Geoff
Systems & Control Library
On Wed, 25 May 2011, b [dot] mrkajic [..] ... wrote:
> Lately, an idea of a widely needed library in the field of systems and
> control was initiated. I am student at Eindhoven University of Technology
> of Systems & Control master's track and this is a part of my graduation
> project. I would like to get you familiar with the idea my professors and
> I had, so in case you are interested in the topic, you can comment and
> contribute. Additionally, this was also discussed with the group from KU
> Leuven working on OROCOS, especially BFL library.
Thanks for the initiative! Let me add my (lot more then) "two cents" on
this topic.
Within the BRICS and Rosetta project consortiums, there are also a couple
of people that want to start/use a similar "SCL" (Systems and Control
Library). (And Klas Nilsson of Lund (and Rosetta) has some very sharp ideas
about the topic; hopefully he is able to share them with us, non-Java
earthlings, too...:-) So, I am forwarding this message to the relevant
BRICS and Rosetta mailinglists (since I am not sure they are on this Orocos
list). I do suggest that further discussions take place on "Orocos dev"
(which I think is a more appropriate place then "Orocos users": after all,
there is not really something to use already :-)). So, I am also forwarding
to orocos-dev.
> The starting idea is to make a stand alone library in C++, which consists
> of digital filters as components (basically discrete transfer function of
> standard control components like leadlag, PID, low-pass, etc). The
> component oriented programming, similar to OROCOS, is chosen. Each
> component should have initialize, update and finalize functionality.
The motivation for this is that it reflects the fact that the component in
which SCL functionality can be deployed alwasy(?) have corresponding "life
cycle states".
> Configuration should also be enabled. Soon, I will have an example, which
> I will post here.
Good :-)
> The next step is to make a kind of composition, that would enable
> (control) block diagrams (Simulink-like). This includes structure of tree
> or DAG type, which would be able to execute coordination of the
> components, i.e. configure them, define connections and communication and
> take care of sequence of updates of each one of them (and would make an
> overview and visualization of running components feasible). A simple FSM
> machine is possible here. If this is done properly, combination of this
> kind of component compositions should be possible as well (subsystems
> feature).
Let me try to explain my ideas on the suggestions in the paragraph above,
structured according to the relevant "5C" aspects:
- Connection: control block diagrams are _graphs_ in general (and not trees
nor DAGs), so we must come up with a data structure that represents this.
(More about that below).
Control diagrams typically also have a hierarchical decomposition in that
one control block can consists of a complete control block diagram in
itself. Hence, the concept of "composite" control block must be
introduced as a "first class citizen".
(Orocos itself misses this "composite" component concept, at least in a
formal way; many (good) developers already use the concept implicitly.)
- Computation: control block diagrams have one generic behaviour, i.e., one
computes the whole diagram every "sample time". However, one has to come
up with an _explicit_ "partial ordering" in which to run the functions in
each of the blocks in the diagram (= calling the "update hook" of that
block. A Directed Acyclic Graph (DAG)
<http://en.wikipedia.org/wiki/Directed_acyclic_graph>
(or even better, a (poly)tree
<http://en.wikipedia.org/wiki/Polytree>)
are appropriate data structures to encode such a partial ordering. So, we
have to come up with an appropriate data structure for that.
(More about that below.)
- Configuration: each individual control block component must be
appropriately initialized (and "finalized", especially when its output is
being used to drive a motor!), and this configuration takes place in the
"finalize" state of the Coordination state machine of the whole control
diagram (see below). Each "composite" control block's "initialize" (and
"finalize", and "update") function should know what to do with the
corresponding initialization/finalization/updating of the control diagram
that it encapsulates; in principle, this should be rather straightforward
because the DAG datastructures can be nested hierarchically (I think...)
In addition, there can be runtime configuration of
some of the "gains" in some of the blocks, which would be done in the
"update" state of the composite control block, but via the configuration
interfaces of the individual control blocks.
- Coordination: for the SCL _library_ there should be _no_ state machine
functionality, since that is the responsibility of the _component_ in
which the functionality is being computed. Of course, it would be nice if
we could provide the SCL functionality in an Orocos/RTT compatible
component; and that one will have a Coordination state machine. There are
plenty of examples for this in the KDL and BFL libraries; also there, the
separation between the functionality and the "component deployment" has
been nicely achieved. But the 'executable graph' idea was not yet there
when these libraries were conceived, so the both have their own, partial,
implicit, implementation of that idea. Food for refactoring :-)
- Communication: each individual control block will be designed in a
"component based way", that is, the "update" function reads the input
"Ports" (including configuration, possibly), does its computations, and
then writes the "output" Ports. This design allows usage in the following
relevant use cases:
- fully "collocated" deployment, that is, everything takes place in one
single thread, without any "communication middleware", so:
- each Connection is just a shared variable;
- each Port access is a read/write to that variable
- the Coordination of the computational scheduling is done via the
Directed Acyclic Graph data stucture.
- "multi-threaded" deployment, that is, some component run in one thread,
others in another thread, but still in the same address space. Then
nothing changes in the _functions_, but the RTT component framework comes
into play, and more in particular, its "lock-free data ports", and a
Coordinator for the whole system to take care of the coordination of the
initializations and finalizations.
- "multi-process" deployment: similar as multithreaded, but now with the
RTT mqueues.
- "multi-platform" deployment: again similar, but now a non-Orocos-native
Communication middleware has to be used.
About the graph, tree, DAG, polytree data structures: these are much more
generally useful than the SCL context, so we should make a separate library
for them. I have a Master student working on this, and we call it
"executable graphs", for the time being. Roughly said, he has made a fully
"5C comptabile" design for graph structures, including the computational
scheduling of a graph (using a graph in itself).
> On the other side, this is just a part and all the requirements of such a
> library are not firmly set yet, so any suggestions in that context would
> be appreciated too.
>
> To sum up, having any questions or suggestions, please don't hesitate to
> reply to this post.
I am considering doing exactly that :-)
Thanks for taking the initiative. I was hoping for someone to do this since
"Day one" of Orocos, which is ten years ago, this September :-)
> Kind regards,
> Boris
Herman
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>