ocess / orbitx Goto Github PK
View Code? Open in Web Editor NEWRewrite of OrbitV, maintained by Patrick, Gavin, and contributors
License: MIT License
Rewrite of OrbitV, maintained by Patrick, Gavin, and contributors
License: MIT License
lol we already got this. Way to go Sean.
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.
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)
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.
Keys like 'l' for label, and 'p' for pause will stop working. Not sure how to reproduce this. Will try to get a repro.
With time acceleration 20000 orbits seem jagged
This is maybe not a serious request, but technically it's part of the legacy orbit.
Optional.
Collision detection probably doesn't work when there are multiple objects. Guess I'll have to fix that.
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.
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.
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.
Gravity isn't working, see the test_gravitation test case.
Tracking issue for any work done just for improving the demo.
The demo should:
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.
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'
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'
For AYSE to be implemented, we'll need:
Features needed in the GUI:
If man-made objects collide too fast, what happens?
Related to #37
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.
fill in body later sorry
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.
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
Currently we can only change throttle by 1 or -1, make it possible to change by number between -1 and 1
Commit a067f2 adds Ye Qin's standalone physics engine prototype. I'll try to get it integrated.
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.
Related to #34
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.
assert False
in physics is getting triggered
Legacy orbit allows you to land on a planet, and stick there. We should implement something like this, specifically:
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
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.
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.
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:
See title. This is probably because of how the events functions are implemented.
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.
These can also be thought of autopilot modes. Examples are
etc
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.
For now, just a simple circle to represent a planet is good enough for the prototype.
These can be split into their own issues
Solution might be to astype to float64 or object dtype.
Legacy orbit simulates atmospheric drag around certain planets (Earth, Sun, gas giants, etc). We should simulate this somehow.
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.
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.
Throttle can go beyond 100%
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.