Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 14

Поставлю плюс, но хочу порекламировать

  • немного селфдрайвинга https://github.com/fubarlabs/foocars

  • свой опыт изготовления масси с минимизацией покупных компонентов (только подшипники, болты и двигло) https://github.com/fablab77/printed-car-chassis/tree/v1

Если не ошибаюсь, то видел ваш проект. Но там teensy, которую и раньше не просто было достать и tensorflow 1x версий.
Возможно, он (проект) уже шагнул дальше. А так - задел большой!

В опубликованном – да.
foocars я не мейнтейню, но сделать форк на TF2 / pytorch можно (и даже нужно).

С Teensy без проблем можно перейти на атмегу32 (опубликую, оно уже готово) или BluePill (с кодом чуть поаккуратнее нужно будет быть). К счастью, оно всё в Platformio давно, и никуда там не упирается в ресурсы

Задел кое-какой есть, но проект принципиально учебный (одна моделька между камерой и управляющими командами Speed/Turn). В реальном селфдрайвинге всегда архитектурный ад разводят, будь то ROS, TCS-AD или что-то менее публичное. Но оно позволяет ряд ситуаций отработать по жёсткой логике, а остальное – предсказуемо изолированно обучать.

У вас на фото стрелочка "драйвер" указывает на ESC, который к управлению сервой вообще не имеет отношения

с чего вы взяли, что не имеет отношения ? вот провод от драйвера (esc) на серву.

Этот провод идёт на приёмник. Питает его и серву. И сигнал с приёмника идёт по этому же проводу на esc

А, кажется я понял. На фото с подписью не ваша машина. Там видно ESC, приёмник и серву. На вашей машине мог быть ESC совмещённый с приёмником. Ну и bts7960 не смог бы управлять двигателям с того фото.

И главный вопрос. У вас получилось нормально ездить на ней? Такие машинки медленно не ездят. А у вас тормозная камера и тормозной энкодер, которые сами по себе дают задержку около 50мс...

Нормально ездить получилось, но есть нюанс. Камера, не высокоскоростная, это факт. А что про энкодер вы имели в виду ?

Обычно в таких системах измеряется время glass to glass - от момента начала сканирования матрицы до вывода полного кадра или первого пикселя.

Выбранная вами камера медленно сканирует и отдаёт картинку. А HW видео энкодер во всех raspberry до жути медленно кодирует каждый кадр. То есть он успевает реалтаймово кодировать, но это слишком долго и вносит существенную задержку

Интересуюсь для личных задач: хорошо бы иметь удаленное управление машинки типа Go-Getter, "пойди-принеси" на разные задачи.

Вопрос к размерам и ходовой: почему использовали маленький размер корпуса и ходовой? Ведь, если нужно полностью автономное управление, это ненадежная конструкция. Перевернулся и все.

Насчет автономности: были ли мысли добавить зарядное устройство для подзарядки батарей? Типа как на автономных пылесосах.

Насчет удаленного управления: использовать симку накладно.
А что если врезаться в ближайший Wi-Fi?
https://habr.com/ru/articles/814495/

Нет, конструкция не подразумевает полностью автономное управление.
Мысли добавить зарядное устройство были, но размер солнечной панели не устроил. Да и цели не те.
Про симку постараюсь во второй части не забыть.
За врезаться в ближайший wifi по ссылке в статье, если он к тому же чужой, можно получить а-та-та.

Вам надо связку ardurower + ros. Там и поддержка лидаров и всякого разного есть

Сразу оговорюсь: я не настоящий механик.

Но позволю вставить свою 5 копеек. Как по мне, одноплатник (почти любой подходящий) стоит довольно дорого. И в то же время весьма тормознутые они. Я бы взял какой-то Android-смартфон. Здесь на борту уже и более менее вменяемая камера, модем и GPS. И стоимость такого на вторичном рынке близка к стоимости одноплатников, даже б/у. А по производительности и функциональности они существенно лучше.

Связь с машинкой можно организовать как по Bluetooth, так и по надежнее, используя USB-OTG.

Возможно я ошибаюсь, но в целом не сильно сложно захватить поток с камеры и выдать наружу по rtmp. Да хоть в Zoom или напрямую на YouTube/Rutube. Попутно по WebSocket туда/обратно гонять пакеты с координатами, управлением, скоростью, зарядом батареи и т.п

Для работы с USB я бы выбрал что-то типа STM32F103 (F401?), у этих камней и производительности за глаза и аппаратный USB с поддержкой Custom HID. Это чуть ли не единственный довольно простой способ обмена по USB в плане разработки ПО для камня и для Android.

Бонусом можно получить даже обе камеры (основную и фронтальную) и видеть, что происходит за машинкой. Мало ли кому в голову взбредет за ней погнаться или что-то сделать. Или те же животное часто не здоровый интерес проявляют к такого рода объектам.

Возможно смартфон можно и раздеть (по типу как делают т.н naked GoPro) и тогда все это дело будет к тому же компактным.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации