Moduły startowe w kategoriach ~sumo - Wasza opinia

[KD93]

Wg mnie dodatkowe oczekiwanie po starcie robotów przy pomocy modułów jest zbędne, niepotrzebnie opóźnia walki i dodatkowo wprowadza po części to, czemu ma przeciwdziałać - niedokładności odliczania tego czasu przez roboty.

Nie wiem tylko czy jest sens tego zdalnego zatrzymywania robotów, wolę jednak łapać i wyłączać przyciskiem niż być narażonym na jakieś przypadkowe wyłączenie robota sygnałem IR. Niby z pomocą przychodzi ten EEPROM, ale nie wszystkie roboty go mają (pozdro dla Horneta 😋 ).

[ProeXtreme]

KD93, a nie będzie przypadkiem tak, że jak widz-żartowniś będzie chciał wyłączyć jednego robota to wyłączy oba? Zależy gdzie każdy z robotów będzie miał odbiornik IR, ale jest to wysoce prawdopodobne. Ewentualnie musiałby wysoko wyciągnąć rękę aby wyłączyć tylko jednego. W tym momencie jednak zostało by to zauważone.

[Treker (Damian Szymański)]

Można na module dodać LED'a (jeśli już go tam nie ma), który informowałby, że zatrzymanie nastąpiło właśnie z jego rozkazu.

[mactro]

Pomysł z LEDem dobry, ale czy naprawdę myślicie, że ktoś będzie na tyle wredny, żeby celowo wyłączać roboty w czasie walki? Trochę wiary w ludzi 😉

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[BlackJack]

Ja bym chciał trochę wrócić do problemu, wykorzystania popularnych rozwiązań radarów na TSOPach. Otóż ten pilot działa na 38KHz jak się nie mylę. Co teraz jak zastosuję prosty radar, np. wg. pomysłu KD93, który będzie siał na 38KHz. Teoretycznie kodowanie RC5 zapewnia, odporność na to, jednak pod pewnym warunkiem, że mój radar nie będzie używał czasów ramki podobnych do tych z RC5 (T = 1,778ms czyli powtarzanie paczek ok 562Hz)

Co do pytania kolegi KD93, o to że jak ma 4 TSOPy na pokładzie to czy może je użyć. Jeżeli będą w stanie złapać sygnał, i umiesz napisać odpowiednie oprogramowanie (analizator logiczny działający w real Time) nie widzę problemu.

Ostatecznie zabronić stosować TSOPy na 38KHz.

[koval_blazej]

W Wiedniu kill switch był wymagany tylko do sumo ze względów bezpieczeństwai myślę, że tu będzie tak samo. Więc jak ktoś tak się boi tego wyłączania, nie musi go używać.

Można też ustawić kilka odbiorników wokół ringu, żeby wyłapywać ewentualne manipulacje.

[bulibulibu]

To co napisał mactro: Jezu, trochę wiary w ludzi. Zresztą, jakby ktoś został przyłapany na oszustwie (przy ilu walkach może się udać? Jednej? Pięciu? W końcu ktoś się zorientuje) to jest spalony na wszystkich polskich zawodach, a na forbocie zostanie przeklęty do piątego pokolenia. Poza tym wpierw ten ktoś musi zdekodować jaki kod dohyo został wgrany do robota/modułu (który, jeśli jesteśmy przewrażliwieni, można zmieniać co walkę). Przy innym kodzie dohyo można sobie wciskać kill switch do woli.

[danioto]

Hej,
oczywiście, mimo, że nie startowałem w tej konkurencji i raczej nie planuję (raczej), to też popieram standaryzację. Zastanawiam się tylko nad sprawą ustawienia robotów. Czy dobrym pomysłem byłoby określenie jednego punktu i sposobu ustawienia robota? Jasnym jest, że wyklucza to przypadkowość i jest bardziej profesjonalne, ale czy to nie odbiera możliwości ustawienia według jakiejś taktyki? Jak sądzicie?

Chciałem spytać również o system wizyjny. Kilka razy przewinął się jego temat tutaj, ale chyba nie do końca rozumiem jego sensu... Co taki system miałby sprawdzać/kontrolować? Poza rzuceniem obrazu na jakiś ekran nie widzę innego zastosowania...

[KD93]

Czy dobrym pomysłem byłoby określenie jednego punktu i sposobu ustawienia robota?

IMO nie, bo skoro z góry będzie wiadomo jak będą ustawione roboty to przewagę ma na starcie ten, który potrafi się szybciej obrócić. To wg mnie powinno zostać tak jak jest.

