roboforum.ru

Dead, понимаю к чему Вы клоните, спрашивая )))



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



Еще как говорили ) Вон господин Казаринов заложил аж три месяца работы и вышло у него 9600 только на кодера. Это при том, что он обычно ошибается как по времени, так и по срокам )))) И это было ПОСЛЕ смены ТЗ и троекратного упоминания об этом.

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


Ключевое слово выделено

Добавлено спустя 1 минуту 59 секунд:
PS: Поправил чуть сообщение после публикации

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Dead, Вас понял ))))))))

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

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

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


Ну понятно, что все под Богом ходим. Ударит молния в рулетку, считыватель не сработает. Гибче надо подходить к цифрам.


Конечно не успели, Вы поспешили дать свою оценку.
Вы серьезно полагаете, что после той суммы и сроков, которые Вы объявили, был смысл предлагать неделю на разработку и 500 долларов?


Это в каком-то идеальном мире, наверное.

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

Из интереса посмотрел ютубовские ролики (по запросу "roulette spin -chat" их уйма). Так я уверен, что и скорость+положение шарика можно выводить в реалтайме с той же вебки - шарик-то там вполне заметен.

Выделить зону между двумя эллипсами, где шарик бежит, побить ее на штук 20-30-50 секторов, в каждом тупо усреднить все яркости пикселей и эти значения для каждого сектора записать как опорные в состоянии, когда никакого шарика точно нет. А потом уже с шариком проделать то же самое, вычесть из полученных яркостей опорные и найти максимум. Номер сектора с максимальной разностью яркости даст положение шарика. Причем даже в случае, если шарик на картинке смазан. И пусть максимальная погрешность позиции шарика будет 20-30 градусов, это ж дла рассматриваемой задачи вполне приемлемо. Чтобы получить скорость, взять позиции шарика за предыдущие несколько десятков измерений и найти коэффициент линейной регрессии (просто конечная разность (alfa_n+1-alfa_n)/dt будет шуметь сильно).

Можете попробовать выдать данный алгоритм и еще пару сот баксов вашему программисту, если не жалко. Я не даю 100% гарантии что заработает Если серьезно, кстати, цифра 100% в первом посте я считаю была едва ли не самым большим фактором роста цены разработки. 100% означает 99.99...% с любым количеством девяток. А каждая девятка стоит своих дополнительных денег. Таким образом вы этой цифрой как бы дали понять - заплачу любое количество денег.

А что за применение, кстати, если не секрет - контроль за реальным столом или рулеточный автомат какой-то?

Я сам о применении пару раз спрашивал(мимо ушей). Или ноу-хау или криминал похоже...

_________________
Роботы, уже среди нас...
Прошу прощения за аватар, никак схему динамической индикации не могу настроить :)

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

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

Всем привет!

Boez, спасибо Вам большое за участие. Я согласен с Вами в том, что 100% могло смотреться несколько вызывающе. Весь сыр-бор разгорелся из-за того, что никто из уважаемых донов не сказал ничего конкретного по воплощению идеи, все сразу началось с денег, причем немалых и совершенно (ну совершенно!) непонятно за что.

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

Vadinator, Вам тоже запоздалое мерси за то что предлагали решения по делу вместо разделки туши пресловутого медведя.

Собсно вопрос, а где это у вас казино?

Тсссс! Подпольное воронежское казино

Было бы у меня казино, я бы такой фигней не занимался

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

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

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