Align model with template

[ClemensLinnhoff]

Add a description
This PR aligns the camera model with the template inkl. documentation structure and CI test pipeline.

Take this checklist as orientation for yourself, if this PR is ready for Maintainer Review

• My suggestion follows the governance rules.
• All commits of this PR are signed.
• My changes generate no errors when passing CI tests.
• I updated all documentation (readmes incl. figures) according to my changes.
• I have successfully implemented and tested my fix/feature locally.
• Appropriate reviewer(s) are assigned.

[MarzenaFranek]

Done ! Mit freundlichen Grüßen / Best regards Dr. Marzena Franek (CR/AEL2) Robert Bosch GmbH | Renningen | 70465 Stuttgart | GERMANY | www.bosch.com<http://www.bosch.com/> Tel. +49 711 811-17691 | Mobil +49 1522 9403572 | Telefax +49 711 811 | ***@***.******@***.***> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; Aufsichtsratsvorsitzender: Prof. Dr. Stefan Asenkerschbaumer; Geschäftsführung: Dr. Stefan Hartung, Dr. Christian Fischer, Dr. Markus Forschner, Stefan Grosch, Dr. Markus Heyn, Dr. Tanja Rückert ​ Von: Clemens Linnhoff ***@***.***> Gesendet: Freitag, 14. April 2023 13:38 An: openMSL/sl-1-4-object-based-camera-object-model ***@***.***> Cc: Franek Marzena (CR/AEL2) ***@***.***>; Mention ***@***.***> Betreff: Re: [openMSL/sl-1-4-object-based-camera-object-model] Align model with template (PR #1) Corresponding to your email @MarzenaFranek<https://github.com/MarzenaFranek>, I fixed the integer conversion remark from clang-tidy. I think this concludes working on the clang-tidy remarks. The remaining ones are fine by me. While I was fixing that, I found several unused parameters in the Lamda functions, e.g. &mpos_x, &mpos_y, &mpos_z, &origin_rot_x, &origin_rot_y, &origin_rot_z, &mpos_rot_x, &mpos_rot_y, &mpos_rot_z, and actual_range in the for_each loop in line 1087 and similarly in line 1307, line 1448 and line 1607. Could you fix those? Then I think the C++ code would be finished. I also removed the image from the readme, since you added the video as a gif. While I was doing that, I noticed the following section in the modeling approach: The actual logic of the model is packed in a so called strategy. The apply function of the strategy is called by the do_calc function of the OSMPFramework. The strategy itself is structured into four modules as shown in the image below. I think this is a copy-paste-error, since strategies are only used in the FZD OSMP Framework, which is not used in this model. I could also not find the modules described in the block diagram, such as clustering, in the code. Also some of the interfaces seem odd. To my knowledge there is no "osi3::VideoDetection" in OSI. Could you go over the readme and check these sections? — Reply to this email directly, view it on GitHub<#1 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A4ROATHG6DNRBTDFOMBSJWTXBEZI5ANCNFSM6AAAAAAWGKA4N4>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ClemensLinnhoff]

Looks very good! I tried to fix the last clang-format remarks, but in my opinion the formatting is fine.

The DCO sign-off check fails, as not all commit are signed off. But since your last ones are, and we are doing a squash merge anyways, I am fine with ignoring it. Therefore, I give my approval to the PR.
Before merging, we need one more review from another maintainer.

[jdsika]

@ClemensLinnhoff this is outdated now, as we use the repo name as FMU name, right?

[ClemensLinnhoff]

Yes, but let's merge this PR first, then adapt to naming the FMU according to the repo. This requirement did not exist, when @MarzenaFranek startet, so I would like to keep it separate.

[jdsika]

@ClemensLinnhoff would this also need to be adapted to the repo name?

[ClemensLinnhoff]

Not necessarily, but as above, I would adapt this in a separate PR.

[jdsika]

For the sake of showing the use of the MPL 2.0 OSMP sensor packaging in combination with a model implementation and looking at the weak copy left of MPL, shouldn't we split the function into a different file? In this case the function will also be MPL but we had the diuscussion about how this could be used in combination with other licenses? @ClemensLinnhoff

