eu_tomat

В видео я не услышал главного: почему после поворота на один градус нужно ждать именно 30 миллисекунд. Почему не больше? Почему не меньше? Изменится ли эта задержка при повышении или понижении напряжения питания сервопривода? Насколько я знаю, положение шагового двигателя со 100% точностью мы можем определить лишь в одном случае: если знаем его начальное положение. Ну, и если не было пропуска шага при работе двигателя с перегрузкой. Перегрузки у нас не будет. Но как определить начальный угол вала шагового двигателя при включении робота?

@BrightYC Спасибо за разъяснения. Это поможет мне быстрее вникнуть в предмет. Я погуглил тему датчиков, и там всё оказалось сложно. Дешёвые датчики имеют малую дальность. То есть, роботу будет нельзя сильно разгонятся. Дорогие датчики по сути являются дальномерами. Они видят сравнительно далеко и точно, и точность, как это ни странно, создаёт новые проблемы: препятствие может оказаться между лучей, и робот его не заметит. Чтобы заметить препятствия между лучами, робот должен крутить головой. И желательно, крутить головой достаточно быстро. И тут начинается самое интересное. Правильно ли я понимаю, что сервоприводы для Ардуино могут лишь воспринимать управляющий сигнал без возможности передать контроллеру фактический угол поворота? И если сервоприводу дать команду развернуться в крайней положение из противоположного, то время завершения операции можно определить лишь примерно? Оно, насколько я понимаю, зависит от питающего напряжения? И является ли скорость поворота сервопривода более-менее постоянной, или сервопривод замедляется ближе к целевой точке? И есть ли у сервопривода крайние положения? Может ли он непрерывно вращаться на 360 градусов? Зная ответы на эти вопросы, можно было бы вращать головой на полной скорости сервопривода, считывая расстояния до всех предметов на горизонте. Ещё есть идея вскрыть сервопривод, и если позволит схема, подключиться непосредственно к потенциометру сервопривода. Это позволит точно определять угол даже не остановившегося сервопривода. Скорректированный план пока такой: от дешёвых датчиков отказываюсь, использую один дальномер на сервоприводе. Стартовую программу придётся сразу усложнить, и это огорчает, т.к. я надеялся снизить порог вхождения в этот проект, усложняя алгоритм постепенно.

Здравствуйте, товарищи! Я в очередной раз заинтересовался темой микроконтроллеров и на этот раз я намерен перевести свой интерес в практическую плоскость. При выборе платформы я склонялся сначала к Arduino, но потом вспомнил о платформе NodeMCU, с которой нас познакомил @BrightYC. NodeMCU позволяет писать программы на языке Lua, благодаря чему эта тема может стать интересной более широкому кругу форумчан. Поэтому для первого проекта я выбрал NodeMCU. Должен сразу сказать, что тему микроконтроллеров я знаю поверхностно и лишь теоретически. И я слабо представляю возможности типовой периферии Arduino и NodeMCU, и насколько совместима эта периферия между платформами. Поэтому я буду рад любым советам. Ближайшая цель: выбрать комплектующие для проекта и заказать их в Китае. Можно заказать и в России, если это будет не сильно дороже. Конечная цель проекта: Минимум: Сделать игрушечную машинку на четырёх колёсах с танковым разворотом, способную случайно блуждать по полу, объезжая препятствия. Датчики препятствий нужны какие-то оптические, чтобы не пугать ультразвуком котов. Датчики желательно аналогвые, чтобы знать примерное расстояние до препятствий, если это вообще возможно на типовых модулях. Также требуется подключение по WiFi для отладки скриптов. Датчиков препятствий пока планируется три: один смотрит вперёд, а другие немного в стороны, чтобы выбрать предпочитительное направление для поворота, не вращая корпус машины. Машинка будет иметь четыре колеса с двигателями и редукторами на каждое колесо. Колёса требуются какие-нибудь простые и недорогие. Двигатели будут объединены в две группы, для их управления нужен какой-нибудь модуль драйвера. Драйверы будут управляться либо аналоговым сигналом, либо ШИМ, чтобы машинка могла двигаться с переменной скоростью и делать повороты различного радиуса. Также требуется аккумулятор для питания устройства и контроллер заряда с USB-интерфейсом. Опционально: Нужна сервомашинка для вращения "глазами" для улучшения ориентации на поворотах. Нужен датчик тепла, скорее всего, на сервоприводах, чтобы искать котов, отличая их от батарей отпления или ног людей. В дальнейшем я предполагаю добавление алгоритма троллинга этих самых котов для большего веселья. Нужен способ воспроизводить звуки из заданного набора с флешки. Корпус первой машинки я планирую изготовить из картона с помощью термоклея. Все элементы, включая электронику также будут лепиться на термоклей. Для начала чем проще, тем лучше. Я хочу сосредоточиться в первую очередь на логике, а не на эстетике или долговечности игрушки. Вопросы на текущем этапе: Как выбирать плату контроллера? Установлен ли на плату WiFi, или он устанавливается отдельным модулем? Насколько часты у начинающих самодельщиков случаи "ткнул не туда, плата сгорела"? Имеет ли смысл взять несколько плат на всякий случай? Какие выбрать модули для управления двигателями? По каким критериям? Какие существуют оптические датчики расстояния? Могут ли они выдавать аналоговый сигнал, и есть ли в аналоговом сигнале какой-либо смысл? Как выбрать аккумулятор и контроллер заряда? Как подключаются сервомашинки к контроллеру? Нужны ли им дополнительные модули драйверов? Какая периферия требуется для воспроизведения звуков с флешки? Если какие-то из моих формулировок вам непонятны, задавайте уточняющие вопросы. Я пока сам не знаю, как правильно сформулировать свои мысли в новой для меня теме. На практике я знаю лишь Lua, да умею пользоваться паяльником, а также знаю основы электроники и электротехники. А вот, всякие там Ардуинки и прочие конструкторы в руках держать пока не доводилось, и возможностей компонентов я тоже не знаю. Надеюсь обо всём этом узнать в процессе реализации данного проекта. Возможно, с вашей помощью.

