1 / 23

ORBITAL

ORBITAL. Orbital Simulation and Telemetric Data Collection Software. Developed By: Aaron M. Rosenfeld. Specifications. ORBITAL accurately simulates space flight of one spacecraft around a single planet.

joan-mcdonald
Download Presentation

ORBITAL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ORBITAL Orbital Simulation and Telemetric Data Collection Software Developed By: Aaron M. Rosenfeld

  2. Specifications • ORBITAL accurately simulates space flight of one spacecraft around a single planet. • Displays a 2D view port of space which can be centered on different objects or be freely moved. • Collects telemetry data which can be displayed as graphs in real time or post-simulation.

  3. User Interface

  4. Autonomous Guidance • ORBITAL currently supports only orbit-stabilization guidance. It can autonomously maintain LEO (Low Earth Orbit) and GEO (Geosynchronous Earth Orbit). • In the future, ORBITAL will be able to complete more advanced orbital maneuvers such as Hohmann transfer orbits, direct transfer orbits, and “sling-shot” orbits around a planet.

  5. Firing System • To accurately portray real-world manual guidance systems, a simple firing system was used. • User selects a length of time to fire the engine (currently only max thrust). • User can manually ignite the engine or set a pre-defined position to do so. These positions can be an angle with respect to the planet, a distance threshold, or at an apogee or perigee.

  6. Firing System Example • The following demonstrates a very basic course correction to take a spacecraft from LEO to an orbit of just under 8,000 km. • The firing system was set to fire at full thrust for 100 seconds at the next occurring apogee.

  7. Firing System (Setup)

  8. Firing System (Burn)

  9. Firing System (Completion)

  10. Firing System Example 2 • This example shows how one can use ORBITAL’s firing system to cause a spacecraft to re-enter the Earth’s atmosphere. • Only one burn was used here in a retrograde orientation (the spacecraft is facing the opposite direction of travel) which slows the spacecraft, allowing it to descend.

  11. Firing System 2 (Setup)

  12. Firing System 2 (Burn)

  13. Firing System 2 (Completion)

  14. Geosynchronous Orbit Stabilization • The following is a demonstration of the Geosynchronous Orbit Stabilization system (GeoSync) included with ORBITAL. • No manual course corrections were made and time acceleration error was negligible (under .4%).

  15. Geosynchronous Orbit Stabilization

  16. Geosynchronous Orbit Stabilization

  17. Geosynchronous Orbit Stabilization

  18. To Do • For Users • Add UI for intitial settings. • User-defined spacecraft setting such as weight, fuel, etc. • User-defined planet specifics such as radius, mass, etc. • Make orbital maneuvers (LEO, GEO) buttons configure burn(s) to get the spacecraft into that orbit. • Allow more than one planet. This will require a complete re-working of the software's computational methodology so it may not be soon. • Add units for user-defined graphs. • For Developers • Complete re-orgazination of RenderFrame class structure. File is horribly messy. • Create 'System' class for ship/planet. • Create 'UI' class for all UI elements and functionality. • Create 'InputController' class to handle all user input via mouse, keyboard, etc. • Find a better method of UIElement.Button invocation and boolean checking (Pointers?). • Possibly create a math class of some sort to deal with all the distance, drag, and trajectory calculations.

  19. Time Acceleration Computations • If time is accelerated, acceleration, velocity, and position cannot be computed at every single moment in time. • Cannot simply evaluate these vectors at the few moments the time acceleration allows. Error would be too great. • Utilized a method called “Dynamic State Vector Propagation” developed by Martin Schwieger, PhD. • Assumes a quadratic interpolation of vectors between all known times. • Integration of the acceleration vectors between tn and tn+1 gives us an estimated velocity which is then used to determine position. • Error low enough to allow up to 1.0 x 103 time acceleration in LEO which is does not actually have a quadratic interpolation. • Proof will be available on the ORBITAL website very soon.

  20. Technical Data • Full program is about 3,000 lines of code. • Completely coded in C# .NET with no “unsafe” code blocks (i.e. no direct memory management). • Extensive use of delegates to pass data between forms without needing pointers and unsafe code. • Client was originally a stand alone render screen that has just recently been added to the new full MDI system. • Full optimization benchmark completed.

  21. Technical Data (con’t.) • Telemetry Data • All telemetry data is stored even if it is not being used in a real-time graph. • Allows for later retrieval or mid-simulation display. • All data stored in packets (struct ShipDataPacket) that allow for very quick extraction of data. • Future • Allow for statistical analysis of graphs (regression, min, max, mean, standard deviation, etc) • Allow users to add markers to the graphs (horizontal or vertical reference lines).

  22. Optimization Findings • After benchmarking the following changes were made: • All foreach loops were changed to forloops which resulted in a Log(N) decrease in runtime. • All non-inherited classes were changed to sealed improving runtime by allowing all virtual methods to be treated as finally declared. • String modification in frequent methods were concatenation with the StringBuilder class instead of + contamination, decreasing runtime by a factor of 14. • The repaint method was changed from a self-invoke to a System.Threading.Timer invoked event relieving nearly 32% of processor usage.

  23. Contact • Aaron Rosenfeld • E-Mail: aaron.rosenfeld@drexel.edu

More Related