Именно по этому Дракон отправляется с урезанным экипажем - двое вместо четверых. Так что риск будет только между моментом отстыковки старлайнера (планируется на 6 сентября) и пристыковкой Crew-9 (25 сентября), что, впрочем, тоже не хорошо.
Проблема не только в этом. У посетителей МКС (астронавтов, космонавтов и т.п.) должна быть возможность экстренной эвакуации. Если Старлайнер отправляется в беспилотном режиме, астронавты остаются на МКС без пути отхода - ведь на оставшихся кораблях места не хватит. Не спичку же тянуть...
Это одна из причин по которой в НАСА до сих пор не определились. Наряду с проблемой того что сбойный сервисный модуль сгорит в атмосфере, а значит расследование причин отказа усложняется значительно - на Земле же походу не воспроизвели.
Я не знаю как у вас, но у меня чаще всего бывало так, что довольно значительная часть кода проекта собственно с железом никак не связанна. Например какой-нибудь тестовый стенд собирает данные, сохраняет отчет на флешку. То как он соберет данные это важно, тут никаких вопросов, но вот отлаживать сохранялку в файл прямо на микроконтроллере откровенно запарно. Или коммуникация - работа с драйвером железозависима и не может не отрабатываться на нем, но форматы сообщений и протоколы высокого уровня очень удобно писать в платформонезависимом виде и проверять вот в таких вот эмуляциях. Железо в этом случае просто прячется за моком, сильно подробно копировать его поведение, в данном случае, не нужно, только проверять нужные тестовые сценарии.
При этом в такой модели разработки никто вам не запрещает подробную симуляцию железа и проверку непосредственно кода драйверов и других плохо изолируемых компонентов, тогда можно проводить действительно подробную верификацию софта в таких режимах, которые в железе повторять запарно или просто дорого. Это я собственно и имел ввиду под "любым удобным видом", хотите детализируете, хотите проверяйте только библиотеки которые могут быть платформонезависимы.
А зачем вам прямо эмулировать железо? Тут же задача в первую очередь подтвердить что софт работает так как должно, по крайней мере как я понимаю из статьи. По сути автор просто написал обертки для системных вызовов с тем же интерфейсом что и в rtos.
Такое очень полезно в больших проектах, чтоб автотесты бизнес-логики делать. Вот, например, в НАСА написана своя абстракция для этих целей - Operation system abstaction layer. Представляет собой библиотеку, статически изолирующую системные вызовы, предоставляя совместимый интерфейс. В рамках нее можно отрабатывать довольно сложное поведение систем прямо в линуксе, вообще без железа на столе. Поведение железа при этом эмулируется в любом удобном виде, а использование cmake позволяет в любой момент сменить тулчейн и использовать другой компилятор и другой код непосредственно разговаривающий с железкой. Довольно удобно
Чисто технически, разворачивание и сворачивание это разные операции, скорее всего нужны отдельные приводы для этого, такую массу тащить на орбиту незачем, а на земле можно свернуть внешними приводами. Ну и в целом - сведение и выведение это очень разные процессы по перегрузкам. Для понимания - большую часть времени при создании подобных систем занимает тестирование - т.е. дешевле новый сделать чем спустить этот и потом опять подготовить к запуску.
Вообще предусмотрены. Для возможной дозаправки добавлены соответствующие клапаны, пассивный стыковочный механизм (простейший, по сути интерфейс с РБ) тоже есть. Всерьез, правда, никто не планировал... Подробней можно почитать тут
Другое дело, что в отличие от Хаббла никакая разборка на орбите с заменой внутренних деталей невозможна - там обслуживание было полноценной фичей, Хаббл делался как ПН для Шаттла в первую очередь
На самом деле скорость столкновения может быть почти какой угодно. Мусор может быть и на не-круговой орбите и на наклоненной на 180 градусов относительно орбиты космонавта - вариантов не так уж и мало. А объекты на той же орбите опасности не представляют вообще - относительная скорость почти никакая. 7км\с это ведь относительно Земли, а не относительно космонавта
"Переход к новой "короткой" схеме стал возможен только с вводом в эксплуатацию ракеты-носителя "Союз-2.1а", позволяющей по своим техническим характеристикам и возможностям системы управления выводить космические объекты на заданную орбиту с высочайшей точностью. Также важной особенностью реализации двухвитковой схемы сближения со станцией является предварительное формирование требуемой рабочей орбиты МКС и точное выполнение заложенной в бортовой вычислительный комплекс транспортного корабля программы автономного наведения"
Вы так говорите как будто это фишка Союза (корабля) хотя это в большей степени обеспечено расчетом баллистики и минимизацией "зазора" запуска РН. Ну и тем фактом что наклонение МКС подобрано именно под Байконур, и не факт что с какого-либо другого космодрома, кроме реально экваториальных (а не просто близких, как Канаверал), можно делать выкрутасы с ловлей МКС за 1-2 витка.
Это было бы очень странно, ведь то что делает телескоп первое время это обзоры, а обзоры имеет смысл делать в наиболее широком спектре, т.е. обоими телескопами. Можно вот тут почитать https://habr.com/ru/post/508760/
Не удивлюсь, если немецкие инженеры, увидев, что творит их начальство, уже передали...
А потом сели мотать срок? У нас тут умудряются сесть и за журналистику в этой области, а "передать документацию по управлению" это несколько иной уровень
Срок активного существования у этого телескопа 6.5 лет, и несколько обзоров неба eROSITA уже собрала, так что мы не останемся совсем без ничего. Я думаю шанс на то что сотрудничество по фундаментальным наукам стабилизируется за следующие 3.5 года есть - ИТЕР же как-то продолжают строить. А шанс восстановить сломанный телескоп без знания как он устроен крайне низок. Включить они его наверное включат, но, как и во всем космическом - нет проблем с ситуацией когда все хорошо, главные проблемы возникают в ситуации когда хорошо не все, и вот режимы восстановления можно и не осилить.
Можно сколько угодно спорить о том стоило ли его выключать, фундаментальная наука она для всех. Но это дело тех, кто этим инструментом владеет. Впрочем, Роскосмосу не привыкать заниматься космическим пиратством.
Такие телескопы работают долгие годы - может лучше подождать пока отношения стабилизируются хоть чуть-чуть? С орбиты он никуда не денется, сломать всегда можно успеть, а чинить потом - как? Это не домашняя фотокамера с защитой от дурака, телескоп при неправильном обращении легко можно и спалить или, в лучшем случае, отправить в безопасный режим, а как его оттуда вытаскивать потом, методом тыка?
Желание даже всех ученых ЕКА недостаточно - нужна более конкретная информация о порядке восстановления и требуемых командах, а такую без явного и публичного разрешения никто не предоставит.
Это не то дело, которое "пробуют" - риск не оправдан, второго шанса может не быть.
Просто инженеры консервативны в оценках. Это как с марсоходами - гарантируют не меньше месяца работы, а караются потом годами сверх гарантированного срока.
Да и вообще, тут же речь про передовой научный инструмент! Большинство ключевых технологий в космосе в первый раз, было бы странно если бы предельные характеристики всех решений были точно известны заранее, ведь тогда бы он не был бы передовым, скорее рядовым, правильно?
Продлить ресурс конечно же можно, что-то можно поменять, что-то - просто перепроверить и уточнить ресурс, но это все равно дополнительные операции.
Все сильно зависит от аппарата. "Науке" не нужно было входить в атмосферу другой планеты на второй космической и мягко садиться. Некоторые модули "Казачка" вполне и не разборными могут быть, обслуживание-то не предполагалось.
У космических аппаратов все очень дорого, и потому очень точно рассчитано, считают даже километраж на дорогах - можно проехать не более N километров, иначе ресурс вибростойкости может пострадать слишком сильно, и аппарат может просто не пережить выведение. Предел по хранению может означать, например, предел стойкости конструктивных материалов к воздействию кислорода (в космосе и на Марсе с кислородом не оч, а значит можно использовать что-то более легкое, но менее стойкое к коррозии).
Пример с кислородом я взял из головы, но надеюсь идея понятна - необходимость оптимизировать конструкцию аппаратов до предела может вылезти в неожиданных местах.
Когда о таком говорят, то речь обычно не о близко расположенных участках, а об участках которые находятся буквально в одном здании. Причем если на таких участках мало наблюдателей, и они "правильные", то явка отличается на десятки процентов. Так же наблюдается интересная закономерность - чем выше на участке явка, тем более однообразно люди на участке голосуют - это и есть "хвост кометы", который объясняют вбросами. Собственно если отбрасывать все такие странные УИКи люди в нашей стане оказываются вполне себе однородными, по крайней мере без резких пиков на пустом месте.
Примеры были, выборы в дугих старанах, выборы РФ 2000
Выборы 2000 г
Явка в целом большая, но большая часть голосов, как ни удивительно, кучкуется в одной области. Посмотрим что было в 2016
2016
Чем больше людей приходит, тем более размазанным оказывается ядро.
График в статье тоже выглядит интересно, не нем можно заметить регулярную сетку в верхней части графика:
Самое забавное что это не ошибка - это крайне похоже на результат "подгона" на участков результатов под конкретный процент. Похожую сетку можно увидеть на голосовании за поправку:
2020, голосование за поправку
Не знаю как вам, а мне такой способ поиска проблем кажется вполне убедительным. И он показывает что в среднем результаты по стране вполне себе монотонные, пусть на вашем примере какие-то участки и будут выделяться, но на масштабах страны с большей вероятностью будут выделятся именно проблемные участки. К сожалению, по данным текущей детализации (участок-процент за каждый пункт) более точной картины (чтоб отличить действительно странные участки) построить нельзя. Более интересны в этом смысле результаты электронного голосования, там можно выделить каждый отдельный голос, и отделить время голосования (с определенной, пусть и загрубленной точностью). Но это уже другая история
И все же ее планируемая нагрузка на НОО составляет всего 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)
Именно по этому Дракон отправляется с урезанным экипажем - двое вместо четверых. Так что риск будет только между моментом отстыковки старлайнера (планируется на 6 сентября) и пристыковкой Crew-9 (25 сентября), что, впрочем, тоже не хорошо.
Проблема не только в этом. У посетителей МКС (астронавтов, космонавтов и т.п.) должна быть возможность экстренной эвакуации. Если Старлайнер отправляется в беспилотном режиме, астронавты остаются на МКС без пути отхода - ведь на оставшихся кораблях места не хватит. Не спичку же тянуть...
Это одна из причин по которой в НАСА до сих пор не определились. Наряду с проблемой того что сбойный сервисный модуль сгорит в атмосфере, а значит расследование причин отказа усложняется значительно - на Земле же походу не воспроизвели.
Я не знаю как у вас, но у меня чаще всего бывало так, что довольно значительная часть кода проекта собственно с железом никак не связанна. Например какой-нибудь тестовый стенд собирает данные, сохраняет отчет на флешку. То как он соберет данные это важно, тут никаких вопросов, но вот отлаживать сохранялку в файл прямо на микроконтроллере откровенно запарно. Или коммуникация - работа с драйвером железозависима и не может не отрабатываться на нем, но форматы сообщений и протоколы высокого уровня очень удобно писать в платформонезависимом виде и проверять вот в таких вот эмуляциях. Железо в этом случае просто прячется за моком, сильно подробно копировать его поведение, в данном случае, не нужно, только проверять нужные тестовые сценарии.
При этом в такой модели разработки никто вам не запрещает подробную симуляцию железа и проверку непосредственно кода драйверов и других плохо изолируемых компонентов, тогда можно проводить действительно подробную верификацию софта в таких режимах, которые в железе повторять запарно или просто дорого. Это я собственно и имел ввиду под "любым удобным видом", хотите детализируете, хотите проверяйте только библиотеки которые могут быть платформонезависимы.
А зачем вам прямо эмулировать железо? Тут же задача в первую очередь подтвердить что софт работает так как должно, по крайней мере как я понимаю из статьи. По сути автор просто написал обертки для системных вызовов с тем же интерфейсом что и в rtos.
Такое очень полезно в больших проектах, чтоб автотесты бизнес-логики делать. Вот, например, в НАСА написана своя абстракция для этих целей - Operation system abstaction layer. Представляет собой библиотеку, статически изолирующую системные вызовы, предоставляя совместимый интерфейс. В рамках нее можно отрабатывать довольно сложное поведение систем прямо в линуксе, вообще без железа на столе. Поведение железа при этом эмулируется в любом удобном виде, а использование cmake позволяет в любой момент сменить тулчейн и использовать другой компилятор и другой код непосредственно разговаривающий с железкой. Довольно удобно
Чисто технически, разворачивание и сворачивание это разные операции, скорее всего нужны отдельные приводы для этого, такую массу тащить на орбиту незачем, а на земле можно свернуть внешними приводами. Ну и в целом - сведение и выведение это очень разные процессы по перегрузкам. Для понимания - большую часть времени при создании подобных систем занимает тестирование - т.е. дешевле новый сделать чем спустить этот и потом опять подготовить к запуску.
Вообще предусмотрены. Для возможной дозаправки добавлены соответствующие клапаны, пассивный стыковочный механизм (простейший, по сути интерфейс с РБ) тоже есть. Всерьез, правда, никто не планировал... Подробней можно почитать тут
Другое дело, что в отличие от Хаббла никакая разборка на орбите с заменой внутренних деталей невозможна - там обслуживание было полноценной фичей, Хаббл делался как ПН для Шаттла в первую очередь
На самом деле скорость столкновения может быть почти какой угодно. Мусор может быть и на не-круговой орбите и на наклоненной на 180 градусов относительно орбиты космонавта - вариантов не так уж и мало. А объекты на той же орбите опасности не представляют вообще - относительная скорость почти никакая. 7км\с это ведь относительно Земли, а не относительно космонавта
https://tass.ru/kosmos/5360378
Уж не знаю зачем это конкретно, я не настоящий сварщик, видимо не всякая возможная орбита МКС подходит для быстрой схемы
Вы так говорите как будто это фишка Союза (корабля) хотя это в большей степени обеспечено расчетом баллистики и минимизацией "зазора" запуска РН. Ну и тем фактом что наклонение МКС подобрано именно под Байконур, и не факт что с какого-либо другого космодрома, кроме реально экваториальных (а не просто близких, как Канаверал), можно делать выкрутасы с ловлей МКС за 1-2 витка.
Это было бы очень странно, ведь то что делает телескоп первое время это обзоры, а обзоры имеет смысл делать в наиболее широком спектре, т.е. обоими телескопами. Можно вот тут почитать https://habr.com/ru/post/508760/
А потом сели мотать срок? У нас тут умудряются сесть и за журналистику в этой области, а "передать документацию по управлению" это несколько иной уровень
Срок активного существования у этого телескопа 6.5 лет, и несколько обзоров неба eROSITA уже собрала, так что мы не останемся совсем без ничего. Я думаю шанс на то что сотрудничество по фундаментальным наукам стабилизируется за следующие 3.5 года есть - ИТЕР же как-то продолжают строить. А шанс восстановить сломанный телескоп без знания как он устроен крайне низок. Включить они его наверное включат, но, как и во всем космическом - нет проблем с ситуацией когда все хорошо, главные проблемы возникают в ситуации когда хорошо не все, и вот режимы восстановления можно и не осилить.
Можно сколько угодно спорить о том стоило ли его выключать, фундаментальная наука она для всех. Но это дело тех, кто этим инструментом владеет. Впрочем, Роскосмосу не привыкать заниматься космическим пиратством.
Такие телескопы работают долгие годы - может лучше подождать пока отношения стабилизируются хоть чуть-чуть? С орбиты он никуда не денется, сломать всегда можно успеть, а чинить потом - как? Это не домашняя фотокамера с защитой от дурака, телескоп при неправильном обращении легко можно и спалить или, в лучшем случае, отправить в безопасный режим, а как его оттуда вытаскивать потом, методом тыка?
Желание даже всех ученых ЕКА недостаточно - нужна более конкретная информация о порядке восстановления и требуемых командах, а такую без явного и публичного разрешения никто не предоставит.
Это не то дело, которое "пробуют" - риск не оправдан, второго шанса может не быть.
Просто инженеры консервативны в оценках. Это как с марсоходами - гарантируют не меньше месяца работы, а караются потом годами сверх гарантированного срока.
Да и вообще, тут же речь про передовой научный инструмент! Большинство ключевых технологий в космосе в первый раз, было бы странно если бы предельные характеристики всех решений были точно известны заранее, ведь тогда бы он не был бы передовым, скорее рядовым, правильно?
Продлить ресурс конечно же можно, что-то можно поменять, что-то - просто перепроверить и уточнить ресурс, но это все равно дополнительные операции.
Все сильно зависит от аппарата. "Науке" не нужно было входить в атмосферу другой планеты на второй космической и мягко садиться. Некоторые модули "Казачка" вполне и не разборными могут быть, обслуживание-то не предполагалось.
У космических аппаратов все очень дорого, и потому очень точно рассчитано, считают даже километраж на дорогах - можно проехать не более N километров, иначе ресурс вибростойкости может пострадать слишком сильно, и аппарат может просто не пережить выведение. Предел по хранению может означать, например, предел стойкости конструктивных материалов к воздействию кислорода (в космосе и на Марсе с кислородом не оч, а значит можно использовать что-то более легкое, но менее стойкое к коррозии).
Пример с кислородом я взял из головы, но надеюсь идея понятна - необходимость оптимизировать конструкцию аппаратов до предела может вылезти в неожиданных местах.
Когда о таком говорят, то речь обычно не о близко расположенных участках, а об участках которые находятся буквально в одном здании. Причем если на таких участках мало наблюдателей, и они "правильные", то явка отличается на десятки процентов. Так же наблюдается интересная закономерность - чем выше на участке явка, тем более однообразно люди на участке голосуют - это и есть "хвост кометы", который объясняют вбросами. Собственно если отбрасывать все такие странные УИКи люди в нашей стане оказываются вполне себе однородными, по крайней мере без резких пиков на пустом месте.
Примеры были, выборы в дугих старанах, выборы РФ 2000
Выборы 2000 г
Явка в целом большая, но большая часть голосов, как ни удивительно, кучкуется в одной области. Посмотрим что было в 2016
2016
Чем больше людей приходит, тем более размазанным оказывается ядро. График в статье тоже выглядит интересно, не нем можно заметить регулярную сетку в верхней части графика:
Самое забавное что это не ошибка - это крайне похоже на результат "подгона" на участков результатов под конкретный процент. Похожую сетку можно увидеть на голосовании за поправку:
2020, голосование за поправку
Не знаю как вам, а мне такой способ поиска проблем кажется вполне убедительным. И он показывает что в среднем результаты по стране вполне себе монотонные, пусть на вашем примере какие-то участки и будут выделяться, но на масштабах страны с большей вероятностью будут выделятся именно проблемные участки. К сожалению, по данным текущей детализации (участок-процент за каждый пункт) более точной картины (чтоб отличить действительно странные участки) построить нельзя. Более интересны в этом смысле результаты электронного голосования, там можно выделить каждый отдельный голос, и отделить время голосования (с определенной, пусть и загрубленной точностью). Но это уже другая история
Картинки взяты отсюда
Ошибки тут нет, скорее передёргивание фактов от автора. По первоначальному плану самая первая рабочая конфигурация 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)