Request staging via message from another CPU

[Patrykz94]

I'm working on this functionality on my fork which would allow another CPU to request a stage separation while in the atmospheric guidance mode (before UPFG converges).

This feature is useful in my project (landing a rocket booster) because I need to separate before the fuel runs out in the first stage and I don't know the separation time in advance (well, I can figure out a few seconds in advance). Not sure how useful (if at all) it would be to anyone else but if you want, I can send a PR when it's done.

In case this is something you'd like to add to the main PEGAS script, I wanted ask what would be a good way of implementing this? My current plan is to add a WHEN trigger running in the background and checking if the message queue is not empty. Once it receives a message with staging command, which could be either a string "stagingRequested" or maybe a list/lexicon which also contains the staging time, it would change the control["upfgActivation"] to the new desired staging time (either now or a few seconds in advance), and also change the nextStageTime global variable to the new value.

I haven't had a chance to test this yet but looking at PEGAS code, I guess that would hopefully work.

Would you be interested in this to be added to PEGAS?

[Noiredd]

Yes, this is interesting. If this is something that will make it possible to launch a fully automatic ascent with first stage landing and second stage insertion - go for it. I think the way of doing it which you proposed is okay; I'd only ask you to try and keep as much code as possible in pegas_util.ks and only put the most important things in pegas.ks - it's very easy to clutter the main file if one's not paying attention ;)

Before you start however, can we think of other situations where a cross-CPU communication would be useful? Would be nice to do this in a more general way if it allows more features in the future.

[Patrykz94]

I made a very simple version of it for testing a few days ago which mostly works, although I just noticed that while the "Initiating UPFG!" message appears straight away, the thrust is not actually cut until a few seconds later. May be because I'm trying to do it without any advance. Will need to read over PEGAS code again to better understand how it's actually dealing with staging and initiating UPGF (probably tomorrow).

I also got PEGAS to send a message with it's liftoff time once it's calculated (needed that in landing script), and I'm sure there could be other things that could be done with this. Let me know if you have any ideas for that.

Here's a quick and dirty version of what I added so far. And yeah... it's all in pegas.ks at the moment, I'll try to minimize the use of that file.

[Noiredd]

Delay between the message and actual UPFG activation is on purpose - read this bit in particular.

Your "quick and dirty" version looks okay. What I would do differently would be to make it a function in pegas_utils.ks and just have it called once. setComms(), maybe?

In the future, the body of a WHEN could be relocated into a separate function, much like my current event execution system, which works like this:

• an event handling mechanism is initialized (setUserEvents) by setting a trigger,
• trigger body sets a flag (userEventFlag) informing that an event has happened,
• main loop encounters a flag and calls an event handling routing (userEventHandler).

I can imagine something like this for a more flexible communication system. But maybe let's not go that far just yet since we don't know what else would it be supposed to do - the current implementation is okay ;)