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

CNSA про свой марсианский "трактор" молчит уже ровно неделю.
Пауза возникла потому, что они переводят на китайский язык заметку из "Правды" про Лунаход-2 и и пресс-релиз NASA о начале миссии Оппотьюнити ;)
 
Реклама
миг-21р, ну разработчики кажется уверены в том, что неисправность была именно софтовой :rolleyes:
Мол, система контроля полета получала данные от навигационных камер с задержкой, поэтому не могла давать корректные команды подсистеме управления ротором вертолета. С чего бы нам им не верить?

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

25940_3-PIA24645-web.gif


25945_4-PIA24646-web.gif


25946_2-PIA24661-web.gif


 
Роскосмос:
30.05.2021 14:10
Динамические дюны на Марсе
На первый взгляд, эта завораживающая картина поля дюн, подернутая легкой дымкой облаков, напоминает спутниковые снимки одной из земных пустынь. Однако на самом деле это красивейший пейзаж на соседней планете Марс.

Поражающее воображение поле дюн расположено в центре кратера Ломоносова, далеко в северном полушарии Красной планеты (65° с.ш., 351° в.д.). Фотография сделана 2 декабря 2020 года камерой CaSSIS с борта аппарата Trace Gas Orbiter совместной миссии Госкорпорации «Роскосмос» и Европейского космического агентства ExoMars-2016. При помощи этих изображений ведется исследование развития поля дюн в течение года.

На момент снимка зима в северном полушарии Марса заканчивалась, и иней в этом регионе начал сублимироваться. Темные пятна указывают на зоны, где иней уже сублимировался, открыв взору темный базальтовый песок. Гребни дюн указывают среднее направление ветра, в данном случае ветер дует с нижней левой в верхнюю правую сторону снимка. Справа видны более темные, насыщенные базальтовые отложения без инея. Кроме того, справа заметны ярко-белые облака, контрастирующие с темными породами на поверхности планеты.

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

Раннее утро в кратере Езеро (снято в минувшую пятницу).

Красота, ... Эх, вышел с чашкой кофе из палатки, вдохнул полной грудью и наслаждаешься пейзажем.
 
Я вот сейчас это делаю, сидя у монитора. И зачем мне тащиться за миллионы километров... :)
 
Все это решаемые проблемы. Связываешь кадр с меткой времени в одну структуру, можно еще код crc добавить чтобы гарантировать неизменность. Но видно не озаботились...
А откуда данные, что не озаботились?

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

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

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