`AC.bvb` field not written on socket

[DarioTurchi]

`AC.bvb` field not written on socket

[ericstoneking]

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]

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]

Sure, that should work.

[DarioTurchi]

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]

You might want to study Database/Readme.txt.

[DarioTurchi]

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