Identyfikacja pionków/figur na szachownicy

[Pampuch]

Cześć,

myślę nad projektem elektronicznej szachownicy, która będzie identyfikować jaka figura stoi na polu. Wiem, że jest już podobny temat na forum, jednak założeniem tamtego projektu było, aby elektroniczna szachownica nie różniła się niczym od tej tradycyjnej, żadne wiercenie czy coś nie wchodziło w grę. Mój projekt nie ma takiego ograniczenia i zastanawiam się czy następujące rozwiązanie ma jakiś sens: figury i pionki będą miały pod spodem diody o różnej barwie, a każde pole będzie posiadać czujnik koloru, który w ten sposób ma zidentyfikować naszą bierkę. Nie miałem co prawda do tej pory styczności z czujnikami koloru i nie wiem czy to w ten sposób zadziała, stąd moje pytanie do Was. Myślicie, że ma to rację bytu? Czy sugerujecie jakieś inne rozwiązanie? 

[AntekBezak]

@Pampuch Jeśli użyjesz tego rozwiązania w każdej figurze będzie musiała być bateria. Jeśli znasz pythona to możesz użyć YOLOv8. To naprawdę potężny i prosty w użyciu algorytm do rozpoznawania obiektów na obrazie np. z kamerki.

[Pampuch]

@AntekBezak Niestety w pythonie nie miałem okazji jeszcze programować. Pewnie warto to nadrobić. 

A może zamiast diod wystarczyłyby kartki pod spodem pionka/figury w różnych kolorach? 

[H1M4W4R1]

1 godzinę temu, Pampuch napisał:

Cześć,

myślę nad projektem elektronicznej szachownicy, która będzie identyfikować jaka figura stoi na polu. Wiem, że jest już podobny temat na forum, jednak założeniem tamtego projektu było, aby elektroniczna szachownica nie różniła się niczym od tej tradycyjnej, żadne wiercenie czy coś nie wchodziło w grę. Mój projekt nie ma takiego ograniczenia i zastanawiam się czy następujące rozwiązanie ma jakiś sens: figury i pionki będą miały pod spodem diody o różnej barwie, a każde pole będzie posiadać czujnik koloru, który w ten sposób ma zidentyfikować naszą bierkę. Nie miałem co prawda do tej pory styczności z czujnikami koloru i nie wiem czy to w ten sposób zadziała, stąd moje pytanie do Was. Myślicie, że ma to rację bytu? Czy sugerujecie jakieś inne rozwiązanie? 

O matko ale przekombinowane... 😄

