Форум arduino.ua

Значит, я говорю про систему для несерьезных огородников :-)

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

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

Разве компилятор не выдает ошибку для case "A1"? Как оно вообще собирается?

Оператор case ожидает целочисленное значение. Это неплохо работает со следующей конструкцией, потому что 'А' фактически является числом 65 и C может свободно привести char к int, обратите внимание на одинарные кавычки.

switch (command) {
case 'A':
    functionA();
    break;
...
}

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

Касательно сути вопроса. Serial.read() возвращает всего один (первый) байт из буфера, поэтому чтобы обрабатывать больше, нужно либо сохранять прочитанные байты между вызовами loop(), либо читать весь буфер Serial в контексте одного вызова loop(). Также возникает вопрос, что произойдет, если передать две команды "А1" и "B2" подряд? Подозреваю - поправьте меня, пожалуйста, если это не так - что они будут прочитаны как одна команда "A1B2". А если два устройства будут заполнять буфер Serial одновременно, не возникнет ситуация, когда результат окажется чем-то вроде "AB12"?

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

Какое планируется количество кнопок?

Думаю, что для автоматического подруливания может пригодиться компас - магнитометр с акселерометром, например, LSM303AGR. Из-за покачиваний кораблика на волнах скорее всего нужно будет учитывать все шесть осей. Это проще обрабатывать с помощью одного из алгоритмов машинного обучения. Очевидно, что понадобится фильтр Калмана.

Увеличить дистанцию с nRF24 можно разными способами. Если есть прицельная видимость, то самый дешевый способ - использовать направленную антенну на передатчике. В зависимости от конструкции антенны это должно поднять уровень передаваемого сигнала в сторону кораблика в среднем на 6-9 Дб и, соответственно, увеличить дистанцию раза в два-три. С другой стороны, можно взять модуль nRF24 со встроенным PA/LNA. К тому же такие модули обычно имеют не только более чувствительные антенны, но и лучше держат ее настройку. Это добавит около 8-10 Дб к чувствительности приемника кораблика, что будет соизмеримо с результатом направленной антенны. Само собой, можно использовать оба подхода одновременно.

Ну и в качестве альтернативы, можно рассмотреть переход на Bluetooth 5, который регламентирует помехоустойчивое кодирование (coded phy) и увеличивает дистанцию где-то в те же самые два-три раза. Для этого понадобится заменить nRF24 на одну из микросхем серии nRF52, которая имеет поддержку long range. В контексте этой задачи имеет смысл сразу иметь поддержку Bluetooth 5.1 Direction Finding - кораблик тогда вернется назад, просто как на маяк в море. Это ограничивает выбор до микросхем nRF52811 для приемника кораблика (чувствительность около -97Дб), и nRF52820 / nRF52833 для передатчика. Но можно взять и все одинаковые, например, nRF52811 и иметь PA/LNA. В таком случае усилитель должен иметь возможность переключать антенны, чтобы полноценно работал алгоритм direction finding.

В теории, сочетание coded phy + усилители на приемнике (+10Дб) и передатчике (+20Дб) + направленная антенна (+10Дб) может увеличить энергетический баланс на +30..35 Дб и, соответственно, дальность Bluetooth раз в пятьдесят. Это может составить свыше 5 км.

Еще один вариант - это модули LoRa. За счет высокого энергетического баланса линии и помехоустойчивого кодирования дальность связи может быть до 10 км. При плохой связи задержка, однако, может доходить до нескольких секунд. Что, впрочем, на таких дистанциях в море может быть приравнено к управлению спутником в космосе :-)

Может быть, имеет смысл контролировать влажность и температуру почвы, воздуха? Датчики можно разместить даже на разной глубине. Кроме того, насколько я знаю, полив обычно проводится так, чтобы избежать попадания прямых солнечных лучей сразу же после полива (нужен датчик освещенности). Если нужно будет разместить систему в поле, то понадобятся сборщики и накопители энергии на солнечных батареях. В свою очередь Bluetooth 5 мог бы обеспечить хорошее покрытие на произвольной площади.

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

Обновлено: Возвращаясь к базовым требованиям, цена на Arduino и датчик дождя очень маленькая. Электромагнитные клапаны тоже не очень дорогие. Похоже, что основные задачи, которые нужно решить - это неблагоприятные условия и электропитание.

Вон оно чё, Михалыч...

Да вроде ж позволяет.

Ага, вижу, извините за невнимательность. Размер получается еще меньше!

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

"На показанных фотографиях [ширина цифр] равна 45 пикселям (Ymid), высота цифр 21 пикселям (Y_d)", и вы можете добавить порядка двух внутренних уровней по 16-20 узлов, а так же иметь один 10 разрядный уровень на выходе. Итого 45*21+2*20+10 = 995 байтов займет нейронная сеть. Плюс несколько десятков байтов на другие структуры. Само собой, веса тренированной сети прописаны в ПЗУ.

Суммирование операция простая, скорость тут тоже не требуется. Даже если цифра будет проворачиваться в момент получения фотографии и ее нельзя будет распознать, то через 5 секунд это уже станет возможным. С дополнительным контролем результата (число должно все время увеличиваться, цифры в старших разрядах не должны хаотично менять свои значения) можно избежать случайных ошибок. Кроме того, можно даже вести карту вероятностей появления каждой цифры - счетчик ведь работает предсказуемым образом. Она тоже займет порядка 10*N байтов, где N - количество разрядов на счетчике. Зато вероятность ошибки может быть получится свести чуть ли не до нуля.

REST service detected

Верно, спасибо, что обратили внимание - моя ошибка. Должно обойтись в семьсот долларов.

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