Otherworldly Java: Gateway to the Moon and beyond

Transcript

Craig Davis: Let's dive in. Let's start the movie first. Here we go. I work on a program called the "Gateway." It is the next human outpost in space. It's going to be an international collaboration between NASA, ISA, Roscosmos, JAXA, various other space agencies. It will be humanity's proving ground for deep space technology, like solar electric propulsion and other deep space technology we have to test to make sure that we can get humans beyond the Earth-Moon system. It's also a staging location for these missions beyond Earth-orbit, like humans to Mars, humans to asteroids. This is what we're working on.

Where are we going to build this outpost? It's like a space station that's going to be compiled kind of like the ISS was. Well, we're going to the Moon, but because we've got objects coming and going from this space station, we have to have a special orbit. So this is a kind of lunar orbit we're used to, right? Apollo went to this kind of orbit. It's only about 100 kilometers from the surface in a circle, nice, well-behaved. It takes two hours to go around, but it's deep within the gravity wall of the Moon. So it's really expensive to get in and out of this orbit. So we're not going there. We're going to go to a special orbit. It's called a halo orbit. It's really big. It goes way farther away from the Moon, than the Apollo orbit did. So, at the farthest point, it gets 70,000 kilometers from the surface, and it takes an entire week to go around.

This orbit is interesting because it's affected simultaneously by the gravity fields, especially the Earth and the Moon and also the Sun, but this complicates a trajectory design. You can see it no longer behaves like a circle or an ellipse. The Earth is pulling that orbit around. It's complicated to design trajectories with this complicated kind of gravity fields. It's a highly sensitive problem. So, a small change at one point in the trajectory has a huge effect downstream, which is sort of the definition of a chaotic system. There's an enormous data space. There's lots of orbits that you can start from lots of positions and space, lots of energy levels, and we got to sort through all this data.

Now that we've added two gravity bodies, just two, even if you assume they're in perfect circles around each other, there's no analytical solution to this problem. And we can't use the old methods to do it. We require innovative design methods to do this, to find the needle in the haystack. We've got a huge data space of complicated orbits with no analytical solution, and we need to find the orbit we're looking for that will satisfy our mission constraints. So, how do we do this? I'll give you a clear that Java is involved.

Introduction

I'm an astrodynamicist at a.i. solutions. Unlike what Martin says, I don't work for NASA. So that's important to remember. I work for a contractor called a.i. solutions. We are astrodynamics company. We do work mainly for NASA and the Department of Defense. In my past life, I've done navigation of spacecraft to Mars through the NASA's Jet Propulsion Laboratory. This is Mars Express I worked on back in 2003. I led some ground system development at NASA Johnson Space Center. That means we're building the software that they use on the ground to fly the space station. How many of you all saw the movie "Gravity," anyone? That's what we don't want to happen. So I built the collision avoidance software for the ISS.

And for the past three years, I've been working on orbit design for the Gateway at NASA Johnson Space Center. We have these complicated orbits we're trying to get into, and that happens to be my area of expertise. Also, as a reminder, I don't represent NASA. So, if you're tweeting, don't say, "I saw a NASA scientist," because I don't want to get in trouble.

I'm an astrodynamicist. I'm not a software developer. I need tools in order to design these complicated orbits that may not exist. I've got colleagues who like to use numerical grid searches. I've tried myself trial and error. I was working on designing the Cassini end of life trajectory at Saturn and really big orbits that the Sun was pulling on. And this was my famous last words, "There has to be a better way to do this." That became my Ph.D. research because I was finding visual methods to use your intuition to involve the visualization into the design process to try to find a better way to design some of these orbits because it was really hard.

I did come up with some clever ideas, but I'm not a software developer, and I was using MATLAB, and they were not pretty. Not only were they not pretty, but they were hard to communicate. They were hard. I mean, I developed methods that I could use, but there's no way anyone else could ever navigate through my crummy software to use these methods as well. But then I started collaborating. At a.i. solutions, I got involved with a JavaFX. I call him a magician, really, a super amazing software developer named Sean Philips. He saw my data, and he's very interested in visualization and big data management. He started telling me about what is possible, which I didn't know. So we started collaborating and working together. I mean, it became a very, very powerful collaboration.

I want to talk to you today about just the art of the possible Java and JavaFX. What have we done that I didn't even know was possible? We're looking at interactive data visualization where you really involve the data itself in the design process. Then I'm going to try to point out throughout that the power of collaboration between a developer and an expert user. I think something very unique about this project that we've done is that it was a partnership the whole way. He didn't know what problems needed to be solved, and I didn't know what was possible to solve them. So both with the ISS software development have done and with this project, these two successful software development projects have shared a common theme, which is effective collaboration between the developers and the users.

Trajectories

