ExoMars - Schiaparelli landing |
ExoMars - Schiaparelli landing |
![]()
Post
#1
|
||
Solar System Cartographer ![]() ![]() ![]() ![]() Group: Members Posts: 10196 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) |
|
|
||
![]() |
![]()
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) |
|
|
![]()
Post
#3
|
|
![]() Member ![]() ![]() ![]() Group: Members Posts: 920 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" ![]() 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 |
|
|
![]()
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. |
|
|
![]()
Post
#5
|
|
Senior Member ![]() ![]() ![]() ![]() Group: Members Posts: 2520 Joined: 13-September 05 Member No.: 497 ![]() |
As a career software engineer, I doubt very much if either logical correctness or speed of execution are much of an issue here. 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. -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
![]()
Post
#6
|
|
Senior Member ![]() ![]() ![]() ![]() Group: Members Posts: 1585 Joined: 14-October 05 From: Vermont Member No.: 530 ![]() |
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. 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. |
|
|
![]() ![]() |
![]() |
Lo-Fi Version | Time is now: 21st June 2024 - 12:06 PM |
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. |
![]() |