Обсуждение

Подари мальчишке мультиметр, макетку и grab bag, чтоб по мусоркам не рыться :) Ну или конструктор "Знаток". Радиотехника полезна для общего развития.

Да есть у меня "Знаток". И мультиметр дома есть. А до макетки ему, как до луны, поэтому и детальки не очень нужны. Интереса у него нет, вот проблема. Я боюсь, ему сразу нужно будет какой-нибудь raspberry pi с картами датчиков через пару-тройку лет, если интерес проснётся. Собственно, я ожидаю, что будет десять таких разобранных устройств сначала, потом одно собранное :-)

Мне любопытно смотреть на робототехнику с точки зрения университетов и исследователей. Профессиональная деформация заставляет смотреть через определенную призму, но не могу сказать, что испытываю большой недостаток в источниках информации. :) Я понимаю, вам вряд ли интересны частности - вам, похоже, больше интересны общие тенденции и, наверное, насколько в частных случаях люди следят за передаваемостью своих результатов работы, возможностью их повторного использования в новых проектах и прочее. Я больше слежу за примерами, когда в рамках одной лаборатории удается замкнуть контур управления - разработать не только сам объект, но и алгоритм управления, а потом еще и реализовать его в настоящем железе. Интересны наработки в Penn University (можно посмотреть ютуб просто по запросу grasp lab university of pennsylvania, чтобы увидеть их результаты). Потом, поковырявшись на сайте лаборатории, можно найти публикации. А начинается весь поиск с очередного видео под бойкую музыку, не слишком пестрящего инжерными деталями, но дающего неплохой повод воспользоваться поисковиком. Например, вот c этого я начал искать, что делают в Penn University.

Как раз мне больше интересны частности, невидимые на уровне попсовых публикаций. Если меня копнуть, то окажется, что я существенно больше знаю о том, как устроены кишки ROS, чем может показаться на первый взгляд. То есть я оригинальные документацию и публикации читаю, а ролики смотрю по-минимуму. Про ссылки -- да, ваш интерес к MathLab, конечно, понятен и оправдан, но мой интерес чуть пошире. Так, пролёты через местность с препятствиями (например, квадрокоптер по лесу на высоте метра) обеспечиваются unsupervised learning прежде всего, а это на сегодня чистый Python. Плюс среды моделирования (типа Stage), которые делают возможным сверхбыстрый прогресс. Вообще, крайне интересная и прорывная область, в ней настоящий взрыв исследований идёт. Мне тоже интересно, как замыкают то, что вы называете "контур управления" -- от датчиков до приводов, интегрируя по пути с железом. Но если вам интересно, как это делают в одной лаборатории, меня крайне интересует, как можно интегрировать в это дело несколько лабораторий/фирм (железо из одной, датчики из другой, алгоритмы частью из третьей, частью из четвертой, и т.д.). Как научить этим премудростям, это тоже важно. И не столько студентов, сколько кого угодно (например, сотрудников, которым нужно начинать робототехникой заниматься. Им ведь даже учебник сейчас нельзя дать читать: там каждые три года меняется понимание, меняется поколение алгоритмов и инструментов, меняется поколение железа. Учебники просто не успевают, основные статьи устаревают так же стремительно, и остаются "историческими"). Что делать в такой ситуации непонятно, и поэтому крайне любопытно.

Рад узнать, что частности интересны. Я слежу больше за университетами, потому что их проекты проще всего изучить детально: в отличие от коммерческих предприятий, они довольно охотно делятся ноу-хау и теми самыми кишками. Заметна и тенденция к project-based learning, где люди задумываются не просто о "быстрее сделать", но о том, как совершенно разных специалистов научить работать друг с другом для быстрого получения качественного и недорогого результата. Странно, но я не замечаю впрямую ссылок на практики системной инженерии. Наоборот, иногда встречается непонимание разницы между просто system engineering и software system engineering. Не только у нас. К слову о деталях. Посмотрите на досуге сайт проекта E.D.W.A.R.D.. Товарищи довольно аккуратно собирают в одном месте отчеты и публикации по проекту. Насчет средств работы (инструментов - не техник): разбираясь в различных историях и текущих проблемах компаний, я заметил, что проекты иногда упираются в языки вроде Python. Тот же пример с квадрокоптером, облетающим препятствия: когда речь заходит о масштабировании задачи на семейство квадрокоптеров, выполняющих какую-то функцию совместно (к примеру), компания начинает искать средство программирования более высокого уровня абстракции - каузальные исполняемые блок-схемы или акаузальные физические сети. Эта проблема возникает не из-за плохого содержания старых наработок и невнедрения практик, а из-за трудности применения этих самых практик для языков с относительно низким уровнем абстракции, для различных инструментов между различными отделами. В этом случае единство среды разработки и относительно высокий уровень абстракции языков программирования (блок-схемы, акаузальное моделирование) мне видится хорошим решением. Понятно, что это упирается в свои ограничения, но думать о том, как бы обеспечить работу отделов - разработчиков механических железок, алгоритмистов и программистов микроконтроллеров - приходится заметно меньше. То есть, резюмируя, мне думается, это неплохо, когда единая среда разработки частично решает хотя бы проблему обмена информацией между несколькими отделами. И ей можно прощать относительную закрытость. P.S.: ну и, чтобы два раза не вставать - небольшой оффтоп. Мы однажды беседовали об акаузальных средствах моделирования, и вы замечали, что у нас уж очень мало кто знает о Modelica, особенно в конструкторских бюро (в тех, оставшихся со старых времен). Спешу обрадовать: в одном самарском авиастроительном предприятии OpenModelica используется по назначению и приносит хорошие результаты. Конечно, в масштабах отдельных представителей отдела (это ни разу не стандарт предприятия), но всё равно неплохо. А началось всё с записей ваших лекций.

В Python очень мало пишется на самом уровне языка: это ведь прежде всего скриптовый язык, т.е. как раз "высокоуровневый", в нём есть средства вписывания в него разных DSL и разных других библиотек -- его использование как "клея" для единой среды разработки хорошо описывается для научного компьютинга, на эти темы проводятся конференции с обменом опытом, есть и фирмы-поставщики специнструментария (пример типичной презентации из этой области -- http://www.youtube.com/watch?v=mLuIB8aW2KA). В том числе там огромное количество библиотек для всяческой визуализации, огромное число библиотек с разными алгоритмами. Иногда (и даже часто) тамошнее хозяйство бывает чересчур клочковатым и неудобным в использовании, но акаузальность тут явно не про выбор языка. Что же касается объединения разных вычислений, то опять-таки вопрос в данных чаще всего, а не в собственно языке. Питон в этом случае просто предоставляет библиотеку парсера тех или иных данных. Про самарских авиастроителей порадовали. Я подозревал, что КПД этих лекций чуть побольше, нежели просто обучение пары десятков студентов, но никто же не говорит об их пользе -- вот так случайно и узнаю... Кстати, буквально на днях выложили по этой ссылке на сайте кафедры две последних лекции курса, года с момента окончания лекций не прошло! :-)

Сколько я ни смотрел на GitHub, и даже пользовался им — участвовал в проектах, слал pull requests, — так и не понял, чем он столь хорош, что на него все бегут. По-моему, это просто мода. Чем он лучше какого-нибудь SourceForge, Gitorious, тысячи их? Могу сказать, чем он мне лично не понравился. Кривенький web-дизайн, плохо влезает в мой браузер (у меня стоят крупные шрифты). Слишком много AJAX и анимации.

Разным людям разные конфеты нравятся. Кому-то AJAX не хватает, а кому-то его много.