[ClemensLinnhoff]

For the sake of showing the use of the MPL 2.0 OSMP sensor packaging in combination with a model implementation and looking at the weak copy left of MPL, shouldn't we split the function into a different file? In this case the function will also be MPL but we had the diuscussion about how this could be used in combination with other licenses? @ClemensLinnhoff

Yes, I think this would generally be a good idea! Would it be possible for you @MarzenaFranek to do this? So put the model contents (pretty much everything in the doCalc function) into a separate file? Then we would have a clean separation between model and OSMP.

[MarzenaFranek]

I can try this in KW19, currently I am full with other tasks,. Mit freundlichen Grüßen / Best regards Dr. Marzena Franek (CR/AEL2) Robert Bosch GmbH | Renningen | 70465 Stuttgart | GERMANY | www.bosch.com<http://www.bosch.com/> Tel. +49 711 811-17691 | Mobil +49 1522 9403572 | Telefax +49 711 811 | ***@***.******@***.***> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; Aufsichtsratsvorsitzender: Prof. Dr. Stefan Asenkerschbaumer; Geschäftsführung: Dr. Stefan Hartung, Dr. Christian Fischer, Dr. Markus Forschner, Stefan Grosch, Dr. Markus Heyn, Dr. Tanja Rückert ​ Von: Clemens Linnhoff ***@***.***> Gesendet: Montag, 17. April 2023 17:43 An: openMSL/sl-1-4-object-based-camera-object-model ***@***.***> Cc: Franek Marzena (CR/AEL2) ***@***.***>; Mention ***@***.***> Betreff: Re: [openMSL/sl-1-4-object-based-camera-object-model] Align model with template (PR #1) For the sake of showing the use of the MPL 2.0 OSMP sensor packaging in combination with a model implementation and looking at the weak copy left of MPL, shouldn't we split the function into a different file? In this case the function will also be MPL but we had the diuscussion about how this could be used in combination with other licenses? @ClemensLinnhoff<https://github.com/ClemensLinnhoff> Yes, I think this would generally be a good idea! Would it be possible for you @MarzenaFranek<https://github.com/MarzenaFranek> to do this? So put the model contents (pretty much everything in the doCalc function) into a separate file? Then we would have a clean separation between model and OSMP. — Reply to this email directly, view it on GitHub<#1 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A4ROATFUHKDNIOS6ERMW3MTXBVQHZANCNFSM6AAAAAAWGKA4N4>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ClemensLinnhoff]

I just added the separation to the sl-1-0-sensor-model-repository-template. Now there is an OSMP.cpp file with the packaging and a MySensorModel.cpp file with the actual model in the src directory.
@MarzenaFranek you can basically copy this concept to the camera model.

[github-actions]

Cpp-Linter Report ⚠️

Some files did not pass the configured checks!

clang-tidy reports: 22 concern(s)

