И все же ее планируемая нагрузка на НОО составляет всего 70
Ошибки тут нет, скорее передёргивание фактов от автора. По первоначальному плану самая первая рабочая конфигурация sls будет способна закинуть на низкую орбиту как раз 70 тонн, эта конфигурация будет летать 1-2 раза (планы постоянно меняются). Block 1a уже сможет больше. Что интересно, информацию о 70 тоннах я смог найти только забитую в различные уголки на английской Вики и паре зарубежных сайтов, так что возможно планы изменились, и теперь реально с первого раза будет по 95т.
«Придирки» это если бы я вам говорил про ошибки форматирования в статье (они кстати тоже есть). А я говорю о фактических ошибках, которые могут запутать неопытных пользователей ROS. Написав этот «гайд» вы исказили его оригинальный смысл, у людей которым он может потребоваться возникнут противоречия с другими материалами, а это безусловно плохо. Проще говоря, вместо того чтобы помочь, вы потенциально навредили.
Если оригинальный гайд вам кажется непонятным — дополните его. Разберитесь с непонятными кусками и расширьте их в своем гайде. Вместо этого вы просто пропустили оригинальный гайд через какой-то гугл транслейт (шаг 6, «sudo apt установить python3-rosdep» тому пример) и убрали то, что показалось вам лишним, хотя лишним оно не являлось. Вы же хотите чтоб ваш материал принес пользу, ведь так?
Это конечно мое личное мнение, но мне кажется было бы намного лучше, если бы вы привнесли на хабру какой-то новый полезный опыт. То, чем является ваша статья в данный момент — скорее вредно, чем полезно. Хабр это не личный блог, качество материалов важнее факта их наличия.
Есть много путей какими вы могли бы улучшить оригинальный гайд, сделав его более понятным для начинающих, например убрав из него избыточность, или объяснив зачем эта избыточность нужна. rosinstall, например, для многих пользователей на начальном этапе просто не нужен, хотя бы потому что он больше интересен при чистой установке окружения на новых роботов, а при разработке люди либо используются бинарными пакетами, устанавливая их ручками через apt. Другой пример — при обычном пользовании совершенно не важно знать разницу между инсталяциями ros-noetic-desktop и ros-noetic-desktop-full, хотя бы потому что для компьютера разработчика чаще всего просто ставится full (благо машины разработчиков обычно почти бездонные), а вот на роботах лучше ставить base, а доустановку зависимостей производить тем же rosinstal (и в этот момент он начинает быть нужен на компе разработчика, ведь файлы описаний нужно еще написать и проверить).
Если не хотите добавлять новое, напишите хотя бы дословно все то, что есть в оригинале.
Главное, на что я хочу обратить ваше внимание, так это на то, что статью можно, и нужно улучшить, тогда она может стать полезной и важной. Сейчас ваша статья таковой не является.
Простите, но вы же просто перевели исходный гайд на официальном сайте ROS, добавив в него явно кусок на который этот гайд просто ссылается. При условии что процесс установки ROS почти буквально состоит из готового набора команд, который просто можно ввести в указанной последовательности. А ведь ROS можно установить не только на убунту, и не только для bash…
Вы убрали то, что было в официальном гайде, исказили суть некоторых фраз своим переводом (Какой еще пакет bash вы устанавливаете в шаге 4? это настройка переменных окружения, о чем явно сказано в исходном гайде. Более того, вы делаете это неправильно — вы устанавливаете переменные только в текущем экземпляре терминала, чтоб установить их для всех будущих экземпляров нужно добавить эту строку в .bashrc)
Более того, если официальный гайд изменится ваш гайд тут же станет еще больше путать других людей. Перевод не должен искажать смысл оригинала. И насколько я помню офсайт построен на вики структуре, и поддерживается сообществом ROS, там множество готовых гайдов для ros на руссоком. Может вам стоило лучше перевести их? (http://wiki.ros.org/ru/ROS/Installation)
В комментах разразилась куча споров о том что надо читать документацию, надо проверять ошибки. Но как будто никого не смущает что это очевидная ошибка дизайна — невалидное значение pid_t, возвращаемое из fork, является вполне себе валидным для kill:
pid_t fork(void);
int kill(pid_t pid, int sig);
И там и там pid_t. По идее fork должен возвращать не pid_t а что-то вроде pid_or_invalid_t, так чтобы невалидное значение не могло быть преобразованно к pid_t без сигнала ошибки.
То что man читать надо, это и так понятно.
Марсоход по массе почти в два раза тяжелее китайских луноходов «Юйту» и в четыре раза легче «Спирита/Оппортьюнити», которые сели на Марс в январе 2004.
Судя по открытым данным «Спирит/Оппортьюнит» имеют массу по 185 кг, Юйту — 140 кг. В вашей статье масса марсохода указанна как 250 кг (в английской и китайской вики 240 кг). Что-то не вяжется.
Может сравнение все-таки с Кьюриосити (899 кг)?
Читал когда-то статью о методе сильного снижения эффективности аппаратного шифрования путем криогенной заморозки контроллера — встроенному генератору случайных чисел становилось не откуда брать «случайность». Было бы интересно посмотреть на эффективность комбинированной атаки
Сами атаки на пропуск инструкции кажутся мне крайне серьезными, а защита от атаки крайне слабой — без использования случайных задержек в голову приходят только проверки паролей с поэтапным вычислением хеша так, чтобы пропуск любого этапа делал хеш не валидным.
Но это разве принципиально? ОСРВ-совместимых процессоров много, даже среди радстойких есть выбор. Да даже среди радстойких и не очень дорогих есть выбор)
О, может подскажете что-нибудь? Даже не представляю где можно обывателю приобрести такой, видел решения от st утверждается pin-to-pin совместимость, но не нашел даже четкой информации о ценнике и том как приобрести.
Что по поводу моего вопроса к коту — мне просто интересно. Люблю технические детали:)
Значит будем ждать вашего главного отчёта, чем вам не угодили существующие варианты. Мне-то этот вопрос интерестен.
Кстати вы уже определились о том что будет в основе БКУ, какой процессор?
На вашем месте яб посмотрел на альтернативы внимательней. Объем кода некоторых приложений nasa, которые вроде бы должны быть простыми, намекает ( https://sourceforge.net/projects/cfs-cfdp/reviews ). А вы вроде говорите что ресурсов у вас не много.
Просто получается что решение, претендующее на универсальность есть, а вы все равно решаете делать свое решение, и непонятно чем обоснованно это.
Дак Линукс — это даже не начало — это начала начала. Речь о том что проект nasa уже содержит в себе часть базовых программ платформы (если надо могу дать ссылки на соответствующие презентации/программы). Линукс же — это только ядро, и ничего больше. Получается все базовые программы вам делать самим.
Вы про open source или про сам фреймворк? Если речь о фреймворке — процессы разработки-отладки-тестирования у нас не на много хуже. Зачастую конечно это существует для странных* процессоров, и странных ОСРВ, но суть примерно одинакова. Сложности всегда в бюрократизации процесса, когда-то давно была статья про разработку ПО для самолетов — примерно такой же подход.
Если речь об opensource — это не возможно в текущих реалиях. Не потому что у нас такие-сякие, а потому что nasa — чисто государственная организация, и она должна публиковать результаты своей деятельности. Основные разработчики ПО БКУ у нас — МАРС, Энергия и ИСС делают его для себя. И это — коммерческие компании, пусть и с государственной долей. Вы же не ждете такого подхода от, например, Боинг?
*странных — в смысле не очень распространенных и закрытых для обывателя
cfs.gsfc.nasa.gov
У nasa отличный подход в этом плане, давно внедряют. Тут и кросс-разработка, и набор «стандартных приложений» и другие фишки. Все для микроспутникостроителей. И opensource конечно, хотя насовскую лицензию еще поразбирать надо.
Почему все привязались именно к НК-33… Что бы там не говорилось в новости — повторять двигатель в точности никто не будет, не надо понимать эти действия буквально. Если мы говорим о какой-либо экономической целесообразности, о чем S7 как раз все время и твердит — это будет производный продукт, а никак не точная копия. Продукт созданный с современными реалиями. Никто в здравом уме не будет использовать старую систему управления — она не эффективна. Материалы старые не будут использоваться — они уже давно не производятся (те же припои с которыми погорел Хруничев — устаревают и перестают выпускаться). Восстановить производственную цепочку полностью — нереально и не целесообразно. Посмотрят документацию, разберутся, пообщаются с инженерами — и в итоге сделают свое, пусть похожее, может даже с таким же названием — но не в точности то самое. Возможно сам Сопов этого еще не понимает, но на практике будет именно так — иное нереально даже с их деньгами.
В сложившихся условиях это самая правильная стратегия — не разрабатывать свое с нуля, а воспользоваться существующим заделом. На коммерческих рельсах его скорее всего получится сделать эффективней с точки зрения цена-качество (ведь по сути это ведь все равно будет другой двигатель, пусть и имеющий корни у старого)
CorneliusAgrippa самый главный вопрос — когда? После вашего поста про организацию производства в Москве новостей особо не появлялось. На сайтах тоже ничего особенного. Расскажите, на каком этапе находится создание промышленной установки? Чем сейчас занимается завод в Москве, неужели все два года на электронные линзы ушли?
Считаю что безмасочные технологии могут просто перевернуть рынок, особенно если получится быстро адаптировать их под производство радстойкой электроники — нормальные ПЛИСы у нас делать явно не хотят, возможно такая технология позволила бы делать радстойкие схемы значительно дешевле и быстрее, чем изготавливать маски для БМК. А это дало бы качественный рывок нашей космонавтике — сейчас без ПЛИС из США даже мирные научные миссии не могут запустить
Вот только в аварийном режиме Dragon должен иметь возможность сесть не только во флориде и в аварийной ситуации никто не будет выбирать садиться заснеженную степь или пустыню. Хотя конечно в капсуле можно разное добро на такой случай разместить, спасательные одеяла, к примеру, двуцветные бывают — с одной стороны серебряные, с другой — золотые.
Ну, в кубсатах обычно нет дублирования, коммерческая электронная база, и вообще он во много раз проще и глупее большой геостационарной платформы (хотя если сравнивать только служебные вычислительные системы спутников то разница в производительности не большая). Да, там реально может стоять матрица от зеркалки. Конечно не с совсем уж мыльницы, и не такая уж и обычная, допиленная для большей устойчивости к вибрациям и т.п., но вполне доступная за вменяемые деньги.
Ваш один прибор помимо прочего наверняка внутренне сдублирован (если не строирован), куча гальванической развязки, еще и корпус крутой, и термоинтерфейс какой-нибудь есть. Там все значительно проще. Вот вам аппарат, к примеру
Ошибки тут нет, скорее передёргивание фактов от автора. По первоначальному плану самая первая рабочая конфигурация sls будет способна закинуть на низкую орбиту как раз 70 тонн, эта конфигурация будет летать 1-2 раза (планы постоянно меняются). Block 1a уже сможет больше. Что интересно, информацию о 70 тоннах я смог найти только забитую в различные уголки на английской Вики и паре зарубежных сайтов, так что возможно планы изменились, и теперь реально с первого раза будет по 95т.
Если оригинальный гайд вам кажется непонятным — дополните его. Разберитесь с непонятными кусками и расширьте их в своем гайде. Вместо этого вы просто пропустили оригинальный гайд через какой-то гугл транслейт (шаг 6, «sudo apt установить python3-rosdep» тому пример) и убрали то, что показалось вам лишним, хотя лишним оно не являлось. Вы же хотите чтоб ваш материал принес пользу, ведь так?
Это конечно мое личное мнение, но мне кажется было бы намного лучше, если бы вы привнесли на хабру какой-то новый полезный опыт. То, чем является ваша статья в данный момент — скорее вредно, чем полезно. Хабр это не личный блог, качество материалов важнее факта их наличия.
Есть много путей какими вы могли бы улучшить оригинальный гайд, сделав его более понятным для начинающих, например убрав из него избыточность, или объяснив зачем эта избыточность нужна. rosinstall, например, для многих пользователей на начальном этапе просто не нужен, хотя бы потому что он больше интересен при чистой установке окружения на новых роботов, а при разработке люди либо используются бинарными пакетами, устанавливая их ручками через apt. Другой пример — при обычном пользовании совершенно не важно знать разницу между инсталяциями ros-noetic-desktop и ros-noetic-desktop-full, хотя бы потому что для компьютера разработчика чаще всего просто ставится full (благо машины разработчиков обычно почти бездонные), а вот на роботах лучше ставить base, а доустановку зависимостей производить тем же rosinstal (и в этот момент он начинает быть нужен на компе разработчика, ведь файлы описаний нужно еще написать и проверить).
Если не хотите добавлять новое, напишите хотя бы дословно все то, что есть в оригинале.
Главное, на что я хочу обратить ваше внимание, так это на то, что статью можно, и нужно улучшить, тогда она может стать полезной и важной. Сейчас ваша статья таковой не является.
Вы убрали то, что было в официальном гайде, исказили суть некоторых фраз своим переводом (Какой еще пакет bash вы устанавливаете в шаге 4? это настройка переменных окружения, о чем явно сказано в исходном гайде. Более того, вы делаете это неправильно — вы устанавливаете переменные только в текущем экземпляре терминала, чтоб установить их для всех будущих экземпляров нужно добавить эту строку в .bashrc)
Более того, если официальный гайд изменится ваш гайд тут же станет еще больше путать других людей. Перевод не должен искажать смысл оригинала. И насколько я помню офсайт построен на вики структуре, и поддерживается сообществом ROS, там множество готовых гайдов для ros на руссоком. Может вам стоило лучше перевести их? (http://wiki.ros.org/ru/ROS/Installation)
pid_t fork(void);
int kill(pid_t pid, int sig);
И там и там pid_t. По идее fork должен возвращать не pid_t а что-то вроде pid_or_invalid_t, так чтобы невалидное значение не могло быть преобразованно к pid_t без сигнала ошибки.
То что man читать надо, это и так понятно.
Судя по открытым данным «Спирит/Оппортьюнит» имеют массу по 185 кг, Юйту — 140 кг. В вашей статье масса марсохода указанна как 250 кг (в английской и китайской вики 240 кг). Что-то не вяжется.
Может сравнение все-таки с Кьюриосити (899 кг)?
Сами атаки на пропуск инструкции кажутся мне крайне серьезными, а защита от атаки крайне слабой — без использования случайных задержек в голову приходят только проверки паролей с поэтапным вычислением хеша так, чтобы пропуск любого этапа делал хеш не валидным.
О, может подскажете что-нибудь? Даже не представляю где можно обывателю приобрести такой, видел решения от st утверждается pin-to-pin совместимость, но не нашел даже четкой информации о ценнике и том как приобрести.
Что по поводу моего вопроса к коту — мне просто интересно. Люблю технические детали:)
Значит будем ждать вашего главного отчёта, чем вам не угодили существующие варианты. Мне-то этот вопрос интерестен.
Кстати вы уже определились о том что будет в основе БКУ, какой процессор?
На вашем месте яб посмотрел на альтернативы внимательней. Объем кода некоторых приложений nasa, которые вроде бы должны быть простыми, намекает ( https://sourceforge.net/projects/cfs-cfdp/reviews ). А вы вроде говорите что ресурсов у вас не много.
Просто получается что решение, претендующее на универсальность есть, а вы все равно решаете делать свое решение, и непонятно чем обоснованно это.
Дак Линукс — это даже не начало — это начала начала. Речь о том что проект nasa уже содержит в себе часть базовых программ платформы (если надо могу дать ссылки на соответствующие презентации/программы). Линукс же — это только ядро, и ничего больше. Получается все базовые программы вам делать самим.
Если речь об opensource — это не возможно в текущих реалиях. Не потому что у нас такие-сякие, а потому что nasa — чисто государственная организация, и она должна публиковать результаты своей деятельности. Основные разработчики ПО БКУ у нас — МАРС, Энергия и ИСС делают его для себя. И это — коммерческие компании, пусть и с государственной долей. Вы же не ждете такого подхода от, например, Боинг?
*странных — в смысле не очень распространенных и закрытых для обывателя
У nasa отличный подход в этом плане, давно внедряют. Тут и кросс-разработка, и набор «стандартных приложений» и другие фишки. Все для микроспутникостроителей. И opensource конечно, хотя насовскую лицензию еще поразбирать надо.
Считаю что безмасочные технологии могут просто перевернуть рынок, особенно если получится быстро адаптировать их под производство радстойкой электроники — нормальные ПЛИСы у нас делать явно не хотят, возможно такая технология позволила бы делать радстойкие схемы значительно дешевле и быстрее, чем изготавливать маски для БМК. А это дало бы качественный рывок нашей космонавтике — сейчас без ПЛИС из США даже мирные научные миссии не могут запустить
Ваш один прибор помимо прочего наверняка внутренне сдублирован (если не строирован), куча гальванической развязки, еще и корпус крутой, и термоинтерфейс какой-нибудь есть. Там все значительно проще. Вот вам аппарат, к примеру