Dragon 2 ISS docking simulator

[CorvusCorax]

"5512" -- engage auto-docking sequence - for those who are lazy

When I tried this it didn't work as intended. First I tried 5512 and then <Enter>, then I tried plain old 5512 without <Enter>. Both times yaw, pitch and roll all started drifting farther and farther from zero. Translation stays where it started with no change.

In the original sim with no mod/user script installed?  Do you have any other extensions (addblockers, no-script, ...) that could be messing with it?

Which browser are you using?

The way SpaceX implemented that, the simulator is constantly monitoring key presses while its running and the window is active. Most actions are single key:

[w],[a],[ s ],[d] and [q],[e]  activate translational thrusters

cursor keys and [,],[.] activate rotational thrusters
so do [8],[4],[5],[6],[7],[9] on the number block with numlock enabled

but they also keep a history of last n keypresses if those are
5,5,1,2  then it would auto-warp to the docking port
e,a,r,t,h would toggle the earth shape
f,l,a,t,e,a,r,t,h would do the same, but since it ends in "earth" that's pretty redundant, dunno why that's in there

my mod added additional keys for functions you'd normally need a mouse click:
[y] or [z]  - toggle fine/course thrusts for translational thrusts
[x] - toggle fine/course thrust for attitude

and the following new functions:

[c] - reset timewarp factor to 1 (realtime)
[v] - reduce timewarp factor by 1/10 (no less than 1)
[ b ] - increase timewarp factor by 10 (no more than 1000)

Edit: Maybe I read your post wrong. The 5512 sequence does not zero your rotation vector. It puts you in the right place and orientation and will zero translation, but not rotation. Make sure you are not rotating before using that

[CorvusCorax]

Meanwhile at version 0.000008

New features:
- Navball now works properly
- When docking to PMA-3 the radiator goes into a configuration that allows colission-free access to the port
- In "Proper Orbital Dynamics" mode, ISS Solar panel now track sun over the course of one orbit. Also ISS reaches night side (previously the light was in a fixed position relative to ISS)

Unfortunately I didn't get earth shadow to work correctly yet, so ISS remains somewhat illuminated even during the night. That remains a TODO. But at least the earth below is dark.

[Rzeppa]

In the original sim with no mod/user script installed?  Do you have any other extensions (addblockers, no-script, ...) that could be messing with it?

Which browser are you using?

Edit: Maybe I read your post wrong. The 5512 sequence does not zero your rotation vector. It puts you in the right place and orientation and will zero translation, but not rotation. Make sure you are not rotating before using that

Yes, original sim with no mods. Firefox 76.0.1, only add-ons are Adobe Flash, Acrobat Reader and Ad Block Plus. Since I'm not an L2 member I whitelist this site. I do use private browsing most of the time, I can't think that that should make any difference to java.

I wasn't rotating prior to keying in the 5512, roll = 15.0°, pitch -20.0° and yaw = -10.0°, all static until I keyed in 5512 which caused all 3 to start increasing farther from zero.

The sim seems to work as-intended when docking manually. [shrugs shoulders]

[CorvusCorax]

In the original sim with no mod/user script installed?  Do you have any other extensions (addblockers, no-script, ...) that could be messing with it?

Which browser are you using?

Edit: Maybe I read your post wrong. The 5512 sequence does not zero your rotation vector. It puts you in the right place and orientation and will zero translation, but not rotation. Make sure you are not rotating before using that

Yes, original sim with no mods. Firefox 76.0.1, only add-ons are Adobe Flash, Acrobat Reader and Ad Block Plus. Since I'm not an L2 member I whitelist this site. I do use private browsing most of the time, I can't think that that should make any difference to java.

I wasn't rotating prior to keying in the 5512, roll = 15.0°, pitch -20.0° and yaw = -10.0°, all static until I keyed in 5512 which caused all 3 to start increasing farther from zero.

The sim seems to work as-intended when docking manually. [shrugs shoulders]

Hmm then the only thing I could think of is that you used the numpad keys (attached image, section 2). These are interpreted as "arrow keys" and will trigger attitude thrusters, only 5512 typed on the regular number keys (attached image, section 1) will trigger the feature - without accidently triggering any thrusters in the process.

by the way the other codes "earth" and "flatearth" will trigger translational thrusters (w,a,s,d) while being typed in, so if you wanna switch back and forth from conspiracy mode without changing your trajectory, you should do it via the settings menu

This is just a guess. I was doing all my tests on the laptop, and it doesnt even have a numpad like that, so I actually don't know what happens when one uses it.

and I managed to confirm this using a dekstop PC

With "numlock" OFF, the number pad will work like regular arrow keys, and produce the same key codes. So
"2" will pitch down
"4" will yaw left"
"6" will yaw right
"8" will pitch up

but the comma has no effect, only regular "," and "." on the main keyboard will adjust roll
typing "5512" on the number pad as such will cause the vehicle to pitch downwards due to "2" being pressed

with "numlock" ON, the number pad works slightly differnt. The attitude control keys now become
"4" will yaw left"
"5" will pitch down
"6" will yaw right
"7" will roll left
"8" will pitch up
"9" will roll right

typing "5512" now will cause a stronger pitch down since "5" is pressed twice

the "auto dock" is only ever triggered by pressing keys on the main keyboard.

[CorvusCorax]

Check this out : https://gist.github.com/CorvusCorax/d6e6e98c946b8bfad56563b514df23a9

Version 0.000009:

With the new "Challenge" feature (defaults to "Dock") you can now select "Rendezvous + Dock"

If you select this, Dragon will be placed in a circular deployment orbit, at 198 km above sea level, with a not insignificant phase angle to ISS.

This ups the ante, now you need to use the maneuvering Thrusters in manual mode for more or less all orbital operations - including ISS rendezvous (and you can also do de-orbit later, if you like )

But don't panic - there is now additional data displayed on the HUD, which allows you to get to ISS in a near optimal way.

I am pretty sure the real Dragon interface displays the relevant data somewhere as well. Probably not on the docking HUD overlay, but without a template how SpaceX displays that, I couldn't make it any more realistic than that.

By the way, I also fixed the bug in the sim with the high speed attitude thrusters messing up the HUD display. They now work correctly.

[CorvusCorax]

Before I forget, some fine tuning is possible in the Javascript Console of your browser.
The following variables can be interesting:

GMPhase - phase angle for rendezvous spawn position - in degrees - defaults to 11 - negative values put Dragon in front of ISS
GMOrbit - orbital altitude for the rendezvous spawn position - defaults to 198 - don't go below 80 though setting to orbits higher than ISS (450) is also fun.
GMPerigee - perigee and apogee for initial rendezvous spawn position - defaults to 190x205 now
GMApogee
GMInclination - side offset to the ISS orbit - in meters. Defaults to 300 - ish.  For significant inclinations, can be set to millions of meters. Might make the orbit wonky if you do, which won't make rendezvous easier.


Edit:  And I fixed the bug with the attitude thrusters in coarse-control mode breaking the HUD displayed rotation speed. That works correctly now.

[CorvusCorax]

updated to version 0.000010 - changed initial spawn orbit for "rendezvous" challenge to a very slightly eccentric 190x205 km

Edit: which makes it much harder the displayed parameters for a Hohman transfer assume a circular initial orbit. It will work if initiated at Perigee or Apogee, but will miss the ISS when used in between. So the best solution is to circularize the orbit first before going for the actual rendezvous transfer. But if you wait for apogee in the 190x205 deployment orbit, you'll have overshot ISS and need to wait quite a number of orbits - which makes it a several day transfer.

The way I manage the transfer quickest is by burning prograde right after spawn for an apogee between 375-400km circularize that at apogee, then do the rendezvous burn when the rndvz planner says with the displayed deltaV.

I could try to upgrade the rndvz planner to work with eccentric starting orbits but I don't have a formula for the resulting phase, nor is it trivial to find which direction to burn towards in the sim,

[CorvusCorax]

Updated mod to version 0.000011.

I fixed the RNDVZ planner. It now calculates transfers from eccentric orbits correctly. In fact so accurately that if you follow it exactly you run the risk of crashing into ISS roughly 45 minutes after a single transfer burn.

Shoutout to http://www.braeunig.us/space/orbmech.htm - that page had all the formulas I needed for the transfer computer implementation

[sevenperforce]

How hard would it be to add a variable that increments expended dV and notes how much you have remaining? You could then add an output at the end (post-successful docking) to grade the user on how much dV they expended in comparison to auto-docking.

[CorvusCorax]

How hard would it be to add a variable that increments expended dV and notes how much you have remaining? You could then add an output at the end (post-successful docking) to grade the user on how much dV they expended in comparison to auto-docking.

Pretty trivial to do.

Only issue is that the amount of deltaV you get per thruster pulse - because of the way the (presumed) SpaceX intern originally implemented it - is dependend on your system speed / framerate. The only place where they calculate anything with realtime is in the "approach rate" display (red number bottom right in HUD). I added proper velocity calculation to the orbital mechanics, but I so far didn't touch the propulsion code.  This puts people with fast systems at a disadvantage. A thruster pulse adds 0.5 meters per frame of velocity, but with more frames per second, they spend more meters per second on small, unavadable course corrections - up to the point where they might exceed the docking limits even at minimum speed (1 single thruster pulse)