So what do we do with all this spaghetti, how do we pick the one out of that that'll work? I'm going to give you a crash course in astrodynamics. Are you all ready? So here we have an orbit around Jupiter's moon Europa. It's a periodic orbit that's repeating that we found with the software. But you can see how fast the spaghetti of trajectory becomes unmanageable. What we're going to only do is focus on the points of closest approach, so those green dots. It's called the periapsis, or I might also use the term para lune. We're going to get rid of the spaghetti of the trajectory and just keep the green points. You can see in this periodic trajectory, we've got patterns. So we can use the patterns and the periapsis points, the points of closest to approach, to learn something about these orbits.

Here we've got four trajectories, and all four of these, every time it makes a closest approach to Europa, we mark that point in white. So you can see this periodic orbit here has these distinct patterns that characterize this orbit, whereas these guys over here, it's filling in the space. So, these are all the same energy level. All these orbits have the same energy. They're the same body, but you can see they're significantly different. So we can get information about the trajectories, even if we're not looking at the trajectory itself, just out of the points.

Here we have 845 trajectories, and you can see what a mess that would be if they were all in screen at once. But there's 56,000 periapsis points that have been generated, and it's called a Poincaré map. This is a periapsis Poincaré map, and we're plotting only the periapsis over time, only the points of closest approach over time. You can see the islands within the maps or structures within the map that point out these interesting trajectories that might be relevant to our space requirements, so we can find our candidate trajectories within these structures. And so, in this way, we condense the date space for analysis. Even JavaFX can't manage 850 trajectories all on screen at once.

Deep Space Trajectory Explorer

So, we build a tool. And that's what we've done here. Let's see. What have we got? Let's take a look at this tool that I use. I'm doing something very dangerous. I can't minimize the tool on screen when this is a movie. So you just bear with me. Let's actually minimize the movie, and then start. This is the Deep Space Trajectory Explorer. This is the tool that Sean and I have built over the past five years or so, mostly in our spare time because it's fun. Up until recently, when you open up the tool, it was a blank black screen, and you'd have to drag in a text-based properties file in order to do anything, which is somewhat intimidating for a user. So we decided to make this a little bit user-friendly. And we needed a way to generate these Poincaré maps.

My thought was, "I have a properties file, but I need to turn that into GUI so people know how to do that. So let's just get a 2D form, and put it up on the screen, and we can fill in the data text file in and then [inaudible 00:08:50]. This is JavaFX. So let's not do that. Let's do this instead.” What we have here, you can see the Earth-Moon system here if we zoom out. Can everyone see that all right? It's a little bit dark. Every point in this cube is a starting point for trajectory. So you can see we've got this cube centered around the Moon, and you can imagine every point of those, once you say go, it's going to propagate forward in time, and they're all going to go somewhere else. We're going to propagate these forward using parallel streams. It's an embarrassingly parallel situation here because they're completely independent. And we'll propagate them forward to make our map.

What we have here is a scatter plot mesh that's free from fxyz.org, and it updates and redraws immediately as you change things. For example, I've got sliders over here in the X, Y, and Z position that you can make this borg bigger if you want to. It's like a psychedelic here. And if you're really feeling evil, you can go and attack the Earth. So it's always dangerous. But you can also see down here that we've got our 8,424 initial states. That's a really useful one because the data space gets big really fast. If you're doing a live demo at a conference, and you don't necessarily want to run 8,000 trajectories all at once, you might decrease your data space just a little bit so you have something more manageable.

Let's do this, and let's put it back close to the Moon. And let's maybe drop it. You can open this up a little bit. Let's drop it sort of in the center here, and let's see. We're down to 1,000. Let's say 100. Then what we do is, let's say these are the conditions we want. You can set the energy. Let's turn that up just a little bit, and how long you want to propagate everything for various settings. So then we just add just some standard controls here. Oh, come on. That'll work. I already had a map loaded in here. There it is.

What we've done then is generated a Poincaré map. These are all the periapsis of those initial points propagated forward. Then we can interact with this map. Let me go back and load back in the one that I wanted to look at. This is one of my favorites. So these represent only planar trajectories around the Moon at a particular energy level. So this is the kind of thing I've done in MATLAB. And you can imagine in MATLAB, if I wanted to see what's this point down here, where does it go? What trajectory does it belong to? I'd have to zoom it in the MATLAB and hover my cursor over and get the X and Y and Z positions and velocities and then go type them into MATLAB. That's not fun.

Instead, we have a point-clicky mode. We have this target. Can you see the targeting reticule there on the screen? It does a binary search to find the closest approach. It's going to jump from point to point. So then you can see this map, and you can see that there are structures inside of it. This is one of my favorites. I had no idea this guy existed, but you just click in the middle of this guy. You can see this quasi-periodic orbit around the Moon, which is pretty cool. You've also got guys that have no real structure, like this blue fellow up here. It's just kind of all over the place. This is all at the same energy level. They're just completely different orbits down here in these maps. You could also see, if I was trying to look at the trajectories themselves, it's just kind of a mess really, which is why we use the maps at all.