Na marginesie, na Robotic Day ustawiało się roboty naprzeciw siebie "face to face" w odległości 10cm. Robot z klapką jest bez szans, a wygrałaby konstrukcja z jednym mocnym silnikiem na dwa koła i mocno przylegającym pługiem, nawet proc by nie był potrzebny.

[ Dodano: 15-05-2012, 14:43 ]

Chciałem spytać również o system wizyjny. Kilka razy przewinął się jego temat tutaj, ale chyba nie do końca rozumiem jego sensu... Co taki system miałby sprawdzać/kontrolować? Poza rzuceniem obrazu na jakiś ekran nie widzę innego zastosowania..

Co do systemu wizyjnego to chodzi o kamery z dużą ilością FPS, zdolne do wychwytywania falstartów z dokładnościa do kilku ms.

[MatManiak]

Co do systemu wizyjnego to chodzi o kamery z dużą ilością FPS, zdolne do wychwytywania falstartów z dokładnościa do kilku ms.

..które w przypadku użycia modułów startowych są oczywiście zbędne;) Oczywiście jeśli po starcie z pilota, roboty ruszałyby odrazu, bez odliczania 5sek, co jest oczywiście lepszym rozwiązaniem, bo eliminuje ewentualne falstarty.

Ktoś wyżej też wspomniał o odliczaniu przez sędziego "3,2,1, [przycisk na pilocie]" - to też nie jest dobre rozwiązanie, bo mógłbym mieć oprócz modułu startowego wymaganego przez oragnizatora, własnego TSOPa (bo to przecież nie zabronione) i własny pilot i robić minimalne falstarty, słysząc "jeden" wypowiadane przez sędziego. Lepsze byłoby: "gotów" i jakiś losowy czas, po którym sędzia by naciskał pilot. Po naciśnięciu, roboty odrazu startują.

[danioto]

Bez przesady. Nie zakładajmy, że pierwsze co robi uczestnik turnieju to wczytuje się w regulamin i próbuje próbuje oszukać. Wydaje mi się, że Ci co mieliby realne szanse na wygraną nie poniżyliby się do tego, by oszukiwać z milisekundowym falstartem. A jeśli ktoś nie miałby realnej szansy by wygrać, to tych kilka milisekund mu nie pomoże. Jeśli myślelibyśmy o całkowitym wyeliminowaniu przypadku i oszustwa to można byłoby zrobić i RC5, i wizję, i jeszcze czujniki poza ringiem sygnalizujące, czy dany robot został już wypchnięty. Bez przesady.

[mdymczyk]

Bez przesady. Nie zakładajmy, że pierwsze co robi uczestnik turnieju to wczytuje się w regulamin i próbuje próbuje oszukać.

Też jestem zwolennikiem takiego podejścia. Jeśli chodzi o odliczanie sędziego - tak było w Wiedniu właśnie (tzn. '3, 2, 1... start' i wtedy sędzia naciskał przycisk na swoim pilocie) i ciężko by było zamaskować nawet minimalny falstart. Kombinowanie z wcześniejszym odpalaniem wyjdzie natychmiast na jaw, serio.

Co do TSOPów. Na pewno nie będziemy niczego zabraniać ani ograniczać. Do tej pory część osób też korzystało z RC5 do startowania robotów i nic nie wiadomo mi o zakłóceniach ze strony dalmierzy własnej roboty.

[zuraf]

Cześć,

Chciałbym odświeżyć temat modułów. Jako jeden z organizatorów pragnę poinformować, że w trosce o zapewnienie odpowiedniego poziomu zawodów, w tym roku podczas Robotic Areny wymagane będzie stosowanie modułów startowych w klasach microsumo, minisumo oraz sumo. Możliwe będzię jego wypożyczenie w dniu zawodów, lub zbudowanie we własnym zakresie. W tym celu przygotowana została dokumentacja umożliwiająca jego samodzielne wykonanie. Gotowe, przetestowane moduły będą wydawane podczas rejestracji i będą podlegać zwrotowi po zakończeniu zmagań. Konieczne będzie wypełnienie oświadczenia, w którym uczestnik zobowiązuje się do oddania urządzenia. Więcej informacji oraz materiały niezbędne do wykonania własnego modułu na stronie organicatorów

[Barto]

Wydaję mi się, że zapoznałem się z dokumentacją systemu startowania i widzę lukę w systemie. Zaczynając od najprostszej rzeczy- co jeżeli czujniki przeciwnika są oparte na IR i sędzia będzie chciał zatrzymać roboty? Piszecie w uwagach żeby wyłączyć nadawanie podczas czekania na sygnał startu. A co w trakcie walki?

Ktoś pisał, że dotąd nie słyszał o konfliktach nadawania IR i problemem w działaniu odbiorników do startowania. Otóż problem istnieje i jest bardzo spory. Osobiście byłem świadkiem gdzie robot z czujnikami przeciwnika opartymi na IR powodował zakłócanie komend startowych/zatrzymujących przeciwnika. Nadawanie było zwykłym prostokątem 36kHz. Skończyło się na zasłanianiu modułu kartką papieru przez zawodnika.Żeby wyczerpać problem- zgodnie z regulaminem zabronione jest skanowanie czujnikami przed startem. Nie ma żadnej mowy o pracy nadajnika.

Druga rzecz, tycząca się myślę większej ilości zawodników. Niby moduły nie są zbyt duże i ze standardowymi wyjściami. Ale co z ich montażem mechanicznym i "upchaniem" w zakończonych już konstrukcjach?Umieszczanie ich na górze, gdzie przelatywanie robotów jest na porządku dziennym (minisumo) może skończyć się uszkodzeniem płyty głównej robota. Zmierzam do tego, że robiąc konstrukcję od zera takie rzeczy się uwzględnia, mając stan zastany jest to niełatwe. Jest jeszcze pewna opcja. Wykorzystanie odbiorników w czujnikach do odbioru kodu z pilota. Pomijając problem częstotliwościowy jest jeden znacznie większy który z pewnością KD93 potwierdzi. Odbiorniki są bardzo ukierunkowane w podłoże i IR z "kodem" idąca z góry może zostać nie odebrana lub potraktowana jako zakłócenie.

Liczę na owocną dyskusję.

Ogólnie zawsze SKORP był za eliminacją falstartów. Pomysł z modułami jest dość skuteczny, ale dość uciążliwy dla starych ekip.

[zuraf]

Moduły z powodzeniem były stosowane na tegorocznych zawodach w Wiedniu i żaden z opisywanych problemów nie występował. Jako jeden z uczestników RC również byłem zobligowany do zainstalowania modułu w swoim robocie, który nie był z myślą o tym projektowany. Pomimo tego nie było to wielkim problemem. Myślę, że robot minisumo jest na tyle duży, by wygospodarować 2cm^2 powierzchni w miejscu, gdzie nie występuje ryzyko jego uszkodzenia. Oczywiście, istnieją różne konstrukcje mechaniczne, być może w niektórych przypadkach będzie to problematyczne, ale zawsze można znaleźć rozwiązanie. W przypadku mniejszych konstrukcji, wiadomo, miejsca jest odpowiednio mniej. Dlatego jeśli z powodu zainstalowania modułu robot nie spełnia wymagań odnośnie wymiarów/masy, sędziowie będą to uwględniać.

Co do zakłócania czujników, samoczynnych startów itp... Dokumentacja autorów modułów jest dostępna w sieci (link w pdfie). Jeśli ktoś wystarczająco uważnie ją przejrzał, wie, że start robota nie odbywa się po odebraniu nośnej, lecz odpowiedniego adresu i komendy. Czy uważasz, że wystarczająco prawdopodobne jest to, że zakłócenia docierające do modułu ułożą się w poprawną sekwencję, odpowiadającą kodowaniu RC5 i zawierająca odpowiednią informację?

Odbiorniki działają w pasmie 38kHz. Jak wspomniałeś, większość czujników w robotach działa na 36kHz. Wiadomo, charakterystyka czułości względem f nie jest prążkiem 38kHz, lecz jest rozciągnięta. Niemniej działamy na innych częstotliwościach, gdzie czułość niepożądanych odbiorników jest znacznie mniejsza. To samo tyczy się czułości na długość fali. W przypadku zastosowanych odbiorników jest to 950nm co wprowadza drugi "stopień swobody" w prawdopodobieństwie występowania przypadkowych odpaleń/zatrzymań robotów.

Poza tym walki, w których robot nie wystartuje z przyczyn losowych będą powtarzane. Jeśli ktoś ze względu na użyte czujniki obawia się o poprawne funkcjonowanie modułu, zawsze może zbudować własny pilot sędziowski i przetestować urządzenie w domowym zaciszu. Decyzja o wprowadzeniu modułów ogłaszana jest na tyle wcześnie, by każdy zdążył z przystosowaniem swojej konstrukcji. Poza tym, pomysł był konsultowany z bracią konstruktorską znacznie wcześniej (patrz ten wątek) i po ankiecie widać, że zyskał poparcie.