Meadville Space Center
Welcome, Guest. Please login or register.
October 25, 2020, 06:40:06 AM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development (Moderators: movieman, Tschachim, Swatch, lassombra)
| | |-+  V8 Release Work Thread
« previous next »
Pages: 1 [2] 3 4 ... 16 Print
Author Topic: V8 Release Work Thread  (Read 24342 times)
thewonderidiot
Full Member
***
Posts: 48



View Profile
« Reply #15 on: January 20, 2017, 02:19:48 PM »

SbyPressed currently needs to be reset by whatever DSKY you have as soon as PRO is released. If it's left high the computer will come right back out of standby after one period of F17B (0.78 seconds).
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #16 on: January 29, 2017, 06:52:04 PM »

I easily solved that by adding in an else case in our agc_engine.c to automatically reset SbyPressed when the channel state is high. Now I can get the Standby state set, but the STBY light still comes on early, and the DSKY should blank after Standby is enabled, right?

That's some progress made, though.

EDIT: In addition, when the PRO is held to enable Standby, it's enabled for a little while, but then Standby is exited to F 37. This indicates that the engine isn't able to distinguish from a held PRO in this circumstance.
« Last Edit: January 29, 2017, 07:22:05 PM by eddievhfan1984 » Logged
thewonderidiot
Full Member
***
Posts: 48



View Profile
« Reply #17 on: January 29, 2017, 08:41:59 PM »

Your standby light is probably controlled by output channel 13 bit 11, which is set at entry to P06. This bit is what enables standby to be started via PRO depression. The VirtualAGC agc_engine.c and yaDSKY2 use the new fake output channel 163 to simulate these hardware (rather than software)-controlled lights. The STANDBY light is bit 9 (00400) of that channel. Indy mentioned that he used channel 163 for something else, though, so there might need to be some renumbering somewhere.

As far as lights going off -- that happens because the DSKY receives the AGC's switched 14V rail for use in its EL power supply. When +14VSW stops providing power, the EL segments all go off. yaDSKY2 doesn't do this yet... it's on my TODO list. But basically you'll just want to manually switch them off whenever State->Standby is 1, and restore their previous state when it goes back to 0. EDIT: Actually, you could just dual-purpose the STANDBY light bit in channel 163 for this.  Happy

As far as your edit -- I'm not sure if I'm reading it correctly, but it is possible to go straight through standby and back out into the V37 program selection if you just keep holding PRO down.
« Last Edit: January 29, 2017, 08:49:55 PM by thewonderidiot » Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #18 on: January 29, 2017, 09:49:43 PM »

That was the case prior to the edit, except the state of the PRO switch was latched on, causing a near-immediate return to F 37. The edit just permitted the system to remain in standby mode after PRO was released.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #19 on: February 24, 2017, 09:24:39 AM »

There are a few Orbiter 2016 specific problems we should look into first:

-Accelerometers. Our implementation of accelerometers used everywhere (EMS, IMU, LV IMU etc.) seems to have some problems. While it still seems to be fairly accurate overall, it is always oscillating. Most noticable this is during the reentry on the EMS scroll. There are some extreme peaks on the G-axis of the scribe, so much that the EMS becomes fairly useless. Our accelerometers use the average of the GetWeightVector() function in two timesteps, or something like that. That seems to have been a fix necessary for Orbiter 2006 and it doesn't seem to work quite as good anymore. We might even be able to use a more simple implementation of accelerometers now in Orbiter 2016, but in any case we might have to rework all our accelerometers. Does someone want to look into this issue?

-Orbiter 2016 bug. The same GetWeightVector() function seems to be buggy in Orbiter 2016. Before a vehicle has moved (engines being fired, landing gear operated etc.) this returns a zero vector. I created a bug report: http://orbiter-forum.com/project.php?issueid=1318 and we might have to wait until this is fixed or use a different accelerometer implementation before we can really solve our launch problems. In NASSP this issue means that the EMS Tests on the launchpad can't be done (it's even bad without the GTA switch) and I think this also causes issues for the LVDC++, because it doesn't measure the weight acceleration from GRR until thrust buildup. At that point the weight vector starts returning something useful, but the IU state vector is already veeery bad. This might be part of our bigger launch issues.

-Touchdown point definition. The way touchdown points work in Orbiter 2016 is very different and more realistic. So we need to give our vessels new parameters, the old ones won't really work. Look for SetTouchdownPoints() in the Orbiter API reference. This seems like a nice little project that doesn't require all that much coding. So again, any volunteers?
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #20 on: February 24, 2017, 03:58:55 PM »

Is there a GetAccelerationVector in the new API?
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #21 on: February 24, 2017, 04:09:48 PM »

AFAIK, the weight vector stuff was a work-around for Orbiter 2006, as GetForceVector didn't work for docked vehicles in 2006. See here-> http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2127.msg21910#msg21910
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #22 on: February 25, 2017, 08:29:59 AM »

