Кстати, интересно. Не могу избавиться от мыслей о технической возможности снимать ЭКГ с помощью двух беспроводных браслетов.
Та ещё задачка на самом деле.
Если ЭКГ — это измерение разности потенциалов, значит можно попробовать измерять её встроив тело в распределенный колебательный контур.
Что если подвесить в браслетах две ёмкости (ионисторы?), и очень синхронно толкать электроны в руку и обратно. Наверно туда, где электронный потенциал выше, их заталкивать будет сложнее?
И ещё по аналогиям… Вот у нас две бочки с разными давлениями газа. Если их соединить трубой, то можно мерять скорость ветра (ток) в трубе, чтобы определить разность давлений (потенциалов). В принципе того же можно добиться изолированными датчиками диф-давления с эталонными емкостями.
1. В 1 робота закладывают программу взрывов, смоделированных на симуляторе (робот-минёр)
У нас нет и близко похожих программ с достаточной степенью автономности по обмеру геометрии полостей, по навигации и перемещению в пещерах и выработках сложной формы. Делать их очень дорого и пока что на Земле нет других отраслей, где такие разработки могут пригодиться и при этом будут рентабельны.
2. В другого робота закладывают программу распознавания камней и их эвакуации из зоны производства взрывов (на основе ультразвукового обследования пространства).
То же, что и в первом пункте. У нас нет софта для автономного ориентирования, перемещения и манипулирования объектами в столь сложных средах. Тут нет ничего невозможного, но манипуляция мешками на порядки проще и я расскажу об этом подробнее ниже.
3. Разрабатывают сценарий их совместной работы на основе поочерёдного захода в рабочую зону.
Ну сложно же! Автономное сложное взаимодействие в сложной среде при необходимости обеспечивать связь через множественные ретрансляторы…
Это чертовски дорого разработать и мало где можно повторно эффективно применить. Отправлять в космос тяжести дорого, но разрабатывать технологии, испытывать их строить уникальных сложных роботов — это все очень дорого.
В постскриптуме вы сами обо всём этом сказали — про дороговизну и неэффективность таких разработок.
Но нам торопиться пока некуда, да и заброска на Марс любого оборудования обходится нам " в копеечку". А роботы — это самая лёгкая полезная нагрузка, чем предложенные вами устройства паковки и укладывания мешков!
Устройство паковки мешков — это тоже своего рода робот. И по устройству он гораздо проще и надежнее ваших сапёров и киберкамнетаскателей.
Дело в том, что для навигации в сложной среде нужно много лидаров, камер, манипуляторов, тактильных сенсоров, буров, ковшов, молотков, захватов и прочих инструментов. Всё это нужно резервировать и питать энергией. У ваших роботов для манипуляций инструментами и породой в пространстве должно быть огромное количество степеней свободы.
Это уже не лёгкие роботы и они очень-очень сложные не только программно и аппаратно, но и конструктивно.
К тому же вы забыли про то, что перед обустройством пещер нужно произвести их разведку, а это также нетривиальная задача.
А ещё иногда нужно не только убирать породу там, где она не нужна, но и формировать стены и перегородки там, где они нужны. И тут наши сапёры-спелеологи ничего предложить не могут. Разве что они еще и каменщиками будут?
С другой стороны, устройство для сбора грунта — это своего рода большой робот-пылесос. Таких роботов можно делать много одинаковых (масштабирование, удешевление).
Устройство для наполнения мешков можно сделать стационарным. Там будет перегрузочный бункер для грунта, шнековая система с насыпной горловиной и простой механизм подачи и отрезания рукава. Плюс конвейер для мешков. Всё это максимально просто и программно и конструктивно.
Укладывание мешков, как я выше писал, делает даже не робот, а механизированный легкий каркасный подъёмный кран с тремя лебедками. Самое сложное — это развертывание трёх штанг на шарнирах с полиспастами и укрепление опор в грунте. На относительно ровном, заметьте, предварительно выбранном со спутника участке местности. Никакой проблемы со связью, с логистикой (на равнине же), с подводом энергии (можно сделать замену аккумулятора у «пылесосов» при «сдаче» грунта насыпному заводу. Питание от ядерного реактора или поля солнечных батарей по проводам на поверхности.
Все эти механизмы на порядки проще, легче и надежнее роботов-шахтеров-спелеологов.
Я не утверждаю, что использование пещер — это тупиковый вариант, я всего лишь хочу сказать, что изложенный мной сценарий на порядок проще и до первых людей на Марсе его воплотить будет вполне реально.
Да, вы правы, всегда можно погрузиться еще глубже. Мне кажется, что осваивать такие вещи новичкам нужно поэтапно. Выделить начальные этапы так, чтобы их описание не вводило в заблуждение при погружении в более глубокие слои — это искусство преподавания.
Является. Если кто-то и нарушит эти принципы, то это будет программист. Он это сделает либо нарочно, а значит это его дело, либо нечаянно — такие ошибки надо искать линтерами. Просто питон не налагает лишних ограничений и не разводит бюрократию. Это позволяет ему быть лаконичным и простым.
Мне кажется об этом правильнее рассказывать по-другому.
1. У объекта могут быть атрибуты.
2. Класс — это тоже объект.
3. При обращении к атрибуту объекта (через точку или getattr) поиск происходит сначала в контексте самого объекта, потом в контексте его классов.
4. Запись атрибута происходит в контекст самого объекта.
Да. Есть специальный оператор `def` для определения функций. Когда он выполняется, тогда и вычисляются выражения в описании аргументов. То же самое с классами.
Странно, что не дали скачать трек и не показали его на карте, чтобы все могли убедиться в честности, а так же прикинуть насколько кто промахнулся со своими прогнозами.
Пардон. Имел в виду «в реальном времени». В автоматическом режиме не нужно. согласен, достаточно автоматизированного. Но управление нужно в реальном времени. Нельзя сейчас в среде такой сложности и в системе с таким числом степеней свободы управлять не в реальном времени. Задержки сигнала сделают процесс управления недопустимо медленным.
Лаг длиною до 40 минут. Всё управление должно быть программным. Сейчас только марсоходы недавно научились в таком режиме работать. Но там задача плоская и относительно легко поддается формальному описанию. В объёме мы такое делать не умеем.
И как? Появились уже?
Вообще интересная задача — бот выживальщик по-честному. Ну ок, пусть он не анализирует отрендеренную картинку, как человек, но можно ему хотя бы отдавать через API только те блоки, которые видно с его позиции «глазами». Та ещё задачка — сделать натурально ведущего себя бота в таком открытом мире.
Не только так. Повторно — это значит, что полностью аналогичные модули будут использованы в других миссиях и проектах. Когда компоненты разрабатываются и производятся штучно, они очень дороги по определению. Любое массовое производство удешевит конечный продукт. Унификация, стандартизация и модульность — залог ремонтопригодности, эффективности и надежности.
Всё это давно на земле делают роботы: роботы-минёры ( у них есть манипулятор и скребки, которые выдерживают даже взрыв, могут буксировать большие камни), а бурят и изучают грунт — Луноходы и Марсоходы! (я уже писал про это).
Похоже вы совершенно не разбираетесь в теме.
Ключевая моя фраза:
Всё это в автоматическом режиме мы делать не умеем».
Именно в автоматическом режиме не умеем. Автоматизированные системы у нас есть, но сейчас нет роботов, которые САМИ находят камни и сами находят место где бурить, сами подъезжают и сами бурят. В том-то и проблема. И вся эта горнопроходческая деятельность в десятки, а-то и сотни раз сложнее, чем то, что я описал про мешки.
Все просто. Если воспользуетесь ленивыми булевыми операциями, вы не сможете отличить пустую строку от пустого списка, нуля или None. В некоторых случаях это вполне допустимо и на мой взгляд читается гораздо проще, чем тернарный оператор ( if else ).
item = (
items and item[0]
or can_use_others and other_items and other_items[0]
or default
)
Представьте себе такое выражение с тернарными операторами.
С другой стороны если развернуть это в блок кода, то будет читабельнее, с третьей стороны в лямбде блок кода не употребишь.
Судя по «трюкам» в этой статье не все поймут вашего сарказма в этом месте.
Поясню. Не стоило в конструкторе делать копирование. Литералы [], {}, () и т.д. идентичны соответствующим выражениям: list(), dict(), tuple().
Тело объявления класса выполняется один раз при первом импорте модуля или при запуске программы, если это __main__. Если вы употребите литерал [] или вызов list() в конструкторе, то список будет инициализироваться при каждом вызове конструктора. Кстати, __init__ — это, строго говоря, не конструктор. В питоне конструктор — это __new__. Это я так… на всякий случай.
Кстати о списках и прочих mutable объектах в классовых переменных. Это бывает полезно, если мы хотим без использования метаклассов реализовать класс, который будет «знать» все свои инстансы. Он просто будет сохранять их в свою коллекцию на классовом уровне.
А мне вот не понятно почему в настройках цветовой схемы никто еще не додумался делать кроме обычного дерева с селекторами цветов еще и фильтры как в графических редакторах? Часто хочется какую-то стандартную тему, но чуть контрастнее или чуть менее Saturated или чуть зеленее по Hue…
Да, наверно у нас возникло недопонимание.
Имелось в виду использование мешков как несущих элементов конструкции стен и куполов. Вот более релевантные картинки:
Та ещё задачка на самом деле.
Если ЭКГ — это измерение разности потенциалов, значит можно попробовать измерять её встроив тело в распределенный колебательный контур.
Что если подвесить в браслетах две ёмкости (ионисторы?), и очень синхронно толкать электроны в руку и обратно. Наверно туда, где электронный потенциал выше, их заталкивать будет сложнее?
И ещё по аналогиям… Вот у нас две бочки с разными давлениями газа. Если их соединить трубой, то можно мерять скорость ветра (ток) в трубе, чтобы определить разность давлений (потенциалов). В принципе того же можно добиться изолированными датчиками диф-давления с эталонными емкостями.
У нас нет и близко похожих программ с достаточной степенью автономности по обмеру геометрии полостей, по навигации и перемещению в пещерах и выработках сложной формы. Делать их очень дорого и пока что на Земле нет других отраслей, где такие разработки могут пригодиться и при этом будут рентабельны.
То же, что и в первом пункте. У нас нет софта для автономного ориентирования, перемещения и манипулирования объектами в столь сложных средах. Тут нет ничего невозможного, но манипуляция мешками на порядки проще и я расскажу об этом подробнее ниже.
Ну сложно же! Автономное сложное взаимодействие в сложной среде при необходимости обеспечивать связь через множественные ретрансляторы…
Это чертовски дорого разработать и мало где можно повторно эффективно применить. Отправлять в космос тяжести дорого, но разрабатывать технологии, испытывать их строить уникальных сложных роботов — это все очень дорого.
В постскриптуме вы сами обо всём этом сказали — про дороговизну и неэффективность таких разработок.
Устройство паковки мешков — это тоже своего рода робот. И по устройству он гораздо проще и надежнее ваших сапёров и киберкамнетаскателей.
Дело в том, что для навигации в сложной среде нужно много лидаров, камер, манипуляторов, тактильных сенсоров, буров, ковшов, молотков, захватов и прочих инструментов. Всё это нужно резервировать и питать энергией. У ваших роботов для манипуляций инструментами и породой в пространстве должно быть огромное количество степеней свободы.
Это уже не лёгкие роботы и они очень-очень сложные не только программно и аппаратно, но и конструктивно.
К тому же вы забыли про то, что перед обустройством пещер нужно произвести их разведку, а это также нетривиальная задача.
А ещё иногда нужно не только убирать породу там, где она не нужна, но и формировать стены и перегородки там, где они нужны. И тут наши сапёры-спелеологи ничего предложить не могут. Разве что они еще и каменщиками будут?
С другой стороны, устройство для сбора грунта — это своего рода большой робот-пылесос. Таких роботов можно делать много одинаковых (масштабирование, удешевление).
Устройство для наполнения мешков можно сделать стационарным. Там будет перегрузочный бункер для грунта, шнековая система с насыпной горловиной и простой механизм подачи и отрезания рукава. Плюс конвейер для мешков. Всё это максимально просто и программно и конструктивно.
Укладывание мешков, как я выше писал, делает даже не робот, а механизированный легкий каркасный подъёмный кран с тремя лебедками. Самое сложное — это развертывание трёх штанг на шарнирах с полиспастами и укрепление опор в грунте. На относительно ровном, заметьте, предварительно выбранном со спутника участке местности. Никакой проблемы со связью, с логистикой (на равнине же), с подводом энергии (можно сделать замену аккумулятора у «пылесосов» при «сдаче» грунта насыпному заводу. Питание от ядерного реактора или поля солнечных батарей по проводам на поверхности.
Все эти механизмы на порядки проще, легче и надежнее роботов-шахтеров-спелеологов.
Я не утверждаю, что использование пещер — это тупиковый вариант, я всего лишь хочу сказать, что изложенный мной сценарий на порядок проще и до первых людей на Марсе его воплотить будет вполне реально.
1. У объекта могут быть атрибуты.
2. Класс — это тоже объект.
3. При обращении к атрибуту объекта (через точку или getattr) поиск происходит сначала в контексте самого объекта, потом в контексте его классов.
4. Запись атрибута происходит в контекст самого объекта.
Лаг длиною до 40 минут. Всё управление должно быть программным. Сейчас только марсоходы недавно научились в таком режиме работать. Но там задача плоская и относительно легко поддается формальному описанию. В объёме мы такое делать не умеем.
Вообще интересная задача — бот выживальщик по-честному. Ну ок, пусть он не анализирует отрендеренную картинку, как человек, но можно ему хотя бы отдавать через API только те блоки, которые видно с его позиции «глазами». Та ещё задачка — сделать натурально ведущего себя бота в таком открытом мире.
Похоже вы совершенно не разбираетесь в теме.
Ключевая моя фраза:
Именно в автоматическом режиме не умеем. Автоматизированные системы у нас есть, но сейчас нет роботов, которые САМИ находят камни и сами находят место где бурить, сами подъезжают и сами бурят. В том-то и проблема. И вся эта горнопроходческая деятельность в десятки, а-то и сотни раз сложнее, чем то, что я описал про мешки.
Представьте себе такое выражение с тернарными операторами.
С другой стороны если развернуть это в блок кода, то будет читабельнее, с третьей стороны в лямбде блок кода не употребишь.
Судя по «трюкам» в этой статье не все поймут вашего сарказма в этом месте.
Поясню. Не стоило в конструкторе делать копирование. Литералы [], {}, () и т.д. идентичны соответствующим выражениям: list(), dict(), tuple().
Тело объявления класса выполняется один раз при первом импорте модуля или при запуске программы, если это __main__. Если вы употребите литерал [] или вызов list() в конструкторе, то список будет инициализироваться при каждом вызове конструктора. Кстати, __init__ — это, строго говоря, не конструктор. В питоне конструктор — это __new__. Это я так… на всякий случай.
Кстати о списках и прочих mutable объектах в классовых переменных. Это бывает полезно, если мы хотим без использования метаклассов реализовать класс, который будет «знать» все свои инстансы. Он просто будет сохранять их в свою коллекцию на классовом уровне.
Имелось в виду использование мешков как несущих элементов конструкции стен и куполов. Вот более релевантные картинки: