jammer312

Про включение микроконтроллеров компьютерами знаю, здесь оно не используется из-за того, что нет возможности определить, относится ли микроконтроллер к ячейке или нет. Использование прямого включения в качестве запасного варианта делает нежелательным установку gps ячейки (точнее, ее контроллера) вплотную в другим микроконтроллерам, ибо и при первоначальном включении, и в случае форсмажора, из-за которого один из микроконтроллеров ячейки не проснулся, может включиться лишний микроконтроллер (вред этого варьируется в зависимости от назначения этого микроконтроллера). Могу сделать дополнительную версию, включающую подобный функционал, но имхо овчинка выделки не стоит (3 лишних прожатия пкм при постройке погоды не сделают). Захардкоженный порт поправил, поле переименовал, `ok` сделал локальной. Про объявление локальных переменных, использующихся один раз - мне кажется, их использование положительно влияет на читаемость кода, при этом потери от их объявления минимальны (емнип, луа держит локальные переменные на стеке, а может даже (некоторые) на регистрах, ну и оптимизаций при компиляции никто не отменял; даже если ничего из этого не выполняется, все равно упомянутые потери несоизмеримо малы по сравнению с временем работы компонентов). В частности, то, что `setWakeMessage` возвращает старое значение, мне не кажется очевидным, к тому же вики умалчивает об этом.

Суть упрощенных вычислений - в прошлой реализации я решал СЛУ методом крамера, а там много умножений. В этой реализации я пользуюсь геометрией системы: Будем искать относительные координаты цели. Относительные координаты контроллера - (0, 0, 0), 3 микроконтроллеров - (+-1, 0, 0), ... ,(0, 0, +-1). Вместо решения той системы (подробно об этом в прошлой теме) из 3 уравнений, будем решать систему из других трех уравнений, конкретно получаемых вычитанием из первого уравнения предшествующей системы второго, третьего и четвертого. Из-за особого вида координат контроллера и микроконтроллеров уравнения получаются вида x_i * (2x - x_i) = d_0^2 - d_i^2 (d_0 - расстояние до контроллера, d_i - расстояние до микроконтроллера, у которого i-я координата не ноль, x_i - ровно эта i-я координата) и из них весьма тривиально выражаются x, y и z. Для получения относительных координат контроллеров пользуемся способностью микроконтроллеров "закрывать" стороны, чтобы через них не отправлялись проводные сообщений. Стороны у него не относительные (перед-зад), а абсолютные (юг-север). Собственно, на этапе конфигурации каждый микроконтроллер отправляет в каждую сторону (кроме лицевой, ибо на ней он крашится, но т.к. делает он это через pcall, все окей) сообщение, контроллер же ловит их и запоминает, с какой стороны пришло. Ну и как обычно, важное уточнение, подобный жпс дает координаты с точностью до блока, ибо события модема дают расстояние именно до блока, а не до entity, от которой пришло сообщение.

Я уже закидывал сюда похожую прогу года три назад, но она кривая-косая, не очень надежная, ну и геморная в плане развертки. Эта версия более компактная (и простая в постройке), использует упрощенные вычисления и более эффективный механизм передачи сообщения меж компонентами; помимо этого используются особенности микроконтроллеров для автоматической конфигурации системы. Код в репозитории, для контроллера и периферии. Для постройки одного модуля нужно 3 микроконтроллера второго уровня и один компьютер второго уровня, начинка одинаковая, в каждом нужен процессор, плата оперативной памяти и беспроводная плата второго уровня. Операционная система на компьютер не нужна. В данном контексте компьютер будет контроллером, микроконтроллеры - периферией. Код для них пишется на eeprom. Помимо кода на eeprom можно записать параметры работы (в сегмент данных), для периферии это просто одно число - порт, на котором ожидаются запросы, для контроллера эта строка вида "port: \d+, key: \w+, anchor: \{-?\d, -?\d, -?\d\}", в ней записаны порт, на котором ожидаются запросы и с которого отправляются ответы, ключ-пароль (для настройки координат через беспроводные сообщения, об этом потом), а также якорь - координаты компьютера. По умолчанию используется 312 порт, ключ-пароль admin, и координаты {0, 0, 0}. Схема постройки простая, нужно установить где-либо компьютер-контроллер, а потом вплотную к трем его сторонам установить микроконтроллеры-периферию, при этом не должно быть такого, что контроллер расположен между двумя периферийными микроконтроллерами (если с одной стороны есть микроконтроллер, на противоположную ставить нельзя). Помимо этого лицевые стороны микроконтроллеров (одна из 6 сторон имеет иную картинку, и, что важно, к ней не присоединяются провода) не должны смотреть на контроллер. После постройки нужно единожды включить каждый из 4 компонентов, они при этом сами быстро выключатся. Это нужно для настройки модема, для того, чтобы компонент просыпался при получении определенного сообщения. После этого система уже готова к работе, но при этом не знает (если это не было заранее записано в сегмент данных eeprom контроллера) своих координат, и будет отвечать на все запросы относительными. Для включения системы достаточно отправить сообщение "gps_wake", при этом система запустится, сконфигурируется, и после этого отброадкастит сообщение "gps_ready". Такое же сообщение, но на адрес того, от кого пришло "gps_wake", отправится в случае, если система уже активна на момент получения запроса. Для того, чтобы сообщить координаты контроллеру, нужно отправить сообщение "gps_anchor", после которого идет ключ-пароль (записан в сегменте данных eeprom контроллера), после которого идут координаты (3 числа) контроллера. Координаты при этом запишутся на eeprom, т.е. при выключении-включении они все так же будут известны контроллеру. Для использования системы достаточно отброадкастить "gps_request", контроллер ответит (именно тому, от кого запрос) сообщением "gps_response", после которого идут 3 числа - координаты x, y, z. Таймаут обработки запроса - 1 секунда, если вдруг 1 секунда прошла, а ответа не пришло - что-то не так. При этом контроллер при таймауте запроса забывает все его данные, поэтому кривой запрос (например, отправленный сквозь толстую стену, которая снизила мощность сигнала настолько, что он дошел лишь до части системы) не будет "портить" последующие. Имеет смысл "включить" систему перед первым запросом (послать "gps_wake" и дождаться ответа "gps_ready"), на непосредственно включение уйдет до примерно 2 секунд (вообще с потолка взял, на деле должно шустрее, но внутри таймаут привязки стоит именно 2 секунды, после этого он отправляет 3 сообщения периферии и посылает сообщение о готовности), включенная же сразу ответит. Картинка для референса:

Кажется, я нашел, в чем проблема. Когда робот идет по координатам, он сначала поворачивается, потом идет вперед, пока не дойдет до нужной координаты. Все бы хорошо... НО. На каждом шагу (на самом деле каждые 32) робот проверяет разные параметры, и, если ими не доволен, возвращается домой, потом возвращается обратно на те же координаты, при этом не учитывая своей ориентации. Если он это сделал в середине пути, он может после возвращения быть повернут не туда, и переть не в ту сторону, все так же ожидая достижения нужной координаты, которой он никогда не достигнет. Лечится добавлением запоминания направления туда же, где в home запоминаются координаты, и добавлением smart_turn на это направление после возвращения на эти координаты.

Исправляется простым добавлением аргумента к сортировщику (и задание оного при вызове в функции возвращения домой), при задании которого он не проверяет инвентарь. Помимо упомянутого - я не вижу тут прекращения работы (он говорит, что завершил работу, и по идее прется дальше). Он у меня уже убежал весьма далеко (выкопав длинный туннель без ответвлений), не уверен, из-за чего так, завершение работы прикручу и еще посмотрю, будет ли он еще так делать. P.S. Завершение работы нашел, робот снова убежал далеко (но потом вернулся), пока неясно, почему.

Может, это я чайник, но теперь у вас робот при возвращении домой пакует ресурсы (вызывает сортировщик ДО выгрузки), проверяет инвентарь (вызывает в конце сортировщика), видит, что инвентарь полон, возвращается домой... Иными словами, циклится.

Не уверен, насколько эффективно и верно предлагаемое, но оно весьма просто. Ну и я на практике не проверял, это просто на ходу придуманный вариант. Сначала надо выяснить, какое максимальное целое число можно хранить в переменной в луа без потери точности, пусть это будет N, тогда n=sqrt(N) (округленное вниз). Длинное число реализуем как индексированную таблицу произвольной длины, в которой в каждой ячейке хранится число от 0 до n, сие есть запись числа в позиционной системе счисления по основанию n+1. Тогда операции можно реализовать по аналогии с сложением/вычитанием/делением/умножением столбиком (с учетом того, что система счисления уже не десятичная, конечно же), при этом операции над разрядами - просто арифметические операторы луа. Выбор основания гарантирует, что при сложении, вычитании и умножении разрядов переполнения или потери точности не будет. Взятие остатка от деления можно реализовать через деление, умножение и вычитание (ессно целочисленное) (a%b = a-(a/b)*b). P.S. Основание у системы счисления выбрано согласно двум соображениям: 1. оно должно быть как можно больше, чтобы кол-во разрядов, а следовательно - кол-во операций при умножении и делении, было как можно меньше; 2. оно должно быть таким, чтобы при самой "опасной" операции - умножении - не происходило потери точности (ну или переполнения, будь в луа целочисленная арифметика). Ну и "какое максимальное целое число можно хранить в переменной в луа без потери точности" сформулировано немного некорректно, я имел ввиду такое число N, что все числа от 0 до N представимы в переменной. Скорее всего с этой оценкой я переосторожничал, но лучше недооценить, чем переоценить.

Ввиду отсутствия адекватных хранилищ для жидкости на сборке эвила, чей-то вопрос о способах хранения больших объемов жидкости привел к такой весьма странной идее. Предлагаемое - цистерна емкостью до 65536 ведер жидкости, что достигается связкой цистерны из мода EnderStorage с компом. Но у оной связки есть одна существенная проблема, о которой напишу в конце поста. Концепт - цистерна настроена на некий цвет, хранит некую жидкость; если в цистерне кончается жидкость, она переключается на другой цвет, в цистерне с которым жидкость есть; если же цистерна заполняется - переключается на "пустой" цвет. Вот простая реализация, которая работает (не проверял, но должна) как на ОпенОС, так и на чистой прошивке: https://pastebin.com/2V1qY4LH В начале проги три параметра, первые два задают области частот (на каких цветах цистерна может хранить жидкость), третий - задержку меж обновлениями цистерны (проверкой и переключением на цвета). Для работы нужен комп с подключенным к нему адаптером, стоящим вплотную к цистерне. Работает согласно описаному концепту. Защиты от дурака особо не содержит, разве что ограничение диапазона частот (нижняя граница взята "с потолка", но наверняка верная, верхнюю искал бинпоиском (последняя не рантаймящая)(да, мне лень было считать кол-во цветов и возводить в куб)) Преимущества: 1. Весьма дешевая 4-блоковая цистерна емкостью в 65536 ведра (можно меньше). 2. Неужто вам первого пункта не хватило? Оная цистерна может находиться в нескольких местах сразу, а также легко перемещаема, что существенно, например, при осушении незера. Недостатки: 1. Задержка меж обновлениями. Если у вас нечто, что люто быстро забирает или заливает жидкость, скорость оного будет ограничена скоростью компа. 2. "Дребезжание" на границах. Если цистерна заполнена, она будет переключаться меж эти "заполненным" цветом и следующим "пустым", что может немного задержать доступ к жидкости (когда надо выкачать, а оно "прыгнуло" в "пустой" цвет, например). Я не придумал умного способа это отлавливать, но можно придумать внешнее средство контроля (которое в этом неопределенном случае определяет состояние), или захардкодить определенный выбор. Но текущий вариант позволяет без вспомогательных конструкций и забирать, и доливать жидкость, пусть и с небольшой задержкой. 3. Возможные приколы при использовании нескольких таких канистр на пересекающихся диапазонах (например, когда из состояния неопределенности из-за небольшого рассинхрона одна канистра ушла на следующий цвет и в нее долили, а из другой в то же время забрали, и они рассинхронизировались меж собой). Проблема: Комп не может менять частоту цистерны с алмазным замком, что делает идею неприменимой на сервере (ибо с замком оно не работает, а без замка использование приравнивается к раздаче, и вас скорее всего переедет фемидой). Однако, если вдруг подобное ограничение уберут, система наверняка будет востребованной. К синглу эта проблема по очевидным причинам не относится.

io,component=require"io",require"component" -- Подключаем библиотеки io и component для взаимодействия соответственно с пользователем и с компонентами redstone=component.redstone -- Получаем прокси компонента редстоуна, будь то карта или блок SIDE=2 -- Задаем сторону, в которую будет выдаваться сигнал function lock() print"Enter password" t=io.read() if t=="123" then print"Correct!" redstone.setOutput(SIDE,15) os.sleep(7) redstone.setOutput(SIDE,0) else print"Incorrect!" end end -- Начало самой программы while true do --Всегда повторяем кусок ниже lock() --Вызываем функцию замка os.sleep(0) --Даем событиям шанс на обработку. Здесь не играет особой роли, но обычно полезно end

1. Объявляешь функцию lock, вызываешь функцию pass. Pass не определена, о чем он тебе и говорит. 2. Если не ошибаюсь, у тебя не заработает еще по одной причине, а именно redstone не определен. Попробуй впихнуть в самое начало 'redstone=require"redstone"' или 'redstone=component.redstone'. 3. Делать это через рекурсию - упорото и небезопасно, переделай под цикл. P.S. 4. 'sleep' замени на 'os.sleep' 5. В начало проги 'io=require"io"', 'read' замени на 'io.read'

Вот одно из предложений: http://computercraft.ru/topic/1977-rekvest-apgreida-kompas-dlia-os/ Для поддержания чистоты темы предлагаю все обсуждение этого предложения вести в его теме. Вкратце суть: предлагается введение апгрейда для планшета, который позволяет получать направление, в котором смотрит игрок.

Апгрейд для планшета; возможно, найдется применение и в роботах/дронах, но я пока не придумал. Суть апгрейда - позволяет получать направление, в котором смотрит игрок, который держит планшет (два угла, по горизонтали и по вертикали), помимо этого сообщает оное вместе с событием "tablet_use". Область применения - задачи, в которых требуется более точное позиционирование в пространстве, вот несколько идей в качестве примеров: банальное ручное наведение турелей гораздо более удобное и точное дистанционное управление дроном редактирование голограмм на самих голограммах (например, с постройкой голограммы в воздухе подобно постройке структур в майнкрафте, т.е. присоединением блоков к уже имеющемуся куску) голографический интерфейс в 3д со всякими голографическими же кнопками, текстовыми полями и подобным Очевидно, применение апгрейда этими примерами не ограничивается. Надеюсь, многие найдут предложенное полезным, просьба оставлять конструктивную критику/предложения по улучшению идеи апгрейда в комментариях, если таковая (-ые) будет.

У меня не получилось установить оное ингейм, валится на подгрузке иконки. Пока в код не лез, но вот скрин проблемы: P.s. До меня внезапно дошло, что может не хватать места. Ща вставлю второй хард и попробую снова. [uPD] Да, именно так, теперь вроде нормально поставилось.

Сие ( http://pastebin.com/C0S2m3d8 ) является реализацией программной навигации для робота под eeprom. Здесь уже мелькали реализации подобного, но их все отличает от предложенной большой размер и наличие малоиспользуемых функций. Собственно эта реализация влезает в 780 байт с учетом двух переводов строки после себя (ну мало ли). Имена переменных и функций сокращены настолько, чтобы занимать как можно меньше места, но при этом оставаться осмысленными. Отступы убраны для уменьшения размера. Некоторых проверок "на дурака" нет из тех же соображений. Значимые переменные: ns,nx,ny,nz - направление и три координаты, где x и y образуют горизонтальную плоскость. Изначально робот смотрит в сторону оси x, ось y направлена направо, ось z - вверх. Значимые функции: n_u, n_d - navigation_up/down, движение вверх/вниз; n_f - navigation_forward, движение вперед; n_l, n_r - navigation_left/right - поворот налево/направо; t_t - turn_to, повернуть к, принимает в качестве аргумента число от 0 до 3, задающее новое направление. 0 - направление оси x, далее по порядку по часовой стрелке; n_t - navigate_to, движение к заданой точке, принимает в качестве аргумента координаты точки, в которую требуется проследовать. Сначала передвигается по оси z, затем x и y. Для использования достаточно скопировать код в вашу программу, далее все описанное будет доступно. Если место позволяет, для удобства можно переназвать планируемые к использованию функции (аля "local turn_left=n_l"). Далее у вас будет более 3Кб под остальную часть программы. Надеюсь, кому-нибудь будет полезно.

Не хочу никому навязывать мое увлечение дронами, но не кажется ли Вам, что это - одна из тех задач, в которых они будут справляться намного лучше? Вместо дорогой и местозатратной конструкции из транспозеров и сундука делаем плотное (по вялилке на блок) поле вялилок в виде параллелепипеда, рядом ставим сундук, который каким-либо образом пополняется, а лучше сразу два (входной и выходной). И запускаем дрона под управлением компьютера, который растаскивает ресурсы из сундука по вялилкам, а потом собирает готовое с вялилок в второй сундук. С контроллером инвентаря можн даже вялить разные ресурсы. Комп знает расположение вялилок и помнит, что на них висит, дрону только говорит "неси туда/оттуда". При вялении разных ресурсов дрон еще сообщает компу тип ресурса, чтобы комп учитывал это при выдаче заданий. Учитывая скорость и проходимость дрона, это сильно лучше, чем транспозеры или роботы. Лучше по: цене (очевидно), плотности (можно упихать гораздо больше вялилок в единицу объема), наверное, лагодромности, ибо 1 дрон + 1 комп наверняка грузят сервер меньше, чем сервер + тонны транспозеров. P.s. Специально потратил некоторое время на проверку возможности взаимодействия дронов с вялилками, чтобы удостовериться в том, что автор не выбрал дронов не потому, что они не могут решать эту задачу. Они могут.