Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

No make target bebop/sitl #78

Closed
mVanSteen opened this issue Nov 7, 2023 · 39 comments
Closed

No make target bebop/sitl #78

mVanSteen opened this issue Nov 7, 2023 · 39 comments

Comments

@mVanSteen
Copy link

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
@mVanSteen mVanSteen changed the title No make targer bebop/sitl No make target bebop/sitl Nov 7, 2023
@lorenzo-gomez-windhover
Copy link
Collaborator

You didn't miss anything. Docs need to be updated. I just pushed a branch that adds a build called "gemini2-sitl-ppd". WindhoverLabs/airliner@df370ec

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

@mVanSteen
Copy link
Author

Hello again, now there seems to be no target for make commander_workspace 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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

lorenzo-gomez-windhover commented Nov 8, 2023 •
edited

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
Copy link
Author

mVanSteen commented Nov 8, 2023 •
edited

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
Copy link
Collaborator

lorenzo-gomez-windhover commented Nov 8, 2023 •
edited

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

lorenzo-gomez-windhover commented Nov 9, 2023 •
edited

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Collaborator

lorenzo-gomez-windhover commented Nov 9, 2023 •
edited

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
Copy link
Author

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
Copy link
Contributor

mbenson1 commented Nov 10, 2023 via email

@mVanSteen
Copy link
Author

mVanSteen commented Nov 10, 2023 •
edited

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Collaborator

lorenzo-gomez-windhover commented Nov 10, 2023 •
edited

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Contributor

mbenson1 commented Nov 10, 2023 via email

@mbenson1
Copy link
Contributor

mbenson1 commented Nov 11, 2023 via email

@lorenzo-gomez-windhover
Copy link
Collaborator

@mVanSteen
Copy link
Author

mVanSteen commented Nov 13, 2023 •
edited

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
Copy link
Author

mVanSteen commented Nov 13, 2023 •
edited

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
Copy link
Collaborator

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
Copy link
Collaborator

lorenzo-gomez-windhover commented Nov 13, 2023 •
edited

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
Copy link
Author

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

mVanSteen commented Nov 14, 2023 •
edited

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

@mVanSteen
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mbenson1 @lorenzo-gomez-windhover @mVanSteen