Every time I click on an orbit, a 2D thumbnail of it pops up over here on the right, so I can see what I'm working with. But we can do other things with this map too, which is pretty cool. One of the first things we actually built was this trajectory brushing mode where, let's say, I had this periapsis here, and I don't want to plot the whole orbits, but I want to select a region in here. Then it shows all the other points that are associated with that data set. So you can imagine if you had a data set that is not space related, but you wanted to understand how the point is related to each other, if some of the points belong to a certain set of data, what we've done is highlighted the data up here in this blue box, and the software is able to say, "These are all the other data points in those data sets that are associated with the same set of points." So you can come up here and just grab in this space. You can see how it fills in that whole area.

Now, hiding within these data sets, there are more islands that you can't really see here. So what we have is a set of range sliders. Hang on just a second. They're from ControlsFX. Some of the stuff I have to write down because I'm not a software developer. I'm just playing one in this movie. What we can do is go through this and filter the data. So it's redrawing it immediately. You can see these guys, these islands showing up as you filter through the data. I don't think you can read the guys on the right, but they're various values that I care about, like the angle, the eccentricity, the inclination, the various orbit parameters that we've built into this. So it's computing those. They're just equations from each data point. Then I can filter through them. Then I can click on these guys and say, "What is this guy in the middle of this?" You can see this is very high resonance periodic orbit that you just might not even know is there. They just keep going in this map. This blue guy is really fun, too.

We had this guy set up. I said, "But, Sean, there was this other view." This is only one possible view of the data, right? It's Y versus X. This is position space. You can see this right here, this circle. That's the Moon. So this is just a position space looking down on the top of the Moon, and this is where the closest approaches lie. But there's other ways you can visualize the data, and there was one in particular that I found really useful, which was to put each trajectory in a column. We're on the horizontal axis. This is a starting state, an initial condition, initial state. So you have like a histogram of all your trajectories. There's patterns you can find. Sean said, "But, Diane, this is JavaFX. We don't have to limit it to that."

Let me go in and load this map again. In this map we have 1,500 trajectories with 269,000 points that we're trying at once. So now we have our four views. This one on the upper right is the one I was looking for. But we don't have to limit it to that. And, in fact, we don't even have to tell the user to pre-decide which data parameters we want in the axis. Up here again we have position space. This is Y versus X position. This is like a polar plot of the radius and the angle. It's like spread out. You can see, as I move my ticker around one of the squares, you all see a little white dot moving around in the back? It's finding the corresponding data point in the other views. So this periodic guy over here corresponds to that one over there in the middle. But we don't have to limit ourselves to this.

What we have are slide outs here. So we can change just immediately the axes that are plotted. Maybe I want to plot semi-major axis versus eccentricity for some reason. Here we go. We get this sort of tornado looking thing going on. You can see how the same data looks completely different based on what parameters you plot. This is one that I want to pull out of this orbit mechanics tool because I think there's other applications, so really, any kind of scientific data that's coming in that's huge that you need to understand how one parameter relates to another, I think something like this could be very powerful to help sort through data, because I found it very powerful. So you can see once again, with the patterns and the various views, where your periodic orbits are. So I can click over here in one view, and it shows up in the other. And then once again, especially if my screen doesn't freeze, you can filter through the data, and it filters the entire data set. We're using range sliders here from ControlsFX.

Working with 3D Data

We've got these trajectories now. What we've got then are a bunch of trajectories. However, there's something funny about these trajectories that I want to show you because they're limiting. Let's let this guy back in. Let's click on a few. We've got this guy. We've got this guy over here in the middle. We can look at these in three dimensions. Here is our trajectory around the Moon, and there's the Earth. What do we notice? These are very flat. But space is not flat. The enemy's gate is down. We need to be able to work with three-dimensional data. So, let's do that. Let's come back here and let's load in a different map. This guy is, you can imagine, a cloud of periapsis points around the Moon. These are 3D orbits, and we've smashed the map down into two dimensions. And you can't see any structure in this map like we saw in the planar map, which is why I showed that one first. However, this is where the visual query comes in really handy.

I'm going to come down here, and I'm going to sort by inclination. As we sort through this data, let me pull this one up maybe. There we go. Hang on, I'll pull this one back up. There they are. You can see these six islands showing up. Come on. There we go. So this is an orbit. We're calling it a tulip orbit. It's in a six to one resonance with the Earth-Moon system. You'd never know that that was hiding in that map without the ability to filter through the data so quickly. This orbit, we believe, has never been found by anyone else before. So it required visual tools like this so that I can use my intuition as a trajectory designer to sort through that data and manage that data to find this orbit. If we go to our 3D view, you can see it here. Here is our 3D tulip shaped orbit. If we turn it upside down, it's kind of like a tulip flower. And it's in a six to one resonance with the Moon.