I might have to change that too.

Edit: Apropos "remaining deltaV" -- for that I'd need to know Dragon2's deltaV budget to begin with. Whats a DeltaV of a fully laden Crew Dragon?

[CorvusCorax]

How hard would it be to add a variable that increments expended dV and notes how much you have remaining? You could then add an output at the end (post-successful docking) to grade the user on how much dV they expended in comparison to auto-docking.

Implemented. DeltaV budget is now monitored and reported during and after each flight in version v0.000013
In the settings you can chose wether the budget is soft or hard.

The budget is 25 m/s for docking operations and 175 m/s for the entire phasing, rendezvous + docking thing.

25 m/s for docking only is plenty if one isn't in a hurry, but could get some speed-runners into trouble if they want to dock to the harder to get to docking ports. 175 m/s for rendezvous is pretty tight. When I tried it, I had only 20m/s left - and that was with a single transfer - no intermediate orbit and no fly-around (Although you can "orbit" the ISS with a very tiny deltaV budget if done right)

Obviously the real Dragon would have propellant margins beyond the budget. But NASA would start complaining if you go into those How large that budget highly depends on the amount of payload carried by dragon. Little to no cargo payload would almost double Dragon's total budget. I did some quick calculations and got to a minimum of ~ 250m/s (full dragon) and a maximum of around 400 m/s. (empty dragon) - mileage of real vehicle might vary.

[CorvusCorax]

After playing around with this for a bit, I think we can put a lower bound on the DeltaV budget Crew Dragon must have for ISS operations.

To get from the deployment orbit to the ISS requires on the magnitude of 155 m/s deltaV - with a direct Hohmann transfer.
Adding a phasing orbit round 400 km adds around 5 m/s.

Proximity operations around ISS are surprisingly cheap. The hold points are all in front of the ISS on the exact same orbit, just phased, so they can be held with basically 0 propellant usage.
Adding a bit of eccentricity to that orbit without changing the period will get Dragon on a pseudo-orbit around the ISS. So the circle around the space station, or traversing from the rendezvous point below the ISS nadir to the hold point in front of the ISS only takes around 0.1-0.2 m/s.

Coming in to dock would be a bit more expensive just because of the tight position constraints. It's hard to tell how much propellant Dragon will burn but it should be less than 5 m/s for all ISS proximity operations combined.

Deorbiting - again with a circular phasing orbit below ISS - took me around 120 m/s.

All in all I get to 280 m/s minimum DeltaV to get to the ISS and back -- add some margin for failed ISS approaches and manual flight experiments, and we can conclude Dragon should have at least 300 m/s.