Чтение является основным занятием программиста: читать код, читать спецификации, читать задание. Не всегда их текст короток и, что ещё хуже, не всегда соответствует друг другу. И лишь во вторую очередь программист пишет текст: код, спецификации. задание. Есть две ссылки: для урана и для MOX: Но фокус, как всегда, в том, что эта информация не совсем верна. И для её уточнения, не всегда требуется читать много текста или писать код. Предлагаю провести следующие эксперименты: Пространство реактора с шестью дополнительными камерами заполняем теплоёмкими реакторными обшивочными пластинами, а в один из слотов помещаем одиночный урановый ТВЭЛ. К реактору подключаем MFSU. На реактор подаём сигнал редстоуна и уходим гулять. Часов через пять с половиной убеждаемся в том, что стержень сгорел до конца, проверяем энергию в MFSU, а также нагрев реактора. Для проверки нагрева можно воспользоваться компьютером или информационной панелью из NuclearControl. Зная расчётный выход энергии и тепла, можно оценить фактическое время работы реактора. Эксперимент аналогичен предыдущему. Но вместо урана используется MOX. Проверяется нагрев реактора. На эксперимент уходит около трёх часов. Ещё один эксперимент с MOX. Но вплотную к стержню кладётся разогнанный теплоотвод. Проверяется энергия в MFSU. Эксперименты с MOX можно объединить в один, но тогда для проверки выделенной энергии придётся заняться интегрированием и потом искать ошибку, либо в своём интегрирующем коде, либо в реализации ic2exp, это занятие лишь для самых суровых программистов. Все три эксперимента не запрещается провести параллельно и даже воспользоваться модами, повышающими TPS и ускоряющими течение времени в Майнкрафте, насколько позволяют ресурсы компьютера. После получения экспериментальных данных о фактическом выходе тепла и энергии при работе стержней можно задуматься о дальнейших экспериментах. А сколько вам удалось выжать тепла и энергии из одиночно стоящих стержней из урана и MOX?

Мда, печаль. Я тут вижу две основные проблемы. Во-первых, даже самая частая запись на диск не гарантирует сохранения всех данных. Во-вторых, что частая запись на диск, что обработка спама событиями редстоуна приведут к дополнительной нагрузке на игровой сервер. А роботы тоже отключаются? Потому что в этом случае самых простых роботов-шахтёров после перезагрузки сервера искать придётся вручную.

Что за пакеты такие? Это же не сетевые пакеты? И, может быть, это не бага, а фича тех серверов? Вот, я и думаю: это результат взаимодействия модов в сборке, или владельцы серверов пропатчили мод под свои цели?

Да не нужен мне твой приват. Мне нужен комп на проблемном сервере. А тратить время на развитие ради возможности посмотреть на проблему я в ближайшее время не планирую. Кстати, проверь, проявляется ли эта проблема в сингле на их сборке? Если да, то мне и твой приват с компьютером не нужны. На наших сборка такого вроде бы не было. Помню, мониторы от gpu отцеплялись, и эта проблема была пофикшена. Но компы OC вроде не вырубались.

Что значит "игрокам"? В том смысле, что игроки могут каким-то необычным образом офать свой комп? Или игрокам кто-то другой может оффнуть их комп? И что за бага такая? Интересно было бы на это взглянуть. Если пустите меня в свой приват посмотреть на это чудо, то я даже не поленюсь там зарегистрироваться и скачать лаунчер. Предложения пишите в личку.

Комп полностью выключается, или только пропадает картинка на мониторе? Какая версия OpenComputers?

Вопрос разработчикам модов Майнкарфта. Попытка понять странности поведения одного мода привела меня к чтению его исходного кода, полученного с помощью декомплятора. И там я встретил кучу непонятных методов со странными названиями. Я впервые вижу написанный на Java код, и, возможно, могу что-то понимать неправильно. Кроме того, я совершенно не знаю, как пишутся моды для Майнкрафта. Поэтому я не уверен даже в постановке вопроса. Код Майнкрафта, скорее всего, обфусцирован, и поэтому названия методов имеют нечеловеческие названия. Для создателей модов наверняка существуют какие-то справочники, но поиск пока привёл меня лишь к исходным текстам каких-то модов. Вопросы: Что делает метод net.minecraft.item.ItemStack.func_77964_b? Что это за API, и API ли это? Майнкрафтовский ли это API, или ещё чей? И вообще, куда копать, чтобы понять эту петрушку?

Вот, мы говорим про микроконтроль. Пытаемся малыми действиями достичь большого эффекта. Но это не значит, что каждую секунду обязательно следует опрашивать какие-то датчики и что-то перемещать. Ядерный реактор Industrial Craft это не самолёт, которому надо учитывать случайные воздушные потоки и турбулентности. Многие процессы в этих реакторах предсказуемы. Зачем прямо сейчас переносить в холодное место один из теплоотводов, если перегрев грозит ему лишь через минуту? Зачем каждый тик проверять догорающие ТВЭЛ'ы, если время их работы точно известно? Предлагаю несколько похожих загадок: Есть почти сгоревший урановый ТВЭЛ с разрушением 9980. На сколько секунд горения его хватит? А на сколько хватит свежего уранового ТВЭЛ? А сколько секунд будет гореть сдвоенный ТВЭЛ? А счетверённый? Теперь то же самое с ТВЭЛ'ами из смеси оксидов. Есть одиночный MOX-ТВЭЛ с разрушением 9980. Сколько секунд сможет гореть он? И сколько секунд будет гореть свежий ТВЭЛ? А сдвоенный? А счетверённый? У кого какие ответы?

Скопировал код из этой темы: os.execute("cls") end Код при вставке выглядит так: $ xclip -selection primary -o | xxd - | grep -i 'EF\s*BB\s*BF' 00000010: 2229 0a65 6eef bbbf 64 ").en...d Исходный код на странице: os.execute("cls") en<span></span>d<span></span><span></span><span></span></span> А при вставке выглядит так: После обновления страницы проблема не проявилась. А фрагмент теперь выглядит так: os.execute("cls") end<span></span><span></span></span> Проблемные страницы я ищу таким образом: открываю страницу, выделяю всё содержимое, копирую в буфер и запускаю $ xclip -selection primary -o | xxd - | grep -i 'EF\s*BB\s*BF' Чаще всего BOM обнаруживается где-то на стыках форматирования, но бывает внезапно и посреди кода. А потом пропадает по непонятным причинам.

Речь шла об этой схеме: Я тут вижу только вариант с 27 MOX. А у тебя какой был? P.S.: Схема с конденсаторами, ясное дело, не требует дополнительных реакторов для охлаждения.