Nie mogą to być zwykłe styki i figurka z magnesami? W figurce są styczniki złożone ze sprężyn i kulek łożyskowych, które poruszają się w pionie (oczywiście kulka w pełnym "rozprężeniu" sprężyny lekko wystaje poza podstawę figury, ale nie wypada (otwór jest nieco mniejszy od jej średnicy).

Magnesy pozwalają ustawić figurę w konkretnej pozycji niezbędnej do komunikacji. Wewnątrz figury jest tani EEPROM, z którym szachownica się komunikuje (oczywiście do tego pełen multiplex pól szachownicy, by ograniczyć ilość MCU).

Tylko ofc figury muszą być nieco "większych rozmiarów".

Okej, przebiłem poziom skomplikowania 😄 Za to rozwiązanie jest znacznie bardziej stabilne.

Edytowano 14 lutego przez H1M4W4R1

[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

[AntekBezak]

Kartki to chyba dobry pomysł

[Pampuch]

@H1M4W4R1 pomysł godny przemyślenia, jednak kurczę, tak jak powiedziałeś, też trochę skomplikowany 😅 Ale dziękuję za przedstawienie swojego rozwiązania 😄 

[Santiago]

To musisz je podświetlać od dołu. I była tutaj szachownica która działała w inny sposób, poszukaj.

[KaDe]

Witam. 

A czy nie prościej było by zrobić w ten sposób by każda figura miała zwykły magnes w podstawie a pod szachownicą matryca złożona z kontaktronów czy czujników Halla i działanie opierałoby się na sprawdzeniu pozycji skąd-dokąd (gdzie się pole zwolniło a gdzie pojawiło) w określonym czasie bądź za potwierdzeniem przycisku czy zegara? Wiadomo że pozycja startowa gry ma taki układ figur i po każdym wykonanym ruchu musi nastąpić "zwolnienie" jednego pola i po chwili zajęcie innego pola. Kontrolując w ten sposób i mając ten obraz w pamięci wiadomo czy to jest biały pion czy czarny skoczek i jakie mają możliwości ruchu czy szachowania? Dobór odpowiedniego sprawdzenia czy nastąpił wykonany ruch, a przy okazji czy wykonanie jego było możliwe. 
Gdybyśmy zaczynali np. analizę już zaczętej partii, niestety trzeba by było wklepać ręcznie co stoi na jakim polu. Ale myślę że to też nie problem, a nie ma kłopotów z masą czujników , oznaczeń, symboli czy kolorów. Wszystko opierałoby się na oprogramowaniu.  

Pozdrawiam Krzysztof.

[H1M4W4R1]

14 godzin temu, KaDe napisał:

Gdybyśmy zaczynali np. analizę już zaczętej partii, niestety trzeba by było wklepać ręcznie co stoi na jakim polu. Ale myślę że to też nie problem, a nie ma kłopotów z masą czujników , oznaczeń, symboli czy kolorów. Wszystko opierałoby się na oprogramowaniu.  

Spróbuj to ogarnąć przy graniu blitza albo bulleta 😉

Edytowano 15 lutego przez H1M4W4R1

[Pampuch]

14 godzin temu, KaDe napisał:

Witam. 

A czy nie prościej było by zrobić w ten sposób by każda figura miała zwykły magnes w podstawie a pod szachownicą matryca złożona z kontaktronów czy czujników Halla i działanie opierałoby się na sprawdzeniu pozycji skąd-dokąd (gdzie się pole zwolniło a gdzie pojawiło) w określonym czasie bądź za potwierdzeniem przycisku czy zegara? Wiadomo że pozycja startowa gry ma taki układ figur i po każdym wykonanym ruchu musi nastąpić "zwolnienie" jednego pola i po chwili zajęcie innego pola. Kontrolując w ten sposób i mając ten obraz w pamięci wiadomo czy to jest biały pion czy czarny skoczek i jakie mają możliwości ruchu czy szachowania? Dobór odpowiedniego sprawdzenia czy nastąpił wykonany ruch, a przy okazji czy wykonanie jego było możliwe. 
Gdybyśmy zaczynali np. analizę już zaczętej partii, niestety trzeba by było wklepać ręcznie co stoi na jakim polu. Ale myślę że to też nie problem, a nie ma kłopotów z masą czujników , oznaczeń, symboli czy kolorów. Wszystko opierałoby się na oprogramowaniu.  

Pozdrawiam Krzysztof.

Wiem, że można to w ten sposób ogarnąć, jednak kluczem mojego projektu jest jednak to, aby szachownica rozpoznawała figury, które na niej stoją, nie pozycję startową 😅

[H1M4W4R1]

Czyli albo styki mechaniczne albo RF albo zabawa z polem magnetycznym przy czym to ostatnie odpada, bo nie masz dość cierpliwości by walczyć z zakłóceniami sąsiednich pól (trust me). RF też nie jest zbyt prostym zadaniem, chociaż może RFID na jakąś częstotliwość o zasięgu 2-5cm z ukierunkowaną anteną by dało radę... Rozpoznawanie kolorów jest dość ryzykowne i niestabilne przy większych ilościach kombinacji.

Najmniej problemów to styki mechaniczne, ale to też kwestia implementacji. Może ktoś ma inny "pomysł"...

Najłatwiej zaimplementować to używająć multiplekserów analogowych, ADC i dzielników napięciowych. Tylko ADC musi mieć bardzo dobrą stabilność, bo tolerancje rezystorów spowodują wtedy ogromną ilość zakłóceń, teoretycznie wysoka rozdzielczość i interpolacja liniowa w funkcji czasu powinny to rozwiązać, ale idnk jak to zadziała w praktyce.

Interpolacja liniowa w funkcji czasu (algorytm)

// DATA: ref currentValue, ref newValue, in deltaTime, in interpolationTime

// Calculate interpolation weight while not dividing by 0 or negative numbers. If division by 0 or negative would occur then consider weight as 1.
var weight = interpolationTime > 0f ? clamp(deltaTime / interpolationTime, 0f, 1f) : 1f;

// Recompute current value using linear interpolation algorithm
currentValue = lerp(currentValue, newValue, weight);

Uwaga: nie jest to stabilny algorytm (nie jest deterministyczny i mocno zależy od wydajności obliczeniowej sprzętu).

Przykład zastosowania H1M4W4R1/LUNA:

	[BurstCompile] [BurstCompatible]
        private void CalculateSpeedFactor(ref WeaponMovementData movementData)
        {
            // Return if deltaTime is 0 to avoid division by zero in the speed calculation
            if (movementData.deltaTime == 0) return;

            // Compute position and speed
            var currentSpeed = (movementData.position - movementData.previousPosition) / movementData.deltaTime;

            var wData = movementData.weaponData;
            
            // Moving average formula using LERP
            var weight = wData.expectedAttackTime > 0 ? math.clamp(movementData.deltaTime / wData.expectedAttackTime, 0f, 1f) : 1f;
            wData.currentSpeed = math.lerp(wData.currentSpeed, currentSpeed, weight);

            movementData.weaponData = wData;
            
            // Update previous position and time for the next frame
            movementData.previousPosition = movementData.position;
        }

EDIT: Ta wersja jest bardziej skomplikowana, bo też zamienia przemieszczenie na prędkość 😉

W CPP jakoś tak (trochę inny algorytm - zwraca wartość, a nie ją aktualizuje):

#include <iostream>

float lerp(float a, float b, float t) {
    return a + t * (b - a);
}

float calculateMovingAverage(float previousValue, float currentValue, float deltaTime, float interpolationTime) {
    float alpha = (interpolationTime > 0) ? (deltaTime / interpolationTime) : 1;
    return lerp(previousValue, currentValue, alpha);
}

int main() {
    float previousValue = 10.0f;
    float currentValue = 15.0f;
    float deltaTime = 1.0f;
    float interpolationTime = 2.0f;

    std::cout << "Moving Average: " << calculateMovingAverage(previousValue, currentValue, deltaTime, interpolationTime) << std::endl;

    return 0;
}

 

Edytowano 15 lutego przez H1M4W4R1

[ethanak]

Mam głupi 🙂 Dioda ir w podstawie figury nadająca określony kod i odbiorniki w szachownicy.

[H1M4W4R1]

1 minutę temu, ethanak napisał:

Mam głupi 🙂 Dioda ir w podstawie figury nadająca określony kod i odbiorniki w szachownicy.

Hmm... Tylko jak zasilić diodę... Bateria? Akumulator? Styki mechaniczne (znowu)?

[ethanak]

5 minut temu, H1M4W4R1 napisał:

Tylko jak zasilić diodę...

O to nikt nie pytał 🙂 Ale baterie bywają małe (takie jak w tych zapalniczkach z latarką). O elektronice to nie wspominam, bo będzie mniejsza niż ta bateria jak się ją dobre zaprojektuje.

[_LM_]

tagi RFID tylko trzeba 64 nadajniki, za to odbiornik można podkleić pod filc pionka. U komunistów dostępne https://pl.aliexpress.com/item/1005004138179272.html   

Edytowano 15 lutego przez _LM_