Wzajemne zakłócanie się czujników w robotach sumo

W robotach sumo najczęściej stosuje się czujniki na podczerwień. Lecz jeśli 2 czujniki będą pracować na tej samej częstotliwości i znajdą się na przeciwko to mogą się wzajemnie zakłócać, co może uniemożliwić walkę.
Jaka jest wtedy reakcja sędziów ???

Jak to zaklocac? Jak masz czujnik na powiedzmy 36kHz (czyli standart) to jego dzialanie opiera sie na zasadzie odbitego od przeciwnika podczerwonego swiatelka, tak? No to jesli przeciwnik nadaje tez 36kHz to raczej nie przeszkadza, a nawet pomaga no nie? bo jak dostaniesz w czujnik 36kHz to wykryje ci sygnal i niewazne czy to jest twoj odbity czy nadawany przez przeciwnika.

Ale ja chce wykorzysta czujnik sharpa, który ma zasięg 20-100 iluś tam. I poniżej 20cm napięcie jest takie samo jak powyżej 20cm. Dlatego chce wykorzystać czujnik podczerwieni o zasięgu <20cm co pozwoli określić czy mierze powyżej 20cm czy poniżej. Dlatego też jak przeciwnik mi przywali wiązką z odległości np. 50cm to czujnik radar się zmyli. I uzna tą odległość za ok. 5cm - http://www.junun.org/MarkIII/datasheets/GP2Y0A02YK.pdf

Danielu, przestań kombinować. Tutaj chodzi o walkę fair, a nie kombinowanie. Z resztą piszesz i piszesz już o robotach i zawodach tak dużo, ale czy w ogóle masz pojęcie o co w tym chodzi? Naprawdę, wymyślasz dziwne rzeczy, jakbyś tylko chciał sobie nastukać postów... Jak dobrze pomyślisz, i poszukasz, to znajdziesz odpowiedź.

Jeśli masz wątpliwości co do regulaminu, to skontaktuj się z organizatorami.

zerpo napisał:

Jeśli masz wątpliwości co do regulaminu, to skontaktuj się z organizatorami.

Właśnie to robię - na forum jest członek organizatorów.

Reszty Twojego posta nie komentuje bo normalnie szkoda słów

Dodano po 1 [minuty]:

Pozatym nie znam adresu e-mail organizatorów.

Dodano po 2 [minuty]:

Poprostu jeśli mój robot dostanie wiązkę podczerwieni o tej samej częstotliwości z odległości większej niż 15cm – to radar się pomyli i będzie robić uniki zamiast ataków.

To jeśli robot jest blisko robi uniki, a jeśli daleko atakuje? Nawet jeśli na odwrót to beznadziejnie, bo robot nigdy nie zaatakuje.

Zakłócenia ze strony przeciwnika będą i nic na to nie poradzisz, musisz tak napisać program żeby one ułatwiały odnalezienie przeciwnika

To nie takie łatwe!!
Mój robot określa położenie przeciwnika, prędkość i porównuje z czasem potrzebnym na atak. Jeśli czas na atak jest dłuższy to robot ucieka. Więc zakłócenia przeciwnika uniemożliwią walkę bo robot będzie cały czas uciekać.

Jak ma się do tego to ???:

zabronione jest:
- zakłócanie pracy urządzeń elektronicznych w robocie drużyny przeciwnej poprzez wykorzystanie jakichkolwiek urządzeń zakłócających
(...)

Dodano po 1 [minuty]:

McRancor napisał:

To jeśli robot jest blisko robi uniki, a jeśli daleko atakuje?

Tak

Danielu, czy Ty w ogóle już coś zbudowałeś z dziedziny robotyki, co by działało? Albo chociaż prosty układ z uC? Wątpię. A zabierasz się za robota sumo, który jest naprawdę trudną konstrukcją. A Ty jeszcze określasz (napisałes w czasie teraźniejszym) prędkość przeciwnika, jakbyś już dawno miał to zrobione. Jest tak? Nie udawaj już proszę fachowca...

