Did you know that there are over 8000 programming languages that have been developed and used so far? Most people can’t name them all, but as a scientist some names would pop into your mind including C++, Python, Java, C#, even MATLAB. This list will be even narrower if you are considering programming for robotics and controls. This blog is not an attempt to convert your allegiance, but rather share some thoughts I have collected from Quanser engineers over the years on MATLAB/Simulink and Python, embellished with my own experiences. Having developed software for embedded real-time applications for controls, robotics and machine vision, here is my take on this matter.
I am going to focus this blog on Simulink and Python. They are quite common in the engineering world, for both teaching and research. Let’s see some pros and cons of each.
Simulink for Controls
For years, we primarily had support for MATLAB/Simulink with our real-time control software QUARC, Simulink offers some great advantages for designing and simulating controls applications. You can see the direct parallel between a theoretical model and its representation in Simulink below. This offers engineering students all over the world a bridge between theory and simulation. With QUARC, you can take this one step further, and deploy the Simulink model as a real-time application on numerous platforms including Windows and Linux based systems. You can tune parameters on the fly with QUARC, and monitor signals with the aid of scopes and displays while your code is deployed and running. This on-line real-time monitoring and tuning utility is a great asset for rapid control prototyping. This further bridges the gap from simulation to practice.
The added ability to drop in MATLAB function blocks into your model for logical or text-based code implementations, or even S-functions for testing embedded C/C++ code is what makes Simulink with QUARC my primary go-to for developing and testing algorithms. MATLAB/Simulink natively does not support real-time applications though, and although some people like the visual arrangement of blocks, understanding what runs first is not straightforward. Simulink does provide a Sorted Execution Order option to visualize this, but it does not beat a serial implementation in text-based languages. Speaking of text-based code implementations, let’s talk about my favorite snake – Python.
Python for Robotics
Python is a different beast altogether. Check out the video below, which shows how it gained in popularity from 2000 to 2019 , and became the most sought-after language when programming for robotics and controls, autonomous applications and machine learning for students and researchers alike. Python offers a wide array of cross-platform tools and libraries that are a single import statement away. It also benefits from constant updates and support from a massive active open-source community, and numerous tutorials.
For first-year students struggling with the complexities of C/C++, Python offers a breath of fresh air with its ease of use and practical utilities. Here is an example of a for loop that prints out every letter in a string, written in C versus Python. Am I saying that Python is a better language? Not at all. Instead, I’m stating that some may say Python is superior as a language for engineering education. It allows students to focus on algorithm development, and problem solving, rather than implementation .
I have also heard mentions of the lack of robustness or reliability with Python compared against C/C++, which is valid. At times, there aren’t clear cut ways of doing some things. Consider getting a real-time keyboard input, for instance. There are numerous packages available for this task, and the choice is also platform dependent. If your controller is deployed and you wish to update a gain, you’ll most likely have to terminate your application and tune it off-line. Lastly, think about all the print statements you would have to use to monitor any signal of interest as supposed to scopes/displays from Simulink.
Choosing a language
The decision making behind which language to select comes down to numerous factors. You have to consider the expertise and background knowledge of your students. Research staff tend to be more familiar with Python due to its open and established community, and adoption by numerous companies including Google, Facebook and Amazon. Secondary schools find it easy to adopt Python in their curriculum as well, making it popular with students new to programming in general. Engineering schools on the other hand most likely have MATLAB site licenses. This makes MATLAB/Simulink a practical tool for instructors in courses related to linear algebra, scientific computing, machine learning and robotics. This also increases the number of graduate students who have expertise with MATLAB/Simulink in their undergraduate years.
Another factor boils down to what you are doing and where the code will be deployed eventually. If you want to focus on machine learning for example, TensorFlow or PyTorch are probably the way to go, making Python a natural choice. Toolboxes for modeling aerospace and control systems, availability of continuous blocks and working in the frequency domain make Simulink a better choice instead. MATLAB/Simulink and Python both seem to be a solid choice when programming for robotics and controls.
The last factor I’ll mention is reusability and shareability. MATLAB/Simulink being proprietary, makes this difficult, although it’s becoming a strong contender in academia.
Today at Quanser, we aim to provide support for all of the above. If you have research teams familiar with Python, go for it. You have another team versed in MATLAB/Simulink through a local engineering education? Go for it. You have staff interested in C code deployment directly? I’d say go for it. One of our solutions, the QCar is a great example of this. A single QCar platform in a research lab with numerous students can have different layers of an autonomy stack deployed in different languages. They all share data through Quanser’s stream API implementation in Python, MATLAB, Simulink and C. Students can rely on their expertise and background, research interest, or support for a particular library or utility. This hybrid approach promotes putting aside your code allegiance and innovating together.
My team, the Academic Application engineers at Quanser, think about these factors extensively before developing supporting content for our solutions. When it comes to providing research focused examples, our task is rather simple. We provide a few examples in MATLAB, Simulink and Python, as well as ROS to help researchers get started with hardware. They use these are building blocks for their own applications.
However, teaching content has a permanent feel to it, as it affects students for years to come. The choice for us also depends on industry standards as well as an extensive survey of the courses offered at prominent universities. The QUBE Servo 2 curriculum for example, is all based in Simulink with some parts in MATLAB. It is backed by numerous academics as the default language when programming for robotics and controls simulations. Developing teaching content for self-driving vehicles or industrial automation robots is a very different story. It is vital for us to help students taking such courses to also develop skills relevant to the industry they are pursuing, making Python/ROS a better choice.
To summarize, it really depends on what you want to do. What are your thoughts on this? Comment below.
 - Foldager, Frederik & Thomsen, Dan & Li, Haijie & Frederiksen, Kasper & Andersen, Anders & Zhang, Xuping. (2015). Electrical-Mechanical Dynamic Modelling and Testing of a Lightweight-Link Robot Manipulator.  - Most Popular Programming Languages 1965 - 2019. (2019). YouTube  - Fangohr, H. (2004). A Comparison of C, MATLAB, and Python as Teaching Languages in Engineering. In: Bubak, M., van Albada, G.D., Sloot, P.M.A., Dongarra, J. (eds) Computational Science - ICCS 2004. ICCS 2004. Lecture Notes in Computer Science, vol 3039. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-540-25944-2_157