Let's go and reset our constraints. Let's set constraints. This is a flat map. It's all smooshed into a 2D screen, and you can't see much about. It doesn't give us information about where this periapsis lies around the Moon. And sometimes we're looking for a polar orbit. For example, this is a lunar orbit, but the same orbit exists around Enceladus. We're designing orbits that we could fly through the South Pole, really close to install this because they have plumes coming out. They've got geysers of water ice coming out of Enceladus. It would be great if we can get funding. But we want to send a spacecraft to fly through those plumes and sample that water to get information without having to actually land on Enceladus, which is very hard. What if we could get into orbit around Enceladus and fly through those plumes? So, we want to know which of these orbits might lie below the South Pole of Enceladus or the Moon or whatever it is we're looking for.

Of course, we're not limited to 2D maps because this is JavaFX. We're using now JavaFX 3D. It's the same canvas, and we have a 3D-Poincaré map. Now you can see the same data. We were looking at it like this before, but now we've got it in a 3D-view. Let's just run in. I turned that point size up before, so let's turn it back down just a bit so we can see that a little bit better. Can we see our points now? Let's get rid of a little bit of that data because they're just a bit much. I can pull a little bit of that down. I can see just a bit better. Here we go. Let's get rid of it a little bit more. We've got this 3D map. We can zoom in and out, but it still only gives us information about three dimensions. We don't work in a three-dimensional world. We work in a six-dimensional world.

We've got three position coordinates, but then we've got three velocity coordinates as well. We can be traveling in any direction, and so your data space gets big really fast. This is another situation where Sean didn't necessarily know that I needed six dimensions, and I didn't really know what was possible. But when we got together and we started talking, we said, "Well, why do we have to show these just as little points?" I'm still trying to get rid of some data. "Why do we have to view these simply as points? Why can't we put direction information in the map itself?" Hang on. Let me turn this down also. All my settings got changed when I restarted the tool. Let's scale this down or we're going to have just really enormous velocity coordinates so you have a little bit of suspense there. Let's turn these into arrows.

Now the arrow is pointed in the direction of velocity. You can see which in direction all these guys are traveling. You can see these ones at the bottom are pointed down. The ones in the middle are pretty much sideways, and there at the top, they're pointed up. We have this 3D map where we have now suddenly information on where all the points are in space and what direction each one is traveling in. But we don't have to stop there because, once again, we were inspired by the perspectives grid where we had the four data sets. We can change what's on each of the axes, and we end up with more information. So what we have here is we're able to change the direction of the arrow in the corner. I don't know if you can read this. Let's change this, for example. Instead of Z position on the Z axis, let's make it inclination.

And so now you have this odd like psychedelic mushroom thing going on. I'm not sure why this would be interesting to you as you're designing trajectories, but the point is is that you don't know. I don't know what I need to look at. At any point, I might be interested in any number of parameters, and this tool has the flexibility to let me change the view immediately. Again, it's an application that's not limited to obscure spacecraft orbit design. But for any data set you can give the user the flexibility to work within the data set and interact with the data as design. So many folks in my industry use numbers to compute the orbits and figure out what it is that they're looking for. At the end of the day, they might make a picture for their management. But there's power in using the visualization as part of the design process, which is what I like to do.

Then you might ask me, "What does all of this have to do with the Gateway because weren't we talking about the Gateway?" Let's go back to our movie, and we're going to give you some more crash courses on astrodynamics. Once again, we have the Gateway in this Near Rectilinear Halo Orbit. Things are going to be coming and going. We're going to be chucking objects off the spacecraft, like possibly CubeSats or spent logistics modules like shipping containers that have to leave. And we have to send things away from the Gateway. But did you see how that guy left and then came back real close? Let me play that again. We're departing right about here, and it looks like it's going away. But as you passed through para lune again, it nearly crashes into the Gateway. What we don't want to do is that movie "Gravity" again. We don't want to crash anything into the spacecraft with those people on board, and then there's Sandra Bullock, and it's just a mess. There's no Chinese space station out here you can dock with. I mean, they're pretty much stuck, so no crashing.

Applications

So we've got various applications. We've got CubeSats, we might want to send to the Moon or other places to do the science. We've got these spent logistics modules that the current plan for them is possibly to send them out into heliocentric space. That means away from the Earth-Moon system to go orbit the Sun where they're not going to bother anybody. Then we have to compute the risk of re-contact for anything departing. This is a really large data space, though, once again. We could depart anywhere along the orbit all the way around from apolune down here all the way up to paralune at the top. We can depart in any direction. We've got a sphere of directions, a whole orbit worth of space. And then we can depart with a larger small burn. So you can make a tiny little burn where it might stick around for a long time, or a really big burn where it might depart really fast. But how do you know where you can depart and in what direction so that it's safe?

