No make target bebop/sitl

[mVanSteen]

There seems to be no rules to make the target bebop/sitl as it is shown in the quick start guide. Please let me know if I forgot or missed something. (Am I supposed to install airliner first or is step 2 the required installation ?)

Thank you for your help

[lorenzo-gomez-windhover]

You didn't miss anything. Docs need to be updated. I just pushed a branch that adds a build called "gemini2-sitl-ppd". https://github.com/WindhoverLabs/airliner/commit/df370eca14fff9a1f85e0194e01cf9585a1f6b2c

Basically same docs, but switch to that branch and replace everything that says "beebop/sitl" with "gemini2-sitl-ppd".

[mVanSteen]

Hello again, now there seems to be no target for _make commanderworkspace and make start-yamcs in the airliner/build/fixedwing/gemini2/ppd/sitl/target directory. I could not find anything that seem to mach those target in therms of name or comparable expected output (mentioned in the README).

Once again thanks for the help it is very much appreciated

[lorenzo-gomez-windhover]

I half-expected the workspace to not build. We need to seriously update our docs :). Do a pull from that 178_easy_build and run make gemini2-sitl-ppd-workspace.

[lorenzo-gomez-windhover]

Now it's probably a good opportunity to explain a bit more about what is happening here, since the workspace itself is probably a lot more relevant to your question.

The workspace is essentially your ground system. Once built with the command above, it should have all of your telemetry and command definitions. Most importantly is the fact that those definitions are generated from the flight software binary that will execute on your vehicle whether it is simulated or real hardware. Meaning you won't have to worry about ABI issues when switching targets. Whether it is PowerPC, x86 or Arm those definitions will be correct (there are some caveats to be aware which should be stated in our documentation ). And please do let us know if there is any edge cases you find in your workflow. As you read more the auto-yamcs docs, a lot of this should make more sense.

[lorenzo-gomez-windhover]

I should also clarify something else: run make gemini2-sitl-ppd-workspace from root airliner directory and not from airliner/build/bebop2/sitl/target. A lot has changed since the bebop build days and haven't gotten around to updating our docs.

[mVanSteen]

Everything you are telling me seems really interesting is the auto-yamcs docs you mentioned the one that can be generated by the airliner project make file or should I look somewhere esle?

Edit : I must have done something wrong it seems to work now

[lorenzo-gomez-windhover]

Everything you are telling me seems really interesting is the auto-yamcs docs you mentioned the one that can be generated by the airliner project make file or should I look somewhere esle?

I recommend sticking to working with airliner while you learn the workflow for now, just because that's what has been battle-tested with. However, once you through the process end-to-end you can certainly use any other flight software you wish to use.

[lorenzo-gomez-windhover]

auto-yamcs has no "dependency" on airliner, it's just that's what we offer in our tutorials/guides since that is what we use.

[mVanSteen]

Ok thank you very much , one last question (i hope), from where and how should I start yamcs as the make start-yamcs does not seem to work anymore

I recommend sticking to working with airliner while you learn the workflow for now, just because that's what has been battle-tested with. However, once you through the process end-to-end you can certainly use any other flight software you wish to use.

Just to be sure for the airliner doc you are talking about the makefile generated documentation just so I don't spend time trying to understand something that could be outdated

[lorenzo-gomez-windhover]

one last question (i hope), from where and how should I start yamcs as the make start-yamcs does not seem to work anymore

I don't mind the questions at all; this type of exercise adds a lot of value as it forces us to to keep our docs up to date :). Once you have the workspace built( after running make gemini2-sitl-ppd-workspace), cd into build/fixedwing/gemini2/sitl_commander_workspace and run ./bin/yamcs-start /opt/yamcs . and see what happens.

[mVanSteen]

Hello, I know it might not exactly be your topic but is there anything special you have done to install YAMCS or is it as simple as extracting it in the right location.

Sorry if I state the obvious and correct me if I am wrong but from what I understood airliner is your version of the nasa cFS. If so is there a way to configure auto-yamcs to work with nasa cFS ? Sorry if my questions seem obvious but I haven't found any documentation on auto-yamcs apart from the readme so I'm not quite sure of the capabilities of the software yet

Any way thanks again for the help it really helps me a lot

[lorenzo-gomez-windhover]

Hello, I know it might not exactly be your topic but is there anything special you have done to install YAMCS or is it as simple as extracting it in the right location.

