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
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):
Will Opportunity be able to image the Schiaparelli EDL? Maybe the re-entry plasma?
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.
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)...
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.
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
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.
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/
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.
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.
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
And context for that test image: http://www.leonarddavid.com/europe-readies-mars-lander-for-october-touchdown/
With Oppy being so close, was there any consideration on having it listen to Schiapparelli on UHF during the EDL?
Can somebody point out Victoria crater?
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...
This was just for Schiaparelli = Channels, oh well...
Schiaparelli seperation confirmed!
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:
ESA's https://twitter.com/esaoperations?lang=en confirms TGO is now returning telemetry.
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
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
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??
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.
Mars Express transmitting EDL data now.
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.
Does somebody know when Oppy's images attempt will be on the ground?
Looks like the Orbiter burn was successful - signal acquired right on time.
ExoMars TGO is now confirmed to be in martian orbit.
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...
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.
When might we get HiRise coverage of the landing zone?
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
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
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...
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.
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.
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.
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.
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.
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.
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.
"Schiaparelli Mars probe's parachute 'jettisoned too early'"
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.
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.
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.
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
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)
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).
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.
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).
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.
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.
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
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...
53 km's from Oppy, I bet she could reach it.
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:
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.
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.)
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:
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.
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.
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 )
: 425
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.
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.
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).
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)
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?
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.
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)
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.
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...
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).
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.
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.
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?
$$$, (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.
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.
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.
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.
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.
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..."
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.
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)
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...
Out of curiosity did the test lander fail before or after planned decent images?
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:
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.
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?
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.
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.
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.
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 !
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
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?
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....
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.
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:
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...
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 )
: 363
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
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
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...."
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
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
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.
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?
Shouldn't the title of the topic be changed to "...attempted Schiaparelli landing" seeing as it was not successful ?
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.
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
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.]
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
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.
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.
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.
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.
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:
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.
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:
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!
it turns out Schiaparelli finally did provide a little bit of science data:
https://www.researchgate.net/publication/326859133/download (pdf freely downloadable)
The Schiaparelli parachute has shifted a bit in the wind between 2016 and 2019:
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
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
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)