I to, że przeciwnik korzysta z tej samej częstotliwości czujnjków, to nie jest zakłócanie, wystarczy się zastanowić, pomyśleć. Każdy czujnik coś generuje i teoretycznie może zakłocic pracę przeciwnika. Z tego by wynikało, że nie wolno stosować czujników, a to przecież bzdura.

Gadm często z Danielem i wiem ze robi DZIAŁAJĄCE konstrukcje z uC i związane z robotyka chwilowo zapewne nic takiego nie robi
bo mówił mi że chce dokończyć swoją nauke Bascoma.

treker napisał:

Gadm często z Danielem i wiem ze robi DZIAŁAJĄCE konstrukcje z uC...

Jeśli tak, to przepraszam, że się uniosłem.
Jednak nadal uważam, że Daniel mierzy o wiele za wysoko chcąc mierzyć prędkość przeciwnika sumo.
Danielu rozwiń najpierw swoje umiejetności Mikorkontrolerowe, a zdasz sobie sprawę, że zimplementowanie tego, o czym wspomniałeś w programie jest baaaardzo skomlikowane...

Damian(treker) – Teraz jestem na nauce komunikacji przesz rs.
Zerpo- Czy ktoś pytał Cię o zdanie ??
Uczę się bascoma i robię w głowie na razie projekt robota na 3-5prockach !!!
Komunikacja ju7ż zaprojektowana – ale muszę się nauczyć rs’a żeby sprawdzić czy działa.
A ten czujnik na podczerwień jest po to żeby nie mierzyć 20-15cm tylko 0-150cm.

Dodano po 2 [minuty]:

zerpo:Dlaczego trudne ??
Mierze odległość robota, po sekundzie drugi pomiar i teraz proste działania arytmetyczne – co w tym trudnego ??

Dodano po 1 [minuty]:

A kupować części zaczynam 15maja - wtedy przypływ kasy nadchodzi

Dlaczego trudne?
Wyobraź sobie sytuację:
Twój robot porusza się, robot przeciwnika też. Roboty najcześciej nie poruszają się po linii prostej, jeżdzą po łuku, robią nagłe zwroty, przyspieszają i zwalniaja. Wszystko się dzieje dość szybko. Może mniej istotne, ale ring tez jest nierówny.
Czy sytuacja nadal jest prosta? Mierzyć prędkość innego przedmioty z punktu wiudzenia poruszającego się przedmiotu... Sytuacja byłaby do opanowania, gdyby te dwa roboty jechały prosto na siebie ze stałą prędkością, da się to zrobić, ale inaczej... Zadanie będzie niezwykle trudne, może kolega czaina się wypowie, on coś wie, na temat systemów wizyjnych...
Inna sprawa to częstotliwość pracy czujnika, którego chcesz zastosować - Sharp gp...cośtam. Dokonuje on tylko kilka pomiarów na sekundę, a to może okazać się za mało. Może się stać, że po 3ch pomiarach robot przeciwnika zdazy już pod Twojego podjechać, a Twój nawet nie zdązy zmierzyć prędkości.
Inna sprawa jeszcze to sam fakt, czy tego typu uniki w ogóle są potrzebne. Wszystko tam się dzieje często (bo niektóry roboty były dość wolne) szybko. I może być tak, że będziesz robił unik, a tamten robot znajdzie cię podczas uniku...

Mam ciekawe zadnie dla Ciebie i obiecuje, że nie jestem w żaden sposób zgryźliwy. Weź kartkę, rozpisz sobie jakie masz dostępne sygnały zewnętrzne, z czujników. I zacznij pisać sobie algorytm, co ma się po kolei dziać. Zwróc uwagę na to też, ze uC nie przetwarza sygnałów równolegle i operacje też wykonuje jedna po drugiej... Chcąć więc skakać z jegnego miejsca do drugiego w programie musisz napisać bardzo zmyślne procedury, które umożliwą Ci pracę pseudo-wielowątkową...

Nadal łatwe? A to dopiero początek...

