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, but they 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:
Click to view attachment
Click to view attachment
(Why can't I upload a CSV? Rename this to msl_edl.csv when you get it)


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

Of course I'll make an animation at some point, but I am actually more interested in this for analysis and backing out the aerodynamics model, so I can put it as a flyable model for Orbiter.

I think this is part of the reason the landing is so precise -- this "flying" is part of its guided entry. It's sort of Shuttle-like -- it "falls with style." (That's a Toy Story reference, for those of you who have not memorized all of the Disney movies.)

OT, but, yeah, Emily, you really do need to get out more (but you're obviously a great Mom!)

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.

Click to view attachment

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.

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.

Something fun for those with Google Earth. Make sure you are on Mars and load this KMZ. It's my best current effort on an entry, descent, and landing dataset.

The entry state is the state at which Horizons says that the thing passes through 3522.2km distance from the center of Mars and 639.5km uprange of the target. I am landing about 12.2km downrange from the landing site, within the ellipse but only just barely. My code doesn't actually do any guidance, it just flies a reference trajectory I found described in one of the papers mentioned in the KMZ. A proper guidance system could surely land on the correct spot given this entry state.

My program does entry aerodynamics (with the heat shield) and descent aerodynamics (opening and riding the parachute) but does not yet separate and land. If you ride the tour, you will hit the ground at about 75m/s.

One of the fun things to do is to run a tour on the entry track. in Tools/Options/Touring, set the camera tilt to about 70deg, and the speed to 1.0. Then you can ride along with the vehicle.

I just noticed that entry tme is 5:11UTC, which will be 11:11pm MDT August 5 for me. It's a late night one, like the MER landers, not a mid-afternoon one like Phoenix.

Maybe not the right thread, but anyway ...
According to this article NASA obiters will attempt to take pictures of the MSL during EDL.
This means the time (and location) of athmosphere entry must be determined very precisely for orbiters to be there on time.
My question is: do we know entry (landing) time exactly on the second today, or will be available later on after further TCM's?
In the other words, is the Countdown to Landing running on MSL homepage accurate to the seconds?
Thanks

Well, given the fact that further TCMs are probably all but unavoidable for fine targeting I would say that no, the clocks are not accurate to the second at this time. I'm sure that they will be reset once all the maneuvers are completed.

Great to hear that they're gonna try to catch MSL's descent. The shot of Phoenix with chute open from HiRISE was both breathtaking and iconic!

They have to be on time anyway - they have to be there for EDL UHF relay duty.

Nice to know an orbiting interplanetary paparazzi will be clustered along the red carpet to get some glimpses of the arrival.

absolutely one of the top 10 space photos of all time (quickly becoming a crowded field!)

The amazing thing is that the Heimdall background was totally serendipitous... - They were aiming at where Phoenix was supposed to be and BAM!: got it just as it passed Heimdall. For me it is definitely one of the shots of the century in UMSF.

BTW, I made a poster back then which I think is not too shabby:

http://dalsgaard.eu/Pics/2008-06.Phoenix-o...n-Dalsgaard.jpg

Oerstad, Your poster is fabulous !

Thanks. I wanted to present the original shot without "debasing" it with inserts or zoom-ins, yet still (more or less..) subtly focus the attention on the impossibly small smudge that represents human exploration, passing in front of that huge crater...

I am not religious, yet that image always reminds me of the Breton Fisherman's Prayer: "Oh God thy sea is so great and my boat is so small..."
http://wiki.answers.com/Q/Who_said_'Oh..._so_small.'

The new and improved spice kernels at naif.jpl.nasa.gov CAN be used to get fun things like angle of attack, bank angle, etc. The kernels there are continuous from just after trans-mars ejection to landing. They don't include attitude information, but do include enough data that acceleration, alongtrack, crosstrack, and vertical can be found. Since crosstrack acceleration is in this one, you can use the aero model to get bank and pitch information. And come up with something like this:

Mars Science Lab Entry (version 2 revision D)

So far I only have up to about parachute deploy, because my 3D model doesn't have a parachute yet. The data itself is good to start of the skycrane maneuver, after that I can't tell if it is tracking the descent stage or the rover. I think it's neither, it just pretends the descent stage continues at a constant descent rate until the whole thing touches down.

Hey Kwan..
That animation was extremely sweet!
Watching the landing ellipse come into view with a good enough model of Gale was exciting.
I noticed that the the G forces topped out at 12.5+ during the burning reentry phase (lets hope MSL doesn't pass out!)
I'm looking forward to your refinements. (what is the primary tool (or toolset) you are using?)
Great job !

Primary tool is PovRAY ray tracer. It takes a text file which describes the scene, where the spacecraft, planet, topography, sun, etc is. The scene description language is basically turing complete so that the scenes (at least how I do it) are more programs than anything. This is a mostly open-source program which I have been able to modify to directly read SPICE files. It is extremely high quality, but also extremely slow. It takes about 1 mintue to render each frame, and 24 frames per second of video.

Thanks, Kwan, for that animation. Very cool to see how it will happen in "real time."