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.

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

AC.bvb field not written on socket #128

Open
DarioTurchi opened this issue Jan 19, 2024 · 6 comments
Open

AC.bvb field not written on socket #128

DarioTurchi opened this issue Jan 19, 2024 · 6 comments

Comments

@DarioTurchi
Copy link

DarioTurchi commented Jan 19, 2024

The field AC.bvb[] is filled with the ground-truth magnetic field vector in the case where no magnetometers are available to the spacecraft (42sensors.c, line 452, current master branch).
However, this field is not written on the IPC message (SimWriteToSocket.c), and thus the relative information is not made available over the socket connection to a remote FSW.
Is this a mistake or intentional?

I can see that the FSW shouldn't have to access the ground truth, but I can't quite understand why a "local" controller should have different information respect to a "remote" one.
Am I missing something here ?

Many thanks

@ericstoneking
Copy link
Owner

It's intentional, to enforce the discipline of "FSW shouldn't have to access the ground truth". 42 allows some cheats (access to ground truth, ideal actuators) to enable rapid early prototyping, but by the time you're using "remote" controllers, it's recommended that you grow out of those.

@DarioTurchi
Copy link
Author

DarioTurchi commented Jan 21, 2024

Thanks,
so the recommended approach to follow to develop (and use) sensor models extern to the 42 code (which would need ground-truth values) would be to parse the S[].* part of the IPC message and get the ground-truth from there. Correct ?

@ericstoneking
Copy link
Owner

Sure, that should work.

@DarioTurchi
Copy link
Author

Thank you very much for the clarifications so far.
As a related topic, it seems to me the server is not providing the client (via IPC) with details about the involved sensors (e.g., SC[0].MAG[0].Noise), not even just within the first message, in which other configuration aspects are communicated.

This would be useful for a remote ACS in order to, e.g., tune the navigation filtering algorithms without needing replicated configuration files.

Is such information available over the IPC communication and I couldn't figure it out? Or would it somehow break the system philosophy?

@ericstoneking
Copy link
Owner

You might want to study Database/Readme.txt.

@DarioTurchi
Copy link
Author

DarioTurchi commented Feb 1, 2024

Hi,
yes, I've already had (since I wrote the last comment) a better look at that file and the code and I've realised it is possible to enable the communication of those fields by using the [~>~] tag.
However, could you confirm me that it is not possible to have such fields sent only with the first message?
It seems to me (but I'm not sure) that the fields sent only on the first message are the ones under the ~Parameters~ tag, but only within the AC structure.
Am I right ?

Many thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants