А как у этого решения с расшариванием принтера? Очередь печати с просмотром по сети из винды там можно организовать?
У меня под виндой такое. Для сканирования использую BlindScanner. Кнопки на сканере конечно не функционируют и надо просить в кого-то запустить сканирование по сети или самому бегать. Но для «много страниц» бегать не надо — можно задать кол-во страниц и паузу, для перекладывания. Ну и удобно, что каждый может сканировать прям к себе на компьютер.
Ну и как решать проблемы с моим принтером в приведенном в статье случае я не представляю. У меня Epson струйник с СНПЧ. И периодически он может отказаться печатать, потому что считает, что у него кончились чернила. В принципе это можно решить и не отходя от него в слепую, но догадаться какая именно у него проблема будет тяжело. Ну и там всякие прочистки сопел будут ли работать в линуксе?
Вообще не понятно из статьи зачем Backbone в NodeJS.
Нет мне то понятно. Я его и сам использую в связке с Backbone.Relational и модели на клиенте и сервере одинаковые(т.е. один и тот же файл с описанием моделей), только для сервера дополнительно расширяются, ну и sync на севрере и клиенте разный.
Но, мне кажется, в статье мало мотивационной части.
И зачем нужен fetchFromDB, если есть встроенный fetch, который обращается в sync? Ну ладно… для удобства, ну так и замкните его снова на sync. Зачем два раза писать одно и то же.
MK802 не работает нормально с переходником HDMI->DVI. Проблема в том что китайцы не стали делать поддержку HDMI по стандарту, а сделали как им удобней. Минимальная конфигурация HDMI предполагает поддержку цветовой кодировки RGB. MK802 дает только YPbPr, которая есть в стандарте HDMI. Но мониторы только со входом DVI как правило YPbPr не поддерживают, потому что ее нет в стандарте DVI.
Какая ситуация с UG007 надо тестировать. Верить на слово китайцам или обзорщикам, которые его в руках не держали не стоит.
Я уверен, что в базе имеет смысл хранить только, где какой контейнер находится (включая платформы роботов) — 1я таблица. Задачи на перемещение — 2 я таблица. Ну может конечно еще что то, но к управлению роботоми это не будет иметь отношения.
Не очень понятно что такое подсклады. Нельзя все логически объединить в одну систему? Или между подскладами ездят не роботы?
Блокировки пути — я не очень понимаю что это. Если это относится только к системе с роботами, то это должна быть какая то отдельная база, а может быть просто файл на диске?
Если это просто другой робот блокирует путь, то естественно это можно всегда высчитать по данным от оборудования. Зачем это хранить в базе?
Естественно у вас должна как-то хранится структура самого склада. Ну хорошо храните ее в базе. Но даже если ее хранить в базе, то система управления роботами может построить базовый граф на ее основе в удобном для работы формате и хранить его копию на диске.
У вас нет возможности восстановить состояние системы не прибегая к базе? Ну т.е. у вас нет возможности спросить у оборудования, где находится робот и есть ли на нем контейнер? Ну еще где находится, какой контейнер я еще поверю, что информация может быть только в базе. Но роботы то должны отслеживаться? По контейнерам информация должна быть в системе более высокого уровня. Не той которая управляет роботами. И это простая таблица — никаких состояний.
Ключевые слова очевидны - транспортная задача. Я не уверен на 100%, что это оно. Но уверен что эта задача уже кем то решалась и надо искать подходящую мат. модель.
Мне кажется вы смешали в кучу несколько задач. Вам надо их разделить и решать по-отдельности.
Я вижу такие:
1. Управление отдельным роботом — да автомат с состояниями, едем, стоим, переместились на ячейку N, заклинило в ячейке N.
2. Граф состояния склада — узлы — ячейки, или координаты — скорее всего не во всех координатах есть ячейки. Связи это возможность перемещения робота из одной координаты в другую. Граф перестраивается при поступлении новых данных. Например если робот остановился с ошибкой — граф перестраивается. В граф можно добавить узлы не связанные с координатами, а например узел, который отвечает за уборку мешающего робота.
3. Решение задачи оптимизации перемещения робота по графу. Робот перемещается по оптимальному пути, после его вычисления. Любое событие повлиявшее на граф и пересекающееся с узлами через которые проходит путь робота приводит к пересчету пути на новом графе. Впрочем условие пересечения это уже преждевременная оптимизация.
Может я и ошибаюсь, но к конечным автоматам это не имеет отношения. Нет т.е. конечно можно представить склад с ячейками как систему в определенном состоянии, а перемещение ячеек, как переход в другое состояние. Но на первый взгляд это транспортная задача, с известными методами решения. А у вас получился какой-то набор эвристик. Еще и Oracle… За ним же следить надо.
Интересно. на камере которая смотрит на землю просматривается область с прямыми углами, как поле. Но с такой высоты она должна быть огромной. И еще скорость относительно земли достигала 200Км/ч — нехилый такой ветерок.
У меня под виндой такое. Для сканирования использую BlindScanner. Кнопки на сканере конечно не функционируют и надо просить в кого-то запустить сканирование по сети или самому бегать. Но для «много страниц» бегать не надо — можно задать кол-во страниц и паузу, для перекладывания. Ну и удобно, что каждый может сканировать прям к себе на компьютер.
Ну и как решать проблемы с моим принтером в приведенном в статье случае я не представляю. У меня Epson струйник с СНПЧ. И периодически он может отказаться печатать, потому что считает, что у него кончились чернила. В принципе это можно решить и не отходя от него в слепую, но догадаться какая именно у него проблема будет тяжело. Ну и там всякие прочистки сопел будут ли работать в линуксе?
Пока не понял почему, но работает.
Нет мне то понятно. Я его и сам использую в связке с Backbone.Relational и модели на клиенте и сервере одинаковые(т.е. один и тот же файл с описанием моделей), только для сервера дополнительно расширяются, ну и sync на севрере и клиенте разный.
Но, мне кажется, в статье мало мотивационной части.
И зачем нужен fetchFromDB, если есть встроенный fetch, который обращается в sync? Ну ладно… для удобства, ну так и замкните его снова на sync. Зачем два раза писать одно и то же.
Какая ситуация с UG007 надо тестировать. Верить на слово китайцам или обзорщикам, которые его в руках не держали не стоит.
Не очень понятно что такое подсклады. Нельзя все логически объединить в одну систему? Или между подскладами ездят не роботы?
Блокировки пути — я не очень понимаю что это. Если это относится только к системе с роботами, то это должна быть какая то отдельная база, а может быть просто файл на диске?
Если это просто другой робот блокирует путь, то естественно это можно всегда высчитать по данным от оборудования. Зачем это хранить в базе?
Естественно у вас должна как-то хранится структура самого склада. Ну хорошо храните ее в базе. Но даже если ее хранить в базе, то система управления роботами может построить базовый граф на ее основе в удобном для работы формате и хранить его копию на диске.
Ключевые слова очевидны - транспортная задача. Я не уверен на 100%, что это оно. Но уверен что эта задача уже кем то решалась и надо искать подходящую мат. модель.
Мне кажется вы смешали в кучу несколько задач. Вам надо их разделить и решать по-отдельности.
Я вижу такие:
1. Управление отдельным роботом — да автомат с состояниями, едем, стоим, переместились на ячейку N, заклинило в ячейке N.
2. Граф состояния склада — узлы — ячейки, или координаты — скорее всего не во всех координатах есть ячейки. Связи это возможность перемещения робота из одной координаты в другую. Граф перестраивается при поступлении новых данных. Например если робот остановился с ошибкой — граф перестраивается. В граф можно добавить узлы не связанные с координатами, а например узел, который отвечает за уборку мешающего робота.
3. Решение задачи оптимизации перемещения робота по графу. Робот перемещается по оптимальному пути, после его вычисления. Любое событие повлиявшее на граф и пересекающееся с узлами через которые проходит путь робота приводит к пересчету пути на новом графе. Впрочем условие пересечения это уже преждевременная оптимизация.
Смысл делать похожее API, а не совместимое? Это только путает.
Что то у них давление на сайте не правильно показывает — внутри и снаружи одно и то же.В видео картинке показывали была разница.
Исправилось