For a given separation location and delta-v maneuver magnitude along the orbit, like this five meters per second burn here, we have a map of all the different directions. Right in the center of the map is, if I'm the Gateway orbit and I'm traveling this is direction, is the velocity direction. Then along the X-axis here, hang on just a second, is the VR. So we're going from minus 180 to 180 degrees in direction along the horizontal axis, and the vertical axis is the pitch of the direction from minus 90 to 90 degrees. This is a map of all the possible directions we can leave in, if we're leaving at that one spot in the orbit. Any point that is green is a maneuver direction that departs safely. So nothing happens. It leaves the NRHO. We're gone. We're safe. If it's red, it means we have come within 100 kilometers of the Gateway again, sometime later down the line, and that's too close for comfort. So we say there's a risk of re-contact, and we color those guys red. If they're yellow, it means that that object has impacted the Moon after it left the orbit. Now, that could be bad if you don't want to impact the Moon, but you might have an impactor, CubeSat, a small impactor there for science reasons, you want it to go and you want it to impact the Moon on purpose. So you might be looking for trajectories that impact the Moon.

I'm going to restart this guy once again just to clear it out. There's a lot of mount data I had loaded in because we're going to do something completely different now. Here we go. How do we make those halo orbits? Let's do that first. Once again, this is a GUI tool that we put together. We also have properties files you can drag in to make these families of orbits, but we also have a tool for the user. I'm zooming out here. Here's the Earth-Moon system. I'm using that one more. So, can you all see my mouse if I just point with the mouse? Here's the Earth, and here's the Moon. This is a rotating frame, which means the whole picture is moving around the Earth like this. In this frame, in this circular restricted model, there are five equilibrium points. There's no analytical solution to the equations of motion like I said. We've got the Earth here and the Moon here, and there are five equilibrium points. They're called libration points or Lagrange points. You may have heard of these. So we've got L1 and L2 here near the Moon. L3 is way out here beyond the Earth and L4 and L5. Actually, Trojan asteroids, Jupiter or at the Sun, L4 and L5 points. They're stable equilibrium points. The rest of them are unstable in the Earth-Moon system.

These guys are stable, but we're looking at these guys. These are interesting. They're near the Moon. So these are equilibrium points, but around those equilibrium points are families of periodic orbits. Some of these are called halo orbits. They're called halo orbits because if you're looking at them down the line, here, let's look at it like this, it forms a halo around the Moon. That's why they're called halo orbits. So we've got families of halo orbits around the libration points around L1 and L2. These flowers are really unstable. But this is just one member of the family. So what the tool is doing at this point is it’s taking initial state, just a guess of what a periodic orbit is, it’s propagating around, and it's using a differential corrector to solve for the periodic orbit. That's the first member of the family. And now when I hit go, it's found one member of the family. It's going to step out of plane in the Z direction and then solve for the next member of the family.

So let's generate this family of L2 halos now. Here it is. You can see the family growing. So this is the L2, a part of the L2 halo family here. You can see each one of these colored orbits is a different orbit. These are the unstable guys. Here's the L1 guys and then we'll put in the L2 South always also. So the L1 family is really interesting because it gets really big and really far away from the Moon at the end. You can see, as the L1 family approaches the Moon, these guys get really huge. That's part of the reason we're going to an L2 NRHO and not an L11, but anyway. These pink guys down here are the Near Rectilinear Halo Orbits. So they're defined by their stability. These orbits right here, the flatter ones are really unstable. You don't necessarily want to put several billion dollar spacecraft with people on board in a really unstable orbit where if you miss the maneuver, you'll leave within a couple weeks. These are nearly stable down here. So that's both good and bad, but it means it's easier to stay in them, which is nice when you've got people there.

My resolution is causing me troubles. Let's go grab some of these halo orbits. We got a screen resolution problem going on. No exceptions. That's good. There we go. Let's render that guy in 3D. So we're going to look at this unstable halo, and one of the things that we're able to do with this guy is, an unstable orbit has manifold trajectories. And so basically all that is, is a fancy orbit that asymptotically approaches or departs the trajectories. If you've heard of the interplanetary space highway, that's what they're talking about. You can jump from manifold to manifold for free. Once you get on it anywhere, it asymptotically approaches this orbit. So you can jump from side to side.

I'm going to plot a few of these to take a look because this is a kind of departing trajectory we might use to get into or out of one of these unstable halo orbits. The James Webb Space Telescope is going to one of these. The Genesis spacecraft went to these guys in the Sun-Earth system. The manifold trajectories look something like this as they generate. What we're doing is we're computing a matrix associated with this orbit that gives you information on the stability, and you find the unstable eigenvector direction, and you take your spacecraft off with a tiny little maneuver in that direction. So you get these interesting manifold trajectories that depart pretty quickly. Once you hop on to one of these peach colored ones, it asymptotically approaches the halo orbit. As you hop onto one of these red guys, it asymptotically departs.