Podzielam zdanie zerpo sprawa nie jest taka prosta
daniel93 jeżeli chcesz w prosty sposób rozwiązać zakłócenia emitowane przez przeciwników to istnieje coś takiego jak modulacja wiązki promieniowania IR , poszukaj sobie tematów związanych z barierami optycznymi zrozumiesz o co chodzi
przy takiej konstrukcji uC otrzyma tylko sygnał z Twojego nadajnika IR i bedziesz miał wyjątkowego pecha jeżli ktoś będzie modulował sygnał na tej samej częstoliwości , jeszcze inne rozwiązanie to kodowanie sygnału , ale to już chyba " sztuka dla sztuki "

Cytat:

Uczę się bascoma i robię w głowie na razie projekt robota na 3-5prockach !!!

jestem pełen podziwu 3-5 procków ..... pochwal się układem na 1 procku pokaż co potrafi Twój program

Zerpo’a już przekonałem i uznał, że jakieś szanse mam
bogdan_p: to jest myśl !!! A żeby nie było konfliktów to dam 2 częstotliwości do wyboru i zapytam przeciwnika na jakiej częstotliwości nadaje

Dodano po 48 [sekundy]:

Jka coś powstanie to poinformuje...

Daj przykłady jakichś swoich konstrukcji Daniel

He he nie było na nie czasu - cała moc poszła w naukę bascoma <ops> ale spoko maroko zarys za niedługo będzie.
A jak cos się uda to opublikuję

daniel93 napisał:

Zerpo- Czy ktoś pytał Cię o zdanie ??

zerpo, podziwiam samozaparcie

I teraz nawet mogł bym coś napisać na temat, ale nie wiem czy nie dostanę podobnej odpowiedzi od autora...

daniel93 napisał:

Zerpo’a już przekonałem i uznał, że jakieś szanse mam

Co do tych szans to napisałem tak:
"szanse masz, jesli bedziesz stopniowo podchodzil do wszystkiego, a nie naraz"...

Tawez: dzięki, trzeba walczyć.

daniel93 napisał:

Zerpo- Czy ktoś pytał Cię o zdanie ??

Myślałem, że idea forum na tym polega, że każdym może się wypowiedzieć w danym temacie.
Ale dosyć już tych małych "przepychanek".

Gadając z Danielem wywedziałem się, że ma on w planach budowę sumo-robota, z bardzo skomplikowanym systemem wykrywania przeciwnika. Składać się on będzie z głowicy umieszczonej na serwomechaniźmie. Głowica będzie zawierać przynajmniej podczerowny czujnik odległości Sharp'a i coś tam jeszcze. System będzie miał za zadanie znalezienie przeciwnika, zmierzenie jego prędkości oraz dystansu i w efekcie decyzję o tym, czy robot ma wykonać unik i zajechać przeciwnika od boku/tyłu, czy atakować. Całość ma się opierać o kilka uC, które będą się komunikować za pomocą protokołu własnego pomysłu.

Mi się wydaję to trochę gra nie warta świeczki. Trochę już pisałem powyżej dlaczego. Owszem można zasotować system uników, ale żeby zbudować układ który umożliwi robotowi otrzymanie takich informacji, żeby 'wiedział' jak jechać, żeby 'dorwać' przeciwnika od tyłu to już lekka przesada. Nie wyobrażam sobie w ogóle jak amator jest w stanie zbudować tak skomplikowaną zabawkę.

Apropo ruchomej głowicy, to w tym roku na Sumo Zawodach w Poznaniu był robot mający sonary (może coś jeszce) na takiej ruchomoej wieżyczce. Fajnie to wyglądało, jednak robot odpadł bardzo szybko, miał nawet problemy w eliminacjach...

Moim zdaniem więc przedsięwzięcie Daniela mierzy zbyt wysoko i jest zbyt skomplikowane jak na początek dla amatora... Aplikacja takiego systemu w sumo-robocie na pewno będzie bardzo efektowna, ale czy na pewno opłaca się tracić tyle czasu i pieniędzy na to?

"kukulka" odpadla bo albo ten sonar nie dzialal, albo byl zle zrobiony. Nie wiem czy zauwazyles, ale ani razu nie zatrzymala sie ta glowica (moze tak mialo byc, bo mogl mierzyc wielkosc przeciwnika, ok, ale wg mnie lepszym rozwiazaniem bylo by zatrzymanie sonaru i ustawienie robota w kierunku ktory sonar wskazuje)

Danielu, montowanie kilku uC wg mnie troche mija sie z celem, tak samo jak wymyslanie wlasnych protokolow. Lepiej zastosowac jeden mocniejszy (np. rodzina ARM). Jezeli nie chcesz kombinowac z nowym typem prockow (a podejrzewam ze uzywasz jedynie AVRow) to poczytaj troche o UART, albo/i o TWI. Prawie kazdy AVR jest wyposazony w UART, a niektore w TWI (jak nie znajdziesz o TWI materialow to poszukaj o i2c, to prawie to samo). Jezeli zastosujesz kilka uC to glownie beda sie zajmowac przesylaniem danych zamiast ich przetwarzaniem i glowny procek zapchasz, bo dla AVRow maksymalny kwarc to 16MHz, a to wg mnie za wolno.

gromnik19 napisał:

"kukulka" odpadla bo albo ten sonar nie dzialal, albo byl zle zrobiony. Nie wiem czy zauwazyles, ale ani razu nie zatrzymala sie ta glowica (moze tak mialo byc, bo mogl mierzyc wielkosc przeciwnika, ok, ale wg mnie lepszym rozwiazaniem bylo by zatrzymanie sonaru i ustawienie robota w kierunku ktory sonar wskazuje)

Zauważyłem, że ta głowica, jak coś było na widoku, to obracała się w tamtym kierunki o podążała za celem. Więc to na pewno działało. Dlaczego robot sobie słabo poradził, to nie wiem, może drużyna nie miała czasu dopracować programu...

Sporo do wyjaśnienia

ja napisał:

Zerpo- Czy ktoś pytał Cię o zdanie ??

Przyznam, że byłem wtedy lekko zdenerwowany – tak więc przepraszam...

zerpo napisał:

daniel93 napisał:

Zerpo’a już przekonałem i uznał, że jakieś szanse mam

Co do tych szans to napisałem tak:
"szanse masz, jesli bedziesz stopniowo podchodzil do wszystkiego, a nie naraz"...

Ja od początku podchodzę modułowo...

zerpo napisał:

podczerowny czujnik odległości Sharp'a i coś tam jeszcze

Jeśli ktoś widział charakterystykę napięć tego czujnika to wie, że poniżej 15cm napięcie się powtarza. Więc to „coś tam jeszcze” to jest czujnik na podczerwień o zasięgu 15cm. Dostarczy to informacji czy mierzę odległość mniejszą czy większą od 15cm. Więc jeśli robot będzie nadawać na mojej częstotliwości to mój bot będzie myślał, że mierzy mniejszą odległość niż 15cm.
I to był problem w tym wątku.

Ma ktoś jakiś pomysł na filtrowanie częstotliwości ??
Według mnie one się nakładają

zerpo napisał:

które będą się komunikować za pomocą protokołu własnego pomysłu.

Tu wdarła się pewna nieścisłość ponieważ uC mają się komunikować przez USART + 1 pin. Te dodatkowe piny mają być ze sobą połączone. Cały algorytm działa tak:
Sprawdzam czy stan pinu dodatkowego to 0 jeśli tak to ustawiam tam 1 i przesyłam przez USART id procka docelowego i id procka, który przesyła(to pierwszy bajt). Później lecą polecenia i po wszystkim na pinie dodatkowym jest 0(linia wolna).

gromnik19 napisał:

Danielu, montowanie kilku uC wg mnie troche mija sie z celem, tak samo jak wymyslanie wlasnych protokolow. Lepiej zastosowac jeden mocniejszy (np. rodzina ARM). Jezeli nie chcesz kombinowac z nowym typem prockow (a podejrzewam ze uzywasz jedynie AVRow) to poczytaj troche o UART, albo/i o TWI. Prawie kazdy AVR jest wyposazony w UART, a niektore w TWI (jak nie znajdziesz o TWI materialow to poszukaj o i2c, to prawie to samo). Jezeli zastosujesz kilka uC to glownie beda sie zajmowac przesylaniem danych zamiast ich przetwarzaniem i glowny procesor zapchasz, bo dla AVRow maksymalny kwarc to 16MHz, a to wg mnie za wolno.

16Mhz to nie jest wolno biorąc pod uwagę, że każdy proc ma określone zadanie.
A ja umie programować w bascomie więc do ARMów to ma się nijak
Z tym zmulaniem procków przesyłaniem danych to nie powinno być tak źle.Np. dane z sonaru do proca głównego mają lecieć co 0,5sekundy.

Ps> Nie było błędów ortograficznych

Z tym muleniem przez transmisję to racja. Sam proces przesyłania danych też trwa chwilę. Poza tym chcąc przesyłać większe ilości danych trzeba odpowiednio skonstruować protokolik przesyłania tych danych, wprowadzić pewne opóźnienia, żeby to wsyztko nadążało.

Załóżmy taką sytuację (zakładam, że transmisja obslugiwana jest w przerwaniu):
Sonar zaczyna transmisję. W tym samym czasię Twój robot najeżdża na białą linię... Jak wtedy się zachowasz?

Poza tym 0,5 sekundy to troche słabo. W tym czasie przeciwnik może przejechać Tobie przed nosem i sonar nawet tego nie chwyci.

Nie chce niekogo tutaj odwlekać od pomysłu, sam mam zamiar następnego robota zrobić na 2ch, może w przyplywie genialnego pomysłu 3ch prockach, ale nie mam zamiaru zapychać magistrali ciągłym wysyłaniem danych. Zdaj sobie sprawę, że taka mała sieć może Ci zepsuć niemało zdrowia. Mała zmiana programu jednego uC może oznaczać konieczość przeprogramowania całej reszty, a to może być już, delikatnie mówiać wku****jące...

Poczytaj o MPCM - funkcji USARTu

McRancor - może troche więcej info ??
Albo jakiś link - po polskiemu (dla nie kumatych ten błąd jest specjialnie )

Dodano po 16 [minuty]:

McRancor napisał:

możesz nawet użyć MPCM, ale bascom tego nie obsługuje.

To wiele mi pomaga

zerpo napisał:

Załóżmy taką sytuację (zakładam, że transmisja obslugiwana jest w przerwaniu):
Sonar zaczyna transmisję. W tym samym czasię Twój robot najeżdża na białą linię... Jak wtedy się zachowasz?

Olewam transmisje i po cheblach

Dodano po 1 [godziny] 55 [minuty]:

gromnik19 napisał:

dla AVRow maksymalny kwarc to 16MHz

ATTINY2313 ma 20Mhz. Myślę, że spokojnie by poleciała na 25Mhz(przy 6v)...

Dodano po 5 [minuty]:

zerpo napisał:

Mała zmiana programu jednego uC może oznaczać konieczość przeprogramowania całej reszty, a to może być już, delikatnie mówiać wku****jące...

Mam pewien myk na ten problem.
Złącze programujące do WSZYSTKICH proców to będzie jedna złączka com.
5 pinów to:GND, CLK, MISO, MOSI i reset.
pozostałe 4 piny mają po jednym tranzystorze na pin i każdy tranzystor włącza zasilanie do 1 procka.
Proste, skuteczne - za jednym złączem możemy programować wszytkie procki - chyba więcej jak 4 to ich nie będzie

Dodano po 1 [godziny] 33 [minuty]:

Potrzebuje info na temat odbierania tylko wybranej częstotliwości(ustawionej przez NE555).
Bardzo dziękuję z góry za pomoc

ps> za pomoc klikam pomógł

Dodano po 4 [minuty]:

Myślałem, żeby fototranzystor podłączyć do dwuwejściowej bramki AND(hmmm coś mi się wydaje, że najlepsza była by bramka XNOR)