For use in landing (#34), we'll need to refine the graphics (#6) and make sure that when the underlying physics entities are touching, the graphics show no gap between two spheres.

If man-made objects collide too fast, what happens?

• there should be some visual feedback that you've crashed
• sound? optional
• the compatibility layer would tell engineering that we've crashed
• stop the simulation (and maybe re-centre on the crashed object)

Related to #37

fill in body later sorry

When testing landing, I noticed it's particularly hard to do so since I can't have an accurate estimate of my position relative to Earth, having altitude and speed at which I'm heading towards Earth would be greatly helpful when performing landing

Commit a067f2 adds Ye Qin's standalone physics engine prototype. I'll try to get it integrated.

Using orbitx shouldn't be molasses-like.

Our GUI (vpython) should stay at about 20 or 30 fps consistently, even after long runtimes on spacesim's setup.

As well, we should be able to do max time acceleration and push updates several times a second.

Collision detection probably doesn't work when there are multiple objects. Guess I'll have to fix that.

It seems spacesim members just want a list of features. This makes sense because there are lots of features in legacy orbit that are undocumented. For example, even when I was demoing the legacy flight software to CS493 team members, I accidentally pressed a button and like five more lines of text were displayed.

Hopefully the issues list on this repo will help make this feature list.

The periapsis, apoapsis, horizontal speed, and vertical speeds in the GUI are just placeholder "100" values right now. Someone who knows physics n stuff should change the relevant functions in flight_gui.py (like _periapsis, _h_speed) so that they give correct information.

assert False in physics is getting triggered

Solution might be to astype to float64 or object dtype.

Throttle can go beyond 100%

For now, just a simple circle to represent a planet is good enough for the prototype.

• circle representation of planets, when zoomed very in and very out
• basic GUI (information like engine thrust)

These can be split into their own issues

Given .json files, we should be able to load these files and deterministically get the same physical state. Likewise, we should be able to save and create these files.

There are colour blind spacesimmers, which doesn't work well with legacy orbit when the only way of differentiating different planets is the colour of them.

When developing our GUI, we should read up on some colour-blindness accessibility guides. In January, there's a talk at StarCon there's a talk about just this topic! I'll be there and see what we can learn.

First off, the help text was well-appreciated (although the html table of the digits needs to be fixed, otherwise the table 'wobbles' when numbers change a lot)

• spacesim members noted that the numbers in the text display have too many significant digits, although they also noted that they would sometimes need a bit more accuracy. But most of the time, lots of wildly-changing numbers is a readability issue. Maybe bigger numbers? We'll have to investigate what legacy orbit/KSP do.
• spacesim members noted that there was a lot of whitespace. Once we fill in more text fields, we should check the general clutter and figure out how to sectionize the GUI text fields.
• Spacesim members were confused that headings are taken relative to Solar west, instead of e.g. pitch above the reference object.
• Heading can't get higher than 360 (well only for a frame or two) but it might be able to get very negative
• Spacesim members at this specific demo expressed that they found legacy orbit's text readouts are familiar and should be preferred when designing the new GUI (although for example, the vectors display in legacy orbit's sidebar aren't used, instead people just zoom in to see where the habitat is pointing. So not all text fields are mandatory)
• A possible solution to an confusingly-rotated viewpoint could be a "revert to default top-down view"
• Spacesim members (and also honestly sometimes us) were confused that player input sets the warp to 1x. We should either make it obvious that it does this, or remove this behaviour. I think a feature toggle is too much, we should have it or we should not have it.
• The test pilot kept on changing time warp, and requested a keyboard shortcut to change timewarp
• specific text fields that were requested were Vcen, Vtan, Apoapsis, and Periapsis
• it was noted that the current landing graphic does not make it obvious that you're moving tangentially to the surface of the earth
• also it's confusing that a landing graphic has the same texture as the planet
• orbit projects were requested, but we know this is something we need to do
• It was requested that engines be in the range of [-100%, 100%]
• it was pointed out that trails are not important
• we should check that ref Vo changes with altitude
• for AYSE, try to represent the painting in MC, although we should also make it obvious from the top-down view where you can dock with AYSE
• the test pilot pointed out that labels are covered up by planets. We shouldn't put essential information in these labels

See OCESS.json

All planets in the solar system should be able to be loaded at once. For feature parity with legacy orbit, we should be able to simulate at 60x time acceleration for at least one orbit of Mercury and all subsystems of the solar system should be stable (especially Mars-Phobos, Mars-Deimos, Jovian moons, and habitat-Earth if we implement that).

Also, everything should orbit in the same way the solar system orbits.

We should be able to test our code easily and with one command. Our test code doesn't need to test the GUI, but it should test the most important testable for the prototype demo: the physics engine.

For each important aspect of the physics engine, there should be a corresponding test case.

Legacy orbit is notoriously hard to learn. Perhaps a bit more intuitiveness in the new UI will go a long way. Something to keep in mind when developing the GUI. See #6 for any other GUI things.

Tracking issue for any work done just for improving the demo.

The demo should:

• recover from recoverable errors
• noisily fail from unrecoverable errors
• show off all features
• be easy to run

This is an ongoing issue, related to #8 for the stability of the solar system, and keeping the goals of #4 and #16 in mind.

I'm not sure how stable legacy orbit is, although I'm pretty sure that the orbit of at least the ISS and maybe Phobos needs to be corrected after large timewarps.

However, for every physics feature we add, we have to make sure that it does not impact:

• being able to simulate at 100,000x time acceleration
• being able to gravitate
• being able to detect collisions properly (i.e. moons in a stable orbit should not collide)

This is maybe not a serious request, but technically it's part of the legacy orbit.

Optional.

We should have a high-level idea of how to architect this project, and make sure all three of us have this plan in our heads.

Currently we can only change throttle by 1 or -1, make it possible to change by number between -1 and 1

lol we already got this. Way to go Sean.

With time acceleration 20000 orbits seem jagged

These can also be thought of autopilot modes. Examples are

• prograde in orbit
• retrograde in orbit
• away from target
• towards target

etc

An ongoing issue. When developing, we should make sure our code adheres to PEP8 style guide, Has public APIs and any important internal helpers well-documented, and our code is generally readable.

If we ever do rough terrain on planets, this might be relevant.
In legacy orbit, there is a rectangular-ish launch tower. It's definitely optional to implement that in our new physics engine, but technically that's part of feature parity.

Oops we broke trails. Trails are now drawn relative to the camera centre instead of the reference, which is bad because we are usually controlling the habitat while it's the camera centre, and we want to see how its moved.

Trails should:

show how the habitat moves relative to the reference object (usually Earth) even when the habitat is the centre.

Related to #34

• bouncy collisions: when natural objects go too fast, they bounce
• not-bouncy collisions: when two objects go slowly, they stick to each other
• destructive collisions: when man-made objects go too fast, they explode (consider: if the habitat is going too fast, display a warning? TODO in the future)

Gravity isn't working, see the test_gravitation test case.

The habitat is a special entity. Will need some special extra fields, like engine thrust and remaining fuel. These could be added to the proto definition as optional fields, and whatever internal representation is most convenient is also good.

• technical ideas (physics not on main thread, 'framerate' is what will get an impressive demo)
• they're going to be doing a code review, so make sure code is readable!! Thanks Sean for adding docstrings to functions
• we should be able to show our process (feature ideation -> actual code)
• the three Ps: Product, Process, Presentation
• start associating commits with issues, making sure that our meeting notes reference features
• for the presentation: we should convince viewers that our project was a good project (show features, don't tell), make sure that our demo is stable

To complete #6, we need a sidebar that has information on the habitat (e.g. the centripetal velocity and tangential velocity of the habitat). Hopefully most of the same info as legacy orbit, but we'll do the simpler ones for the demo.

AttributeError Traceback (most recent call last)
~/projects/orbitx/flight.py in
250 warnings.filterwarnings('once', category=DeprecationWarning)
251 warnings.filterwarnings('once', category=ResourceWarning)
--> 252 main()

~/projects/orbitx/flight.py in main()
231 try:
232 if args.data_location.scheme == 'file':
--> 233 lead_server_loop(args)
234 else:
235 assert args.data_location.scheme == 'mirror'

~/projects/orbitx/flight.py in lead_server_loop(args)
184 if not args.no_gui:
185 gui.draw(state)
--> 186 gui.rate(common.FRAMERATE)
187 else:
188 time.sleep(common.TICK_TIME)

~/projects/orbitx/orbitx/flight_gui.py in rate(self, framerate)
265
266 def rate(self, framerate):
--> 267 self._vpython.rate(framerate)

~/projects/orbitx/venv/lib/python3.6/site-packages/vpython/vpython.py in call(self, N)
214 self.rval = N
215 if self.rval < 1: raise ValueError("rate value must be greater than or equal to 1")
--> 216 super(_RateKeeper2, self).call(self.rval) ## calls call in rate_control.py
217
218 if sys.version > '3':

~/projects/orbitx/venv/lib/python3.6/site-packages/vpython/rate_control.py in call(self, maxRate)
171 return
172
--> 173 dt = calledTime - self.lastEndRate # time spent in user code
174 nr = self.whenToRender[self.renderIndex]
175 if self.count == 2 or (self.count == self.lastCount + self.rateCalls):

AttributeError: '_RateKeeper2' object has no attribute 'lastEndRate'

As in title, this is not a good UX. Switching to a lower warp value does not fix the problem.

We should either stop high warp values from freezing (optimizing at high warp values) or allow users to recover, ideally both.

Before we implement engineering and eecom etc., we should have OrbitX be able to communicate to legacy programs, so that we can act as a drop-in replacement.

for #6.

Currently, trails are long, left by not just planets but also moons (which is a confusing sinusoidal wave), and have no way to disappear or be cleared.

either have a max length for trails, or clear them completely

Legacy orbit simulates atmospheric drag around certain planets (Earth, Sun, gas giants, etc). We should simulate this somehow.

For AYSE to be implemented, we'll need:

• it needs to be dockable (mechanism for gluing habitat and AYSE together?)
• it should be able to communicate to legacy ENGINEERING when AYSE is docked and whatever
• legacy ENGINEERING will tell us when the docking arm is engaged
• if AYSE crashes, it might explode or something (see issue #40)
• when the habitat and AYSE are docked, they should be merged (which means this is blocked on #34)
• sound effects? wow, optional for sure. We'll do that in April if at all. We might not do that.
• AYSE should be able to provide thrust and use fuel. This happens when we are docked with AYSE, and we start to control AYSE. That is its whole own can of worms. AYSE and the habitat should move together when this happens.

Features needed in the GUI:

• model for AYSE (simpler is better, maybe a custom texture? physics-wise we'll not be able to model the habitat entering AYSE, and something as simple as a cone is fine)
• once AYSE docking is implemented, some mechanism for docking/undocking (a GUI button? keyboard shortcut?)

• engines provide thrust
• different graphics for spacecraft?
• user able to rotate spacecraft
• user able to adjust engine thrust
• able to change time acceleration during runtime
• able to change center, target, ref, NAVmode (and have an effect in the physics engine)

See title. This is probably because of how the events functions are implemented.

Keys like 'l' for label, and 'p' for pause will stop working. Not sure how to reproduce this. Will try to get a repro.

Legacy orbit allows you to land on a planet, and stick there. We should implement something like this, specifically:

• In the GUI, it should look like you're on the surface of a planet when you're landed on it
• When you're landed, you shouldn't bounce or jitter

We got the following error when making a list of triangles, then making a compound object of them:

Exception ignored in: <function standardAttributes.__del__ at 0x00000279BFAD1730>
Traceback (most recent call last):
  File "C:\Users\Patrick\orbit\orbitx\venv\lib\site-packages\vpython\vpython.py", line 1135, in __del__
    super(standardAttributes, self).__del__()
  File "C:\Users\Patrick\orbit\orbitx\venv\lib\site-packages\vpython\vpython.py", line 354, in __del__
    cmd = {"cmd": "delete", "idx": self.idx}
AttributeError: 'compound' object has no attribute 'idx'