-
Notifications
You must be signed in to change notification settings - Fork 62
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
cFS ground system GUI Python code should generate cmd UDP directly #61
Comments
Good point, the complexity/dependency is unnecessary. Guess at the core needs:
Not to limit the upper end if someone wants to add the capabilities (scripting, graphics, triggered actions, etc), but I think the sweet spot is between nothing and a full blown ground system. |
Once again, I'll just remind folks that this is (mostly) implemented in the EDS library, which is now apache 2/open source and as such can be integrated if/when the desire exists. (https://github.com/jphickey/cfe-eds-framework) The EDS runtime library has Python bindings that allow one to build CMD packets using EDS packet definitions, so one can use this to generate a packet. |
@CDKnightNASA it would seem that I need to at least partially implement this fix in order to implement #103 |
Resolved by #103. |
Is your feature request related to a problem? Please describe.
Currently the ground system code calls cmdUtil to send commands to the "spacecraft" via UDP messages to CI. This is clunky (and a giant security issue, not that we're that concerned about that...) and Python's quite capable of generating CCSDS UDP packets directly, skipping the need to call cmdUtil.
Describe the solution you'd like
I suggest implementing a library function to send commands, and that library function can directly generate CCSDS command UDP traffic. cmdUtil could even be re-written to be a Python program that just wraps that library function rather than requiring a compiler to build an executable version of cmdUtil.
Describe alternatives you've considered
Could just stick with current architecture. Currently this requires compiling cmdUtil and ensuring you're in the right location relative to cmdUtil for it to be called. Current calls assume the executable is in "../cmdUtil/cmdUtil" (so, wherever you start the GUI, it assumes cmdUtil is in a subdirectory called "cmdUtil" under the parent directory.
Additional context
Add any other context about the feature request here.
Requester Info
[email protected]
The text was updated successfully, but these errors were encountered: