roboforum.ru

Поправлю Вас, Виктор.
"До тех пор, пока стоимость работы программиста выше стоимости железа"
А это на долго
С другой стороны, не надо думать, будто "раздутый код" это специально. Нет. Просто решать задачи надо "вчера".

Графическая подсистема "по месту" может быть УДОБНА, если она нормально (а не как обычно) используется - это снижает количество ошибок пользователя.
Но для мобильных роботов, вот прямо сейчас, я могу представить себе только одно узкое место - видео.
Причём для передачи видео узким местом является не бортовой компутер, а канал связи.
А вот для обработки, да в реальном времени... Упс...
Ну ещё всякая экзотика типа нейросетей в системе управления. Но это экзотик.

Добавлено спустя 4 минуты 59 секунд:
Ага.
А вот про "роботы умнее" - это "поведение".
И до сих пор игрушки. Некоторые (которые сейчас на далёкой-далёкой гал... планете) и правда имеет смысл делать "умнее". До определённого предела.

А у нас самый умный робот - это пылесос, главный смысл которого, даже не пылесосить а развлекать разговорами одинокую бабушку.

Эх, hokuyo в такую плату ещё можно запихать (по UART), а вот какой-нибудь kinect уже нифига не влезет как по причине отсутствия порта, так и тупо по производительности. Хотя был бы чертовски интересен вариант исполнения в стиле sodimm (как у малины compute модуль).

Можно долго дискутировать о влиянии аскетизма на себестоймость робота, но уж больно часто случается ситуация, когда какой-нибудь нифига не скромный microsoft/primesense со своим кинектом "забывает" сделать экономный драйвер к своему устройству, и куча трудочасов, потраченая на оптимизацию кода просто умножается на 0 этой ерундой. Мегагерцы, оператива и лишние порты никогда лишними не бывают. Скромносто тоже хороша, там где ей есть разумный простор.

Кстати, мы графическую систему (GLES 1.x) используем для помощи в некоторых частях SLAM. Аппаратный растеризатор - потрясающая штука если правильно ею гвозди забивать. Да и предварительную обработку видео можно сделать в пределах стандарта OpenGL года эдак 95го.

В том то и суть создания умных роботов чтобы их программировали декларативно, а не императивно. тогда любая домохозяйка - программист телевизионных пультов будет программировать роботов как ухаживать за розами. Про другие отрасли программирования ничего не скажу.

_________________
Проект Robosonic RS http://www.aigod.com

Вот в целом. Какие ИНТЕЛЛЕКТУАЛЬНЫЕ задачи имеет практический смысл переложить на робота, без выноса на удалённую стационарную станцию или пульт оператора?

А те которые перекладываются на практике (автоматическая ориентация в пространстве и обработка видеоданных) в бюджетные компутеры ни как не утаптывается

Я вот сейчас как раз утаптыванием в RPI ориентации в пространстве, автоматического планирования любых автономных действий робота, его объемным зрением и занимаюсь. Для этого написал альфа-версию специального программного движка управляемого потоком данных.

_________________
Проект Robosonic RS http://www.aigod.com

Хотите сказать, что писать на прологе проще чем на php ?

А главное. Давным-давно, когда "экспертные системы" ещё были моднявы по самое не могу, наш мудрый тогдашний директор, отправил в мусорку все грандиозные планы на эту тему (включая неслабые наработки), с очень простой мотивацией: "если ЭС ошибётся, кто будет виноват?"
Но это оффтоп. Тогдашние ЭС вполне запускабельны на арджунке, если флешку подключить

Добавлено спустя 50 секунд:

Боджи мой... Я когда-то пытался промышленное зрение на синклере сделать... Закончилось всё концевиками

домохозяйка и программирование звучит круто. а если вспомнить, сколько людей долго с инструкцией будут изучать что в пульте от кондиционера тыкать...

Робота, который никогда не будет ошибаться невозможно создать потому, что мир незамкнут т.е. мы можем наблюдать лишь его малую часть и поэтому принципиально не можем вычислить даже ближайшее будущее.

_________________
Проект Robosonic RS http://www.aigod.com

Кстати код раздувается не столь уж сильно.
Хотя это во многом зависит от опыта и аккуратности программиста.

Возьмем например любой дистрибутив линукса.
Даже очень простые программы должны уметь многое - и с файловой системой работать, и с интерфейсами ввода-вывода, и картинку отображать а по хорошему еще мультипоточно работать на разных ядрах в системе.
Написать все кусочки программы для осуществления всех этих задач весьма не просто.
Поэтому все типовые задачи решаются централизованно для всех программ системы через системные (или вспомогательные) библиотеки.
Для разработчика остается только написать уникальную математику/алгоритмы а остальной функционал осуществляется системными библиотеками.

Есть ли в этом раздувание кода ? Да однозначно, ибо 70-80% библиотек никогда не используются, с другой стороны они и не подгружаются в оперативную память - лежат себе на диске.

Другое дело если программист приложения недальновиден, то он пишет кривой код.
К примеру раньше памяти постоянно не хватало, и было правило создавать swap раздел в два раза превышающий объём оперативки (потом стали ориентироваться на объём равный оперативке). Теперь представьте применение этого правила на современных серверах с объёмом памяти 128-256GB swap на пол терабайта это глупо и бессмысленно

