ExoMars - Schiaparelli landing |
ExoMars - Schiaparelli landing |
Aug 12 2016, 07:07 PM
Post
#1
|
||
Solar System Cartographer Group: Members Posts: 10184 Joined: 5-April 05 From: Canada Member No.: 227 |
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-exom...6-landing-site/ http://exploration.esa.int/mars/57446-exom...6-landing-site/ Phil -------------------- ... because the Solar System ain't gonna map itself.
Also to be found posting similar content on https://mastodon.social/@PhilStooke Maps for download (free PD: https://upload.wikimedia.org/wikipedia/comm...Cartography.pdf NOTE: everything created by me which I post on UMSF is considered to be in the public domain (NOT CC, public domain) |
|
|
||
Oct 25 2016, 06:51 AM
Post
#2
|
|
Member Group: Members Posts: 149 Joined: 18-June 08 Member No.: 4216 |
Reported in Anatoly Zak's website:
"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) |
|
|
Oct 25 2016, 02:00 PM
Post
#3
|
|
Member Group: Members Posts: 916 Joined: 15-June 09 From: Lisbon, Portugal Member No.: 4824 |
That sounds like something you should catch during testing 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 |
|
|
Oct 25 2016, 04:58 PM
Post
#4
|
|
Senior Member Group: Members Posts: 2530 Joined: 20-April 05 Member No.: 321 |
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. |
|
|
Lo-Fi Version | Time is now: 5th June 2024 - 02:14 AM |
RULES AND GUIDELINES Please read the Forum Rules and Guidelines before posting. IMAGE COPYRIGHT |
OPINIONS AND MODERATION Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators. |
SUPPORT THE FORUM Unmannedspaceflight.com is funded by the Planetary Society. Please consider supporting our work and many other projects by donating to the Society or becoming a member. |