Giter Site home page Giter Site logo

Comments (15)

ericstoneking avatar ericstoneking commented on July 28, 2024

Hi Peter,

For anything related to NOS3, I refer you to the NOS3 folks (nasa/NOS3). I'm just the 42 guy.

That said, I did recently (inspired by the NOS3 folks) reform how 42 sets up and uses sockets. Take a fresh look at Inp_IPC.txt and the Standalone example problem. This new socket setup unkludges some things on my side, and I think it simplified some things on the NOS3 side, too. Maybe the NOS3 folks can give you further guidance.

Good luck.

Regards,
-Eric

from 42.

PeteBlanchard avatar PeteBlanchard commented on July 28, 2024

Thanks, I appreciate the quick response. I was looking at your latest Standalone, which prompted the question. Since you are listening for connection now in the ACS implementation, but I believe that the NOS FSW would expect a call from 42 to register on the NOS Engine (bus) command and telemetry (channels). Were your thoughts that the new TXRX mode be used?

I will ask about the NOS3 specific stuff on their site (though I thought it would be fair game since it IS in your header files).

Also, your documents show one of the configurations as having 42 running as the "Main GSE" and multiple (42) displays being driven from it (or receiving data from it; page 7 of the "42 Summary for DSM.pdf")...is there a way to run the "42 Cam", etc. and have them talk to a 42 instance on another machine through configuration?

from 42.

ericstoneking avatar ericstoneking commented on July 28, 2024

Hi Peter,

Thanks, I appreciate the quick response. I was looking at your latest Standalone, which prompted the question. Since you are listening for connection now in the ACS implementation, but I believe that the NOS FSW would expect a call from 42 to register on the NOS Engine (bus) command and telemetry (channels). Were your thoughts that the new TXRX mode be used?

The new TXRX mode is intended to be a two-way pipe: 42 will send a message, then wait for a reply. I don't know specifically if that's how NOS3 talks to 42, but it could very well be something like that.

Looking through my code, I see that I left off before implementing TXRX! Oops, sorry about that. I'll get that done and have it online within a week or so.

The ACS IPC mode is like TXRX, except the messages get exchanged in the appropriate point in the sim step for ACS messages to be sent and received. This is a different point in the sim step than the other IPC modes use, which is why the ACS mode needs to exist distinct from TXRX.

I will ask about the NOS3 specific stuff on their site (though I thought it would be fair game since it IS in your header files).

A fair assumption. I let the NOS3 folks put hooks in, but it's their sandbox to manage.

Also, your documents show one of the configurations as having 42 running as the "Main GSE" and multiple (42) displays being driven from it (or receiving data from it; page 7 of the "42 Summary for DSM.pdf")...is there a way to run the "42 Cam", etc. and have them talk to a 42 instance on another machine through configuration?

Easily, as long as the two machines are on the same local network. Use the TxRx example problem (see Docs/TxRx Example.txt), except in Rx/Inp_IPC.txt, replace "localhost" with the IP address (of the form 128.192.100.200) of the machine that the Tx instance is running on. You should end up with the Tx instance running on one machine with no display, and Rx running the display using data obtained from the Tx instance.

Regards,
-Eric

from 42.

PeteBlanchard avatar PeteBlanchard commented on July 28, 2024

Awesome, I just hadn't looked far enough. Thank you for the pointers!

Really IS an amazing tool. Thanks again.

from 42.

msuder avatar msuder commented on July 28, 2024

Hi Peter and Eric,

Hi Peter,

Thanks, I appreciate the quick response. I was looking at your latest Standalone, which prompted the question. Since you are listening for connection now in the ACS implementation, but I believe that the NOS FSW would expect a call from 42 to register on the NOS Engine (bus) command and telemetry (channels). Were your thoughts that the new TXRX mode be used?

I don't think it is very clear (yet) in the NOS3 documentation, but the NOS Engine bus is mainly intended for use between cFS/NOS3 apps in NOS3 and NOS3 sims... the only place NOS Engine is hooked into 42 is for time synchronization. The NOS3 sims communicate (if necessary) with 42 via straight up TCP/IP sockets (IPC) that Eric has implemented (and evolved nicely) in 42.

The new TXRX mode is intended to be a two-way pipe: 42 will send a message, then wait for a reply. I don't know specifically if that's how NOS3 talks to 42, but it could very well be something like that.

Typically now, NOS3 sims would use two separate sockets, one RX and one TX (both if and only if necessary) between the sim and 42.

The reason is that the interface between NOS3 sims and 42 is not modeled/thought of as a communication bus. A good example is the NOS3 generic reaction wheel simulation (apologizes for kind of cross posting)... while the sim communicates with the cFS application on what is modeled as a communication bus... on the other side (think of the sim as the hardware device and 42 as the real world that is being sensed/manipulated), the sim interfaces with 42 via two separate threads, one handling TX to 42 (e.g. torquing the wheel) and one handling RX from 42 (e.g. receiving momentum information from the wheel).

While these might be synchronous, this more generic design allows them to be asynchronous (and do note that as far as "real world" time, it is all synchronized via the NOS3 time mode in 42).

Looking through my code, I see that I left off before implementing TXRX! Oops, sorry about that. I'll get that done and have it online within a week or so.
That's cool... thanks, Eric! Although per my response immediately above, I don't think we will leverage TXRX (at least for now).

The ACS IPC mode is like TXRX, except the messages get exchanged in the appropriate point in the sim step for ACS messages to be sent and received. This is a different point in the sim step than the other IPC modes use, which is why the ACS mode needs to exist distinct from TXRX.

