Исследования Марса

CNSA про свой марсианский "трактор" молчит уже ровно неделю.
Пауза возникла потому, что они переводят на китайский язык заметку из "Правды" про Лунаход-2 и и пресс-релиз NASA о начале миссии Оппотьюнити
 
Вроде там проблема не в задержке, а в том что кадры неправильно привязывались ко времени. Проблема софтовая, но похоже есть проблемы с обеспечением целостности данных.
 
китайцы срочно дооснащают полигон-съемочную площадку в Гоби...
 
Команда марсианского ровера Curiosity сделала открытие: облака, появляющиеся там раньше, находятся на большей высоте и состоят, судя по всему, из замороженного углекислого газа.
"Если вы видите мерцающее облако пастельных оттенков, это потому, что все его частицы почти одинаковые по размеру. Обычно такое происходит сразу после того, как облака сформировались и росли с одинаковой скоростью", - цитирует сотрудника Института космических наук в Боулдере Naked Science.
Марсианские облака в основном парят на высоте не более 60 километров и состоят из водяного льда. На Красной планете редко случаются пасмурные дни: облака обычно низкие и встречаются в районе экватора в холодное время года, когда Марс наиболее удаленный от светила по своей вытянутой орбите.
Однако в 2019 году команда из Лаборатории реактивного движения NASA, работает с марсоходом Curiosity, заметила облака, формирующиеся над горой Шарп в кратере Гейл раньше, чем ожидалось. Через два года ученым удалось не только вновь наблюдать это явление, но и получить его снимки.
Тонкие облака начали формироваться в конце января, причем на высоте более 60 километров. Их заполняли кристаллы льда, которые рассеивали свет от Солнца, в результате чего облака якобы переливались. Поскольку они находились выше, чем обычно, специалисты предположили, что облака состоят не из водяного льда, а из замороженного углекислого газа (сухой лед).
Чтобы точно сказать, какие из недавних изображений Curiosity отразили облака из водяного льда, а какие - из сухого, уйдет некоторое время и новые цветные снимки с камеры марсохода. Они покажут кристаллическое мерцание облаков и определят их высоту: когда Солнце находится выше уровня облаков, кристаллы сухого льда сияют ярким светом, а когда светило опускается ниже, они теряют часть блеска.







 
Роскосмос:

 
Потеря данных в процессе передачи - это нормально. Особенно если по радиоканалу, но и в проводах может иметь место.
А вот что они время вычисляли тупо по номеру кадра...
 
Да ну ладно, у насовцев всегда так - план минимальный а потом на все деньги если он за пять полетов не сдох значит ему ещё летать и летать. Вон оппо по Марсу 90 Сол должен был ползать, а по факту 14лет и 45км.
 
Реакции: SDA
А вот что они время вычисляли тупо по номеру кадра...
А надо было "умно по номеру кадра"? Сделали бы отдельную таблицу соответвия номеров кадра временны́м меткам, также могла бы испортится сама таблица с тем же результатом.
 
Все это решаемые проблемы. Связываешь кадр с меткой времени в одну структуру, можно еще код crc добавить чтобы гарантировать неизменность. Но видно не озаботились...
 
Все это решаемые проблемы.
Вы не поняли о чем я говорю: если у вас кадры идут строго друг за другом через определенное время, то их номера являются исчерпывающей информацией и просто высчитывать время из номеров или хранить отдельно время - с точки зрения надёжности хранения и использования алгоритмов дублирования, проверки и прочего абсолютно нет никакой разницы как хранить. Вообще чем меньше в любой базе дублирующих друг друга данных (то есть легко выводимых друг из друга, тем лучше). В том числе, если один кадр вообще выпал из системы (не был зарегистрирован), то он мог бы быть не был зарегистрирован и в вашей структуре (хуже того, ошибки при связывании ещё добавляют геморроя при восстановлении связности. Ну и ресурсы. Не забывайте, что всякое дополнительное действие - это не только источник дополнительных ошибок - это ещё и дополнительные ресурсы. В общем не изучив данную конкретную программу в данных конкретных условиях улыбаться якобы глупым решениям авторам вертолета я бы не торопился...
 
Красота, ... Эх, вышел с чашкой кофе из палатки, вдохнул полной грудью и наслаждаешься пейзажем.
 
Я вот сейчас это делаю, сидя у монитора. И зачем мне тащиться за миллионы километров...
 
А откуда данные, что не озаботились?

Насколько я понимаю, ошибка была в изначальной привязке меток времени к кадрам.
 
Так ведь и хрен с ним, он и не нужен. Его обработали и забыли. Если выпал - обработали следующий, в нём достаточно информации для полёта. Если конечно известно как давно он снят и сколько мы с этого момента пролетели.
 
то что я читал, пропал один кадр (бывает), и все последующие кадры оказались провязаны к неправильному времени (что не должно быть). Что и вызвало осцилляции. По мне чисто проблема в дизайне real time system.
На посадке навигация по кадрам не используется, так что сели без проблем
 
Но где они оказались привязаны к неправильному времени? В камере (такое бывает, не уверен, что это делает их модель), в драйвере, на входе в user-space часть конвейера, или дальше по ходу конвейера?

Что и вызвало осцилляции. По мне чисто проблема в дизайне real time system.
Скорее всего, проблема в том, что люди, занимавшиеся functional safety, не рассмотрели возможности такого отказа и не выдвинули требований по нему.
 
Как понимаю - в программе обработки, там тупо номер кадра = таймкод.
А эта программа, на базе анализа последовательных картинок, вычисляет перемещение аппарата. И соответственно позиция разошлась с реальной на межкадровый интервал, а он достаточно большой.