Spel, läsa position av objekt på ett bräde (1x2m)

[Nerre]

5 m/s motsvarar om jag inte räknat fel 18 km/h. Jag frågar mig hur spelarna ska kunna styra objekten i den hastigheten? Det lär ju behövas otroliga reflexer?

[Perli]

Ultraljud och triangulera kanske?

Sätt en accelerometer + utraljudssändare i varje pjäs. Aktivera ultraljudet med pulser när pjäsen rör sig. Gäller att bara 1 flyttas.

När den står still igen så kan den för säkerhets skull skicka ID några ggr.

Hmm, det skulle kunna vara något. Skulle objektet skicka ut ultraljudspulser då? Med ett eget kodat ID så det går att följa flera samtidigt?

saken som rör sig, i vilken form är den ?och hur rör den sig
ex rullar som en boll, glider som en puck

skulle det vara det sistnämnda kan man ha irlysdiod riktad nedåt och ha lagom raster med fotodioder som reagerar när den kommer över området

Den kommer glida, mer som en puck. Det skulle kunna vara möjligt men ett problem är att plattan måste vara relativt tunn och slagtålig och med bra glid.

5 m/s motsvarar om jag inte räknat fel 18 km/h. Jag frågar mig hur spelarna ska kunna styra objekten i den hastigheten? Det lär ju behövas otroliga reflexer?

Exakt! Det är det som är syftet

[Micke_s]

Om du vill följa flera samtidigt så krävs det nog någon slags synkronisering när varje puck sänder en ultraljudsklick.

[Micke_s]

Hittade detta.
https://people.ece.cornell.edu/land/cou ... /index.htm

Edit:
Även denna kanske är något.
https://hal.archives-ouvertes.fr/hal-01166763/document

[Perli]

Om du vill följa flera samtidigt så krävs det nog någon slags synkronisering när varje puck sänder en ultraljudsklick.

Ja, eller att de sänder på olika frekvenser och kan identifieras utifrån det?

Hittade detta.
https://people.ece.cornell.edu/land/cou ... /index.htm

Edit:
Även denna kanske är något.
https://hal.archives-ouvertes.fr/hal-01166763/document

Första länken, där fick de det inte riktigt att fungera. Reaktionen på signalen varierade med några millisekunder där varje millisekund är ca 30cm vilket är alldeles för låg upplösning.

Den andra lyckades de får milimeterprecision, det är imponerande! Måste läsa den noga, tack för tipset!

[Nerdboy123]

Vad är budgeten?
Jag tror att en billig kamera med typ 60/120 fps är tillräckligt och det finns redan rätt mycket färdig mjukvara för att köra object tracking på github.
Gopro kanske är en bra början, går att få för runt 2 lax på blocket.
Annars skulle en kinect kanske kunna göra jobbet.

Nätverket med trådar under och en magnet skulle också kunna funka, genom att multiplexa varje tråd att läsa av dom med rätt hög frekvens skulle man kunna få en rätt hög upplösning med relativt liten budget.

[Perli]

Kan absolut lägga några tusenlappar på att försöka få till en fungerande prototyp. Ska fundera på en kamera ändå, det kanske inte gör något ifall precisionen inte är den bästa. Får man det att fungera hjälpligt så får man experimentera lite med vad som krävs för att få tillräckligt bra kvalité!

Går det att komma undan billigt så är det ju såklart att föredra! Ska labba lite med koppartråd och magneter och se om det ens går att läsa av någon puls.

[nifelheim]

Raspberry pi kameran går i 90fps om man minskar upplösningen till VGA, kanske skulle räcka?
200 cm 640 pixlar borde bli 0,3 cm /pixel
5m/s drygt 5 cm mellan två bildrutor?

[bobobo]

Nifelheims förslag låter vettigt.
Annars finns här kameror med 400fps för 167eur (+objektiv)
https://www.get-cameras.com/industrial-cameras
(Jag har bara hittat dem via Google, ingen egen erfarenhet)

[E Kafeman]

Tror inte elektronik kommer må så bra i objektet som ska flyttas runt, det kommer nog utsättas för ganska omild behandling. Väldigt snabba riktningsförändringar, stötar och slag.

Objekt som ska flyttas runt, snabba riktningsförändringar?
En aning fattig beskrivning för att uttrycka det milt så svaren blir på samma nivå.
Finns siffror/beskrivning av vad som är "omilt" och vad som är snabbt?
Finns en beskrivning av hur spelet ska interagera med spelarna, informations-vägar till och från spelarna, vad spelaren ska reagera på och hur återkopplingen ska ske?
Jämför t.ex. ett fjärrstyrt flipperspel där spelaren ska ges information via bildskärm att vid rätt tillfälle aktivera en viss flipper via joystick/tangentbord från spelaren för att därifrån skapa en signalväg att påverka mekaniska induktivt styrda flipprar. Här går att ställa systemkrav på t.ex. tidskraven på de olika system-delarna.

Somliga kallar simultan-schack för ett snabbt och omilt spel på liten spelplan med korta beslutstider.
Detta spelet, kan dess systemkrav specificeras?

Jag var med och tog fram realtids tracking av ishockey-puckar för ett par år sedan. Byggde på en kombo av absolutläges-referenser och 3D accelerometer som mätte upp till 250G och överlever 10.000G.
Det kan uppstå upp till 6000G men räknefelet för oräknad G/positions-förändring blir minimal.

Det var vissa praktiska problem med att få batteriet till att överleva men det löste sej. Av ekonomiska skäl har man sålt in tekniken i en helt annan idrottsgren.
Info: https://www.dna.fi/dnabusiness/blogi/-/ ... al-markets
Inte så informativ hemsida: http://www.sportiq.fi/
Inte samma men snarlik funktions-beskrivning: https://www.researchgate.net/publicatio ... ockey_Puck
Där står visserligen att max g-force är 60.000G men det lär aldrig inträffa då pucken i sej är mer elastisk.

Det är realtids tracking men realtid är relativt. Används BT så finns redan där en paket-fördröjning. Används kamera finns en frame-fördröjning innan något alls processas. Mellan BT och bildskärm ska numeriska data processas och presenteras som grafik. Spelaren ska förmodligen utföra något som skapar en liknande händelsekedja åt andra hållet fast därom är det bara gissning.
Det medie som ska presentera informationen om den ska vara aktuella, 10m/s och positions-upplösning 0.1m innebär att man har 10ms på sej att registrera och överföra position till spelaren innan positionen är utanför förväntad positions-noggrannhet.

Exempelvis BT. Ett normalt 3D gyro-chip, MPU-6000, överför 3D data (eg. 9axlar) seriellt (I²C) till BT-chippet som kan överföra data i nästkommande sänd-framen. Typisk tid från faktisk händelse till utsänd data kan kosta 3-4 mS. https://www.electronicdesign.com/techno ... ignspart-1
Om optimalt så finns 7 mS kvar för att göra något med den seriella 3D-datan som mottagits.
Ska data gå vidare till PC eller hur ska seriell 3D-data omvandlas till något en person kan agera efter inom den tidsgränsen?
Skickas data till PC för att skapa någon grafisk representation, kan gå rätt snabbt men bildskärmen kanske bara uppdateras 100ggr/s. Har man otur skapar det ensamt en fördröjning på 10mS vilket går utanför krävda positions-noggrannheten.
Ett snabbt "BT till PC-skärm" system kan få det svårt att garantera bättre än 20mS. Sedan ska spelaren utföra något mha av den nya informationen och det ska processas tillbaka till spelplanen på begränsad tid?
Finns någon övergripande beskrivning hur spelet fungerar, vad spelaren ska utföra och hur spelaren ska få information att reagera på och vad som ska ske med den informationen, om den ska återmatas på något vis via hårdvara t.ex.?

En kamera för positionering är tekniskt en betydligt enklare lösning, kräver mindre kunskaper att konstruera då det finns massor av halvfärdig kod på nätet för positions-bestämning av många slag men det blir fortfarande en utmaning vad gäller reaktions-tid om processandet ska gå fram och tillbaka genom en PC på 10-20mS.
"Stuff made here" använder kamera för att träffa basketkorg och komplicerad positions-bestämning av biljardbollar på spelplan.
Blandat resultat men beskriver rätt bra olika problem att interagera med verkligheten via hård och mjukvara:

[Perli]

Stort tack för ett bra svar!
Du gav mig en hel del att fundera på och det uppskattas verkligen. Jag vet att jag varit lite luddig, det är medvetet. Tycker ändå jag har fått bra svar och funderingar, lyckas vi så ser vi en marknad. Det finns produkter redan som kan sägas vara väldigt primitiva versioner jämfört med vad vi tänker oss försöka uppnå.

Du har naturligtvis helt rätt i att det är väldigt relativt vad som kan anses vara omild behandling, funderar på om inte flipperspelet ligger rätt nära och när du beskriver vad ni lyckades göra med en hockeypuck så känns ju det rätt tryggt! Det ska nog kunna gå att lösa detta ändå! Accelerationen är ju rätt extrem där!

Den övergripande beskrivningen finns inte på pränt utan är väl så att säga fortfarande i ett idé-stadium i våra huvuden. Så man kan väl säga att vi har en övergripande idé av vad vi vill uppnå medans många detaljer fortfarande behöver lösas.

En fördel vi har är att vi kommer inte visa objektets position på skärmen, enbart t.ex. hinder som ska undvikas. Vi kommer därför inte behöva se eftersläpningen som skulle uppstå om objektet skulle upp på skärmen också. Det innebär såklart inte att det blir viktigt att hålla fördröjningen så låg som möjligt men viss brist i upplösning kan lösas matematiskt genom att beräkna vart den befunnit sig mellan två kända positioner.

Helt klart intressant video, en hel del viktiga poänger att ta hänsyn till där.

[Perli]

https://magpi.raspberrypi.org/articles/air-hockey-robot

Intressant! De kör en pie camera v1 i 80 fps. Den fixar både tracking och styra i rätt bra hastighet. Blir till att beställa lite prylar snart så det går att labba lite

[Krille Krokodil]

Många bildanalys-funktioner kan göras med multi-media-funktionerna i CPU eller på GPU och då är man ofta nere på us i
beräkningstid. Intel & Nvidia har sponsrat mycket utveckling av open source där och det mesta finns om än att det kan vara
lite mer pill för att använda det än i kommersiella bilanalys-bibliotek där det kan ske automagiskt under huven.

I industrikameror så kan man också ha kontroll på allt ner till ps eller us, databladen specar alla tider ner i minsta detalj.

Med lite belysning så bör man kunna ligga på en slutartid på under 1 ms här så det bör inte bli särskilt utsmetade objekt.

Jag har gjort ett program i C# som processar 2 MP färgbilder från en GigE industrikamera i 100 FPS och jag har för mig att
CPU låg på under 10% där, med något realtids OS så känns det i min maggrop väldigt görbart att finna positionen inom 10 ms.

[Perli]

Har labbat lite med en Raspberry Pie 4 och en Pi Camera och det fungerar rätt bra faktiskt! Har inte försökt optimera något än utan bara slängt ihop ett "demo". Tack för tipsen alla som kommenterade!