Now, unfortunately, our Near Rectilinear Halo Orbit doesn't have these manifold trajectories. Let's clear this out, and I'll show you what I'm talking about. Let's head down here. I think the NRHO shows we're at the bottom. Yes. So here's an L2 NRHO, and this is an almost stable orbit. Let's do another. Once again, what did I do, 50 of them? And then I think I propagate it for 30 days. Is that right? I'll show you how fast they don't leave. So the trajectories are in there but look at that. With a tiny little maneuver like that, after 30 days, it hasn't gone anywhere. So, we don't have asymptotically departing trajectories that are useful for us. But what we can do is generate transfers with a delta-v magnitude that we pick. Let's say 15 meters per second because those guys tend to depart pretty fast. I'm going to type in the form.

Let's make this go for, let's say, 50 days. We'll go forward and backward integration in two directions. Then if we generate the transfer trajectories, we get something that makes more sense. So instead of an infinitesimal delta-v off that unstable halo orbit, we put in 15 meters per second. And by delta-v, I mean a maneuver. You can see these guys. Look how symmetric that is. It's just absolutely beautiful. There we go. Anyway, we have these departing manifold trajectories, but as I mentioned, this is how we would get off of or onto one of these halo orbits. What we've done is we've designed transfers from the NRHO back to Earth. We've designed transfers from the NRHO into other systems in orbits like retrograde orbits and other halo orbits. This is the kind of thing we've used to do this. And then what I've been looking at is, "Well, are we going to run into the Gateway again after we leave?"

The latest, the newest development we've done here is this transfer map generation tool. On the right, we see the Earth-Moon system. Let's go get our NRHO. Let me get the right one right here. There it is. So here's our halo orbit that the Gateway is going to be in. Then on the right, we're going to generate those maps I showed you. Let's set that up. We want the yaw to be from minus 180 to 180 degrees. The pitch is going from minus 90 to 90. We're going to do a five-meter per second delta-v on this guy because it makes an interesting map. What have we got? We can do a whole range of values, and I'll make a whole bunch of maps. And let's go from 0 to 8 to 28. All right, 20. I need to get those right. Let's generate these maps. And then while that is running, I'll load one in so we don't have to wait.

This is what I showed you before. If we remember, in the center was the velocity direction. This is for a certain point along the orbit. I think this one's like right about here. On the orbit, we probably should mark it. That would be a good idea. We'll put like a dot here. Any point that's colored green is a maneuver direction that departs from the Gateway without doing anything bad like running into the Moon or crashing into the Gateway, which we're avoiding. For example, you can see also up here is the flight time. So the fate is departed. This is the direction. This is the magnitude of the delta-v of the maneuver we've used. Here's our flight time. This guy departs where my mouse is falling down to, after 16.48 days. This is the state of that position, and it's departed. That's nice. Let's click on that guy and see what it looks like. There we go.

You can see that guy is departed after 16 days. Nothing bad happened. One other thing I want to say is, depending on which direction you go, it can depart really fast or really slowly. So this guy departed in the 16 days, but over here, it takes twice that long. So this is 32 days to depart. There it goes. These guys also left the building without crashing into anything. So that's nice. Let's clear those. However, the red guys are maneuver directions where you re-contact the Gateway. These two tadpole looking guys re-contact really fast if you depart. You can see it's leaving the Gateway right here, and then it's next parallel in passage just a few hours later. That probably takes about an hour and a half. It's getting back within 100 kilometers of the Gateway, and it risks re-contact. So that's not what we're looking for.

We also have this sine wave looking guy of departures that take longer to re-contact with the Gateway after separation. So, if I clicked here, it takes 19 days. That's three rounds around the NRHO because it takes a week to go around. You can see it hasn't departed very fast. It's still pretty much in the halo orbit itself, and we've had a risk of re-contact. So we wouldn't want to chuck up a spacecraft off of the Gateway at this position in that direction, because you would risk re-contacting and crushing into your Gateway. These yellow guys, like I said, are lunar impact trajectories. They're pretty interesting actually. So they hang out in that NRHO for a while. And then this one flips into the north, and you can see that it slams into the North Pole of the Moon there. So that will be interesting.

Compute

One thing I want to do is compute. These are going to be super fun. Compute the impact position on the Moon, and then map it on a map of the Moon on the right. I want to put the position of the impact in the velocity. We almost had that done before Christmas. I want to explore these guys. In fact, these are so interesting because look at this guy - the impact time was 47 days. Well, look at this guy in the middle; you would never have found this without some tool to do it for you. 101 days, but look at this guy. It hangs on in the NRHO. You think it's just behaving, no big deal. Then it flips the pin in the North. It is a whole bunch of rest there in this beautiful symmetric thing, and then it crashes into the main again.

But look at this thing. It's this perfectly symmetric dance around the Moon before it slams into - How do you even find this? I've got actually a graduate student at Purdue right now who is exploring these trajectories to say, "These are different of families of orbits." So what we're doing is we're flipping. From the NRHO, we're transferring accidentally to this family of periodic orbits in the South that flips to the family of periodic orbits to the North, and then it slams into the Moon.