Последовательность EF BB BF часто встречается при копировании кода с подстветкой синтаксиса. Это уже баг. Правда, пока непонятно, чей именно баг. Например, он должен обязательно встретиться здесь, на границах тега span: local x=0 Но в приведённых выше примерах нет подсветки. Откуда там BOM посреди текста? P.S.: нет, не встретился, почему-то. Скопирую из проблемного поста: local cx,cy,cz = -1408,0,512 P.P.S.: Тоже всё в порядке. После обновления страницы и в проблемном посте тоже перестало проявляться. Чудеса какие-то.

Последовательность EF BB BF является маркером последовательности байтов UTF-8.

Проявилось в очередной раз. У меня выглядит так: $ xclip -selection primary -o | xxd - 00000000: 7767 6574 2068 7474 7073 3a2f 2f72 6177 wget https://raw 00000010: 2e67 6974 6875 6275 7365 7263 6f6e 7465 .githubuserconte 00000020: 6e74 2e63 6f6d 2f68 6f68 7365 7267 312f nt.com/hohserg1/ 00000030: 4f70 656e 436f 6d70 7574 6572 7350 726f OpenComputersPro 00000040: 6772 616d 732f 6d61 7374 6572 2f70 6c61 grams/master/pla 00000050: 7965 726c 6f6f 6b2f 676c 6173 7365 732e yerlook/glasses. 00000060: 6c75 efbb bf61 lu...a Но после обновления страницы уже так: $ xclip -selection primary -o | xxd - 00000000: 7767 6574 2068 7474 7073 3a2f 2f72 6177 wget https://raw 00000010: 2e67 6974 6875 6275 7365 7263 6f6e 7465 .githubuserconte 00000020: 6e74 2e63 6f6d 2f68 6f68 7365 7267 312f nt.com/hohserg1/ 00000030: 4f70 656e 436f 6d70 7574 6572 7350 726f OpenComputersPro 00000040: 6772 616d 732f 6d61 7374 6572 2f70 6c61 grams/master/pla 00000050: 7965 726c 6f6f 6b2f 676c 6173 7365 732e yerlook/glasses. 00000060: 6c75 61 lua

Да, конденсаторы сильно упрощают схему охлаждения. Она не требует балансировки. Но как ты добился лишь одного холодильника при использовании теплообменников? Попробуем посчитать. К слову, я тоже ошибся в своих расчётах. Теперь попробую посчитать правильно. На уране 8099 eu/t не достичь, даже если забить ТВЭЛ'ами все слоты реактора. Остаётся MOX. Максимальный множитель эффективности для разогретого реактора 4.9996, а для минимизации тепла при максимизации температуры мы используем счетверённые ТВЭЛ'ы с базовой генерацией 60 eu/t. Значит, используется 8099/4.9996/60 = 27 счетверённых стержней MOX. Реактор имеет 54 слота, значит, стержни можно разместить лишь в шахматном порядке. Каждая сборка генерирует 96 hu/s, а все сборки 96*27 = 2592 hu/s. В свободные ячейки мы можем разместить теплоотводы или теплообменники. Самый эффективный теплоотвод даёт охлаждение в 20 hu/s на слот, и для полного охлаждения требуется 2592/20 = 129.6 слотов. В рабочем реакторе есть 27 свободных слотов. Фактически меньше, т.к. для поддержания высокой температуры реактора количество разогнанных теплоотводов в реакторе потребуется уменьшить. Но для грубых расчётов будем считать 27 слотов. Значит, для охлаждения потребуется (129.6-27) / 54 = 1.9 охлаждающих реакторов. Два холодильника в самом лучшем случае. Как у тебя получился один?

У меня сейчас не повторилось, но иногда проявлялось в других местах. Никакой системы я не обнаружил. Попытка обсуждения была мною замечена здесь. Диверсантов надо бы устранить, но сначала надо понять, откуда они пришли. Первое, что мне приходит в голову, это водяные знаки, позволяющие в некоторых случаях установить первоисточник. Но эти водяные знаки работают лишь при бездумном копировании текста. А на форуме, подразумевающем копирование кода, водяные знаки только мешают.

А почему не говоришь, что для охлаждения схемы требуется 2.667 дополнительных реакторов для охлаждения? Получится уже 2208 eu/t на реактор. И то, эффективно использовать дополнительные реакторы получится лишь при количествах, кратных 11 штукам: 3 генерирующих и 8 охлаждающих. При этом в рамках одного реактора существует сбалансированная схема на 2099 eu/t, что чуть менее эффективно, на 5% меньше в пересчёте на реактор, но зато не требуется согласования работы одиннадцати реакторов друг с другом.

