Тест на погружение
На прошлой неделе я сделал первый тест на погружение основных деталей рамы, двигателей и электроники. На борту не было никакой важной электроники, кроме плат ESC. Цель состояла в том, чтобы убедиться, что вода не проходит во внутрь.
К счастью, у меня есть ванна на заднем дворе, поэтому тест был очень прост.
Я доволен экспериментом так как потеков воды внутри емкостей я не заметил.
Основная плата: Версия 1.1
Версия 1.1 основной платы прибыла несколько дней назад. Я заказал ее у DirtyPCBs некоторое время назад, но из-за китайского праздника потребовалось немного больше времени для доставки, чем обычно. Основной целью V1.1 было убрать различные ошибки от V1.0, а также добавить чип мультиплексора I2C. Это обеспечивает две полезные функции: 1 – он обеспечивает некоторую степень защиты “Малины”, когда я возился с устройствами I2C в ROV, а 2 – позволяет мне обрабатывать конфликты адресов, размещая устройства I2C с одинаковым адресом на разных шинах. У V1.0 был конфликт адресов, когда я попытался добавить датчик давления воды – адрес столкнулся с датчиком влажности / давления / температуры. В V1.1 я переместил последний датчик на его альтернативный адрес, но я хотел добавить дополнительную безопасность для будущей разработки .
Новая плата, установленная на raspberry pi с платой Tenda, (видна ниже) и это эта связка работает !
Первые фотографии кабины пилота ROVa
В настоящее время кокпит находится в режиме «моно» (т.е. Не используется стереокамера) … что можно увидеть на фото выше. Справа вы можете увидеть различные фрагменты информации:
- Текущее использование процессора и памяти
- Внутреннее (внутри воздухонепроницаемого корпуса) и внешнее давление
- Внутренняя (внутри корпуса) и внешняя (вода) температура
- Уровни напряжения питания и потребляемый ток трех источников напряжения
- Статус судна
- Кинематика – это состояние ИДУ, которое будет откалибрована при погружении
- Баланс вкл / выкл – автоматическая балансировочная система, которая удерживает уровень и устойчивость аппарата
- Глубина – глубина судна, рассчитанная на основе внешнего давления и плотности воды
- Вода – пресная или соленая вода
- Здоровье – общее состояние здоровья
- Ошибки отображают любое сообщение об ошибке, зарегистрированное на судне
Центр- искусственный горизонт и компас. Искусственный горизонт (средний бит) показывает текущий шаг. Компас (вокруг края) показывает направление.
Вся инструментария построена с использованием «three.js», основанной на Javascript 3d-моделирующей библиотеки, которая работает в браузере. Я выбрал этот вариант, потому что он позволяет мне легко переключаться в режиме 3D. Вы можете видеть это ниже (хотя это все еще нуждается в некоторой настройке, потому что я фактически не подключил свой VR Rift, чтобы проверить все это):
На этом изображении используются две камеры, в то время как three.js дублирует инструменты на основе их положений в трехмерном пространстве.
9 килограмм
Взвесив свой ROV на весах я получил значение в 9 кг. Безусловно, самыми тяжелыми являются батареи, алюминиевые торцевые крышки и платы ESC. В планах провести еще раз тесты, как в прошлый раз, мне придется увеличить вес, чтобы сделать его нейтрально плавучим
Новый контейнер для аккумуляторов.
Ниже представлен новый контейнер для батарей. Оригинальный был сделан из 2-дюймовой трубки от Blue Robotics. Новый – 3-дюймовая трубка от Blue Robotics . Батареи слегка не вписывались в старую трубку, и после того, как были добавлены различные другие части соединительного оборудования, установка еще больше усложнилась, отсюда и новая трубка.
Испытания ROV
Ниже находится полностью собранный RGB BorgCube. Завтра я погружу его в воду и посмотрю, то ли он тонет, то ли плавает.
Испытание воды
Итак, вот полностью собранный робот в ванне с водой. Как вы можете видеть на фотографиях, он плавает, чего мы и добивались, в ходе испытаний было выяснено что нужно будет добавить вес, для того чтобы аппарат более уверенно погружался.
Проблемы с ИДУ
Устройство IMU необходимо для ROV для поддержания баланса корабля. Тем не менее, IMU, который я использую, часто теряет калибровку в неожиданные моменты. Как ни странно, это особенно заметно, когда я включаю свет! Просмотрев мой дизайн печатной платы, 12-вольтовая дорожка, которая передает свет, проходит в пределах 10 мм от ИДУ. Я не видел никаких замечаний по дизайну плат от Bosch относительно размещения устройства, но мне кажется, что это слишком близко.
Требуется больше экспериментов и точного выявления проблемы, но я намерен разместить дополнительное ИДУ в передней капсуле где расположены камеры. Посмотрим, как они сработают вместе.
Двойные ИДУ и Средство Циркуляров
Сегодня я добавил дополнительный IMU на переднюю панель ROV. Я еще не уверен, получится ли исправить эту проблему.
Второй ИДУ я купил у Adafruit и он установлен в передней трубе на одной и той же несущей конструкцией камеры. Электрически и магнитно он находится в совсем другом месте. Он сидит на шине I2C, используя свой альтернативный адрес.
Сегодняшний урок состоит в том, что вы не можете просто усреднять углы и рассчитывать на правильную работу. Например, если вы делаете простой средний арифметический результат 359 и 1, вы получаете 180, когда фактический угол, на который вы надеялись, равен 0. Получается, что к средним углам вы должны считать это с использованием векторов (см. https://en.wikipedia.org/wiki/Mean_of_circular_quantities ), который теперь выполняет код.
BNO005 и ошибка малины Pi I2C
Существует длинная документированная ошибка во всей версии Raspberry Pi (включая, по-видимому, новый v3), в результате чего шина I2C не работает в спецификации. Для тех, кто не знает, шина I2C поддерживает понятие «растяжение часов», которое позволяет либо главному подчиненному устройству замедлять связь, если один конец не может идти в ногу. Большинство устройств I2C не используют это, потому что они могут поддерживать все в норме, но устройство BNO055 использует растяжение часов, а малина Pi не справляется с этим.
Результатом этого в моем ROV является то, что иногда я получаю плохие данные от ИДУ. Эти плохие данные проявляются двумя способами: 1 – я просто возвращаю 0; и 2 – последний бит 16-разрядного чтения устанавливается равным 1, когда ему должно быть 0. К сожалению, по какой-либо причине немедленное повторное чтение данных обычно не приводит к хорошим результатам; что заставляет меня думать, что BNO055 занят внутренним и не может ответить мне правильно прямо сейчас … но кто действительно знает.
В идеальном мире я придумал решение, чтобы шина I2C работала правильно на малине Pi, но пока это не происходит, мне нужно иметь дело с этой зараженной ошибкой данными. Мой первый план состоял в том, чтобы просто отказаться от этих плохих показаний. К счастью, их легко заметить, потому что чтение всех 0 для подачи заголовка и ролика очень маловероятно, а высокий бит будет установлен радианным значением больше 2 * pi. К сожалению, эти ошибки происходят достаточно часто, и в итоге я получаю большие пробелы в потоке данных, что не облегчает балансировку ROV.
По крайней мере, работая в радианах, устройству нужно вернуть только 14-значные данные высоты тона и заголовка. После некоторых экспериментов кажется, что малина Pi может, по крайней мере, получить эти данные до того, как возникнут какие-либо ошибки. Если я просто использую эти 14 бит, поток данных будет почти идеальным (случайные наборы 0 все еще встречаются, но не так редки, чтобы их можно было игнорировать).
Тем не менее, я предпочел бы, чтобы Raspberry Pi правильно выполнял протокол I2C.
Часть 4 —>