While I've been yammering on about this thing, my software, which doesn't like the resolution of my 4K, monitor hooked up to this presenter, has been making maps. Well, what it's done is made a bunch of different maps. And if I could see them, what I would tell you is that they look really different based on where around the NRHO they're departing. Let's just see if I can just ask it to go to a different screen. It's all there. It's not wanting to. Let's flip away and let's flip back. It's not going to work for me. But basically, the character of this map changes a ton. And as you're about right here in the orbit, the entire map turns red. That's something I didn't expect. When I started, I was like, "We're not going to have problems with re-contact. It's just going to go away." But what this map told me is no. In fact, there are certain areas where you leave. You can leave down here and you got no problems. You're just leaving. But if you leave up here, almost the entire map is red. So you just have to be careful where you leave the Gateway so that you don't run it back into the spacecraft and cause trouble. So, it sounds like I'm running out of time. I will finish up.

Lessons Learned

What I have learned in my five years of working with Sean Phillips is that Java and JavaFX are extraordinarily powerful for desktop applications. What we've made is a tool that I find almost magical with interactive visualizations of large data sets that's enabling me to do the research that I need for the future of human space, the future of robotic space play, because more and more, we're going to these complicated trajectories, and it’s tools like these that are allowing the research to be done. Without the right tools, we just can't do it. We can't go to these new kinds of orbits and really take advantage of the fuel savings and the things that they can do if we don't have the tools that will let us do that.

Then the power of collaboration. Without the power of a Java developer who really knows what he's doing and knows what is possible, and then a subject matter expert who knows what's needed. When you combine those two just at the root of the software problem, we've made magic that's really beyond either one of our single contributions. I found this also too, and hang on. I'm going to divert for a second. I was working on building the ground system for the ISS. I led the team that built the collision avoidance subsystem, and you might wonder why astrodynamicist, and not a software developer is leading this. But anyway, the users loved it. So on that slide, I was actually on the developer side, not the user side. And I wrote a lot of the astrodynamics parts, and then I had software developers. We actually built that on a C#, building the C# user interface. But there were a lot of different subsystems being built, and ours ended up being very successful. We finished it early.

It was deployed six months ahead of schedule because the users, the topos, the guys who fly the ISS, loved it so much. They were flying the space station with Excel spreadsheets, guys. Anyway, we built them a pretty cool application that would assess the risk of collision with ISS. There's lots of space debris up there. We've got all sorts of satellites. There are dead satellites. There are fragments of satellites that folks have blown up and left there. The space station has to maneuver to get out of the way of data. The U.S. Air Force tracks all these objects. And if there's a potential collision coming up, they send a file to the guys that fly the ISS and say, "Hey, you all, there's a risk of collision. There's a conjunction coming up." So then they load this conjunction message into our software, and it computes the probability collision. If it's above a certain level, then they have to do a maneuver to get out of the way, and it computes the maneuver they need to do.

Anyway, the point is we worked so closely with the topos from day one. I actually one day locked them in the room with blank sheets of paper and said, "Draw what you want," but they didn't know. But we built it together. We designed it together. And because of that, it does exactly what they need. They loved it, and they deployed at six months early. They got special permission because we had that collaboration. We built what they wanted. We didn't just hand them something at the end, and it turns out we didn't understand the requirements, and it wasn't what they wanted. In the same way, and maybe more dramatically with his tool, Sean and I have taken this This tool made something amazing. So this is Sean. You can find him on Twitter. He's got quite a resume there, and he's currently principal software engineer at Johns Hopkins Applied Physics lab. So, with that, I will say thank you so much for coming to listen, and I'll open it up for any questions you all may have. Remember I'm not a software developer. So be kind.

Questions & Answers

Participant 1: So, there's [inaudible 00:46:16] around these like bodies might move. I was thinking about, not remembering obviously, the kind of Apollo-era when they're kind of doing all of this with slide rules and all that kind of stuff. Was it luck that they ended up in kind of what looks like stable orbits, or were they at risk of falling into these really complicated?

Craig Davis: That's a very good question. It was not luck. They were brilliant, and, in fact, I say that in a way, because of the software tools we have now, we've lost some of those skills that they had doing everything by hand. But they were not going into one of these orbits. Remember that orbit I showed at the very beginning? It was just 100-kilometer circle around the Moon. So, that one can be approximated by an analytical solution, a conic section. It's an ellipse. And so what they did is they designed the trajectories into that conic section. Back in the '60s, these weren't even known that they even existed. Well, mathematically Lagrangian had figured that out, I suppose. But really, they were not going into these complicated trajectories. They were going into something much simpler. However, they also did it with less power than, significantly less as an iPhone, so matters by train.

