ENG: Update Loop

[StefanDeYoung]

Engineering should be able to run an update function on a given frequency to:

1. Read the value of all switches
2. Receive data from other programs (Fuel amount, In atmosphere, Master Alarm, etc.)
3. Send data to other programs
4. Update the Engineering display

Desiderata:

1. Figure out how to do the update loop in tkinter only, in case Engineering is running stand-alone for training
2. Figure out how to trigger the update loop from the Physics Server

[pmelanson]

1. What does desiderata mean

2. My thought for how to do the simulation is that we just include engineering simulation stuff in the existing physics simulation loop. The benefit is we don't have to duplicate the IMO too-intricate simulation loop logic (with its threading and such). Also,

• in a networked context (with hab/MC flight etc also running) the physics server can continue to be the centralized and authouritative server, which simplifies things for people setting up the network. (Currently with OrbitV, hab engineering is the authouritative copy for some parts of the simulation, and hab flight is authouritative for other parts, and it's just confusing!)

• in an unnetworked context i.e. singleplayer training mode, we can just run the simulation locally. Maybe we could even simulate just the hab, AYSE, and the Earth to make the simulation faster, since we won't be representing mars, Jupiter, etc in engineering training.

How does this sound? The main hangup I see is that the current simulation infrastructure relies being able to create a derivative function of the state of the universe. For physical locations, that's as simple as

d/dt(position, velocity) = (velocity, acceleration)

But I am emphatically NOT an electrical engineer, so we should make sure we can actually make such a derivative function to describe the hab and AYSE power grid. That seems like a thing that's possible though(?) But if it's not, we'll have to rethink.

[StefanDeYoung]

1. Desiderata is latin for "the things desired." I've heard it used mostly in math contexts. For example, at the start of a proof you might lay out what you want to prove as the desideratum. 2. I agree wholeheartedly to making Physics Server the single authoritative update loop. It just makes sense. 3. We should be fine to create derivatives. I'm pretty sure most electrical concepts like voltage, current, resistivity, and temperature are usually continuous and smooth. If we introduce capacitance and inductance, then we will _need_ derivatives! I considered importing PySpice, which is an interpretation of SPICE, a circuit profiling software. In the end, I don't think that SPICE gives us what we want. It's usecase is to do short simulations of a circuits response to various inputs, to allow iteration in the design of the circuit. I don't think that our simulation should be as fine-grained as to depend on the actual model numbers for electronics parts.

…

On Sun, Jul 5, 2020 at 4:50 PM Patrick Melanson ***@***.***> wrote: 1. What does desiderata mean 2. My thought for how to do the simulation is that we just include engineering simulation stuff in the existing physics simulation loop. The benefit is we don't have to duplicate the IMO too-intricate simulation loop logic (with its threading and such). Also, - in a networked context (with hab/MC flight etc also running) the physics server can continue to be the centralized and authouritative server, which simplifies things for people setting up the network. (Currently with OrbitV, hab engineering is the authouritative copy for some parts of the simulation, and hab flight is authouritative for other parts, and it's just confusing!) - in an unnetworked context i.e. singleplayer training mode, we can just run the simulation locally. Maybe we could even simulate just the hab, AYSE, and the Earth to make the simulation faster, since we won't be representing mars, Jupiter, etc in engineering training. How does this sound? The main hangup I see is that the current simulation infrastructure relies being able to create a derivative function of the state of the universe. For physical locations, that's as simple as d/dt(position, velocity) = (velocity, acceleration) But I am emphatically NOT an electrical engineer, so we should make sure we can actually make such a derivative function to describe the hab and AYSE power grid. That seems like a thing that's possible though(?) But if it's not, we'll have to rethink. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALCBTKIUPO2DMHO7B7MN33R2DRSDANCNFSM4OQDLE2A> .

[pmelanson]

dang, pyspice does sound cool though, but agree unfortunately :<

oh by the way, did you find the definitions of the electrical properties of all the switches and stuff in OrbitV? I seem to recall it was in orbitsej.txt but can't actually find that or a similar text file when I looked around a little bit last week. Want me to help with deciphering that code?

[StefanDeYoung]

Yeah! Absolutely! Let's talk about it at tonight's (July 6) meeting? Coincidentally, I saw Dr. Magwood by video chat this weekend, and mentioned to him my difficulty decoding the switches matrix. He might be able to provide us a reference doc. :D

…

On Mon, Jul 6, 2020 at 12:40 PM Patrick Melanson ***@***.***> wrote: dang, pyspice *does* sound cool though, but agree unfortunately :< oh by the way, did you find the definitions of the electrical properties of all the switches and stuff in OrbitV? I seem to recall it was in orbitsej.txt but can't actually find that or a similar text file when I looked around a little bit last week. Want me to help with deciphering that code? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALCBTJH6UC4FLFJEDBFTP3R2H46PANCNFSM4OQDLE2A> .

[pmelanson]

Action item for next week:

can someone with like five phds figure out how to model the current, temperature, resistance, and voltage for the system of components. The best way would probably be to define the derivative for all four in the system.

For example:

    def our_deriv_func(orbitx_state):
        t = orbitx_state.engineering['INS'].t
        r = orbitx_state.engineering['INS'].r
        i = orbitx_state.engineering['INS'].i
        v = orbitx_state.engineering['INS'].v

        t` = eta * (i**2)*r
        r` = alpha * t`

        v` = 0(?)  # <--- figure this part out

        i` = (r`*v - r*v`)/(v^2)

[pmelanson]

I'll add some accessors to implement orbitx_state.engineering['INS'] and other things like that.