eu_tomat

Более подробно об использовании символических ссылок я рассказывал в этом посте:

В 07.08.2019 в 09:38, eu_tomat сказал:

Ещё я рекомендую использовать символические ссылки. Когда проект большой, и файлы программ распределены между несколькими роботами и компьютерами, то после длительного перерыва в разработке бывает трудно вспомнить, в каком сохранении игры и на каких дисках хранятся нужные файлы. Символические ссылки упрощают работу. Все файлы проекта можно разместить в одной общей папке с понятным названием. А в папках, соответствующих дискам OpenComputers, создаются символические ссылки на требуемые файлы проекта. Особенно удобно, если один и тот же файл используется в нескольких роботах, его достаточно обновить лишь один раз в текстовом редакторе. Также символические ссылки позволяют дать удобные имена папкам дисков для быстрого доступа к ним.

1 час назад, Doob сказал:

Если человек сначала изучил обезьяний язык, то его потом будут бить костылями другие программисты, пока он не переучится.

Со взрослыми языками та же история. После Си, начав программировать на Питоне, тоже бывает сложно не получить костылями от питонистов.

Меня от изучения чисто игровых языков останавливают три вещи:

• Недостаточна мотивация для изучения малоприменимого языка.
• Мало информации по редкому языку.
• Дизайн языка, скорее всего, хуже его взрослых аналогов.

1 час назад, hohserg сказал:

А что если определить критерии оптимума без учета времени вычисления, а алгоритм сделать достаточно быстрым, чтобы временные затраты на вычисление было достаточно малы и не влияли существенно на оптимальность системы в целом

Почему бы и нет. Какие у тебя есть идеи по созданию быстрого и при этом оптимального алгоритма поиска пути при большом количестве целей?

Про лучший способ использования Git я не скажу, но если проблема только в этом:

1 час назад, hohserg сказал:

• файлы одного проекта могут лежать на разных устройствах в игре, в разных фс, следовательно, в разных папках в saves мира
• даже если папка одна, то .git каталог будет частью фс компа, а видеть его из игры совершенно не нужно

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

10 минут назад, whiskas сказал:

Ну по твоей назве я понял что у тебя алгоритм расчитан ити к ближайшему соседу что следовательно не самое оптимальное.

Самое оптимальное в каком смысле?

Абсолютный оптимум по количеству времени действий робота можно найти лишь полным перебором всех целей. Но времени на обработку придётся потратить очень много. Настолько много, что проще выкопать карьер сплошной копкой. Существуют итеративные методы, улучшающие решение на последующих шагах вычислений. С одной стороны, каждая последующая серия итераций позволяет сэкономить время движений робота, а с другой стороны, время расходуется и на сами вычисления тоже. Оценка соотношений затраченного и сэкономленного времени позволяет оптимизировать общее время, вовремя перейдя от вычислений к действиям. Это более-менее объективный критерий оптимума.

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

1 час назад, BrightYC сказал:

Добавил проверку.

Метка "tmpfs" не обязательно указывает на временную файловую систему.

Верное решение:

local tmpfs = component.proxy(computer.tmpAddress())

8 часов назад, hohserg сказал:

filesystem.getLabel() позволяет отличить

При условии, если кто-то не указал носителю метку "tmpfs". К слову, ничто не мешает это сделать.

5 часов назад, hohserg сказал:

Это только для OpenOS, вроде

Действительно, только для OpenOS. Заглянув в недра системы, я пришёл к такому решению:

local tmpfs = component.proxy(computer.tmpAddress())

Так должно работать гарантированно верно.

5 минут назад, BrightYC сказал:

Этот код будет работать на любом компьютере, правда нужно учесть, что с OpenOS может выбраться случайная файловая система.

Насколько я понимаю, дело не в наличии OpenOS, а в наличии других носителей с файловыми системами.

1 час назад, hohserg сказал:

Есть ли какой-то способ отличить tmpfs от filesystem жесткого диска?

~~~

filesystem.getLabel() позволяет отличить

Ещё способ:

filesystem.fsnode.name

2 минуты назад, BrightYC сказал:

Computronics радар обнаруживает игроков/предметы.

Насколько я помню, этот радар не показывает координаты игроков. Соответственно, мы не знаем, находится ли другой игрок в нашей кабинке или же соседней. Можно, конечно, поставить радар на достаточном удалении от стен кабинки, но тогда компактность страдает.

51 минуту назад, BrightYC сказал:

Заходит другой игрок пока другой получает товары, ну вот и небезопасность. Либо просить админов отключить телепорты/эндержемчуги, но там где я играю - есть куча предметов, которые помогут проникнуть в кабинку. PIM/транспозер - надёжнее. 

Вполне безопасно, если проверять наличие посторонних игроков в кабинке. А наилучший способ передачи предметов зачастую определяется не теорией, а конкретным игровым сервером: где-то транспозер не работает с интерфейсом игрока, где-то админы запретили PIM. Что тогда остаётся использовать кроме робота?

