Arduino.ru

Где редактировать я не нашел, придется дописывать отдльным постом..

По-моему скромному представлению алгоритм примерно такой:

в сетапе:

инициализируем Com-порт, пишем что для хелпа нажмите "H"

в лупе: ожидаем прихода чего-либо с ком порта:

если приходит какой-либо символ делаем что-либо. (Как вариант switch(symbol) { case A: ... break; ... case D: .. break;} где под этими кейзами, например, "вначало", "хелп", "выбрать горизонтальную ось", "выбрать вертикальную ось", "остановка", "взять деталь", "положить деталь".

Если мы выбираем "начало" (приходит, допустим N) то он едет до концевиков в определенную сторону,  (для калибровки, иначе я без понятия как он сам для себя(внутри программы) определит положение);

Если мы выбираем хелп, выдается серия принтлнов с пояснениями;

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

Если выбираем вертикальную - аналогично.

Остановка - понятно:)

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

Что непонятно:

1)можно ли сделать такое "контекстное меню", т.е. 1й уровень - вводим букву, от которой зависит, что мы делаем; при выборе буквы потом где-то надо будет вписать цифру..? 

2)в силу того, что движки мощные, управление происходит через релешки(по2 реле на движок, соотв по 1 ножке на каждую реле итого 6 ножек на двигатели): хотим поехать вперед на 1ю ножку 5в, реле открывется, питание идет на движок. В другую сторону - на эту 0, питание на 2й ножки 5в, он едет обратно. Чтобы "контекстное меню" было доступно только когда движки не двигаются, надо вводить флаги (условно назовем их "олредиран"), которые отвечают на вопрос - двигатель стоит? или он движется?  в связи с этим собственно вопрос:

значение у такого флага может быть только тру-фолс? или -1, 0, 1 ? (как пример:

t=symbol-newsymbol;

if (t<0) {

reletuda;

alreadyrun=-1; }

ifelse(t>0) {

relesuda;

alreadyrun=1; }

else {

migdenado;

allreadyrun=0;

}

?

3) Т.к. датчики на 1 проводе, программно надо определять у какого мы находимся.. что-то аля: 

...

VD = analogRead(1)

...

if(VD1==1)
{
if(allreadyrunVert==-1) counterVert--;
if(allreadyrunVert==1) counterVert++;
if(counterVert==a1 && allreadyrunVert!=0) STOP();
}

куда пихать эту часть? в цикл проверки всех олредиранов в начале или нет? 

*т.е. сначало VD = analogRead(); по всем датчикам

потом условие движения:

if(alreadyRunV == 0)&&(alreadyRunH == 0)&&(alreadyRunS == 0) по 3м осям - внутрь этого условия?..

 Ну и в меньшей степени интересующий меня вопрос(сомневаюсь что оно мне нужно):

можно ли сделать интерфейс управления этим самым делом?

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

все ячейки - кнопки. кликаешь на ячейку, он понимает что ты хочешь туда поехать - едет.  - Целесообразно ли это сделать, или нет? Да и вообще можно ли?

Работы на несколько часов - это только кодирование. Потом этап отладки. А перед ним - алгоритмизация процесса. Это отдельный вопрос, который решается в паре с технологом. Из опыта автоматизации могу заметить, что, как правило, все не так просто, как кажется на первый взгляд. Особенно, если нужен пользовательский интерфейс. И датчиков положений много не бывает, бывает только мало :(

 >значение у такого флага может быть только тру-фолс? или -1, 0, 1 ? (как пример:

Значение может быть любое. Можно 0,1,2,3,4. Только тогда это уже не флаг называется. А как-то типа "режим", "состояние" и т.п.

Лучше не кодить "цифры", а использовать константы, enum-ы и т.п.

>для опытного программиста работы максимум на 1день

Хе-хе. Опытные от такой фразу сразу дернутся как черт от ладана. Дьявол как раз в деталях. И какая-то мелочь, спокойно может заставить ковырятся пару дней.

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

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

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

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

Это не в упрек. Как для "заказчика", как "стартовое" - вы дали очень не плохое описание. Но для старта реальной работы, нужно еще 10-ть тысяч вопросов задать и кучу подготовки проделать.

По поводу "меню", "интерфейсов" и проч. - все возможно. Было-бы время и бюджеты. Но тут вылазит другая сторона медали - наем программера вещь довольно дорогая. Все арудино-проекты, где "за пару баксов сделали то что продается за тысячи" - неявно подразумевает, еще и кучу $$ потраченные на работу. Которые обычно не считают. Приводят расчет только стоимости деталей.

А когда вы видите что что-то продают за $100 уже с готовым софтом, так там работа програмера отбивается за счет массовости продаж.

Так что подумайте потянете ли вы. Готовы ли вы к тому, что в итоге софт вам обойдется на порядки дороже железа. Может проще найти готовое решние?

Ну либо искать программера который будет работать "из интереса" (фактически делать свой вклад в ваш проект, это тоже не редкость)

На память приходит где-то вычитанный "закон Мерфи": "Начальную оценку нужно умножить на 4 и взять единицу измерения более крупную" Так что 4 часа превращается в 16 дней - это реально, ввиду того, что даже если "железная" часть готова, ее приходится дорабатывать, настраивать и переделывать, ибо проекта, где все учтено коллективом умных дяденек в проектном бюро, нет. Да и смежники (монтажники) постоянно подводят.

Так что если "возможна оплата" подразумевается "практически бесплатно", то Вам здесь смогут помочь, разве что, кодированием. Если напишите грамотный алгоритм, то Вам кто-нибудь поможет с программой. Хотя бы я :)

Все "железо" есть. Оно сейчас в стадии проверки работоспособности. Закупка ничего нового - не планируется(замену не работающего не причисляю к закупке нового). 

2Алекс.

Что вы подразумеваете под грамотным алгоритмом? Примерный алгоритм я могу написать. Меня, в принципе, хватило на всю прогу, но когда я начал куски складывать воедино... я плюнул на все это дело и стал уже писать не кусками, а целиком. В итоге мало что получилось. Алекс а можно вашу почту/скайп/аську для контакта? :)

2Leshak.

Мммм, ну скажем так. У меня написано многое, из того что я хочу туда впихнуть (я так думаю, по крайней мере, но как может выясниться - это не так), но как это скомпоновать в единую программу я не знаю. Есть пара идей, которые проверяются методом тыка :) "Работы на 1 день"  - мне хотелось бы узнать типовые примеры решения тех проблем, которые есть у меня. В частности, в этой же ветке обсуждается(лся) "Перевод принятого символа с com-порта в число", который и мне пригодится.

Да, пишите очень подробный алгоритм и если механическая часть готова выкладывайте фото, видео, что бы конкретно представлять о чем идет речь.

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

Я тоже раньше увлекался написанием программы, когда есть только примерный алгоритм. Теперь сначала стараюсь породумать алгоритм и "пляшу" от состояний (фаз) системы (имеется в виду и программа, и механика).

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

>Теперь сначала стараюсь породумать алгоритм и "пляшу" от состояний (фаз) системы

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

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

Все хотят что-бы изначально заказчик сформулировал "четкие, непротеворичивые и детальные требования". Только в реальности это сферический конь в вакууме. Встречается редко. Приходится работать с тем что есть. А в реальности осознания реальных требований у заказчика возникает только когда он "что-то пощупает в руках". И это не исключение, а правило.

>> Все хотят что-бы изначально заказчик сформулировал "четкие, непротеворичивые и детальные требования". Только в реальности это сферический конь в вакууме. Встречается редко. Приходится работать с тем что есть. А в реальности осознания реальных требований у заказчика возникает только когда он "что-то пощупает в руках". И это не исключение, а правило. << 

Я если что то кому то пишу то перво наперво обговариваю алгоритмы. Чтобы потом не было "Давайте вот это переделаем (уберем/добавим)" и т.д.

Нормальные заказчики бывают. Я не давно работал с одним удаленно . Так он железо паял , я программу писал.

Отладка программы УДАЛЕННО это геморой тот еще , но вроде получилось. А железо (тем более если оно подвижное) эмулировать

придется в любом случае.

 >Я если что то кому то пишу то перво наперво обговариваю алгоритмы.

Сильно зависит от того насколько я знаком с предметной областью заказчика. В идеале мы обговариваем систему как "черный ящик". Он говорит что у нее должно быть на входе, что на выходе. А как она добивается этого, какими алгоритмами - это мое дело. Заказчик может и не обладать алгоритмическим мышлением. И только если я слабо знаком с предметной областью,заказчику нужна реализация конкретного алгоритма, или просто он хочет "вникнуть в детали, обучится" - говорим про детали реализации.

>Чтобы потом не было "Давайте вот это переделаем (уберем/добавим)" и т.д.

А почему нет? IMHO это нормальное состояние. Требовани - меняются, осознание их - тоже. Свойство человека. Особенно если что-то сложное,  четко все зафиксировать сразу - не возможно. Либо потребуют дичайшего перерасхода времени.

Если клиент понимает что уберем/добавим - это работа и готов ее оплачивать, почему нет? Наоборот, желанный. Постоянный клиент.

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

>Отладка программы УДАЛЕННО это геморой тот еще

Ну, если бы все было просто, то программеры были бы голодными. Плюс это интерестно.

В некоторых случаях можно com-порт по сети пробросить и работать с удаленным железом. Я, например, даже дома так работаю. ArduinoIDE у меня стоит на одной машине, а сама arduina подключена к ноуту (физически туда удобней). И все замечательно работет.

> А железо (тем более если оно подвижное) эмулировать придется в любом случае.

Это да. Даже когда железо есть под руками. Я вообще поклонник TDD. Так что, когда есть возможность - стараюсь эмулировать все что только возможно.