Не могу пройти мимо, когда в интернете кто-то не прав. Я, к сожалению, испытал на себе язву 12-перстной кишки. Лечился сначала таблетками, естественно по назначению врача, естественно после всех необходимых анализов. Принимал как мог аккуратно: ставил будильники, чтобы съесть одну таблетку за 30 минут до еды, другую — 30 минут после еды. Принимал антибиотики от бактерий и еще несколько других препаратов. Результат: острое состояние удалось снять, но здоровым я себя не чувствовал. Пробовал повторять лечение, естественно, по назначению врача после сдачи анализов — результат не сильно лучше.
Пробовал диету. Диета помогает гораздо эффективнее. С диетой ты чувствуешь себя хорошо, а съешь что-то не то — боль, слабость, изжога и так далее. Опять же, диета оказалась достаточно неожиданной. Скажем, одним из самых вредных блюд оказался суп. Если внимательно почитать про стол номер 1, то выяснится, что нельзя бульон и нельзя капусту.
Пробовал спорт — можно до некоторой степени выменивать погрешность в диете на тренировку. Но самым эффективным оказалось немного похудеть...
Не утверждаю, что мой рецепт поможет всем. У кого-то, может быть, генетическая особенность, у кого-то сильное влияние внешних факторов. Но думаю, что если вы не имеете наследственных болезней и живете обычной жизнью, вас поставит на ноги на первых порах диета, а в долгосрочной перспективе — похудение и физкультура. А не таблетки.
Ну мой литий к моменту разряда уже соединен с кислородом. Лучше сбросить аккумулятор, чем упасть всему аппарату.
Впрочем, это, конечно, пока область фантазий, не стоит особых обсуждений.
Надо бы собрать кладбище разрекламированных, но загнувшихся идей.
1) Сегвей как убийца традиционных авто
2) Суборбительный космический туризм
3) Mars one
4) Google glass
5) Бытовая 3d-печать как массовое явление
6) Space Shuttle как убийца одноразовых ракет
7) Аэротакси как массовая услуга на основе мультикоптеров и прочих нетрадиционных ЛА
Мы не слишком далеко от фундаментальных ограничений, раза в два еще может быть, когда нибудь, химические источники тока и выдадут.
Предел эффективности химических источников тока ограничен примерно характеристиками бензобака с бензином. Это на порядок-другой больше, чем сейчас. То есть, тут есть куда расти.
Такой аккумулятор мог бы получиться, если бы химики нашли какое-то вещество, которое может соединяться с кислородом воздуха и давать ток, а при зарядке возвращать кислород. Да, аккумулятор бы тяжелел в процессе полета, но лишний вес на посадке не так критичен, как на взлете, а в аварийной ситуации разряженный потяжелевший аккумулятор можно сбросить.
Странно, что не упомянули вот такой работающий алгоритм:
После праздника, перед тем, как лечь спать, пьем много воды. 0.5 литра, или больше — сколько влезет.
Ночью просыпаемся от гидробудильника. Выполняем основную миссию, затем опять пьем воду, 0.5 литра или больше. Если данный пункт происходит несколько раз за ночь — так и хорошо.
Отлично. Но заявка должна браться не из хотения заявляющего, а с какого-то внешнего проекта, или из поручения топа. Вот эти 100500 от склада должны суммироваться в бюджет внешнего проекта, или в бюджет изначальной заявки. И в конце можно будет поднять вопрос эффективности работы отделов при выполнении изначальной задачи.
Рассказывали, как группа товарищей пыталась совместить кайт и манутинборд, катались по полям. Среднее время до обращения в медпункт составляло 5 минут.
Я посмотрел несколько роликов (не все). На тех, что я смотрел — робот выполнял действия совместно с человеком. Человек подавал штуку, робот ее брал, вертел, обрабатывал и возвращал назад. Думаю, что в таком сценарии робот не может заменить 2-3 рабочих. Чтобы робот смог заменить рабочего, его надо научить брать деталь из коробки, в которой деталь может лежать любым боком. Искать отвертку, которая куда-то завалилась, замазывать брак с предыдущего участка, за кружкой пива обсуждать с технологом, как бы оптимизировать процесс. И тут дело не в подшипниках…
В прочем, в этой области я теоретик. Было бы интересно услышать отзывы практиков.
Несколько лет назад написал пару статей в лурку. Скажу так: там никого не волнуют такие нюансы, как ссылки на авторитетные источники, и т.п. Текст должен быть увлекательным, текст не должен быть похож на выдумку или личное мнение. Текст должен быть про нечто более-менее на слуху. Этого достаточно.
Если напишешь что-то, что кто-нибудь может принять на свой счет и обидеться — удалят. Например, у меня из песни выкинули четверостишье. Я не встал на тропу войны правок, я заметил-то это через месяцы.
Вы немного не о том написали. Вы написали о бизнес сценарии «отмена турпоездки» или «изменение в планах поездки». Наша система тоже это умеет — надо заложить дополнительные правила по отмене ненужных действий. Система построит новый процесс, в котором будут шаги по отмене ненужных действий и совершению новых нужных (например, отменить бронирование гостиницы, забронировать яхту на эти же даты).
Но это просто дополнительные требования, которые могут быть, а могут и нет. Изначально я писал о том, что если произошла техническая ошибка (код выбросил исключение), то нет общего способа решить проблему без программиста. Предложили вариант откатиться на последнее ручное действие — это не подходит, т.к. отмена в общем случае не реализуема.
Пример. Процесс планирования турпоездки. Одно из действий — бронирование гостиницы — автоматизировано. Наша система посылает в систему бронирования запрос, система бронирования что-то отвечает. Внезапно интерфейс системы бронирования чуть-чуть поменяли, или решили забронировать какую-то нестандартную гостиницу. Ответ от системы бронирования пришел и был провалидирован, но на одном из дальнейших шагов (скажем, распечатка памятки для клиента) произошла системная ошибка — гостиница называлась корейскими иероглифами, для которых не нашлось шрифтов.
Автоматически подобные ошибки не решить: мы не знаем, какие шаги отменять. И как их правильно отменять. Если мы попробуем включить процесс «компенсации», то он тоже может упасть на каком-нибудь шаге вроде «распечатки квитанции об отмене».
По мне так должна быть одна система, в которой гармонично переплетаются PM/BPM/ACM. И далее выясняется, что ИС должна быть тесно интегрирована с ERP & CRM.
Как в известном анекдоте: «мышки, станьте ежиками».
Тут можно было бы сделать блокирвоку, что невалидная заявка не снимается с данного пользователя. Так и болтается в его списке задач. И еще продумать форму ввода адреса, чтобы не вбивали кривые адреса.
Ошибка может проявиться через много шагов после того, как были вбиты данные. Естественно, этого пытаются избежать, но мир не идеален и всякое бывает. Проблема еще и в том, что в том подходе, который описан в статье, задача отката не решается, если только специально не создавать точки отката. Впрочем, и с точками отката тоже не все ясно — ошибочный процесс мог поменять что-то вне своих локальных переменных — как это откатить?
Обычно путем декомпозиции, вынося участки схемы в подпроцессы, можно существенно улучшить понимаемость схем процессов. Если, например, бизнес-процесс состоит из 7 шагов, каждый из которых является подпроцессом, то на диаграмме процесса будет всего 7 элементов. Однако, при клике на любой из этих элементов, BPMS откроет схему этого подпроцесса. В случае четырех уровней вложенности для подпроцессов из 7 элементов, 4-ый уровень будет содержать 2401 задачу, при этом каждая схема будет состоять только из 7 элементов.
Для реальных бизнес-процессов, конечно, все не так просто. При декомпозиции надо учитывать не только количество элементов, но и бизнес-логику процесса. Но, в целом, путем декомпозиции понимаемость схем можно существенно улучшить.
У нас также использовались подпроцессы, все это было возможно. Однако я много раз смотрел товарищам через плечо и видел, как они скролят направо-налево и вверх-вниз какие-то змеиные кольца. С одной стороны, мир не идеален, и, если приложить усилия, наверняка можно было сделать процесс более читаемым. С другой стороны, эти люди не враги себе, наверняка есть большие сложности с тем, чтобы все упростить.
Но было бы интересно увидеть конкретные примеры с вашей стороны. В реальном решении, на сколько сложны бизнес-процессы?
Процессный подход не предназначен для решения таких задач. Для таких задач надо применять управление проектами. Для этого разработан другой класс программного обеспечения. Бизнес-процессы предполагают многократное выполнение одних и тех же цепочек действий. Проект предполагает однократное выполнение, контроль ресурсов, возможность существенного отличия фактических действий от плановых и т.п.
Из написанного можно сделать вывод, что процессы — это максимально упрощенная версия проектов.
«Проект предполагает однократное выполнение» — естественно, однократное выполнение не автоматизируется, но мой пример — строительство коттеджей по уникальным проектам — можно представить как процессы с вариабельными частями, либо типовые проекты. И это уже можно автоматизировать.
«контроль ресурсов» — тут не понял. При выполнении процесса легче легкого контролировать ресурсы. Как и другие показатели.
«возможность существенного отличия фактических действий от плановых» — что значит «существенного»? Если в процессе стоит ветвление по условию, это уже проект, или еще нет?
Компания, где я работаю, также занимается автоматизацией бизнес-процессов. Но это одно из направлений нашей деятельности, мы автоматизируем не все подряд процессы, а только некоторый подкласс, но все описанные вами нюансы у нас встречаются.
У нас тоже был модуль, работавший как ваш BPMS-движок. Там можно было рисовать в графике процессы, состоявшие из заданий, соединять их стрелочками, и т.д. — все как у вас. Мы даже это внедряли, но потом отказались от этого подхода. Почему:
1) Реальный процесс получался из десятков задач. Диаграмма занимала несколько экранов, ходила петлями и змейками — жуть.
2) Все проблемы с переиспользованием и версионированием, о которых в коментах уже говорили.
3) Если на каком-то шаге возникала программная ошибка, то процесс падал и без участия программиста не оживал. Ну как пример: пользователь вбил адрес в каком-то новом формате, о котором аналитики не подумали. Код свалился с ошибкой, процесс остановился — ждем программиста. В результате пара человек просто сидела на поддержке 100% времени, разбирая целыми днями эти ошибки.
Но самый большой гвоздь в крышку гроба был забит, когда пришел очередной заказчик, и выдвинул такие требования:
— Хочу, чтобы некоторые задачи в некотором конкретном процессе можно было отменять.
— А еще некоторые задачи мне хочется менять местами — опять же, в конкретном инстансе конкретного процесса. Ну вот попался такой особый случай — менеджер должен иметь возможность кое-что перепланировать.
— А еще бывает, что менеджеру хочется в некотором конкретном случае добавить несколько дополнительных задач.
Самое ужасное, что эти требования — нормальные, если речь идет о длительном процессе с уникальными особенностями. Представьте, что вы автоматизируете бизнес строительной компании, которая строит коттеджи по уникальным проектам. Для каждого участка строительства надо предусмотреть разное количество задач. Если эти задачи еще и делаются в параллели, то средствами BPMS это не решается никак.
В итоге сейчас в нашей компании есть средство, которому эта задача «по зубам». Я не знаю, до какой степени об этом можно рассказывать. В википедии навскидку похожего не нашел. Скажу только, что конкретный вид процесса каждый раз генерируется автоматически. Если кому-то интересно — попробую сделать статью об этом и опубликовать через корпоративный блог.
Статья интересная, но не раскрыт вопрос, что даст повышение температуры Северного Ледовитого океана? Мне вот не очевидно, что если его нагреть, то в Сибири и в Канаде сразу станет теплее. Даже если и так, то на сколько надо нагреть?
Есть такая штука — общая циркуляция атмосферы. Искал подробности — нагуглил http://www.iki.rssi.ru/books/2008astafieva1.pdf. Собственно, надо развернуть теплые воздушные потоки на территорию Восточной Сибири. Надо ли для этого греть Северный Ледовитый океан? А может наоборот, его стоит охладить? Может течения в Тихом Океане играют бОльшую роль? Не станет ли в Европе холодно после обогрева Сибири? Вот эти вопросы вызывают наибольший интерес. А уж что для этого делать — дамбу строить или углем посыпать снега — это уже следующий вопрос.
А можно среди всех этих остроумных комментариев оставить один занудный?
Если бы робот умел только выгружать посуду из раковины в посудомойку — он бы уже нашел свою рыночную нишу. Но что-то мне кажется, что он на такое не способен.
1) Вы заметили, что стакан изначально стоит перевернутый как надо, и на открытом месте? У меня в раковине стаканы лежат как попало, а еще там есть тарелки, ложки, кастрюли и иногда попадаются совсем странные вещи вроде разобранной мясорубки. Начнем с того, что лапа робота явно не сможет захватить все многообразие предметов — надо бы хотя бы 3 пальца, да еще и гибких, чтобы можно было обхватить предмет. Но это еще не все!
— Предмет надо выбрать из кучи других. Где пруф, что робот распознает чашку по ручке, торчащей из кастрюли с грязной водой?
— Вытаскивая предмет из раковины, надо не перебить остальную посуду. И не залить пол грязной водой из кастрюли.
— Посудомойка бывает заполнена — надо найти для предмета свободное место.
— Предмет надо правильно сориентировать в посудомойке. Вопрос может быть не тривиальным, например, для разобранной мясорубки. Если пользователь купил крафтовую чашечку (не из каталога Икеи), робот тоже должен уметь с ней управляться.
2) В принципе, для робота, который это все умел бы, ноги и необязательны. Это может быть рука, встроенная между посудомойкой и раковиной. Но концепт может перемещаться, и это сразу поднимает еще больше вопросов.
— Какой там вес у агрегата? 25 кг? А если он мне на ногу копытом наступит?
— У меня маленькие дети в квартире — что будет при столкновении робота с ребенком? А если ребенок полезет изучать робота, засунет палец в шарнир, а робот этого не заметит и побежит по своим делам?
— А если робот спутает какую-нибудь мою выступающую часть тела с посудой, схватит и потащит, пока я зазевался?
ИМХО роботы крупнее пылесоса — не для жилых помещений, на данном этапе развития техники.
Думаю, в Гугле это все тоже понимают, поэтому и спихивают данное подразделение под благовидным предлогом, пока есть желающие вложиться.
Причём если реактивной массой его заправить можно будет относительно просто, то ядерный реактор/солнечные батареи должны быть рассчитаны на весь срок его эксплуатации. А это значит, что чем эффективнее мы будем расходовать их энергию, тем больше рейсов такой буксир сможет сделать и тем больше грузов сможет доставить.
Да, но выше сравнивали КПД электрореактивного двигателя с КПД химического, который не потребляет ничего от реактора/батарей.
Вообще я расстроен низким уровнем дискуссии. На профильном форуме вспомнили бы проекты/концепты с теми или иными вводными. Например, можно сравнить полет зонда СМАРТ с традиционными АМС. Впечатляет разница в начальной массе, зато СМАРТ летел дольше. Если бы его двигатели при той же мощности работали с большим УИ, он бы, наверно, летел еще дольше, хотя затратил бы меньше рабочего тела. Очевидно, есть оптимум. И, очевидно, он будет разный при полетах к Луне и к Плутону. В автоматическом или пилотируемом режиме. Далее, наверняка есть куча проектов разных миссий на разных движках. Например, Энергия прорабатывала 2 проекта марсианских кораблей: на химическом топливе и на солнечных батареях + ЭРД. Описание, вроде, было на их сайте. Те, кто в теме, назовут таких проектов десяток. Интересно было бы сравнить по основным параметрам. Дальше начали бы обсуждать влияние гравитационных потерь и стратегии преодоления радиационных поясов.
Не могу пройти мимо, когда в интернете кто-то не прав. Я, к сожалению, испытал на себе язву 12-перстной кишки. Лечился сначала таблетками, естественно по назначению врача, естественно после всех необходимых анализов. Принимал как мог аккуратно: ставил будильники, чтобы съесть одну таблетку за 30 минут до еды, другую — 30 минут после еды. Принимал антибиотики от бактерий и еще несколько других препаратов. Результат: острое состояние удалось снять, но здоровым я себя не чувствовал. Пробовал повторять лечение, естественно, по назначению врача после сдачи анализов — результат не сильно лучше.
Пробовал диету. Диета помогает гораздо эффективнее. С диетой ты чувствуешь себя хорошо, а съешь что-то не то — боль, слабость, изжога и так далее. Опять же, диета оказалась достаточно неожиданной. Скажем, одним из самых вредных блюд оказался суп. Если внимательно почитать про стол номер 1, то выяснится, что нельзя бульон и нельзя капусту.
Пробовал спорт — можно до некоторой степени выменивать погрешность в диете на тренировку. Но самым эффективным оказалось немного похудеть...
Не утверждаю, что мой рецепт поможет всем. У кого-то, может быть, генетическая особенность, у кого-то сильное влияние внешних факторов. Но думаю, что если вы не имеете наследственных болезней и живете обычной жизнью, вас поставит на ноги на первых порах диета, а в долгосрочной перспективе — похудение и физкультура. А не таблетки.
Ну мой литий к моменту разряда уже соединен с кислородом. Лучше сбросить аккумулятор, чем упасть всему аппарату.
Впрочем, это, конечно, пока область фантазий, не стоит особых обсуждений.
Надо бы собрать кладбище разрекламированных, но загнувшихся идей.
1) Сегвей как убийца традиционных авто
2) Суборбительный космический туризм
3) Mars one
4) Google glass
5) Бытовая 3d-печать как массовое явление
6) Space Shuttle как убийца одноразовых ракет
7) Аэротакси как массовая услуга на основе мультикоптеров и прочих нетрадиционных ЛА
Кто еще что припомнит из этой же серии?
Предел эффективности химических источников тока ограничен примерно характеристиками бензобака с бензином. Это на порядок-другой больше, чем сейчас. То есть, тут есть куда расти.
Такой аккумулятор мог бы получиться, если бы химики нашли какое-то вещество, которое может соединяться с кислородом воздуха и давать ток, а при зарядке возвращать кислород. Да, аккумулятор бы тяжелел в процессе полета, но лишний вес на посадке не так критичен, как на взлете, а в аварийной ситуации разряженный потяжелевший аккумулятор можно сбросить.
Странно, что не упомянули вот такой работающий алгоритм:
После праздника, перед тем, как лечь спать, пьем много воды. 0.5 литра, или больше — сколько влезет.
Ночью просыпаемся от гидробудильника. Выполняем основную миссию, затем опять пьем воду, 0.5 литра или больше. Если данный пункт происходит несколько раз за ночь — так и хорошо.
Утром последствия почти не ощущаются.
В прочем, в этой области я теоретик. Было бы интересно услышать отзывы практиков.
Если напишешь что-то, что кто-нибудь может принять на свой счет и обидеться — удалят. Например, у меня из песни выкинули четверостишье. Я не встал на тропу войны правок, я заметил-то это через месяцы.
Но это просто дополнительные требования, которые могут быть, а могут и нет. Изначально я писал о том, что если произошла техническая ошибка (код выбросил исключение), то нет общего способа решить проблему без программиста. Предложили вариант откатиться на последнее ручное действие — это не подходит, т.к. отмена в общем случае не реализуема.
Пример. Процесс планирования турпоездки. Одно из действий — бронирование гостиницы — автоматизировано. Наша система посылает в систему бронирования запрос, система бронирования что-то отвечает. Внезапно интерфейс системы бронирования чуть-чуть поменяли, или решили забронировать какую-то нестандартную гостиницу. Ответ от системы бронирования пришел и был провалидирован, но на одном из дальнейших шагов (скажем, распечатка памятки для клиента) произошла системная ошибка — гостиница называлась корейскими иероглифами, для которых не нашлось шрифтов.
Автоматически подобные ошибки не решить: мы не знаем, какие шаги отменять. И как их правильно отменять. Если мы попробуем включить процесс «компенсации», то он тоже может упасть на каком-нибудь шаге вроде «распечатки квитанции об отмене».
Как в известном анекдоте: «мышки, станьте ежиками».
Ошибка может проявиться через много шагов после того, как были вбиты данные. Естественно, этого пытаются избежать, но мир не идеален и всякое бывает. Проблема еще и в том, что в том подходе, который описан в статье, задача отката не решается, если только специально не создавать точки отката. Впрочем, и с точками отката тоже не все ясно — ошибочный процесс мог поменять что-то вне своих локальных переменных — как это откатить?
У нас также использовались подпроцессы, все это было возможно. Однако я много раз смотрел товарищам через плечо и видел, как они скролят направо-налево и вверх-вниз какие-то змеиные кольца. С одной стороны, мир не идеален, и, если приложить усилия, наверняка можно было сделать процесс более читаемым. С другой стороны, эти люди не враги себе, наверняка есть большие сложности с тем, чтобы все упростить.
Но было бы интересно увидеть конкретные примеры с вашей стороны. В реальном решении, на сколько сложны бизнес-процессы?
Из написанного можно сделать вывод, что процессы — это максимально упрощенная версия проектов.
«Проект предполагает однократное выполнение» — естественно, однократное выполнение не автоматизируется, но мой пример — строительство коттеджей по уникальным проектам — можно представить как процессы с вариабельными частями, либо типовые проекты. И это уже можно автоматизировать.
«контроль ресурсов» — тут не понял. При выполнении процесса легче легкого контролировать ресурсы. Как и другие показатели.
«возможность существенного отличия фактических действий от плановых» — что значит «существенного»? Если в процессе стоит ветвление по условию, это уже проект, или еще нет?
Ну и т.д.
У нас тоже был модуль, работавший как ваш BPMS-движок. Там можно было рисовать в графике процессы, состоявшие из заданий, соединять их стрелочками, и т.д. — все как у вас. Мы даже это внедряли, но потом отказались от этого подхода. Почему:
1) Реальный процесс получался из десятков задач. Диаграмма занимала несколько экранов, ходила петлями и змейками — жуть.
2) Все проблемы с переиспользованием и версионированием, о которых в коментах уже говорили.
3) Если на каком-то шаге возникала программная ошибка, то процесс падал и без участия программиста не оживал. Ну как пример: пользователь вбил адрес в каком-то новом формате, о котором аналитики не подумали. Код свалился с ошибкой, процесс остановился — ждем программиста. В результате пара человек просто сидела на поддержке 100% времени, разбирая целыми днями эти ошибки.
Но самый большой гвоздь в крышку гроба был забит, когда пришел очередной заказчик, и выдвинул такие требования:
— Хочу, чтобы некоторые задачи в некотором конкретном процессе можно было отменять.
— А еще некоторые задачи мне хочется менять местами — опять же, в конкретном инстансе конкретного процесса. Ну вот попался такой особый случай — менеджер должен иметь возможность кое-что перепланировать.
— А еще бывает, что менеджеру хочется в некотором конкретном случае добавить несколько дополнительных задач.
Самое ужасное, что эти требования — нормальные, если речь идет о длительном процессе с уникальными особенностями. Представьте, что вы автоматизируете бизнес строительной компании, которая строит коттеджи по уникальным проектам. Для каждого участка строительства надо предусмотреть разное количество задач. Если эти задачи еще и делаются в параллели, то средствами BPMS это не решается никак.
В итоге сейчас в нашей компании есть средство, которому эта задача «по зубам». Я не знаю, до какой степени об этом можно рассказывать. В википедии навскидку похожего не нашел. Скажу только, что конкретный вид процесса каждый раз генерируется автоматически. Если кому-то интересно — попробую сделать статью об этом и опубликовать через корпоративный блог.
Есть такая штука — общая циркуляция атмосферы. Искал подробности — нагуглил http://www.iki.rssi.ru/books/2008astafieva1.pdf. Собственно, надо развернуть теплые воздушные потоки на территорию Восточной Сибири. Надо ли для этого греть Северный Ледовитый океан? А может наоборот, его стоит охладить? Может течения в Тихом Океане играют бОльшую роль? Не станет ли в Европе холодно после обогрева Сибири? Вот эти вопросы вызывают наибольший интерес. А уж что для этого делать — дамбу строить или углем посыпать снега — это уже следующий вопрос.
Если бы робот умел только выгружать посуду из раковины в посудомойку — он бы уже нашел свою рыночную нишу. Но что-то мне кажется, что он на такое не способен.
1) Вы заметили, что стакан изначально стоит перевернутый как надо, и на открытом месте? У меня в раковине стаканы лежат как попало, а еще там есть тарелки, ложки, кастрюли и иногда попадаются совсем странные вещи вроде разобранной мясорубки. Начнем с того, что лапа робота явно не сможет захватить все многообразие предметов — надо бы хотя бы 3 пальца, да еще и гибких, чтобы можно было обхватить предмет. Но это еще не все!
— Предмет надо выбрать из кучи других. Где пруф, что робот распознает чашку по ручке, торчащей из кастрюли с грязной водой?
— Вытаскивая предмет из раковины, надо не перебить остальную посуду. И не залить пол грязной водой из кастрюли.
— Посудомойка бывает заполнена — надо найти для предмета свободное место.
— Предмет надо правильно сориентировать в посудомойке. Вопрос может быть не тривиальным, например, для разобранной мясорубки. Если пользователь купил крафтовую чашечку (не из каталога Икеи), робот тоже должен уметь с ней управляться.
2) В принципе, для робота, который это все умел бы, ноги и необязательны. Это может быть рука, встроенная между посудомойкой и раковиной. Но концепт может перемещаться, и это сразу поднимает еще больше вопросов.
— Какой там вес у агрегата? 25 кг? А если он мне на ногу копытом наступит?
— У меня маленькие дети в квартире — что будет при столкновении робота с ребенком? А если ребенок полезет изучать робота, засунет палец в шарнир, а робот этого не заметит и побежит по своим делам?
— А если робот спутает какую-нибудь мою выступающую часть тела с посудой, схватит и потащит, пока я зазевался?
ИМХО роботы крупнее пылесоса — не для жилых помещений, на данном этапе развития техники.
Думаю, в Гугле это все тоже понимают, поэтому и спихивают данное подразделение под благовидным предлогом, пока есть желающие вложиться.
Да, но выше сравнивали КПД электрореактивного двигателя с КПД химического, который не потребляет ничего от реактора/батарей.
Вообще я расстроен низким уровнем дискуссии. На профильном форуме вспомнили бы проекты/концепты с теми или иными вводными. Например, можно сравнить полет зонда СМАРТ с традиционными АМС. Впечатляет разница в начальной массе, зато СМАРТ летел дольше. Если бы его двигатели при той же мощности работали с большим УИ, он бы, наверно, летел еще дольше, хотя затратил бы меньше рабочего тела. Очевидно, есть оптимум. И, очевидно, он будет разный при полетах к Луне и к Плутону. В автоматическом или пилотируемом режиме. Далее, наверняка есть куча проектов разных миссий на разных движках. Например, Энергия прорабатывала 2 проекта марсианских кораблей: на химическом топливе и на солнечных батареях + ЭРД. Описание, вроде, было на их сайте. Те, кто в теме, назовут таких проектов десяток. Интересно было бы сравнить по основным параметрам. Дальше начали бы обсуждать влияние гравитационных потерь и стратегии преодоления радиационных поясов.
Понятие КПД можно определить по-разному. Мне кажется, при данном определении КПД, высокое значение КПД не означает меньших затрат.