Feature Request: Orbital Plugin

[evenstensberg]

It would convenient to have an plugin that shows launches as well as their orbital data/telemetry. This could be consumed via:

• https://www.space-track.org
• https://github.com/shashwatak/satellite-js

References:

http://stuffin.space/

What do you think?

[gdunge]

I need this capability for one of my upcoming projects.

[larkin]

@gdunge Would you be looking to utilize data from some existing public source (e.g. space-track.org) or would you have data available from some internal source? We've talked with a few people about a plugin like this, and it shouldn't be hard to put together.

@ev1stensberg It's a useful view to have, have seen a few promising demos. Questions remain about whether we want to link it to our time conductor or allow it to visualize data coming from a source other than space-track.org.

[gdunge]

I'm interested in the ability to render my own telemetry data as the trajectory of a suborbital rocket. It could be used for demos and visualizations before the launch by generating a simulated trajectory stream.

During the flight, if the actual trajectory could be displayed from downlinked telemetry or radar tracking alongside the predicted trajectory, differences between the two would be a clue that something's not going as expected.

Into the future, i imagine using WebGL or something similar to show a 3D model of the vehicle (predicted vs. actual). Attitude, flight events (staging, engine on/off), or alert indications

Something like the animated displays from Satellite Toolkit that you see on NASA TV, perhaps. But hopefully less expensive. That's the plan, anyway.

[larkin]

@gdunge Just to clarify, you'd like to start with a 3d trajectory view, e.g. the kerbal map view or this view from a spacex webcast:

With this, what format would your trajectory data be-- TLEs? SGP4 model or similar? Or?

We have a few things in discussion like this so understanding what you're looking for (and getting your feedback) is very helpful here.

[gdunge]

The idea is something similar to that view, yes. Although for a suborbital trajectory, so a tighter focus - and no TLEs for a suborbital launch, of course. We haven’t decided what format(s) to support. KML? WebGL JSON? NMEA sentences? No clue.

I think my preference is that you pick whatever is easiest to get it working in Open MCT, and we’ll figure it out when we get there.

On Aug 7, 2017, at 3:54 PM, Pete Richards notifications@github.com wrote:

@gdunge https://github.com/gdunge Just to clarify, you'd like to start with a 3d trajectory view, e.g. the kerbal map view or this view from a spacex webcast: https://user-images.githubusercontent.com/226503/29045020-cd4192ce-7b76-11e7-9bc9-96fb4da5312c.png With this, what format would your trajectory data be-- TLEs? SGP4 model or similar? Or?

We have a few things in discussion like this so understanding what you're looking for (and getting your feedback) is very helpful here.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nasa/openmct/issues/1645#issuecomment-320777717, or mute the thread https://github.com/notifications/unsubscribe-auth/ABC_O1KW8OU_yMit8323k59jxNEu5Gk2ks5sV3l1gaJpZM4OSMjh.

-- Doug Weathers http://www.gdunge.com "There is no easy way from the Earth to the stars." - Seneca "We choose to go to the Moon and do the other things - not because
they are easy, but because they are hard." - John F. Kennedy

[larkin]

Need to specify plugin details so we can open up as a help-wanted.

[evenstensberg]

This would be a quite extensive plugin, which would need trajectory calculations as well as it needs to depend on telemetry to calculate the trajectory. Also, for the maps, threeJS or possibly also google maps api could be sufficient

[larkin]

@ev1stensberg typically there would be a ground system that performs trajectory calculations as part of the data processing workflow and then pushes the data to clients: Open MCT would only be responsible for visualizing that trajectory.

On the Open MCT side, there would be a plugin that takes that telemetry (e.g. TLEs, KML, WebGL JSON) and displays it on 3d globe or similar. I suspect we'd use cesiumjs for most suborbital and single body trajectories; I'm not sure if that is also a good solution for multi-body trajectories.

[evenstensberg]

@larkin Gotcha. I think that the "best" requirements for this would consist of

• Realtime telemetry that has trajectory ( current height, speed, longitude, altitude )
• History telemetry that has previous trajectory/telemetry of previously mentioned

We'd also need to make a sort of integrated 3D map in the OpenMCT project, and that sounds that should be included of OpenMCT and not for the given plugin.

[larkin]

@ev1stensberg Correct, the 3D map would be a separate Open MCT plugin from the plugin that provides the realtime/historical trajectory.

If the 3D map plugin is of good quality and we feel that it's reusable for other deployments then we'd like to include it in the core Open MCT package (similar to plots and tables).

[evenstensberg]

So first action would he to create the 3D map?

[larkin]

Yes. And a super simple plugin that provides a fake trajectory telemetry to test it with.

[evenstensberg]

We could group up all the plugin requests into one issue?

[evenstensberg]

Starting the work on this

[evenstensberg]

@larkin What do you want as the name of the trajectory map (plugin) ?

[larkin]

@ev1stensberg We tend to do plugin requests separately, easier to discuss and track and close out / update.

As for a name... We can always change that down the road if we find a good one. But how about....

openmct-trajectory-map

?

I know it's very unique :)

[evenstensberg]

@larkin Yeah sure. Is there any better alternative to Cesium? The API is really good, but the map itself is kinda blurry..

Creating the orbital plugin and the map separately so that the map could be reused.

[akhenry]

@ev1stensberg I've worked with Cesium a bit in the past, so let me know if I can help. In my experience it's great at doing 3D maps, and ok at doing 2D maps. But on the plus side, it does do both, which gives you the option of switching to a 2D ground track plot without any extra work.

I agree the imagery looks a little dull and blurry compared to say the 3D globe in Google Maps. From memory there were some graphical settings you could tweak in the API that might improve things a bit.

[akhenry]

Also, we're not married to Cesium (as far as I know), happy to listen to alternative proposals.

[evenstensberg]

@akhenry @larkin I'll integrate Cesium and let's take it from there

[evenstensberg]

Would it be convenient to use legacyRegistry for the plugin, or is the entire API now implemented?

[akhenry]

@ev1stensberg You should be able to get pretty far with the new API for this one. You can use the objects API for defining a new Orbital View type. You can then use the new view API to define the new orbital view, and of course the telemetry API for pulling down any positional data (eg. spacecraft position, orbital and ground tracks, etc). The View API is not yet documented, but take a look at #1807 for a rough guide.

[akhenry]

On the topic of telemetry, if you're dealing with discrete positional data, then it should map fairly well to our concept of 'telemetry'. On the other hand, if you're dealing with geometry (such as orbital and ground tracks defined in KML or GeoJSON) then it may not map so well, especially if the plugin natively supports those formats (which Cesium does). It might not make sense to use the telemetry API in that case. Keep us in the loop and we can talk about the best approach based on your data source, format, etc.

[evenstensberg]

@akhenry The view API allows to draw on screen like the imagary/display plugin? If so, then it could be great, first step would be to get a Cesium map drawn on screen and add respective features later

[evenstensberg]

Opened a small demo at #1851 for you to see. One problem is the distrubution of Cesium, it doesn't work well with AMD, and I had to download the source code before importing it. Tried every combination in the requireJS config, but the only way it was working was with the distribution.

https://cesiumjs.org/downloads/

[akhenry]

@ev1stensberg The orbital plugin should be a separate plugin and not a branch of the Open MCT source. As a plugin you can build it however you want (requireJS is not a requirement of using Open MCT). As an example, we have a very experimental "heatmap" plugin that builds using webpack - https://github.com/VWoeltjen/openmct-heatmap