Is there any official number? (It's of course mission specific. More payload = less deltaV)

[Kaputnik]

Is it meaningful to compare our best docking times, or does it depend on your system clock speed?
(FWIW I can do it in about three and a half minutes...)

[Tommyboy]

Is it meaningful to compare our best docking times, or does it depend on your system clock speed?
(FWIW I can do it in about three and a half minutes...)

Amateur. Somebody did it in 16 seconds:

[Lars-J]

Is it meaningful to compare our best docking times, or does it depend on your system clock speed?
(FWIW I can do it in about three and a half minutes...)

Amateur. Somebody did it in 16 seconds:

Neat! But it could still be faster... note that the script does keep toggling reverse and forward thrust during the final approach.

[CorvusCorax]

Is it meaningful to compare our best docking times, or does it depend on your system clock speed?
(FWIW I can do it in about three and a half minutes...)

The way SpaceX implemented it, the simulator runs at whatever framerate the webbrowser (in GL) mode can support. This is the window redraw rate, often limited by the graphics driver (it won't trigger a redraw at more than your monitor fps) but it can be slower than that on a slow system if graphics can't keep up.

They also made it so that the velocity is internally measured in "meters per frame" - and each thruster pulse will add or substract a small value from that.

The same is true for rotations - even though it says "°/s" in the display - for most people rotations are a lot faster than that.

so when the sim displays 0.1 °/s rotation speed it actually means 0.005 ° per frame
This matches if, and only if your system runs graphics at exactly 20 frames per second - which is actually often not too far off, especially with a slow browser (javascript wise) such as Firefox

But with a fast Browser (Chrome) and GPU, some systems easily reach 60 fps, so they will rotate and translate 3 times as fast.

To make things worse, the actual framerate isn't constant. It varies considerably whether you have ISS in your view, earth, or only the stars.

What might make sense for a speedrun is a frame counter.

Or... maybe I should go to the trouble and actually fix the fps control of the simulator and enforce the sim to run at clock speed instead of animation speed.

Not completely trivial though. It gets to the point where I'd have more or less rewritten the entire game

[CorvusCorax]

Is it meaningful to compare our best docking times, or does it depend on your system clock speed?
(FWIW I can do it in about three and a half minutes...)

Amateur. Somebody did it in 16 seconds:

Well, with my twiddly fingers I never got beyond 25 m/s , but with the computer in charge, as in that video, it might be possible to go through all 200 m/s deltaV Dragon2 has left in the last 200 meters to the space station and run out of propellant

I'd love to see the same script run with my mod installed just to see how much juice that burnt through

[CorvusCorax]

Hey look, NASA put their own docking simulator on-line:


https://rocketsciencec2e.ksc.nasa.gov/

it's kinda "pre-school-style" compared with the SpaceX one though.

and even though they use Unity, their model of the ISS kinda sucks.

but you can "fly" "around" with both Dragon and CST-100.

(Edit: except you can't do exactly that. They don't let you fly "around" the ISS - it restarts if you leave the approach vector)

[CorvusCorax]

I added a frame - simtime and mission time counter to the Customize ISS-SIM Userscript. This should make comparison of speed runs easier. Rotation and translation speed is now independent of FPS.

This is the complete changelog:


    v 0.000001 2020-05-13 Initial Customize ISS-SIM Script
        Toggle permanent Tesla visibility
        Toggle 500m distance restriction
        Toggle HUD Online/Offline
        Toggle Docking constraints - original versus IDA specs
        Toggle precision rotation/translation per via keyboard
    v 0.000002 2020-05-14 Bugfix
        Bugfix to work with different browsers / extension loaders (Greasemonkey, Chrome native, Tampermonkey, Violent Monkey, ...)
    v 0.000003 2020-05-14 Docking Ports
        Support for all the ISS docking ports
        Improved greeter and intro
    v 0.000004 2020-05-16 Proper Orbital Mechanics
        Support for time warp
        Support for realistic orbital mechanics instead of simplified "gravity" - allows altering orbit around earth arbitrarily
    v 0.000005 2020-05-17 Bugfix
        Fixed bug in Tampermonkey/Chrome where some menu entries weren't functional
    v 0.000006 2020-05-18 Fix the Earth
        In Proper Orbital Mechanics, ISS is now in correct 51° inclined prograde Orbit, earth rotates correctly around itself
        Navigation ball displays orientation relative to earth.
    v 0.000007 2020-05-19 Navball Bugfix
        Corrected an error in the nav ball orientation
    v 0.000008 2020-05-19 Follow the sun
        In Proper Orbital Mechanics mode, the sun no longer orbits with the ISS but stays stationary relative to earth. ISS enters earth shadow
        ISS Solar panels track and follow the sun
        ISS radiators move out of the way, when the obstructed PMA-3 docking port is selected
    v 0.000009 2020-05-20 A New Challenge
        Orbital rendezvous calculator display added to Proper Orbital Mechanics mode
        Added new Objective/Spawn position to allow player to begin in deployment LEO and sync to the ISS themselves
        Bugfix of rotation-precision-mode bug in the original ISS-SIM
    v 0.000010 2020-05-21 DM-2 Dragon Deploy
        Dragon now deployed in eccentric 190km x 205km orbit - matching DM-2 deployment orbit
    v 0.000011 2020-05-23 Eccentric Rendezvous
        Updated rendezvous calculator to work and predict correctly when Dragon is initially in an arbitrary eccentric orbit (aka any orbit)
    v 0.000012 2020-05-23 Un-Phased
        Updated initial orbit of the rendezvous challenge to be phased 1/3 orbit behind ISS - as it would be on May 27 planned DM-2 launch
    v 0.000013 2020-05-24 Sparse resources
        Keep track and display used DeltaV and DeltaV budget
        Added limited propellant to the optional docking constraints. Exceeding the DeltaV budget for the mission phase means GAME OVER.
    v 0.000014 2020-05-25 It's Time
        Added mission- and game- elapsed time counter to allow comparison of speed-run challenges
        Added fps display
        Fixed velocity and rotational velocity calculation to be correct and independent of system fps

[CorvusCorax]

Check out the free drift orbital trajectory preview.

We saw SpaceX have that it in the DM-1 webcast for the 2d navigation side view, but I figured having a preview where you're capsule's going might be quite useful. Especialy if orbital mechanics come into play and the exact shape of the trajectory might become a bit non-intuitive



This is version 0.000015