Это решение подходит лишь тем экстремалам, у которых не только пинг хороший, но и чувство времени отличное. Но трудность не в этом, воронка вовремя извлекает теплоотвод, временной зазор достаточен для срабатывания схем на редстоуне. Основная трудность: у меня не получилось выдать такой по времени импульс, который бы гарантированно включил реактор ровно на один реакторный такт. А пока что у меня получаются импульсы, либо иногда включающие реактор на два такта, либо иногда вообще не включающие. Чаще всего реактор включается на один такт, но результат не гарантирован. Как сформировать импульс, гарантированно включающий реактор на один такт? Без NuclearControl и OpenComputers.

Похоже, тут остаётся лишь воздействовать на автора мода. Ещё вместо роботов можно попробовать использовать автокликеры.

А какой мод добавляет верстак с сеткой 5x5?

Я провёл эксперименты со схемой полуавтоматического разогрева реактора за одну секунду без использования компьютеров. В первую очередь я хотел автоматизировать изъятие теплоотвода. С этим проблем не возникло. Достаточно было лишь развернуть схему так, чтобы теплоотвод вынимался воронкой первым. Затем надо было вспомнить, что в этом случае теплоотвод начинает работать лишь на втором реакторном тике. Эта часть успешно работает. Но обнаружилась другая проблема. Каменная кнопка должна выдавать сигнал длительностью 1 секунду. На практике оказалось, что 18-19 тиков. Изредка случаются и значительно меньшие значения. Бывало, что кнопка отжималась через 1 тик. Но чаще всего интервал между нажатием и отжатием составлял 18-19 тиков. Замеры проводились с помощью робота, нажимающего кнопку, и компьютера, фиксирующего изменения сигнала красного камня. Подозревая, что проблема в кнопке, я дал задачу роботу аккуратно генерировать импульсы длительностью 19 тиков с помощью красной платы. Но регистрирующий компьютер получал 18-19 тиков. Меньшие интервалы не были зафиксированы. Компьютер выполнял роль кнопки заметно лучше самой кнопки. Но разброс между 18 и 19 тиками всё равно оказался критичным. При 19 тиках сигнала красного камня реактор иногда успевает сделать два реакторных тика. А при 18, бывает, не делает даже одного. Джиттер в тиках красного камня и джиттер в тиках реактора делают схемы без обратной связи непредсказуемыми. Пока что я я реализовал схему на повторителях, которая выдаёт сигнал длительностью 17-18 тиков независимо от глюков кнопки. Это хотя бы позволяет избежать перегрева реактора. Предварительные выводы таковы: без обратной связи с реактором (OpenComputers, NuclearControl) сделать схему, гарантированно нагревающую реактор за одну секунду до 9999 hu, невозможно. Лучший результат, которого мне удалось добиться: выложить схему в реакторе, нажать на кнопку, проверить температуру. Если нагрев не выполнен, вернуть из воронки в реактор вытянутые компоненты и нажать ещё раз. Я буду рад услышать идеи о том, как улучшить полученный результат и сделать разогрев реактора на целевую температуру за одно нажатие кнопки. По результатам обсуждения выложу гайд.

Любимая многими ядерщикам схема на 420 eu/t способна работать исключительно в условиях асимметрии. Даже поняв основные принципы построения реакторных схем, и научившись самостоятельно проектировать реакторные схемы под свои специфические нужды, именно эту схему я долгое время не мог понять. Охлаждение шести сборок у меня не вызывало вопросов. Но охлаждение седьмой сборки (в схеме она расположена в верхнем левом углу) мне казалось какой-то магией. Улучшить эту схему вряд ли возможно. Она в некотором смысле совершенна. Настойчивые попытки придумать улучшение этой схемы и привели меня в конечном итоге к идее микроконтроля. Впрочем, это не мешает мне забывать про асимметрию и время от времени взрывать свои реакторы. Кстати, у этой схемы есть один симметричный и при этом работоспособный двойник. Желающим размять свои мозги в вопросе асимметрии схем ядерных реакторов предлагаю ответить на вопрос, какое из симметричных преобразований сохранит эту схему в работоспособном состоянии, и почему допустимо именно это преобразование.