Как перестать гадать, что сегодня /dev/ttyUSB0: стабильная работа с USB в Linux Ubuntu

[vdudouyt]

Раз уж весь процесс "привязывания" заключается в создании симлинков, почему нельзя сразу открывать в софте по /dev/*/by-path/* вместо /dev/cam_left и иже с ними (к тому же, как я понимаю, все равно не сильно стандартные) - и не городить лишний конфиг, скрипт и юнит systemd?

[Stepan_Burmistrov]

Причин тому несколько: читаемость ссылок в коде, удобство использования стандартных пакетов для лидаров в ROS2 (конечно, переопределить параметры запуска, можно, а зачем?)

[ky0]

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

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

[ptr128]

Лично для меня идентификация только по by-path не кажется удобной, так как при наличии большого количество устройств не очень-то поймёшь, куда какой воткнул.

Зато, для примера, ESP32-С3 замечательно идентифицируются по серийному номеру, что позволяет давать произвольные имена устройствам.

Bus 001 Device 015: ID 303a:1001 Espressif USB JTAG/serial debug unit
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 [unknown]
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x303a Espressif
  idProduct          0x1001 USB JTAG/serial debug unit
  bcdDevice            1.01
  iManufacturer           1 Espressif
  iProduct                2 USB JTAG/serial debug unit
  iSerial                 3 80:65:99:2D:19:64

На всякий случай, приведу пример использования. Создаем файл /etc/udev/rules.d/91-esp32.rules с содержимым:

  ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="303a", ATTRS{idProduct}=="1001", ATTRS{serial}=="80:65:99:2D:19:64", SYMLINK+="gate_control_dev_1"

Перезагружаем правила udev

sudo udevadm control --reload-rules

Подключаем ESP32-C3 с серийным номером, указанным выше и видим симлинк /dev/gate_control_dev_1

[ptr128]

В случае отсутствия серийного номера, как для CH340, действительно приходится ориентироваться на by-path. Но для этого тоже достаточно udev. Например:

ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7522", DEVPATH=="*/usb1/1-3/1-3:1.0/*", SYMLINK+="ch340_on_USB3-2"
ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7522", DEVPATH=="*/usb1/1-4/1-4.4/1-4.4.3/1-4.4.3:1.0/*", SYMLINK+="ch340_on_USB3HUB-6"
ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7522", DEVPATH=="*/usb1/1-4/1-4.4/1-4.4.4/1-4.4.4:1.0/*", SYMLINK+="ch340_on_USB3HUB-7"

Тут первая строка - для встроенного в мой ноут второго порта USB3.0. Вторая - для шестого порта внешнего семипортового USB3.0 хаба. Третья - для седьмого порта того же хаба.

[aeder]

Идентификация по серийному номеру (или, например, MAC-адресу) имеет один существенный недостаток - надо настраивать для каждого экземпляра устройства.

Т.е. если вы делаете девайс с тремя сетевыми платами, серийно делаете, хотя бы по 100 штук в месяц - вас задолбает привязка по МАС-адресу каждой платы в каждом девайсе.

А ещё при ремонте - плату заменил, меняй правила в udev. А меняет - местный персонал, который открутить-прикрутить может, а вот прописать правило в udev - нет.

Это как минимум чрезвычайно неудобно.

--------------------

Можно конечно скрипт написать, типа "вставьте кабель/нажмите/где лампочка зажглась скажите" - который бы позволял более-менее автоматизировать привязку по серийнику. Но всё равно неудобно.

[ptr128]

неудобно

Это субъективно и зависит от контекста. При этом я специально указал, как при помощи того же самого udev делать идентификацию не только по serial, но и по devpath. Вы возражаете против свободы выбора?

[anoldman25]

Спасибо. Честно говоря мне эта мысль не приходила в голову. У меня сейчас 6 серийных устройств, все время в них путаюсь.

[el_mago]

Практический вопрос: если исключить переходники с одинаковыми VID/PID и добавить подключение устройств не в те порты + переезд на другой вычислитель, то насколько такой подход удобнее предварительного программного опроса и последующего изменения путей в конфигурации перед запуском робота?
Зачем вы лидар в нижней части расположили?

[Stepan_Burmistrov]

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

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

Я у себя в канале рассказываю про этот и другие проекты. Если интересно, добро пожаловать!