Pull to refresh

Comments 23

radio.setPALevel(RF24_PA_HIGH);

За это нужно по пальцам бить. Почему во всех ардуиновских проектах на NRF24L01 выставляют высокую/максимальную мощность передачи, на расстояние передачи в пределах комнаты, и это при том что сам модуль может бить чуть ли не на километр.

А в чем проблема, если модуль работает на высокой мощности?

В том, что нет смысла бить на большую мощность забивая этот канал, мешая другим устройствам. 2.4ГГц это не только NRF24, это еще и WiFi, и BlueTooth.

В пределах комнаты (и даже квартиры с бетонными стенами) более чем хватает минимальной мощности.

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

Однако в пределах всего нашего помещения сигнал добивает только на высокой мощности.

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

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

А вы проводили тесты с разными версиями NRF?

С тремя разными:
0. nrf24l01+(как в статье)
1. nrf24l01+PA+LNA(у него ещё sma антенна отдельная)
2. nrf24l01 на 27 dBm от Ebyte (у них есть как с SPI, так и UART)
По-сути везде одинаковая микросхема трансивера (https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf). Только обвязка отличается. Но основная цель проверки заключалась в измерении максимальной дальности, поэтому они всегда работали на максимальной мощности и я особо не задумывался о том кому они там мешают. Самый мощный, на 27dbm, при постоянной передаче не мешал WiFi роутеру (либо я не заметил). Канал для nrf'ки я выбирал с минимальной загруженностью, поэтому скорее всего они просто были достаточно хорошо разнесены по частоте. Про bluetooth сказать ничего не могу, но он автоматический "скачет" по частотам в поиске менее загруженной, а значит просто так nrf'ка ему мешать не может (при адекватном использовании).

Вы не пробовали после отладки на компьютере перенести реализацию машинного зрения непосредственной на мобильную платформу, используя MicroPython, например?

Можно, конечно! Только вот с рукой бегать за мобильным роботом будет не сильно удобно)))
А так, можно и не microPython, а любой orangePi.
Связать с Arduino можно по uart или по SPI (https://habr.com/ru/articles/708844/)

Можно, конечно! Только вот с рукой бегать за мобильным роботом будет не сильно удобно)

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

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

А почему бы orangePi Zero не взять для этой задачи? Маленький, быстрый. Для такой задачи вполне подойдет.
А Arduino для управления аппаратной частью.

Так там вроде полноценный питон. В Распберри Пай точно, а в Зеро не знаю.

Да, там линукс можно поставить и нормальный питон. И все запустится ?

А в вашей статье питон-часть на чём играет? Я что-то не понял. На PC?

А зачем ардуина? У него же есть GPIO, ну или по I2C например через PCF8574 управлять.

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

но на практике: на питоне выполняются высокоуровневые команды,

Например управление I2C через модуль python-smbus. Например: SMBus: Работа с I2C на Python в Raspberry Pi/BPI/OPI - MicroPi (micro-pi.ru)

Например для управления шаговыми двигателями нужно соблюдать интервалы между сигналами очень точно

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

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

Обмен данными по SPI между Raspberry Pi и Arduino https://habr.com/p/708844/

И тут есть еще один момент-это стоимость компонентов и минимизация потерь в случае ошибок подключения. Поэтому для роботом с двумя уровнями управления-мой выбор uart или spi

Прикольно построено изложение. Статья про управление жестами. Единственная схема - схема питания. А где камера? На фотках что угодно, но камеры нет. Какая модель, какие параметры камеры? Неужели радиомодуль и питание в статье про управление жестами важнее камеры?

По жестам - представленные жесты для управления вправо-влево, вперёд-назад не особо интуитивны. А не пробовали управлять, например, направлением указательного (или большого) пальца? Это возможно?

А камера вообще любая вебка, даже самая дешевая.

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

Sign up to leave a comment.

Articles