Compared to vanilla KSP, this interface is excellent. Intuitive placement of translate Vs rotate. Heh. Far less change of RUD due to using the wrong one at the wrong time. And no clampotron bounce XD
I agree. It's so good to always have access to all controls at all times. KSP has a modal interface. Translation is only enabled while in docking mode and it randomly switches back to normal out of nowhere.
Lost count of how many maneuvers I screwed up due to mode errors. Not being in docking mode or being in the wrong docking mode. For some reason switching from the galaxy map back to the ship would turn off docking mode every time. I'd try to decelerate my ship only to end up rolling out of control and by the time I manage to stabilize it's too late. Best case scenario I'd simply overshoot my space station and have to waste propellant maneuvering back to it. Worst case scenario I smash right into it at ludicrous speeds.
I recommend never using docking mode. For rotation use the standard WASD with QE for roll, and for translation use the IJKL with HN for forwards/backwards. Additionally, use Caps Lock to set "precision controls" when needed.
This is all in standard mode (staging mode), not docking mode. I've never seen the point of docking mode mixing around my controls. I often don't want my main engines to shut off for docking, and I do want to have manual roll control to align the attitudes.
I really want to get into Elite Dangerous but that rabbit hole seems time consuming…. Is it possible to play and enjoy without dumping tons of hours in?
The typography is terrible - the numbers are too widely separated and taking too much space on the screen. You also need to know where to look and interpreting is not as easy as the SpaceX approach.
OTOH, a Soyuz does this with brains similar to an MSX computer while the SpaceX's screen overlay icons takes up more memory than all computers aboard a Soyuz put together.
Kurs interface is a list of values that you want all to move towards zero, it gives me an `int axes[] // x,y,z,Rx,Ry,Rz`. In SpaceX interface I'd have to `for axis in axes: axis_value = getObjectLocation(axis, screen).getValue()` and that's a ton of overhead.
In my opinion, if I was a Chrome engineer, I'd be pretty surprised that someone would decide to include Chromium in a spaceship. Disclaimer of warranty indeed.
Last time I saw this posted here, people implemented various auto-pilots for this [0].
Here is a short video of my attempt: https://youtu.be/jWQQH2_UGLw
Given that this simulator supposedly maps closely to the actual interface on the spacecraft, it's funny to imagine SpaceX hooking it up to the real thing and seeing how it fares. Succeed or fail, it would be a pretty wild ride.
This autopilot doesn't use the rotation and translation rates as input, just the momentary values. It also uses the same control function for all axes.
I saw at least two autopilots that used PID control in a couple of different ways. They all needed tuning though because any moderate control input would send them spiraling off into the void.
Musk needs the working class in space or else his utopia on Mars won't even begin. This is yet another push to bring a work force of non-astronauts to space, showing off that anyone from the internet is going to be able to control a SpaceX vehicle at one point with minimal training.
Do you believe that robots and autonomous systems, keeping in mind that they will develop by leaps and bounds between now and whenever regular Mars trips are in full swing (say 15 years from now), will somehow not take a lot of the load?
The real life docking is already autonomous. This game just simulates what would happen if the crew decided to turn the autonomous system off and dock it manually. No human intervention is needed on the Crew Dragon during normal operation.
...or that having a well-designed UI with intuitive controls is a hallmark of good design that has been proven time and time again to reduce errors, whether or not something is designed for the layman or a highly paid professional.
This is always such a weird take. Mars isn't going to be a 'utopia' in any of our lifetimes, Musk is also aware of that.
On the other hand, the point of modernizing the UX is indeed to make things more accessible, but that is absolutely necessary if we are going to expand beyond Earth.
Ignoring the idea of a Mars colonization effort, even just a roundtrip to Mars is a several years long mission. You're going to want to simplify the 'routine' parts to allow the astronauts to focus on training for the unknowns.
A lot of the various UI elements used at SpaceX are created by / under Shane Mielke (the pixel ranger, 2Advanced). Specifically he made this simulator.
I've got it down to 3mins if I rush orientation followed by position. I'm convinced this can be pushed further if you have the coordination to combine it.
[edit] 2:30 combined with some exciting drama at the end
[edit] 1:40 combining pitch & yaw & forward-thrust, followed by roll while accel/decel (because doesn't affect approach), finally eyeballing Y and Z and monitoring X reading for reverse thrust (because eyes suck at distance estimation)
[edit] 1:30 with a ~50% chance of becoming a space station projectile, am I hired?
[edit] 1:24 with a 90% chance of becoming tomato puree
[edit]
Found this 00:23 seconds, but they seem to be able to accelerate and decelerate much faster than I can, maybe I need to tweak key repeat and delay times to achieve this.
I thought the main advantage of re-usable rocket use on the ISS was the potential for providing an economical takeout service for astronauts... it needs to be hot on arrival, but not too hot.
The real fun would be to try do dock to a space station rotating along its intermediate axis (following the lost of orientation control caused by an impact with space debris) .
Can anyone comment on the fact that you seem to directly influence your speed, and not your acceleration? Is this also the case in reality?
Compared to my first flightsim experience this was much easier, the speed with which you can 'stop' any motion seems only limited by how fast you click. In flightsim I found myself easily overcompensating, if impatient or stressed even oscillating to increasingly bigger extremes.
This would work in real life, the only hitch is that you'd run out of fuel much quicker. There's no fuel constraints in the simulator so you can use the RCS thrusters to kill your acceleration as much as you want.
RCS thrusters often has fixed thrust and used in pulses, like a PDM or PWM analog output from a digital pin in a microcontroller. So it's normal to mash buttons or bump joysticks in space to achieve desired rates, rather than gradually adding and maintaining force on the joystick to keep attitudes as done in airplanes.
In real life, there is also 'coupling' between axes, e.g. trying to move towards top of your head might cause spacecraft to somehow point slightly sideways while at it. That used to be taken care of by pilot's skill in Apollo era and before, but today it should be mitigated by software.
This could be a really cool teaching platform if they would provide a more robust physics emulation (including the gyroscopic effects you mention) as well as direct interface to a simulated RCS control system with realistic operating inputs and constraints (eg you ask for a 120ms burn at 75% throttle and you get 125ms at 85%). Then gamify various operations like IIS docking, JWST repair mission, deorbiting X37 via momentum transfer.
If you're not going for a speedrun and just proceeding at a casual rate it works pretty well to start https://www.youtube.com/watch?v=m3zvVGJrTP8 in the background. Back when this came out I used to challenge my son to get it docked safely before the music stopped. He was almost 4 at the time so it was a pretty good challenge to finish it in under 4 minutes.
One of the weirdest aspects of Crew Dragon is the total lack of precision controls for manual docking. There's a reason that most aircraft, even the most computerized and automated ones like the F-35 and Airbus A350 still rely on a joystick for fine control. A touchscreen interface like this seems like a really clunky way to implement manual control, and offers less flexibility for alternate and abort flight modes where automated control may not be possible.
The Soyuz is fully automated from liftoff to touchdown and still has a cockpit with a plethora of manual controls and two joysticks for RCS control.
I guess the idea was to make it look all sleek and sci-fi on the interior... but at the expense of precision and versatility. It just seems to demonstrate a lack of consideration for tactility and the importance of it in a mission-critical environment like space.
It's definitely unusual but the idea was actually not to waste time building things that aren't needed. Dragon is fully automated, has fault-tolerance in pretty much every subsystem, and there's a stack of procedures five feet high that operators would try before telling the crew to go manual. (Well, not literally. All the procedures are electronic.) This "simulator" is a marketing gimmick and bears almost no resemblance to real-world docking ops.
That's fair, but traditionally the rule of thumb in aerospace and avionics is to compensate for every single possible edge case into consideration. (Obviously there are diminishing returns past a certain point, but assuming modified and emergent flight modes is important for a reason.) In an edge case where avionics failure is inevitable, fully automated aircraft with flight envelope protection like Airbus, Dassault, and Lockheed still retain "direct law" and "alternate law" modes that allow direct control of aircraft control surfaces. It just seems like an oversight.
In 99.99% of normal flight law situations there will be no issue with touch controls. That 00.01% however is even more important in space than it is in the air, which is why Crew Dragon's avionics design philosophy strikes me as particularly odd. If there was ever an Apollo 13 style disaster on board, it would be an uphill battle to retain control compared to a traditional spacecraft like Orion or Soyuz.
In space mass and volume are at a premium. The Dragon approach produces a spacecraft that isn't stuffed with instrumentation like Soyuz. The extra capacity is available for more productive use.
You seem to be confusing a stick with mechanical linkage. Airbus aircraft don't have mechanical linkage; there is no "direct control of aircraft control surfaces." Even in the degraded modes, you're still going through the computers. Apollo and Shuttle didn't have mechanical linkage either. So the "direct control" you're describing isn't actually direct; it's mediated by the avionics, just like Dragon.
Even without mechanical linkage, a stick makes sense in an aircraft because its surfaces and powerplants have continuous ranges. But Dragon's propulsion doesn't--it makes discrete pulses. A continuous control in Dragon wouldn't actually be able to provide output over a continuous range.
The pace of operations in space is also much, much slower than it is in the air. These aren't ace top guns doing split-second maneuvers with lightning reflexes. They aren't even airline pilots switching off the autopilot at 100' AGL. Docking is slow. Don't let the orbital velocities or the excitement of launch and reentry fool you--spaceflight is much more like sailing than it is like aviation.
In any case, the proof is in the pudding: Dragon crews train for manual docking on the (real) simulator, and it works.
> So the "direct control" you're describing isn't actually direct; it's mediated by the avionics, just like Dragon.
Very true, but I'm more describing the difference in the UX of how pilots access the avionics rather than arguing for fully manual control. Most pilots raised on FBW would find fully manual flight rather tricky (think an F-16 pilot stepping into a P-51), so I'm not suggesting we do that. It's just that Dragon's design philosophy seems like kind of an interesting departure from conventional wisdom.
> The pace of operations in space is also much, much slower than it is in the air. These aren't ace top guns doing split-second maneuvers with lightning reflexes. They aren't even airline pilots switching off the autopilot at 100' AGL. Docking is slow. Don't let the orbital velocities or the excitement of launch and reentry fool you--spaceflight is much more like sailing than it is like aviation.
This is a pretty solid point, and one I hadn't really considered. Leave that up to Hollywood and Kerbal Space Program for misleading everyone on how fast-paced spaceflight really is, heh!
Unfortunately the model is really simplified and it makes the whole thing infinitely easier than in reality.
You can clearly see the weirdness if you start pitching up, say at -0.3 °/s and then add a lot of roll to either side (-2.0 °/s). The roll should not affect the pitch in any way (the reticle should continue to move along a straight line on the screen), but in this simulator the reticle actually starts drawing a circle, as if a yaw thruster was firing continuously.
I wrote my post too fast, the reticle shouldn't move along a straight line after pitch + roll are applied, but along a different curve. I really need to read up on the physics behind it, but it feels too easy to cancel all the rotations along different axes, even when badly upset, compared to other sims (Orbiter, KSP, Simple Rockets)
Thanks for sharing. Took me around 4 minutes and docked successfully on my first try. What a great interface too. Without training and without even looking at the instructions, I managed to dock it.
This may be a dumb question but I noticed something a bit odd. I had no trouble getting the orientation right and stabilizing those numbers. They didn't drift after getting to zero. But there was always a little drift on Y and a bit more on Z. A very small drift, but I was thinking I should have been able to completely stabilize it. That a single click right thrust would cancel out the previous single click of the left thrust.
But that wasn't the case. Is that a fault of the simulator? Or how a spaceship would handle in reality? That the translation movements can never be completely canceled out and have to be monitored?
I believe it might be because of the orbit isn’t perfectly circular and and same inclination as the station. Check some docking videos where they show relative trajectories between docking ships and station and you notice that it forms “loops” if no thrust is applied. Orbital mechanics can be unintuitive, if you apply thrust towards your orbital motion you raise your orbit on the opposite side of the earth and so on.
If you're accelerating towards an orbital object you are by definition not in the same orbit as the target object. If you were you would be moving at the exact same speed. This effect makes getting yourself close enough for docking all sorts of tricky if you don't know what you're doing. Once you get close enough (like in the linked simulator) you can mostly ignore the problem since the effects are small given the relative speeds involved.
I can heartily recommend messing around with orbital maneuvers in KSP to get a feel for the problem. It's not exactly intuitive.
92 comments
[ 3.6 ms ] story [ 169 ms ] threadBut Kudos, maybe it's my KSP experience, but that interface is really great and understandable.
Lost count of how many maneuvers I screwed up due to mode errors. Not being in docking mode or being in the wrong docking mode. For some reason switching from the galaxy map back to the ship would turn off docking mode every time. I'd try to decelerate my ship only to end up rolling out of control and by the time I manage to stabilize it's too late. Best case scenario I'd simply overshoot my space station and have to waste propellant maneuvering back to it. Worst case scenario I smash right into it at ludicrous speeds.
This is all in standard mode (staging mode), not docking mode. I've never seen the point of docking mode mixing around my controls. I often don't want my main engines to shut off for docking, and I do want to have manual roll control to align the attitudes.
1: https://youtu.be/LL_usHvz3G0?t=135
OTOH, a Soyuz does this with brains similar to an MSX computer while the SpaceX's screen overlay icons takes up more memory than all computers aboard a Soyuz put together.
Still, it is super cool
[1] https://news.ycombinator.com/item?id=23162820
[0] https://news.ycombinator.com/item?id=27252639
Given that this simulator supposedly maps closely to the actual interface on the spacecraft, it's funny to imagine SpaceX hooking it up to the real thing and seeing how it fares. Succeed or fail, it would be a pretty wild ride.
This autopilot doesn't use the rotation and translation rates as input, just the momentary values. It also uses the same control function for all axes.
Video: https://youtu.be/jLTr6UwuSd4
definitely not PID control
[1] https://gist.github.com/ggerganov/092b86a59fa34926998953701a...
I saw at least two autopilots that used PID control in a couple of different ways. They all needed tuning though because any moderate control input would send them spiraling off into the void.
Do you believe that robots and autonomous systems, keeping in mind that they will develop by leaps and bounds between now and whenever regular Mars trips are in full swing (say 15 years from now), will somehow not take a lot of the load?
On the other hand, the point of modernizing the UX is indeed to make things more accessible, but that is absolutely necessary if we are going to expand beyond Earth.
Ignoring the idea of a Mars colonization effort, even just a roundtrip to Mars is a several years long mission. You're going to want to simplify the 'routine' parts to allow the astronauts to focus on training for the unknowns.
https://www.shanemielke.com/work/spacex/iss-docking-simulato...
I've got it down to 3mins if I rush orientation followed by position. I'm convinced this can be pushed further if you have the coordination to combine it.
[edit] 2:30 combined with some exciting drama at the end
[edit] 1:40 combining pitch & yaw & forward-thrust, followed by roll while accel/decel (because doesn't affect approach), finally eyeballing Y and Z and monitoring X reading for reverse thrust (because eyes suck at distance estimation)
[edit] 1:30 with a ~50% chance of becoming a space station projectile, am I hired?
[edit] 1:24 with a 90% chance of becoming tomato puree
[edit]
Found this 00:23 seconds, but they seem to be able to accelerate and decelerate much faster than I can, maybe I need to tweak key repeat and delay times to achieve this.
https://www.youtube.com/watch?v=tQ0J784PO6I
https://www.chicagotribune.com/news/ct-xpm-1988-06-23-880109...
[1] https://www.speedrun.com/spacex_iss_docking_simulator_
https://www.youtube.com/watch?v=WwWccjAD2i8
Get ready for a career upgrade...
edit: when its 3m away, its still going 4 metres per second (but braking rapidly)
No idea how to get around the double tap -> zoom issue which makes this pretty hard.
Compared to my first flightsim experience this was much easier, the speed with which you can 'stop' any motion seems only limited by how fast you click. In flightsim I found myself easily overcompensating, if impatient or stressed even oscillating to increasingly bigger extremes.
In real life, there is also 'coupling' between axes, e.g. trying to move towards top of your head might cause spacecraft to somehow point slightly sideways while at it. That used to be taken care of by pilot's skill in Apollo era and before, but today it should be mitigated by software.
Ref: https://www.youtube.com/watch?v=bLeLSo0lK8w
The Soyuz is fully automated from liftoff to touchdown and still has a cockpit with a plethora of manual controls and two joysticks for RCS control.
I guess the idea was to make it look all sleek and sci-fi on the interior... but at the expense of precision and versatility. It just seems to demonstrate a lack of consideration for tactility and the importance of it in a mission-critical environment like space.
In 99.99% of normal flight law situations there will be no issue with touch controls. That 00.01% however is even more important in space than it is in the air, which is why Crew Dragon's avionics design philosophy strikes me as particularly odd. If there was ever an Apollo 13 style disaster on board, it would be an uphill battle to retain control compared to a traditional spacecraft like Orion or Soyuz.
Even without mechanical linkage, a stick makes sense in an aircraft because its surfaces and powerplants have continuous ranges. But Dragon's propulsion doesn't--it makes discrete pulses. A continuous control in Dragon wouldn't actually be able to provide output over a continuous range.
The pace of operations in space is also much, much slower than it is in the air. These aren't ace top guns doing split-second maneuvers with lightning reflexes. They aren't even airline pilots switching off the autopilot at 100' AGL. Docking is slow. Don't let the orbital velocities or the excitement of launch and reentry fool you--spaceflight is much more like sailing than it is like aviation.
In any case, the proof is in the pudding: Dragon crews train for manual docking on the (real) simulator, and it works.
Very true, but I'm more describing the difference in the UX of how pilots access the avionics rather than arguing for fully manual control. Most pilots raised on FBW would find fully manual flight rather tricky (think an F-16 pilot stepping into a P-51), so I'm not suggesting we do that. It's just that Dragon's design philosophy seems like kind of an interesting departure from conventional wisdom.
> The pace of operations in space is also much, much slower than it is in the air. These aren't ace top guns doing split-second maneuvers with lightning reflexes. They aren't even airline pilots switching off the autopilot at 100' AGL. Docking is slow. Don't let the orbital velocities or the excitement of launch and reentry fool you--spaceflight is much more like sailing than it is like aviation.
This is a pretty solid point, and one I hadn't really considered. Leave that up to Hollywood and Kerbal Space Program for misleading everyone on how fast-paced spaceflight really is, heh!
You can clearly see the weirdness if you start pitching up, say at -0.3 °/s and then add a lot of roll to either side (-2.0 °/s). The roll should not affect the pitch in any way (the reticle should continue to move along a straight line on the screen), but in this simulator the reticle actually starts drawing a circle, as if a yaw thruster was firing continuously.
https://www.reddit.com/r/interstellar/comments/gmiwgh/no_tim...
Andrew Ng was proud of training a system to fly a helicopter upside down, just curious.
This may be a dumb question but I noticed something a bit odd. I had no trouble getting the orientation right and stabilizing those numbers. They didn't drift after getting to zero. But there was always a little drift on Y and a bit more on Z. A very small drift, but I was thinking I should have been able to completely stabilize it. That a single click right thrust would cancel out the previous single click of the left thrust.
But that wasn't the case. Is that a fault of the simulator? Or how a spaceship would handle in reality? That the translation movements can never be completely canceled out and have to be monitored?
I can heartily recommend messing around with orbital maneuvers in KSP to get a feel for the problem. It's not exactly intuitive.