Всем привет! Продолжаем занимать вас интеллектуальными задачами, и наша следующая — по мотивам фантастической комедии «Быть Джоном Малковичем»:
Примерно на 19-й минуте фильма Крег Шварц выясняет имя своей коллеги Максин, с которой он решил обязательно познакомиться. Крег произносит, казалось бы, нечленораздельную последовательность звуков «ваал-люуупэлюкааадашээрзуузээльмэммамайманмаксин» и следит за реакцией Максин. Алгоритм Крега понятен — после того как ему удается угадать первую букву имени, он видит положительную реакцию на лице Максин и переходит к следующей и следующей букве, озвучивая «мэммамайманмаксин». После четвертой угаданной буквы ему удается подставить полное имя из словаря.
Вопрос: сколько букв потребуется озвучить, чтобы выяснить методом Крега Шварца первые четыре буквы имени на русском языке? Будем считать, что имя из числа распространенных и не начинается на Й, Ь, Ы, Ъ, Ч, Ш и Щ.
При решении рекомендуем использовать поисковые системы, AI и Википедию.
Варианты ответов оставляйте в комментариях 👇 Я Павел Бузин — эксперт Cloud.ru по AI, машинному обучению и точным наукам, раскрою правильный ответ под этим постом 16 мая.
Хочу поделиться удобным сервисом для создания резюме. Изначально мы делали его как часть внутреннего продукта, но «Резюмеха» быстра выросла в отдельный сервис и теперь живёт своей собственной жизнью.
В отличие от популярных платформ, у нас всё по-человечески: никаких логотипов, пёстрых шаблонов, копирайтов и визуального шума. Все поля видны сразу, они интуитивно понятны и легко заполняются — потеряться в интерфейсе невозможно.
Формат — максимально читабельный и компактный. Мы постарались учесть всё, что может понадобиться для создания чистого и современного резюме. И, конечно, вы можете заполнить резюме как на русском, так и на английском.
Парни из AWS Fundamentals запилили каталог AWS анимаций. В настоящее время он включает в себя 14 сервисов и паттернов, но, ожидается, что команда будет добавлять новые еженедельно!
В текущем каталоге:
The Dark Reader Deployment Pattern
Polling vs. WebSockets via Amazon API Gateway
Running Code on the Edge with CloudFront
Adaptive Capacity with DynamoDB
Bidirectional Sync across Regions with DynamoDB Global Tables
Async vs. Synchronous Invocations at AWS Lambda
What’s Happening at a Cold Start in AWS Lambda?
DNS Resolution with Route 53
Region Failovers with Route 53 DNS Records
Multi-Region Routing with Route 53 Latency Records
Объявлено решении включить в состав выпуска GNOME 49 видеопроигрыватель Showtime, который станет поставляться под именем GNOME Video Player и будет задействован по умолчанию вместо видеопроигрывателя Totem (GNOME Videos).
Для желающих протестировать Showtime не дожидаясь осеннего релиза GNOME 49 подготовлен пакет в формате flatpak. Программа отличается минималистичным интерфейсом, отображаемым поверх содержимого и скрываемым во время просмотра. Поддерживаются типовые элементы управления, полноэкранный режим, изменение скорости воспроизведения, показ субтитров и создание скриншотов.
AI-агенты в облаке: как они работают, зачем нужны — и как создать собственного
📅 13 мая | 18:00 (МСК) | Онлайн
На встрече поговорим о том, как устроены современные AI-агенты на базе LLM, какие архитектуры и инфраструктуры используются для их работы, и продемонстрируем создание агента в режиме live coding.
👨💻 Спикер — Михаил Дремин Технический лидер Data Science-направления в Clоud.ru
🔍 В программе: — Основы LLM-агентов и взаимодействие с внешним миром через инструменты (tools) — Архитектурные подходы: Prompt chaining, ReAct, Evaluator-optimizer, ambient agents и другие — Реальные кейсы использования — Практическая часть: разработка собственного агента на Python (с использованием LangChain) и развертывание в облаке
💼 А также: представители компании расскажут о стажировке для студентов и молодых специалистов: какие направления доступны, как попасть в команду.
Тикток-блогер its_ken04, известная как Кен, опубликовала запись «собеседования», которая стала вирусной. В ролике ИИ-рекрутер 14 раз подряд повторяет фразу «vertical bar pilates», иногда запинаясь или заикаясь, пока Кен с невозмутимым видом смотрит на экран.
Девушка подавала заявку на работу в фитнес-центре. Кен рассказала, что компания заранее предупредила ее об использовании ИИ в процессе отбора, и платформа называлась Apriora. «Похоже, мне нужно было заслужить право говорить с человеком, ха-ха», — написала девушка в комментариях к видео.
Стартап Apriora обещает помочь компаниям «нанимать на 87% быстрее» и «проводить собеседования на 93% дешевле», поскольку может одновременно интервьюировать нескольких кандидатов. «Соискатели во многих случаях предпочитают проходить собеседование с ИИ, поскольку знание того, что интервьюер — это ИИ, помогает снизить тревогу, позволяя кандидатам проявить себя наилучшим образом», — заявили в компании.
Опыт Кен с Apriora был отрицательным. «Мне показалось это действительно жутким, я была в шоке», — сказала она. «Я не находила это смешным, пока не выложила тикток и комментарии не подняли мне настроение. Я была очень удивлена, я ничего не сделала, чтобы вызвать сбой, так что это было неожиданно. Я больше никогда не буду проходить это снова. Если другая компания захочет, чтобы я общалась с ИИ, я просто откажусь», — заявила блогер.
Рэймонд Чен — ветеран компьютерной индустрии, который работает в Microsoft c 1992 года. Рэймонд участвовал в разработке OS/2, Windows 95, DirectX и оболочки Windows, а последние десятилетия отвечает за сохранение обратной совместимости системы. В своём блоге Old New Thing Чен регулярно делится забавными историями из разработки софта, но также показывает действительно полезные примеры.
На этот раз Чен показал, почему история буфера обмена не отражает быстрые изменения содержимого буфера. Рэймонд приводит следующий фрагмент кода от клиента. Этот код был написан для некой утилиты, вставляющей в историю буфера обмена объекты. В некотором роде историю прошлых изменений превращали в будущее — целью было предугадать, какие элементы пользователь хотел бы видеть в истории буфера обмена.
// В целях наглядности вся проверка ошибок опущена
#include <windows.h>
void SetClipboardText(HWND hwnd, PCWSTR text)
{
OpenClipboard(hwnd);
EmptyClipboard();
auto size = sizeof(wchar_t) * (1 + wcslen(text));
auto clipData = GlobalAlloc(GMEM_MOVEABLE, size);
auto buffer = (LPWSTR)GlobalLock(clipData);
strcpy_s(buffer, size, text);
GlobalUnlock(clipData);
SetClipboardData(CF_UNICODETEXT, clipData);
CloseClipboard();
}
// Чтобы они были под рукой, разместим эти строки в истории буфера обмена
static constexpr PCWSTR messages[] = {
L"314159", // номер бага, который мы хотим исправить
L"e83c5163316f89bfbde7d9ab23ca2e25604af290", // коммит, к которому привязываем ошибку
L"Widget polarity was set incorrectly.", // комментарий, который нужно добавить
};
int wmain([[maybe_unused]] int argc,
[[maybe_unused]] wchar_t* argv[])
{
auto tempWindow = CreateWindowExW(0, L"static", nullptr, WS_POPUPWINDOW,
0, 0, 0, 0, nullptr, nullptr, nullptr, nullptr);
for (auto message : messages)
{
SetClipboardText(tempWindow, message);
}
DestroyWindow(tempWindow);
return 0;
}
Код записывает в буфер обмена последовательно три строковые переменные. Однако при запуске утилиты в истории буфера обмена оказывалась лишь одна — последняя. Куда делись две остальные?
Дело в том, что служба истории буфера обмена работает асинхронно через механизм Clipboard Format Listener, существующий с эпохи Windows Vista. В этом механизме через функцию AddClipboardFormatListener приложение добавляет себя в качестве листенера. После этого никаких дополнительных опросов буфера обмена проводить не нужно — система сама оповестит приложение, если буфер изменился.
При получении уведомления служба истории буфера обновляет собственно историю буфера обмена. Но из-за асинхронности событие может происходить с задержкой. Как объясняет Чен, из-за асинхронной природы обновлений при получении WM_CLIPBOARDUPDATE от Clipboard Format Listener буфер может успеть обновиться ещё раз.
Как считает Рэймонд, это даже не баг, а фича. Так получается избегать приложений, которые быстро спамили бы в буфер обмена множество изменений. Если даже пользователь не успевает воспользоваться содержимым буфера, то сохранять это для истории смысла нет, указывает Чен.
В другом посте из своего блога Рэймонд объяснил механизмы утилит-просмотрщиков буфера обмена с синхронными обновлениями буфера. Здесь периодически выполняется опрос GetClipboardSequenceNumber. У данного подхода тоже есть проблемы: редкий опрос угрожает привести к пропуску изменения буфера, но слишком частые запросы создадут лишнюю нагрузку на систему.
Рэймонд обещает в следующий раз показать, как исправить код выше.
Продолжая тему взаимодействия с MITRE насчёт CVE. В прошлый раз я обращался к MITRE из-за нежелания вендора Docker создавать CVE. Теперь же я попытался внести уточнение к существующей записи CVE-2018-14847, описание которой не слишком точное:
MikroTik RouterOS through 6.42 allows unauthenticated remote attackers to read arbitrary files and remote authenticated attackers to write arbitrary files due to a directory traversal vulnerability in the WinBox interface.
По такому описанию можно подумать, что уязвимы абсолютно все версии ниже 6.42. На самом деле это не так. Более точное описание есть у вендора MikroTik:
Versions affected:
Affected all bugfix releases from 6.30.1 to 6.40.7, fixed in 6.40.8 on 2018-Apr-23
Affected all current releases from 6.29 to 6.42, fixed in 6.42.1 on 2018-Apr-23
Affected all RC releases from 6.29rc1 to 6.43rc3, fixed in 6.43rc4 on on 2018-Apr-23
Но, и оно не совсем правдивое. Как минимум версия 6.28 уязвима (проверял используя этот эксплоит). Я обратился в MITRE через эту форму (выбрал "Request an update to an existing CVE Entry"), объяснив всё это. В итоге MITRE лишь добавили ссылку на описание уязвимости от вендора (обновление от 28.04.2025). Это в очередной раз подтверждает, что при оценке угроз не стоит полностью полагаться ни на CVE, ни на информацию от вендора. О чём говорю не только я. Был у меня личный опыт, показывающий неточность в описании уязвимых версий со стороны вендора: Cisco UCS Manager. А если пытаться смотреть на CVE, указанные вендором по этой проблеме - так каши в голове становится лишь больше: в CVE речь о версиях bash (а какая версия bash в какой прошивке и оборудовании есть - в CVE не указывается).
Профильные эксперты выяснили, что уровень детализации в трейлере Grand Theft Auto VI (там показан геймплей и катсцены на движке, никакого пререндера) достиг высоких планок в графическом дизайне и даже в некоторой степени превзошёл ожидания пользователей, включая освещение, тени, работу с мелкими элементами типа прозрачных материалов, стекла, динамических объектов в отражениях.
Одной из деталей трейлера оказалось то, что в нём велосипедисты специально продевают шлёпанцы через педали, чтобы было удобнее ездить. Многие пользователи подумали, что это один из багов игры, но велолюбители пояснили, что это совершенно нормальное явление и так можно ездить на велосипеде.
6 мая 2025 года Rockstar Games выпустила второй трейлер Grand Theft Auto VI. В описании трейлера говорится, что неудачное ограбление меняет всё и заставляет героев скрываться в опасных районах самого солнечного места Америки.
Сюжет GTA VI разворачивается в вымышленном американском штате Леонида, где расположены легендарный Вайс‑Сити и другие городки игры. «Grand Theft Auto VI направляется в штат Леонида, где расположены залитые неоном улицы Вайс‑Сити, и за его пределами, в самой большой и самой захватывающей эволюции серии Grand Theft Auto», — пояснили в Rockstar.
2 мая 2025 года Rockstar Games официально сообщила о переносе даты выхода Grand Theft Auto VI. Вместо осени 2025 года релиз тайтла состоится 26 мая 2026 года. В компании пояснили, что это необходимая мера, так как команде проекта понадобилось дополнительное время на то, чтобы завершить создание игры в таком виде, чтобы она превзошла все ожидания пользователей.
5 декабря 2023 года Rockstar опубликовала официальный трейлер GTA VI. Планировалось, что GTA VI выйдет на Xbox S|X и PlayStation 5 осенью 2025 году, а вот дата выхода на ПК остаётся неизвестной. По одной из версий СМИ, ПК‑версия игры в этот раз может появиться вместе с консольной, а не через пару лет, как обычно.
Приглашаем вас на бесплатный вебинар «TypeScript за час: основы, плюсы и практика». Познакомим вас с TypeScript. Расскажем, зачем он появился, в чём его преимущества и как он помогает писать понятный и надёжный код. Подойдёт и новичкам, и практикам.
⁉️ На вебинаре вы сможете задать вопросы спикеру.
📅 Дата: 13.05.2025
⏰ Время: 17:00-18:00 (Мск)
На вебинаре:
✔️ История возникновения TypeScript
✔️ Преимущества использования TypeScript
✔️ Пример написания кода на TypeScript
👨🎓 Спикер: Кучин Евгений — разработчик на Java и JavaScript.
Возможно, вам будет интересен курс «Язык программирования TypeScript». Вы освоите TypeScript, изучив типизацию, интерфейсы и классы. Узнаете, как использовать статическую типизацию, интегрировать TypeScript с существующим JavaScript и настраивать окружение разработки. Это поможет сделать ваш код более безопасным и структурированным.
Могучий русский язык и предиктивный ввод в умной клавиатуре
Русский — это вызов даже для самых продвинутых языковых моделей. Одна из ключевых причин — его морфологическая сложность. В отличие от английского языка, где у слов относительно немного форм, русский язык отличается большим количеством словоформ, которые образуются с помощью приставок, суффиксов и окончаний.
Это означает, что одно лексическое понятие, например глагол «читать», может породить десятки различных форм: «читаю», «читаем», «читаешь», «прочитал», «прочитала» и так далее. Для модели предиктивного ввода это серьезная проблема: чтобы корректно предсказывать или завершать такие слова, ей нужно либо обладать глубоким пониманием морфологии, либо иметь достаточно большой словарь, который покрывает все возможные варианты словосочетаний.
Мы увеличили размер словаря для русского языка до 40 тысяч слов и использовали модель Char CNN + RNN. Так удалось добиться прироста метрики KSS (количество сэкономленных нажатий) на 60%.
Читайте в статье ИИ-инженера Вадима Воеводкина из YADRO, как его команда улучшила предиктивный ввод на планшетах KVADRA_T и с какими сложностями столкнулась.
Вместе с МФТИ Альфа-Банкоткрывает набор в магистратуру «Машинный интеллект в финансах». Обучим управлять циклом создания модели, анализировать и моделировать данные с помощью алгоритмов Python, а также решать прикладные задачи Machine Learning и Deep Learning.
Почему стоит попробовать:
Бесплатное обучение — все расходы покрывает Альфа-Банк.
Ежемесячная стипендия и оплачиваемая стажировка с первого дня.
Возможность попасть в IT-команду Альфа-Банка.
Что нужно:
Иметь диплом бакалавра или магистра.
Подать заявку и решить задачу по машинному обучению (кредитного скоринга или прогнозирования баланса клиентов).
Пройти вступительные испытания в МФТИ (подробнее о нихна сайте МФТИ).
Как работать с реактивным кодом в iOS на примере Combine
Пожалуй, каждый iOS-разработчик видел в требованиях вакансий «знание фреймворков RxSwift, RxCocoa». Эти инструменты основаны на концепции реактивного программирования.
Реактивное программирование, как следует из названия, основано на реакции на событие: пользователь взаимодействует с интерфейсом и ждёт реакцию от приложения. Этот подход популярен в фронтенд-разработке, в том числе на iOS.
Мы в Surf долгое время избегали «реактивщины» в приложениях. Во-первых, это лишние зависимости. Во-вторых, подобные библиотеки несут в себе не только преимущества, но и проблемы с дебагом, сложностью поддержки кода и так далее.
Однако с выходом Combine и SwiftUI, мы решили начать внедрять реактивный подход в наши приложения. Благо, теперь не нужны сторонние решения: хватит того, что предоставляет Apple. Давайте посмотрим, как можно работать с реактивным кодом.
Главные элементы Combine, с которыми происходит работа:
1) Publisher — издатель
Протокол, указывающий, что тип может передавать последовательность значений со временем. Publisher предоставляет данные только подписчику (Subscriber) и делает это, когда данные становятся доступны. Без подписки Publisher не активен.
Publisher описывается двумя ассоциированными типами: <Output, Failure>
Output — тип выдаваемых значений
Failure — тип возможной ошибки. Если ошибок быть не может, используется Never.
2) Subscriber — подписчик
Отвечает за запрос и получение данных от издателя, а также за обработку ошибок. Имеет типы <Input, Failure>:
Input — тип входных данных
Failure — тип ошибки
Subscriber сам инициирует запрос и управляет объёмом поступающих данных. Основные способы обработки:
sink(receiveCompletion:receiveValue:)Принимает два замыкания: первое вызывается при завершении (успешно или с ошибкой); второе — при получении значений.
assign(to:on:)Присваивает полученные значения свойству объекта по keyPath.
3) Operators — операторы
Методы, преобразующие данные и потоки. Операторы — это промежуточное звено между издателем и подписчиком. С их помощью строятся цепочки обработки, трансформации и фильтрации данных.
4) Subjects — субъекты
Особый вид Publisher. Объекты, реализующие этот протокол, могут отправлять значения подписчикам через метод .send(_).
Subjects полезны для интеграции императивного кода: позволяют вручную вставлять значения в поток.
Управление подпиской
Publisher продолжает отправку до завершения или ошибки. Если подписка больше не нужна, её можно отменить с помощью метода cancel(). Все подписчики реализуют протокол Cancellable.
«Как нефть, только важнее»: как выстроить культуру работы с данными
В рамках конференции ArenaDAY, посвящённой передовым технологиям и трансформации бизнес-процессов, Chief Data Officer ОТП Банка Николай Шевцов выступил с докладом «От data-команд к data-компании: как сформировать культуру работы с данными».
На примере ОТП Банка он представил пошаговый подход к выстраиванию data-культуры в крупной организации — от локальных инициатив внутри ИТ-подразделений до интеграции данных в повседневные бизнес-процессы.
«Весь процесс работы с данными напоминает нефтепереработку: сырые данные — это нефтеносная жидкость, которую сначала нужно добыть (собрать), затем очистить (data governance) и переработать в полезные продукты — отчёты, аналитику, модели. Но главное отличие в том, что данные — не просто актив, а неотъемлемая часть нашей жизни, как одежда или предметы быта. Чтобы быть эффективными, мы должны научиться работать с ними так же естественно, как дышать», — отметил Николай Шевцов.
В центре внимания доклада — зрелость компании по отношению к данным, доверие к информации и способность организаций принимать решения на её основе. Николай представил собственную систему замера уровня data-культуры и рассказал о ключевых ролях, необходимых для её развития: от Data-чемпионов в командах до топ-менеджмента, задающего вектор и распределяющего ресурсы.
По мнению эксперта, эффективная трансформация невозможна без постоянного обучения, пилотных запусков и механики «быстрых побед» — так создаётся среда, где данные становятся не просто инструментом, а частью корпоративной ДНК.
ОТП Банк последовательно внедряет подход data as a culture и делится практиками, которые позволяют строить устойчивые решения в условиях высокой неопределённости.
Привет, Хабр! Мы продолжаем рубрику для тех, кто хочет размять мозги. На этот раз предлагаем вспомнить момент из фильма про Алана Тьюринга «Игра в имитацию».
По сюжету Алан настаивает на том, что нельзя реагировать на каждое расшифрованное сообщение, чтобы их не раскрыли, и допускает затопление конвоя. Если фиксировать реакцию на расшифровку как 1, а отсутствие реакции как 0, должна получиться случайная последовательность нулей и единиц.
Вопрос: какова должна быть минимальная длина случайной последовательности, чтобы четыре единицы подряд в последовательности (четыре реакции на шифровки) были неотличимы от случайности?
Иначе говоря: найдите математическое ожидание количества бросков монеты до первого появления четырех единиц подряд (т. е. «орел», «орел», «орел», «орел») в последовательности бросков, если вероятности выпадения 1 («орла») и 0 («решки») равны и независимы друг от друга.
При решении рекомендуем использовать поисковые системы, AI и Википедию.
Варианты ответов оставляйте в комментариях 👇 Я Павел Бузин — эксперт Cloud.ru по AI, машинному обучению и точным наукам, раскрою правильный ответ под этим постом 12 мая.
Всегда спрашивай дедлайн у заказчика, директора, менеджера, руководителя проекта, у любого, кто пришел к тебе с задачей, проектом. Прямой вопрос может остаться без ответа. Задавай разные вопросы. Основная задача - выяснить дедлайн. Он нужен.
Дедлайн есть всегда. Если ты его не знаешь, тебе его не сказали или сказали, что его нет - он все равно есть. Он настигнет тебя в самый неподходящий момент. Он будет для тебя "сюрпризом".
Даже размытый дедлайн - это хорошо: конец следующего года, через 3 месяца. Он создает основу для диалога, порождает вопросы и предложения. Он систематизирует, расставляет приоритеты, помогает принимать решения, показывает дистанцию. Ты можешь планировать работу, нагрузку, периоды ускорения и замедления, вехи.
Периодически уточняй дедлайн. Дедайн может измениться. Ты его не контролируешь. Это нормально. Он может измениться в силу внешних обстоятельств. Твоя задача - держать руку на пульсе и уточнять изменения в дедлайне. Не жди, что тебе скажут первым о изменениях - не скажут.
А у меня нет дедлайна. Думаешь тебе повезло? Нет. Это повод задуматься. Скорее всего у источника задачи нет стратегии, целей, долгосрочных планов, ожидания не соответствуют действительности. Он не понимает, что хочет. Задача - это идея, без понимания практического применения. Скорее всего ты в "болоте". Если компания "живая", дедлайн тебя настигнет. А может быть тебя хотят "слить" и это ловушка? Я видел такое, так бывает.
Почему классический мониторинг не работает для микросервисов и облаков? Переход к Observability
Современные системы давно перестали быть монолитами — теперь это сложные экосистемы из микросервисов, облачных сервисов и распределенных баз. Но если ваш мониторинг всё ещё фокусируется только на CPU и RAM, вы рискуете пропустить критические сбои.
Главные проблемы классического подхода:
Невидимые бизнес-сбои: Сервер «живой», но конверсия платежей падает.
Поиск иголки в стоге сена: При ошибке в цепочке из 10 микросервисов метрики инфраструктуры не укажут на источник проблемы.
Ручная настройка: Часы на алерты для каждого сервиса вместо автоматизации.
Решение — Observability:
Объедините метрики (Prometheus), логи (EFK) и трейсы (Jaeger), чтобы система сама «объясняла» свои сбои.
Пример кода
Отслеживание конверсии платежей в .NET-сервисе:
// Отслеживание конверсии платежей
using App.Metrics;
public class PaymentService
{
private readonly IMetrics _metrics;
public PaymentService(IMetrics metrics) => _metrics = metrics;
public void ProcessPayment()
{
try
{
// Логика обработки платежа...
_metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);
}
catch
{
_metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);
}
}
}
Код автоматически фиксирует успешные и неудачные платежи. Эти метрики интегрируются в Grafana для анализа бизнес-показателей.
Про колёсо Илона (оно же "колесо Mecanum") я с коллегами узнал достаточно давно. Году в 2018 мы загорелись желанием изготовить свой вариант четырехколёсной тележки на колёсах Илона чтобы освоить программирование её кинематики и начали с проектирования собственно колёсного хаба. К слову сказать, таких колёс на просторах известного китайского маркетплейса - вагон и маленькая тележка, но нам захотелось изготовить колесо своего дизайна. Подробности о кинематике тележки на четырех колёсах Илона можно прочесть в статье на Wikipedia.
Коллега ЧПУшник за пару недель полностью спроектировал колесо в 3D и даже изготовил один хаб (из двух симметричных половинок) из сплава Д16Т на нашем фрезерном ЧПУ в 5-ти координатах. Много лет этот хаб лежал на витрине и пугал своей экзотичной формой посетителей нашего офиса. В марте-апреле 2025 года у нас образовалось некоторое количество свободного времени и мы решили задействовать его с пользой, то есть дожать тему колёс Илона. Мы изготовили оставшиеся три хаба, для чего пришлось полностью переписать программу для ЧПУ чтобы сделать инверсную копию колеса. Запроектировали и изготовлили на токарном ЧПУ латунные втулки для роликов, а на 3D принтере напечатали сами ролики из эластичного материала. Оси роликов изготовили из калибровонного прутка Ф6 пищевой нержавейки.
Собрали всё воедино и установили на платформу с четырьмя шаговыми двигателями типа NEMA17, привод на колёса от которых передается через червячные редукторы с числом редукции 1:30. Для подачи сигнала на ШД использовали драйверы DRV8825 от дешманского 3D принтера предоставленного на разграбление всё тем же коллегой. Блок управления запрограммировали на Verilog-е для разработанной ранее плате "Карно" предназначенной для обучения ПЛИСоводству. В качестве дистанционного управления тележкой выбрали пульт ДУ от телевизора, так как код его декодера очень прост в реализации на Verilog и уже применялся нами для другого аналогичного проекта.
Как видно из приведенного выше видео, первая проба нашей тележки получилась не очень удачной, в ней имеются следующие проблемы:
1. Слишком большое редукционное число (1:30) делает перемещение тележки очень медленным. Радикально увеличить частоту сигнала STEP (сейчас это 16 кГц при режиме MODE=1/16) не получается - шаговики теряют синхронизацию и перестают вращаться. Планируем зменить редукторы, воможно вместе с ШД, на BLDC.
2. Из-за отсутствия подвески любые неровности поверхности приводят к потере сцепления одного из колёс, что моментально сказывается на направлении движения тележки.
3. Число роликов в колесе требуется увеличить (сейчас их 6 шт), чтобы обеспечить плавный переход от одного ролика к другому, иначе заметны рывки.
4. Ролики требуется изготавливать гладкими из резины с высоким коэф трения, 3D печать не дает качественной поверхности и такие ролики плохо сцепляются с половым покрытием. Тут есть варианты: выточить на ЧПУ из полиуретана или отлить из эластопласта в пресс-форму. Возможности для этого имеются.
Ждем следующей паузы в основной деятельности, чтобы заняться разрешением выявленных проблем нашей тележки. На этом пока всё.
