So, if you've ever seen anything that looks like this, but is also slowly spinning, the spinning isn't just to look cool. The spinning, even very slow and gentle, can help give a sense of the 3D depth of the space. Even just fractions of a degree/sec can be very helpful. I recommend trying to toss in some slow constant rotational motion and see if it helps get a sense of the space. At least based on my browser, you've got the performance for it to look pretty decent.
Edit: Klunky hack you can pop in the URL bar to make it go zoom:
Once you run that, screw with camYawIncr directly, rather than re-running that. Clicking a particular element causes jiggling as the klunky hack fights with the code tracking the element.
You may need something other than .001, depending on what frame rate you're getting.
(Edit edit: There's something to be said for this whole "web" thing sometimes. It's neat that we can hack on code like this....)
Oddly, I built something very similar a while ago. I haven't pushed an updated version anytime recently, so there isn't any UI, but here is an example of it:
Now I finally understand why, in Star Trek TOS, they only visited planets with "lifeforms less advanced than humans" (or with no human-like lifeforms). Bugger the Prime Directive, and the mission to "explore strange new worlds". Doing otherwise was just too dangerous!
Can you imagine the perils of trying to keep a 300m-long starship in orbit, without hitting all the bits of rubbish? Sulu would have been doing slaloms for half of every episode. (Although they could probably spring-clean a planet of orbital debris within a few hours, too, just vacuum it all up with a tractor beam).
As Spock so eloquently put it in ST4: "Judging by the pollution content of the atmosphere, I believe we have arrived at the latter half of the 20th Century."
On the other hand, in order to maintain the orbit, that space junk is going to be traveling at close to the same speed, if it's at the right altitude to hit you.
That's a good point. I was thinking about it from the perspective of Earth-launched debris, which would usually be traveling somewhat the same direction, as it's the cheapest orbit in terms of energy expenditure.
Not really, since lots of satellites have technical requirements for polar orbits or are otherwise not following the least-energy, eastward orbits. Even if two satellites are traveling within 5 degrees of the same direction, their relative speed is still over 1,000 mph. (LEO speeds are over 15,000 mph.)
I believe that was addressed in canon, the Vulcan scene in ST2009 notwithstanding. However, in Into Darkness, I recall an aside that the Enterprise would incinerate on reentry unless shields were restored, indicating utility beyond weaponry (that they did not, even though the pivotal moment was long after they were in blue sky, was a bit confusing).
This is so awesome, and render beautifully in Firefox, but I can't seem to get the "orbs" (the actual objects) to render themselves in Chrome. Is anyone else having this difficulty? Disabled all blockers and everything.
I see tiny little pulsating pixels in Chrome, which briefly show an orbit if you manage to mouse over their exact pixel. I was going to comment on the usability problem.
This reminds me that not only do you need to develop for different browsers, you also need to test the same browser on different operating systems. I can't count the amount of times Chrome has rendered stuff differently on PC and Mac (pure CSS things, don't even want to think about the differences in JS/WebGL).
Regardless of where the defect originates, if you want people to be able to use your product in different environments, you gotta test in different environments. The user won't care whether your product looks like crap because of a browser defect or because of a product defect; all they know is that it looks like crap. Of course, strike a balance; don't bother developing for IE6 on WinXP anymore.
We did something similar at the Space Apps NYC hackathon this April where we tried to simulate the effects of cascading space debris collisions known as the "Kessler syndrome".
We ran out of time so it doesn't actually cascade but it shows the rather high likelihood of collisions if you fast-forward with the slider on the bottom left of the screen. Pull requests would be very welcome, the data from space-track.org generally is great fun to play around with (as is three.js and satellite.js).
Wow, your project and this hackathon looks super cool, wish I had known about it earlier to attend. Will definitely follow the Meetup for future events, thanks for sharing!
It was the most fun I've had in a long time, I would definitely encourage you to participate as it is a global hackathon [1] and anyone can join from anywhere actually :)
That said I'd still prefer to be on-location as there was such a wide range of people with different backgrounds who were all super inspiring and a joy to work with! There actually weren't enough programmers so I got to hook up a lidar to an Intel Edison for another team which ended up winning the Intel price - the team leader even gave me one of those Edisons and invited me to visit Google NYC.
Yupp, I'm a lucky bastard :) and I didn't even mention that Lord British gave a talk too [2] (he bowed when I thanked his honour for being an inspiration since my childhood).
If you are only slightly interested do participate in the next Space Apps Challenge!
That's really neat! Is the code available anywhere? Are you propagating the TLEs with the SGP4/SDP4 propagator? Gonna tweet this now to share within the EU project I'm in, focussed on asteroids and space debris, so there could definitely be some pull requests around the corner!
Awesome :) I've added the github repo to my comment!
And yes, we were using satellite.js [1] which provided us with the propagation functionality together with a static set of TLEs from space-track [2] - I'll add an github issue for adding support for dynamic aggregation of that data right away actually :)
literally came here to say the same thing, it is all about Kessler Syndrome (though I dont remember if they called it that in the book). Fascinating site and good work!
o/
Nikola here.
If anyone is interested in the engineering of the space junk removal device, you can contact me at vianikola@yahoo.com , or on Twitter (which I haven't checked in a long time >.<") @Manakias2
This is awesome, thanks for the github link! I wonder what service is providing the data -- the lack of back-end in the repo and need for Web Workers makes me think it's something external. A brief tour of the source makes me think that the clue would be somewhere in satellites.js, but that is a doozy of a file.
It took me a little bit of staring to realize all the dots are animated, and actually orbiting. That's rad. It would be neat if clicking on a satellite pulled up its picture from wikipedia and linked to the wiki page.
So, question on the geostationary satellites. A lot of them have relatively high inclinations, like ~14 degrees. At first I thought this was because the countries that use them are at corresponding latitudes, but then I realized they'd be opposite the equator half the time.
Are these orbits to optimize directness during the day, at the expense of the night? If so I guess that would explain why they tend to favor the southern hemisphere over the dark side of the Earth and the northern hemisphere over the light side (because that's where population is concentrated).
There are a couple of ways to do "geosynchronous".
The most obvious way is an circular equatorial orbit at 35,786km. As I'm sure you know, but others may not, the orbital period at that distance means that the satellite completes one full orbit in 24 hours, thus it completes a circle in the same time that the earth does, so it's always over the same spot.
There is also the concept of a Molniya orbit (https://en.wikipedia.org/wiki/Molniya_orbit), where you have a small cloud of satellites (at least 3) with extremely elliptical orbits that together can provide coverage for non-equatorial areas.
If you come up with the satellite's name or designation you found, it's probably relatively easy to determine why it is at the inclination it has. Do you remember what it was you found?
I wasn't concentrating on any specific satellite, just noticing a very noticeable trend of 24 h period orbits with inclinations between 0 and 15 degrees. They are not eccentric, so I think it rules out Molniya orbits. The trend is readily apparent if you zoom out and view the Earth in profile (see http://imgur.com/FQpTkLR). There is the obvious trend at 0 degrees and then a noticeable high density from 0-15 degrees before then trailing off.
For arbitrary examples, see Palapa 1, Insat 1A, Raduga 6.
The 0 inclination orbit must be the most sought one, hence the highest density there. Then in cases where a small compromise from 0-inclination orbit was tolerable, and considering that the second most important thing is fuel consumption, I presume that the rest of orbits may have something to do with the launching point (a lot of satellites were launched from Baikonur Cosmodrome).
The preferred geosynch orbit has an inclination of 0deg, as that minimizes it's apparent motion in the sky. But this requires a lot of fuel for N/S stationkeeping.
The reason the orbits get inclined is because they're being pulled from the side by the sun and moon, and just like any other rotating object pulled by a lateral force, their axis precesses (just like a top). Left to itself, the orbit cycles between 0 and 14 deg inclination.
Interesting. Wouldn't the effects tend to cancel each other out because the inclination of the Earth spends half the year with the poles facing each to and from the Sun? Also since the Earth's inclination is 7 degrees, why do the satellites get to 14 degrees inclination?
Edit: And furthermore, wouldn't the spread be somewhat random with respect to the longitude of the ascending nodes? This seems to be anything but random: http://imgur.com/FQpTkLR
Some do cancel out. The inclination effect isn't driven by the sun's being above or below the equator - it's basic rotational mechanics. The net effect of the moon and sun's gravity pulling on the satellite causes the rotational axis to precess. The precession shows up in the orbit as the change in inclination (and ascending node).
Regarding the non-random spread.... all the orbits start at the same place (0 deg inclination - because that's where people want them). And it's the same sun and moon affecting all of them them in the same way, so you wouldn't expect it to be random. It is interesting that they all appear in that band, I don't have a good explanation for that : )
Something I've always wondered about: how do space agencies (NASA, SpaceX, etc) coordinate launches so that they don't hit this stuff? Are the coordinates aligned with launch pads blocked?
They map objects larger than about 10 cm (so, like, a softball?) and take manouvers if there's a debris cloud. Most stuff is shielded, some has more shielding.
As far as I know they really don't worry about it- there's a lot of space up there and considering how small satellites are the chance of hitting anything is astronomical.
What is the benefit of having time period larger than geosynchronous satellite? I see quite some satellite like that, e.g. OPS 6638 which has a time period of 6,701.8 minutes. I can think of no benefit of it, and on the downside it will require stronger rocket and provide low visibility.
There are some reasons for science spacecraft to be in high orbits but most of what you see is decommissioned comsats in graveyard orbits, which are supersynchronous. This is because such orbits have the least chance of decaying or of colliding with other satellites and creating a debris problem.
Great to see this. One of the very first examples of client-site Java put up years ago by JPL (or NASA?) was essentially this, but it went down a few years ago.
So simple, yet very powerful tool to grok intuitively quite a few things: geostationary orbits - and to see at a glance why latency is going to be a problem; the issue of coverage for satellite phones etc.
Edit: Looks like the NASA one still exists (http://science.nasa.gov/realtime/jtrack/3d/JTrack3D.html/) but it's a pain to get it to run because of Java security, and seems to be broken. Won't run in Chrome, broken display in IE and Firefox.
Yes! I always had this open on my Dad's computer quite some time ago. I always wanted to catch a glimpse of a satellite, or especially the ISS, as it traveled over-head.
It's called a Molnya orbit. The Soviets started using it because it would provide good coverage of their very nordic territory, something geostationary sats would not do. Of course, the sats are not stationary (from the point of view of earth, so that excludes stationary parabolic antennas, as are very common with GEO sats) and you do need at least three for continuous coverage in time.
Very cool! Really neat that it pops out info about the individual objects too. Great to see that the code has been published too.
Might try and integrate this visualization with a new tool I'm developing called D2D [1], based on a new solver called Atom [2], to model high-thrust debris-to-debris transfers for multi-target active debris removal mission design.
Assuming you were talking about debris, you can choose to stop tracking objects in the tracking station. This also destroys the object, unlike the pesky real world.
But if you've got that many stations/satellites that you want to keep, you're on your own :).
If you zoom out a bit, there are noticeable "holes" above the North and South Poles where the density of objects is lower. Does anyone know what is causing these holes?
* Those spots are the furthest possible distance from the equator (in angular terms), so they should be the most expensive places to put something in orbit (either you launch from a northerly/southerly latitude or spend a lot of fuel on maneuvering into that orbit either way that's expensive)
* Maybe Earth's magnetic field interferes with electronics (less protection from the sun's radiation)
* No one really lives there so there's fewer reasons to spend a lot of money putting something in orbit
Most satellite footprints (imagine a cone from the satellite to the earth) are quite big I'd guess, so the need to launch into a truly polar orbit to capture all of the poles isn't needed.
That said my knowledge comes from playing KSP with the scansat mod.
I think it's just a math artifact. There's lots of "holes" in the orbit inclinations -- their distribution is actually very non-uniform. But at a frozen moment in time, the object's latitude will be anywhere from -i to +i, so the latitude distribution is "smeared out" over the whole range. The gap in the polar inclinations is the only one that's not, so that's the latitude gap you see.
Here's a histogram of the orbit inclinations where you can see this:
Right - even though polar orbits are pretty useful, so there probably are quite a few satellites with inclinations close to 90 degrees, they spend less than 10/360 = 2.8% of their time within 5 degrees of the north pole. What's surprising is the sudden increase in the density of stuff around 80 degrees north.
One possible explanation is the combination of the iridium 33 collision debris field, which is in orbits with inclinations around 86 degrees, and Fengyun 1C debris, which is around 99 degrees (so, 81 degrees but going the opposite direction). The limit of the distributions of those two clusters might account for the clear 'edge' of the circle around the pole.
No network traffic is generated after the initial load so my guess is that this JSON file is generated on the server from some other data source and is read on load and then continues to calculate positions from that initial load. The data on the server changes every 10 - 15 minutes it seems...must be a script updating it.
My first thought is there is a lot of material up there that is going to just burn up in the atmosphere at some point. Would be nice to collect it all together for some later use?
Maybe some kind of solar sail salvage drone could do it.
Steam punk, space stations cobbled together from bits of old rockets and satellites.
One of my first startup ideas I pitched to YC was to deorbit the inactive LEO satellites/debris as as service utilizing kilowatt-class lasers utilize radiation pressure to degrade the orbit enough to let atmospheric drag take care of the rest.
Well due to (IIRC) the Outer Space Treaty, spacecraft launched is still owned by their original company and I dont think the original company, or anyone else for that matter wants to pay to cleanup their trash, therefore no market.
Didn't get interviewed for most likely that reason.
We decided against launching them because the laser would have a limited power supply and could only deorbit X amount of debris before completely depleting its power supply; something solar panels can't effectively recharge (well you'd need A LOT of them). Combine that with cost for launch, it gets pretty expensive to deorbit only a few satellites.
Because of this we went with surface based lasers; they could be recharged using the local grid and clean a specific section of the sky. We looked at placing lasers at locations with high altitude and cross referenced them with the local $ per kilowatt hour. Never really got to the stage of deciding where to place one since we were still stuck with figuring out the market for it. I guess someones active satellite needs to get Sandra Bullocked by some old debris before we start going "hey. there's a market for cleanup!".
The ISS is currently looking into a laser system to clean up debris if i remember correctly. I guess if they ever figure out the person who uses it would get to call him/herself "ISS Door Gunner"
I feel like this sort of visualization really makes us realize how much space there is out there. There is SO MUCH debris just flying out there and yet we manage to avoid any of it with nearly every launch we've made.
I'm sure there's money in recycling/reusing the rare and expensive metals and components of now-defunct satellites, but I think it would probably encounter a) resistance from the owners of those satellites if it's not just an altruistic cleanup job sanctioned by governments, and b) related to what you say, the cost of actually performing the task would undoubtedly outweigh any money recouped.
Do you mean the ones in geostationary orbit above the equator? If so: "A geostationary orbit can only be achieved at an altitude very close to 35,786 km (22,236 mi), and directly above the Equator. This equates to an orbital velocity of 3.07 km/s (1.91 mi/s) or an orbital period of 1,436 minutes, which equates to almost exactly one sidereal day or 23.934461223 hours. This ensures that the satellite will match the Earth's rotational period and has a stationary footprint on the ground. All geostationary satellites have to be located on this ring." [1]
Edit: Klunky hack you can pop in the URL bar to make it go zoom:
Once you run that, screw with camYawIncr directly, rather than re-running that. Clicking a particular element causes jiggling as the klunky hack fights with the code tracking the element.You may need something other than .001, depending on what frame rate you're getting.
(Edit edit: There's something to be said for this whole "web" thing sometimes. It's neat that we can hack on code like this....)