Модуль подводного ультразвукового дальномера. Часть вторая

    image

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

    Изменение №1: Временная автоматическая регулировка усиления (ВАРУ).
    В процессе тестирования первой версии модуля чётко вырисовывалась проблема зашкаливания отражённого сигнала от препятствий, находящихся близко к излучателю. Некоторые комментаторы к предыдущей заметке рекомендовали ВАРУ. Да, применение ВАРУ оказалось очень уместным. Теперь, в первые мгновения после посылки зондирующего импульса, есть возможность сделать коэффициент усиления минимальным и увеличивать его с течением времени.

    Реализация ВАРУ показана на схеме №1.

    ЦАП микроконтроллера генерирует напряжение, подающееся на затвор транзистора Q4.
    Для применённого транзистора экспериментально получена характеристика вносимого затухания, в зависимости от напряжения на затворе. На основе этой характеристики, и указанной пользователем параметров среды, рассчитывается таблица значений, которая посредством DMA отправляется в ЦАП микроконтроллера.

    Фактически, транзистор, работая в линейном режиме, частично замыкает полезный сигнал с выхода первого каскада усилителя на «землю», тем самым регулируя амплитуду сигнала, идущего в последующие каскады усилителя.

    image

    Изменение №2: Повышающий преобразователь для питания выходного каскада.
    Схема №2. Тут всё просто. Повышающий преобразователь позволяет сделать наш излучатель чуть «громче». Можно регулировать напряжение питания выходного каскада с 5 до 16 Вольт. Полезная штука для дальних измерений.

    Изменение №3: MEMS гироскоп/акселерометр.
    Схема №3. Встроили микросхему ICM20602. Это позволит получать не только информацию об уровнях отражения от объектов на пути луча, но и направление (угол) куда в этот момент смотрит модуль. Сделав простейшую развёртку модуля (хоть покрутив модуль рукой) можно получить реалистичную картинку объекта сканирования по принципу формирования изображения лидаром.

    К изменениям стоит ещё отнести применение более дешёвого, но не худшего усилителя MCP669-E/ML. Драйверы затворов тоже выбраны самые дешёвые из доступных TPS51604DSGR.
    Форма печатных плат сделана круглой, для более рационального размещения внутри металлического корпуса.

    Для компактности и постоянства характеристик от экземпляра к экземпляру, трансформатор изготавливается по планарной технологии.

    Железо готово. Что дальше? Наступает звёздный час программистов!

    Хоть основной низкоуровневый функционал уже проверен в работе (управление драйвером, работа с АЦП, ЦАП и т.п.), необходимо ещё реализовать удобное взаимодействие с хостом, создать и подробно описать API, дающий доступ ко всем возможностям модуля. Напомню, в качестве физического интерфейса для этих целей мы выбрали UART. И тут стоит упомянуть, что в команде появилось разногласие, на каком виде протокола стоит пока остановиться: на текстовом, или бинарном. С одной стороны, бинарный протокол – это быстродействие, простота обработки на стороне хоста. С другой стороны, текстовый протокол позволяет проще анализировать обмен данными (даже в «Гипертерминале»), и использовать осмысленные команды/ответы модуля. Вот небольшой пример взаимодействия с модулем используя текстовые команды в терминале Putty:

    image

    По нажатию клавиши TAB выводится список всех команд.

    Приведён пример использования команды YPR, которая возвращает текущее значение направления модуля по трём осям (углы Эйлера).

    Команда CHART возвращает значение отражённого сигнала от объектов на пути зондирующего импульса. Можно задать дискретность измерения (пока в сантиметрах) и количество измерений.

    Конечно, идеальный случай – поддержка обоих вариантов протокола, и текстового и бинарного. Но мы, к сожалению, во времени ограничены, и хотелось бы сразу направить усилия на более приемлемый для пользователей вариант. Отсюда скромная просьба: отметьте в голосовалке вариант, который был бы вам более удобен.

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

    P.S.
    Мнения по поводу контента для второй статьи внутри коллектива разделились: сухо, немного, но сейчас, либо ёмко, красиво, но потом… «Сейчас» победило.

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

    Сборка излучателей

    image

    Обработанные металлические корпуса

    image

    Корпуса с нанесённой лазером маркировкой

    image

    Сборка плат модулей

    image

    Only registered users can participate in poll. Log in, please.

    Предпочтительный вид API:

    • 45.4%Текстовый30
    • 54.5%Бинарный36
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 42

      +7
      Лично я предпочёл бы хорошо описанный бинарный протокол с дополнительной библиотекой на Питоне для «поиграться» (туда же можно будет сразу добавить простеньких визуализаций входящих данных). Кроме того, думаю, будет полезным в дополнение к протоколу «запрос-ответ» добавить ещё режим работы «постоянная посылка измерений», можете, например, ознакомиться с протоколом RPLIDAR. Ну и про контрольные суммы сообщений разумеется не забудьте.
        0
        Уверен, многие согласятся, что качественно описать и оформить протокол (с навигацией по разделам и с примерами) — это труд не сильно легче самой реализации протокола.
        Если создание качественного описания мы воспринимаем как неизбежное, то с примерами сложнее.
        О питонах известно лишь, что они обитают в тропических лесах восточного полушария… И зачем им ультразвук?
        А если серьёзно, то мы бы не отказались от помощи в создании примеров работы с модулем используя разные средства. Хоть Питон, хоть Ардуино, хоть МикроПаскаль.
        0

        Лучше реализовать оба протокола — и текстовый и бинарный, с возможностью переключения.

          0
          Назовите же сумму!
            0
            Себестоимость материалов для изготовления одного модуля перевалила отметку $40
            0
            Конечно два протокола удобнее. А если бы ещё и за разумные деньги купить устройство — всё пошло бы быстрее.
              +5
              После того как я начал работать с GSM-модемами, я понял, что текстовые протоколы в автоматической обработке — полный отстой :) Нет, я и раньше это подозревал, но вот тут прочувствовал в полной мере :) Так что я за бинарный :)
              Но в дополнение к нему можно внести и текстовый, потом когда появится время.
                0
                а что не понравилось?
                мне казалось, что минималистичный текстовый автоматизируется\разбирается\передается ненамного хуже бинарного, зато гораздо удобнее «смотрится вручную».
                  +6
                  а что не понравилось?

                  Громоздкость его обработки. Получив структурированный бинарный пакет можно просто наложить на него указатель соответствующей структуры — и все данные как на ладони. А текст приходится парсить, определять тип сообщения строковыми сравнениями, преобразовывать числовые величины из строк в числа и т.д. Особенное зло — асинхронные сообщения, вываливаемые в канал связи :)
                    0
                    ну, понятно, что я не про JSON\yaml, а про что-то уровня CSV (и форматирования а-ля дат\времен\координат).
                    Если к вам в середину одного бинарного пакета асинхронно «приедет» другой бинарный пакет — тоже ничего хорошего.
                    Единственные два минуса текстового — это преобразования чисел из строк и бОльший размер (опять же — из-за символьного представления). Но это не настолько уж и критичные минусы ИМХО.
                      +1
                      я не про JSON\yaml, а про что-то уровня CSV (и форматирования а-ля дат\времен\координат).

                      Так и я про простые на первый взгляд протоколы типа системы AT-команд :)
                      Если к вам в середину одного бинарного пакета асинхронно «приедет» другой бинарный пакет — тоже ничего хорошего.

                      Во-первых, такого просто не может случиться при прямом канале данных, а во-вторых в бинарных протоколах обычно предусматривается контроль целостности данных :)
                        0
                        так а что мешает добавить контроль целостности (base64\hex-поле) в текстовой?
                        при неизменной длинне сообщений (например при выравнивании нулями) можно также ориентироваться на служебные символы (те же разделители), т.к. их отсутствие\смещение — признак «порчи пакета»
                          0
                          Да можно, конечно, кто же спорит. Я ведь и не утверждаю, что текстовые протоколы неработоспособны, я говорю лишь о том, что для автоматической обработки они подходят гораздо хуже бинарных. Особенно в микроконтроллерных системах.
                          Текстовые протоколы имеет смысл делать для отладки или взаимодействия с человеком, но как рабочие при взаимодействии с микроконтроллерами — это отстой :)
                            0
                            В микроконтроллерных системах вообще любые подобные протоколы подходят плохо.

                            Там хорошо подходит модель с прерываниями и регистрами, по которой подавляющее большинство современных чипов и работает: дёрнулась ножка — проверил регистр статуса — прочитал регистр состояния.
                              0
                              Ну почему, работа в формате «запрос/команда-ответ/подтверждение» вполне неплохо работают и на микроконтроллерах. По крайней мере у меня было несколько реализованных проектов с подобными протоколами общения между модулями, все очень неплохо ложилось в линейную программу без всяких RTOS. Естественно, с использованием прерывания на том интерфейсе, который отвечал за канал данных.
                              Сейчас вот делаю девайс, который должен время от времени отправлять данные на сервер через модем и принимать от него запросы, команды, обновление прошивки и т.п. Тоже набросал типовой бинарный протокол с фиксированными заголовками, данными переменной длины и гарантированной доставкой пакетов. Все отлично работает, не напрягая микроконтроллер функциями типа strstr() и scanf() :)
                              По поводу «дернул ножкой» — да, я хотел написать, что этому измерителю не помешал бы выход прерывания, но не стал расписывать. Например, микроконтроллер дал ему команду измерить и занялся дальше своими делами, а модуль притянул этот свой выход к земле («занято»). Как только измерение закончено, модуль отключает притягивание этого выхода к земле («свободно»), запуская в микроконтроллере прерывание. Ну или микроконтроллер сам время от времени проверяет уровень этого выхода модуля и если обнаруживает что там единица, запрашивает у модуля готовые данные. Распространенное решение :)
                      +1
                      наложить на него указатель соответствующей структуры — ну это пока там нет полей переменной длины: строк, массивов и т.п
                        +2
                        Само собой. Но в бинарных данных все это решается гораздо проще, чем в текстовых.
                          +1
                          habr.com/ru/users/alexzeed
                          Откуда в простой железяке появятся случайные данные? Это-же не радиомодуль, это девайс с жёсткими фиксированными таймингами. Есть окно на отправку импульса, есть окно на приём. Мешать их нельзя, всю служебную информацию можно оправлять в каждом пакете с данными — там времени и места вагон.

                          Другое дело что ультразвуковой дальномер с одним излучателем/приёмником — это как-бы вчерашний день. Да, комплектующие свежие, точность чуть выше, но результат как у 100500 аналогичных устройств.
                          Имея два приёмника можно обнаруживать несколько объектов на линии горизонта — несколько самых громких и ближних. А если три приёмника — то уже в плоскости.
                          А три приёмника + три излучателя — возможность просвечивать интересующие вас участки пространства. На этом этапе однотоновая посылка становится мало информативной. А разбор ответа требует современных быстрых мк.
                          В этом случае заголовок бинарного пакета определяет его свойства — можно обрабатывать на лету.
                      +2
                      У модема проблема не в текстовости, а в полной асинхронности — когда у тебя ответ на запрос приходит через неизвестный промежуток времени, а иногда вместо него вообще приходит какой-нибудь RING.
                        0
                        Да, и я так и не придумал как малой кровью на 100% побороть это :) Когда, например, принимаемые бинарные данные обрываются текстовым сообщением «CLOSED» :)
                        Немало крови попило и то, о чем Вы пишете — когда ответ на запрос приходит не в виде:
                        <ответ>
                        OK

                        а в виде:
                        OK
                        (прошло какое-то время)
                        <ответ>

                        Или вообще:
                        OK
                        (прошло какое-то время)
                        <какое-то левое асинхронное сообщение>
                        <ответ>

                      0
                      Для применённого транзистора экспериментально получена характеристика вносимого затухания, в зависимости от напряжения на затворе. На основе этой характеристики, и указанной пользователем параметров среды, рассчитывается таблица значений, которая посредством DMA отправляется в ЦАП микроконтроллера.

                      Вы как-то учитывали разброс параметров транзистора и зависимость от температуры?
                        0
                        Спасибо за вопрос. Сейчас температура не учитывается вообще никак. Она, действительно, ощутимо влияет на параметры транзистора на границе открытия. К счастью, это всё можно учесть в прошивке. Темодатчики встроены в корпуса микроконтроллера и гироскопа/акселерометра.
                          +1
                          Да, но есть еще производственный разброс. Надеюсь вы проверили на нескольких экземплярах. Лучше было бы завести управление через real time обратную связь на МК как то, что бы вообще не зависеть от параметров транзистора. Вдруг текущий снимут с производства.
                            0
                            Вы описали идеальный случай. Я мог бы сказать, что у нас не осталось свободных каналов АЦП и т.д. и т.п. Но в реальности, высокая точность регулировки усиления не сильно тут важна, и мы не заботимся об этом сознательно, упрощая и ускоряя процесс разработки. Достаточно преодолеть порог открытия транзистора, и работать в пределах его линейного режима с небольшой погрешностью в итоговом коэффициенте усиления.
                              0
                              Понял. Успехов!
                        +2
                        Некоторые комментаторы к предыдущей заметке рекомендовали ВАРУ. Да, применение ВАРУ оказалось очень уместным. Теперь, в первые мгновения после посылки зондирующего импульса, есть возможность сделать коэффициент усиления минимальным и увеличивать его с течением времени.


                        Есть другой вариант — менять мощность выхлопа в ультразвук. Мы в дальномере с диапазоном 300...6000 мм, например, подаём на излучатель 5 импульсов, смотрим зону до 2000 мм, если там ничего нет — подаём 15 импульсов, смотрим 2000...4000 мм, потом 25 и 4000...6000.

                        И это помогает не столько с зашкаливанием на отражении от близких объектов, сколько с уменьшением собственного звона излучателя.

                        Повышающий преобразователь позволяет сделать наш излучатель чуть «громче». Можно регулировать напряжение питания выходного каскада с 5 до 16 Вольт


                        Можно проще — LC-контур из излучателя и индуктивности, возбуждаемый драйвером, вполне себе сам себе повышающий преобразователь, на котором можно развить 10-15 В. Очень дёшево и практично, минус — с температурой ёмкость излучателя меняется.
                          +1
                          LC-контур из излучателя и индуктивности это не очень хорошее решение, поскольку сделать так, чтобы его частота совпадала с частотой резонанса излучателя почти невозможно (в частности из-за температурных уходов). А излучатель, даже специально задемпфированный, это довольно добротная штука.
                            0
                            Есть другой вариант — менять мощность выхлопа в ультразвук. Мы в дальномере с диапазоном 300...6000 мм, например, подаём на излучатель 5 импульсов, смотрим зону до 2000 мм, если там ничего нет — подаём 15 импульсов, смотрим 2000...4000 мм, потом 25 и 4000...6000.

                            Этот метод рабочий, но, к сожалению, понижает полезную частоту обновления данных на выходе. Более того, большое количество импульсов в пачке снижает разрешение (детализацию). Например, было проверено, что два импульса в пачке при сканировании обычной стеклянной бутылки на расстоянии 40см дают отчётливую картину отражения сигнала от передней и задней стенок бутылки. Если увеличить количество импульсов до, примерно, десяти, то эти два отражения сливаются в одно.
                            Думаю, что увеличение именно мощности излучения позволит не терять в разрешении на более дальних дистанциях. Хотя понимаю, что бесконечно повышать мощность нельзя. Наступит момент, когда излишняя мощность будет просто съедаться кавитацией.
                            Про добротность хотел добавить.
                            Добротность нашего излучателя в воде, к счастью, никакая ))) Излучатель согласован неплохо, звон практически отсутствует. Большая часть энергии уходит в воду.
                              0
                              Да, с водой вам хорошо. На воздухе у обычного парктроника от пяти импульсов по 15 В звон на несколько миллисекунд, активным демпфированием его удаётся задавить до ~1,5 мс — и это будет слепая зона (нахождение в которой объекта у многих дальномеров даёт ложные показания).
                                0
                                активным демпфированием

                                Это вы в противофазе сигнал даёте?
                                  0
                                  Нет, неверно выразился — демпфирование само по себе пассивное (нагружаем на RL), активность только в том, что оно подключается на короткое время, а не висит на излучателе непрерывно.
                              0
                              Можно проще — LC-контур из излучателя и индуктивности, возбуждаемый драйвером, вполне себе сам себе повышающий преобразователь, на котором можно развить 10-15 В.


                              Как я заметил ранее, добротность излучателя крайне мала, так что резонансная система вряд ли будет эффективной.
                              Ну и когда я заявлял о диапазоне 5-16 Вольт, то речь шла о напряжении питания драйвера первичной обмотки повышающего трансформатора. На самом пьезоэлементе (подключен ко вторичке транса) амплитуда превышает 500 Вольт.
                              +1
                              Про использование Mavlink не думали?
                                +1
                                Из стандартных только об NMEA думали.
                                0
                                А Wake протокол не рассматривали? Вроде достаточно простой.
                                p.s. Не совсем по теме, но ни у кого не завалялся код асинхронного чтения com порта на Си и winapi(да, пока нужны свои велосипеды для понимания)? Застрял на этом месте, нет стабильного приёма.
                                  –2
                                  В протоколе, использующем UART:
                                  — передача текста использует XON/XOFF (0x11;0x13)
                                  — для передачи бинарных данных потребуется еще два провода/сигнала RTx;CTx, либо конвертировать bin<->hex
                                    +1
                                    Не мешайте в кучу логический и протокольный уровни. UART может передавать и принимать все что угодно без дополнительных линий и по любой логике, которую опишет программист.
                                    0
                                    Когда в прошлой жизни в моей конторе делали усилитель с ВАРУ (назывался ЛУВР — линейный усилитель с временной регулировкой), то в нем в обратную связь был включен ЦАП, который, в свою очередь, управлялся данными с ППЗУ с выборкой по временному регистру. Точность была очень высокой.
                                      0
                                      Ещё как вариант можно было сделать I2C потенциометр, который работал бы как аттенюатор для ослабления промежуточного сигнала.
                                      По габаритам занял бы столько же места.
                                      По управлению может было бы и проще. Тут надо экспериментировать.
                                      Так как Вы транзистор в линейном режиме используете, у Вас h21 будет влиять на работу.
                                      Я правильно понимаю, что от прибора к прибору значения напряжения, подаваемые с DAC на затвор транзистора немного разные?
                                        0

                                        Даже в мыслях не было ставить компонент, сложнее транзистора. Точность аттенюации здесь не важна особо. Ну будет не в 10 раз сигнал ослабляться, а в 9, или в 11 раз, не страшно. Главное, чтоб вся амплитуда выходного сигнала умещалась в диапазон измерения АЦП. Лучше, когда мы имеем небольшой коэффициент усиления, но при этом не упускаем детали, которые были бы не видны, если был бы сплошной зашкал.

                                          0
                                          Понравилось решение с планарным трансформатором.
                                          Делал подобный вариант, только у меня набор был из 4-х плат.
                                          Не расскажете вкратце, можно ссылку, по какому принципу проводили расчёт?
                                            0

                                            С трансформатором история такая:
                                            В первую очередь, выбирался сердечник. Выбор происходил из самых маленьких и доступных к заказу.
                                            Во вторую очередь, исходя из требований производства печатных плат были нарисованы дорожки вторичной обмотки с максимально возможным заполнением трёх слоёв платы. На первичку остался один слой. Количество витков первички — 1.5. Эта цифра была определена экспериментальным путём, на основе опытов с трансформатором предыдущей версии.

                                      Only users with full accounts can post comments. Log in, please.