There have been a bunch of models for multiple-rotor flying machines floating around the File Exchange, but this entry is far and above the most comprehensive entry I have seen.
It has neat, sophisticated Simulink models of the dynamic system behavior; graphical user interfaces for data analysis, data formatting, and visualization; and finally, it includes the notion of model development and verification.
To me this entry represents the power MATLAB and Simulink can provide to the design of complex dynamic systems such as flying machines.
This video summarizes it very nicely.
Okay, maybe not everything. At some point you need to have substance in order to be useful. And documentation helps create the context in which to operate the tools. The Quad-Sim entry has all of these. The content of this entry is well organized in a way which helps detail what exactly is available within the content of the Quad-Sim tools.
In addition, the Simulink simulation models are well organized in terms of functional hierarchy. In other words, elements contained within the Simulink model are placed in well-named subsystems and libraries according to their functionality. There are clear partitions between inputs, controllers, plant dynamics, sensors, etc.
It sounds simple, but it makes all the difference. The organization of the content and the models alone made it very easy for me to understand, and start using the models.
I am definitely a proponent of Simulink as a platform for the development of dynamic systems and their control. Because I believe in Simulink as a design tool, it also means I spend a great deal of time and effort thinking about how to create and share models and supporting materials.
I have a self-imposed bias that makes it difficult for me to demonstrate or promote models that are messy, or otherwise difficult to understand. As such, I struggle to find File Exchange entries that involve Simulink, especially because Simulink is designed as a graphical tool, and therefore the form of the simulation model is at the forefront.
If David and his colleagues somehow believe that the world of development and design will always be well thought-out and documented, they will soon be in for a shock.
Generally deadlines of overlapping projects loom, and we must produce functionality to meet specific needs now, and worry about documentation later (if at all).
As all of us know, being a user of a tool we want clear, well though-out documentation that not only has details of how to use a particular tool or feature, but examples of its use. Finally understanding the underlying nature of a particular feature helps us better use features appropriately. But as many of us are some sort of developer or designer, we also are aware of the effort required to produce such rigorous documentation.
The Quad-Sim not only has well written documentation on specifically how to use the included tools (e.g. Modeling GUI):
It also has detailed explanations of various experimental processes so they can be reproduced, and the tools can be understood relative to a specific design context (e.g. Motor Modeling Hardware).
The fact that David and his colleagues bothered to attempt and verify their system models really excited me. I know it sounds like maybe I should reconsider my priorities in life, but I couldn’t help showing some of my colleagues in my hall the Quad-Sim entry. Nor could I hide my excitement in seeing users spend the time to make sure their models are correct.
A model is an invaluable tool for design and analysis of complex systems. But what good is the use of that model for design if it is “wrong”?
Certainly “wrong” is a relative term. A model is always wrong, otherwise it’s not a model. I am specifically referring to the notion that a model must capture the important attributes of a system sufficiently with enough accuracy to be useful for the purposes of the design and analysis.
Maybe I should say: what good is using a model that is “too wrong”?
It wasn’t clear to me that David and his colleagues used automated C-code generation from Simulink to implement the controller on the Arduino processor. Control systems like this are ideal candidates for our C-code generation technology from Simulink.
In my opinion, the Quad-Sim entry covers the more important aspects of the design process. It’s more important to get it right, without damaging people or equipment, than to implement quickly.
Seeing as that part of the process has been taken care of, it seems natural to me to automate the process of generating the control algorithm from the Simulink model to be implemented on the Arduino processor.
This enables two key design process attributes:
- Prevent the introduction of errors when translating designs from Simulink to C-code
- Permit design iterations to be tested in simulation, and then quickly implemented
Both of these help save demand on software development resources, especially as designs become more complex, and design cycle iterations become shorter. We do offer an Arduino Hardware Support Package that enables you to include connections of the model to hardware peripherals such as analog-to-digital converters (ADC), and go all the way from the Simulink model to the executable running on the hardware with a single button click.
This is fine if you can represent the entire system software in Simulink. But in most cases, engineers want to integrate the control algorithm with some existing software framework. For this, you can leverage Embedded Coder to generate the C-code and then integrate the resulting code into your software project.
I have lots of other comments and notions about this entry, but I’ll save that for other discussions. Let us know what you think.
If you would like to leave any comments regarding this post, please click here.
To leave a comment, please click here to sign in to your MathWorks Account or create a new one.