roboforum.ru

При 3-5 датчиках подход конечно может прокатить, но зачем всё наворачивать так, если это нельзя будет адекватно масштабировать до 20-30 датчиков потом?

Там же по хорошему надо к каждому измерению Timestamp прикладывать, если всё правильно делать.

Короче или на коленке собранная система будет несерьезная, или мало датчиков будет держать, мне так кажется.

как же тогда вообще данные с датчиков собирать, если так плохо будет с ресурсами? Тогда и DSS не поможет - не опрашивать же все датчики с высокой частотой через канал?

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

SMT писал(а):как же тогда вообще данные с датчиков собирать, если так плохо будет с ресурсами? Тогда и DSS не поможет - не опрашивать же все датчики с высокой частотой через канал?

Почему бы не опрашивать их с высокой частотой?

1. только данные команд (без учета сервисных данных и ответов): 20 датчиков по 10 байт на команду (по 8 бит байте) это 1600 бит. Даже при скорости канала 9600 бит в секунду похоже реально опросить их все за секунду н(меня это смущало). понятно, что там всякие паузы есть. Я ничего не путаю? Если так, то вы правы (тем более, что скорость можно и 115к установить при необходимости).
2. по протоколу команда заканчивается символом "*" и "\n"?
3. МК после выполнения команды ожидает следующую из UART-а ("отвлекаясь" на прерывания)?.
4. протокол аналогичен в OpenRobotics? Если да, то что имеется ввиду под пометкой

команды длиной 9 байт можно дополнять "00", например, вместо "QFF002002" разрешается отправлять "QFF00200200"

я не потрещать - пробую к своей софтине управляющей прикрутить

SMT писал(а):1. только данные команд (без учета сервисных данных и ответов): 20 датчиков по 10 байт на команду (по 8 бит байте) это 1600 бит. Даже при скорости канала 9600 бит в секунду похоже реально опросить их все за секунду н(меня это смущало). понятно, что там всякие паузы есть. Я ничего не путаю? Если так, то вы правы (тем более, что скорость можно и 115к установить при необходимости).

Ну да, разумеется реально их быстро все опросить. А вообще я прикручу потом еще к протоколу возможность снять инфу сразу со всех датчиков, типа читать по i2c кучу данных за 1 запрос. Тогда можно будет отправлять 1 запрос на чтение 20 датчиков путём получения 20 байт подряд завёрнутые в небольшую шапку ответа, а значит на чтение 20 датчиков будет уходить не более 40 байт, а это 320 бит всего, хоть 30 раз в секунду можно будет опрашивать.

SMT писал(а):2. по протоколу команда заканчивается символом "*" и "\n"?

\n

SMT писал(а):3. МК после выполнения команды ожидает следующую из UART-а ("отвлекаясь" на прерывания)?

Ага.

SMT писал(а):4. протокол аналогичен в OpenRobotics? Если да, то что имеется ввиду под пометкой

команды длиной 9 байт можно дополнять "00", например, вместо "QFF002002" разрешается отправлять "QFF00200200"

я не потрещать - пробую к своей софтине управляющей прикрутить

Аналогичен на 100%, вот только какие там порты прописаны - я не знаю
Надо сорцы смотреть. А про 9-байт и приписки - это у меня терминал глючил на 9-10 байтовых командах, вот и пришлось извращаться, считайте, что приписки нету, надо переходить на другой терминал или этот лечить. В выходные займусь, наверное.