Ну а в целом исходные коды коллективных проектов которые пишут под открытыми лицензиями весьма оптимизированы, ибо в сообществе есть грамотные программеры, которые либо сами исправят код либо укажут на косяки.

Добавлено спустя 3 минуты 3 секунды:

прежде че надсмехаться познакомились бы с работами коллеги по ссылочке в подписи ...

Добавлено спустя 3 минуты 53 секунды:
P.S. Кстати Виктор, а где Ваши работы? ссылочка ведет на заглушку

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

Анекдот из жизни в тему:

Шеф: Бардак! У нас 13 серверов и 5 типов обмена данными! Это по сути внутри одного распределённого приложения!
Шеф: Давайте весь обмен пустим одним протоколом через облако, 13 серверов выкинем, а поставим современный кластер на котором всё запустим да с 4-х кратным горячим резервированием.
Мы: $$#^234@$
Результат: Теперь у нас 7 типов обмена данными, 12 старых серверов и 1 новенький 4-нодовый кластер...

Добавлено спустя 1 минуту 17 секунд:


Где надсмешка? Это ностальгия По временам юности и безудержного оптимизьму

2setar: даже взяв нужную библиотеку, часто приходится использовать очень незначительную часть ее функций. А подгружается она вся. И если библиотек много, то сколько же понапрасну тратится впустую даже здесь ресурсов? Думаю, что ооочень много.
Ссылочка ведет на заглушку потому, что пока нет никакой возможности оформить сайт. С одной стороны, хотелось бы вначале добиться хоть какого-то реального результата, чтобы не представлять желаемое за действительное, а с другой стороны нет денежек на хостинг сайта посерьезнее трех статических страниц, которые мне предоставил провайдер домена. Сейчас сильнее всего у меня имеется озабоченность добычей пропитания. Но это как-то не по тематике данной ветки.

_________________
Проект Robosonic RS http://www.aigod.com

да, куча лишнего. ну так есть причины для такого. библиотеки могут быть и в исходниках. при желании ручками выпиливаете лишнее. если вы про dll`ки, так тоже отчасти решаемо. делаете свою файловую, делаете анализатор файлов библиотек. выпиливаете неиспользуемые куски файла и запихиваете это всё в свою файловую, что бы система могла с ними нормально работать. вот вам и экономия места, только попыхтеть прилично нужно. с софтом в операционках аналогично. можно грохнуть сервисы, стереть кеши/хранилища драйверов, грохнуть лшний софт. очень сильно ускорить выпиливание можно повозившись с live образами.

А не слабо взять кому-то да и придумать и воплотить стандарный способ раздеребанивания скомпиленых библиотек по запросу списка требуемых функций? Если такое невозможно сейчас из-за абсолютных адресов или еще по каким-то причинам, то могли бы процессоные гиганты придумать дошлепку в свои процессоры, которая помогала бы этому делу. Но это им невыгодно. Выгодно чтобы клиенту всегда не хватало вычислительных ресурсов. Ведь кроме подгрузки библиотек на уровне ядра еще столько всякого хлама неиспользуемого или непроизводительного есть.
Взять хотя бы мьютексы и пр. Я от них отказался в пользу межпоточного взаимодействия с помощью атомарных процессорных операций. Стало в десятки раз быстрее, по сути дела, вообще ядро здесь не участвует, и кода стало гораздо меньше.
Ладно, все равно мир под себя не прогну, скорее наоборот, я прогнусь.

_________________
Проект Robosonic RS http://www.aigod.com

вам нужно, вы и пилите. такое возможно, только нужно понимать, что библиотеки и всё проче не просто так избыточным получается. и не стоит забывать, что это может содавать проблемы и ненужные сложности. ну вот выпилите вы какой сервис, а потом допустим решите юсб прикрутить, а связанные файлы или сервисы вы уже выпилили. приехали.
ну в теории вы можете поступить лучше, но арбайтен там тоже немеряно. вам нужно начиная примерно с компиляторов и языка, создавать своё или модифицировать опенсорсное. продумываете как хранить метаданные, продумываете какие анализаторы использования кусков кода и файлов ресурсов и т.д. до высокоуровневых вещей в операционке.

не слабо
gentoo linux

так называемые USE флаги позволяют собирать пакеты (в том числе библиотеки) без лишнего функционала

пример выбора нужного и ненужного (здесь я взял пакет, тут больше выбор-показательно, но библиотеки собираются так же) :

[ebuild N ] dev-lang/php-5.5.24:5.5 USE="berkdb bzip2 cli crypt ctype fileinfo filter gdbm hash iconv ipv6 json nls opcache phar posix readline session simplexml ssl tokenizer unicode xml zlib -apache2 -bcmath -calendar -cdb -cgi -cjk -curl -debug -embed -enchant -exif (-firebird) -flatfile -fpm (-frontbase) -ftp -gd -gmp -imap -inifile -intl -iodbc -kerberos -ldap -ldap-sasl -libedit -libmysqlclient -mhash -mssql -mysql -mysqli -oci8-instant-client -odbc -pcntl -pdo -postgres -qdbm -recode (-selinux) -sharedmem -snmp -soap -sockets -spell -sqlite (-sybase-ct) -systemd -sysvipc -threads -tidy -truetype -vpx -wddx -xmlreader -xmlrpc -xmlwriter -xpm -xslt -zip" 13,025 kB