-
Notifications
You must be signed in to change notification settings - Fork 2
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.
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
No make target bebop/sitl #78
Comments
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". |
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 |
I half-expected the workspace to not build. We need to seriously update our docs :). Do a pull from that |
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. |
I should also clarify something else: run |
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 |
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. |
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. |
Ok thank you very much , one last question (i hope), from where and how should I start yamcs as the
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 |
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 |
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 |
Nothing special. Our workspace |
Thanks for the clarification but when I just do that I get an error saying YAMCS is missing a file Am I missing something ? |
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 |
No you're not. You are in the right track. Now make the following changes:
Then try |
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. As a last question is there any documentation regarding auto yamcs I should read before diving in? |
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. |
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: 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. |
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: ***@***.***>
|
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
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 |
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): |
Correct.
Correct.
Correct.
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:
Another use case is to represent strings since a string(at the moment) is a "special case" of a type:
If you look at our YAML there are plenty of examples under the
All we mean here is the binary that executes the flight software--in our case |
Yes.
Correct. |
The docs are a little misleading on this(I'll update them when I can)
Just to make sure I understand, when using |
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 : I tried cloning yamcs-cfs in the Full error trace : Traceback (most recent call last): |
Make sure that the path you pass to |
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: ***@***.***>
|
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: ***@***.***>
|
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:
#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
<#78 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQLAJQLDY7CUAHJZV2KY33DYD3BPXAVCNFSM6AAAAAA7BBN6ZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWGU4TKOJTGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Indeed this was the problem. Thanks for the help ! |
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) |
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. |
Depends at what step we're talking about merging. None of the
The same applies to commands. I highly recommend browsing and exploring 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. |
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 Secondly, and this is minor setup inconvenience but I figured I would ask anyway. In my version of cFS we have define like those : |
Okay thanks a lot for the clarification, I completely misunderstood the use of tlm_cmd_merger |
Yes, that is most likely the problem. In order the debug this issue, look at |
I found the problem. I'm just blind and forgot to change the elf file in the msg_def_overrides.yaml |
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 |
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
The text was updated successfully, but these errors were encountered: