Method and system for streaming buffer value propagation - Patents.com

Abstract

The system, method, and instructions for the computer-readable medium may include obtaining user-selected configuration parameters for the trajectory simulation at a client machine; transmitting a first set of configuration parameters for the trajectory simulation from the client machine to a remote system via a network connection, the first set of configuration parameters including the user-selected configuration parameters; receiving at the client device a stream of trajectory data including points along the trajectory from the removal device via the network connection, the points along the trajectory being determined by the remote system based on the first set of configuration parameters; and presenting a dynamic rendering of the trajectory simulation on a display, the trajectory simulation being based on the stream of trajectory data.

Description

[Technical field]

[0001] cross reference

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 301,919, filed January 21, 2022, and U.S. Provisional Patent Application No. 63 / 368.954, filed July 20, 2022, each of which is fully incorporated by reference into this specification.

[0002] Statement Regarding Federally Sponsored Research

[0002] This invention was made with US Government support under Contract No. FA8649-20-9-9147 from the US Air Force SBIR / STTR Center of Excellence. [Background technology]

[0003] background

[0003] Improvements in the cost per pound of putting a satellite into orbit, as well as the fact that space flight is now in its eighth decade (depending on the start date chosen), mean that the number of objects orbiting the Earth, either by design or accident, will continue to increase. The increasing amount of orbited material presents further challenges, as mission planners and other specialists responsible for planning satellite orbits must design orbits to meet prescribed mission criteria, such as geosynchronicity, while avoiding collisions in an increasingly crowded space environment.

[0004]

[0004] Furthermore, external factors such as the global health crisis and changing employee sentiment have caused experts to move from centralized offices and research facilities with direct access to high-performance computers capable of running high-dimensional, high-precision trajectory simulations to their homes or remote workplaces, where they access servers or other workplace computing resources via client computing devices such as laptops or tablets that generally do not have the computing power or memory resources to handle such simulations without significant latency, if at all (e.g., waiting an hour for simulation results). Summary of the Invention [Means for solving the problem]

[0005] overview In one embodiment, the method may include receiving, by a graphical user interface (GUI) at the client machine, user-selected configuration parameters for the trajectory simulation presented by the GUI, and transmitting, by the client machine, a first set of configuration parameters for the trajectory simulation to a streaming data interface via a network connection, the first set of configuration parameters including the user-selected configuration parameters, the streaming data interface communicatively connected to a propagator executing on the host machine. The method may further include, at the client machine, determining an estimated trajectory based on the user-selected configuration parameters, displaying a rendering of the estimated trajectory by the GUI, receiving, from the streaming data interface via the network connection, a stream of trajectory data including points along the trajectory calculated by the propagator based on the first set of configuration parameters, at the client machine, interpolating the stream of trajectory data to determine points along the trajectory between the points calculated by the propagator to generate an interpolated stream of trajectory data, and displaying a dynamic rendering of the interpolated stream of trajectory data by the GUI.

[0006]

[0006] In another embodiment, a client device may include a display and a processor. The processor may be configured to: receive, via a graphical user interface (GUI) presented on the display, user-selected configuration parameters for a trajectory simulation presented by the GUI; transmit a first set of configuration parameters for the trajectory simulation to a streaming data interface via a network connection, the first set of configuration parameters including the user-selected configuration parameters, the streaming data interface communicatively connected to a propagator executing on a host machine; determine an estimated trajectory based on the user-selected configuration parameters; display a rendering of the estimated trajectory by the GUI; receive from the streaming data interface via the network connection a stream of trajectory data including points along the trajectory calculated by the propagator based on the first set of configuration parameters; interpolate the stream of trajectory data to determine points along the trajectory between the points calculated by the propagator to generate an interpolated stream of trajectory data; and display a dynamic rendering of the interpolated stream of trajectory data by the GUI.

[0007]

[0007] In another embodiment, a non-transitory computer-readable medium includes instructions that, when executed by a processor, cause a client device to receive, via a graphical user interface (GUI) presented on a display, user-selected configuration parameters for a trajectory simulation presented by the GUI; transmit a first set of configuration parameters for the trajectory simulation to a streaming data interface via a network connection, the first set of configuration parameters including the user-selected configuration parameters, the streaming data interface being communicatively connected to a propagator running on a host machine; determine an estimated trajectory based on the user-selected configuration parameters; display a rendering of the estimated trajectory via the GUI; receive from the streaming data interface via the network connection a stream of trajectory data including points along the trajectory calculated by the propagator based on the first set of configuration parameters; interpolate the stream of trajectory data to determine points along the trajectory between the points calculated by the propagator to generate an interpolated stream of trajectory data; and display a dynamic rendering of the interpolated stream of trajectory data via the GUI.

[0008]

[0008] In another embodiment, the method may include (a) obtaining, at a client machine, user-selected configuration parameters for the trajectory simulation; transmitting a first set of configuration parameters for the trajectory simulation from the client machine via a network connection to a remote system, the first set of configuration parameters including the user-selected configuration parameters; (c) receiving, at the client device, a stream of trajectory data including points along the trajectory from the removal device via the network connection, the points along the trajectory being determined by the remote system based on the first set of configuration parameters; and (d) presenting a dynamic rendering of the trajectory simulation on a display, the trajectory simulation being based on the stream of trajectory data.

[0009]

[0009] In another embodiment, a client device may include a display and one or more processors configured to: (a) obtain user-selected configuration parameters for the trajectory simulation; (b) send a first set of configuration parameters for the trajectory simulation to a remote system via a network connection, the first set of configuration parameters including the user-selected configuration parameters; (c) receive a stream of trajectory data including points along the trajectory from the remote system via the network connection, the points along the trajectory being determined by the remote system based on the first set of configuration parameters; and (d) present a dynamic rendering of the trajectory simulation on the display, the trajectory simulation being based on the stream of trajectory data.

[0010]

[0010] In another embodiment, one or more non-transitory computer-readable media include instructions that, when executed by one or more processors, cause a client device to: (a) obtain user-selected configuration parameters for the trajectory simulation; (b) send a first set of configuration parameters for the trajectory simulation to a remote system via a network connection, the first set of configuration parameters including the user-selected configuration parameters; (c) receive a stream of trajectory data including points along the trajectory from the remote system via the network connection, the points along the trajectory being determined by the remote system based on the first set of configuration parameters; and (d) present a dynamic rendering of the trajectory simulation on a display, the trajectory simulation being based on the stream of trajectory data.

[0011]

[0011] Other technical features may be readily apparent to those skilled in the art from the following drawings, descriptions, and claims.

[0012] Incorporation by Reference

[0012] All publications, patents, and patent applications mentioned in this specification are incorporated by reference herein to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference. To the extent that the publications and patents or patent applications incorporated by reference conflict with the disclosure contained in this specification, it is intended that the specification supersedes or supersedes any such conflicting material.

[0013] BRIEF DESCRIPTION OF THE DRAWINGS For a more complete understanding of the present disclosure and its advantages, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which: [Brief description of the drawings]

[0014] [Figure 1] 1 illustrates an example of a client device according to certain embodiments of the present disclosure. [Diagram 2]

[0015] 1 illustrates an example of a server that can act as a backend propagator, according to certain embodiments of the present disclosure. [Diagram 3]

[0016] 1 illustrates an example of an architecture for implementing a streaming buffer propagator system according to various embodiments of the present disclosure. [Figure 4A]

[0017] 1 illustrates an example of a graphical user interface (GUI) for configuring and receiving a buffered stream of trajectory data from a backend propagator, according to some embodiments of the present disclosure. [Figure 4B]

[0018] 1 illustrates another example of a graphical user interface (GUI) for configuring and receiving a buffered stream of trajectory data from a backend propagator, according to some embodiments of the present disclosure. [Figure 4C]

[0019] 1 illustrates another example of a graphical user interface (GUI) for configuring and receiving a buffered stream of trajectory data from a backend propagator, according to some embodiments of the present disclosure. [Figure 4D]

[0020] 1 illustrates another example of a graphical user interface (GUI) for configuring and receiving a buffered stream of trajectory data from a backend propagator, according to some embodiments of the present disclosure. [Figure 4E]

[0021] 1 illustrates another example of a graphical user interface (GUI) for configuring and receiving a buffered stream of trajectory data from a backend propagator, according to some embodiments of the present disclosure. [Figure 4F]

[0022] 1 illustrates another example of a graphical user interface (GUI) for configuring and receiving a buffered stream of trajectory data from a backend propagator, according to some embodiments of the present disclosure. [Figure 4G]

[0023] 1 illustrates another example of a graphical user interface (GUI) for configuring and receiving a buffered stream of trajectory data from a backend propagator, according to some embodiments of the present disclosure. [Figure 4H]

[0024] 1 illustrates another example of a graphical user interface (GUI) for configuring and receiving a buffered stream of trajectory data from a backend propagator, according to some embodiments of the present disclosure. [Diagram 5]

[0025] 1 illustrates operations of an exemplary method for implementing a data clutch, according to certain embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Detailed Description

[0026] While various embodiments of the present invention have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Numerous modifications, changes, and substitutions may occur to those skilled in the art without departing from the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed.

[0016]

[0027] Developing a system and method for enabling remote configuration and access to numerically integrated, high-precision orbit simulations with minimal latency represents a source of technical challenges and opportunities for improvement in the art. This disclosure provides embodiments of a streaming buffer numerical propagator system and method for providing same.

[0017]

[0028] The systems, methods, computer-readable media, and techniques described herein provide numerous advantages. For example, computational and time efficiency can be advantageously improved by using a remote system to determine points along a trajectory that are then transmitted to a client device. In another example, because certain embodiments according to the present disclosure provide locally generated trajectory estimates, a user can advantageously configure a trajectory simulation more efficiently (e.g., in terms of transmitting data) by avoiding waiting for the propagation of trajectories that, if estimated, are not of interest.

[0018] Example of remote orbital simulation device

[0029] FIG. 1 illustrates a non-limiting example of a device 100 that allows a user to remotely configure a trajectory simulation and present the results of the remotely performed trajectory simulation, according to some embodiments of the present disclosure. According to various embodiments of the present disclosure, the device 100 may be implemented as one or more of a smartphone, tablet, or laptop computer. In certain embodiments, one skilled in the art will appreciate that the device 100 may have more or fewer components than shown, and other embodiments of the device are possible, including a processor, memory, network interface, and support for receiving inputs provided to a display. The embodiment of the device 100 illustrated in FIG. 1 is for illustrative purposes only, and other configurations are possible. However, there are many different configurations of suitable devices, and FIG. 1 is not intended to limit the scope of the present disclosure to any particular implementation of the device.

[0019]

[0030] 1, device 100 may include a communication unit 110, which may include, for example, a radio frequency (RF) transceiver, a BLUETOOTH transceiver, or a WI-FI transceiver, a transmit (TX) processing circuit 115, a microphone 120, and a receive (RX) processing circuit 125. Device 100 may also include a speaker 130, a main processor 140, an input / output (I / O) interface (IF) 145, input / output devices 150, and a memory 160. Memory 160 may include an operating system (OS) program 161 and one or more applications 162.

[0020]

[0031] Applications 162 may include one or more client applications that enable device 100 to interface with a streaming data interface to which device 100 is connected over a network interface (e.g., by communication unit 110). According to some embodiments, resources of device 100 include, without limitation, speaker 130, microphone 120, input / output devices 150, and additional resources 180.

[0021]

[0032] The communication unit 110 can act as a network interface for the device 100. For example, the communication unit 110 can receive an incoming RF signal, e.g., a near field communication signal such as a BLUETOOTH or WI-FI signal. The communication unit 110 can downconvert the incoming RF signal to generate an intermediate frequency (IF) signal or a baseband signal. The IF signal or the baseband signal can be sent to the RX processing circuit 125, which generates a processed baseband signal by filtering, decoding, or digitizing the baseband signal or the IF signal. The RX processing circuit 125 can transmit the processed baseband signal to the speaker 130 (e.g., in the case of voice data) or to the main processor 140 for further processing (e.g., in the case of web browsing data, online game play data, notification data, or other message data). In addition, the communication unit 110 can include a network interface, such as a network card, or a network interface implemented by software.

[0022]

[0033] TX processing circuitry 115 may receive analog or digital voice data from microphone 120 or other outgoing baseband data (such as web data, email, or interactive video game data) from main processor 140. TX processing circuitry 115 encodes, multiplexes, or digitizes the outgoing baseband data to generate processed baseband or IF signals. Communications unit 110 may receive the processed baseband or IF signals from TX processing circuitry 115 and upconverts the baseband or IF signals to RF signals for transmission.

[0023]

[0034] The main processor 140 may include one or more processors or other processing devices and executes an OS program 161 stored in memory 160 to control the overall operation of the device 100. For example, the main processor 140 may control the reception of forward channel signals and the transmission of reverse channel signals by the communication unit 110, the RX processing circuitry 125, or the TX processing circuitry 115. In some embodiments, the main processor 140 may include at least one microprocessor or microcontroller. According to certain embodiments, the main processor 140 may be a low power processor, such as a processor that may include control logic to minimize consumption of the battery 199 or to minimize heat buildup within the device 100.

[0024]

[0035] Main processor 140 may also execute other processes and programs resident in memory 160. Main processor 140 may move data in and out of memory 160 as required by executing processes. In some embodiments, main processor 140 is configured to execute applications 162 based on OS programs 161 or in response to input from a user or applications 162. Applications 162 may include applications developed specifically for the platform of device 100 or legacy applications developed for previous platforms. Main processor 140 may be coupled to I / O interface 145, which may provide device 100 with the ability to connect to other devices, such as laptop computers and handheld computers. I / O interface 145 may be a communication pathway between these accessories and main processor 140.

[0025]

[0036] Main processor 140 may be coupled to input / output devices 150. An operator of device 100 may use input / output devices 150 to input data into device 100. Input / output devices 150 may include a keyboard, a touch screen, a mouse, a trackball, or other devices capable of functioning as a user interface to allow a user to interact with device 100. In some embodiments, input / output devices 150 may include a touch panel, an augmented reality or virtual reality headset, a (digital) pen sensor, keys, or an ultrasonic input device.

[0026]

[0037] Input / output device 150 may include one or more screens (e.g., a touch screen), which may be a liquid crystal display, a light emitting diode (LED) display, an optical LED (OLED), an active matrix OLED (AMOLED), or other screen capable of rendering graphics.

[0027]

[0038] Memory 160 may be coupled to main processor 140. According to certain embodiments, a portion of memory 160 may include random access memory (RAM) and another portion of memory 160 may include flash memory or other read-only memory (ROM). According to certain embodiments, device 100 may further include a separate graphics processing unit (GPU) 170.

[0028]

[0039] According to certain embodiments, device 100 may include additional resources 180 accessible by application 162, if permitted. According to certain embodiments, additional resources 180 may include an accelerometer or inertial measurement unit (IMU) 182, which may detect motion of the electronic device along one or more degrees of freedom. Additional resources 180, in some embodiments, include one or more cameras 186 of device 100, such as a complementary metal oxide semiconductor (CMOS) sensor type camera.

[0029]

[0040] According to various embodiments, the above-mentioned components of device 100 may be powered by a battery 199 (e.g., a rechargeable lithium-ion battery), the size, charge capacity, and load capacity of which are constrained in some embodiments by the form factor of the device and user demand. As a non-limiting example, in an embodiment in which device 100 is a smartphone, battery 199 may be configured to fit within the smartphone's housing and may be configured not to support a current load that would cause heat buildup (e.g., by running a graphics processing unit at full power for a sustained period of time).

[0030]

[0041] FIG. 1 illustrates an example of a device 100 that can function as a client device for remotely configuring and receiving trajectory simulations. For example, the device 100 can send data (e.g., input parameters) to a server and receive data (e.g., simulation data) from the server. Various modifications to FIG. 1 are possible. For example, the device 100 can include any number of components in any suitable arrangement. Generally, devices including computing and communication systems come in a wide variety of configurations, and FIG. 1 is not intended to limit the scope of the disclosure to any particular configuration. Although FIG. 1 illustrates one operating environment in which various features disclosed herein can be used, the features can be used in any other suitable system.

[0031] Remote orbit simulation server example

[0042] 2 illustrates an example of a server 200 that can be configured to perform trajectory simulation based on a remotely configured propagator, according to certain embodiments of the present disclosure. The embodiment of server 200 illustrated in FIG. 2 is for illustrative purposes only, and other embodiments can be used without departing from the scope of the present disclosure. According to certain embodiments, server 200 operates as a computationally powerful remote system that can receive data from one or more client devices (e.g., device 100 of FIG. 1), have processing and memory resources to perform back-end numerical integration-based trajectory simulation, and provide a stream of simulation result data over a network to one or more client devices (e.g., device 100 of FIG. 1).

[0032]

[0043] In the example shown in FIG. 2, the server 200 may include a bus system 205 that supports communication between at least one processing unit 210, at least one storage unit 215, at least one communication unit 220, and at least one input / output (I / O) unit 225.

[0033]

[0044] Processing unit 210 may execute instructions that may be loaded into memory 230. Processing unit 210 may include any suitable number and type of processors or other devices in any suitable arrangement. Examples of types of processing unit 210 include microprocessors, microcontrollers, digital signal processors, programmable gate arrays, application specific integrated circuits, and discrete circuits.

[0034]

[0045] Memory 230 and persistent storage 235 are examples of storage 215 and represent any structure capable of storing and facilitating retrieval of information, such as temporary or persistent data, program code, or other suitable information. Memory 230 may represent random access memory or any other suitable volatile or non-volatile storage device. Persistent storage 235 may include one or more components or devices that support long-term storage of data, such as ready-only memory, a hard drive, flash memory, or an optical disk.

[0035]

[0046] The communications unit 220 may support communications with other systems or devices. For example, the communications unit 220 may include a network interface card or a wireless transceiver to facilitate communications over a network. The communications unit 220 may support communications over any suitable physical or wireless communications link.

[0036]

[0047] The I / O unit 225 may allow for the input and output of data. For example, the I / O unit 225 may provide a connection for user input via a keyboard, mouse, keypad, touch screen, or other suitable input device. The I / O unit 225 may also send output to a display (e.g., a graphical user interface), a printer, or other suitable output device.

[0037] Remote Orbit Simulation Architecture Example

[0048] FIG. 3 illustrates an architecture 300 for configuring, receiving, and presenting a stream of trajectory simulation data on a client device according to various embodiments of the present disclosure.

[0038]

[0049] With reference to the illustrative example of FIG. 3, in some embodiments, architecture 300 includes three computing platforms: client device 301, streaming data interface 351, and propagator 371. These three computing platforms may be communicatively connected (e.g., via a network, a hardline connection, etc.). In certain embodiments, architecture 300 may include additional client machines that connect to propagator 371 via streaming data interface 351. Similarly, in some embodiments, there may be multiple instances of propagator 371. Additionally or alternatively, streaming data interface 351 and propagator 371 may be implemented on a common device. Furthermore, in some embodiments, propagator 371 may be implemented on an instance of a virtual machine. One skilled in the art will appreciate that architecture 300 may be both flexible and scalable with respect to the number and type of machines used in a given implementation.

[0039]

[0050] As shown in the illustrative example of FIG. 3, the client device 301 is an instance of a remote device (e.g., device 100 of FIG. 1) connected via a network interface (e.g., communication unit 110 of FIG. 1) to one or more devices (e.g., server 200 of FIG. 2) that implement the streaming data interface 351. In some embodiments, the client device 301 further includes one or more instances of a connection application programming interface 305 for maintaining a persistent connection between the client device 301 and the streaming data interface 351, thereby avoiding the request-and-response connection approach utilized by HTTP web connections. In some embodiments, the connection API 305 includes a WebSocket API for establishing a communication session between the client device 301 and the streaming data interface 351. In various embodiments, the connection API 305 includes a remote procedure call (RPC) API configured to provide microservices, e.g., gRPC.

[0040]

[0051] 3, the client device 301 further includes an application that provides one or more graphical user interfaces (GUIs) 310 that enable a user to configure, receive, and view streams of trajectory simulation data at the client device 301. Non-limiting example instances of GUIs 310 are shown with respect to Figures 4A-4C of the present disclosure.

[0041]

[0052] Systems for performing numerical integration of simulated orbital paths, also referred to herein as propagators, typically present an operator with at least two layers of configurable parameters for controlling the simulation. The first layer includes the orbital parameters of the simulation. The term "orbital parameters" as used in this disclosure encompasses parameters of the force model that represents the orbital path. Examples of orbital factors include, without limitation, the oblateness of the Earth, gravitational forces from the Moon and Sun, atmospheric drag, and orbital parameters that characterize the initial position and orientation of the orbiting object. The second layer includes calculation-specific parameters. The term "calculation-specific parameters" as used in this disclosure encompasses parameters that specify aspects of how the orbital simulation is calculated at the server and animated at the client device 301. Examples of calculation-specific parameters include, without limitation, the selection of an integrator, the step value and tolerance used by the selected integrator, the start and end dates of the propagation, and the playback speed. Setting the appropriate orbital and calculation-specific parameters can be frustrating for new users or for users configuring simulations across a network to remote computers without advanced academic training in celestial mechanics. Thus, in certain implementations, the client device 301 includes one or more software modules that implement the dynamic step function algorithm 315. According to various embodiments, the dynamic step function algorithm 315 determines the optimal number and time interval of computation steps for each trajectory given the camera angle. In this way, the propagator 371 provides a sufficient number of data points for the interpolation and estimation module 320 to present a smooth visual trajectory via the GUI 310, while at the same time minimizing the front-end processing load performed by the interpolation and estimation module 320.

[0042]

[0053] As shown in the illustrative example of FIG. 3, the client device 301 includes program code that, when executed by the device's processor, provides an instance of an estimation and interpolation module 320. According to various embodiments, the estimation and interpolation module 320 is configured to receive orbital parameters for a simulation and locally determine an estimation of the orbit (e.g., using a two-body model that excludes computationally expensive factors such as atmospheric drag and the effects of other celestial bodies) that can be presented by the GUI 310. In addition, the estimation and interpolation module 320 is further configured to receive a stream of orbital data from the propagator 371 via the streaming data interface 351. According to various embodiments, the orbital data includes calculated points along the orbit at a predefined time step interval (e.g., a time step interval determined by the dynamic step function algorithm 315). In some embodiments, in order to present the orbit simulation by the GUI 310, it is necessary to determine or interpolate points on the trajectory of the orbit that correspond to the times between the time steps of the orbit data received from the streaming data interface 351. According to various embodiments, the estimation and interpolation module 320 fits points between the orbit data points provided by the streaming data interface 351.

[0043]

[0054] According to various embodiments, the streaming data interface 351 includes at least the following components: an instance of the connection API 355 and a pre-processing / buffering stage 360. As discussed elsewhere in this disclosure, in certain embodiments, the architecture 300 is both flexible and scalable, allowing multiple propagators 371 to connect to the client device 301 through the streaming data interface 351 without any modification of the operation of the propagators 371 or their output. In this manner, the propagators 371 may output the results of a given simulation as large "drops" of data that exceed the bandwidth of the connection, or intermittent bits depending on the computation parameters. Thus, in various embodiments, the streaming data interface 351 includes a pre-processing and buffering stage 360 ​​that operates to buffer trajectory data received from the propagators 371 so that a steady stream of trajectory data can be passed between the streaming data interface 351 and the client device 301. As shown in FIG. 3, the streaming data interface 351 further includes one or more connection APIs 355, which operate similarly to the connection API 305 in the client device 301 to maintain a persistent connection between the client device 301 and the streaming data interface 351.

[0044]

[0055] According to various embodiments, architecture 300 further includes one or more propagators 371 that include a processing platform (e.g., server 200 of FIG. 2, a cloud, or a virtualized equivalent thereof) configured to perform orbit simulations according to one or more computational models. Examples of computational models that may be implemented in propagator 371 include the J2 propagator model, the J4 propagator model, the Simplified General Perturbation (SGP) model, and the Simplified Deep Space Perturbation (SDP) model.

[0045] Example of a trajectory simulation interface

[0056] 4A-4H illustrate an example of configuring and receiving a trajectory simulation in a GUI (e.g., GUI 310 of FIG. 3) provided by a client device (e.g., client device 301 of FIG. 3) according to various embodiments of the present disclosure. For convenience, cross-referenced elements common to several of FIGS. 4A-4H are similarly numbered. GUI 400 may be implemented on any suitable processing platform (e.g., device 100 of FIG. 1) configured to implement a streaming data interface (e.g., via connection API 305 of FIG. 3) and a streaming connection with an interpolation and estimation module (e.g., interpolation and estimation module 320 of FIG. 3). Examples of suitable processing platforms include, without limitation, laptop computers, tablets, and smartphones.

[0046]

[0057] Referring to the illustrative example of FIG. 4A, GUI 400 includes a view of a central body 401 (Earth in this case) that is controllable by a camera widget 403 that allows a user to set camera parameters such as zoom and viewpoint. According to various embodiments, GUI 400 further includes one or more widgets that allow a user to specify both orbital parameters and parameters related to the calculation. For example, widget 405 allows a user to specify which perturbations are to be considered by the propagator model. Similarly, widget 407 allows a user to specify the type of object to be put into orbit. According to various embodiments, widget 409 allows a user to specify one or more orbital parameters such as the semi-major axis and inclination of the orbit with respect to the Earth's equator. As shown in FIG. 4A, as the user adjusts the orbital parameters in GUI 400, an orbit estimate 411 of the orbit is displayed. In certain embodiments, orbit estimate 411 is generated by the interpolation and estimation module 320 of FIG. 3. According to various embodiments, local orbit estimation 411 includes an estimate of the orbital path calculated locally (e.g., on the client device) based on a subset of parameters available for configuration in GUI 400 using a computationally lightweight analytical (e.g., a model that does not assume step-by-step numerical integration) model such as the Keplerian orbit model.

[0047]

[0058] According to various embodiments, the front-end application providing the GUI 400 can automatically determine initial values ​​for the calculation parameters (e.g., time step values ​​determined by the dynamic time step function algorithm 315 of FIG. 3), but provide options for further user configuration (e.g., via one of the pull-down menus 413). In certain embodiments, the trajectory calculations can be made in an adaptive manner, with the time step values ​​depending on the position or curvature of the ellipse, with areas of the trajectory with greater curve change having smaller time steps.

[0048]

[0059] As shown in FIG. 4A, GUI 400 further includes an execution widget 415 that allows a user to specify a date range over which the simulation will be run and can initiate a process of providing a set of simulation parameters (e.g., both user-selected and automatically generated orbit and calculation-related parameters) to one or more backend systems that provide a propagator (e.g., propagator 371 of FIG. 3) for running the orbit simulation.

[0049]

[0060] Referring to the illustrative example of FIG. 4B, the GUI 400 is shown in an intermediate state, where simulation parameters are provided to the backend propagator via a streaming data interface (e.g., streaming data interface 351 of FIG. 3), and the backend propagator has begun numerical integration but has not yet output enough trajectory data to fill the buffer of the streaming data interface 351 so that a stream of trajectory data can be provided to the client device 301. Because certain embodiments according to the present disclosure provide a locally generated trajectory estimate 411, a user can advantageously configure the trajectory simulation more efficiently (e.g., in terms of data transmission) by avoiding waiting for the propagation of trajectories that are not of interest if estimated. In other words, the locally generated trajectory estimate 411 provides the user with an on-demand approximate visualization of what the final trajectory simulation will look like.

[0050]

[0061] FIG. 4C shows an example of a GUI 400 that presents a trajectory simulation based on a stream of trajectory data provided by a propagator to a client device (e.g., client device 301 of FIG. 3). With reference to the illustrative example of FIG. 4C, this figure shows the GUI 400 at a later time than shown in FIG. 4B. In the example of FIG. 4C, the propagator has populated a buffer (e.g., pre-processing and buffering stage 360 ​​of FIG. 3) with enough data to the point that a nearly continuous stream of trajectory data (e.g., a stream sufficient for the GUI 400 to present the propagation progress at a steady frame rate, similar to presenting a streaming video) is received at the client device over a persistent connection (e.g., a web socket connection established by connection API 305 of FIG. 3) with a streaming data interface.

[0051]

[0062] According to various embodiments, once the stream of trajectory data is received from the propagator, points between data points contained within the stream of trajectory data are interpolated (e.g., by the interpolation and estimation module 320 of FIG. 3 ) and a plot 420 of the trajectory's trajectory is calculated and rendered in near real-time in the GUI 400. According to certain embodiments, the trajectory data from the propagator is buffered by a streaming data interface, such that once the propagator has populated the buffer to a threshold level, streaming and rendering of the plot 420 may continue while the propagator continues to run the simulation. In this manner, certain embodiments according to the present disclosure can minimize the latency or wait time between the start of a simulation by the back-end propagator and when you start to see a visualization of the fully computed trajectory in the GUI 400.

[0052]

[0063] 4D-4H show additional examples of configuring and receiving an orbit simulation in a GUI that may be the same or similar to the graphic user interface of FIGS. 4A-4C, at least with respect to certain elements (e.g., locally generated orbit estimate 411).

[0053]

[0064] In some embodiments, if no changes are made to the trajectory after the initial propagation, all propagated trajectories may be cached (e.g., by the application) in memory (e.g., memcache). In some embodiments, an application receives a request that is converted to a hash key. That hash key may then be looked up in memory (e.g., a memcache database) to retrieve the result, if one exists. In some embodiments, the result may be verified to ensure that it includes all steps of the propagation. The initial call may be a hash of the request that returns the number of steps. In some embodiments, the application may append the step number to the hash key to get the individual steps of the propagation. For example, a request "123" may create a hash of "dsve", which may include the number of steps of the propagation. The initial call to memory (e.g., memcache) with a key of "dsve" may return 100 steps. Subsequent calls may be made with keys of "dsve1", "dsve2", "dsve3", ..., "dsve100". If no key matches the request, the key is sent with the request to the propagator, which streams the results to the backend and GUI. Then, in some embodiments, the propagator can simultaneously, in a separate thread, stream to the cache writer, which writes the stream to memory with a given number of propagation steps.

[0054] Example of how to

[0065] 5 illustrates an example method 500 for configuring and receiving a trajectory simulation on a client device (e.g., client device 301 of FIG. 3) according to various embodiments of the present disclosure. Method 500 can be performed on any suitable processing platform (e.g., device 100 of FIG. 1) capable of implementing a GUI (e.g., GUI 310 of FIG. 3) and an estimation and interpolation stage (e.g., interpolation and estimation module 320 of FIG. 3). Examples of suitable processing platforms include, without limitation, laptop computers, tablet computers, and certain smart phones.

[0055]

[0066] 5, in operation 505, a client device connected to a propagator by a streaming data interface (e.g., streaming data interface 351 of FIG. 3) receives, via a GUI presented on the device, user-selected configuration parameters for an orbit simulation calculated according to a numerical integration method on a computation platform (e.g., server 200 of FIG. 2) acting as a back-end propagator. In certain embodiments, the user-selected configuration parameters may be orbit parameters, such as parameters specifying the eccentricity of a satellite's orbit around the Earth or the semi-major axis of the orbit. In some embodiments, the user-selected computation parameters (e.g., selection of a force model) are also selected in operation 505 by a GUI (e.g., GUI 400 of FIG. 4).

[0056]

[0067] As shown in FIG. 5, in operation 510, the client device sends a first set of configuration parameters (including user-selected configuration parameters) to the streaming data interface, which in turn provides the first set of configuration parameters to the back-end propagator. According to various embodiments, the first set of configuration parameters includes all of the configuration parameters of the simulation (both trajectory and calculation) that can be set on the client device. In various embodiments, one or more parameters of the first set of configuration parameters are automatically set on the client device to a determined value (which can be reconfigured by the user if desired). Examples of parameters that can be automatically set on the client device include, without limitation, a step value of the calculation performed on the propagator. In response to receiving the first set of configuration parameters via the streaming data interface, the propagator begins to perform numerical integration according to the specified parameters to determine points along the simulated trajectory.

[0057]

[0068] In operation 515, an estimated trajectory is determined locally at the client device based at least on the user-selected configuration parameters received in operation 505. According to certain embodiments, the estimated trajectory is determined based on an analytical (e.g., not numerical integration) force model that considers only a subset of the configuration parameters. In contrast to the numerical integration performed by the propagator, generating the estimated trajectory is computationally inexpensive, allowing a preview of the simulated trajectory to be quickly generated and presented on a GUI.

[0058]

[0069] According to various embodiments, a rendering of the estimated trajectory (e.g., estimated trajectory 411 of FIG. 4A ) is presented by the GUI in operation 520. In some embodiments, operations 515 and 520 can be performed before operation 510, such that a rendering of the estimated trajectory is presented in the GUI as a preview of the fully computed trajectory. In this manner, the estimated trajectory operates a tool to help a user visualize the simulated trajectory and tune configuration parameters before sending the first set of parameters to the propagator.

[0059]

[0070] As shown in FIG. 5, in operation 525, after being allowed to run for a period of time, the propagator fills one or more buffers of the streaming data interface (e.g., pre-processing and buffering stage 360 ​​of FIG. 3) with enough trajectory data to support a data stream from which a dynamic rendering of the fully computed trajectory can be presented in the GUI. The stream of data can be received at a client device (e.g., by a persistent connection between the client device and the streaming data interface). As used in this disclosure, the phrase "dynamic rendering" refers to rendering of a trajectory where the rendering is updated as new trajectory data is received and interpolated at the client device. Using the systems, methods, computer-readable media, and techniques described herein, the client device can make adjustments to the trajectory simulation and then receive an updated trajectory simulation in response.

[0060]

[0071] According to various embodiments, the received stream of trajectory data is locally interpolated at the client device to determine points along the trajectory path between points specified in the stream of trajectory data from the propagator, at operation 530. Finally, at operation 535, a dynamic rendering of the interpolated stream of trajectory data (e.g., plot 420 of FIG. 4C) is presented in a GUI.

[0061] Additional Considerations

[0072] While various embodiments of the present invention have been shown and disclosed herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Numerous modifications, changes, and substitutions may occur to those skilled in the art without departing from the invention. It should be understood that various alternatives to the embodiments of the invention disclosed herein may be employed.

[0062]

[0073] It should be noted that the various example or suggestive ranges described herein are specific to the example embodiments and are not intended to limit the scope of the disclosed technology, but again merely provide example ranges of frequencies, amplitudes, etc. relevant to particular embodiments or use cases thereof.

[0063]

[0074] Unless a term is expressly defined in this patent using the sentence "As used herein, the term '_' is defined herein to mean '...'" or a similar sentence, no explicit or implicit limitation of the meaning of the term beyond the plain or ordinary meaning of the term is intended, and the term should not be construed as limited in scope based on any statement made in any section of this patent (other than the claim language). To the extent any term recited in the appended claims is referred to in this patent in a manner consistent with a single meaning, it is done so merely for clarity so as not to confuse the reader, and it is not intended that such claim term be implicitly or otherwise limited to that single meaning. Finally, unless a claim element is defined by the term "means" and a recitation of a function without any specification of structure, the scope of any claim element is not intended to be construed under application of 35 U.S.C. 112, paragraph 6.

[0064]

[0075] Throughout this specification, components, operations, or structures described as a single instance may be implemented by multiple instances. Although individual operations of one or more methods have been illustrated and described as separate operations, one or more of the individual operations may be performed simultaneously, and there is no requirement that the operations be performed in the order illustrated. Structures and functions presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functions presented as a single component may be implemented as separate components. These and other alterations, modifications, additions, and improvements are within the scope of the subject matter of this specification.

[0065]

[0076] Additionally, certain embodiments are described herein as including logic or certain routines, subroutines, applications, or instructions. These may constitute software (e.g., code embodied on a machine-readable medium) or hardware. In hardware, routines, etc. are tangible units capable of performing certain operations and may be configured or arranged in a certain way. In an exemplary embodiment, one or more computer systems (e.g., stand-alone, client, or server computer systems) or one or more hardware modules of a computer system (e.g., a processor or processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations described herein.

[0066]

[0077] In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may include dedicated circuitry or logic that is permanently configured (e.g., as a dedicated processor, such as a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC)) to perform certain operations. A hardware module may also include programmable logic or circuitry that is temporarily configured by software (e.g., as contained within a general-purpose processor or other programmable processor) to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) is driven by cost and time considerations.

[0067]

[0078] Thus, a hardware module may encompass a tangible entity, whether physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed), to operate in a certain manner or to perform certain operations as described herein. Considering an embodiment in which the hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one moment in time. For example, if the hardware modules include a general-purpose processor that is configured using software, the general-purpose processor may be configured as different individual hardware modules at different times. Thus, the software may, for example, configure the processor to configure a particular hardware module at one moment in time and a different hardware module at a different moment in time.

[0068]

[0079] A hardware module can provide information to and receive information from other hardware modules. Thus, the described hardware modules can be considered to be communicatively coupled. When multiple such hardware modules are present simultaneously, communication can be achieved by signal transmission (e.g., over appropriate circuits and buses) connecting the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times, communication between such hardware modules can be achieved, for example, by storing and retrieving information in memory structures accessible to the multiple hardware modules. For example, a hardware module can perform an operation and store the output of the operation in a memory device to which the hardware module is communicatively coupled. An additional hardware module can then access the memory device at a later time to retrieve and process the stored output. A hardware module can also initiate communication with an input or output device and act on a resource (e.g., a collection of information). Elements described as coupled and / or connected can refer to two or more elements that may or may not be in direct contact with each other (e.g., in direct physical contact) but still cooperate or interact with each other.

[0069]

[0080] Various operations of the example methods described herein may be performed, at least in part, by one or more processors that are temporarily or permanently configured (e.g., by software) to perform the associated operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. Modules referred to herein may include processor-implemented modules in some example embodiments.

[0070]

[0081] Similarly, the methods or routines described herein may be at least partially implemented by a processor. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented hardware modules. The performance of certain operations may be distributed among one or more processors that reside within a single machine, or even spread across several machines. In some exemplary embodiments, the processor may be located in a single location (e.g., in a home environment, in an office environment, or as a server farm), while in other embodiments, the processor may be distributed across multiple locations.

[0071]

[0082] Execution of certain processing may be distributed among one or more processors, which may reside within a single machine, or may be spread across multiple machines. In some exemplary embodiments, one or more processors or processor-implemented modules may be located in a single geographic location (e.g., in a home environment, an office environment, or a server farm). In other exemplary embodiments, one or more processors or processor-implemented modules may be distributed across several geographic locations.

[0072]

[0083] Although preferred embodiments of the present invention have been illustrated and disclosed herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. It is not intended that the present invention be limited by the specific examples provided herein. Although the present invention has been described with reference to the foregoing specification, the description and explanation of the embodiments herein are not intended to be construed in a limiting sense. Numerous modifications, changes, and substitutions may now occur to those skilled in the art without departing from the present invention. Furthermore, it should be understood that all aspects of the present invention are not limited to the specific depictions, configurations, or relative proportions set forth herein which depend upon a variety of conditions and variables. It should be understood that various alternatives to the embodiments of the present invention disclosed herein may be employed in practicing the present invention. It is therefore contemplated that the present invention covers any such alternatives, modifications, variations, or equivalents. It is intended that the appended claims define the scope of the present invention, and that the methods and structures within the scope of these claims and their equivalents are covered by the claims.

[0073]

[0084] Unless otherwise defined, all technical terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this subject matter belongs.

[0074]

[0085] As used in this specification and the appended claims, "some embodiments," "further embodiments," or "particular embodiments" means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Thus, the appearances of the phrases "in some embodiments," "in further embodiments," or "in particular embodiments" in various places throughout this specification do not necessarily all refer to the same embodiments. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0075]

[0086] As used in this specification and the appended claims, when the terms "at least," "greater than," or "greater than or equal to" are placed before or after the first number in a series of two or more numbers, the term "at least," "greater than," or "greater than or equal to" applies to each and every number in the series. For example, 1, 2, or 3 or more is equivalent to 1 or more, 2 or more, or 3 or more.

[0076]

[0087] As used in this specification and the appended claims, when the terms "up to," "less than," or "less than or equal to" appear after the first number in a series of two or more numbers, the terms "up to," "less than," or "less than or equal to" apply to each and every number in the series. For example, 3, 2, or 1 or less is equivalent to 3 or less, 2 or less, or 1 or less.

[0077]

[0088] As used herein, "or" is intended to mean what is also known as "inclusive or" or "disjunction," where when used as a logical statement, the phrase "A or B" is true if either A or B is true, or if both A and B are true, and when used as a list of elements, the phrase "A, B, or C" is intended to include all combinations of the elements listed in the phrase, e.g., any elements selected from the group consisting of A, B, C, (A,B), (A,C), (B,C), and (A,B,C), and so forth, if additional elements are listed. Thus, any reference to "or" herein is intended to encompass "or" unless otherwise specified.

[0078]

[0089] As used herein and in the appended claims, the indefinite articles "a" or "an," and the corresponding and related definite articles "the" or "said," are intended to mean one or more, respectively, unless otherwise specified, implied, or physically impossible. It should further be understood that the phrases "at least one of A and B, etc.", "at least one of A or B, etc.", "selected from A and B, etc.", and "selected from A or B, etc." are each intended to mean any listed element individually, or any combination of two or more elements, e.g., any of the elements from the group consisting of "A," "B," and "A and B together," etc.

[0079]

[0090] As used herein and in the appended claims, "about" or "approximately" may mean within an acceptable error range for a value, which depends in part on how the value is measured or determined, e.g., the limitations of the measurement system. For example, "about" may mean within one standard deviation or within more than one standard deviation, as is customary in the art. Alternatively, "about" may mean within a range of up to 20%, up to 10%, up to 5%, or up to 1% of a given value. When values ​​are described in the present application and claims, unless otherwise specified, the term "about" can be assumed to mean within an acceptable error range for the particular value.

[0080]

[0091] "Couple" and its derivatives refer to direct or indirect communication between two or more elements, whether or not the elements are in physical contact with one another. The terms "transmit", "receive", and "communicate" and their derivatives encompass both direct and indirect communication. The terms "include" and "comprise" and their derivatives are meant to include without limitation. The phrase "associated with" and its derivatives mean include, comprise within, interconnect, contain, be contained within, connect, couple, be in communication with, cooperate with, interleave, juxtapose, be adjacent to, be associated with, have, have a characteristic of, have a relationship with, and the like. The term "controller" refers to any device, system, or part thereof that controls at least one operation. Such a controller may be implemented by hardware or a combination of hardware and software or firmware. The functionality associated with a particular controller may be centralized or distributed, locally or remotely.

[0081]

[0092] Moreover, various functions described below may be implemented or supported by one or more computer programs, each of which is formed from computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, related data, or portions thereof adapted for implementation in suitable computer-readable program code. The phrase "computer-readable program code" may include any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" may include any type of medium accessible by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, compact disc (CD), digital video disc (DVD), or any other type of memory. "Non-transitory" computer-readable medium excludes wired, wireless, optical, or other communication links carrying transitory electrical or other signals. Non-transitory computer-readable media can include media that can store data permanently, as well as media that can store data and later be overwritten, such as a rewritable optical disk or an erasable memory device.

Claims

1. (a) obtaining, at a client machine, user-selected configuration parameters for a trajectory simulation; (b) transmitting a first set of configuration parameters for the trajectory simulation from the client machine to a remote system via a network connection, the first set of configuration parameters including the user-selected configuration parameters; and (c) receiving, at the client device, a stream of trajectory data from a removal device via the network connection, the stream including points along a trajectory, the points along the trajectory being determined by the remote system based on the first set of configuration parameters; (d) presenting a dynamic rendering of the trajectory simulation on a display, the trajectory simulation being based on the stream of trajectory data; and A method comprising:

2. determining, at the client machine, an estimated trajectory based on the user selected configuration parameters; (d) presenting a rendering of the estimated trajectory on the display prior to presenting the dynamic rendering of the trajectory simulation. The method of claim 1 further comprising:

3. The method of claim 2 , wherein the estimated orbit is determined analytically based on a subset of the first set of configuration parameters.

4. (d) prior to presenting the dynamic rendering of the trajectory simulation, interpolating the stream of trajectory data at the client machine to generate the trajectory simulation. The method of claim 1 further comprising:

5. 5. The method of claim 4, wherein interpolating the stream of trajectory data to generate the trajectory simulation comprises determining interpolation points along the trajectory between the points determined by the remote system.

6. determining, by the client machine, a second configuration parameter of the first set of configuration parameters based on the user selected configuration parameter; The method of claim 1 further comprising:

7. The method of claim 6 , wherein the second configuration parameter is a time step value for a propagator.

8. 2. The method of claim 1, wherein the remote system includes a host machine running a streaming data interface and a propagator, the streaming data interface and the host machine being communicatively connected.

9. Establishing a persistent connection between the client machine and the streaming data interface via at least one of a WebSocket or a Remote Procedure Call (RPC) connection. The method of claim 8 further comprising:

10. The method of claim 1 , wherein the client machine includes the display.

11. obtaining second user-selected configuration parameters at the client machine while the remote system is determining the points along the trajectory, the second user-selected configuration parameters including additional parameters of an updated trajectory simulation; and transmitting, by the client machine over the network connection to the remote system, a second set of configuration parameters for the trajectory simulation, the second set of configuration parameters including the second user-selected configuration parameters; determining, at the client machine, a second estimated trajectory based on the second user selected configuration parameters; presenting a rendering of the second estimated trajectory on the display; and receiving, at the client machine, a second stream of trajectory data from the remote system via the network connection, the second stream of trajectory data including a second point along a second trajectory, the second point along the second trajectory being determined by the remote system based on the second set of configuration parameters; at the client machine, interpolating the second stream of trajectory data to determine second interpolated points along the second trajectory between the second points determined by the remote system; presenting on the display a dynamic rendering of the updated trajectory simulation, the updated trajectory simulation being based on both (i) the stream of trajectory data and (ii) the second stream of trajectory data; The method of claim 1 further comprising:

12. The method of claim 11 , wherein the second user-selected configuration parameter relates to an in-orbit maneuver.

13. A display and (a) obtaining user-selected configuration parameters for a trajectory simulation; (b) transmitting a first set of configuration parameters for the trajectory simulation to a remote system via a network connection, the first set of configuration parameters including the user-selected configuration parameters; and (c) receiving a stream of trajectory data from the remote system via the network connection, the stream including points along a trajectory, the points along the trajectory being determined by the remote system based on the first set of configuration parameters; and (d) presenting a dynamic rendering of the orbit simulation on the display, the orbit simulation being based on the stream of orbit data; and one or more processors configured to A client device comprising:

14. the one or more processors: determining an estimated trajectory based on the user selected configuration parameters; (d) presenting a rendering of the estimated trajectory on the display prior to presenting the dynamic rendering of the trajectory simulation. The client device of claim 13 , further configured to:

15. The client device of claim 14 , wherein the estimated trajectory is determined analytically based on a subset of the first set of configuration parameters.

16. the one or more processors: (d) prior to presenting the dynamic rendering of the trajectory simulation, interpolating the stream of trajectory data to generate the trajectory simulation. The client device of claim 13 further configured to:

17. 17. The client device of claim 16, wherein interpolating the stream of trajectory data to generate the trajectory simulation comprises determining interpolation points along the trajectory between the points determined by the remote system.

18. the one or more processors: determining a second configuration parameter of the first set of configuration parameters based on the user selected configuration parameter The client device of claim 13 further configured to:

19. 20. The client device of claim 18, wherein the second configuration parameter is a time step value for a propagator.

20. the one or more processors: obtaining second user-selected configuration parameters while the remote system is determining the points along the trajectory, the second user-selected configuration parameters including additional parameters of an updated trajectory simulation; and transmitting a second set of configuration parameters for the trajectory simulation to the remote system via the network connection, the second set of configuration parameters including the second user-selected configuration parameters; determining a second estimated trajectory based on the second user selected configuration parameters; presenting a rendering of the second estimated trajectory on the display; and receiving a second stream of trajectory data from the streaming data interface via the network connection, the second stream of trajectory data including a second point along a second trajectory, the second point along the second trajectory being determined by the remote system based on the second set of configuration parameters; Interpolating the second stream of trajectory data to determine second interpolated points along the second trajectory between the second points determined by the remote system; and presenting on the display a dynamic rendering of the updated trajectory simulation, the updated trajectory simulation being based on both (i) the stream of trajectory data and (ii) the second stream of trajectory data; The client device of claim 13 , further configured to:

21. When executed by one or more processors, (a) obtaining user-selected configuration parameters for a trajectory simulation; (b) transmitting a first set of configuration parameters for the trajectory simulation to a remote system via a network connection, the first set of configuration parameters including the user-selected configuration parameters; and (c) receiving a stream of trajectory data from the remote system via the network connection, the stream including points along a trajectory, the points along the trajectory being determined by the remote system based on the first set of configuration parameters; and (d) presenting a dynamic rendering of the trajectory simulation on a display, the trajectory simulation being based on the stream of trajectory data; and One or more non-transitory computer-readable media comprising instructions that cause a client device to:

22. When executed by the one or more processors, determining an estimated trajectory based on the user selected configuration parameters; (d) presenting a rendering of the estimated trajectory on the display prior to presenting the dynamic rendering of the trajectory simulation.

22. The one or more non-transitory computer-readable media of claim 21, further comprising instructions for causing the client device to:

23. 23. The one or more non-transitory computer-readable media of claim 22, wherein the estimated trajectory is determined analytically based on a subset of the first set of configuration parameters.

24. When executed by the one or more processors, (d) prior to presenting the dynamic rendering of the trajectory simulation, interpolating the stream of trajectory data to generate the trajectory simulation.

22. The one or more non-transitory computer-readable media of claim 21, further comprising instructions for causing the client device to:

25. 25. The one or more non-transitory computer-readable media of claim 24, wherein interpolating the stream of trajectory data to generate the trajectory simulation comprises determining interpolation points along the trajectory between the points determined by the remote system.

26. When executed by the one or more processors, determining a second configuration parameter of the first set of configuration parameters based on the user selected configuration parameter; 22. The one or more non-transitory computer-readable media of claim 21, further comprising instructions for causing the client device to:

27. 27. The one or more non-transitory computer-readable media of claim 26, wherein the second configuration parameter is a time step value for a propagator.

28. When executed by the processor, obtaining second user-selected configuration parameters while the remote system is determining the points along the trajectory, the second user-selected configuration parameters including additional parameters of an updated trajectory simulation; and transmitting a second set of configuration parameters for the trajectory simulation to the remote system via the network connection, the second set of configuration parameters including the second user-selected configuration parameters; determining a second estimated trajectory based on the second user selected configuration parameters; presenting a rendering of the second estimated trajectory on the display; and receiving a second stream of trajectory data from the streaming data interface via the network connection, the second stream of trajectory data including a second point along a second trajectory, the second point along the second trajectory being determined by the remote system based on the second set of configuration parameters; Interpolating the second stream of trajectory data to determine second interpolated points along the second trajectory between the second points determined by the remote system; and presenting on the display a dynamic rendering of the updated trajectory simulation, the updated trajectory simulation being based on both (i) the stream of trajectory data and (ii) the second stream of trajectory data; 22. The one or more non-transitory computer-readable media of claim 21, further comprising instructions for causing the client device to:

Images