rPman

Все зависит от того, какие типы данных в полях, постоянные ли они от строке к строке и много ли 'пустых' значений или точнее, значений с переменной длиной (строки например).

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

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

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

Данные хранишь в файле так, как они хранятся в памяти ардуинки (особенно если они больше нигде использоваться не будут, ну или заранее продумай в каком формате числа будешь хранить BE/LE.

Каждая 'строка' в файле у тебя будет фиксированной длины (можно еще и выровнять на количество байт степени двойки, что оптимизирует операции умножения вычисления позиции, для ардуинки может быть актуально под какие то задачи) и разделители не нужны. Т.е. по номеру строки и номеру колонки можно высчитать смещение данных в файле простым умножением и сложением.

Если нужны запросы по значению, пиши рядом индексный файл, где храни последовательность пар хеш_значения->номер_строки_в_файле, при этом если происходит коллизия, делай в этом файле еще записи с тем же хешем (рядом, чтобы пришлось делать только два лишнего чтение). Значения сортируй по хешу, поиск нужного значения делай тупой дихотомией (метод деления пополам или бинарный поиск) - как нашел значение, читай записи вверх, а потом вниз от него, пока есть коллизия хеша.

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

смартфоны, mid/high-end имеют отличные камеры (а некоторые и оптику), только замоделить крепление к объективу или сразу такой купить

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

p.s. купи объектив 10x с креплением к смартфону и больше ничего не понадобится (только чем то этот смартфон удерживать)

в чем заключается вопрос то? указанной информации не хватит для ответа.

Либо ты устанавливаешь посредника между твоим устройством и интернетом, чтобы физически между ними было какое то подключение (например компьютер, к которому устройство подключается например по usb/com/lpt/ir), либо снабжаешь свое устройство модулем ethernet/wifi/мобильные сети и, в зависимости от выбранного стандарта, реализуешь в прошивке необходимый фунукционал.

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

p.s. напоминаю, что выпускать в интернет порты, обслуживаемые слабым оборудованием, не способным противостоять минимальным ddos, глупо.

С точки зрения интерфейса, наплечное устройство должно показывать направление до дома и опционально - расстояние, плюс кнопку сос и в идеале - голосовая связь, но все радиокоммуникации зарегулированы в стране (в лесу тупо может не быть привычной сотовой связи, напоминаю спутниковая тоже зарегулирована так что ее цена неподъемна для большинства), для стороннего наблюдателя это должно быть приложение, показывающее на карте выбранного пользователя.

Создание своего устройства, с высоким уровнем защиты (особенно защита от холода создаст проблем) - проблема, которую сложно будет решить тем кто задает вопросы такого уровня. Ищите лучше готовые решения.

p.s. представь ты создал устройства, раздал из людям, но из-за ошибке в реализации (первый релиз, баги, обычное дело) люди, понадеявшиеся на твое устройство - зашли в болото и погибли, ты готов к подобной ответственности?

дешевле всего купить ИПБ с портом USB
так как остальные варианты крутятся вокруг самодельного/на заказ устройства, детектирующего наличие отсутствия питания в сети 220 и соответственно сигнализирующего об этом по usb

p.s. само простое можно сделать самому на основе обычной электромагнитной реле, одного резистора и любого блока питания на 5-12в + наличии lpt порта в компьютере (софт к нему пишется за десять минут из пяти строчек)

реле подключается к блоку питания, а земля и один из портов данных lpt через резистор подключаются к контактам реле (пока замкнуто реле, сигнал по lpt пойдет - это единичка, разомкнул - ноль), софт читает файл lpt и смотрит как только там не 1 в нужном бите, ждать таймаут и если все еще ноль - вызывать shutdown /h

idena.io - главная идея проекта, майнят не мощности а идентити (человек).

На текущей момент никакой адекватной пользы проект не приносит, инструменты для использования имеются (например можно на сайте сделать авторизацию через клиент), встроенный ipfs и наличие rpc команды для публикации объекта по уму могут позволить сделать что то по истине децентрализованное, но пока стандарт не устаканился (и документации нет) пилить что то не советую.

Для прохождения валидации уже не хватит процессора малинки (но апдейт это исправляющий уже вышел и прошла валидация, пока безрезультатно, разрабы что то пилят), желательно ssd вместо hdd да и памяти надо больше 1гб, очень кушает сетевой трафик (в месяц больше терабайта в обе стороны), но тут можно пользоваться shared node (бесплатно никто не выкладывает доступ но вроде дешево) и проходить валидацию в браузере, хоть с телефона, майнить кстати тоже можно делегировать кому-то, но публично пулов я не видел, надо договариваться.

p.s. на прохождение валидации тратится (сейчас раз в ~2 недели) примерно пол часа.
1 аккаунт даст с майнинга в сутки примерно 0.25 центов, за прохождение валидации от 0 до 20$ (каждый успешно выданный инвайт может принести в конечном счете ~20-30$, на это уйдет 3-4 валидации, каждую валидацию аккаунту дают по 1 инвайту, если ты human, плюс если скор высокий еще одну.

при не заскорузлых мозгах и большом везении можно тянуть два аккаунта

p.p.s. с каждой валидацией увеличивается количество желающих (10k+ как раз последняя принесла и в криптоэкономике это много, ибо даже в худшем, половина реальных активных людей) и уменьшается доход пропорционально, так же увеличиваются требования к машине, если год назад все работало чуть ли не на калькуляторах, то теперь дешевых 1$ vps-ок уже не хватит, я видел пример когда на старенького фенома уже нехватало

Не сказано про требования точности и скорости съема.

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

для хрома вроде можно
отпишись тут если это работает

у вас поворотная дверь? легко - серия блоков (можно найти в мебельной фурнитуре но дешевле колхозить самому из самых дешевых подшипников и на 3d принтере напечатать колесики), чрез которые протянуто соединенное в кольцо бечевка, желательно которая не тянется, зафиксированная на двери и она же обернута вокруг вала обычного коллекторного двигателя за пару сотен рублей 12в-24в (его придется как то защищать от влаги и перепадов температур), в идеале чтобы одна и та же бечевка была соединена с дверью снизу и с верху, чтобы не было перекоса. Направление вращения двигателя определяет порядок подачи тока +- (меняется трехпозиционным парным переключателем либо двумя двухпозиционными), при клине двери бечевка на блоке двигателя просто прокручивается, ничего не повреждается.

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

opencv в общем случае, там есть все по распознаванию видео, и все будет зависеть от того, как именно вы будете фиксироваться на объекте. Не пытайтесь в реалтайме детектить сложные вещи, даже в идеальных условиях это медленно (десятки кадров в секунду) и не позволят следить за быстрыми источниками. Сразу ищите камеры 60-100 fps и я боюсь не каждый android телефон даст вам такой быстрый сенсор (даже дорогие используют аппроксимацию и в реалиях дают fps в половину заявленного) и главное вам тупо не хватит железа android на обработку изображения с необходимой скоростью.

Доступ к камере - native camera api

Самое простое реализации и потреблению ресурсов - разместить на объекте уголковый отражатель и выбирать источник света с максимальной интенсивностью, у камеры светильник (рекомендую добавить светофильтр, чтобы минимизировать фальшивый источник).

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

p.s. на сколько я знаю красивого стандарта на управление поворотными камерами нет, точнее он есть у каждого производителя свой, с другой стороны, можно воспользоваться готовой админкой у дешевых для домашнего использования, отреверсить http запросы и слать их из своей программы.

У вас основная проблема — механика.
Даже собрав на базе любого микропроцессора (хоть к тому же обычному компьютеру по LPT цепляйте через драйвер шаговые моторы) ваша конструкция может вносить погрешности — т.е. соскочил зубец в редукторе, погнулась 'балка', да банально разная температура и соотв. температурное расширение и камера уже смотрит не туда.

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

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

Я могу предложить самую простую и оригинальную — закрепить лазерную указку/или зеркала, отражающие ее свет таким образом, чтобы движение светового пятна по стенам комнаты (лучше соорудите специальные экраны, с правильными углами для облегчения расчетов) а положение этого пятна отслеживать видеокамерой и очень простым софтом (его даже и на ардуине написать можно, считывая информацию с видеосенсора, получающего изображение через светофильтр, подобранный под цвет указки, гуглить 'arduino слежение за источником света') либо приспособить для этого обычный компьютер и несколько дешевых вебкамер (выбор которых определяется скоростями, с которыми будет поворачиваться камера)

Количество лазерных указок подбирается под количество свобод, в которых должна двигаться камера, например две свободы (поворот верх/низ, влево/вправо) — один луч.

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

Самый простой сортировщик предметов — воронкообразная центрифуга, Для таких предметов как бусины обороты очень маленькие (в зависимости от формы, плотности и веса объекты будут 'докатываться' на разную высоту).

Иногда можно обойтись купанием предметов в жидкости, она уменьшает влияние тяготения и облегчает методы сортировки той же центрифугой (посмотрите как ведут себя предметы в водяной воронке). А уж для предметов на грани равенства плотности воды можно неплохо рулить глубиной их погружения, просто меняя давление в емкости с водой, а там, собирать нежные/ненужные предметы ситом.

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

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

p.s. А для зрелищности можно соорудить роботизированную руку и обучить алгоритмы компьютерного зрения для вашей конкретной задачи.