Теперь понял, чего не хватает в вашей версии. Bloom-эффекта и Motion Blur (его слишком мало). Из-за этого всё выглядит совсем не так киношно, как в оригинале. Плюс цветовая гамма огней. В вашей версии нету разноообразия, по сути есть лишь три цвета. И уровень чёрного высоковат, сцена выглядит несколько серовато.
того полицейского, который ударил женщину ногой в живот судить надо
Если бы это на самом деле было реально (не номинально, а с конкретным тюремным сроком для полицейского), то такие каналы с персональными данными и не появлялись бы.
Отличный материал, огромное Вам спаибо! Мне эта тема весьма интересна, но времени на то, чтобы углубленно курить специализированную литературу, пока особо не было. Во мнгоих источниках всё это описано весьма неоднозначно и поверхностно, а вот у Вас кратко и по существу. И у меня наконец-то паззл по моторам окончательно сложился.
Господа, ну камон. Публикация из серии «как нарисовать сову». Новичкам она не поможет, потому что описано всё очень поверхностно. Тем, кто уже хоть немного в теме, не поможет тоже, потому что рассказывает очевидные вещи. Если вы хорошо знаете нюансы серийного производства, то напишите про них подробно и с примерами — мол вот был кейс, планировали вот так, а получилось не очень, потому что [...]
Если внимательно почитать документацию к довольно популярному полётному софту Ardupilot и найти описание работы модуля EKF (отвечает за отслеживание положения и ориентации дрона, используя данные со всех доступных датчиков), то можно узнать что инерциальные сенсоры (акселерометры и гироскопы) накапливают ошибки с такой скоростью, что уже примерно через 5 секунд данные о местоположении, вычисленые лишь с их помощью, становятся полностью непригодными для сколь-нибудь точного позиционирования.
Но с газонокосилкой всё проще — это не летательный аппарат, для котороко отвал RTK может означать немалую вероятность крушения. Газонокосилка при отвале RTK может просто остановиться и подождать, пока RTK не восстановится. Поэтому в ней вполне можно использовать намного более дешёвые решения на базе NEO-M8P, с которыми вполне реально уложиться в $200 — 250 за всё GPS-оборудование.
Чуть дешевле: у ublox в продаже есть весьма хороший набор для разработчиков — C099-F9P. Стоит 220 евро. В комплект входит плата с модулями ZED-F9P и ODIN W2 (Wi-Fi/BT) с выведенными на штырьковую гребёнку интерфейсами, весьма хорошая керамическая антенна с длинным кабелем, магнитным креплением и земляной пластиной, антенна для Wi-Fi/BT. Двух таких комплектов более чем достаточно для большинства задач, требующих RTK.
Мануал-то простенький, но практика показывает, что всё не так-то просто. RTK невероятно чувствителен к качеству принимаемого сигнала. Поэтому для стабильной работы RTK на F9P, во-первых, нужны хорошие и дорогие активные двухдиапазонные антенны. Это спиральные антенны либо керамические патч-антенны стомостью $50 — 80. Я протестировал несколько более дешёвых вариантов и выяснил, что с ними про стабильный RTK можно лишь мечтать. Кабели, коннекторы — всё тоже критически важно — роль играет каждый децибелл сигнала, всё нужно тщательно тестировать. Во-вторых, даже при использовании подходящих антенн крититески важна очень хорошая видимость неба. Это и отсутствие высоких преград поблизости, и хорошие погодные условия. В городских условиях на уровне земли получать стабильное целочисленное решение RTK выходит крайне редко, а в пасмурные дни — примерно никогда.
Если говорить о более дешёвых вариантах, то можно посмотреть в сторону однодиапазонного ublox NEO-M8P. Стоимость комплекта будет вдвое меньше, но вместе с ней в первую очередь ухудшится стабильность работы в неблагоприятных условиях. Насколько именно — сказать не могу, пока не тестировал.
NordicEnergy, там у этого вашего камня TMS320F28027F есть весьма интересная технология InstaSPIN-FOC. Использовали её? Как впечатления? Ну и главный вопрос: можно ли при помощи одного камня рулить несколькими моторами сразу? Несколько инстансов InstaSPIN можно инициализировать?
Когда-то давно довелось плотно познакомиться с этой платой. Образы загрузочных SD-карт с Debian и Android всегда были доступны вот здесь. Полноценную загрузку с USB сделать так и не удалось, но частичная вполне работала. Для загрузки всё ещё требовалась SD-карта, на ней размещался uboot, его конфиг и образ ядра uImage. Всё остальное можно было перенести на USB-накопитель. Для этого нужно создать файл uEnv.txt в корне первого раздела загрузочного носителя и добавить в него строку root=/dev/sda1
Чего ещё хотелось бы:
— Аппаратную реализацию 1-wire протокола (текущая полупрограммная версия работает ужасно криво при некоторых обстоятельствах).
— Побольше каналов аппаратного ШИМ (хотя бы 4, лучше 8).
— Хотя бы пару АЦП.
Короче говоря, хотелось бы, чтобы реже встречались ситуации, когда для реализации того или иного проекта к малине нужен ещё дополнительный контроллер, потому что она чего-то не умеет.
Также присоединяюсь к пожеланиям добавить SATA (пусть и в более дорогой версии малины — это позволило бы не использовать в качестве загрузочного носителя флешкарты, которые нередко дохнут), добавить коннекторы для подключения внешних антенн и реализовать нормальный UART, лучше два.
Господа, у вас места на самом деле предостаточно. Взгляните на досуге на то, как реализована подсветка LCD-экранов в мобильных устройствах. На ту сторону платы, что смотрит на пользователя, можно распаять по 4 smd-светодиода на кнопку (только не тех, что светят перпендикулярно плате, а тех, что параллельно), направленных к центру кнопки, всю эту сторону платы закатать в белую шелкографию и накрыть пластиной рассеивающего пластика с отфрезерованными отверстиями для светодиодов (они будут светить в торцы отверстий, в которых гнездятся). Толщина увеличится на 1,5 — 2 мм. Если и это не устраивает, то можно заменить участок текстолита, на котором сейчас сенсорная площадка, на врезку из того же рассеивающего пластика, металлизированного с одной стороны. И чтобы два раза не вставать: я рад, что у нас в РБ есть-таки разработчики, делающие что-то стоящее, всех вам успехов и хорошего настроения.
Все так рьяно бросились обсуждать последствия клонирования сознания абсолютно без оглядки на то, что его возможность даже в теории под большим вопросом. Давайте начнём с простых, привычных нам вещей. Когда мы делаем клон, скажем, виртуальной машины, её приходится ставить на паузу. Нужен именно снэпшот, мгновенный снимок всего и сразу. Если этого не сделать, то ни о какой консистентности клона не может быть и речи. Потому что копирование не происходит мгновенно. На тот момент, когда в копию уже записалась некоторая часть оригинала, в оригинале продолжают происходить изменения, ведь мы копируем живую систему, продолжающую работать прямо во время копирования. Далеко не факт, что скопированный таким образом клон вообще заведётся. У кого-то есть идеи, как снять снэпшот сложного реального физического объекта, такого, как человеческий мозг? Насколько точным должно быть клонирование, что нужно воспроизвести для клонирования сознания 1:1 без потерь, а что можно игнорировать? Тут уже говорили и про сохранение заряда при поатомном копировании конденсатора, и про принцип неопределённости. Если для получения достаточно идентичной копии важен спин каждого электрона в мозге, то похоже, что о таком клонировании вообще можно забыть как минимум очень надолго, если не вообще.
# udevadm info -a -n /dev/mmcblk0
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/platform/soc/20202000.sdhost/mmc_host/mmc0/mmc0:aaaa/block/mmcblk0':
KERNEL=="mmcblk0"
SUBSYSTEM=="block"
DRIVER==""
ATTR{ro}=="0"
ATTR{size}=="15523840"
ATTR{stat}==" 4491 1914 202850 16300 1386 1625 24289 26390 0 13340 42620"
ATTR{range}=="32"
ATTR{discard_alignment}=="0"
ATTR{force_ro}=="0"
ATTR{ext_range}=="32"
ATTR{alignment_offset}=="0"
ATTR{inflight}==" 0 0"
ATTR{removable}=="0"
ATTR{capability}=="10"
looking at parent device '/devices/platform/soc/20202000.sdhost/mmc_host/mmc0/mmc0:aaaa':
KERNELS=="mmc0:aaaa"
SUBSYSTEMS=="mmc"
DRIVERS=="mmcblk"
ATTRS{cid}=="035344534c303847803da92ee4010481"
ATTRS{csd}=="400e00325b5900003b377f800a4040af"
ATTRS{scr}=="0235800100000000"
ATTRS{date}=="04/2016"
ATTRS{name}=="SL08G"
ATTRS{type}=="SD"
ATTRS{preferred_erase_size}=="4194304"
ATTRS{fwrev}=="0x0"
ATTRS{hwrev}=="0x8"
ATTRS{oemid}=="0x5344"
ATTRS{manfid}=="0x000003"
ATTRS{serial}=="0x3da92ee4"
ATTRS{erase_size}=="512"
looking at parent device '/devices/platform/soc/20202000.sdhost/mmc_host/mmc0':
KERNELS=="mmc0"
SUBSYSTEMS=="mmc_host"
DRIVERS==""
looking at parent device '/devices/platform/soc/20202000.sdhost':
KERNELS=="20202000.sdhost"
SUBSYSTEMS=="platform"
DRIVERS=="sdhost-bcm2835"
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform/soc':
KERNELS=="soc"
SUBSYSTEMS=="platform"
DRIVERS==""
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
Olimex A13, SanDisk Ultra 8GB class 10
# udevadm info -a -n /dev/mmcblk0
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/platform/sunxi-mmc.0/mmc_host/mmc0/mmc0:aaaa/block/mmcblk0':
KERNEL=="mmcblk0"
SUBSYSTEM=="block"
DRIVER==""
ATTR{ro}=="0"
ATTR{size}=="15523840"
ATTR{stat}==" 5839 3033 327488 15840 1378 801 17850 7150 0 13780 22900"
ATTR{range}=="8"
ATTR{discard_alignment}=="0"
ATTR{force_ro}=="0"
ATTR{ext_range}=="256"
ATTR{alignment_offset}=="0"
ATTR{inflight}==" 0 0"
ATTR{removable}=="0"
ATTR{capability}=="50"
looking at parent device '/devices/platform/sunxi-mmc.0/mmc_host/mmc0/mmc0:aaaa':
KERNELS=="mmc0:aaaa"
SUBSYSTEMS=="mmc"
DRIVERS=="mmcblk"
ATTRS{cid}=="035344534c30384780657324d401078b"
ATTRS{csd}=="400e00325b5900003b377f800a4040af"
ATTRS{scr}=="0235800100000000"
ATTRS{date}=="07/2016"
ATTRS{name}=="SL08G"
ATTRS{type}=="SD"
ATTRS{preferred_erase_size}=="4194304"
ATTRS{fwrev}=="0x0"
ATTRS{hwrev}=="0x8"
ATTRS{oemid}=="0x5344"
ATTRS{manfid}=="0x000003"
ATTRS{serial}=="0x657324d4"
ATTRS{erase_size}=="512"
looking at parent device '/devices/platform/sunxi-mmc.0/mmc_host/mmc0':
KERNELS=="mmc0"
SUBSYSTEMS=="mmc_host"
DRIVERS==""
looking at parent device '/devices/platform/sunxi-mmc.0':
KERNELS=="sunxi-mmc.0"
SUBSYSTEMS=="platform"
DRIVERS=="sunxi-mmc"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
Годная статья, спасибо автору. Поделюсь своей скромной статистикой. Собрал две торговых машины на мини-ПК от Olimex (того же плана пирожки, что и Raspberry). Поставил MicroSD карты Transcend 4GB. ОС — адаптированный Debian, c GUI. Никаких твиков по снижению износа карт не делал. Торговый софт на Python, на карту пишет логи (несколько десятков килобайт в сутки). В первой машинке карта продержалась год: система перестала загружаться, показывая чёрный экран малевича. Заменил карту на такую же. Замена прожила полгода: перестал запускаться торговый софт, при старте падал с ошибкой segmentation fault. Заменил на SanDisk Ultra 8GB на днях. Во второй машинке карта проработала полтора года, но я её для профилактики тоже заменил на SanDisk.
Ещё одна карта Transcend 4GB из той же партии умерла в Raspberry, который я дома время от времени использую для разработки. Система перестала загружаться, бесконечно плевалась сообщениями от fsck при загрузке. Выполнил запись нулей во все блоки виндовой утилитой flashnul, ею же прогнал полный тест — всё хорошо вроде бы. Перезалил образ. Система загрузилась, но развалилась через полчаса. Выбросил.
Так и знал, что они в сговоре! Что ж, это многое объясняет.
После этого строку «Raspberry Pi compatible» в характеристиках любого одноплатника стоит расценивать не иначе как «Распиновка гребёнки GPIO совпадает с таковой у Raspberry», не более.
Теперь понял, чего не хватает в вашей версии. Bloom-эффекта и Motion Blur (его слишком мало). Из-за этого всё выглядит совсем не так киношно, как в оригинале. Плюс цветовая гамма огней. В вашей версии нету разноообразия, по сути есть лишь три цвета. И уровень чёрного высоковат, сцена выглядит несколько серовато.
Если бы это на самом деле было реально (не номинально, а с конкретным тюремным сроком для полицейского), то такие каналы с персональными данными и не появлялись бы.
Если говорить о более дешёвых вариантах, то можно посмотреть в сторону однодиапазонного ublox NEO-M8P. Стоимость комплекта будет вдвое меньше, но вместе с ней в первую очередь ухудшится стабильность работы в неблагоприятных условиях. Насколько именно — сказать не могу, пока не тестировал.
root=/dev/sda1— Аппаратную реализацию 1-wire протокола (текущая полупрограммная версия работает ужасно криво при некоторых обстоятельствах).
— Побольше каналов аппаратного ШИМ (хотя бы 4, лучше 8).
— Хотя бы пару АЦП.
Короче говоря, хотелось бы, чтобы реже встречались ситуации, когда для реализации того или иного проекта к малине нужен ещё дополнительный контроллер, потому что она чего-то не умеет.
Также присоединяюсь к пожеланиям добавить SATA (пусть и в более дорогой версии малины — это позволило бы не использовать в качестве загрузочного носителя флешкарты, которые нередко дохнут), добавить коннекторы для подключения внешних антенн и реализовать нормальный UART, лучше два.
Ещё одна карта Transcend 4GB из той же партии умерла в Raspberry, который я дома время от времени использую для разработки. Система перестала загружаться, бесконечно плевалась сообщениями от fsck при загрузке. Выполнил запись нулей во все блоки виндовой утилитой flashnul, ею же прогнал полный тест — всё хорошо вроде бы. Перезалил образ. Система загрузилась, но развалилась через полчаса. Выбросил.
После этого строку «Raspberry Pi compatible» в характеристиках любого одноплатника стоит расценивать не иначе как «Распиновка гребёнки GPIO совпадает с таковой у Raspberry», не более.