• src/OSMP.cpp

  /src/OSMP.cpp:60:5: warning: [cppcoreguidelines-pro-type-member-init]

  uninitialized record type: 'myaddr'

      union Addrconv
      ^

  /src/OSMP.cpp:69:12: warning: [cppcoreguidelines-pro-type-union-access]

  do not access members of unions; use (boost::)variant instead

      myaddr.base.lo = lo;
             ^

  /src/OSMP.cpp:70:12: warning: [cppcoreguidelines-pro-type-union-access]

  do not access members of unions; use (boost::)variant instead

      myaddr.base.hi = hi;
             ^

  /src/OSMP.cpp:71:12: warning: [cppcoreguidelines-pro-type-reinterpret-cast]

  do not use reinterpret_cast

      return reinterpret_cast<void*>(myaddr.address);
             ^

  /src/OSMP.cpp:71:43: warning: [cppcoreguidelines-pro-type-union-access]

  do not access members of unions; use (boost::)variant instead

      return reinterpret_cast<void*>(myaddr.address);
                                            ^

  /src/OSMP.cpp:82:5: warning: [cppcoreguidelines-pro-type-member-init]

  uninitialized record type: 'myaddr'

      union Addrconv
      ^

  /src/OSMP.cpp:91:12: warning: [cppcoreguidelines-pro-type-union-access]

  do not access members of unions; use (boost::)variant instead

      myaddr.address = reinterpret_cast<unsigned long long>(ptr);
             ^

  /src/OSMP.cpp:91:22: warning: [cppcoreguidelines-pro-type-reinterpret-cast]

  do not use reinterpret_cast

      myaddr.address = reinterpret_cast<unsigned long long>(ptr);
                       ^

  /src/OSMP.cpp:92:17: warning: [cppcoreguidelines-pro-type-union-access]

  do not access members of unions; use (boost::)variant instead

      hi = myaddr.base.hi;
                  ^

  /src/OSMP.cpp:93:17: warning: [cppcoreguidelines-pro-type-union-access]

  do not access members of unions; use (boost::)variant instead

      lo = myaddr.base.lo;
                  ^

  /src/OSMP.cpp:231:18: warning: [readability-convert-member-functions-to-static]

  method 'DoStart' can be made static

  fmi2Status OSMP::DoStart(fmi2Boolean tolerance_defined, fmi2Real tolerance, fmi2Real start_time, fmi2Boolean stop_time_defined, fmi2Real stop_time)
                   ^

  /src/OSMP.cpp:236:18: warning: [readability-convert-member-functions-to-static]

  method 'DoEnterInitializationMode' can be made static

  fmi2Status OSMP::DoEnterInitializationMode()
                   ^

  /src/OSMP.cpp:297:18: warning: [readability-convert-member-functions-to-static]

  method 'DoTerm' can be made static

  fmi2Status OSMP::DoTerm()
                   ^

  /src/OSMP.cpp:308:1: warning: [cppcoreguidelines-pro-type-member-init]

  constructor does not initialize these fields: boolean_vars_, integer_vars_, real_vars_

  OSMP::OSMP(fmi2String theinstance_name,
  ^

  /src/OSMP.cpp:468:24: warning: [cppcoreguidelines-pro-bounds-constant-array-index]

  do not use array subscript when the index is not an integer constant expression

              value[i] = real_vars_[vr[i]];
                         ^

  /src/OSMP.cpp:492:24: warning: [cppcoreguidelines-pro-bounds-constant-array-index]

  do not use array subscript when the index is not an integer constant expression

              value[i] = integer_vars_[vr[i]];
                         ^

  /src/OSMP.cpp:509:24: warning: [cppcoreguidelines-pro-bounds-constant-array-index]

  do not use array subscript when the index is not an integer constant expression

              value[i] = boolean_vars_[vr[i]];
                         ^

  /src/OSMP.cpp:526:24: warning: [cppcoreguidelines-pro-bounds-constant-array-index]

  do not use array subscript when the index is not an integer constant expression

              value[i] = string_vars_[vr[i]].c_str();
                         ^

  /src/OSMP.cpp:543:13: warning: [cppcoreguidelines-pro-bounds-constant-array-index]

  do not use array subscript when the index is not an integer constant expression

              real_vars_[vr[i]] = value[i];
              ^

  /src/OSMP.cpp:560:13: warning: [cppcoreguidelines-pro-bounds-constant-array-index]

  do not use array subscript when the index is not an integer constant expression

              integer_vars_[vr[i]] = value[i];
              ^

  /src/OSMP.cpp:577:13: warning: [cppcoreguidelines-pro-bounds-constant-array-index]

  do not use array subscript when the index is not an integer constant expression

              boolean_vars_[vr[i]] = value[i];
              ^

  /src/OSMP.cpp:594:13: warning: [cppcoreguidelines-pro-bounds-constant-array-index]

  do not use array subscript when the index is not an integer constant expression

              string_vars_[vr[i]] = value[i];
              ^

Have any feedback or feature suggestions? Share it here.

[ClemensLinnhoff]

Data Cluster Maintainer Decision: Merge as is, update CI pipeline according to template in new PR.