Да, мы смотрели на него при первоначальном брейншторме, но это оказались совершенно разные задачи. Тут нет десятков квадратных метров площади и не требуется высокая скорость реза. А три омниколеса много где используется)
Мы начали с раздельных покупных плат. Были отдельные драйверы на 5 двигателей. Но намного надежнее оказалось сделать единую плату с STM, к которой подключаются все датчики/двигатели/распберри
Мы с тканями не пробовали. Они легче и скользят по столу. Думаю, что если требуется фиксированный небольшой размер - то гравер бесконтактный лучше подойдет
Заказчик хотел создать устройство, работающее рядом с человеком на одном столе. Резаки продаются, но размером 5х10 стоят как боинг и на нем уже ручной раскрой не провести. В этой сфере обычно ограниченное пространство на производстве.
В нашем случае размер рабочей области получился неограниченным и форма стола может иметь любой замкнутый многоугольник, а такие огромные станки не мобильны, весят очень много и без вакуумного стола не работают.
У нас вышло не дешевле) Точность позиционирования на любую точку стола должна быть с погрешностью около 1мм. Если есть бюджетное решение - напишите, очень интересно)
про лидар... ну мне кажется мы его выбрали в первую очередь из-за не опытности, если честно :) И само собой из-за доступности и дешевизны)
У меня кубер с ингрессом, под ним я делал 5 инстансов принимающего сервиса, но для телеграмма это неважно. Балансировщик один на вход. Вы вебхуками телеграмма пользуетесь?
Постгрес позволяет обрабатывать конфликты при добавлении записей, например:
Я получаю шкуру и создаю запись с счетчиком = 1
При получении второй - у меня тот же запрос, но у одного юзера может быть только одна запись - тогда я добавляю в insert конструкцию on conflict (поля констрейнта) do update set count = table_name.count +1
Получается, что логика добавления и обновления находится в одном запросе) Сильно сокращает количество кода.
Но при этом сложнее дебажить и тестировать, но на стадии прототипа скорость важнее ;)
Да, именно так. Все подключение заняло пару строчек кода, так как в нем при добавлении записи проставляю время ее существования. Если запись существует, то я не отправляю данные в следующий сервис, а просто игнорирую.
А вот с идемпотентностью пришлось провозиться, так как телега позволяет до получения ответа отправить новый запрос. Каждая кнопка содержит инкреметальный идентификатор действия и в случае повторных отправок (при плохой сети у пользователя или при проблемах на моем сервере), либо при открытии нового сообщения и нажатия кнопок в старых - я просто произвожу обновление сообщения без совершения действия, отправляя в чат кнопки с актуальными actionId
Да, мы смотрели на него при первоначальном брейншторме, но это оказались совершенно разные задачи. Тут нет десятков квадратных метров площади и не требуется высокая скорость реза. А три омниколеса много где используется)
Тут не подскажу, не пробовали
Мы начали с раздельных покупных плат. Были отдельные драйверы на 5 двигателей. Но намного надежнее оказалось сделать единую плату с STM, к которой подключаются все датчики/двигатели/распберри
А есть какой-нибудь производитель в РФ?
А можно ссылку, я про навигацию с этим датчиком не нашел статью
Мы с тканями не пробовали. Они легче и скользят по столу. Думаю, что если требуется фиксированный небольшой размер - то гравер бесконтактный лучше подойдет
Про идею с арендой - интересно! Надо попробовать предложить кому-нибудь
Вот мы не смогли найти таких(
Хотя, возможно плохо искали)
Наоборот! У них ЗП повысилась, так как они сложные заказы делают быстрее)
Мы запатентовали, Роспатент патент на изобретение выдал. Все норм)
Спасибо)
Заказчик хотел создать устройство, работающее рядом с человеком на одном столе. Резаки продаются, но размером 5х10 стоят как боинг и на нем уже ручной раскрой не провести. В этой сфере обычно ограниченное пространство на производстве.
В нашем случае размер рабочей области получился неограниченным и форма стола может иметь любой замкнутый многоугольник, а такие огромные станки не мобильны, весят очень много и без вакуумного стола не работают.
У нас вышло не дешевле) Точность позиционирования на любую точку стола должна быть с погрешностью около 1мм. Если есть бюджетное решение - напишите, очень интересно)
про лидар... ну мне кажется мы его выбрали в первую очередь из-за не опытности, если честно :) И само собой из-за доступности и дешевизны)
А как такая ситуация возможна?) Пользователь удаляя сообщение - удаляет кнопки)
У меня кубер с ингрессом, под ним я делал 5 инстансов принимающего сервиса, но для телеграмма это неважно. Балансировщик один на вход. Вы вебхуками телеграмма пользуетесь?
Для обновлений сообщений никак(( сразу лочит
Постгрес позволяет обрабатывать конфликты при добавлении записей, например:
Я получаю шкуру и создаю запись с счетчиком = 1
При получении второй - у меня тот же запрос, но у одного юзера может быть только одна запись - тогда я добавляю в insert конструкцию on conflict (поля констрейнта) do update set count = table_name.count +1
Получается, что логика добавления и обновления находится в одном запросе) Сильно сокращает количество кода.
Но при этом сложнее дебажить и тестировать, но на стадии прототипа скорость важнее ;)
Да, именно так. Все подключение заняло пару строчек кода, так как в нем при добавлении записи проставляю время ее существования. Если запись существует, то я не отправляю данные в следующий сервис, а просто игнорирую.
А вот с идемпотентностью пришлось провозиться, так как телега позволяет до получения ответа отправить новый запрос. Каждая кнопка содержит инкреметальный идентификатор действия и в случае повторных отправок (при плохой сети у пользователя или при проблемах на моем сервере), либо при открытии нового сообщения и нажатия кнопок в старых - я просто произвожу обновление сообщения без совершения действия, отправляя в чат кнопки с актуальными actionId
Точно нет) скорее всего это сервис, отвечающий за контроль 1 сообщения в секунду на входе
Да, я напишу про детали реализации. Тут много всего использовал, что интересует больше всего?