​​Наконец-то!

​​Всё-таки я умудрился ошибиться на таких простых платах и пришлось поработать ножом и паяльником.
После детальной проверки выложу герберы плат для заказа.

​​Один танк полностью готов.

Датчик положения MPU6050 состоит из гироскопа, акселерометра и датчика температуры.
Датчик температуры позволяет контролировать нагрев внутренних компонентов при зарядке и не дать перегреваться аккумулятору. Литиевые батареи этого не любят и у них снижается ёмкость.
Интегрирование данных акселерометра даёт линейную реальную скорость танка с небольшой точностью, а пики ускорения помогут в будущем определять столкновения и их направление.

​​На данный момент я получаю от танка:
Напряжение аккумулятора (косвенно помогает оценить оставшийся заряд) и статус зарядки (заряжается или нет);
Время работы с последней зарядки или с момента включения;
Температуру внутри;
Вращение по вертикальной оси относительно начального положения;
Линейную скорость вперёд или назад;
Выходное значение ПИД-регулятора коррекции направления.

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

​​Пока нет времени заниматься танчиками, но обещаю, что скоро доделаю.

Пару дней назад сделал игрушку для ребёнка, который любит нажимать кнопочки и крутить колёсики:

​​Я использовал ардуину, кусок RGB-светодиодной ленты и колесо с энкодером от компьютерной мыши.
Исходники и другие фото доступны в репозитории.

​​Скетч использует библиотеку Adafruit NeoPixel для управления светодиодами и мой код работы с инкрементальным энкодером. Свой потому, что не устроили готовые библиотеки. Мне нужно было обновление положения энкодера при каждом щелчке и работа по прерыванию.

В коде я использовал функцию выделенных внешних прерываний INT0 и INT1, которые висят на пинах D2 и D3 МК ATMega328p. Механический энкодер от мыши коммутирует эти пины на землю, а в состояние 1 они возвращаются внутренним резистором подтяжки к напряжению питания. Подтяжка включается записью 1 в порт этих пинов, как если бы они были выходами (строки 49 и 50 в коде).

​​Оказывается я не могу писать в канал регулярно, поэтому буду писать нерегулярно.
Написал материал про то, как я пошатал API TJournal весной: https://tjournal.ru/flood/124066-shiryaev-byl-v-yarosti-kogda-uznal

Сегодня вечером (в восемь по Мск) вместе с профессором Новиковым обсудим «Ирландца», я последний раз побомблю с Death Stranding, а также разберем ситуацию вокруг законопроекта о профилактике домашнего насилия.
https://www.twitch.tv/petyancast

Трудно заставить себя делать что-то регулярно, но постараюсь обновлять канал чаще.
Промежуточные результаты на данный момент:
1. OpenCV на raspberry Pi zero W еле шевелится, распознавание цветных пятен в кадре 320x320 при 10 к/с грузит единственное ядро на 100%. Пока попробую rpi 2 B, может перейду на rpi 4 или x86.
2. Стрим H264 в браузер с низкой задержкой работает только с кастомным декодером видеопотока (один из вариантов), нативно браузер будет буферизовать поток с задержкой в несколько секунд.
3. Стрим MJPEG даёт не намного большую задержку, зато работает и в мобильных браузерах и не требует обработки случаев подключения в середине трансляции. Для rpi и её камеры я сделал демку. Почти все похожие демки перед отправкой кадра конвертируют его в base64, что в полтора раза увеличивает трафик, у меня же кадры передаются в бинарном виде и без лишней нагрузки на процессор. Пример может быть интересен тем, кто хочет передавать бинарные данные через вебсокеты.

4. Билдить OpenCV на самой малине могут только мазохисты. На Zero этот процесс занимает от 12 часов. На наше счастье есть вариант кросс-компиляции.

5. Теперь у меня есть герметичная камера с хорошим освещением и размерами поля 50х50 см. Любая открытая конструкция засирается пылью и шерстью кошек, которая потом наматывается на движущиеся детали машинок.

6. И 3D-печатные ходовые части с колёсиками от лего или гусеницами. Гусеничная имеет размеры 45х45 мм.

Поставил на RPi2, добавил тестов. Выяснилось, что я скармливаю OpenCV кадры в неправильном формате и около 60-70 мс занимает только парсинг JPEG 512х512 точек. Три из четырёх ядер загружены на 90% каждое и это ещё нет никакой обработки. С камеры можно получить raw данные в нужном формате (BGR), их и попробую. Буду держать в курсе.