Project [In finalisation]Solar modules P3/P4/P5/P6 from ISS

[Russ_H]

Hi, Brian

From my research I found that docking ports do not rotate with the ship, but attachment points can be rotated. I am happy to see you take this project over to be honest I got in over my head on this project and could not finish it. Mustard is a good guy to work with.

Russ

 

[BrianJ]

Mustard: Merci pour les vids et infos. Je t'écrirai bientôt

The ISSU project plans to make an ISS that actually generates/stores/uses/depletes power. Solar tracking was one of our wishes, but I don't know what else would be needed in order for the arrays to actually generate & send power to the batteries.

Hi Pete,
an ambitious project, to be sure! Well, I'm no C++ whizz - all I can do is make .dll's for Orbiter, working within the OrbiterAPI.
As far as power generation from the Solar Panels goes, I guess it will be (roughly)proportional to the sine of the angle of incidence of the Sun on the panels (and zero during eclipse). You could calculate that in an MFD(or seperate vessel) if you know the rotation angles(animation states) of the Panels. However, I don't see any GetAnimationState() type functions in the OrbiterAPI (unless someone out there knows better!).

What I could do, as a workaround, is create a "zero-thrust thruster" for the P3/P4 module and set the thruster level proportional to the
Sun->Panel angle (or sine thereof). You could then use the GetThrusterLevel() function to read it from an MFD,etc.

Maybe someone who knows more about C++ can suggest a better way.

Hi, Brian
From my research I found that docking ports do not rotate with the ship, but attachment points can be rotated. I am happy to see you take this project over to be honest I got in over my head on this project and could not finish it. Mustard is a good guy to work with.

Hey Russ,
Well, you weren't doing so bad , as far as you went. I've done the rotating attachment points, sun tracking,etc. before so I know where I'm going. You need to make friends with the sine/cosine functions and google for "vector rotation"! ;-) And, yes, I've worked with Mustard before, always a pleasure to code for his beautiful meshes.

Cheers,
Brian

 

[tblaxland]

Maybe someone who knows more about C++ can suggest a better way.

I suggest that ISSU queries your module for a vector (in ecliptic frame) representing the direction of the normal to panels. ISSU can do their own calcs for the power generated based on this. An alternative would be to calculate the power in your module and have ISSU query that (this would allow you to do things like damage/failure simulation in your module).