The instability results from this line of code:

Code:
dvel = (vel - lastGlobalVel) / simdt;

This is the difference between the global velocity of this timestep and the last timestep. The dvel is then compared with the weight vector for the acceleration. This "dvel" is the source of the oscillation. And it's not a frame rate issue, this happens with a steady 60 fps. The systems that use accelerometers get called in clbkPostStep, so maybe something is weird there with the global velocity.

Even without this workaround, if we use GetForceVector() and only the force vector from this timestep, the calculation gives the exact same result, because the acceleration, "dvel" from above, is still subtracted from the force/weight vector. If we find the issue with dvel and the global velocity vectors then we can try if GetForceVector() is working for docked vessels now, which would probably allow some simplifications for our accelerometers.

EDIT: Actually, the oscillation is much larger in Earth orbit than somewhere during translunar coast. Makes sense of course, the global velocity vector, especially the direction, will change much more during one timestep in LEO.
« Last Edit: February 25, 2017, 09:18:42 AM by indy91 » Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #23 on: February 25, 2017, 10:55:10 AM »

Am I just thinking wrong, but why don't we do it the simple way? a = F/m, or total force vector divided by current vehicle mass. This should give us the acceleration directly, without any dvel or something. Of course, this will only work if GetForceVector works with docked vehicles.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #24 on: February 26, 2017, 05:38:16 AM »

Accelerometers are measuring accelerations relative to free fall, in relativity terms a "proper acceleration". GetWeightVector and GetForceVector are returning the actual forces that are acting on the spacecraft. If you would simply use this acceleration for accelerometers then pointing the spacecraft at the Earth would result in a measured acceleration of 1G.

So instead our accelerometers are taking the difference between the weight acceleration and the global velocity difference since the last timestep as the measured acceleration. Right now it goes even further, because it also uses the weight vector of the last timestep to calculate this measured acceleration and then it takes the average between these two calculated measured accelerations.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #25 on: March 04, 2017, 11:55:23 AM »

For the V8 work on orbiter 2016, will I need to change anything to make pull requests in git?  Or will my current git setup allow me to make them for the 2015 branch?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #26 on: March 04, 2017, 02:17:28 PM »

If your current git setup is in your Orbiter 2016 folder and you are following the Orbiter2015 branch then you should be good. Otherwise you need to set up your Orbiter 2016 folder with git as you did for Orbiter 2010. But instead of using the master branch you have to use Orbiter2015. Then any pull requests can be made from rcflyinghokie:Orbiter2015 into dseagrav:Orbiter2015.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #27 on: March 05, 2017, 07:36:28 AM »

If your current git setup is in your Orbiter 2016 folder and you are following the Orbiter2015 branch then you should be good. Otherwise you need to set up your Orbiter 2016 folder with git as you did for Orbiter 2010. But instead of using the master branch you have to use Orbiter2015. Then any pull requests can be made from rcflyinghokie:Orbiter2015 into dseagrav:Orbiter2015.

I don't know if its set up the same or not, I had git set up for both branches.  I am going to push an Apollo 9 checklist file and LM Checklist file to test it, bear with me!

It will not let me add the Orbiter 2015 branch, it is telling me it doesnt exist.  And when I try with my existing setup none of my changes show up as staged changes to commit.
« Last Edit: March 05, 2017, 07:42:41 AM by rcflyinghokie » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #28 on: March 05, 2017, 08:01:37 AM »

The Orbiter2015 branch is always part of the repository, so you don't really need to add it in any way. Are you trying to add a remote repository with that name maybe? Because that won't work.

What you need to have is a seperate Orbiter 2016 folder and set up git there just as you did with Orbiter 2010. But instead of using the master branch use the Orbiter2015 branch. I really can't recommend using the same folder for both branches, you will just break your NASSP 7.0 version. So this thread (http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2864.0) still applies but replace "master" everywhere with "Orbiter2015".
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #29 on: March 06, 2017, 08:51:02 AM »

The Orbiter2015 branch is always part of the repository, so you don't really need to add it in any way. Are you trying to add a remote repository with that name maybe? Because that won't work.

What you need to have is a seperate Orbiter 2016 folder and set up git there just as you did with Orbiter 2010. But instead of using the master branch use the Orbiter2015 branch. I really can't recommend using the same folder for both branches, you will just break your NASSP 7.0 version. So this thread (http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2864.0) still applies but replace "master" everywhere with "Orbiter2015".

Thats already how I have it set up, I just thought it wasnt working because unstaged changes arent showing up on my end when I make them.  When I replace "master" with Orbiter2015 for example in "git checkout Orbiter2015" it tells me "error: pathspec 'Orbiter2015' did not match any file(s) known to git."
« Last Edit: March 06, 2017, 08:53:37 AM by rcflyinghokie » Logged
Pages: 1 [2] 3 4 ... 16 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!