Nothing special. Our workspace ./bin/yamcs-start script assumes that it is installed(meaning that tar ball extracted) under /opt/yamcs. But you can certainly modify that script and move the yamcs installation to another location, if that is something your prefer.

[mVanSteen]

Thanks for the clarification but when I just do that I get an error saying YAMCS is missing a file XTCE file not found: mdb/cpd.xml

Am I missing something ?

[lorenzo-gomez-windhover]

Sorry if I state the obvious and correct me if I am wrong but from what I understood airliner is your version of the nasa cFS. If so is there a way to configure auto-yamcs to work with nasa cFS ? Sorry if my questions seem obvious but I haven't found any documentation on auto-yamcs apart from the readme so I'm not quite sure of the capabilities of the software yet

Great question. Yes, this is our version of CFS. And yes, you absolutely can use auto-yamcs with any other version of CFS. In fact, as a tool, auto-yamcs is designed that way. If you go to build/fixedwing/gemini2/ppd/sitl/target and look at the files wh_defs.db and wh_defs.yaml--those files are essentially an aggregate of all configuration from all of the CFS modules/apps. In there you'll find telemetry and command definitions. Each app/module in airliner has a YAML file that the user can change the message ids, structures, command code, etc. And then when you build the workspace with make gemini2-sitl-ppd-workspace all of those YAML files are merged into wh_defs.yaml and wh_defs.db. The wh_defs.db is a sqlite database so you can always view the contents of with something like sqlitebrowser GUI. And I want to emphasize that auto-yamcs does not care whether these definitions come from arliner or not. auto-yamcs simply looks at a YAML file and extracts everything(bit, patterns, message ids, commands, etc) needed for a ground system such as YAMCS and outputs XTCE. In our repo we've written some scripts to make this workflow a little easier. But with very little effort you you can easily use auto-yamcs for any other version of CFS. There are some caveats(such as CCSDS header assumptions), but nothing major.

[lorenzo-gomez-windhover]

Thanks for the clarification but when I just do that I get an error saying YAMCS is missing a file XTCE file not found: mdb/cpd.xml

Am I missing something ?

No you're not. You are in the right track.

Now make the following changes:

