roboforum.ru

Единственное чего реально может быть нужно на текущем уровне развития - контроль доставки.

адрессация нужна при более чем 2-х участниках передачи. это и датчики и исполнительные механизмы и все что угодно. ты смотришь узко на передачу точка-точка, хотя малейший шажок в сторону (если надо синхронизировать уз маяки) и уже надо городить новый огород. это не универсально.

Не понял о чем речь?

о том, что такое одоробло на роботе мало кому будет интересно.

О каком TCP/IP по UART'у может идти речь? Чего там нужно кроме контроля доставки?

тебе все равно прийдется все заворачивать в ip. другого способа отправить данные в ip сеть (коей является интернет) просто нет. это все равно произойдет. да и подозреваю, что ты упираешься, так как думаешь, что это сложно и дорого? но на сколько я понимаю, все это работает на доступных avr, которые здесь не новость. сильно не вчитывался, так как с ангельским плохо, но вот:
http://www.laskater.com/projects/uipAVR.htm
http://www.embeddedrelated.com/usenet/e ... 7424-1.php

Пробросить ком чезез tcp\ip? Не проблема — в примерах к PySerial есть махонькая програмка для этого.

Реализацию на ПК я вижу такой:

1. Нужно написать демона, который с одной стороны общается с платформой, а с другой предоставляет интерфейс к пользовательской программе. (бакэнд)
   Какой интерфейс не имеет значения, это может быть и tcp и unix-сокет и dbus и т.п.
   Главное чтобы пользовательское приложение могло получить высокоуровневый асинхронный доступ (мы же собрались замахнуться на веб)
2. Пишется веб-приложение (fcgi, wsgi, etc.) которое взаимодействует с пользователем. (фронтэнд)

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

Добавлено спустя 4 минуты 15 секунд:
Заворачивание всего низкоуровневого трафика в ip не вижу смысла.
Это не нужное переусложнение системы. Следуйте KISS.
В I2C есть адресация, и ее достаточно для работы с датчиками.
Броаткаст ЕМНИП тоже есть.

RoboTok писал(а):DeaD
Так вы хотите на базе своих модулей городить управление через инет ?
ИМХО слишком мутная штука выйдет и дорогая по железу.

Ничего себе выводы пока я наоборот говорю frig'у, что смысла нет делать TCP/IP до ИК-дальномера и нужно на нижнем уровне юзать i2c и UART.

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

Сергей писал(а):Ха, нада сделать переходник LAN->UART

Как вариант, а вообще выше выложен такой переходник за 40 баксов готовый, только разумеется без RoboBus'а.

frig писал(а):в общем очень похоже, что народу очень нравится изобретать велосипед каждый раз, когда возникает необходимость его использовать. чужие грабли никого не интересуют и наработки тоже. грустно.

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

2All
выступаю противником мощной аппаратуры для простых роботов. не надо в радиоуправляемую тележку пихать 512К памяти и портированный линух, что-бы поморгать светодиодом

=DeaD= писал(а):А вот тут всего лишь вопрос совокупной стоимости (включающей не только стоимость железа, но и стоимость времени на его освоение). Сейчас AVR работает на частотах 16МГц и имеет килобайты памяти, а на них делают робота, который может стукнувшись бампером отъехать назад и повернуть. И что?

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

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