Flowchart: Sun position from rotor angle

I made a flow chart. Red arrows mean a delay (in actual P-block code, end of current execution)




This flowchart depicts what I currently believe would be a way to make an somewhat efficient self aligning solar array possible.


Thoughts?

 

Sigurd Hansen on the workshop already has a very good automatic aligning program.
https://steamcommunity.com/sharedfiles/filedetails/?id=367344570
I was watching the efficiency like a hawk, I set his program to get the panel to 119kW and it followed through. I tried 120 for maximum power but the way rotors bounce back and forth its practically impossible.

 

Now the option you want to copy the axis of the rotors and send them to other sets would be a nice addition to his program.

 

The sun is always in the same direction, so no need to hunt for it. If you look in "Environment.sbc" under the game folder (don't remember the exact path), you can find the direction:

Code:

<SunDirection x="0.339467347" y="0.709795356" z="-0.617213368" />

If you know your rotor geometry, and you know the solar panels' orientation (ahem, shameless plug), then you should be able to calculate the exact angles without having to search and rely on DetailedInfo parsing.

I don't know if mods change this direction, so if you use any you might have to check them too.

 

I have seen references to skybox mods that do that, that's why I don't want to use hardcoded parameters.

That's why I added ±10° to the flowchart for angle transfer.

 

I simply used several small solar panels as sensors, meassure their output and generate a sun intensity vector over all solar panel directions. That vector is local and thus determines in which direction i have to turn.
No need to name and define any block and or orientation as all that is done within the code.

Also i am no friend of these static sun vectors myself and thus design my concepts to variable environments too.

 

While that works and is actually pretty clever, my point was it's waste of resources when you can calculate the angles you need on the rotors with any cheap scientific calculator. (Assuming we're talking about stations here and not ships.)

In fact, instead of having to tolerate the shaking of the rotors (for large arrays), you can build a static structure instead that points the panels in the right direction with no shake. I just finished this last night for my 100MW solar array.

How do you know which rotors to operate on, then?

I hardly think a "space engineer" wouldn't know precisely which direction the sun was...

 

Well i dont use rotors to orient, i use gyros. While i use ships only that orient toward the sun, that is also applicable to station-linked structures through rotors with a break moment.

Also a "space engineer" wouldnt have a universal grid to align to, only relative positions in relation to each other. So yes, they would know where the sun comes from relative to them, just like my approach did it. They would however not know that the sun is always coming from direction XY, no matter where in the universe they are right now. That counts for the real world of course and not ingame.
Also once there is a proper mod that changes the suns location like i would love to see, the static approach wouldnt work anymore. Also this game is about engineering. Not just making a good model that works under certain conditions but ones that work under multiple conditions. At least for me that is.
It sure is good engineering if the application fulfills the job with given conditions, though what these conditions are varies here. I want flexibility and am willed to sacrifice a bit of performance.

 

Uh yes, they would. It's called the stars and sailors have been doing it for centuries (and astronauts for less).

(And before you say it, yes, I know this is still technically relative. But on the scale of the solar system, it may as well be fixed.)

And what makes you think the sun should move? If you assume the frame in which our stations rest (and our ships move relative to) is rotating with it's (circular) orbit, then the sun would certainly be in fixed position relative to that frame. If you want an example, look no further than the moon (locked to the Earth).

Yes, engineering. Solving the problem at hand, with the resources available under the given constraints. What you are doing is over-engineering: Solving a (harder) problem that doesn't exist (though maybe it will, some day).

Not that there's anything wrong with over-engineering... other than, as I said, wasting resources.

 

Yay! Time to get pedantic. I love pedantry.

Real-world orbits are neither circular nor perfectly elliptical. Even moon's relative facing to the Earth wobbles over time. Complex interactions between the many orbital bodies in our solar system result in irregular orbits. Perfectly modeling these interactions is a non-trivial job, so if your goal is to find an absolute maximum, it's much simpler to test, make a guess, and iterate slowly, until you reach a solution that is "good enough".

Since the game is a very poor reflection of reality, then yes it's good enough to use the static vector to the sun, pre-calculate the angles to face it ideally, and orient your solar panels. It's ideal, but brittle.

It's also good enough to take a guess, test, and iterate. It's less optimal, but less brittle with respect to likely future problems.

Speaking strictly for myself, I prefer more robust solutions when they aren't onerous to implement. The pedantry of weighing the two approaches, however, reminds of a joke.

A physicist and an engineer, both cis-gendered men, are propositioned by a woman. She stands a distance away and offers a kiss to the first one who can reach her, but they may only approach her as she signals them, and may only cross half the distance to her with each signal. The men agree to the rules, and she gives the first signal. The engineer takes off at a sprint, covering half the distance while the physicist stands there. The woman signals again, and again the engineer sprints the half-remainder of the distance while the physicist stays put. Several iterations pass, the engineer moving quickly while the physicist just shakes his head and smirks. Finally, the engineer turns around and asks, "Why aren't you moving?!" The physicist replies, "Because you'll never cross the entire distance, it's mathematically impossible." To which the engineer replies, "Sure, but I'll get close enough for all practical purposes!"

/rimshot

 

Alright even though i wrote more already, i will write just that as i dont want one of these overly annoying ping-ping-discussions about opinions and whatnot.

SE is a sandbox game and you can achieve your goals the way you want. I want it a way that feels "right" to me, you can use whatever approach you want.

 

At the time scales and distances we're dealing with in this game, we're "close enough for all practical purposes!"

Perhaps you missed my point: his feeling that the current system is unrealistic is based on the assumption that we are non-tidally locked, but orbiting reference frame. I was simply pointing out that under different assumptions, the system could be considered realistic.

In the real world, maybe. But this isn't the real world, so the situation is exactly the opposite. It is much simpler to calculate, one time, the rotations needed for optimal solar panel placement. The proposed iterative solution is significantly more complicated.

It's only brittle if the conditions could change enough to break it. Since the sun's direction can't change, it can't break, thus not brittle.

If the game adds the possibility for the sun to move, I would likely use a similar dynamic approach as proposed. But why waste time and effort solving the problem when it doesn't exist yet!

My solution only needs a few minutes with a calculator. The other proposed solution requires a timer block, programmable block and a bunch of custom code. One seems much more "onerous" to me...

Funny, but off point. We're not arguing theory vs. reality here, but rather reality (as implemented in the game) vs. future realism (as some people hope to be implemented).

That's fine and I certainly won't deny you that. But you were (or atleast, seemed to me) denying my desire to use the simplest solution because it offended your sense of rightness, which is what set me off. If we can agree to disagree for roleplaying reasons, I'm fine w/ that.

---

Anyways, enough of that. I did have a question that occurred to me: How do you handle if one your "sensor" panels gets occluded. That would throw off your direction vector, yes?

 

The issue at hand prompting me to propose ways to find the vector of the sun is simply the possibility to find servers with off-standard vectors.

 

The solar vector is still fixed, just different. So if it were me (and I was unwilling to look up the value in the game files), I would use plaYer2k's method w/ 3 perpendicular solar panels to find the vector. Then hard code that vector in any of my constructions.