Simulink only? How about sharing C codes?

[gurkanctn]

Hello friends,

Congratulations on sharing and open-sourcing your know-how and your architecture with the world. Great courage, and I hope great contributions will follow.

I'm pretty sure that Simulink may not be available to many people for various reasons. At work, I use Simulink daily, but at home, I use C/C++ and Python for experimenting (as a hobby).

Having said that, here comes the suggestions/questions: 1) Will you keep the Repository dependent on Simulink? 2) Could you deploy source codes (maybe 3 codepacks for the three modules) and some interface documentation? This will be great for people who might want to try integrating these functions with other stuff.

Greetings.

[awischnewski]

Thank you for the positive feedback. Actually, we have discussed this point internally some time ago. There is no specific need to keep the repository dependent on Simulink, to answer your first question. However, we are not sure how the best way to share source code would look like. I see a few difficulties with sharing the generated code:

• Module split: We have a high level architecture, however, Simulink enables people to choose how deep they want to investigate the different functionalities. While it might be possible to define some high level interfaces to the major modules for code generation, it will definitly be difficult to deploy finer granularity.
• Code readability: Generated code is many times not as readable as human written code. This might decrease the positive impact as people could only use code instead of reviewing the implementation. I agree, that if this is the main use case there are significant benefits.
• Parametrization: One of the key use cases for this software are Vehicle Target Applications. It is for sure necessary to adjust several parameters according to your use cases. This might be difficult for generated code and could significantly decrease the usability. If you have concrete advice on this topic, I would appreciate if you could share.

In general, all these points are not doing any harm to the existing code base, so there are no disadvantages at all. However, I would like to understand the needs in more detail to provide a solution which could really add value instead of just dropping something here which might not be useful at all. I think it would be great if you could share some more details on what you would expect and in which form.

[gurkanctn]

Hello Alexander,

I guess module split can be an option.

I'll try to explain further:

1. the modules that are currently distributed in Simulink, can be deployed dually as Simulink and Source Code.
2. people who have Simulink can use the Simulink libraries, and can browse inside the modules, change and update the Simulink models,
3. people who do not have Simulink, can use the Source Codes, and may refer to the Code Generation Report for a better understanding of what's under the hood. These users would probably only UTILIZE the modules as they see fit. For example, someone might use some different state estimator (for instance, they might use their own state estimator, using video from a screen capture from Microsoft Airsim, etc.).

This deployment can be done automatically using a deployment script. Code Generation Report would automatically generate interface explanations (at least definitions).

This is the first idea that popped in my mind when I first read about this repo. I'm sure several folks around the world would be interested in using some of your modules in unknown ways.

Greetings.