1. cd into  build/fixedwing/gemini2/sitl_commander_workspace and `rm etc/yamcs.simlink.yaml`
2. Open etc/yamcs.yaml  and delete the line that says "  - simlink"`
3.  Open etc/yamcs.fsw.yaml  and delete the lines:
              - type: "xtce"
                spec: "mdb/cpd.xml"

Then try ./bin/yamcs-start /opt/yamcs . again.

[mVanSteen]

Okay thank you very much, it seems to work as intended.

Thanks for helping me in the installation process, I hope it will be smooth sailing from now on. The capabilities of auto yamcs seem really amazing and could be a huge time saver. I will try it extensively in the following days and will come back to you if I have any issue.

As a last question is there any documentation regarding auto yamcs I should read before diving in?

[lorenzo-gomez-windhover]

Okay thank you very much, it seems to work as intended.

Thanks for helping me in the installation process, I hope it will be smooth sailing from now on. The capabilities of auto yamcs seem really amazing and could be a huge time saver. I will try it extensively in the following days and will come back to you if I have any issue.

You're very welcome. Very glad to see that others are seeing the value in a tool like this. That has always been the intent with auto-yamcs; save yourself time( and ABI-related headaches).

And yes please--do not hesitate to reach out if you run into any other issues.

[lorenzo-gomez-windhover]

As a last question is there any documentation regarding auto yamcs I should read before diving in?

Depends how far you want to go and what your goals are. Off the top of my head here are some resources I can think of the top of the my head: https://github.com/WindhoverLabs/auto-yamcs#table-of-contents https://docs.yamcs.org/ https://groups.google.com/g/yamcs https://github.com/WindhoverLabs/airliner https://github.com/yamcs https://groups.google.com/g/yamcs https://github.com/WindhoverLabs/juicer https://github.com/WindhoverLabs/xtce_generator https://github.com/WindhoverLabs/yamcs-cfs https://www.omg.org/spec/XTCE/1.2/About-XTCE/ https://dwarfstd.org/dwarf4std.html https://github.com/WindhoverLabs/phoebus (modern version of YAMCS Studio Display Builder software) @mbenson1

If you don't mind us asking, how are you using auto-yamcs? It sounds like you are also using it with CFS? New version of CFS perhaps?

[mVanSteen]

If you don't mind us asking, how are you using auto-yamcs? It sounds like you are also using it with CFS? New version of CFS perhaps?

We will be using it mainly for quick prototyping I would say. I'm working at Space Application Services on the ERSA project for ESA and we need to have a very dynamic YAMCS environment to build our CFS bundle.

[mbenson1]

We are using the auto-yamcs tools with CFS but we designed it to be as use agnostic as we could.  It’s actually a collection of loosely coupled tools that can be mixed and matched.  Some of them, like “squeezer”, have zero dependency on the message formats.  Squeezer just extracts bit maps from the dwarf sections of as-built binaries.  Other tools have dependencies on the CCSDS message format.  The only dependency the tools have is on the CCSDS secondary header for commands.  Our work was also born from space projects.  I have over 20 years experience working on ISS, Orion, Waypoint, and other projects.  Auto-YAMCS basically exists to completely eliminate a team/task that every program needlessly has.  Telemetry and telecommand definitions are always maintained manually and always mostly broken throughout the entire development lifecycle.  NASA is very proud of some tools they’ve made to automate the process but when you “extract” bit patterns from source code, you are still fighting a losing battle of constantly trying to predict what the compiler does.  Rather that predict how the compiler is going to build the binaries, Auto-YAMCS reads the as-built binaries directly.  Therefore, our xtce files are created automatically and rarely break.  We have been working with CFS for almost 10 years now.  We do work with the newer version for some customers, but we have our own CFS repositories that we maintain ourselves, forked off from 6.5.0a.  There are many reasons why we prefer to not use the newer versions directly.Sent from my iPhoneOn Nov 10, 2023, at 04:02, mVanSteen @.***> wrote:

If you don't mind us asking, how are you using auto-yamcs? It sounds like you are also using it with CFS? New version of CFS perhaps?

We will be using it mainly for quick prototyping I would say. I'm working at Space Application Services on the ERSA project for ESA and we need to have a very dynamic YAMCS environment to build our CFS bundle.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[mVanSteen]

This seems indeed like very interesting and valuable work that could save a lot of people a lot of time. I'm very eager to learn more and to understand the inner workings enough to use it at it's full potential.

First of all, I have a very rough understanding of how auto-yamcs work, please correct me if I'm wrong (for the moment I talk about the version that is a submodule of airliner). In a first time we build our FSW (done by running make gemini2-sitl-ppd if my understanding is correct). Once this is done we can proceed to the more interesting part, building the workspace. From what I understood every yaml file defining every app and the core are merged using the merger into one file that is comparable to the config/inline_config.yaml that is used in the inline auto-yamcs command. This leaves us with a complete definition of the TM/TC of the flight software. Juicer will then fetch in the binary every structure that is mentioned in the yaml files. Finally through some process that I do not need to understand XTCE files are generated and given to YAMCS.

1) Is all the data used by auto-yamcs contained in yaml files and the binaries ? 2) From what I understood the "standalone' version of autoyamcs works in a similar fashion except it does not merge all the yaml files itself (probably a lot more flexible this way) 3) Regarding the inline use, could you explain a little bit what the --override_yaml is for?

Excuse my ignorance but what is a as-built binaries?

Once again thanks a lot for your help and the work you have done

Edit : my bad I made a typo

[mVanSteen]

Hello again, I tried using the inline use and got an error.

I used the the airliner I previously used for the submodule version and update all the elf files path to match my setup (changing it to ../../airliner/build/fixedwing/gemini2/ppd/sitl/target/target/exe/airliner since Airliner is in /Documents/airliner/ and Auto-yamcs is in Documents/auto-yamcs). I then ran the exact command given in the README of the auto-yamcs git.

Is there anything else I should modify?

Full trace :

Traceback (most recent call last): File "/home/user/Documents/auto-yamcs/src/squeezer.py", line 312, in main() File "/home/user/Documents/auto-yamcs/src/squeezer.py", line 305, in main args.func(args) File "/home/user/Documents/auto-yamcs/src/squeezer.py", line 191, in inline_mode_handler run_xtce_generator(args.output_file, xtce_config_data, args.verbosity, args.xtce_output_path, xtce_config_data['root_spacesystem']) File "/home/user/Documents/auto-yamcs/src/squeezer.py", line 64, in run_xtce_generator xtce_generator.generate_xtce(sqlite_path, xtce_yaml, output_path, cpu_id, verbosity) File "/home/user/Documents/auto-yamcs/xtce_generator/src/xtce/xtce_generator.py", line 2056, in generate_xtce xtce_obj.add_aggregate_types() File "/home/user/Documents/auto-yamcs/xtce_generator/src/xtce/xtce_generator.py", line 1875, in add_aggregate_types self.add_telemetry_containers(qualified_module_name, module[0], File "/home/user/Documents/auto-yamcs/xtce_generator/src/xtce/xtce_generator.py", line 1614, in add_telemetry_containers min_rate = tlm[6] IndexError: tuple index out of range

[lorenzo-gomez-windhover]

In a first time we build our FSW (done by running make gemini2-sitl-ppd if my understanding is correct).

Correct.

From what I understood every yaml file defining every app and the core are merged using the merger into one file that is comparable to the config/inline_config.yaml that is used in the inline auto-yamcs command. This leaves us with a complete definition of the TM/TC of the flight software. Juicer will then fetch in the binary every structure that is mentioned in the yaml files. Finally through some process that I do not need to understand XTCE files are generated and given to YAMCS.

Correct.

File "/home/user/Documents/auto-yamcs/xtce_generator/src/xtce/xtce_generator.py", line 1614, in add_telemetry_containers min_rate = tlm[6] IndexError: tuple index out of range

2. From what I understood the "standalone' version of autoyamcs works in a similar fashion except it does not merge all the yaml files itself (probably a lot more flexible this w

Correct.

Regarding the inline use, could you explain a little bit what the --override_yaml is for?

It's useful for cases when the user would like to override a certain type that is in the binary. For example:

In the C language one might have an "enumaration" that is really just a uint32. If you procesed that enum without the override you would end up with just an int32 on your ground system, without the nice the labels of enums. So instead of having a raw uint32, you can "override" the type like this in YAML:

     - parent: CFE_ES_RestartCmd_Payload_t
        member: RestartType
        type: enumeration
        enumerations:
          PROCESSOR_RESET: 1
          POWERON_RESET:   2

Another use case is to represent strings since a string(at the moment) is a "special case" of a type:

      - parent: CFE_ES_ShellCmd_Payload_t
        member: CmdString
        type: string

If you look at our YAML there are plenty of examples under the msg_def_overrides keys. Hopefully those explain the usefulness of this feature.

Excuse my ignorance but what is a as-built binaries?

All we mean here is the binary that executes the flight software--in our case build/fixedwing/gemini2/ppd/sitl/target/target/exe/airliner. Though this is an important detail since this as @mbenson1 pointed out the other approach to extracting definitions is looking at source code, which in my opinion, is not a effective way at all of extracting bit patterns since something like a C structure will be modified by the compiler--it might add padding for example. These ABI issues get compounded when you switch from platform to platform(which all have different compilers that do different tricks/optimizations)--an ARM compiler might treat padding very differently than an x86 one. If one were to rely on source code you'll be deceived as that struct's size will not be the same after it gets compiled.

[lorenzo-gomez-windhover]

Is all the data used by auto-yamcs contained in yaml files and the binaries ?

Yes.

From what I understood the "standalone' version of autoyamcs works in a similar fashion except it does not merge all the yaml files itself (probably a lot more flexible this way)

Correct.

[lorenzo-gomez-windhover]

File "/home/user/Documents/auto-yamcs/xtce_generator/src/xtce/xtce_generator.py", line 1875, in add_aggregate_types self.add_telemetry_containers(qualified_module_name, module[0], File "/home/user/Documents/auto-yamcs/xtce_generator/src/xtce/xtce_generator.py", line 1614, in add_telemetry_containers min_rate = tlm[6] IndexError: tuple index out of range

The docs are a little misleading on this(I'll update them when I can)

I used the the airliner I previously used for the submodule version and update all the elf files path to match my setup (changing it to ../../airliner/build/fixedwing/gemini2/ppd/sitl/target/target/exe/airliner since Airliner is in /Documents/airliner/ and Auto-yamcs is in Documents/auto-yamcs). I then ran the exact command given in the README of the auto-yamcs git.

Just to make sure I understand, when using inline mode, did you use the auto-yamcs that is a submodule of airliner or did you clone auto-yamcs into a separate directory/folder? Just use the one that is a submodule--sorry the docs are very misleading when it comes to this detail--will fix it in the future.

[mVanSteen]

Yes sorry I don't know why I did not think of running it form the submodule. I modified the path as previously so they point to the binaries in the build folder (for example the path for the core is : ../../../../../airliner/build/fixedwing/gemini2/ppd/sitl/target/target/exe/airliner) and now I get a different error : FileNotFoundError: [Errno 2] No such file or directory: 'airliner/tools/yamcs-cfs/src/main/yamcs/mdb/cfs.xml'

I tried cloning yamcs-cfs in the airliner/tools directory but nothing changed

Full error trace :

Traceback (most recent call last): File "/home/user/Documents/airliner/core/tools/auto-yamcs/src/squeezer.py", line 312, in main() File "/home/user/Documents/airliner/core/tools/auto-yamcs/src/squeezer.py", line 305, in main args.func(args) File "/home/user/Documents/airliner/core/tools/auto-yamcs/src/squeezer.py", line 191, in inline_mode_handler run_xtce_generator(args.output_file, xtce_config_data, args.verbosity, args.xtce_output_path, xtce_config_data['root_spacesystem']) File "/home/user/Documents/airliner/core/tools/auto-yamcs/src/squeezer.py", line 64, in run_xtce_generator xtce_generator.generate_xtce(sqlite_path, xtce_yaml, output_path, cpu_id, verbosity) File "/home/user/Documents/airliner/core/tools/auto-yamcs/xtce_generator/src/xtce/xtce_generator.py", line 2059, in generate_xtce xtce_obj.write_to_file(namespace=root_spacesystem) File "/home/user/Documents/airliner/core/tools/auto-yamcs/xtce_generator/src/xtce/xtce_generator.py", line 1954, in write_to_file xtce_file = open(self.output_file, 'w+') FileNotFoundError: [Errno 2] No such file or directory: 'airliner/tools/yamcs-cfs/src/main/yamcs/mdb/cfs.xml'

[lorenzo-gomez-windhover]

Make sure that the path you pass to --xtce_output_path exists. In the docs I have airliner/tools/yamcs-cfs/src/main/yamcs/mdb/cfs.xml--in that case it is assumed that airliner/tools/yamcs-cfs/src/main/yamcs/mdb directory exists. It doesn't matter where that directory is; as long as it exists. Does that make sense?

[mbenson1]

You don’t need to use airliner to use auto-yamcs.  They are decoupled.Sent from my iPhoneOn Nov 10, 2023, at 10:44, Lorenzo Gomez @.***> wrote:

File "/home/user/Documents/auto-yamcs/xtce_generator/src/xtce/xtce_generator.py", line 1875, in add_aggregate_types self.add_telemetry_containers(qualified_module_name, module[0], File "/home/user/Documents/auto-yamcs/xtce_generator/src/xtce/xtce_generator.py", line 1614, in add_telemetry_containers min_rate = tlm[6] IndexError: tuple index out of range

The docs are a little misleading on this(I'll update them when I can)

I used the the airliner I previously used for the submodule version and update all the elf files path to match my setup (changing it to ../../airliner/build/fixedwing/gemini2/ppd/sitl/target/target/exe/airliner since Airliner is in /Documents/airliner/ and Auto-yamcs is in Documents/auto-yamcs). I then ran the exact command given in the README of the auto-yamcs git.

Just to make sure I understand, when using inline mode, did you use the auto-yamcs that is a submodule of airliner or did you clone auto-yamcs into a separate directory/folder? Just use the one that is a submodule--sorry the docs are very misleading when it comes to this detail--will fix it in the future.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[mbenson1]

Lorenzo, keep in mind he’s building from GitHub.  We haven’t pushed back to GitHub in a while.  It’s definitely not on any official release.What are you trying to do?  Are you just trying to use auto-yamcs or are you really wanting to use airliner?Sent from my iPhoneOn Nov 10, 2023, at 15:12, Lorenzo Gomez @.***> wrote: Make sure that the path you pass to --xtce_output_path exists. In the docs I have airliner/tools/yamcs-cfs/src/main/yamcs/mdb/cfs.xml--in that case it is assumed that airliner/tools/yamcs-cfs/src/main/yamcs/mdb directory exists. It doesn't matter where that directory is; as long as it exists. Does that make sense?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[lorenzo-gomez-windhover]

He's gotten it to build just fine. That's why I pushed this branch for this reason to the github repo: https://github.com/WindhoverLabs/airliner/tree/178_easy_build for him to be able to build it. He already went through the process of building flight software and a working workspace via the "singleton" mode. Right now he's just trying to run auto-yamcs in "inline" mode--to invoke specific tools separately. If you are replying to these via email, you may have missed the rest of our discussion in the past couple of days: https://github.com/WindhoverLabs/auto-yamcs/issues/78

On Fri, Nov 10, 2023 at 6:31 PM Mathew Benson @.***> wrote:

Lorenzo, keep in mind he’s building from GitHub. We haven’t pushed back to GitHub in a while. It’s definitely not on any official release.What are you trying to do? Are you just trying to use auto-yamcs or are you really wanting to use airliner?Sent from my iPhoneOn Nov 10, 2023, at 15:12, Lorenzo Gomez @.***> wrote: Make sure that the path you pass to --xtce_output_path exists. In the docs I have airliner/tools/yamcs-cfs/src/main/yamcs/mdb/cfs.xml--in that case it is assumed that airliner/tools/yamcs-cfs/src/main/yamcs/mdb directory exists. It doesn't matter where that directory is; as long as it exists. Does that make sense?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/WindhoverLabs/auto-yamcs/issues/78#issuecomment-1806595934, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQLAJQLDY7CUAHJZV2KY33DYD3BPXAVCNFSM6AAAAAA7BBN6ZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWGU4TKOJTGQ . You are receiving this because you commented.Message ID: @.***>

[mVanSteen]

Make sure that the path you pass to --xtce_output_path exists. In the docs I have airliner/tools/yamcs-cfs/src/main/yamcs/mdb/cfs.xml--in that case it is assumed that airliner/tools/yamcs-cfs/src/main/yamcs/mdb directory exists. It doesn't matter where that directory is; as long as it exists. Does that make sense?

Indeed this was the problem. Thanks for the help !

[mVanSteen]

Okay, the problem actually kind of applies to me to so I look at it a little bit and managed to fix it by changing the values directly in the XTCE xml files. This is not a very convenient way to do it so I was wondering if there was an easy fix.

The problem is as mentioned previously due to some bad reference. Looking at the YAMCS-CFS repository, some of the definitions in cfs.xml are found in cfs-ccsds.xml this is done by having the reference as follows "cfs-ccsds/cfs-tlm-hdr". In the newly generated cfs.xml, this reference is set as "cfs/cfs-tlm-hdr" which is a problem since this reference does not exist. Is there a way to change this?

Edit : this problem was encountered for "cfs/cfs-cmd", "cfs/ccsds-apid" and "cfs/cfs-tlm-hdr" which should all start with "cfs-ccsds/"

Edit: found the solution in the xtce_generator config file no more problem, just the question at the end

Other than that I was able to run YAMCS by generating the XTCE files from my own binaries and yaml files, so already thank you very much for the time I will save

I was also wondering how the merging of all the Yaml files was done in the singleton mode? Is it done with your tlm_cmd_merger? If yes what are the parameters given? (It is a really nice feature that I would like to add to my auto-yamcs for ease of use)

[lorenzo-gomez-windhover]

Edit: found the solution in the xtce_generator config file no more problem, just the question at the end

Exactly. The intent of that config file is to separate the protocol from the telemetry/commanding, which in your case is CCSDS. However, with this decoupling you can have any other protocol besides CCSDS.

[lorenzo-gomez-windhover]

I was also wondering how the merging of all the Yaml files was done in the singleton mode? Is it done with your tlm_cmd_merger? If yes what are the parameters given? (It is a really nice feature that I would like to add to my auto-yamcs for ease of use)

Depends at what step we're talking about merging. None of the auto-yamcs tools modify YAML. What tlm_cmd_merger does is that it merges data from that YAML(which is however you merge that YAML is irrelevant, as long as it follows the schema in our examples) into the sqlite database(the wh_defs.db file generated by juicer). It takes the telemetry-readable names such as CFE_ES_HK_TLM_MID and maps to a struct such as CFE_ES_HkPacket_t and its message id, hence the following pattern that you will find throughout our YAML file:

            telemetry:
              CFE_ES_HK_TLM_MID:
                msgID: 0x0800
                struct: CFE_ES_HkPacket_t
              CFE_ES_APP_TLM_MID:
                msgID: 0x080B
                struct: CFE_ES_OneAppTlm_t
              CFE_ES_MEMSTATS_TLM_MID:
                msgID: 0x0810
                struct: CFE_ES_PoolStatsTlm_t
              CFE_ES_SHELL_TLM_MID:
                msgID: 0x080F
                struct: CFE_ES_ShellPacket_t

The same applies to commands. I highly recommend browsing and exploring wh_defs.db with something like sqlite GUI browser to get an intuitive understanding of this.

Now, the "final" combined YAML is generated by our build system(airliner build system). But I want to emphasize it does not have to be emphasized by our build system. You can generate that final YAML however you'd like--either by hand or your own custom scripts. If you'd like to see how we do it, this is the script that goes through all of our airliner modules' YAML files and combines them into one for the most part:https://github.com/WindhoverLabs/airliner/blob/integration/core/base/tools/config/wh_defgen.py. But like I mentioned above; how you merge the YAML is up to you as long as it complies with our YAML schema.

[mVanSteen]

Hello, I had some more question (let me know if I should open a new issue since those question are not related to building and running auto-yamcs) :

First of all, I have been trying to make the override work on my csf and I have had some issues. I have managed to play around with override on airliner but when I try to apply it to my cfs nothing seems to happen. After a little investigation, I think it is because the only StringParameterType I have in the BaseType is the plain old string (where in airliner you have string320_LE, string976_LE). Could this be the problem and if yes how can I add Types to BaseType?

Secondly, and this is minor setup inconvenience but I figured I would ask anyway. In my version of cFS we have define like those : typedef CFE_EVS_AppNameCmd_t CFE_EVS_EnableAppEvents_t; When I encoded the struct associated with some commands, I entered CFE_EVS_EnableAppEvents_t but when I opened Yamcs, the command input showed no arguments required. I then proceeded to change the struct to CFE_EVS_AppNameCmd_t and it worked. I'm not quite sure why this append or if this could easily be fixed (if no, no worries, its just good to know that this is not supported)

[mVanSteen]

Depends at what step we're talking about merging. None of the auto-yamcs tools modify YAML. What tlm_cmd_merger does is that it merges data from that YAML(which is however you merge that YAML is irrelevant, as long as it follows the schema in our examples) into the sqlite database(the wh_defs.db file generated by juicer). It takes the telemetry-readable names such as CFE_ES_HK_TLM_MID and maps to a struct such as CFE_ES_HkPacket_t and its message id, hence the following pattern that you will find throughout our YAML file: ...

Okay thanks a lot for the clarification, I completely misunderstood the use of tlm_cmd_merger

[lorenzo-gomez-windhover]

First of all, I have been trying to make the override work on my csf and I have had some issues. I have managed to play around with override on airliner but when I try to apply it to my cfs nothing seems to happen. After a little investigation, I think it is because the only StringParameterType I have in the BaseType is the plain old string (where in airliner you have string320_LE, string976_LE). Could this be the problem and if yes how can I add Types to BaseType?

Yes, that is most likely the problem. In order the debug this issue, look at wh_defs.db and follow the string structure you're trying to remap/override. Follow the symbol and field you're interested in and see how it's mapped. These docs:https://github.com/WindhoverLabs/juicer#elfs should guide you in navigating the schema. You can always edit the XTCE manually for this particular use-case, but you shouldn't need to as we ran into the very issue in the past with strings--that's one of the reasons why msg_def_overrides exists--example here:https://github.com/WindhoverLabs/auto-yamcs/blob/develop/config/singleton_config.yaml#L193C1-L195C29. Look at that db(or post it here if you're able to so I can look at it) and make sure your struct and field names match exactly, otherwise it will not remap that string as you expect it to.

[mVanSteen]

I found the problem. I'm just blind and forgot to change the elf file in the msg_def_overrides.yaml

[mVanSteen]

Ok with some minor tweaking of some file I manage to run auto-yamcs inline and not as a submodule of airliner (I don't know why but something seems to differ between the two)

Thanks a lot for your help and developing this tool, it really helps me a lot