I will ask about the NOS3 specific stuff on their site (though I thought it would be fair game since it IS in your header files).

A fair assumption. I let the NOS3 folks put hooks in, but it's their sandbox to manage.

Yup, that would be me... and the 42nos3.c/.h files are me... also, a historical note for you Peter - prior to some of the IPC refactoring that Eric did, 42 did have additional NOS3 specific methods (developed by me) for send/receive to/from 42, but I removed them after Eric completed his really nice IPC refactoring since his implementation fit better into 42 and satisfied all of the NOS3 needs. I do not think that in the future there will be any NOS3 code in 42 other than the time synchronization stuff... and do note, it has been added in a way such that 42 can be built with no support nor dependencies on NOS3 (and of course, it then won't support NOS3 time sync).

Another thought here: 42 can more easily do some things that NOS3 might be used for... the primary example being direct development of GN&C algorithms/software... Eric has done a nice job providing for a "standalone" ACS app standing in as flight software and providing that framework and then having 42 provide all the dynamics inputs/outputs.

NOS3 is built for a bit larger purpose, providing an entire flight software, and beyond that, ground software and mission development platform (think digital twin). This larger purpose brings along more capability in some respects, but also more complexity. These two tools are in fact being used in this complementary way currently by at least one organization... GN&C algorithms are developed in 42, then integrated within full flight software (and ground software, think COSMOS C&T) and mission development in NOS3.

As another, personal opinion, NOS3 is not as mature as 42... but we are trying and it keeps getting better!

Also, your documents show one of the configurations as having 42 running as the "Main GSE" and multiple (42) displays being driven from it (or receiving data from it; page 7 of the "42 Summary for DSM.pdf")...is there a way to run the "42 Cam", etc. and have them talk to a 42 instance on another machine through configuration?

Easily, as long as the two machines are on the same local network. Use the TxRx example problem (see Docs/TxRx Example.txt), except in Rx/Inp_IPC.txt, replace "localhost" with the IP address (of the form 128.192.100.200) of the machine that the Tx instance is running on. You should end up with the Tx instance running on one machine with no display, and Rx running the display using data obtained from the Tx instance.

Regards,
-Eric

P.S. I second Pete's comment... Eric, 42 IS an amazing tool (thanks for doing F=ma right!)... that is part of the reason we leveraged/integrated it into NOS3.

from 42.

msuder avatar msuder commented on July 28, 2024

Mr. Stoneking,

I apologize for asking such a n00b configuration question, but I was recently looking at the NOS3 and the latest version of 42 and have some simple (for you questions)...

Though the functions are still defined in 42.h (NOS3SendMessageToFSW, NOS3ReceiveMessageFromFSW), the '42nos3.c; file no longer supports sending telemetry to or reading commands from the NOS Engine...only getting time from NOS. Is that correct? If so, is there a reason it is no longer supported?

Peter: Good catch... this is my mistake... NOS3SendMessageToFSW and NOS3ReceiveMessageFromFSW are dead (see my other response) and should be removed from 42.h. Also, while it won't make a difference for compiling/linking, for documentation/communication with other developers, the NOS3Time declaration should be #ifdef protected so it only appears when the 42 makefile is configured to support NOS3. I need to fix those.

I was hoping to use multiple instances of NOS FSW to simulate multiple satellite missions, but the version of 42 installed with NOS3 seems to be only configured via the Inp_NOS3.txt (same as for time). I know I can change CPU, etc. with the NOS FSW, but I don't see a way, right now, that I could attach them to 42. Am I going down the wrong path?

Thanks in advance.

Regards,
Peter Blanchard

from 42.

msuder avatar msuder commented on July 28, 2024

@PeteBlanchard Ping: I'm not sure if my additional comments after this issue was closed got emailed to you.

from 42.

msuder avatar msuder commented on July 28, 2024

@ericstoneking Probably should have pinged you also, FYI.

from 42.

ericstoneking avatar ericstoneking commented on July 28, 2024

from 42.

PeteBlanchard avatar PeteBlanchard commented on July 28, 2024

from 42.

PeteBlanchard avatar PeteBlanchard commented on July 28, 2024

from 42.

ericstoneking avatar ericstoneking commented on July 28, 2024

from 42.

PeteBlanchard avatar PeteBlanchard commented on July 28, 2024

Fair enough. Thanks.

Will be interested in Mark's thoughts too.

from 42.

msuder avatar msuder commented on July 28, 2024

Hi Pete -

I thought about responding, but Eric pretty well summed up my thoughts. I will say that cFS is a very useful framework with an active github community; so you might ask the experts over there: https://github.com/nasa/cFS.

That said, with the little experience I have with cFS, I think you have options. cFS typically is the flight software on the spacecraft C&DH computer, but it would not necessarily need to relay all the data (e.g. from a science instrument)... if you had a mass storage device connected to the instrument, that could directly write to your radio and cFS could be used to just orchestrate the transfer and not really handle the data at all (eliminating routing through the C&DH as a potential bottleneck). On the other hand, cFS supports an "app" (in the cFS parlance) called CFDP (https://github.com/nasa/CF) which can do some of the typical file handling things you might think of (ala FTP or SCP) but with the data being handled through cFS. Or you could do your own homegrown thing using the cFS framework. Again, the cFS folks could probably give you way more details, information, options, and thoughts.

Can I ask what you are putting all these pieces together for?

  • Mark

from 42.

PeteBlanchard avatar PeteBlanchard commented on July 28, 2024

We are building a software testing environment that simulates a satellite and its associated subsystems.

from 42.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.