Simulink: The Good, The Bad, and The Ugly
At the Technische Universität München, I’m working on a project to implement a position-force architecture teleoperation system for a KUKA industrial robot. A user will hold a joystick or some other haptic device called the master, and control the KUKA, which is the slave. If all goes according to plan, the user will feel the forces that the slave is experiencing, measured with a force-torque sensor. To do this, a real-time operating system is used to perform calculations and control both the joystick and robot. Typically, the controls are written in the form of a real-time Simulink model, and then compiled to run on a real-time operating system. Using Simulink to program the controls is a different experience than most programming, since it is a graphical programming language. Here, I highlight the pros and cons of Simulink.
The Good:
Simulink Block + Filter Order + Cutoff Frequency + Zero Effort = Instant Butterworth Filter!
Simulink is made by and for people who do a lot of dynamic systems modeling. Because of this, there are so many built-in tools for doing things that are usually much more difficult to do in C/C++. A well-known problem of differentiating an electrical signal is the amplification of high-frequency noise. This can easily be seen by taking the derivative of A*sin(wt) and getting w*A*cos(wt). Any high-frequency component of the original signal is amplified in the derivative. Thus, to get a good differentiated signal, a low-pass filter is needed to filter out the high-frequency noise. Simulink has an amazing block called “Analog Filter Design” that allows you to choose the type of filter (Butterworth, Chebyshev, Bessel, etc.) filter order, and cutoff frequency. Suddenly, a very long bit of code is condensed into one block, and is implemented in thirty or seconds or less. Simulink, this is why you are good.
The Bad:
Simulink is a graphical language. While this makes it easy to view signal flow and system dynamics, it makes it difficult to determine where sample times begin and end. Perhaps it’s because I am not experienced enough with Simulink to be able to understand, but it is difficult for me to know when one sample begins and ends. The graphical language is built around real-time simulation, so theoretically and graphically, every signal is continuous. In reality, there is a sample time, and a simple loop of calculations that is run every millisecond or so, depending on the sample rate. If the code were sequential, as in interpreted languages, it would be easier to determine the differences between two different samples of the system. The graphical nature of Simulink makes it rather difficult to program the equation below, since samples (n) and (n-1) are difficult to determine. Simulink, this is why you are bad.
Energy Equation not easy to Implement in Simulink
The Ugly:
The equation above leads us right into the ugly. Really, it’s just a simple integration of the term in brackets, but since it includes terms from both the (n)th sample and the (n-1)th sample, you can’t just use an integration block. The ugliness comes out when we look at the code actually generated in order to implement this one equation. The figure below shows part of my implementation. Most of it is hidden, due to intellectual property considerations, but just imagine something like this that fills the entire screen. This is when Simulink becomes ugly. More importantly, this entire thing is just a small controller written to ensure stability of the master device in a much larger teleoperation system. This is why sub-systems are used to organize the mess. But Simulink, you’re still ugly.
An Incomplete view of My Implementation of the Energy Equation