Command/Telemetry Definitions for both YAMCS and flight software

[Ryan Kingsbury]

I am looking to build a command, control and telemetry framework for a Cubesat payload.  Ideally I would like to be able to define my command and telemetry formats in a single place and then have both the ground software (e.g. YAMCS) and the flight software build off of this single "source of truth."

XTCE looked promising on the surface since it is supported by YAMCS, however, I have not found any open source tooling for converting XTCE into language bindings appropriate for use within the flight software (e.g., C/C++ header files).

Solutions for this problem outside the space community seem to be things like Protocol Buffers and flatbuffers.  Unfortunately, I don't see any mention of them in the YAMCS documents.  I do see some protobuf code in the YAMCS repo, but I think it might just be related to the web API? 

Am I missing anything?  Certainly I can't be the first one to want to do something like this.  Any advice would be greatly appreciated.

Ryan

 

[Nicolae Mihalache]

Hi Ryan, Yamcs developer here.

"Certainly I can't be the first one to want to do something like this" - that was my thought when starting Yamcs :)

I thought of adding protobuf support directly in Yamcs, so as to allow receiving TM packets as protobuf messages. That wouldn't be so difficult, however the XTCE encodes more information than just how to extract parameters out of the binary data. It encodes raw to engineering transformation rules, validity limits, alarms. So if you used protobuf you would still need to encode those somewhere.

In the direction you are looking for I know these two:

https://github.com/nasa/CCDD

https://github.com/WindhoverLabs/xtce_generator

They are both related to NASA cFS and I have personally not used them.

I think many companies develop internal tools but never release them outside the company, which is a pity because those kind of tools tend to rot away (new employees not willing to use old guys' tools, etc).

nicolae

--
You received this message because you are subscribed to the Google Groups "yamcs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to yamcs+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/yamcs/3390cab3-880b-4515-a0b2-a47068053584n%40googlegroups.com.

[Lorenzo Gomez]

I hope it's ok if I butt in for a second. I'm one of the main devs of

https://github.com/WindhoverLabs/xtce_generator and I would just like to re-iterate what Nicholae said about XTCE; it's not just serialization of the bits, it's also alarms in your flight software, algorithms for GNC/Grounds Ops, etc....

Because of this,  our https://github.com/WindhoverLabs/xtce_generator is only one of the tools in a set of tools called https://github.com/WindhoverLabs/auto-yamcs which includes XTCE-auto generation and a whole bunch tooling for edge cases that have appeared over the years as a result of automating the workflow. After you configure auto-yamcs via a YAML file(which in turn is in our workflow is the configuration of the entire ground system as a whole), you can generate XTCE in seconds. We've written some documentation to get users started so you're more than welcome to use auto-yamcs(and also ask questions on the issues!). Over the years it has been very flattering that multiple groups are actually using our tooling so it'd be great if you guys started using it too so you don't have to spend months defining telem/commanding files(aka XTCE) and probably make mistakes and not iterate as quickly on the project ;).