As for the communication between modules, you have two options: DLL exports or KeyComm (http://www.orbiterwiki.org/wiki/KeyComm). I tested both when developing my Ananke and Ananke Control modules but ended up settling on DLL exports because it simplified the code (they both worked fine, BTW). The downside to DLL exports is that it would require ISSU to use headers/libraries from your project. KeyComm is probably a much better solution for this application.

I had a discussion with various developers about it here:
http://www.orbiter-forum.com/showthread.php?t=2654&highlight=communication

 

[BrianJ]

Thank you, tblaxland! I'll see if I can get my head around the KeyComm code.

I have a minor question regarding attachment points, specifically the Atlantis RMS arm.

Has anyone noticed any bugs with the Atlantis RMS arm when "handing over" a vessel (child) to another vessel (parent)?

In the Orbiter API_Reference.pdf it says (page 81)

"A child can only be connected to a single parent at any one time. If the child
is already connected to a parent, the previous parent connection is severed."​

However, if I use the Atlantis RMS to move a child vessel next to the attachment point of a parent vessel and attach them (parent vessel->child vessel, attaches OK) then move the Atlantis RMS away without pressing the "release" button on the RMS panel, the child vessel becomes distorted. As though the child vessel is still attached to the RMS arm.

Pressing the RMS "release" button after that leaves the child vessel in a distorted condition until it is released from the parent vessel.

Exiting and restarting the scenario also fixes the problem.

I tried adding some code to the parent vessel to detach any other parents from the child vessel when it is attached, but this creates more problems when trying to re-attach the RMS arm to the child vessel.

Has anyone else noticed anything like this?

It's not a major problem I guess - you just need to remember to "release" the RMS arm after the child vessel is attached to the parent vessel. Quite realistic I suppose. But it seems to go against what the API_Reference says.

Note: the child vessel is purely .cfg based, with attachment points

BEGIN_ATTACHMENT
P 0.0 0.6 1.9  0 1 0  0 0 1 XS ; for shuttle bay
P -0.1 -1.124 0.747   0 -1 0  0 0 -1 GS ; for shuttle rms
P 0.0182 0.543565 -0.2912  0 1 0  0 0 1 MM ; for parent vessel
END_ATTACHMENT

Cheers,
Brian

 

[BrianJ]

As for the communication between modules, you have two options: DLL exports or KeyComm (http://www.orbiterwiki.org/wiki/KeyComm). I tested both when developing my Ananke and Ananke Control modules but ended up settling on DLL exports because it simplified the code (they both worked fine, BTW). The downside to DLL exports is that it would require ISSU to use headers/libraries from your project. KeyComm is probably a much better solution for this application.

I had a discussion with various developers about it here:
http://www.orbiter-forum.com/showthread.php?t=2654&highlight=communication

Hi,
I've managed to get the KeyComm code working for an MFD that scans for any vessels using the P3P4 .dll and displays their power outputs (and gives a total for all arrays) but I have a problem I just can't find a way around.
---------------------------------------------
EDIT: Solved! see end of post
---------------------------------------------

Everything works fine until I use a scenario which includes a purely .cfg based vessel (i.e. ISS_ProjectAlpha, Mir, Ldef, etc) - this gives a CTD.

Scenarios inc. vessel's that use a .dll (Shuttle Atlantis, DeltaGlider, ShuttlePB) are fine.

I assume this is related to the VESSEL/VESSEL2 problem mentioned in the thread in tblaxland's post above.

I can't seem to exclude any non-VESSEL2 vessels before I send a clbkConsumeBufferedKey() call. (which causes CTD in non-VESSEL2 vessels, I think)

I've tried this code for the initial implementation of the MFD which should get the "name" of the first vessel it finds using the P3P4 "identifier key" COMM_SOLARRAY_IDENT.

// ISSSPMFD implementation
ISSSPMFD::ISSSPMFD (DWORD w, DWORD h, VESSEL *vessel)
: GraphMFD (w, h, vessel)
{
 
int vc = oapiGetVesselCount();
for(int i=0;i<vc;i++)
 {
  OBJHANDLE ves = oapiGetVesselByIndex(i);
  VESSEL2* v =(VESSEL2*)oapiGetVesselInterface(ves);
 if (v == NULL); // if not VESSEL2, do nothing.
else{ 
      if((v->clbkConsumeBufferedKey(COMM_SOLARRAY_IDENT,false,(char *)&ident)) == 1)
      {
       oapiGetObjectName(ves, vesname, 30);
       break;
      }
    }
  }
 
}

Above code works for scenarios with Shuttles, DeltaGlider, ShuttlePB, etc
but causes CTD with ISS_ProjectAlpha, Mir, Ldef, etc.

Can anyone show me how to exclude non-VESSEL2 class vessels?

VESSEL2* v =(VESSEL2*)oapiGetVesselInterface(ves);
 if (v == NULL); // if not VESSEL2, do nothing.

doesn't work :-(

Many thanks,
Brian
---------------------------------------------------------
EDIT: This solution

OBJHANDLE ves = oapiGetVesselByIndex(i);
VESSEL2* v =(VESSEL2*)oapiGetVesselInterface(ves);
int vv = v->Version();
if (vv == 0);

v->Version() returns a 0 or 1 depending on "version". Version 0 seems to include all vessels that cause a CTD with v->clbkConsumeBufferedKey.

 

[tblaxland]

int vv = v->Version();

Interesting, thanks mate. I'll have to add that to my list of undocumented functions.

 

[Mustard]

I would like just say you that P3/P4/P5 are finish. BrianJ Completed the work of RussH. The both did a awesome work and i congrat them for their great help and participation.
For information, the solar panel include a electric power managment and a sun tracking.

However, i delay the release because i will add P6 (in progress). It very similar to P3P4 but without rotation. So the adaptation could be very easy and quickly.
I expect a release for mid feb.

 

[Mustard]

Model P6 is finished. BrianJ is working on the coding. P6 is very similar to P3P4 so i hope that it will be easiest.

Remember:
P3P4: solar module with the SARJ rotation
P5: intermediate module to dock a adding solar module
P6: solar module solaire without SARJ.
In a truss with 2 solar modules only one SARJ is necessary on the beginning to rotate all.
note that on ISS this modules are named P or S depending the position Port or Starboard on the station. In a first time i chose "P" but finally this module will rename by ITS# (Integrated Truss Structure), official designation by Nasa. In your scenario file you will can name each module by S# or P# or a other name.
So this is the pic of the final model of ITS6 (undeployed)

Status:
ITS 3-4: 100%
ITS 5: 100%
ITS 6: model 3d finished. Coding in progress
Estimated release: mid-february or last half of feb.

 

[Whatu]

Awesome work!, as always. Its looking very very good!
Can't wait for it :lol:

I smell a Tuesday is coming...

 

[Orbinaut Pete]

Awesome Mustard

 

[Mustard]

Thanks. BTW, BrianJ added the sun tracking and the power electric. A "Must" for the space station builder.

 

[Mustard]

BrianJ sent me the first final beta. I don't have check all yet, but that's seem good. If all is good i must realize a manual (Fr & En) and we can estimate a release for this week end.

 

[Mustard]

Arrive this Monday (9th Feb)

Included:
-Solar Module P3P4 with SARJ
-Intermediate module P5
-Solar Module P6
-Sun tracking (SARJ + BGA)
-Electric power managment
-Manual (Fr & En) for installation on a SpaceStation

 

[DoyleChris]

Sweet Can't Wait

 

[the.punk]

Yeahh.:speakcool:
Can't wait until it's Monday.

 

[Orbinaut Pete]

I think release should be postponed until TUESDAY, for the sake of tradition

 

[Mustard]

I think release should be postponed until TUESDAY, for the sake of tradition

The manual is very difficult to realize and i must translate it. so Tuesday is possible. It's good for the tradition

 

[Russ_H]

Hi

Brian and Mustard are good guys and are being so nice to me. When I handed off the project to Brian do to the fact that I am a new programmer he thought it best to rewrite most of the code. I understand this because I was having a lot of trouble finishing the project. I don't think it is fair to them to have to put my name on this project.

Thanks Mustard and Brian even though I have failed on this project I feel good about the friends I have made.

Russ

 

[Mustard]

Hi

Brian and Mustard are good guys and are being so nice to me. When I handed off the project to Brian do to the fact that I am a new programmer he thought it best to rewrite most of the code. I understand this because I was having a lot of trouble finishing the project. I don't think it is fair to them to have to put my name on this project.

Thanks Mustard and Brian even though I have failed on this project I feel good about the friends I have made.

Russ

You work was great and you did all anims of each foils and part of P3/P4. It was an enormous job. BrianJ made the final work, probably the hardest part of coding but your work helped him to win lot of time. I remember that he said me that your work was great.
This addon merit your name like a co-author. thx for your participation.

Note: the manuals fr and en are finished, probably a release this sunday, on the evening.

 

[BrianJ]

Hi

Brian and Mustard are good guys and are being so nice to me. When I handed off the project to Brian do to the fact that I am a new programmer he thought it best to rewrite most of the code. I understand this because I was having a lot of trouble finishing the project. I don't think it is fair to them to have to put my name on this project.

Thanks Mustard and Brian even though I have failed on this project I feel good about the friends I have made.

Russ

Hmmmm, let me re-iterate part of a message I just sent to RussH.

Russ did 90% of the necessary coding and optimization work to get this project operational. If I'd had to start from the beginning, you'd still be waiting for this to be released come Christmas 2009.

Simple as that.

Cheers,
Brian