Правда, возможности гарантированно обнаружить постороннего игрока тоже может не быть. Существует ли что-то кроме сенсора из OpenPeripheral, способное обнаружить неподвижных игроков?

37 минут назад, BrightYC сказал:

1 - это робот. Постоянно, просто постоянно игроки лезли в чужие кабинки, когда были не свободные кабинки, а с дверью. А с роботом вообще ни о какой безопасности речи быть не может =\

А в чём небезопасность роботов?

@BrightYC Почему в названии темы присутствует термин "вирус"? Что вирусного в этой программе?

7 минут назад, ArtHacker сказал:

Лады раскрою карты

Я хочу сделать "****"

Я сказал что раскрою карты? Забыл сказать. Поддельные карты:)

А зачем вообще было их раскрывать? Теперь придётся спешить.

В 08.11.2019 в 19:51, ArtHacker сказал:

Но сделать я хочу другое. С VR очками.

Теперь кто-то тоже хочет "другое с VR очками". А кто-то не только хочет, но и уже делает.

26 минут назад, 8urton сказал:

Простое API для быстрого и лёгкого написания своих программ (Документация: в розработке)

Ну, хорошо. Документации пока нет. Но имеет смысл хотя бы в в общих словах описать, в чём заключается удобство, почему написание программ становится более быстрым и лёгким.

13 минуты назад, vlast сказал:

Всем привет! Может кто знает где можно найти прогу для взаимодействия опен компьютерс и лантеа крафт на версию 1.6.4? никак не могу на эту версию найти

Задача стоит играть именно на 1.6.4?

Потому как для 1.7.10 есть SGCraft, хорошо интегрированный с OpenComputers.

1 минуту назад, Asior сказал:

Кстати если у вас несоразмерно кривые руки что вы умудритесь запороть файл, дропбокс может его откатить на любое другое предыдущее обновление.

А как можно "запороть" файл?

Для начала надо понять, почему компьютер выключается, и попробовать устранить причину отключений. Если избежать отключений не удаётся, то компьютер можно "разбудить" с помощью либо сетевой, либо красной платы.

При каких обстоятельствах происходит выключение компьютера?

32 минуты назад, BrightYC сказал:

Если честно, то я думаю, что для текущего проекта esp8266 недостаточно. А esp32 вполне подходит, но там NodeMCU уже нет. Я считаю, что нужно начать с простого. На большее с NodeMCU рассчитывать не стоит. Либо действительно брать уже RPI. 

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

Из того, что сейчас интересно мне, это машинка для увеселения котов и людей. Изначально я смотрел в сторону Arduino Nano. Но будет ли этот проект интересен на форуме кому-то кроме меня, я не знаю.

47 минут назад, BrightYC сказал:

Если я правильно понял - хочется сделать именно машинку, которая должна сама ездить, делать какие-то действия? Или просто ездить отталкиваясь от препятствий?

Отталкиваться от препятствий мне скучновато. Хочу какого-то планирования действий в ближайшие секунды, препятствия должны обходиться заранее. Для начала хочется добиться постоянной скорости движения, пусть и небольшой. Потом интересно поднять скорость до максимума, насколько мне хватит умения, терпения и возможностей датчиков.

50 минут назад, BrightYC сказал:

А делать просто машинку, которая избегает препятствий - как по мне, банально не интересно

Мне интересно упороться оптимизациями и скоростями. И как максимум, интересно научить машинку ненавязчиво троллить котов. Тоже интересно узнать, насколько мне это удастся.

54 минуты назад, BrightYC сказал:

На счёт лидаров - в автопилоте Tesla они не используются, а в основном используются камеры.

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

Ещё я могу попытаться всё-таки выжать, что возможно, из решения на NodeMCU, чем бы это ни кончилось. Если не получится, вернусь к начальному решению на Arduino Nano, или буду как-то иначе корректировать решение.

Ещё есть идея. Можно вынести в отдельный проект создание интерпретатора Lua-кода через web-интерфейс. Это почти как с дронами из OpenComputers: непосредственная отладка при работе с периферией дрона затруднена, поэтому приходится использовать планшеты и стационарные компы для опосредованной отладки. Так и тут, чтобы не заливать каждый раз программу в контроллер, можно короткие скрипты выполнять через web-интерфейс и выводить какую-то информацию. Такая программа позволила бы быстрее и удобнее уточнять нюансы при работе с периферией. Но с этой задачей ты и без меня справишься. Возможно даже, до того, как я приобрету NodeMCU.

6 часов назад, BrightYC сказал:

Я думаю математические функции не тронуты, было бы глупо. Но нужно проверить

Было бы глупо что? Трогать функции? Так они же сами себя не напишут. Сам микроконтроллер не имеет аппаратной поддержки чисел с плавающей точкой даже для базовых операций, не говоря уже о тригонометрии.

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

11 час назад, BrightYC сказал:

load не принимает строку в качестве аргумента. Требует функцию. Но есть dofile, у NodeMCU файловая система, похожая на OpenComputers'овскую. 

Насколько я понял, можно сделать что-то вроде pclal(loadfile("test.lua"))

А loadstring принимает строку lua-кода?

У меня вот ещё какой вопрос. Как у NodeMCU дела с математическими функциями? Синусы с косинусами придётся самому вычислять? Как там вообще осуществляются вычисления с плавающей точкой? Какова максимальная разрядность при работе с целыми числами?

Я тут подумал, что в принципе приводу поворота головы не обязательно знать начальный угол. Привод можно откалибровать при старте программы за два сканирования. Между сканированиями надо выполнить одно движение вперёд или назад. Причём, движение не обязательно откалиброванное. Главное, чтобы во время калибровки на пути робота ничего не стояло. Ещё думаю, алгоритм может запутаться при сканировании решетчатых структур, но тут должно помочь сглаживание. Правда, тригонометрия нужна в любом случае. Без синусов я пока не смог придумать калибровку.

3 часа назад, Doob сказал:

Лучше взять нормальный микроконтроллер, а это годится разве только для мигания светодиодом.

Лучше для какой задачи?

3 часа назад, Doob сказал:

Единственное, что не купить и не выдрать из каких-нибудь потрохов - сканирующий дальномер.

Во всяких автономных беспилотниках используют лидары, но у них лютое потребление энергии.

Немного изучив тему, я тоже склонился к лидарам. Потребление энергии лидаром на фоне приводов меня не беспокоит.

Но с лидарами мне пока не всё понятно. Есть, например GY-530 VL53L0X с получением данных по шине I2C, там в характеристиках указано время <30ms. Что это значит? В течение некоторого времени сенсор должен оставаться неподвижным? А есть, например GY-53-L1X VL53L1X, там про время ничего не сказано, а ещё у него есть выход ШИМ. Даёт ли ШИМ возможность непрерывного сканирования без необходимости останавливать движение?

2 минуты назад, BrightYC сказал:

А зачем распознавать преграды микроконтроллером?=)

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

Да, цель в создании именно автономного робота, способного видеть и обходить препятствия без участия человека. Я неточно сформулировал цель. Робот должен объезжать препятствия без помощи человека. Никакого читерства в виде миллионов лет эволюции. Объезжать препятствия за счёт человеческого интеллекта как раз и будет "из пушки по воробьям".

Цели пугать кота я не ставил. Пугать как раз можно было бы ультразвуковым датчиком. А этого я хочу избежать. Кота я планирую троллить: в автоматическом режиме надо найти кота, подползти, выполнить замысловатый танец и попытаться сбежать. Но это дело будущего. Сначала нужно научить робота обходить преграды, это задача-минимум.

18 минут назад, BrightYC сказал:

Погрешность то в любом случае будет. Просто мне кажется, что ставить оптический датчик и шаговый двигатель на радиоуправлямую машинку - из пушки по воробьям. Лучше уж камеру поставить с сервоприводом, повеселее будет, как мне кажется 

Погрешность будет, это понятно. Мне не понятно, может ли сместиться оптимум при работе в других условиях: просело напряжение на батарее, износился сервопривод и т.д. Машинка, кстати, не радиоуправляемая. Вайфай мне нужен в основном для отладки.

Кстати, об отладке. Платформа NodeMCU поддерживает выполнение произвольного Lua-кода? Требуются функции load и pcall.

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

18 минут назад, BrightYC сказал:

По сути, можно использовать недостаток сервоприводов которые не могут вращаться на 360 градусов - крутануть например на 260 градусов вправо, и рано или поздно сервопривод установится в нужное положение. А там уже можно прыгать от исходного положения. 

У них вроде бы и так есть два крайних положения: ноль и один, управляется скважностью через PWM. Тут проблем в том, что скорость работы этих сервоприводов неизвестна. Почти как неопределённость Гейзенберга: либо в режиме реального времени известен относительный угол, либо известен абсолютный, но с некоторой задержкой. Поэтому я не знаю, как применить эту идею.

34 минуты назад, BrightYC сказал:

Скорее всего, эти данные получены экспериментальным путём. Так же, есть задержка между получением данных у ультразвукового сенсора. Ты то можешь выставить любую задержку, не обязательно ведь ставить 30 мс

Понятно, что любую. Вопрос в том, как определить, что задержка достаточна и не избыточна? Не изменится ли оптимум при изменении напряжения питающей батареи?

34 минуты назад, BrightYC сказал:

Никак. Принудительно при включении робота устанавливать угол например на 90%

Ну, а как принудительно установить на нужный угол? Шаговый двигатель не имеет такой возможности. Можно лишь сместить на нужный угол относительно исходного. И снова встаёт вопрос, как определить угол? Исходный или конечный, без разницы.

Я тут, кстати, нагуглил, что есть сервоприводы, способные вращаться на 360 градусов. Но у них та же проблема, что и у шаговых двигателей: есть возможность задать скорость вращения, но абсолютный угол определить или задать невозможно.