Participant 2: Fascinating. You mentioned that to a lot of your problems, there's no analytical solution, because you're computing some numerical solutions to figure out these trajectories. Are those numerical solutions being done in this tool using Java, having used MATLAB in past life, and how easy that is for calculating numerical solutions? Maybe you don't make sure in developing it, but how difficult was it to actually implement the numerical solutions in Java?

Craig David: That is a good question and some of each. Let me see if I have any of the math open here. I don't. You probably can't even see that though. What we're doing is we're using something called the Java Extra Dynamics Toolkit. It's open source. I think it's out of Goddard Space Flight Center. So we've used the Java Extra Dynamics Toolkit to do a lot of the basic functions, but it was very interesting. You can see actually up here is a mild MATLAB code. It's all in the comments, which is not necessarily pretty. Especially at the beginning, I didn't realize that. At this point, he essentially has a master's in astrodynamics. But at the time, he really didn't know much about it, and so he was trying to port my MATLAB code into Java without much help. But anyway, he did it. So, yes, he did have to jump through some hoops.

Like that recontact integrator was a very interesting one, because you can't just integrate one trajectory forward. You have to integrate simultaneously all of them forward because you're computing the range between them over time. And the Gateway's not holding still, and you're propagating this guy. You have to propagate them together. So he had to write a new integrator with equations of motion that would propagate everything forward. But no, all of the computations in this tool are pure Java. To make that map, the last one I showed in the movie was 2 million points, and it ran in 45 minutes to put those 2 million points. It's kind of accidental, but it was so pretty. So 45 minutes to run that. I couldn't even have done it in MATLAB. I would start one of these maps going, and it would take a week to run. I finally said, “This is stupid, and I've coded up the integration of Fortran. So we're just integrating in Fortran and then MATLAB.” It's not good. It doesn't see now, but now I've seen the lines. But no, all the computations are done in Java.

Participant 3: Perfect, where all the orbits you showed without management of correction or boosting of - I know things like the ISS have to regularly boost themselves up a bit again to maintain their orbit.

Craig Davis: That is an excellent question. The Deep Space Trajectory Explorer, the Java tool you see here uses simplified equations of motion. It's called the Circular Restricted Three-Body Problem. Basically, you pretend like the only two objects in the universe are the Earth and the Moon, and they are in perfect spheres, and they're in perfectly circular orbits, their common very center. So those simplifications allow the libration points, the equilibrium points to exist. But that's not the real world.

The movies that I showed at the beginning were done in a trajectory software called Free Flyer. It's a commercial off the shelf astrodynamics software, and in that software, you've got the full fidelity forced models. We consider solar radiation pressure. We consider perturbations on the spacecraft of all kinds. So we do the high fidelity analysis of how much does it cost to do station-keeping to stay in the NRHO long term? It's actually quite cheap. That's done in a high fidelity model where we can model the errors like navigation errors, maneuver execution errors. We do all of that in the High Fidelity software. But preliminary trajectory design is very hard to do in that High Fidelity software. You have to step back to a simplified model to understand the dynamical space, so a really good question.

In this tool no. The ISS has to do reboosts because of the atmosphere. The atmospheric drag, even, it pulls it down. We don't have atmospheric drag, but we do have that instability. We have other errors on the spacecraft. When it slews to do a maneuver, the slew parts a little bit of delta-v. When it has momentum wheels, big gyroscopes that keep the attitude pointed, they get spun up, and you have to desaturate them through maneuver. That puts errors on the trajectory. So we model all that in the Free Flyer software.

Participant 4: How much time, how much power do you guys spend for the whole work, for parting all the models to this JavaFX?

Craig Davis: How much time did we spend building the tool? We worked on it for about five years, and it was a labor of love. For the first probably two years, it was completely just a hobby on the side. We started getting some support from our company after that. But really, it's been a side project for us both. I work full-time at Johnson Space Center, and he was working full-time doing ground system development for the James Webb Space Telescope. So, at best, he was probably able to put in paid like half a day a week on this. We really built it at nights and weekends, but it was significant.

Participant 5: I wasn't going to ask until this you mentioned C# at the end. As someone who’s not a software developer, you seem to have experience in projects done in JavaFX and C#. Could you comment on which one you found is better advantageous or disadvantageous of developing graphic applications in Java or C#?

Craig Davis: I can't answer that question well. What I can say is that it depends on what you're doing. It was interesting. The ISS ground system was almost entirely built in Java, except our application for historical reasons that don't matter. But they were insistent on using Java Swing. But they weren't allowing them to use the GUI builder. So it all had to be coded by hand. You can imagine how it looked like and how pretty it was, whereas in C#, we didn't have those regulations, and so it looked much nicer. So one of the users is like, "Oh, man, I wish that we could have built the rest of it in C# because Java just can't do anything." And then I showed him this and said no. So, it depends really on how you're using the tools, I'm guessing. It looks like my time is up. Thank you very much.

See more presentations with transcripts