Не сомневайтесь, ведь даже читать такие комментарии приятно. Я с трудом представляю себе, что может побудить частное лицо связаться с этой конторой сегодня.
Как выше уже указали, описана вариация CDMA/DSSS. В классическом CDMA информация о времени извлекается из полезного сигнала, что делает первые три пункта неактуальными. Я кстати тоже заметку про это тут писал, но ссылку на свою публикацию не оставлю, это дурной тон :3
Да уж наверное, но смысл-то не в этом. Господин выше предлагает сделать аккумулятор избыточной энергии, а не электростанцию. Аккумулятор предполагает потери.
Автор комментария выше хотел сказать, что действующее значение переменного напряжения с амплитудой 220 В меньше 48 вольт. Однако, это не соответствует действительности: 220/sqrt(2) больше 48 В примерно в три раза.
Не могу пройти мимо не рассказав про наш велосипед, о котором вы, вероятно, не слышали: UAVCAN. Мы решаем задачи построения распределённых вычислительных систем реального времени на транспорте и в робототехнике, что должно быть вам довольно близко. Например, у нас есть обобщённый интерфейс, заменяющий FreeMASTER, текстовый терминал, и экспорт в матлаб в вашем примере, вот тут есть небольшой (пусть и из другой области) пример на основе CAN (ещё поддерживаются UART, TCP, UDP, etc.): https://github.com/UAVCAN/demos/tree/main/udral_servo
Наша большая проблема (которая делает наше решение непригодным в вашем случае) это отсутствие вменяемого графического интерфейса -- пока всё через консоль (Windows тоже, впрочем, поддерживается), но:
Было бы интересно собрать с вас обратную связь по этому поводу, хотя бы просто в формате общих рассуждений. Если будет возможность и интерес, буду рад пообщаться на эту тему в личке или в телеграме (ссылка в профиле).
Не следует копировать на «Хабр» тексты, опубликованные другими людьми на других ресурсах, но можно копировать собственные тексты, если они не нарушают правила ресурса.
Спасибо, всё это чрезвычайно занимательно. Я не хочу упустить возможности заметить, что одной из главных предпосылок к созданию UAVCAN v1 и нового слоя уровня приложения поверх него является именно устранение "перекладывания джсонов" из типичных процессов разработки для ваших роботов. И я не то чтобы предлагаю практики из веб-разработки тащить в робототехнику или авиацию, я просто указываю на то, что сложность бортового ПО растёт быстро, а методы его разработки — нет. И здесь есть чему поучиться у наших "веб"-ориентированных коллег.
Когда мы выпустим UDRAL, я, наверное, попробую сделать ещё один наброс на вентилятор, но в чуть более практическом ключе. Если интересно, присоединяйтесь. Пока ждём, можете присоединиться к нашему каналу в телеге, но ссылку на него я не скажу.
Но библиотеки ST не идеальны и видимо не проходят должного тестирования функционала.
Вы чрезвычайно сдержанны в выражениях.
Одним лишь ST дело тоже не ограничивается. Если у вас популярная аппаратная платформа и есть возможность свободно выбрать ОС, есть смысл использовать что-то вроде NuttX/Zephyr/ChibiOS, где необходимая функциональность может быть доступна из коробки, и в отличие от софта от вендоров МК их код обычно всё-таки работает.
Это всё имело бы смысл, если бы речь шла об отладке на столе. У меня (и у автора публикации) задача шире, и включает в себя сбор телеметрии с устройства в полевых условиях для диагностики и тонкой доводки контуров управления. Одним лишь UART дело тоже редко ограничивается.
Очень занятный проект. Необходимость генерации профиля под конкретное приложение напрягает, потому что несколько усложняет цикл отладки в процессе разработки. Я пару лет назад запилил свой похожий велосипед на C++17, который даже в одном продукте работает; более богатая система типов современного C++ позволяет избавиться от препроцессинга и в то же время не гонять строки через интерфейс трассировки целиком. В итоге я, правда, всё равно им не доволен: реализация вышла сложной, есть потребность в нетривиальной статической инициализации, API неудобный, да и от макросов не получилось избавиться. Сижу ищу альтернативы получше, и в связи с этим вопрос:
Есть ли решение проще и производительнее? В данной статье мы рассмотрим одно из таких
Можете огласить весь список конкурирующих решений, пожалуйста?
Как был обоснован запрет?
Дваждую. Примерно в духе security theater, только здесь innovation theater.
Не сомневайтесь, ведь даже читать такие комментарии приятно. Я с трудом представляю себе, что может побудить частное лицо связаться с этой конторой сегодня.
Какой протокол верхнего уровня используется?
новящевость
Эта лошадь давно сдохла, слезайте.
Как выше уже указали, описана вариация CDMA/DSSS. В классическом CDMA информация о времени извлекается из полезного сигнала, что делает первые три пункта неактуальными. Я кстати тоже заметку про это тут писал, но ссылку на свою публикацию не оставлю, это дурной тон :3
Да уж наверное, но смысл-то не в этом. Господин выше предлагает сделать аккумулятор избыточной энергии, а не электростанцию. Аккумулятор предполагает потери.
https://thispersondoesnotexist.com/
Вы правы, я совсем упустил из виду, что 220 В и есть действующее напряжение, а не амплитудное. Пойду посыплю голову пеплом.
Но при чём тут заземление?
Этот стандарт называется USB Type-C 2.1, а не то, что вы написали.
Автор комментария выше хотел сказать, что действующее значение переменного напряжения с амплитудой 220 В меньше 48 вольт. Однако, это не соответствует действительности: 220/sqrt(2) больше 48 В примерно в три раза.
Не могу пройти мимо не рассказав про наш велосипед, о котором вы, вероятно, не слышали: UAVCAN. Мы решаем задачи построения распределённых вычислительных систем реального времени на транспорте и в робототехнике, что должно быть вам довольно близко. Например, у нас есть обобщённый интерфейс, заменяющий FreeMASTER, текстовый терминал, и экспорт в матлаб в вашем примере, вот тут есть небольшой (пусть и из другой области) пример на основе CAN (ещё поддерживаются UART, TCP, UDP, etc.): https://github.com/UAVCAN/demos/tree/main/udral_servo
Наша большая проблема (которая делает наше решение непригодным в вашем случае) это отсутствие вменяемого графического интерфейса -- пока всё через консоль (Windows тоже, впрочем, поддерживается), но:
Было бы интересно собрать с вас обратную связь по этому поводу, хотя бы просто в формате общих рассуждений. Если будет возможность и интерес, буду рад пообщаться на эту тему в личке или в телеграме (ссылка в профиле).
Справа-вверху ещё одна.
Если серьезно, то мне интересна природа этих точек. Уважаемый автор, известно ли вам, откуда они взялись?
Это правило уже отменено. Теперь там следующее:
Спасибо, всё это чрезвычайно занимательно. Я не хочу упустить возможности заметить, что одной из главных предпосылок к созданию UAVCAN v1 и нового слоя уровня приложения поверх него является именно устранение "перекладывания джсонов" из типичных процессов разработки для ваших роботов. И я не то чтобы предлагаю практики из веб-разработки тащить в робототехнику или авиацию, я просто указываю на то, что сложность бортового ПО растёт быстро, а методы его разработки — нет. И здесь есть чему поучиться у наших "веб"-ориентированных коллег.
Когда мы выпустим UDRAL, я, наверное, попробую сделать ещё один наброс на вентилятор, но в чуть более практическом ключе. Если интересно, присоединяйтесь. Пока ждём, можете присоединиться к нашему каналу в телеге, но ссылку на него я не скажу.
Вы чрезвычайно сдержанны в выражениях.
Одним лишь ST дело тоже не ограничивается. Если у вас популярная аппаратная платформа и есть возможность свободно выбрать ОС, есть смысл использовать что-то вроде NuttX/Zephyr/ChibiOS, где необходимая функциональность может быть доступна из коробки, и в отличие от софта от вендоров МК их код обычно всё-таки работает.
Это всё имело бы смысл, если бы речь шла об отладке на столе. У меня (и у автора публикации) задача шире, и включает в себя сбор телеметрии с устройства в полевых условиях для диагностики и тонкой доводки контуров управления. Одним лишь UART дело тоже редко ограничивается.
Очень занятный проект. Необходимость генерации профиля под конкретное приложение напрягает, потому что несколько усложняет цикл отладки в процессе разработки. Я пару лет назад запилил свой похожий велосипед на C++17, который даже в одном продукте работает; более богатая система типов современного C++ позволяет избавиться от препроцессинга и в то же время не гонять строки через интерфейс трассировки целиком. В итоге я, правда, всё равно им не доволен: реализация вышла сложной, есть потребность в нетривиальной статической инициализации, API неудобный, да и от макросов не получилось избавиться. Сижу ищу альтернативы получше, и в связи с этим вопрос:
Можете огласить весь список конкурирующих решений, пожалуйста?