I am happy to say that I was wrong about NTRS. Plus, the EDL kernel has been released (at least is present on NAIF).
I know what we're doing tonight.
Showing posts with label MSL. Show all posts
Showing posts with label MSL. Show all posts
Monday, May 13, 2013
Sunday, August 5, 2012
I told you it would work!
And then there was this:
While recording the MSL entry data in canister mode, MRO also snapped this photo of MSL on its parachute. They said that this photo would be harder, because even though (or rather because) it's closer, the angular rates are higher. Well, this is a much better picture than that of Phoenix.
I gotta Feeling that Tonight's going to be a Good Night...
Some humor:
Thursday, August 2, 2012
Why do I do this?
I am throwing a zombified lobotomized Omoikane back into
the atomic banana peeler, just for its compute power. I have Unplugged
All the Things (drives) and am going to run it just off of a USB stick
with Ubuntu Precise on it.
I'm no Dan Maas. I don't have the time necessary to give this the attention it deserves. I don't have enough computer power to get a full model of both the lander and the terrain into view at once.
What I can do is easy. Spice kernels take all of the work out of predicting where things are. I don't need an aero model, I don't need a guidance program, I don't even need a numerical integrator.
So why do I bother? Especially in the face of this?
Because I like it. I love doing computer animations. I love collecting data and models. It's tradition started from Phoenix. If I had MER data I would probably do them too. And above all, Absurd Accuracy is Our Obsession. I have seen how SUFR works and how the balance masses deploy. They look weird, but a bit of though suggests its probably right. I have seen the lander scream into Gale Crater and descend against the backdrop of Mt Sharp. I have seen the parachute deploy and the backshell swing on it. I have seen the Skycrane Maneuver, and it doesn't look half as crazy as it once did. To be honest, its the part of powered descent before the skycrane that has me most worried.
Besides, it's not all bad. I finally found a nice map of Gale crater. So, my model of Mars lacks in detail, dozens or hundreds of meters resolution in topography, smaller but still large blocks in image map. Better is available, but not in color and difficult to mosaic. Besides, I don't have the memory for better. POV is particularly inefficient with meshes, and the maps I do have tax Aika's memory.
Anyway, with that map in place, with the backshell scorched, and so on, it looks good to me. Maybe I am comparable to Dan Maas. A little more time, a little more greeblies on the descent stage and rover (and perhaps Santa will bring me a copy of SolidWorks to do it with) and a little more patience and memory, and I might have a world-class animation. I at least hope to have a LASP-class animation to show on Sunday night.
What I can do is easy. Spice kernels take all of the work out of predicting where things are. I don't need an aero model, I don't need a guidance program, I don't even need a numerical integrator.
So why do I bother? Especially in the face of this?
Because I like it. I love doing computer animations. I love collecting data and models. It's tradition started from Phoenix. If I had MER data I would probably do them too. And above all, Absurd Accuracy is Our Obsession. I have seen how SUFR works and how the balance masses deploy. They look weird, but a bit of though suggests its probably right. I have seen the lander scream into Gale Crater and descend against the backdrop of Mt Sharp. I have seen the parachute deploy and the backshell swing on it. I have seen the Skycrane Maneuver, and it doesn't look half as crazy as it once did. To be honest, its the part of powered descent before the skycrane that has me most worried.
Besides, it's not all bad. I finally found a nice map of Gale crater. So, my model of Mars lacks in detail, dozens or hundreds of meters resolution in topography, smaller but still large blocks in image map. Better is available, but not in color and difficult to mosaic. Besides, I don't have the memory for better. POV is particularly inefficient with meshes, and the maps I do have tax Aika's memory.
Anyway, with that map in place, with the backshell scorched, and so on, it looks good to me. Maybe I am comparable to Dan Maas. A little more time, a little more greeblies on the descent stage and rover (and perhaps Santa will bring me a copy of SolidWorks to do it with) and a little more patience and memory, and I might have a world-class animation. I at least hope to have a LASP-class animation to show on Sunday night.
Sunday, July 29, 2012
There's always one more thing...
...This time it is deploying various jettisonable objects. I could just Do It, but there is always a philosophy problem.
Jettisoning things is easy. We know the exact time and place ahead of time where each object will be jettisoned. It's easy to get an exact analytical solution ahead of time so that all we need is the time an object is jettisoned, and its position, velocity, and orientation at that time. There is an analytical solution to its future trajectory, and just apply some random spin to its orientation.
Except, I don't know that there really is an analytical solution when drag is significant. We can fake it with the entry balance masses, since drag is not a big part of their lives. But what about the heat shield? What about the backshell and parachute? What about the descent stage in its flyaway phase? We'll save that for last.
Apparently there is such an analytical solution, but only for drag proportional to the velocity, not the square of the velocity, which is the regime in which conventional drag coefficients work. There is another solution, but the horizontal and vertical velocities are implicit functions of each other. So, it's on to everyone's favorite brute force application! No, not a hammer, a numerical integrator. Almost the same thing though, I can see why there would be confusion.
Now the problem with numerical integration is that it requires a state. It requires memory. And due to the nature of the animation loop (I haven't restored persistent variables to Megapov yet, and it wouldn't do well in the Atomic Banana Peeler anyway) there is no convenient way to maintain this state. So, on each frame, we get to integrate all the way from the time of jettison to now. We can stop when we know the object in question is off-screen, so it will be for a few seconds at most.
Here's the current version of the animation, with the art for the descent stage and rover in place. Almost all the art is done now. I need some decorations on the backshell, to match reality and to show the capsule rolling (or not). Then I still want to char the backshell, and perhaps the heatshield too, as a function of integrated heat.
Jettisoning things is easy. We know the exact time and place ahead of time where each object will be jettisoned. It's easy to get an exact analytical solution ahead of time so that all we need is the time an object is jettisoned, and its position, velocity, and orientation at that time. There is an analytical solution to its future trajectory, and just apply some random spin to its orientation.
Except, I don't know that there really is an analytical solution when drag is significant. We can fake it with the entry balance masses, since drag is not a big part of their lives. But what about the heat shield? What about the backshell and parachute? What about the descent stage in its flyaway phase? We'll save that for last.
Apparently there is such an analytical solution, but only for drag proportional to the velocity, not the square of the velocity, which is the regime in which conventional drag coefficients work. There is another solution, but the horizontal and vertical velocities are implicit functions of each other. So, it's on to everyone's favorite brute force application! No, not a hammer, a numerical integrator. Almost the same thing though, I can see why there would be confusion.
Now the problem with numerical integration is that it requires a state. It requires memory. And due to the nature of the animation loop (I haven't restored persistent variables to Megapov yet, and it wouldn't do well in the Atomic Banana Peeler anyway) there is no convenient way to maintain this state. So, on each frame, we get to integrate all the way from the time of jettison to now. We can stop when we know the object in question is off-screen, so it will be for a few seconds at most.
Here's the current version of the animation, with the art for the descent stage and rover in place. Almost all the art is done now. I need some decorations on the backshell, to match reality and to show the capsule rolling (or not). Then I still want to char the backshell, and perhaps the heatshield too, as a function of integrated heat.
Tuesday, July 24, 2012
Megapov+CSPICE documentation
I have added a feature to my version of Megapov which allows access to a limited subset of JPL Spice directly from the Povray scene description language. Here is the sad part: It was written for Project Blinn, but Project Blinn was (may have been) lost in the Great Hard Drive Crash of 2012. So, I am going to use it on the MSL movie I am (still) working on.
Friday, November 18, 2011
Mars Science Laboratory 2
The first thing to do of course is research. Maybe someone else, like the guys at JPL, have already published a trajectory. Poking through the files at JPL NAIF, I found a couple of kernels for MSL. One is labeled cruise, and one is labeled EDL. Now since there is no target set yet, these are obviously preliminary. I have read somewhere that this target is near the point that is easiest to retarget to any of the four candidate landing sites. These kernels are still interesting for just seeing what EDL is like. this is the comment section of the EDL kernel:
This particular kernel is just a list of positions and velocities at specific times, typically 0.1s apart. The attached CSV is a dump of the kernel at those times, plus some bonus stuff you can read about in the file.
And here it is:
A couple of comments:
12 earth g's on entry! Phoenix peaked at 8.
It flies for a long time, starting to gain altitude at about 110s and not opening the chute until 250s
However, closer examination of this kernel yielded only disappointment.
It doesn't look like this spice kernel can be used for the kind of aerodynamics model I am looking for. It just isn't of sufficient fidelity. For instance, the vehicle never has any significant side lift during the fight portion of the kernel, where we would expect the spacecraft to bank side-to-side. It just pitches further and further down, generating more and more lift, beyond any amount I have seen documented. Also, there is no orientation data associated with this kernel. I can fake it from the lift/drag ratio, but there is nothing authoritative.
However, there are several spacecraft events visible, including the jettison of the six entry balance masses, and I think the heat shield jettison. Data before about 40 seconds is unreliable because there is no significant air, and data after the parachute deploy at around ~250s is unreliable since my code doesn't take into account the new area of the parachute. The PDV separation at ~340s is visible, but the spice kernel ends at about 90m altitude above ground level and 2.5m/s verical speed.
So, what I am doing instead is using the Phoenix aerodynamic model. Apparently, entry capsule aerodynamics is so dominated by the heat shield that it hardly matters what the shape of the backshell is, and with proper scaling, the Phoenix coefficients can be applied to MSL directly. One of the interesting things is that the lift/drag ratio is an almost linear function of angle of attack and not a strong function of speed. So, by looking at the L/D from this plot, I can back out the angle of attack.
Further research reveals the no side-lift thing is intentional. See here .
Movie is in progress, but because of various glitches in the kernel, I'm not sure it will ever be worth publishing. What I would like to do is get the Orbiter model up and running, write a realistic entry guidance autopilot for it, and then collect data and make the movie with that.
MSL Sample EDL Trajectory SPK File (Central Landing Site (0.0 N, 45.0 E)
==========================================================================
Created by Fernando Abilleira, MSL MD/NAV. Comments added by
Boris Semenov, NAIF/JPL on Tue Feb 23 16:34:24 PST 2010.
Objects in the Ephemeris
--------------------------------------------------------
This file contains sample MSL (NAIF ID -76) EDL trajectory, from
atmospheric entry interface point to landing, for Type 1B, open of
launch period (11/25/2011), optimal launch time, central landing
site (0.0 N, 45.0 E), landing time 06-AUG-2012 11:35:46.7 UTC.
THIS FILE SHOULD BE USED FOR TESTING PURPOSES ONLY.
Approximate Time Coverage
--------------------------------------------------------
This file coverage is:
COVERAGE BEGIN TIME (TDB) COVERAGE END TIME (TDB)
------------------------- ------------------------
2012 AUG 06 11:30:58.537 2012 AUG 06 11:36:52.837
Pedigree
--------------------------------------------------------
This file was provided by Fernando Abilleira, MSL MD/NAV on
February 23, 2010. The original name of this file was
'day1_0.edlTraj.bsp'.
Contacts
--------------------------------------------------------
If you have any questions regarding this data contact
Boris V. Semenov, NAIF/JPL,
(818)-354-8136,
Boris.Semenov@jpl.nasa.gov
This particular kernel is just a list of positions and velocities at specific times, typically 0.1s apart. The attached CSV is a dump of the kernel at those times, plus some bonus stuff you can read about in the file.
And here it is:
A couple of comments:
12 earth g's on entry! Phoenix peaked at 8.
It flies for a long time, starting to gain altitude at about 110s and not opening the chute until 250s
However, closer examination of this kernel yielded only disappointment.
Excursion funnels are part of an investigation into how well test subjects can solve problems when traveling through a churning funnel of liquid asbestos. Results so far have been highly informative: They cannot.
It doesn't look like this spice kernel can be used for the kind of aerodynamics model I am looking for. It just isn't of sufficient fidelity. For instance, the vehicle never has any significant side lift during the fight portion of the kernel, where we would expect the spacecraft to bank side-to-side. It just pitches further and further down, generating more and more lift, beyond any amount I have seen documented. Also, there is no orientation data associated with this kernel. I can fake it from the lift/drag ratio, but there is nothing authoritative.
However, there are several spacecraft events visible, including the jettison of the six entry balance masses, and I think the heat shield jettison. Data before about 40 seconds is unreliable because there is no significant air, and data after the parachute deploy at around ~250s is unreliable since my code doesn't take into account the new area of the parachute. The PDV separation at ~340s is visible, but the spice kernel ends at about 90m altitude above ground level and 2.5m/s verical speed.
So, what I am doing instead is using the Phoenix aerodynamic model. Apparently, entry capsule aerodynamics is so dominated by the heat shield that it hardly matters what the shape of the backshell is, and with proper scaling, the Phoenix coefficients can be applied to MSL directly. One of the interesting things is that the lift/drag ratio is an almost linear function of angle of attack and not a strong function of speed. So, by looking at the L/D from this plot, I can back out the angle of attack.
Further research reveals the no side-lift thing is intentional. See here .
Movie is in progress, but because of various glitches in the kernel, I'm not sure it will ever be worth publishing. What I would like to do is get the Orbiter model up and running, write a realistic entry guidance autopilot for it, and then collect data and make the movie with that.
Mars Science Laboratory 1
Next friday, when all of us are relaxing after a fine day of turkey, the guys in Florida will be launching the Mars Science Laboratory.
Back when Phoenix was launched, the guys in Arizona put together a great video showing entry, descent, and landing with various events, all in real time. After the landing occured, the guys at JPL put together a reconstruction of the entry trajectory and orientation, and posted them as a pair of spice kernels. I was able to use this data and put together a cool video, showing the events in real time in proper scale. I had a model of the lander, its aeroshell and parachute, and the topography and map of the area around the landing site. The results came out pretty good:
So, of course I am going to do one for MSL. But, MSL hasn't flown yet and Absurd Accuracy is Our Obsession. So, I have to generate the trajectory and event data myself. I will document what I have done and what I am doing, building up hopefully to the release of this video on or beforelanding launch.
Back when Phoenix was launched, the guys in Arizona put together a great video showing entry, descent, and landing with various events, all in real time. After the landing occured, the guys at JPL put together a reconstruction of the entry trajectory and orientation, and posted them as a pair of spice kernels. I was able to use this data and put together a cool video, showing the events in real time in proper scale. I had a model of the lander, its aeroshell and parachute, and the topography and map of the area around the landing site. The results came out pretty good:
So, of course I am going to do one for MSL. But, MSL hasn't flown yet and Absurd Accuracy is Our Obsession. So, I have to generate the trajectory and event data myself. I will document what I have done and what I am doing, building up hopefully to the release of this video on or before
Subscribe to:
Posts (Atom)