Printable Version of Topic

Posted by: Phil Stooke Aug 12 2016, 07:07 PM

Starting a new topic here - hopefully that's OK! Clearly there will be a lot of action around this in the next weeks and months with descent images and HiRISE views of the hardware.

I thought I had posted this map earlier but apparently not. This shows the various landing ellipses in this area. The original plan was for an ellipse oriented NW-SE, but it changed with the different launch date and is now nearly E-W. Note that the ellipse shown in the recent ESA release is the envelope of all ellipses over a given launch period, but the actual landing ellipse for the given launch date is smaller. Opportunity's final landing ellipse is shown for comparison.

http://exploration.esa.int/mars/57445-exomars-2016-landing-site/

http://exploration.esa.int/mars/57446-exomars-2016-landing-site/

Phil

Posted by: nogal Aug 19 2016, 06:23 PM

I had originally posted this information on http://www.unmannedspaceflight.com/index.php?showtopic=1313&view=findpost&p=232096, but then Phil started this topic and I think it fits better here.

ESA has relased information [http://www.esa.int/Our_Activities/Space_Science/Mars_Express/Spotlight_on_Schiaparelli_s_landing_site] on Schiaparelli's intended landing site on Meridiani Planum, including the landing elipse which, at its eastern edge, just grazes the Endeavour crater. Perhaps Opportunity could spot Schiaparelli descending under its parachute on October 19?

The landing ellipse's size is given on the above mentioned article as 100x15 km, but this could be a simplification for in order to match the ellipse on http://www.esa.int/spaceinimages/Images/2016/08/Meridiani_Planum_topography_with_Schiaparelli_landing_ellipse, I had to make it 115.4x23.9 km. The ellipse is centered at 2.048S, 6.114W.

This is how it looks on Google Earth (Mars):

And here is the KMZ file:  Schiaparelli.kmz ( 19.26K ) : 2313


Fernando

Posted by: sittingduck Aug 19 2016, 08:44 PM

Will Opportunity be able to image the Schiaparelli EDL? Maybe the re-entry plasma?

Posted by: James Sorenson Aug 19 2016, 09:27 PM

Opportunity is heading down deeper into Endeavour, so I'd say that is becoming less likely because of lack of visibility of the surrounding plains and the part of sky where it is expected to be. I guess the only chance will be if the lander overshoots to the far end of its ellipse where Oppy could possibly capture the desent.

Posted by: Explorer1 Aug 20 2016, 02:40 AM

Even capturing one pixel would be a fantastic success of planning; does the MRO team have any imaging planned like the previous landers? (I'd like to update my avatar)...

Posted by: Deimos Aug 24 2016, 03:24 PM

The nominal trajectory has the entry phase and parachute phase each potentially visible, but less than 15 deg above the level horizon. The crater will prove a challenge for even one pixel. It may be worth a bet on the EDM going well downrange--nothing ventured, nothing gained.

Posted by: Ron Hobbs Aug 26 2016, 04:17 AM

The ESA site is featuring images of the landing site. It looks to me that if Schiaparelli lands really long, Oppy might have a chance.

http://www.esa.int/spaceinimages/Images/2016/08/Perspective_view_in_Meridiani_Planum_with_Schiaparelli_landing_ellipse2

I've got my fingers crossed.

Here is the main website: http://www.esa.int/Our_Activities/Space_Science/Mars_Express/Spotlight_on_Schiaparelli_s_landing_site

Posted by: akuo Oct 13 2016, 05:16 PM

I tried to look for information about coverage of the Schiapparelli landing events and communications. Only thing mentioned seems to be that MEX will record the lander's signal for later transmission. Anyone know when that transmission would come? Any chance of following Schiapparelli live, even detection of the carrier signal with radio telescopes like was done with Huygens?

I guess I've gotten too used to Nasa lander style blow-by-blow earth receive time coverage with first pictures arriving minutes after the landing.

I assume at least the orbiter will stay in constant DSN contact during the insertion.

Posted by: Paolo Oct 13 2016, 06:00 PM

I think you can find answers to most of your questions here:
http://blogs.esa.int/rocketscience/2016/03/09/the-big-blog-post-how-exomarstgo-schiaparelli-get-to-where-theyre-going/

Posted by: Paolo Oct 13 2016, 06:05 PM

yesterday ESA published two short articles on Schiaparelli and the expected sequence of images

http://exploration.esa.int/mars/58425-preparing-to-land-on-mars/
http://exploration.esa.int/mars/58435-what-to-expect-from-schiaparelli-s-camera/

I am starting to see other forums getting inflamed by rants about the plans for imaging or lack of it. given the minimal exoected data output of the lander (150 Mbits, of which 100 Mbits will be engineering data) I am not surprised that no proper camera was carried.

Posted by: akuo Oct 13 2016, 07:04 PM

Thanks Paolo, that's the info I need.

To summarise:
An Indian radio telescope in Pune might detect if Schiapparelli is transmitting at all, live.
MEX and MRO will record a subset of telemetry, which could be received at 16:30 and 16:45 UTC on the landing day.
TGO will record full telemetry and it should be available 10h later, at 1:00 UTC.

Posted by: Phil Stooke Oct 13 2016, 07:29 PM

http://www.midnightplanets.com/web/MERB/image/04522/1P529631392EFFCTA4P2671L6M1.html

This is a test image taken by Opportunity and downlinked only about 20 minutes before this post. It's a test for the attempt to view Schiaparelli. Good luck - uh - break a wheel! (no, don't).

Phil

Posted by: Deimos Oct 13 2016, 07:43 PM

And context for that test image: http://www.leonarddavid.com/europe-readies-mars-lander-for-october-touchdown/

Posted by: akuo Oct 13 2016, 07:56 PM

With Oppy being so close, was there any consideration on having it listen to Schiapparelli on UHF during the EDL?

Posted by: climber Oct 14 2016, 07:03 AM

Can somebody point out Victoria crater?

Posted by: climber Oct 14 2016, 07:09 AM

Listening to Schiapparelli? On what Chanel ?

Posted by: centsworth_II Oct 14 2016, 07:19 AM

It's labeled in post 1 and is the most prominent crater south of the flag in post 2.

Posted by: climber Oct 14 2016, 07:35 AM

Oh yes, sorry about that.
If I remembrer correctely, so far, the landers have all overshot the center of the elipse? Is that correct? I guess we still have a chance to get pictures of Oppy's landing hardware...

Posted by: akuo Oct 14 2016, 09:13 AM

Yeah, that could be a problem. I'm pretty sure lander to lander communications were not on top of their minds when these things were designed. Also the radiation cone from the UHF antenna would be pointing in wrong direction, but proximity should definitely help with that.

Posted by: climber Oct 14 2016, 09:26 AM

This was just for Schiaparelli = Channels, oh well...

Posted by: katodomo Oct 14 2016, 07:01 PM

DECA should have a resolution of at best 4-5 m/pixel (at 1.5 km distance), hence not much chance of that.

Posted by: Explorer1 Oct 16 2016, 05:35 PM

Schiaparelli seperation confirmed!

Posted by: nogal Oct 16 2016, 07:50 PM

Here is a link to a page where live updates about ExoMars are being posted: http://m.esa.int/Our_Activities/Space_Science/ExoMars/Live_updates_ExoMars_arrival_and_landing
Excerpt from the page above:

Fernando

Posted by: Hungry4info Oct 16 2016, 09:08 PM

ESA's https://twitter.com/esaoperations?lang=en confirms TGO is now returning telemetry.

Posted by: nogal Oct 17 2016, 11:59 PM

A few ESA links about Schiaparelli's EDL:

https://www.youtube.com/watch?v=OnUfn7uyXJk

https://www.youtube.com/watch?v=C43KXGQuUuY (the whole 5m 52s of the descent)

https://www.youtube.com/watch?v=3j0Zfwdcfwo

Fernando

Posted by: nogal Oct 19 2016, 03:20 PM

ExoMars TGO burning proceding ok, "with slight overperformnace" (Flight Operations Director)

Schiaparelli: at 15:19 UTC it is known it was awake and executing the pre-programmed sequence. Furher information expected within the hour

Fernando

Posted by: xflare Oct 19 2016, 03:25 PM

Following Tweets from ESA, it seems they were able to follow much of the EDL up until the final moments, at which point did the signal disappear? - at the point of landing??

Posted by: akuo Oct 19 2016, 03:28 PM

No exact timing mentioned but the Puna radiotelescope seeing the UHF signal lost it at some point when Schiaparelli would have been in powered flight or at landing.

Posted by: xflare Oct 19 2016, 03:49 PM

Mars Express transmitting EDL data now.

Posted by: Art Martin Oct 19 2016, 04:06 PM

I have a question about this lander mission for the experts. I was surprised to hear the lander has no solar panels, will operate briefly until batteries run out, and has no surface cameras at all, that this mission was primarily just to practice landing techniques in preparation for a future rover mission. It sure seems that these techniques have been fully developed by the US and we are having stunning successes at landing in difficult conditions and I would assume that there would be no reservations at all about sharing the technology with ESA. While I understand that ESA wants to show they can do it on their own, the costs to send a lander are astronomical and not reinventing the wheel seems to be a very logical step. Why is ESA not piggybacking off our experience more? Was this simply a situation where they had such limited payload weights available and this was some last minute addition to the ExoMars mission or did they truly need this step? I just can't fathom going to all that trouble to set something down like this and not include solar panels and a camera.

Posted by: climber Oct 19 2016, 04:32 PM

Does somebody know when Oppy's images attempt will be on the ground?

Posted by: xflare Oct 19 2016, 04:44 PM

Looks like the Orbiter burn was successful - signal acquired right on time.

Posted by: nogal Oct 19 2016, 04:46 PM

ExoMars TGO is now confirmed to be in martian orbit.

Hello Art Martin. I think most of your questions are answered in these ESA pages: http://www.esa.int/Our_Activities/Space_Science/ExoMars/What_is_ExoMars
Fernando

Posted by: Explorer1 Oct 19 2016, 05:08 PM

Oppy's image attempt should come this afternoon, PST. Regarding the final fate of the lander, the Mars Express data is being analyzed now, and should shed light, on what occurred.

MRO imagery would of course, give the ultimate ground truth, but I don't known when that is planned for...

Posted by: PaulM Oct 19 2016, 05:35 PM

Entry descent and landing technology is classified because of its relationship with ICBM technology. This is why we were lucky to see oppy's microscopic images of her heat shield. However, you will notice that jpl have never described what the images revealed. I was surprised that communications protocols between opportunity's central computer and it's instruments were also classified. I have read that this is why opportunity's European made instruments have an analogue interface and not a digital interface to the main computer.

Posted by: mcaplinger Oct 19 2016, 05:49 PM

While there is some truth to this (for "classified" read "covered by ITAR"), there is plenty of open-literature information about US Mars EDL systems.

Posted by: xflare Oct 19 2016, 06:07 PM

According to BBCs Jonathon Amos Mars Express saw pretty much the same thing as the radio telescope.... which doesn't sound good. Perhaps something happened at backshell separation or engine ignition.

Posted by: B Bernatchez Oct 19 2016, 08:16 PM

When might we get HiRise coverage of the landing zone?

Posted by: Phil Stooke Oct 19 2016, 09:52 PM

Have to figure out where it is first. Tracking might help. A CTX image might be the first thing they would try, to find it for targeting HiRISE next time.

Phil

Posted by: James Sorenson Oct 19 2016, 10:03 PM

There are two candidates that I spot in the Oppy images that have come down. But these really do look like CR hits to me. I wouldn't rule out the lander though.
http://qt.exploratorium.edu/mars/opportunity/pancam/2016-10-19/1P530160694EFFCTARP2857L6M1.JPG

http://qt.exploratorium.edu/mars/opportunity/pancam/2016-10-19/1P530160918EFFCTARP2857L6M1.JPG

Posted by: Steve5304 Oct 19 2016, 10:36 PM

Those definately are not cosmic Ray hits...pictures were taken some time apart and the second picture hives with the trajectory of the first that's definately the lander.

Posted by: Explorer1 Oct 19 2016, 10:50 PM

Flipping between the two links James posted I see something around the 9 o'clock position in the 2nd image a lot fainter than the cosmic ray hits (near the black dust spec on the lens).
I know, I know, grasping at straws, but look at my avatar, I can't help myself!
Trouble is we can only guess what it would look like...

Posted by: tanjent Oct 19 2016, 11:23 PM

Based on the shape of the landing ellipse relative to the rover's position, I would have expected the lander to move from left to right across Opportunity's field of view. The phrase "landing long" has been used to express the prerequisite for Schiaparelli's getting near Opportunity's position at all. That said, there are many possible ways to become disoriented when viewing pictures like this for the first time.

Posted by: TheAnt Oct 20 2016, 12:29 AM

The second image, at top right, look a bit like a comet. Isn't that Schiaparelli?

http://qt.exploratorium.edu/mars/opportunity/pancam/2016-10-19/1P530160694EFFCTARP2857L6M1.JPG

Last news from BBC, the same, no signal so isn't it a risk the batteries run out even if the lander mission would turn out to be retrievable after all?
Regardless, this was a crucial step for the Exomars rover, so another delay seem likely.

Posted by: fredk Oct 20 2016, 12:32 AM

As I mentioned in the MER thread, this is daytime at Meridiani, so the exposures are very short. I wouldn't expect the lander to be streaked, especially since if anything we'd be seeing the slow end of the descent trajectory. So I think everything we see is consistent with CR's and noise.

The real clincher would be a feature appearing in simultaneous L6/R2 frames, but I don't see anything matching.

Posted by: nprev Oct 20 2016, 01:48 AM

Had to work all day so just catching up.

Let's please remember that members of the Schiaparelli team may well be reading our posts, if they have the time to do so given the enormous amount of frantic work that must be underway trying to understand--and hopefully recover from--this anomaly.

Mars is hard. There's no denying that. There's no such thing as a 'routine' landing there, not for anyone. But the only way to truly fail is to never have tried at all.

Best wishes to them, and best of luck.

Posted by: JRehling Oct 20 2016, 02:27 AM

I've seen a spacecraft re-enter (Stardust) from downrange, albeit at night. I'm not sure what the martian daytime version would look like, but the terrestrial nighttime version was pretty cool.

Posted by: mcaplinger Oct 20 2016, 03:13 AM

This is not only OT but pretty nonsensical. As an example, the foreign instruments on MSL (RAD, part of Chemcam, and REMS) are not analog interfaces. The digital interfaces may not be publicly documented, and ITAR is often invoked, but they are certainly not secrets within the project.

IMHO the ESA EDL demonstrator is as much about politics and nationalism/regionalism as it is about technical issues, and I have been working on space missions with international participation since the mid 80's.

Posted by: JRehling Oct 20 2016, 03:24 AM

This is nothing we don't already know, but Mars is almost the worst-case scenario for landing. The atmosphere is thick enough to burn a craft up, but not thick enough for a parachute to finish off a soft landing. The Moon, Earth, Venus, Titan, asteroids, comets – all are easier to make a soft landing on than Mars. Mercury might be harder, but at least there, the entire braking would have to be via thrust with no need for a heat shield. Mars requires Rube Goldberg entry schemes, and many attempts at landing there have paid the price.

Posted by: xflare Oct 20 2016, 06:44 AM

I followed the edl on twitter, they got so close I really thought it was going to make it, then the tweets just stopped... The sad thing also is that the successful arrival of the ExoMars Orbiter is going to be completely overshadowed like Mars Express.

Posted by: Explorer1 Oct 20 2016, 08:25 AM

Staying up late for the conference; looks like all the data from the descent was collected and is being processed (which will take a few days) and confirmation that ground radar was activated and that the rockets fired for at least a few seconds. So all key pieces of hardware did fire and they have telemetry (600 megs!). There will be attempts in the coming days to takes MRO images, but it may be a while to find something that small in the images.

Signal was lost about 50 seconds before planned touchdown. When parachute/backshell should have detached from the lander received telemetry started to deviated from expected. Multiple possibilities on what happened after, and they won't speculate yet. May try to send reset commands in a few days.
AMELIA instrument got science data though, so good news for them!

Hopefully the media will chalk this up as at least a partial success.

Posted by: xflare Oct 20 2016, 08:47 AM

Arggh stream kept buffering so missed quite a bit, So the data from the AMELIA investigation was transmitted in real time and recorded on TGO??

hmm lots of interesteing info from Jonathon Amos , quote: Signal received for 19 secs after engines shut off...maybe in free fall.

Posted by: abalone Oct 20 2016, 09:44 AM

"Schiaparelli Mars probe's parachute 'jettisoned too early'"

http://www.bbc.com/news/science-environment-37715202

Posted by: climber Oct 20 2016, 09:57 AM

To me this si more than a partial succes since all EDL instruments get activated.This means they've got it mostly right and they Will learn where they'll have to put more margins. They also said they don't rule out Schiaparelli was too low when engines fired. I understood that data started to deviate from previsions at the end of parachute work. Nevertheless they've got radar' and engines fired!
Experience tells that parachute and heat shield lands prety close to the landers. This will help finding the module...and we know where it is NOT sincy Oppy didn't catch it.
Go ESA, you're pretty close.

Posted by: climber Oct 20 2016, 10:01 AM

Sorry to tell that I never heard such assesments during the conference.

Posted by: alphasam Oct 20 2016, 11:19 AM

Not quite in so many words, however that is what they were indicating.

https://twitter.com/BBCAmos/status/789025342283456513

https://twitter.com/BBCAmos/status/789025867712307200

https://twitter.com/BBCAmos/status/789025046727684100


In the timeline parachute jettison/thruster firing should have occured just 30s before landing.

http://exploration.esa.int/mars/57464-exomars-2016-schiaparelli-descent-sequence/

Posted by: tolis Oct 20 2016, 11:54 AM

I think that it is a mistake that they tried to avoid giving any details on EDM altogether. All the questions they received afterwards
were about EDM. No-one doubts that the lion's share of the science will come from TGO and the EDM was a technology test.
However, one should also be mindful of the fact that the public, who is always footing the bill on these missions, need to be kept informed
(think of passengers in an airplane during an emergency). Coming across as evasive, which in my opinion is what happened here,
puts bees on the bonnet of public opinion, which then propagates to the elected representatives.

Posted by: PaulM Oct 20 2016, 12:24 PM

I did not like the idea of analogue interfaces when I read it 10 years ago from someone on this site so I am pleased that it is not true. The one thing that I would like to find out is how much of the ablative material was still present on opportunity's heat shield. There was speculation 10 years ago that heat shields could be made lighter in future if this information was known

Posted by: craigmcg Oct 20 2016, 02:43 PM

Its always good to be patient in these situations, as hard as it may be. It is fun for us armchair engineers to try and piece together the clues and come up with our own guesses.

I watched the conference just now on livestream and was left wondering what the next step would be in disclosure of the analysis of the EDL. Looking forward to understanding more.

Posted by: Gerald Oct 20 2016, 03:27 PM

Either the shock wave or the thrusters should have created a darkish and less saturated patch of less surface dust on the ground, which should simplify the search in HiRISE images, if taken within the next days/sols.

Posted by: xflare Oct 20 2016, 03:41 PM

Here is Mars Global Surveyor's first images of the Opportunity landing site in 2004 http://www.msss.com/mars_images/moc/2004/02/09/ Merdiani is very flat and has few features, I think it might be easier to find than other missing landers with MRO.

Also , here are the impact sites of the 75kg tungsten balance weights from Curiosity, which were very clearly seen in the MRO context camera images. https://www.nasa.gov/mission_pages/MRO/multimedia/pia16456.html Schiaparelli weighs about 500kg.

Posted by: climber Oct 20 2016, 07:37 PM

Let see if it enters the category of multiple landings as Phylae. It's possible that it had still some horizontal velocity when hiting the ground. MRO will tell

Posted by: katodomo Oct 20 2016, 07:38 PM

Question: Schiaparelli carried INRRI, a laser retroreflector. Would any current or planned near-future orbiter actually have come with a laser that could have used this within the next decade or so?

(i assume that dust storms would have made INRRI unusable relatively fast in comparison to units placed on the moon almost five decades ago)

Posted by: Phil Stooke Oct 20 2016, 07:44 PM

Not sure, but they would take that into account in the design. And there is talk of one being added to Insight as well. Something must be intended but I'm not sure of all the details. I have seen talk of laser reflectors before, and it's possible that a network of them would be built up over time, perhaps allowing very accurate rotation data to be collected to monitor precession (for instance).

Posted by: nprev Oct 21 2016, 12:03 AM

MOD NOTE: Two posts set invisible for inciting (and responding to) a debate re the 'success' of this mission-- see rule 2.6.

We're not doing that.

Posted by: alan Oct 21 2016, 03:20 PM

http://russianspaceweb.com/exomars2016-edm-landing.html#mro

Found this via https://twitter.com/cosmos4u/status/789484298143408128

Posted by: tedstryk Oct 21 2016, 03:30 PM

It appears that they may recover the data from AMELIA (the descent instruments). So they might learn something about the atmosphere, and they will certainly have some info about the technology. Not a success, but not a total failure either. Seems Mars-6 (sent back atmospheric data during descent, then crashed) would be a better comparison than Mars 3 (20 seconds of useless signal).

Posted by: xflare Oct 21 2016, 03:51 PM

Im guessing this would be in a COntext Camera Image.... all the Curiosity EDL hardware is visible in it too.

Posted by: Explorer1 Oct 21 2016, 05:15 PM

Yes, its a CTX image; low res, but that settles it... http://www.esa.int/Our_Activities/Space_Science/ExoMars/Mars_Reconnaissance_Orbiter_views_Schiaparelli_landing_site

HiRISE images next week.

Posted by: JRehling Oct 21 2016, 05:45 PM

This is an extreme "cup half full" interpretation, but the chance to observe impacts of known mass and velocity helps very much to interpret the natural impacts which are regularly observed on Mars, the mass and velocity of which are unknown. So, while this outcome was not desired, there is a benefit. The operational failure is a disappointment, but scientifically, the observation of this impact partially offsets the few days' of surface operations that were lost.

Posted by: nogal Oct 21 2016, 05:53 PM

There were repeated remarks that the landing would be attempted during the dust season, a first. So how much dusty was the atmosphere at the landing area? Is there any data from Opportunity? And how could it have influenced the EDL?
Fernando

Posted by: Explorer1 Oct 21 2016, 05:57 PM

Yes, that's a good point JHReling. I seem to recall the HiRISE images of Curiosity's tungsten counterweights and interplanetary cruise stage impacts were useful in that regard. Saving the AMELIA data is also another bit of silver lining to this cloud.

Small consolation to the rest of the team though; they must be going through something none of us laypersons can imagine. Even I'm having mixed feelings about seeing the high res images next week...

Posted by: Habukaz Oct 21 2016, 06:28 PM

There is currently https://twitter.com/tanyaofmars/status/789516165848543232 of dust in the Martian atmosphere, at least. Apparently, weather radars are capable of picking up https://webcache.googleusercontent.com/search?q=cache:wg4Uxk3MIwoJ:https://ams.confex.com/ams/pdfpapers/64783.pdf+&cd=5&hl=nn&ct=clnk&gl=no&client=opera, and http://www.sciencedirect.com/science/article/pii/S0273117799000721 of radar altimeters. Whether a radar altimeter with poor software or performance could get thrown off by the current amount of dust in the Martian atmosphere is to me an interesting question (and whether Mars' dryness would be relevant here).

EDIT: https://twitter.com/AuerSusan/status/789508288035561472

Posted by: alan Oct 21 2016, 06:29 PM

53 km's from Oppy, I bet she could reach it.

Posted by: fredk Oct 21 2016, 06:52 PM

Lemmon posts very regular tau measurements http://www.lpl.arizona.edu/~lemmon/mars-tau-b.html Tau has climbed from its winter low, but at ~0.9 is on the low side compared with previous years.

Posted by: neo56 Oct 21 2016, 07:25 PM

I looked at Oppy's new images on Midnight Planets and spotted this pic I've not seen yesterday: http://www.midnightplanets.com/web/MERB/image/04528/1P530160317EFFCTARP2857L6M1.html

Do you think the two bright spots above the horizon could be Schiaparelli and its parachute? I circled them:

Time of acquisition seems too early (2:44:13 PM UTC) but Mike specifies that acquisition times are approximate.

Posted by: Explorer1 Oct 21 2016, 07:30 PM

We know from the CTX images that it landed near the middle of the landing ellipses, way below the local horizon, so it can't be. I also withdraw my own speculation from earlier in the thread, given the ground truth.

Posted by: fredk Oct 21 2016, 07:43 PM

On top of that, with the landing site over 50 km from Oppy, the pancam pixel scale would mean that those two specks were about 2.4 km apart! (So I guess theoretically possible if taken just after the parachute/backshell separated.)

Posted by: fredk Oct 21 2016, 08:39 PM

I see a couple of possibly interesting features on the after CTX image. Marked with the black ellipse is some faint dark streaking that roughly aligns with the main lander splat. And circled is a small dark spot. Both weren't in the before image:

It's easiest to see them by flipping between the before and after images. Even though the image is very noisy, both features appear to rise above the noise fluctuations but still could be extreme fluctuations or other artifacts.

Perhaps the streaks, being dark and so perhaps due to removed dust, are associated with the engine firing, and the dark spot the heat shield?

Posted by: tolis Oct 21 2016, 09:49 PM

Indeed, I pointed those two out http://forum.nasaspaceflight.com/index.php?topic=31368.msg1602095#msg1602095

They appear to be downrange of the crash site. That's what you would expect for something that continues on ahead of the decelerating EDM.

Posted by: marsophile Oct 23 2016, 05:49 AM

If the retro-rockets were firing, wouldn't they show up as a streak even in a short exposure?

Posted by: James Sorenson Oct 23 2016, 06:35 PM

When pancam auto-exposes images through each filter, it does so until it reaches a specified DN value. If I recall, that is about a DN of 3000. So Images taken with L2 or R2 would have a lower exposure time then say images taken with L6, L7 or R1. You can even see this in the raws as you approach the blue and UV end, the images start to get more noiser from CR hits and hot pixels since it takes more time to reach the specified DN. So I'd expect L6 images would be in the few second range and If schiaparelli went through the FOV (which is now extremely unlikely if not ruled out since we know where it landed), I would think it would leave a small streak. Images taken with R2 would be a fast exposure and would likely not show a streak at all.

Posted by: mcaplinger Oct 23 2016, 08:23 PM

These images were likely not autoexposed, but you're ignoring the fact that these are frame transfer cameras and would show artifacts with anything moving in the scene, which would probably lead to some kind of streaking for fast-moving objects regardless of exposure time. That said, the team looked at these images and said they saw nothing but cosmic-ray hits, so I'd say leave it at that.

Posted by: nogal Oct 23 2016, 08:26 PM

A minuscule tribute to the ExoMars team. I have updated the kml file with the latest CTX images and also reviewed and extended the text of the several item's descriptions. Zoom in to see the "after" image. Enable (check) the "Hardware" to get small icons of Schiaparelli and its parachute.
Fernando
 Schiaparelli.kmz ( 408.86K ) : 377

Posted by: marsophile Oct 24 2016, 01:20 AM

One way to rule out the streak in

http://qt.exploratorium.edu/mars/opportunity/pancam/2016-10-19/1P530160694EFFCTARP2857L6M1.JPG

as being from Schiaparelli is to examine the times involved. From the filename, the above image was taken at 530160694 seconds in the epoch beginning on January 1, 2000 at 11:58:55.816 UTC. Using a J2000 calculator and subtracting the 64.2 seconds until 12:00:00 would put the image acquisition at 2016-10-19 14:50:29.799 UTC. However, the loss of signal from the Schiaparelli lander reportedly occurred about a minute before the scheduled landing time of 14:48 GMT (= UTC). Thus, the lander would have already crashed before the image was taken, unless I have made some error in my calculation.

Posted by: mcaplinger Oct 24 2016, 03:32 AM

The time in the file name is an SCLK value and drifts around in a way tabulated by the NAIF group http://naif.jpl.nasa.gov/pub/naif/MER/kernels/sclk/mer1.tsc . According to the quick Python program I just wrote (below) this time corresponds to 2016 OCT 19 14:51:27. But your conclusion is right. I'm not sure how the imaging times for the MER imaging were commanded but this seems late.

Posted by: Deimos Oct 24 2016, 05:19 PM

The images were taken with fixed exposure times to minimize a streak. The contrast was expected to be low, even in the unlikely event the lander came to a part of the sky where Opportunity had a line of sight. So, spreading the sub-pixel feature over lots of pixels would just further reduce it.

The few red images were to mitigate against model error or tau change--the contrast was predicted to go through 0 within the Pancam bandpass. But they were few due to bits and to image timing. Pancam is slow; slower still in the rover's current operational mode. Tests ahead of time struggled to demonstrate a way to go fast--generally, when the images have gone fast, subframes were used. So, after the first 5 images (4 L, 1 R), there was no chance. I was expecting ~6 L images, and was betting the descent would be a little later and farther downrange (not having a better option--imaging from inside the crater was like looking for your keys under the streetlight, even if you thought you might have dropped them off in the dark spot off to the left).

Posted by: tolis Oct 25 2016, 06:51 AM

Reported in http://www.russianspaceweb.com/exomars2016-edm-landing.html#1024:

"By October 24, engineers narrowed down a possible culprit to an error in the software of the Schiaparelli's Doppler radar altimeter, which misled the main computer into thinking that the spacecraft had already reached the landing altitude."

That sounds like something you should catch during testing on the ground (Earth ground, that is)

Posted by: Decepticon Oct 25 2016, 08:40 AM

Posted by: vikingmars Oct 25 2016, 09:57 AM

Maybe the radar caught the heatshield flying down in its line of sight...

Posted by: tolis Oct 25 2016, 10:52 AM

It might be, but the way the sentence is phrased points to a coding issue instead.
A simple unit conversion problem, for instance: alt=4km -> alt=4m.
Not to suggest that this is actually the culprit, just an example.

Posted by: Art Martin Oct 25 2016, 01:53 PM

That would be mind blowing if the sequences of landing were placed entirely within the control of the just switched on radar without some background logic going on dealing with the timing of the descent. I would think that even if the craft overshot or undershot its target a bit, the overall timing of events would still end up within a few seconds of the expected and any results coming back from the radar which were way out of those parameters should be considered suspect. I'm a computer programmer but have never been involved in code for spacecraft so I'm talking only from the standpoint of someone that has written code where mistakes could cost a lot of money. You put in what ifs and alternate paths for the logic in those critical events. Of course I have the luxury of not having the decisions come at me over a very short span of time. I'm curious how NASA would handle this in code. Radar would seem to be a critical component but what would software do if the results from it made no sense?

Posted by: nogal Oct 25 2016, 02:00 PM

I've been writing code since 1970 (when the world was "young and uncomplicated" ), but I never dealt with real-time, or near-real-time handling code which, I suspect, Schiparelli must use, and imposes a lot of constraints on code, including path-length (the time available for a given algorithm to execute).

I red somewhere that it has been mathematically proved that, except for simple cases, it cannot be demonstrated that a program is 100% correct. So, given one has to live with errors, what can be done to minimize them? Software building, coding methodologies can be used. "Proven" code can be reused - as long as the context of the proof remains valid for the case at hand and people are aware of it. And, of course, testing. A lot of testing. Automated testing can catch some errors, and test cases are specifically created. Can one foresee everything? Every possible combination of inputs? Some errors are caught by sheer luck, others may remain hidden for a long time, until a rare set of conditions manifests itself. Every time an error is caught its correction is included in the next release of the software. It works for the relatively forgiving environments of every day life. Space is much, much more harsh.

I'm just offering my own experience, not excusing anyone or anything. Sometimes, getting the kinks out of a program, feels harder than landing on Mars [pun intended].
Fernando

Posted by: Habukaz Oct 25 2016, 03:04 PM

According to http://ondemand-mp3.dradio.de/file/dradio/2016/10/24/exomars_was_wurde_aus_der_sonde_schiaparelli_interview_dlf_20161024_1641_b947cedc.mp3 (https://skyweek.wordpress.com/2016/10/20/live-blog-zu-exomars-dps-und-mehr-kosmischem/#Okt24) from Deutschlandradio, there was a timeout in the radar altimeter that ultimately made the onboard computer think it was on the ground far too early.

Posted by: katodomo Oct 25 2016, 03:37 PM

The transcript link above also links:

http://solarsystem.nasa.gov/docs/Bayle_ExoMars_EDM_Overview-Paper.pdf
http://www.corista.eu/Docs/Echo%20Simulator%20Systems%20For%20Exomars%202016%20Radar%20Doppler%20Altimeters%20Tests%20(Full%20Paper)%20-%20PID3710685.pdf
(both in English)

Posted by: JRehling Oct 25 2016, 04:58 PM

As a career software engineer, I doubt very much if either logical correctness or speed of execution are much of an issue here. The logic of the program is almost certainly a small matter compared to the complexity of the dynamic situation with multiple hardware systems operating in a complex and partly uncertain physical world. Even if a program were proven "correct," if that meant correct given that your radar behaved normally and during the actual landing, the radar experienced a glitch, then the correctness of the program could prove irrelevant.

The speed of modern microprocessors probably exceeds the requirements by more than one order of magnitude.

My take, from the outside looking in, is how to make a system that can save the spacecraft if physical events and the performance of sensor hardware go a bit beyond expected limits. If they go radically outside of expected limits, then the software might not be the problem anyway. But if they go moderately beyond normal expectations, then an ideal system might save the spacecraft whereas a good one might not.

I don't know which, if any, of those possibilities apply here. It seems, though, that telemetry took place past the point when things went wrong, so there's a good chance that we'll eventually know the root cause.

Posted by: PDP8E Oct 25 2016, 05:08 PM

I would like to know if ESA released a test article out of an airplane at 20K feet to test the system in real-time/real-world....
I would love to see that film...

Posted by: mcaplinger Oct 25 2016, 06:49 PM

Logical correctness is always an issue. As an unrelated example, MPL failed because of a lack of proper software debounce in the contact sensor that detected landing. I guess you can call that dynamics, but I'd call it a logical failure. At any rate, however you characterize them, software errors can be stupid and simple or extremely subtle or anywhere in between. If I had to make mistakes, I'd prefer to make subtle ones, but failure is failure and nothing much would surprise me in this case.

Posted by: Explorer1 Oct 25 2016, 08:12 PM

English language article saying main hunch is a computer glitch; it may have thought it was on the ground already, and the scientific instruments even turned on!

http://www.nature.com/news/computing-glitch-may-have-doomed-mars-lander-1.20861

At least it should be easier to fix than a hardware problem (all of which seemed to perform flawlessly).

Posted by: siravan Oct 25 2016, 08:12 PM

One of the difficulties of landing on Mars (among others) is the inability to do a full EDL rehearsal on Earth. Software verification and validation is all well and good, but if you cannot test your system in its entirety, all bets are off. We just don't know what happened (yet), it could be a subtle logical error only apparent in Mars environment or a simple error like the big-endian/little-endian mix up that doomed MGS. However, the whole point of Schiaparelli EDM lander was an end-to-end testing of the EDL system, and as such, it was a very successful test.

Posted by: tolis Oct 25 2016, 08:57 PM

Whatever the cause of the mishap, I doubt that Exomars will come out of December's ministerial meeting unscathed.
Ministers are politicians; if they simply allocate 300-odd million Euros for something that then
ends up a smoking heap of ruins on Mars, there will be questions asked.
At the very least, some additional oversight will be imposed - perhaps in the form of an external review panel -
to ensure that the EDL system that is to deliver Exomars 2020 will work end-to-end. In the worst-case scenario,
there may be an increase in cost for additional testing and a delay to 2022 or later.

Posted by: Art Martin Oct 25 2016, 10:10 PM

Reading that paper about the radar testing is a bit disturbing. From what I read the unit was not tested in actual flight conditions but instead simply by sending it simulated echoes. I understand we cannot recreate Mars in drop tests but we can certainly put a unit in some sort of bouncing vibrating box hanging from a parachute under as tough conditions as we can manage and force it to report back its findings over very varied terrain. Anyone have any idea why that wasn't done if I'm reading things right?

Posted by: Explorer1 Oct 26 2016, 03:46 AM

$$$, (or in Schiaparelli's case €€€)
Galileo's jammed HGA comes to mind for me, with insufficient testing after the long period in storage. Though to be fair, we are all backseat flying here on this board, and our speculation is just that. Until we get official word from ESA or raw data is released we should give the team the benefit of the doubt. In the meantime, we can wait for the HiRISE imagery of the site.

Posted by: mcaplinger Oct 26 2016, 04:00 AM

You don't subject your flight hardware to harsh conditions, you take an identical unit out for "qualification testing". IIRC, in the case of MPL, for example, this involved bolting a radar to an F-16 and diving it at the ground.

There are limits to the fidelity of testing, but simulations are a key element. For landings many thousands of simulated landings are done to build up statistics on the distribution of behavior.

With all that, MPL was doomed by a couple of missing lines of code that would have taken 5 minutes to write. The Genesis SRC crashed because its G-switches were installed backwards. Stupid mistakes happen.

Posted by: stevesliva Oct 26 2016, 04:16 AM

Lack of hysteresis in state transitions.... it's sort of both. It's not necessarily on the state machine designer to create hysteresis for a noisy sensor. The senor could instead be improved. But sure, it's easy to do that sort of thing in code-- hold down the power button for 10 seconds to force reboot-- if the need is communicated.

Posted by: katodomo Oct 26 2016, 06:55 AM

The radar unit was tested from cranes in Italy in static suspended tests and mounted on a helicopter in dynamic flight tests in Morocco (possibly also due to not that dissimilar terrain?).

See http://www.ibnbattutacentre.org/edl.html for pictures of the flight tests.

Posted by: Gerald Oct 26 2016, 08:10 AM

Those event-triggered multi-threading systems are very hard to test and debug.
There may have been set a timer, which triggers the thruster shut-down if some event hasn't occurred within this time. If, for example the velocitiy variable is initialized with zero, and adjusted by the radar after an assumed time, a delayed setting of the variable may return standstill, although the variable simply hasn't been set. This could be resolved to some degree by adding an invalid flag. But how should the system behave in case of an invalid variable? Default would still be thrusters off, since waiting too long near ground with thrusters on would prevent a landing, and thrusters on during flight would be wrong, too.
There are certainly thousands of possible errors of this kind you don't see in a fixed set of simulations. With the actual data, they can now set-up a new series of unit tests to get closer to real conditions near Mars. And once the error is nailed down, some will certainly say, that this could have been known before. But before the real-world test, finding a needle in a haystack is much easier.
I'm wondering now, whether another test with a low-cost lander should be performed, or if the expensive payload should be risked without a prior fully accomplished landing test.

Posted by: climber Oct 26 2016, 09:45 AM

I thought the radar comes on line only ONCE the backshell have been released. Now, it's said that parachute and backshell have been released too early. I'm a bit confused...or wrong.

Posted by: mcaplinger Oct 26 2016, 02:17 PM

A sensible designer would never use such a structure for a flight control application. There have been well-understood flight control algorithms in use for almost 50 years that can be tested. Note that Viking landed on Mars with a very simple computer the very first time. http://history.nasa.gov/computers/Ch5-6.html

Posted by: JRehling Oct 26 2016, 06:46 PM

Just to clarify on the question of proving computer program correctness…

In the study of formal program verification, one seeks a mathematical-style proof that a program will correctly meet the formal requirements that are defined. This is, as was noted, quite hard to do for complex systems. Moreover, a program that is proven correct may be part of a failing system because the formal requirements are not an accurate statement of the real world application. For example, an airplane autopilot program that assumed that winds are always under 10km/hour might be proven logically correct, but lead to immediate failure because the real world has winds higher than that.

I doubt if any spacecraft failures take place because an algorithm could have been proven correct in the above sense, but the effort to prove it was not made or was not tractable in a computational sense. It's far more likely that ignorance, oversight, or negligence would arise in defining the formal requirements or – more likely still – the notion of proving an algorithm correct in the formal sense was never part of the development process in the first place, for the very good reason that it's usually not tractable for complex systems.

Formal program verification, as the literature defines it, is not a part of any software development process that I've been around. I'd liken it to a doctor trying to use the periodic table of elements to diagnose a patient's illness. Technically, an illness pertains to how your atoms are arranged, but that's not a useful level of description for a sick person, in most cases.

For example, the two problems that afflicted the Cassini-Huygens relay: (1) The Doppler shift in radio frequency because of the relative velocity of Cassini and Huygens during the mission was not put into the formal requirements. Moreover, empirical testing that would have revealed this would have been unthinkable. The algorithm was absolutely correct – assuming that Cassini and Huygens were not moving very fast. The fact of their high relative velocity during the mission was simply excluded from the design phase, but fortunately this oversight was caught before arrival at Saturn. (2) The software that was supposed to turn on radio receivers listening to two partially-redundant radio channels did not turn on one of the two receivers, which meant that Cassini transmitted it in vain, and half of the images that it took were never received, and lost forever. Here, I'm not sure that enough information was released to the public for us to say exactly what went wrong. It becomes a bit arbitrary as to whether the algorithm was correct, but the specifications written incorrectly, or if the specifications were written correctly but the algorithm was not proven correct. My sense is that the paradigm of logical program verification is probably not a good description of their development process, but that may not be public information.

Posted by: mcaplinger Oct 26 2016, 07:04 PM

I have a PhD in computer science and I develop flight software for a living (among other things) and I use whatever tools I can, including formal correctness. But I guess I'd agree that it's not common.


My understanding is that this was user error (miscommanding) rather than a software failure per se.

Software can be complex, and the simpler it is, the more likely it is to be right. Landing on Mars should not be that hard from a software perspective.

Posted by: Art Martin Oct 26 2016, 08:39 PM

What a wonderful insight into the computer system on the Viking landers. Interesting that they say in there that a system could be run completely off preset timings but it was decided on that mission to allow the craft to fly itself a bit based on accelerometer input. Instead of using radar to decide altitude they basically used computed speed and timing which says to me that one can know fairly accurately where the craft is at any time without sophisticated add ons. Hindsight seems to say that radar is a wonderful addition that enhances the entry but nothing replaces the basic science and physics that can model the path and timings very precisely. I suppose there's a nerd factor that takes over when designing complex systems, a pull to reject simplicity. Sometimes, as in the case of the Curiosity sky crane, it all comes together but we all had nightmares about all the things that had to go exactly right. In many ways the real genius was shown in the very simplistic idea of the airbag delivery system, something that ESA could have certainly used for its first attempts since their lander was so light. I understand they wanted the base of the lander on the actual surface so once the airbag is deflated and retracted flip the thing off onto its head. Oh the ease of armchair quarterbacking. Laughs.

Posted by: mcaplinger Oct 26 2016, 08:50 PM

You are reading way too much into that basically non-technical history. Radar is essential for Viking or any Mars lander that has to do anything based on altitude, as the altitude relative to the ground can't be determined any other way.

Posted by: PDP8E Oct 26 2016, 09:00 PM

I agree with mcaplinger: Landing on Mars should not be that hard from software perspective
Flight/lander software is robust (50 yrs of it) and even newer and tested architectures are out there (Deep Space 1, Remote Agent, late 90s)

An executive like Remote Agent could have said something like: "No Parachute, listen to me, not the Radars, stay with me until I say so...we are on a timeline and we have minutes to go....and as for you Radar, stop sending me crap, and get me good altitude and velocity and quit scaring Parachute... and Rockets, don't even think about firing for only 3 seconds.... everybody get back on the script, and back on the timeline..."

Posted by: siravan Oct 26 2016, 11:27 PM

I doubt that the primary problem was radar, as it does not explain the early release of the backshell. My gut feeling is that for whatever reason (bad accelerometers?) the state vector deviated too much from reality and basically the lander though it was lower than it really was and could not incorporate the radar data into the state vector and ended up ignoring it.

Posted by: PDP8E Oct 27 2016, 05:30 AM

Here is my timeline of what was supposed to happen... and what happened
My suggestion is that the heat shield did not come off (or hung on) and spoofed the radars, computer, and rockets
Where is heat shield on the surface, and how close is it to the other hardware?
HiRise should supply answers.
(ESA times, altitude, and speeds)

Posted by: Explorer1 Oct 27 2016, 07:03 AM

That would be a good theory, but the CTX image shows a possible impact (see http://www.planetary.org/blogs/emily-lakdawalla/2016/10211542-schiaparelli-update-ctx.html)
HiRISE should confirm soon enough...

Posted by: Decepticon Oct 27 2016, 07:10 AM

Out of curiosity did the test lander fail before or after planned decent images?

Posted by: Gerald Oct 27 2016, 09:11 AM

There is an extra ")" at the end of your url. http://www.planetary.org/blogs/emily-lakdawalla/2016/10211542-schiaparelli-update-ctx.html?st=105&start=105 should work.

Posted by: Gerald Oct 27 2016, 11:08 AM

http://spaceflight101.com/exomars/trace-gas-orbiter/ is a detailed technical description of TGO, including http://spaceflight101.com/exomars/schiaparelli-edm/.
Have a closer look at http://spaceflight101.com/exomars/wp-content/uploads/sites/79/2016/03/TGO-FBD.jpg, particularly at the https://www.thalesgroup.com/en/worldwide/space/news/video-exomars-testing-technologies-mars-down-earth (RDA) block within the Surface Platform subdiagram. You'll see a thin blue line injecting the block, meaning connection via https://en.wikipedia.org/wiki/CAN_bus b.
Access to the propulsion sysem via CAN (again via http://spaceflight101.com/exomars/schiaparelli-edm/) :


Communication over CAN bus systems is usually performed via sending https://de.mathworks.com/help/vnt/ug/build-can-communication-simulink-models.html?requestedDomain=www.mathworks.com.
Systems are usually described by https://en.wikipedia.org/wiki/Message_sequence_chart. This would normally mean asynchronous exchange of messages between processes with all the difficult testing.
This doesn't necessarily mean, that the system design of TGO works exactly like this, but I would be surprised, if not.

See also page 9 of https://solarsystem.nasa.gov/docs/3_Portigliotti_ExoMars_GNC.pdf:

Posted by: katodomo Oct 27 2016, 12:43 PM

There's always laser altimeters for altitude and doppler Lidar for relative velocity.

Might be worth it for the 2020 surface platform to check into what's available, especially inhouse with ESA members and associates. OPTEL-D with AIM heritage comes to mind as a family of something that could possibly be further downsized to a sufficiently low footprint.

Posted by: Gerald Oct 27 2016, 01:25 PM

I'd think, they'll "simply" fix the glitch(es) or parameter settings, without fundamental changes of the design.

Edit: Altitude and veolcity of http://spaceflight101.com/exomars/schiaparelli-edm/ were determined by radar:

Posted by: Explorer1 Oct 27 2016, 04:20 PM

HiRISE images out : http://www.jpl.nasa.gov/news/news.php?feature=6663 Definitely heat shield separation, but a strange streak going east of the lander crash.

Posted by: mcaplinger Oct 27 2016, 04:29 PM

Radar is an extremely robust and mature technology and the larger beam footprint and longer wavelength can be an advantage. The landing applications for lidar I know of are for terrain hazard avoidance, not altitude/velocity determination per se, for example https://www-robotics.jpl.nasa.gov/publications/Andrew_Johnson/aejJGCD2002.pdf

AFAIK, every successful Mars lander (and Moon lander, for that matter) has used radar.

Posted by: JRehling Oct 27 2016, 05:30 PM

That is definitely a strange streak. Maybe that's the mini-version of a crater ray: The splash of some small-scale debris from the impact site. Another thought: Perhaps that's a location where a small, random feature in the sub-dust topography had less dust adhering to it. The smoothness of the curve, however, doesn't look like typical rock morphology on that scale. Maybe the impact stirred up a mini dust devil?

Posted by: Hungry4info Oct 27 2016, 08:30 PM

It could be that a pressurised tank was let free in the impact and the curved streak represents the path the tank took while it was depressurising. Just throwing ideas out there, I doubt we'll ever know for sure.

Posted by: marsophile Oct 28 2016, 12:06 AM

http://photojournal.jpl.nasa.gov/figures/PIA21130_fig2.jpg

There is no sign of the curved "tail" in the CTX image taken last week, so it may have developed since then from debris or disturbed soil blown by the wind.

Posted by: marsophile Oct 28 2016, 01:36 AM

This is a comparison of the CTX and HIRISE images as best I can match them by the eye. I guess the tail could be lost by the low resolution. There might also be some dispersion of the debris in the time between the images.

Posted by: Hungry4info Oct 28 2016, 01:38 AM

There's also no signs in the CTX of the rather prominent craters just west of, and south of, the impact site. Either those craters are also a few days old or the CTX image doesn't really have the resolution and/or signal-to-noise ratio to see such finer details.

Posted by: peter59 Oct 28 2016, 05:58 AM

I think this is the right solution. This may be a trace of a rotating and ruptured tank. This explains the arc.

Posted by: xflare Oct 28 2016, 07:37 AM

Little snippets of information still coming out, one saying the lander swung too much while on the parachute confusing the the altimeter causing the computer to look for radar which wasnt on (maybe). Computer triggers remaining decent sequences, even science instruments turned on, thinking it had landed !

Posted by: Steve G Oct 29 2016, 02:05 PM

Could the lack of curved tail be explained by different lighting angles between the two images?

Posted by: Phil Stooke Oct 29 2016, 04:28 PM

It is a resolution issue, but I don't agree that it is not visible in CTX. There is a dark pixel in CTX at exactly the right place.


Phil

Posted by: tolis Oct 29 2016, 06:56 PM

Could someone cognisant speculate on how hydrazine might behave if exposed to martian surface conditions?
For instance, would it burn, explode, quickly evaporate, or linger?

Posted by: Explorer1 Oct 29 2016, 08:08 PM

MSL's hazcam showed the skycrane explosion as a big plume, but there wasn't enough detail to tell if it was smoke from some chemical reaction/combustion or just a dust cloud from the impact itself. They obviously didn't want to risk exposure to toxic hardware to take a closer look with the rover though....

Posted by: Gerald Oct 29 2016, 08:36 PM

First, one needs to know the exact chemical. According to http://www.esa.int/spaceinimages/Images/2016/02/Fuelling_the_Trace_Gas_Orbiter, the propellant has likely been MMH (https://en.wikipedia.org/wiki/Monomethylhydrazine), and "MON" as oxidizer, a mix of nitrogen oxides.
According to table 11 of https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19780005291.pdf, MMH has a boiling point of about 260 K near 600 Pa. The freezing point of MMH is near 220 K, but it can stay liquid down to 207 K.
Hence MMH may freeze overnight, but evaporate away over daytime, unless it isn't http://www.sciencedirect.com/science/article/pii/004060319180065Q on impact.

If the impact didn't cause immediate decomposition, it's likely, that the presence of MON formed a https://en.wikipedia.org/wiki/Hypergolic_propellant mix with MMH, resulting in an explosion, and consecutive decomposition of the remaining MMH.

Posted by: mcaplinger Oct 29 2016, 09:25 PM

No, the lander was a monoprop system using only hydrazine (N2H4). http://spaceflight101.com/exomars/schiaparelli-edm/

Same thing with MSL.

I wasn't able to find the phase diagram of hydrazine, but I would expect most of it to have evaporated under martian ambient pressure.

Posted by: Gerald Oct 30 2016, 04:58 PM

I should have remembered that from a few days before...
If it's really pure hydrazine with no water content, it freezes near 2 C.
According to http://www.asi.org/adb/04/03/09/hydrazine-info.html, the vapor pressure of solid hydrazine at 0 C is 2.60 mm Hg or 2.60 hPa x 1013.25 / 760 = 3.47 hPa. Therefore at estimated 6 hPa on Mars, there should be a narrow temperature range, where hydrazine would be an oily liquid.
But due to the zero partial hydrazine pressure on Mars, it will boil, then evaporate until it freezes, then sublimate.

But again, it is likely to decompose in an explosion on impact:

Or on contact with the surface material on Mars, especially with the iron oxides bearing dust:

This may be dependent of the temperature, but it's reasonable to assume, that the hydrazine in the tanks was warmed and liquid on impact.

If the hydrazine contains some stabilizing additive, odds for staying stable on impact might be a little better. But it will nevertheless react or decompose in the Martian environment after days or weeks.

Posted by: HSchirmer Nov 1 2016, 05:54 AM

Just noticed an interesting quote-



And a prior article about a 170-120 Kelvin difference because of the tides.
http://www.planetary.org/blogs/guest-blogs/2013/mysterious-tides-martian-atmosphere.html

Now, that's a twist I had not thought of. Without running through pv=nrt,
a difference of 50 kelvin degrees, at 120 degrees kelvin, is a huge change in pressure.

Just like a homerun baseball travels farther through thin summer air, shorter through dense fall air,
perhaps part of the story here is that Mars' atmosphere has some major density fluctuations?

Posted by: mcaplinger Nov 1 2016, 02:23 PM

That's always been a fact of life for EDL. It doesn't look to me like it affects the terminal part of landing, it mostly means that the time spent on parachute can vary by a significant amount. It's basically why you need the radar, you can't rely on absolute pressure sensing to figure out your altitude relative to the ground.

Posted by: Explorer1 Nov 3 2016, 06:24 PM

Colour HiRISE imagery released: http://www.esa.int/Our_Activities/Space_Science/ExoMars/Schiaparelli_crash_site_in_colour
http://www.uahirise.org/releases/esa-edm/second-image.php

The white spots are real objects, parachute moving in the wind...

Posted by: nogal Nov 4 2016, 09:05 PM

Here is a refreshed version of the Schiaparelli KML file for GE. I added several ground overlays with the recently released HiRISE color and black & white images. Do zoom in to see them. All images can individualy be made visible or hidden.

There are many white dots around the crash crater, which are interpreted as pieces that broke off Schiaparelli.
Rapidly toggle on and off the color image of the parachute to see it flip (interpreted as caused by wind, just as MSL's parachute).

The HiRISE b&w image's size is 6.82MB, so the KML directly loads it from the ESA web site (instead of being included in the KMZ). This takes a little time and requires the user to be online.

Fernando
 Schiaparelli.kmz ( 602.11K ) : 334

Posted by: PDP8E Nov 5 2016, 03:08 AM

Here is the HiRise color image of the Schiaparelli Impact site.
4X and de-convoluted
My thoughts:
* the three big white spots are the three main fuel tanks for the retrorockets
* the arcing line off the right is the pressurized helium tank, spewing (its purpose was to to pressurize the the fuel tanks as each emptied)
* as always ... your mileage may vary

Posted by: PDP8E Nov 6 2016, 04:12 PM

ESA says in the article cited below, that the investigation should be done by the end of November. The fuzzy 'software glitch' starts to comes into more focus:

"Fundamentally there’s a software issue here between the radar and the on-board computer system,” Mark McCaughrean, a senior science advisor at ESA, told the Associated Press. “The radar was giving inconsistent info on where it was.”

http://www.csmonitor.com/Science/2016/1105/Schiaparelli-s-demise-What-color-photos-of-the-crash-site-tell-us

Posted by: marsophile Nov 8 2016, 07:12 AM

Similar information in this new BBC report:

http://www.bbc.com/news/science-environment-37898565

"The onboard computer had some problems taking data from different sources, and defining correctly the altitude...."

Posted by: nogal Nov 9 2016, 06:13 PM

Here is an interesting article from ESA on a new microprocessor for space applications.
http://www.esa.int/Our_Activities/Space_Engineering_Technology/Talking_technology/Making_space_missions_smarter
Interesting to note that the radiation hardening process, despite progresses, still results in larger circuitry (65 nm) and much smaller speeds (250 MHz) as compared to non-space qualified microprocessors (e.g. the z13 at 22nm and 5GHz).
Fernando

Posted by: PDP8E Nov 19 2016, 09:56 PM

The Italian news agencies are running several stories today about the Schiaparelli EDM Lander.
I counted six articles -- all roughly the same
The craft was built in Italy for ESA. Thales Alenia Space is the spacecraft builder in coordination with Russia’s Roscosmos. The official ESA (interim?) crash report is due on November 24, 2016

Enrico Flamini, 'scientific coordinator' at the Italian Space Agency (ASI) relates what went wrong with the Schiaparelli EDM lander.
• He reports that the lander was ‘in wild oscillation’ on the parachute
• When the altimeter read 2000 meters, the gyros reported -10m (below the surface)
• He said the computer believed the gyros and eventually the lander crashed
• He also said that the stratospheric balloon drop tests of the whole system were never done, to save a million euros
• ASI wanted the Swedish Space Corporation to do the ‘stratospheric throws’, but ESA gave the work to a Romanian company that eventually didn’t do the job
• ESA then 'made itself content' with computer simulations of the landing provided by a British company

Here is one (of many links available)

http://www.quotidiano.net/tech/marte-schiaparelli-sonda-1.2690005http://www.quotidiano.net/tech/marte-schiaparelli-sonda-1.2690005

Posted by: mcaplinger Nov 20 2016, 02:47 AM

Gyros don't measure altitude, and as noted upthread, IMUs can't be used to determine absolute height above the ground. So this part of the story makes little sense. Let's just wait for the report and ignore media misunderstandings.

Posted by: JRehling Nov 20 2016, 03:38 AM

As noted, this isn't a complete/consistent account. It seems to remain open as to whether software caused the crash or if the software simply responded futilely to an already hopeless situation.

Fluid dynamics are not trivial to model computationally, so using computer simulations to validate parachute descent seems like a bad option, but saying that now benefits, of course, from hindsight.

Posted by: mcaplinger Nov 20 2016, 03:51 AM

The last time the US did actual flight-like testing of supersonic parachutes was for Viking (not counting the LDSD flights, which both failed.)

Posted by: tolis Nov 20 2016, 08:36 AM

It would also be interesting to know how the financing of the different components of Exomars
was handled within the overall budget for the mission. For instance, did TGO and Schiaparelli
have their own "ringfenced" budgets or was it possible to raid the budget of one to pay
for the other?

Posted by: MahFL Nov 20 2016, 05:05 PM

Shouldn't the title of the topic be changed to "...attempted Schiaparelli landing" seeing as it was not successful ?

Posted by: mcaplinger Nov 20 2016, 06:34 PM

The word "landing" doesn't imply success. See exchange below.

Posted by: JRehling Nov 20 2016, 08:02 PM

How to test systems that operate in the uncertain realm of fluid dynamics is an interesting proposition.

The Wright brothers tried to use an analytical approach to design propellers for an airplane, and realized that they couldn't do it. So, they started off with the design of ship propellers, which were a proven technology, and adjusted as best they could for the different parameters of air vs. water. It worked.

I see that the Schiaparelli parachute system evolved from the Huygens system. That also involves very different parameters, though certainly not as different as the Wright brothers' case.

Parachutes have worked for entry on Venus, Earth, Mars, Jupiter, and Titan. It would seem like there's not much left to prove there.

Posted by: mcaplinger Nov 20 2016, 11:30 PM

Supersonic Mars parachutes are complicated. Viking proved the original ring-sail design, but this design doesn't scale very well. MSL development was all done in non-marslike conditions (higher pressure, lower velocity) in the big wind tunnel at NASA Ames and resulted in some failures which were only fixed late in testing. LDSD did flight-like testing at great expense for a larger parachute and despite lots of expert consulting (see https://www.nasa.gov/jpl/ldsd/the-supreme-council-of-parachute-experts ) both flights' chutes failed completely. One of the reasons that NASA is participating in SpaceX's Mars demo mission is because larger parachutes are not looking feasible after LDSD.

That said, the EDL demonstrator should have been well within the Viking/Pathfinder/MER experience base and should not have required additional flight testing IMHO. We'll just have to wait for the report to see.

Posted by: mcaplinger Nov 21 2016, 08:28 PM

I misspoke. While ring-sails were tested on Viking (and one was initially proposed for MSL) all US Mars missions have used disc-band-gap parachutes. See https://solarsystem.nasa.gov/docs/p491.pdf

The LDSD failures were of ring-sails.

Posted by: Explorer1 Nov 23 2016, 06:41 PM

Looks like it was the IMU being saturated, confusing the computer.

http://www.esa.int/Our_Activities/Space_Science/ExoMars/Schiaparelli_landing_investigation_makes_progress

Posted by: marsophile Nov 24 2016, 03:04 AM

http://www.bbc.com/news/science-environment-38082636

This BBC report says the IMU error was "propagated forward when the data from the doppler radar kicked in," whatever that means. [I can see that instrument rotational velocity might be subtracted from Doppler velocity to get spacecraft velocity, but I don't see why this would figure into calculating altitude, which I assume would be determined by the delay time of a reflected radar pulse.]

Posted by: JRehling Nov 24 2016, 01:00 PM

If it was used to calculate altitude – and I can't say if or why – the how might have involved the assumption that a rocking/rotating spacecraft would show changes in the measured distance/velocity with respect to the ground as the radar beam pointed at various angles deviating significantly from the nadir.

When I personally leapt from an airplane and hung by parachute, I was surprised by how nearly stationary I felt at the top of my descent, because my horizontal and vertical motion was so small compared to the distance from the ground. It didn't look like I was descending or moving laterally. I promise you, the final few seconds of my descent did not seem that way at all.

I wasn't rocking or rotating – much – but when a spacecraft is, you can't count on the radar beam being pointed right at the nadir, and then the measurement of distance to the end of the beam will exceed the actual altitude. So I guess that an algorithm designed to derive the true altitude of a rocking, rotating, and/or decelerating spacecraft from those changing measurements is necessary until the time when the radar's direction can be guaranteed.

Posted by: PDP8E Nov 25 2016, 12:35 AM

ESA has told us that they have simulated the fault and it matches what happened. OK.... but...
The problem is that the 'glitch' makes as much sense as the Italian Space Agency's story a few days ago.
And there is a very good reason for that. We have no insight into the EDL software design used by the ESA designers and programmers
As an RTOS programmer for decades (VxWorks, also used by MER, Pathfinder, Odyssey, etc) , sanity checks are part of the landscape.
For example: when the craft is at an altitude of 4 Km and in the next second it thinks it is 'on the ground', one of the background sanity checks would have said 'we just accelerated to 14 Million KM/hr -- ignore the readings, wait until they get back in 'range', and do it again. If the controller is taking 50 readings per second, you might say something like: check the next 100 readings to see if they come into range.... ELSE do something different - like maybe rely on a nominal 'EDL Timeline' to do things in sequence for a while, if you are temporarily instrument blind.
Controlling machinery in real-time is very tricky but it also a 'well-plowed' field of study. Controlling a speeding craft during a Mars EDL has to be one of the most demanding situations (you travel very far in a few seconds) and so it requires a robust, well-designed, autonomous controller operating in Real Time
I believe the IMU used on Schiaparelli is the Northrop Grumman LN-200S (S for space) -- see the link below for a PDF of specs.
It looks pretty hard to get this device into delta-theta saturation (laser-gyros) and/or delta-v saturation (accelerometers)
I look forward to reading the final ESA report in early 2017

http://www.northropgrumman.com/Capabilities/LN200FOG/Documents/ln200s.pdf IMU Specs

Posted by: mcaplinger Nov 25 2016, 04:40 PM

AFAIK, typical flight control software doesn't use explicit validity checks but relies on Kalman filter weights to merge data from different sources. There is usually a big discontinuity at radar lockup as the IMU propagated altitude gets replaced. The story isn't making much sense yet but it seems like the filter was confused at this point, which seems like a pretty fundamental mistake as this is a known critical time.

Posted by: marsophile Nov 26 2016, 02:36 AM

So if the radar beam is pointing off-nadir by an angle of theta, the actual altitude y could be calculated as y = x cos(theta), where x is the altimeter reading?
In that case, if theta exceeds 90 degrees, cos(theta) and hence y would be negative. Hmm. Could it be that simple?

Posted by: mcaplinger Nov 26 2016, 03:20 PM

Unlikely, it's a multiple beam Doppler radar which should be able to estimate attitude on its own.

Posted by: JRehling Nov 26 2016, 06:42 PM

Yes, three beams at the vertices of an equilateral triangle should be able to uniquely determine altitude, assuming a spheric surface below, reliable sensors, and no serious latencies in the analog-digital read. If any of those assumptions is not met, an algorithm might return nonsensical calculations of altitude, in which case, some sanity checking ought to exist – changes in altitude and velocity have to be continuous and considerably bound. Meridiani, as we've seen, is pretty flat, so the spheric assumption should work extremely well. A negative altitude calculation could have resulted from an inaccurate sensor reading or significant rotation between the time that discrete measurements were made.

Posted by: PDP8E Nov 26 2016, 09:17 PM

I think the murky picture will finally emerge when the early 2017 report comes out.
Apparently, Schiaparelli transmitted 600 Mega-Bytes of data back to the orbiter.
That's a lot of engineering and science data!

Esa Twitter link:

https://twitter.com/_stephen_lewis_/status/789020772551520256

Maybe they can release some (all) of it in the future.

Posted by: stevesliva Nov 27 2016, 02:31 AM

Ariane V initial launch? It would have failed your sanity checks. Nonetheless he software commanded a wild course correction. I just don't know how many layers of "wait and see" you're supposed to put in there though. Ariane V may well have had plenty of "wait and see" but not amount of it was going to undo the overflow. You can reject a certain amount of garbage data, but eventually that might be all you have left.

Posted by: siravan Nov 27 2016, 12:53 PM

There is a limit of the number of such sanity checks you can explicitly implement in a control system. You get a huge number of rules because you need to consider different combinations of inputs. Instead, since the time of Apollo, most (all?) s/c control systems have used Kalman filter or one of its descendants. The basic idea is that each piece of input comes with a measure of its accuracy that affects how it is incorporated into a state vector. It seems that for Schiaparelli, the control system assigned a higher accuracy to IMU inputs than to the radar readings and therefore rejects radar inputs in favor of the wrong state vector generated from IMU.

Posted by: nogal May 24 2017, 01:45 PM

ESA has just http://www.esa.int/Our_Activities/Space_Science/ExoMars/Schiaparelli_landing_investigation_completedthat the Schiaparelli landing investigation has been completed. A report summary can be downloaded from http://exploration.esa.int/mars/59176-exomars-2016-schiaparelli-anomaly-inquiry/

Here is an excerpt:

Fernando

Posted by: mcaplinger May 24 2017, 07:16 PM

Wow. Basically there were several issues, but there was one parameter that was supposed to be 15 msec and was set to some unstated larger value and nobody caught it.

That's gotta hurt.

Posted by: Explorer1 May 24 2017, 09:34 PM

It always does. Just like Mars Observer and the metric mixup, or Galileo and the HGA, or Genesis accelerators being upside down, or (for ESA) the Huygens Channel A. Nothing to do but live with it and learn from mistakes.

Posted by: mcaplinger May 24 2017, 09:45 PM

That's Mars Climate Orbiter. The Mars Observer problem was a lot more subtle (as was the Galileo problem.)

Posted by: Explorer1 May 24 2017, 09:50 PM

Oops, yes. Looking at the report, I note that they used the observations Oppy took of its heat shield during their analysis. Good use of ground truth and previous experience to build on for the future.
Also from page 18, for something this thread discussed:

Posted by: PDP8E May 25 2017, 06:36 AM

As mentioned upstream in the thread, a few overriding sanity checks can and should be layered on top of the real-time Kalman NAV computer in an EXEC manner.
(underlines are mine)

(ESA) Recommendation 05 – Robust and reliable sanity checks shall be implemented in the on-board S/W to
increase the robustness of the design, which could be, but not limited to :
- Check on attitude
- Check on altitude sign (altitude cannot be negative).
- Check on vertical acceleration during terminal descent and landing (cannot be higher than gravity).
- Check altitude magnitude change (it cannot change from 3.7 Km to a negative value in one second).
- Check wrt pre-flight timeline (altitude or acceleration profile vs time) to check consistency of measurements

Let's get this done and see a working 2020 lander on the surface of Mars!

Posted by: Paolo Sep 14 2018, 05:46 PM

it turns out Schiaparelli finally did provide a little bit of science data:
https://www.researchgate.net/publication/326859133/download (pdf freely downloadable)

Posted by: mcmcmc Nov 20 2018, 10:21 AM

The PDF led me tohttps://archives.esac.esa.int/psa/#!Table%20View/ExoMars%202016=mission which I will have to investigate a lot!

From PDF:

Summary:
14:42:22 Atmosphere entry (T0)
14:45:23 Parachute opening (T1=T0+181)
14:46:04 Heatshield (T2=T0+222 , T1+41)
14:46:46 Parachute/backshield released (T3=T0+263 , T2+41)
14:46:50 Thrusters on (T4=T0+267, T3+4)
14:46:53 Thrusters off, freefall from 2.76 km altitude(T5=T0+270 , T4+3)
14:46:58: end of data (?)

Posted by: Phil Stooke May 12 2019, 10:15 PM

The Schiaparelli parachute has shifted a bit in the wind between 2016 and 2019:

I will try to update this with the older image ID and date later. The images have slightly different orientations.

Phil

Posted by: Phil Stooke May 13 2019, 06:59 PM

Here's the full set of available images of the Schiaparelli parachute. The first 3 are all in late 2016 and show a quick change to the parachute after landing. The last one is from this March and shows a bit more movement, or perhaps parts being covered with dust.

Phil

Posted by: JRehling May 14 2019, 02:13 AM

I think all future flight logic systems can WLOG rule out the possibility that a descending lander is below the surface.

*without loss of generality